Prometheus初体验（三）

一、安装部署

Prometheus基于Golang编写，编译后的软件包，不依赖于任何的第三方依赖。用户只需要下载对应平台的二进制包，解压并且添加基本的配置即可正常启动Prometheus Server。

二进制部署

1、下载安装包

为您的平台下载最新版本的Prometheus，然后解压缩并运行它：

https://prometheus.io/download/

https://prometheus.io/docs/prometheus/latest/getting_started/

tar xvfz prometheus-*.tar.gz
cd prometheus-*
mv prometheus-* /usr/local/prometheus

2、注册为服务

Centos7上，注册为服务：

cat  /usr/lib/systemd/system/prometheus.service

 [Unit]
Description=https://prometheus.io

[Service]
Restart=on-failure
ExecStart=/usr/local/prometheus/prometheus --config.file=/usr/local/prometheus/prometheus.yml

[Install]
WantedBy=multi-user.target

　　

Centos6上，注册为服务：

#!/bin/bash
#
# Comments to support chkconfig
# chkconfig: 2345 98 02
# description: prometheus service script
#
# Source function library.
. /etc/init.d/functions

### Default variables
prog_name="prometheus"
config_file="/usr/local/${prog_name}/${prog_name}.yml"
prog_path="/usr/local/${prog_name}/${prog_name}"
data_path="/usr/local/${prog_name}/data"
pidfile="/var/run/${prog_name}.pid"
prog_logs="/var/log/${prog_name}.log"
#启动项，监听本地9090端口，支持配置热加载
options="--web.listen-address=0.0.0.0:9090 --config.file=${config_file}  --storage.tsdb.path=${data_path}"
DESC="Prometheus Server"

# Check if requirements are met
[ -x "${prog_path}" ] || exit 1

RETVAL=0

start(){
  action $"Starting $DESC..." su -s /bin/sh -c "nohup $prog_path $options >> $prog_logs 2>&1 &" 2> /dev/null
  RETVAL=$?
  PID=$(pidof ${prog_path})
  [ ! -z "${PID}" ] && echo ${PID} > ${pidfile}
  echo
  [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog_name
  return $RETVAL
}

stop(){
  echo -n $"Shutting down $prog_name: "
  killproc -p ${pidfile}
  RETVAL=$?
  echo
  [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog_name
  return $RETVAL
}

restart() {
  stop
  start
}

case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  restart)
    restart
    ;;
  status)
    status $prog_path
    RETVAL=$?
    ;;
  *)
    echo $"Usage: $0 {start|stop|restart|status}"
    RETVAL=1
esac

exit $RETVAL

　　

3、启动promethues

Centos7：

systemctl start prometheus

Centos6:

service prometheus start

Docker方式部署

https://prometheus.io/docs/prometheus/latest/installation/

prometheus.yml通过运行以下命令将您从主机绑定：

docker run -p 9090:9090 -v /tmp/prometheus.yml:/etc/prometheus/prometheus.yml \
       prom/prometheus

　　

或者为配置使用额外的卷：

docker run -p 9090:9090 -v /prometheus-data \
       prom/prometheus --config.file=/prometheus-data/prometheus.yml

　　

二、界面访问

http://localhost:9090访问自己的状态页面

可以通过访问localhost:9090验证Prometheus自身的指标：localhost:9090/metrics

三、自我监控

Prometheus从目标机上通过http方式拉取采样点数据, 它也可以拉取自身服务数据并监控自身的健康状况

当然Prometheus服务拉取自身服务采样数据，并没有多大的用处，但是它是一个好的DEMO。保存下面的Prometheus配置，并命名为：prometheus.yml:

global:
  scrape_interval:     15s # 默认情况下，每15s拉取一次目标采样点数据。

  # 我们可以附加一些指定标签到采样点度量标签列表中, 用于和第三方系统进行通信, 包括：federation, remote storage, Alertmanager
  external_labels:
    monitor: 'codelab-monitor'

