Prometheus生态组件

# 服务发现

# 介绍

Prometheus的服务发现(Service Discovery)功能是其

动态监控能力的核心。服务发现使Prometheus能够自动发现并监控在网络中动态变化的目标（如主机、服务实例等），无需手动配置监控目标的具体地址。这在云基础设施环境中运行的服务尤其重要，因为在这些环境中应用和服务的实例可能会频繁地变化（如扩容、缩容、更新）。

Prometheus支持多种服务发现机制，可以集成不同的环境和平台，如Kubernetes、Consul、AWS EC2、Azure VMs等。服务发现机制会定期查询预配置的服务发现源，自动更新目标列表。

# 常见的服务发现机制

静态配置/基于文件：通过静态文件配置目标。虽然这种方式不涉及自动发现，但在某些简单场景或测试环境中仍然有用。

Kubernetes（K8s）：直接从Kubernetes API服务器获取资源（如 Pods、Services、Endpoints）信息，动态发现和监控K8s集群中运行的服务。

Consul：通过集成Consul服务注册和发现，Prometheus可以自动发现注册到Consul的服务。

云提供商：对于运行在AWS、GCP、Azure等云平台上的资源，Prometheus可以使用云服务提供商的API来发现服务实例。

# 基于文件的服务发现

# 介绍

它仅仅略优于静态配置的方式，它不依赖于任何平台或第三方服务，因而是最为简单和通用的发现方式。静态配置需要重启Prometheus才能生效，而该方式可以在不重启的情况下更新Targets。

# 配置方法

vim ./prometheus/prometheus.yml

scrape_configs:
  - job_name: "prometheus"
    file_sd_configs:
      - files:
        - target/prometheus*.yml
        refresh_interval: 2m
  - job_name: "node"
    # 基于文件的服务发现
    file_sd_configs:
      # 指定要加载的文件
      - files:
        # 文件路径，支持glob通配符
        - target/node*.yml
        # 文件重新加载间隔时间，默认5m
        refresh_interval: 2m

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

vim ./prometheus/target/prometheus.yml

- targets:
  - localhost:9090
  # 额外添加的标签(可选)
  labels:
    app: prometheus

1
2
3
4
5

vim ./prometheus/target/node-linux.yml

- targets:
  - 192.168.10.30:9100
  - 192.168.10.31:9100
  # 额外添加的标签(可选)
  labels:
    app: node-exporter

1
2
3
4
5
6

# 基于Consul的服务发现

# Consul介绍

Consul是一款开源的基于golang开发的服务发现和配置中心应用服务，主要面向分布式、服务化的系统，提供服务注册、服务发现、健康检查、配置管理(键值存储)等功能。

被监控端需要向Consul服务端进行注册，然后Prometheus再连入Consul获取这些被监控端主机的信息，然后在本地将其转化为可被监控的Target。

# Consul部署

# 下载二进制包并解压到/usr/bin
# https://consul.io/downloads

# 创建相关目录
mkdir -p /data/apps/consul/{data,conf}

# 启动Consul
consul agent -server -ui -data-dir=/data/apps/consul/data -config-dir=/data/apps/consul/conf -client=0.0.0.0

# 启动后可以尝试访问Consul的WEB页面：http://10.0.8.1:8500/ui/

1
2
3
4
5
6
7
8
9
10

# Consul命令参数

agent 表示作为节点启动，用于维护集群以及检查注册和健康信息，它作为守护进程运行在集群的每个节点中 -client 客户端模式 -server 服务端模式 -dev 开发模式 -ui 启动内建的WEB界面 -data-dir= 指定数据目录 -config-dir= 指定配置目录 -client=0.0.0.0 指定监听的地址，默认端口8500，该地址会提供HTTP、DNS、RPC等服务

# Consul配置

consul会读取配置目录下所有json文件。

单个配置可以直接service对应一个字典，多个配置就需要service对应列表，其中再嵌套多个字典。

id、name、address、port是最基本的服务配置，tags用于打标供Prometheus基于标签进行过滤。

vim /data/apps/consul/conf/prometheus-server.json

{
	"service": {
			"id": "prometheus01",
			"name": "Prometheus",
			"address": "192.168.10.30",
			"port": 9090,
			"tags": ["prometheus"]
		}
}

1
2
3
4
5
6
7
8
9

vim /etc/consul/nodes.json