# 下面就是拉取自身服务采样点数据配置
scrape_configs:
  # job名称会增加到拉取到的所有采样点上，同时还有一个instance目标服务的host：port标签也会增加到采样点上
  - job_name: 'prometheus'

    # 覆盖global的采样点，拉取时间间隔5s
    scrape_interval: 5s

    static_configs:
      - targets: ['localhost:9090']

　　重启promethues服务。

通过http://10.11.100.99:9090/targets，就可以查看到了：

四、配置文件

配置文件的格式是YAML，使用--config.file指定配置文件的位置。本节列出重要的配置项。

1、全局配置文件

有关配置选项的完整，请参阅：https://prometheus.io/docs/prometheus/latest/configuration/configuration/

Prometheus以scrape_interval规则周期性从监控目标上收集数据，然后将数据存储到本地存储上。scrape_interval可以设定全局也可以设定单个metrics。

Prometheus以evaluation_interval规则周期性对告警规则做计算，然后更新告警状态。evaluation_interval只有设定在全局。

global：全局配置

alerting：告警配置

rule_files：告警规则

scrape_configs：配置数据源，称为target，每个target用job_name命名。又分为静态配置和服务发现

global:
  # 默认抓取周期，设置每15s采集数据一次，默认1分钟
  [ scrape_interval: <duration> | default = 1m ]
  # 默认抓取超时
  [ scrape_timeout: <duration> | default = 10s ]
  # 估算规则的默认周期 # 每15秒计算一次规则。默认1分钟
  [ evaluation_interval: <duration> | default = 1m ]
  # 和外部系统（例如AlertManager）通信时为时间序列或者警情（Alert）强制添加的标签列表
  external_labels:
    [ <labelname>: <labelvalue> ... ]

# 规则文件列表
rule_files:
  [ - <filepath_glob> ... ]

# 抓取配置列表
scrape_configs:
  [ - <scrape_config> ... ]

# Alertmanager相关配置
alerting:
  alert_relabel_configs:
    [ - <relabel_config> ... ]
  alertmanagers:
    [ - <alertmanager_config> ... ]

# 远程读写特性相关的配置
remote_write:
  [ - <remote_write> ... ]
remote_read:
  [ - <remote_read> ... ]

　　其中，比较重要的配置为scrape_configs.

2、scrape_configs

根据配置的任务（job）以http/s周期性的收刮（scrape/pull）

指定目标（target）上的指标（metric）。目标（target）

可以以静态方式或者自动发现方式指定。Prometheus将收刮（scrape）的指标（metric）保存在本地或者远程存储上。

使用scrape_configs定义采集目标

配置一系列的目标，以及如何抓取它们的参数。一般情况下，每个scrape_config对应单个Job。

目标可以在scrape_config中静态的配置，也可以使用某种服务发现机制动态发现。

# 任务名称，自动作为抓取到的指标的一个标签
job_name: <job_name>

# 抓取周期
[ scrape_interval: <duration> | default = <global_config.scrape_interval> ]
# 每次抓取的超时
[ scrape_timeout: <duration> | default = <global_config.scrape_timeout> ]
# 从目标抓取指标的URL路径
[ metrics_path: <path> | default = /metrics ]
# 当添加标签发现指标已经有同名标签时，是否保留原有标签不覆盖
[ honor_labels: <boolean> | default = false ]
# 抓取协议
[ scheme: <scheme> | default = http ]
# HTTP请求参数
params:
  [ <string>: [<string>, ...] ]

# 身份验证信息
basic_auth:
  [ username: <string> ]
  [ password: <secret> ]
  [ password_file: <string> ]
# Authorization请求头取值
[ bearer_token: <secret> ]
# 从文件读取Authorization请求头
[ bearer_token_file: /path/to/bearer/token/file ]

# TLS配置
tls_config:
  [ <tls_config> ]

# 代理配置
[ proxy_url: <string> ]

# DNS服务发现配置
dns_sd_configs:
  [ - <dns_sd_config> ... ]
# 文件服务发现配置
file_sd_configs:
  [ - <file_sd_config> ... ]
# K8S服务发现配置
kubernetes_sd_configs:
  [ - <kubernetes_sd_config> ... ]

# 此Job的静态配置的目标列表，用的最多的配置！！！
static_configs:
  [ - <static_config> ... ]

# 目标重打标签配置
relabel_configs:
  [ - <relabel_config> ... ]
# 指标重打标签配置
metric_relabel_configs:
  [ - <relabel_config> ... ]

# 每次抓取允许的最大样本数量，如果在指标重打标签后，样本数量仍然超过限制，则整个抓取认为失败
# 0表示不限制
[ sample_limit: <int> | default = 0

　　

3、relabel_configs

relabel_configs ：允许在采集之前对任何目标及其标签进行修改

重新标签的意义？

• 重命名标签名
• 删除标签
• 过滤目标

action：重新标签动作

• replace：默认，通过regex匹配source_label的值，使用replacement来引用表达式匹配的分组
• keep：删除regex与连接不匹配的目标 source_labels
• drop：删除regex与连接匹配的目标 source_labels
• labeldrop：删除regex匹配的标签
• labelkeep：删除regex不匹配的标签
• hashmod：设置target_label为modulus连接的哈希值source_labels
• labelmap：匹配regex所有标签名称。然后复制匹配标签的值进行分组，replacement分组引用（${1},${2},…）替代

4、基于文件的服务发现

支持服务发现的来源：

• azure_sd_configs
• consul_sd_configs
• dns_sd_configs
• ec2_sd_configs
• openstack_sd_configs
• file_sd_configs
• gce_sd_configs
• kubernetes_sd_configs
• marathon_sd_configs
• nerve_sd_configs
• serverset_sd_configs
• triton_sd_configs

Prometheus也提供了服务发现功能，可以从consul，dns，kubernetes，file等等多种来源发现新的目标。

其中最简单的是从文件发现服务。

https://github.com/prometheus/prometheus/tree/master/discovery

服务发现支持： endpoints，ingress，kubernetes，node，pod，service

五、监控案例

监控Linux服务器

node_exporter：用于*NIX系统监控，使用Go语言编写的收集器。

使用文档：https://prometheus.io/docs/guides/node-exporter/

GitHub：https://github.com/prometheus/node_exporter

exporter列表：https://prometheus.io/docs/instrumenting/exporters/

收集到 node_exporter 的数据后，我们可以使用 PromQL 进行一些业务查询和监控，下面是一些比较常见的查询。

注意：以下查询均以单个节点作为例子，如果大家想查看所有节点，将 instance="xxx" 去掉即可。

CPU使用率：
100 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100)
内存使用率：
100 - (node_memory_MemFree_bytes+node_memory_Cached_bytes+node_memory_Buffers_bytes) / node_memory_MemTotal_bytes * 100
磁盘使用率：
100 - (node_filesystem_free_bytes{mountpoint="/",fstype=~"ext4|xfs"} / node_filesystem_size_bytes{mountpoint="/",fstype=~"ext4|xfs"} * 100)

　　

监控Mysql数据库

mysql_exporter：用于收集MySQL性能信息。

https://github.com/prometheus/mysqld_exporter

https://grafana.com/dashboards/7362

登录mysql为exporter创建账号：
mysql> CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'XXXXXXXX' WITH MAX_USER_CONNECTIONS 3;
mysql> GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';

# cat .my.cnf
[client]
user=exporter
password=exporter123

# ./mysqld_exporter --config.my-cnf=.my.cnf
- job_name: 'mysql'
    static_configs:
      - targets: ['localhost:9104']

六、可视化方案

Grafana是一个开源的最近非常流行的度量分析和可视化工具。

https://grafana.com/grafana/download

Grafana支持查询普罗米修斯。自Grafana 2.5.0（2015-10-28）以来，包含了Prometheus的Grafana数据源。

Grafana.com维护着一组共享仪表板 ，可以下载并与Grafana的独立实例一起使用。

比如

https://grafana.com/dashboards/9276

七、监控告警

告警无疑是监控中非常重要的环节，虽然监控数据可视化了，也非常容易观察到运行状态。但我们很难做到时刻盯着监控，所以程序来帮巡检并自动告警，这个程序是幕后英雄，保障业务稳定性就靠它了。