{
	"services": [
		{
			"id": "node-exporter-node01",
			"name": "Node Exporter",
			"address": "192.168.10.31",
			"port": 9100,
			"tags": ["nodes"],
			"checks": [
					{
					"http": "http://192.168.10.30:9100/metrics",
					"interval": "5s"
					}
				]
		},
		{
			"id": "node-exporter-node02",
			"name": "Node Exporter",
			"address": "192.168.10.32",
			"port": 9100,
			"tags": ["nodes"],
			"checks": [
                    {
					"id": "metrics-check",
					"name": "Node Exporter metrics HTTP check",
					"http": "http://192.168.10.31:9100/metrics",
					"interval": "5s",
					"timeout": "2s"
                    }
				]
		}
	]
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

checks用于对服务进行健康检查，只有通过健康检查的实例才会包含在服务发现的查询结果中。在服务变得不健康时还会触发告警。

Consul支持的健康检查类型：

HTTP：通过发送HTTP请求到服务的指定端点，并检查响应状态码是否符合预期（例如，200表示健康）。

TCP：尝试建立TCP连接到指定的地址和端口，如果连接成功，则认为服务是健康的。

Script：运行自定义脚本进行检查，脚本需要返回指定的退出状态码来表示服务的健康状态。

TTL（Time to Live）：服务本身负责定期发送心跳到Consul，如果在指定的时间间隔内未收到心跳，服务被认为是不健康的。

# 最后执行命令重新加载配置
consul reload

1
2

# Prometheus配置

vim .prometheus/prometheus.yml

scrape_configs:
  - job_name: "prometheus"
    # 基于consul进行服务发现
    consul_sd_configs:
    # consul的服务端地址
    - server: "192.168.10.20:8500"
    # consul中，只有标签与此处tags相符的服务，才会被认为属于该job
      tags:
      - "prometheus"
      # 读取间隔时间
      refresh_interval: 2m
  - job_name: "node_exporter"
    consul_sd_configs:
    - server: "192.168.10.20:8500"
      tags:
      - "nodes"
      refresh_interval: 2m

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

配置后重启Prometheus即可，使用服务发现的Targets会有一系列_meta开头的元标签，可用于重新打标时使用。

# 重新打标

# 指标抓取的周期过程

# 1. 服务发现

Prometheus首先通过配置的服务发现机制去发现监控目标（Target）。
服务发现机制可以是静态的，也可以是动态的，如基于Consul、Kubernetes等。

# 2. 元标签的重新打标 (`relabel_configs`)

在抓取指标之前，Prometheus允许对服务发现的目标的元标签进行重新打标（修改、添加或删除标签）。
这个阶段通常用于精确控制哪些目标被抓取（通过过滤、保留操作），以及为目标设定更加有意义的标签。

# 3. 抓取指标

Prometheus根据服务发现和重新打标的结果，对目标进行指标抓取。

# 4. 指标的重新打标 (`metric_relabel_configs`)

在指标被存储之前，Prometheus还可以对抓取到的指标数据进行一次重新打标。
这个阶段通常用于在指标级别进行过滤、修改标签等操作，比如删除某些不需要的标签，或者调整标签值的格式。

# Target默认标签

__address__标签值为该target的套接字地址<host>:<port>。
instance标签值为__address__的值。
__scheme__标签值为抓取该Target指标时使用的协议(http或https)。
__metrics_path__标签值为抓取该Target上指标时使用的URI路径，默认为"/metrics"。
__param_<name>标签的值为传递的URL参数中第一个名称为<name>的参数值。

# 元标签的重新打标

元标签的重新打标需要在配置文件中使用relabel_configs参数进行配置，relabel_configs在抓取之前应用，常用于过滤目标或者将元数据标签中的信息附加到指标的标签上。

# 这个例子中，对于example任务中发现的目标，它会将__address__元标签的值替换为example-instance，并将其作为instance标签的值
scrape_configs:
  - job_name: 'example'
    static_configs:
      - targets: ['localhost:9090']
    # 指标打标配置
    relabel_configs:
      # 指定要引用的已有元标签
      - source_labels: ['__address__']
        # 指定引用的元标签的标签值使用的分隔符，默认是";"
        separator: ";"
        # 新创建标签时的标签名
        target_label: 'instance'
        # 指定regex匹配成功时，赋值给新标签的值，默认是$1
        replacement: 'example-instance'

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# 指标的重新打标

指标的重新打标需要在配置文件中使用metric_relabel_configs参数进行配置，在抓取后应用，常用于从指标中删除敏感或不需要的标签、添加或编辑或修改指标的标签值或标签格式。

# 这个例子中，对于example任务中抓取到的所有指标，它会修改job标签的值，前面添加modified-前缀
scrape_configs:
  - job_name: 'example'
    static_configs:
      - targets: ['localhost:9090']
    metric_relabel_configs:
      - source_labels: ['job']
        # 重新打标时执行的动作
        action: 'replace'
        # 对引用标签的值进行模式匹配时的正则表达式，默认是(.*)
        regex: '(.*)'
        # 新创建标签时的标签名
        target_label: 'job'
        # 指定regex匹配成功时，赋值给新标签的值，默认是$1
        replacement: 'modified-${1}'

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# action动作说明

# 替换标签值

replace：替换标签值，当regex能够匹配到target上的source_labels上的各标签的串连值时，将target_label字段中指定的标签的值替换为replacement字段中保存的值

hashmod：将target_label的值设置为一个hash值，该hash则modules字段指定的盐值对source_labels上各标签的串连值进行hash计算生成

# 删除指标

keep：当regex不能匹配到target上的source_labels上的各标签的串连值时删除该target

drop：当regex能够匹配到target上的source_labels上的各标签的串连值时删除该target

# 创建或删除标签

创建或删除标签是基于所有标签的标签名称来进行regex匹配的，不需要指定source_lables。

labelmap：将regex对所有的标签名进行匹配判定，如果能够匹配到，则可以用匹配到的值，经由replacement引用作为新的标签名创建，值仍是原来的。通常用于取出匹配的标签名的一部分生成新标签。

labeldrop：将regex对所有的标签名进行匹配判定，能够匹配到的标签将从该target的标签集中删除。

labelkeep：将regex对所有的标签名进行匹配判定，不能匹配到的标签将从该target的标签集中删除。应当确保在labeldrop或labelkeep操作后，余下的标签集仍能唯一标识该指标。

# 注意事项

重新打标时还可以使用该target上以__meta__开头的元标签，服务发现机制不同，在target上添加的元标签也会各不相同。
在重新打标的过程中需要临时存储标签值，则需要使用__tmp标签名称为前缀，以避免与其他内建标签冲突。
重新打标后，Target上以"__"开头的所有标签都会被移除。

# Grafana

# 介绍

Grafana是一个开源的度量分析和可视化套件，广泛用于展示时间序列数据的图形化仪表板。它通过提供强大而灵活的方式来创建、探索和分享仪表板，是运维人员和开发人员监控应用程序和基础设施状态的首选工具之一。

它的特点有如下：

丰富的数据源支持：Grafana支持多种数据源，包括但不限于Prometheus、MySQL、PostgreSQL、Elasticsearch等。
灵活的仪表板：Grafana的仪表板高度可定制，用户可以根据需要轻松创建和编辑图表、表格、列表和其他多种可视化组件。
团队协作：Grafana支持多用户环境，提供了组织、团队和用户的概念，以及相应的权限控制。
警报功能：Grafana还提供警报规则引擎，允许用户定义基于时间序列数据的警报规则。当数据达到预设的阈值时，Grafana可以通过邮件、Slack等多种方式发送警报。
API接口：Grafana提供了完善的HTTP API，允许程序化方式创建、修改、导入和导出仪表板。

# 部署

进入官网下载地址：https://grafana.com/grafana/download?pg=get&plcmt=selfmanaged-box1-cta1
选择对应版本，在主机上执行官网页面中给出的对应命令。

# WEB页面

Grafana的默认Web端口为3000，我们直接浏览器访问即可：http://localhost:3000/

默认用户名和密码都是：admin

# Grafana添加数据源

侧边栏选择进入配置(小齿轮)。
Data sources选项卡 -> Add data sources。
单击Prometheus的Select。
配置Prometheus数据源。
- URL填Prometheus的IP端口，如：http://192.168.10.20:9090
- 其他的配置可以按需求使用。
单击Save & test保存并测试。

# Grafana新建面板

面板会先通过PromQL语句来获取数据，然后再以图形化的方式展示查询到的数据。

侧边栏选择创建(加号) -> 点击Dashboard。
单击Add an empty panel添加一个新Panel。
添加PromQL获取数据，可Query下的通过+ Query来添加多条查询 (面板上会显示多条线)。
单击右上角Apply来应用面板。
单击右上角保存图标，保存仪表盘。

# Grafana开启默认面板

侧边栏选择进入配置(小齿轮)。
Data sources 选项卡 -> 选择数据源进行配置。
进入Dashboards选项卡后可Import。

# Grafana添加第三方面板

去官网找面板，并复制面板ID：https://grafana.com/grafana/dashboards/
Grafana页面 -> 侧边栏选择Create -> 单击Import。
输入URL/ID/Json -> 单击Load (注意有2个Load)。
选择数据源 —> 单击Import (Overwrite)。

#Linux #监控 #Prometheus #生态组件

← Prometheus查询 Prometheus告警→

Prometheus生态组件

# 服务发现

# 介绍

# 常见的服务发现机制

# 基于文件的服务发现

# 介绍

# 配置方法

# 基于Consul的服务发现

# Consul介绍

# Consul部署

# Consul命令参数

# Consul配置

# Prometheus配置

# 重新打标

# 指标抓取的周期过程

# 1. 服务发现

# 2. 元标签的重新打标 (relabel_configs)

# 3. 抓取指标

# 4. 指标的重新打标 (metric_relabel_configs)

# Target默认标签

# 元标签的重新打标

# 指标的重新打标

# action动作说明

# 替换标签值

# 删除指标

# 创建或删除标签

# 注意事项

# Grafana

# 介绍

# 部署

# WEB页面

# Grafana添加数据源

# Grafana新建面板

# Grafana开启默认面板

# Grafana添加第三方面板

# 2. 元标签的重新打标 (`relabel_configs`)

# 4. 指标的重新打标 (`metric_relabel_configs`)