前面讲到过Prometheus的报警功能主要是利用Alertmanager这个组件。当Alertmanager接收到 Prometheus 端发送过来的 Alerts 时，Alertmanager 会对 Alerts 进行去重复，分组，按标签内容发送不同报警组，包括：邮件，微信，webhook。

使用prometheus进行告警分为两部分：Prometheus Server中的告警规则会向Alertmanager发送。然后，Alertmanager管理这些告警，包括进行重复数据删除，分组和路由，以及告警的静默和抑制。

1、部署Alertmanager

在Prometheus平台中，警报由独立的组件Alertmanager处理。通常情况下，我们首先告诉Prometheus Alertmanager所在的位置，然后在Prometheus配置中创建警报规则，最后配置Alertmanager来处理警报并发送给接收者（邮件，webhook、slack等）。

地址1：https://prometheus.io/download/

地址2：https://github.com/prometheus/alertmanager/releases

注册为服务

#!/bin/bash
#
# Comments to support chkconfig
# chkconfig: 2345 98 02
# description: prometheus service script
#
# Source function library.
. /etc/init.d/functions

### Default variables
base_name="alertmanager"
prog_name="alertmanager"
config_file="/usr/local/${base_name}/${prog_name}.yml"
prog_path="/usr/local/${base_name}/${prog_name}"
data_path="/usr/local/${base_name}/data"
pidfile="/var/run/${porg_name}.pid"
prog_logs="/var/log/${prog_name}.log"
#启动项，监听本地9090端口，支持配置热加载
options="--config.file=${config_file}"
DESC="altermanager"

# Check if requirements are met
[ -x "${prog_path}" ] || exit 1

RETVAL=0

start(){
  action $"Starting $DESC..." su -s /bin/sh -c "nohup $prog_path $options>> $prog_logs 2>&1 &" 2> /dev/null
  RETVAL=$?
  PID=$(pidof ${prog_path})
  [ ! -z "${PID}" ] && echo ${PID} > ${pidfile}
  echo
  [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog_name
  return $RETVAL
}

stop(){
  echo -n $"Shutting down $prog_name: "
  killproc -p ${pidfile}
  RETVAL=$?
  echo
  [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog_name
  return $RETVAL
}

restart() {
  stop
  start
}

case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  restart)
    restart
    ;;
  status)
    status $prog_path
    RETVAL=$?
    ;;
  *)
    echo $"Usage: $0 {start|stop|restart|status}"
    RETVAL=1
esac

exit $RETVAL

　　

启动Alertmanager

service alertmanager start

2、配置alertmanager

一个完整的alertmanager.yml如下：

# 全局配置项
global:
  resolve_timeout: 5m #处理超时时间，默认为5min
  smtp_smarthost: 'smtp.sina.com:25' # 邮箱smtp服务器代理
  smtp_from: '******@sina.com' # 发送邮箱名称
  smtp_auth_username: '******@sina.com' # 邮箱名称
  smtp_auth_password: '******' # 邮箱密码或授权码
  wechat_api_url: 'https://qyapi.weixin.qq.com/cgi-bin/' # 企业微信地址

# 定义模板信心
templates:
  - 'template/*.tmpl'

# 定义路由树信息
route:
  group_by: ['alertname'] # 报警分组依据
  group_wait: 10s # 最初即第一次等待多久时间发送一组警报的通知
  group_interval: 10s # 在发送新警报前的等待时间
  repeat_interval: 1m # 发送重复警报的周期 对于email配置中，此项不可以设置过低，否则将会由于邮件发送太多频繁，被smtp服务器拒绝
  receiver: 'email' # 发送警报的接收者的名称，以下receivers name的名称

# 定义警报接收者信息
receivers:
  - name: 'email' # 警报
    email_configs: # 邮箱配置
    - to: '******@163.com'  # 接收警报的email配置
      html: '{{ template "test.html" . }}' # 设定邮箱的内容模板
      headers: { Subject: "[WARN] 报警邮件"} # 接收邮件的标题
    webhook_configs: # webhook配置
    - url: 'http://127.0.0.1:5001'
    send_resolved: true
    wechat_configs: # 企业微信报警配置
    - send_resolved: true
      to_party: '1' # 接收组的id
      agent_id: '1000002' # (企业微信-->自定应用-->AgentId)
      corp_id: '******' # 企业信息(我的企业-->CorpId[在底部])
      api_secret: '******' # 企业微信(企业微信-->自定应用-->Secret)
      message: '{{ template "test_wechat.html" . }}' # 发送消息模板的设定
# 一个inhibition规则是在与另一组匹配器匹配的警报存在的条件下，使匹配一组匹配器的警报失效的规则。两个警报必须具有一组相同的标签。
inhibit_rules:
  - source_match:
     severity: 'critical'
    target_match:
     severity: 'warning'
    equal: ['alertname', 'dev', 'instance']

　　

设置告警和通知的主要步骤如下：

1. 部署Alertmanager
2. 配置Prometheus与Alertmanager通信
3. 在Prometheus中创建告警规则

a、配置Prometheus与Alertmanager通信

# vi prometheus.yml
alerting:
  alertmanagers:
  - static_configs:
    - targets:
       - 127.0.0.1:9093

　　

b、在Prometheus中创建告警规则

# vi prometheus.yml
rule_files:
   - "rules/*.yml"

# vi rules/node.yml
groups:
- name: example   # 报警规则组名称
  rules:
  # 任何实例5分钟内无法访问发出告警
  - alert: InstanceDown
    expr: up == 0
    for: 5m  #持续时间 ， 表示持续一分钟获取不到信息，则触发报警
    labels:
      severity: page  # 自定义标签
    annotations:
      summary: "Instance {{ $labels.instance }} down" # 自定义摘要
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes." # 自定义具体描述

　　

c、触发告警

d、告警状态

一旦这些警报存储在Alertmanager，它们可能处于以下任何状态：

• Inactive：这里什么都没有发生。
• Pending：已触发阈值，但未满足告警持续时间（即rule中的for字段）
• Firing：已触发阈值且满足告警持续时间。警报发送到Notification Pipeline，经过处理，发送给接受者。

这样目的是多次判断失败才发告警，减少邮件。

3、告警分配

route属性用来设置报警的分发策略，它是一个树状结构，按照深度优先从左向右的顺序进行匹配。

route:
  receiver: 'default-receiver'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  group_by: [cluster, alertname]
# 所有不匹配以下子路由的告警都将保留在根节点，并发送到“default-receiver”
  routes:
# 所有service=mysql或者service=cassandra的告警分配到数据库接收端
  - receiver: 'database-pager'
    group_wait: 10s
    match_re:
      service: mysql|cassandra
# 所有带有team=frontend标签的告警都与此子路由匹配
# 它们是按产品和环境分组的，而不是集群
  - receiver: 'frontend-pager'
    group_by: [product, environment]
    match:
      team: frontend

　　

group_by：报警分组依据

group_wait：为一个组发送通知的初始等待时间，默认30s

group_interval：在发送新告警前的等待时间。通常5m或以上

repeat_interval：发送重复告警的周期。如果已经发送了通知，再次发送之前需要等待多长时间。通常3小时或以上

主要处理流程：

1. 接收到Alert，根据labels判断属于哪些Route（可存在多个Route，一个Route有多个Group，一个Group有多个Alert）。
2. 将Alert分配到Group中，没有则新建Group。
3. 新的Group等待group_wait指定的时间（等待时可能收到同一Group的Alert），根据resolve_timeout判断Alert是否解决，然后发送通知。
4. 已有的Group等待group_interval指定的时间，判断Alert是否解决，当上次发送通知到现在的间隔大于repeat_interval或者Group有更新时会发送通知。

4、告警收敛（分组、抑制、静默）

告警面临最大问题，是警报太多，相当于狼来了的形式。收件人很容易麻木，不再继续理会。关键的告警常常被淹没。在一问题中，alertmanger在一定程度上得到很好解决。

Prometheus成功的把一条告警发给了Altermanager，而Altermanager并不是简简单单的直接发送出去，这样就会导致告警信息过多，重要告警被淹没。所以需要对告警做合理的收敛。

告警收敛手段：

分组（group）：将类似性质的警报分类为单个通知

抑制（Inhibition）：当警报发出后，停止重复发送由此警报引发的其他警报

静默（Silences）：是一种简单的特定时间静音提醒的机制

5、Prometheus一条告警怎么触发的？

报警处理流程如下：

1. Prometheus Server监控目标主机上暴露的http接口（这里假设接口A），通过上述Promethes配置的'scrape_interval'定义的时间间隔，定期采集目标主机上监控数据。
2. 当接口A不可用的时候，Server端会持续的尝试从接口中取数据，直到"scrape_timeout"时间后停止尝试。这时候把接口的状态变为“DOWN”。
3. Prometheus同时根据配置的"evaluation_interval"的时间间隔，定期（默认1min）的对Alert Rule进行评估；当到达评估周期的时候，发现接口A为DOWN，即UP=0为真，激活Alert，进入“PENDING”状态，并记录当前active的时间；
4. 当下一个alert rule的评估周期到来的时候，发现UP=0继续为真，然后判断警报Active的时间是否已经超出rule里的‘for’ 持续时间，如果未超出，则进入下一个评估周期；如果时间超出，则alert的状态变为“FIRING”；同时调用Alertmanager接口，发送相关报警数据。
5. AlertManager收到报警数据后，会将警报信息进行分组，然后根据alertmanager配置的“group_wait”时间先进行等待。等wait时间过后再发送报警信息。
6. 属于同一个Alert Group的警报，在等待的过程中可能进入新的alert，如果之前的报警已经成功发出，那么间隔“group_interval”的时间间隔后再重新发送报警信息。比如配置的是邮件报警，那么同属一个group的报警信息会汇总在一个邮件里进行发送。
7. 如果Alert Group里的警报一直没发生变化并且已经成功发送，等待‘repeat_interval’时间间隔之后再重复发送相同的报警邮件；如果之前的警报没有成功发送，则相当于触发第6条条件，则需要等待group_interval时间间隔后重复发送。
8. 同时最后至于警报信息具体发给谁，满足什么样的条件下指定警报接收人，设置不同报警发送频率，这里有alertmanager的route路由规则进行配置。

6、编写告警规则案例

# cat rules/general.yml
groups:
- name: general.rules
  rules:
  - alert: InstanceDown
    expr: up == 0
    for: 2m
    labels:
      severity: error
    annotations:
      summary: "Instance {{ $labels.instance }} 停止工作"
      description: "{{ $labels.instance }}: job {{ $labels.job }} 已经停止5分钟以上."

# cat rules/node.yml
groups:
- name: node.rules
  rules:
  - alert: NodeFilesystemUsage
    expr: 100 - (node_filesystem_free_bytes{fstype=~"ext4|xfs"} / node_filesystem_size_bytes{fstype=~"ext4|xfs"} * 100) > 80
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: {{$labels.mountpoint }} 分区使用过高"
      description: "{{$labels.instance}}: {{$labels.mountpoint }} 分区使用大于 80% (当前值: {{ $value }})"
  - alert: NodeMemoryUsage
    expr: 100 - (node_memory_MemFree_bytes+node_memory_Cached_bytes+node_memory_Buffers_bytes) / node_memory_MemTotal_bytes * 100 > 80
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: 内存使用过高"
      description: "{{$labels.instance}}: 内存使用大于 80% (当前值: {{ $value }})"
  - alert: NodeCPUUsage
    expr: 100 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100) > 80
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: CPU使用过高"
      description: "{{$labels.instance}}: CPU使用大于 80% (当前值: {{ $value }})"

# cat rules/reload.yml
groups:
- name: prometheus.rules
  rules:
  - alert: AlertmanagerReloadFailed
    expr: alertmanager_config_last_reload_successful == 0
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: Alertmanager配置重新加载失败"
      description: "{{$labels.instance}}: Alertmanager配置重新加载失败"
  - alert: PrometheusReloadFailed
    expr: prometheus_config_last_reload_successful == 0
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: Prometheus配置重新加载失败"
      description: "{{$labels.instance}}: Prometheus配置重新加载失败"