一、Prometheus基本介绍

Prometheus(由go语言开发)是一套开源的监控&报警&时间序列（按照时间排序）数据库的组合。因为kubernetes(俗称k8s)的流行带动了prometheus的发展。它可以监控主机，服务，容器，支持多种exporter采集数据，还支持pushgateway进行数据上报，Prometheus性能足够支撑上万台规模的集群。

https://prometheus.io/docs/introduction/overview/

时间序列数据(TimeSeries Data) : 按照时间顺序记录系统、设备状态变化的数据被称为时序数据。这种时序数据，会应用到很多场景, 如:

  • 最常见的就是我们系统中的日志

  • 无人驾驶车辆运行中要记录的经度，纬度，速度，方向，旁边物体的距离等等。每时每刻都要将数据记录下来做分析。

  • 某一个地区的各车辆的行驶轨迹数据、车流量

  • 传统证券行业实时交易数据

  • 实时运维监控数据，网卡流量图，服务的当前状态，资源的使用情况，比如说，你所监控的内容出现了直线飙升、断崖式下跌、断线，一般都意味着出现了问题，不管是什么时候发生的，都要赶紧查一下出了什么问题

1.1、时间序列数据库的主要优点

时间序列数据库主要用于指处理带时间标签（按照时间的顺序变化，即时间序列化）的数据，带时间标签的数据也称为时间序列数据。

  • 性能好

关系型数据库对于大规模数据的处理性能糟糕，这一点可以从I/O上有明显的体现。使用NOSQL可以比较好的处理大规模数据，但是依然比不上时间序列数据库。

  • 存储成本低

由于采用的是metrics:key=value（标签:关键字=值）的数据存储方式，又使用了高效的压缩算法，平均消耗的存储成本在3.5个字节左右 ，所以比较节省存储空间 ，并且能有效降低IO

Prometheus有着非常高效的时间序列数据存储方法，每个采样数据仅仅占用3.5byte左右空间，上百万条时间序列数据，每隔30秒采集一次，保留60天，大概占用200多G的空间（来自官方文件数据)

1.2、Prometheus主要特征

  1. 多维度数据模型，可以通过多个维度对数据建模，也可以通过多个维度对数据进行查询

  2. 灵活的查询语言，提供灵活的PromQL查询方式，还提供了HTTP查询接口，可以很方便地结合Grafana等组件展示数据

  3. 不依赖分布式存储，支持单节点的本地存储。通过Prometheus自带的时序数据库，可以完成每秒百万级的数据存储，如果需要存储大量历史数据，还可以对接第三方的时序数据库

  4. 以HTTP方式，通过pull模型拉取时间序列数据，并提供了开放的指标数据标准

  5. 也可以通过中间网关支持push模型

  6. 这种推，拉监控其实就是主动和被动监控，默认情况下是以pull(拉)的方式，也就是监控主机去找被监控主机将数据要过来，如果要实现push(推)的方式需要中间网关的支持，这只是与zabbix的叫法不同而已

  7. 通过服务发现或者静态配置来发现目标服务对象

  8. 支持多种多样的图表和界面展示，可以使用第三方的工具来展示内容，如Grafana

1.3、Prometheus监控原理

  1. Prometheus Server负责定时在目标上抓取metrics(指标)数据，

  2. 每个抓取目标[主机、服务]都需要暴露一个HTTP服务接口用于Prometheus定时抓取。也就是说prometheus会将获取到的监控数据打包成一个可访问的web页面，通过访问指定的url来确定主机的状态

Pull方式的优势是能够自动进行上游监控和水平监控，配置更少，更容易扩展，更灵活，更容易实现高可用。简单来说就是Pull方式可以降低耦合。由于在推送系统中很容易出现因为向监控系统推送数据失败而导致被监控系统瘫痪的问题。因为如果同一时间有很多被监控主机都把数据推送给监控主机的话，就很可能导致监控主机处理不过来，所以通过Pull方式，被采集端无需感知监控系统的存在，完全独立于监控系统之外，这样数据的采集完全由监控系统控制。

1.4、Prometheus配置文件六个大配置段的含义

  • 下面这张图展示了Prometheus的架构和各个组件是如何交互和协作的

  • prometheus配置文件各个大配置段

    • scrape_configs 采集配置段 做采集器

    • rule_files 告警、预聚合配置文件段

    • remote_read 远程查询段

    • remote_write 远程写入段

    • alerting: Alertmanager信息段

  • 优秀的开源项目大多是模块化的，能让使用者根据业务场景自行决定开启哪些配置

对应的配置段 用途
采集配置段 做采集器，数据保存在本地
采集配置段 + 远程写入段 做采集器+传输器，数据保存在本地+远端存储
远程查询段 做查询器，查询远端存储数据
采集配置段 + 远程查询段 做采集器+查询器，查询本地数据+远端存储数据
采集配置段 + Alertmanager信息段 + 告警配置文件段 做采集器+告警触发器，查询本地数据生成报警发往Alertmanager
远程查询段 + Alertmanager信息段 + 告警配置文件段 做远程告警触发器，查询远端数据生成报警发往Alertmanager
远程查询段+远程写入段 + 预聚合配置文件段 做预聚合指标，生成的结果集指标写入远端存储

  • yaml具体配置格式

# 全局配置段
global:
  # 采集间隔 
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  # 计算报警和预聚合间隔
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # 采集超时时间
  scrape_timeout: 10s 
  # 查询日志，包含各阶段耗时统计
  query_log_file: /opt/logs/prometheus_query_log
  # 全局标签组
  # 通过本实例采集的数据都会叠加下面的标签
  external_labels:
    account: 'huawei-main'
    region: 'prometheus'
​
# Alertmanager信息段
alerting:
  alertmanagers:
  - scheme: http
    static_configs:
    - targets:
      - "localhost:9090"
​
# 告警、预聚合配置文件段
rule_files:
    - /etc/prometheus/rules/record.yml
    - /etc/prometheus/rules/alert.yml
​
# 采集配置段
scrape_configs:
  # The job name is added as a label 仪表板job=<job_name>仪表板 to any timeseries scraped from this config.
  - job_name: 'prometheus'
​
    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.
​
    static_configs:
    - targets: ['localhost:9090']
​
# 远程查询段
remote_read:
  # prometheus 
  - url: http://prometheus/v1/read
    read_recent: true
​
  # m3db 
  - url: "http://m3coordinator-read:7201/api/v1/prom/remote/read"
    read_recent: true
​
# 远程写入段
remote_write:
  - url: "http://m3coordinator-write:7201/api/v1/prom/remote/write"
    queue_config:
      capacity: 10000
      max_samples_per_send: 60000
    write_relabel_configs:
      - source_labels: [__name__]
        separator: ;
        # 标签key前缀匹配到的drop
        regex: '(kubelet_|apiserver_|container_fs_).*'
        replacement: $1
        action: drop

二、部署prometheus监控平台

物理主机部署

  • 安装部署prometheus服务监控端

  • 监控一个远端机器

  • 监控一个服务：mysql

#prometheus 主程序包：
wget https://github.com/prometheus/prometheus/releases/tag/v3.0.0/prometheus-3.0.0.linux-amd64.tar.gz 
​
#远端主机监控插件(类似于zabbix-agent): 
wget  https://github.com/prometheus/node_exporter/releases/tag/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz
#告警插件
wget https://github.com/prometheus/alertmanager/releases/tag/v0.27.0/alertmanager-0.27.0.linux-amd64.tar.gz 
#mysql业务监控插件: 
wget   https://github.com/prometheus/mysqld_exporter/releases/tag/v0.16.0/mysqld_exporter-0.16.0.linux-amd64.tar.gz 
#haproxy监控插件
wget https://github.com/prometheus/haproxy_exporter/releases/tag/v0.15.0/haproxy_exporter-0.15.0.linux-amd64.tar.gz 
#nginx监控插件
wget https://github.com/nginx/nginx-prometheus-exporter/releases/tag/v1.5.1/nginx-prometheus-exporter_1.5.1_linux_amd64.tar.gz

容器部署

docker run --name prometheus -d -p 127.0.0.1:9090:9090 prom/prometheus

  • 实验拓扑图
     

2.1、部署prometheus服务监控端

[root@prometheus ~]# tar xf prometheus-3.0.0.linux-amd64.tar.gz -C /home/
[root@prometheus ~]# cd /home/prometheus-3.0.0.linux-amd64/
[root@prometheus prometheus-3.0.0.linux-amd64]# nohup ./prometheus --config.file=prometheus.yml &
[root@prometheus prometheus-3.0.0.linux-amd64]# netstat -anptu | grep prometheus
tcp6       0      0 :::9090                 :::*                    LISTEN      41187/./prometheus  
tcp6       0      0 ::1:9090                ::1:44792               ESTABLISHED 41187/./prometheus  
tcp6       0      0 ::1:44792               ::1:9090                ESTABLISHED 41187/./prometheus  
​

命令帮助

Prometheus 监控服务器
用法：
prometheus [<flags>]
标志：
-h, --[no-]help
显示上下文相关的帮助信息（还可以尝试 --help-long 和 --help-man）。
--[no-]version
显示应用程序版本。
--config.file="prometheus.yml"
Prometheus 配置文件路径。
--config.auto-reload-interval=30s
指定检查和自动重新加载 Prometheus 配置文件的间隔时间，当检测到文件变化时触发。
--web.listen-address=0.0.0.0:9090 ...
用于 UI、API 和遥测的监听地址。可以重复多次。
--[no-]auto-gomaxprocs
自动将 GOMAXPROCS 设置为匹配 Linux 容器的 CPU 配额。
--[no-]auto-gomemlimit
自动将 GOMEMLIMIT 设置为匹配 Linux 容器或系统的内存限制。
--auto-gomemlimit.ratio=0.9
保留的 GOMEMLIMIT 内存与检测到的最大容器或系统内存的比例。
--web.config.file=""
[实验性] 配置文件路径，可用于启用 TLS 或身份验证。
--web.read-timeout=5m
请求读取的最大持续时间，之后将超时并关闭空闲连接。
--web.max-connections=512
跨所有监听器允许的最多同时连接数。
--web.max-notifications-subscribers=16
允许同时接收实时通知的最大订阅者数量。如果达到限制，新的订阅请求将被拒绝，直到现有连接关闭。
--web.external-url=<URL>
Prometheus 外部可访问的 URL（例如，如果 Prometheus 通过反向代理提供服务）。用于生成指向 Prometheus 本身的相对和绝对链接。如果 URL 包含路径部分，它将被用作 Prometheus 提供的所有 HTTP 端点的前缀。如果省略，相关的 URL 组件将自动推导。
--web.route-prefix=<path>
Web 端点内部路由的前缀，默认为 --web.external-url 的路径。
--web.user-assets=<path>
静态资源目录路径，可通过 /user 访问。
--[no-]web.enable-lifecycle
通过 HTTP 请求启用关闭和重新加载功能。
--[no-]web.enable-admin-api
启用用于管理控制操作的 API 端点。
--[no-]web.enable-remote-write-receiver
启用接受远程写入请求的 API 端点。
--web.remote-write-receiver.accepted-protobuf-messages=prometheus.WriteRequest... ...
接收远程写入时允许的远程写入 Protobuf 消息列表。支持的值：prometheus.WriteRequest、io.prometheus.write.v2.Request。
--[no-]web.enable-otlp-receiver
启用接受 OTLP 写入请求的 API 端点。
--web.console.templates="consoles"
控制台模板目录路径，可通过 /consoles 访问。
--web.console.libraries="console_libraries"
控制台库目录路径。
--web.page-title="Prometheus Time Series Collection and Processing Server"
Prometheus 实例的文档标题。
--web.cors.origin=".*"
CORS 源的正则表达式。完全锚定。例如：https?://(domain1|domain2)\.com。
--storage.tsdb.path="data/"
用于存储指标的基础路径。仅用于服务器模式。
--storage.tsdb.retention.time=STORAGE.TSDB.RETENTION.TIME
在存储中保留样本的时间。如果未设置此标志或 storage.tsdb.retention.size，保留时间默认为 15 天。支持的单位：y、w、d、h、m、s、ms。仅用于服务器模式。
--storage.tsdb.retention.size=STORAGE.TSDB.RETENTION.SIZE
可用于存储块的最大字节数。必须指定单位，支持的单位：B、KB、MB、GB、TB、PB、EB。例如：512MB。基于 2 的幂，因此 1KB = 1024B。仅用于服务器模式。
--[no-]storage.tsdb.no-lockfile
不在数据目录中创建锁文件。仅用于服务器模式。
--storage.tsdb.head-chunks-write-queue-size=0
用于将头部块写入磁盘以进行内存映射的队列大小，0 表示完全禁用队列。实验性。仅用于服务器模式。
--storage.agent.path="data-agent/"
用于存储指标的基础路径。仅用于代理模式。
--[no-]storage.agent.wal-compression
压缩代理 WAL。仅用于代理模式。
--storage.agent.retention.min-time=STORAGE.AGENT.RETENTION.MIN-TIME
样本在 WAL 截断时被认为可删除的最小年龄。仅用于代理模式。
--storage.agent.retention.max-time=STORAGE.AGENT.RETENTION.MAX-TIME
样本在 WAL 截断时被强制删除的最大年龄。仅用于代理模式。
--[no-]storage.agent.no-lockfile
不在数据目录中创建锁文件。仅用于代理模式。
--storage.remote.flush-deadline=<duration>
在关闭或重新加载配置时，等待刷新样本的时间。
--storage.remote.read-sample-limit=5e7
通过远程读取接口在单次查询中返回的最大样本数。0 表示无限制。此限制不适用于流式响应类型。仅用于服务器模式。
--storage.remote.read-concurrent-limit=10
远程读取调用的最大并发数。0 表示无限制。仅用于服务器模式。
--storage.remote.read-max-bytes-in-frame=1048576
流式远程读取响应类型在序列化之前单个帧的最大字节数。注意客户端也可能有限制帧大小。默认为 1MB，由 Protobuf 推荐。仅用于服务器模式。
--rules.alert.for-outage-tolerance=1h
在恢复告警的“持续时间”状态时，可容忍 Prometheus 停机的最大时间。仅用于服务器模式。
--rules.alert.for-grace-period=10m
告警与恢复“持续时间”状态之间的最小间隔时间。仅当配置的“持续时间”大于此间隔时，才会维护此间隔。仅用于服务器模式。
--rules.alert.resend-delay=1m
在重新发送告警到 Alertmanager 之前的最小等待时间。仅用于服务器模式。
--rules.max-concurrent-evals=4
全局并发限制，允许独立规则同时运行。如果设置，可能需要相应调整 query.max-concurrency。仅用于服务器模式。
--alertmanager.notification-queue-capacity=10000
待处理的 Alertmanager 通知队列容量。仅用于服务器模式。
--[no-]alertmanager.drain-notification-queue-on-shutdown
在关闭时发送任何未处理的 Alertmanager 通知。如果设置为 false，关闭时将丢弃所有未处理的 Alertmanager 通知。仅用于服务器模式。
--query.lookback-delta=5m
在表达式评估和联邦查询期间检索指标的最大回溯时间。仅用于服务器模式。
--query.timeout=2m
查询的最大执行时间，之后将被终止。仅用于服务器模式。
--query.max-concurrency=20
同时执行的最大查询数。仅用于服务器模式。
--query.max-samples=50000000
单个查询可以加载到内存中的最大样本数。如果查询尝试加载超过此数量的样本，则查询将失败，因此这也限制了查询可以返回的样本数。仅用于服务器模式。
--enable-feature= ...
启用的特性名称列表，用逗号分隔。有效选项：

启动测试


看到这个页面说明prometheus启动成功了，默认监控了自己，我们来看一下本机的监控状态

点击 status—Target-health即可看到监控的机器或者资源

看到本机了，同时也可以根据提示在浏览器中输入http://IP:9090/metrics查看监控数据。

#显示监控数据
http://192.168.166.10:9090/metrics

如果能看到这些信息就说明监控拿到了数据，拿到数据就可以正常显示了。通过这个URL我们可以知道prometheus把监控的数据都统一存放在一起,然后生成一个web页面，用户可以通过web页面查看相关的数据，这些数据遵循了时序数据库的格式,也就是key=value的形式.这些数据就是我们的监控指标，只不过现在还没有办法分析，需要借助图形展示才会更方便阅读

prometheus显示同样也提供了图表，可以通过图表很直观的看到监控项的状态，只不过自带的图形实在是不怎么好看。

通过点击Graph可以显示到下列图表，在搜索栏中输入关键字可以匹配出你想看的监控项

这里输入的是process_cpu_seconds_total，CPU使用状态表就出现了，注意要点一下Graph按钮，默认是在Table按钮页面。

2.2、监控一个远端业务机器

a、安装监控客户端
[root@server ~]# tar xf tar xf node_exporter-1.8.2.linux-amd64.tar.gz -C /home/
[root@server ~]# cd /home/node_exporter-1.8.2.linux-amd64/
[root@server node_exporter-1.8.2.linux-amd64]# ls
LICENSE  node_exporter  NOTICE
​
#后台启动
​
[root@server node_exporter-1.8.2.linux-amd64]# nohup /home/node_exporter-1.8.2.linux-amd64/node_exporter &
[1] 41275
[root@server node_exporter-1.8.2.linux-amd64]# nohup: 忽略输入并把输出追加到'nohup.out'
​
#业务机器监控插件服务端口
[root@server node_exporter-1.8.2.linux-amd64]# netstat -anptu | grep node
tcp6       0      0 :::9100                 :::*                    LISTEN      41275/node_exporter 
​
[root@server node_exporter-1.8.2.linux-amd64]# lsof -i :9100
COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
node_expo 41275 root    3u  IPv6  87955      0t0  TCP *:jetdirect (LISTEN)
​
​
#验证  http://被监控机名称:9100/metrics
http://192.168.166.13:9100/metrics
#现在这台机器上的数据被打包成了一个可以访问的页面，所以可以使用浏览器去访问这个页面，看下能否获取到相关的数据，如果能够获取的话就表示没有问题了。

b、在prometheus添加监控信息
#被监控主机设置完成之后，需要在prometeus主配置文件中添加被监控机信息
[root@prometheus prometheus-3.0.0.linux-amd64]# tail -4  prometheus.yml 
​
  - job_name: 'server'    #定义名称
    static_configs:       #定义具体配置
    - targets: ['192.168.166.13:9100']   #定义目标
     
 #重启服务    
[root@prometheus prometheus-3.0.0.linux-amd64]# pkill prometheus
[root@prometheus prometheus-3.0.0.linux-amd64]# nohup ./prometheus --config.file=prometheus.yml &
​
​
#注意：若prometheus启动报错
#**lock DB directory: resource temporarily unavailable"** 
#原因:prometheus没有正常关闭，锁文件存在
#rm $prometheus_dir/data/lock

c、测试验证

设置完查看prometheus页面

查看Status-Targets页面后可以看到被监控机server(192.168.166.13)已经在监控列表中了，同时可以通过浏览器看看其监控数据。

在浏览器中输入http://192.168.166.13:9100/metrics 能看到数据

2.3、监控一个服务：mysql

要监控mysql需要两个条件，一个是系统中有mysql，另一个是要有监控插件，现在监控插件已经下载好了，所以我们要先安装mysql，然后进行相应的授权，让插件可以获取到所需要的信息，然后再设置相关插件，修改prometheus配置文件

a、部署mysql业务
[root@server node_exporter-1.8.2.linux-amd64]# dnf -y install msyql-sever 
[root@server mysqld_exporter-0.12.0.linux-amd64]# systemctl enable --now mysqld

#创建监控用户
mysql> create user 'hello'@'localhost' identified by '123456';
Query OK, 0 rows affected (0.01 sec)
msyql> grant select,replication client,process on *.* to 'hello'@'localhost';
Query OK, 0 rows affected (0.00 sec)
msyql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

b、部署监控插件
[root@server ~]# tar xf mysqld_exporter-0.16.0.linux-amd64.tar.gz -C /usr/local
[root@server ~]# vim /home/mysqld_exporter-0.16.0.linux-amd64/.my.cnf
[root@server ~]# cat /home/mysqld_exporter-0.16.0.linux-amd64/.my.cnf
[client]
user=hello
password=123456

#启动
[root@server ~]# nohup /home/mysqld_exporter-0.16.0.linux-amd64/mysqld_exporter --config.my-cnf=/home/mysqld_exporter-0.16.0.linux-amd64/.my.cnf &

[root@server ~]# netstat -anptu | grep mysqld_export
tcp6       0      0 :::9104                 :::*                    LISTEN      42271/mysqld_export 

[root@server ~]# lsof -i :9104
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
mysqld_ex 7698 root    3u  IPv6  46415      0t0  TCP *:peerwire (LISTEN)

c、在prometheus主配置文件中添加监控

#
[root@prometheus prometheus-3.0.0.linux-amd64]# tail -10 prometheus.yml 
    static_configs:
    - targets: ['localhost:9090']

  - job_name: 'server'
    static_configs:
    - targets: ['192.168.166.13:9100']
  
  - job_name: 'mysql'
    static_configs:
    - targets: ['192.168.166.13:9104']
d、重启prometheus服务
[root@prometheus prometheus-3.0.0.linux-amd64]# pkill prometheus
[root@prometheus prometheus-3.0.0.linux-amd64]# nohup ./prometheus --config.file=prometheus.yml &

e、通过监控页面查看服务

通过Graph页面看看相关图表

三、prometheus Grafana数据展示及告警

Grafana是一个操作性仪表板，用于可视化和监控数据。它提供了一个强大的平台，可以将多个数据源的数据集成到一个统一的界面中。Grafana支持各种数据源，包括Prometheus、InfluxDB、Elasticsearch等。它还提供了丰富的可视化选项，可以创建漂亮而功能强大的仪表板。Grafana还具有灵活的告警功能，可以根据自定义规则发送通知。无论是在云端还是本地部署，Grafana都是一个非常有用的工具，可以帮助用户实现全面的监控和可视化需求。

3.1、部署grafana

a、grafana安装

软件包获得

官方网站: https://grafana.com/

物理主机部署

软件包安装

#yum安装
sudo yum install -y https://dl.grafana.com/enterprise/release/grafana-enterprise-11.3.1-1.x86_64.rpm

服务启动

#服务启动
[root@grafana ~]# systemctl enable grafana-server
Created symlink from /etc/systemd/system/multi-user.target.wants/grafana-server.service to /usr/lib/systemd/system/grafana-server.service.
[root@grafana ~]# systemctl start grafana-server

#验证启动
[root@grafana ~]# lsof -i :3000
COMMAND     PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
grafana-s 17154 grafana    8u  IPv6  53939      0t0  TCP *:hbci (LISTEN)
容器部署


grafana启动成功后，可以通过页面访问到grafana页面


在浏览器中输入http://IP或者域名:3000




要求输入账号密码： admin/admin（默认)


当看到这个页面说明grafana已经安装成功并且工作了。


输入账号密码登录时，由于是第一次登录，更改密码或者Skip跳过。




输入两次新密码后，点击save即可登录


b、grafana页面设置-汉化




c、grafana页面设置-设置数据源


登录成功后，设置数据源。




点击Add data source 增加数据源




选择Prometheus进入下一步。




点击Save & Test后保存成功




通过左侧导航栏中数据源可以看到对应的数据源




3.2、绘制图形


模版下载地址： https://grafana.com/grafana/dashboards/


a、仪表板管理




添加完数据源后，可以继续添加仪表板，这样我们就能以图表的方式看到数据，继续点击“添加可视化”




图上显示你可以增加一个图形到仪表板，也可以选择其他选项


这里选择“添加可视化”




如上图，在A项中根据需求，匹配你的监控项，如果有多项，可以通过右上角的add query增加，设置完成后就可以设置图表样式了，点击图表




仪表板做好了，同时也看到了我们的图形。


b、grafana设置–添加监控cpu负载的图形












c、grafana设置—使用模板图表展示MySQL监控


mysql监控模板下载


https://github.com/percona/grafana-dashboards


下载完成后将模板解压到指定目录




web界面导入模板，点击“导入”




选择对应的json文件，然后加载即可






点击“import”






创建播放列表












d、设置grafana告警


修改grafana配置文件


[smtp]
enabled = true
host = "smtp.163.com:25"
user = "z13516052620@163.com"
# If the password contains # or ; you have to wrap it with triple quotes. Ex """#password;"""
password = "JUh6g3AiLbNtncD4"
;cert_file =
;key_file =
;skip_verify = false
from_address = "z13516052620@163.com"
from_name = Grafana



重启grafana


systemctl restart grafana














四、 配置alertmanager告警


1、部署alertmanager


[root@grafana ~]#  tar xf alertmanager-0.27.0.linux-amd64.tar.gz -C /usr/local


2、配置alertmanager


global:
  # 全局配置，这里可以设置一些全局的参数，如SMTP的超时时间等（可选）
  smtp_smarthost: 'smtp.gmail.com:587'
  smtp_from: 'your-alertmanager-email@gmail.com'
  smtp_auth_username: 'your-alertmanager-email@gmail.com'
  smtp_auth_password: 'your-email-password'
  smtp_require_tls: true | false

route:
  # 路由规则，这里设置所有警报都走默认路由，发送到名为'mail-receiver'的接收者
  receiver: 'mail-receiver'
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h

receivers:
  - name: 'mail-receiver'
    email_configs:
      - to: 'user1@example.com,user2@example.com'  # 多个接收邮件地址用逗号分隔
        send_resolved: true  # 是否发送警报恢复通知
        headers:
          Subject: '[Alertmanager] {{.CommonAnnotations.summary }}'  # 自定义邮件主题，包含警报摘要

inhibit_rules:
  # 抑制规则（可选，根据需要配置）
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']


配置说明


    
 
  1. 
  
    仪表板global仪表板部分
    
  
      
   
    • 
    
      仪表板smtp_smarthost仪表板：指定 SMTP 服务器地址和端口，这里是 Gmail 的 SMTP 服务器。
      • 
   
    • 
    
      仪表板smtp_from仪表板：设置发件人的电子邮件地址。
      • 
   
    • 
    
      仪表板smtp_auth_username仪表板：用于 SMTP 身份验证的用户名，即发件人的电子邮件地址。
      • 
   
    • 
    
      仪表板smtp_auth_password仪表板：对应的密码。
      • 
   
    • 
    
      仪表板smtp_require_tls仪表板：是否要求使用 TLS 加密连接（Gmail 需要）。
      • 
  
    2. 
 
  2. 
  
    仪表板route仪表板部分
    
  
      
   
    • 
    
      仪表板receiver仪表板：指定接收者名称，这里是仪表板mail-receiver仪表板，表示符合此路由规则的警报将发送到该接收者。
      • 
   
    • 
    
      仪表板group_by仪表板、仪表板group_wait仪表板、仪表板group_interval仪表板和仪表板repeat_interval仪表板的含义如前所述，用于对警报进行分组和控制通知频率。
      • 
  
    3. 
 
  3. 
  
    仪表板receivers仪表板部分
    
  
      
   
    • 
    
      仪表板name仪表板：接收者名称，与仪表板route仪表板中指定的名称对应。
      • 
   
    • 
    
      email_configs：配置电子邮件相关参数。
      
    
        
     
      • 
      
        仪表板to仪表板：接收警报的电子邮件地址列表。
        • 
     
      • 
      
        仪表板send_resolved仪表板：设置是否在警报恢复时发送通知。
        • 
     
      • 
      
        仪表板headers仪表板：可以自定义邮件头，这里设置了邮件主题，包含警报的摘要信息（仪表板{{.CommonAnnotations.summary }}仪表板是一个模板变量，会在发送邮件时替换为实际的警报摘要）。
        • 
    
      • 
  
    4. 
 
  4. 
  
    仪表板inhibit_rules仪表板部分（可选）
    
  
      
   
    • 
    
      这里配置了一个抑制规则示例，当有仪表板severity仪表板为仪表板critical仪表板的警报触发时，相同仪表板alertname仪表板、仪表板dev仪表板和仪表板instance仪表板标签的仪表板severity仪表板为仪表板warning仪表板的警报将被抑制，不发送通知。
      • 
  
    5. 



配置案例


global:
  smtp_smarthost: 'smtp.163.com:25'
  smtp_from: 'z13516052620@163.com'
  smtp_auth_username: 'z13516052620@163.com'
  smtp_auth_password: 'XBTi7jHQRHre6tUm'
  smtp_require_tls: false
route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
  receiver: 'default'
receivers:
  - name: 'default'
    email_configs:
    - to: '330288872@qq.com'
      send_resolved: true
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']



启动服务


[root@grafana alertmanager-0.27.0.linux-amd64]# nohup ./alertmanager --web.listen-address=:9093 --config.file=/home/alertmanager-0.28.1.linux-amd64/alertmanager.yml &
[1] 43740
[root@grafana alertmanager-0.27.0.linux-amd64]# nohup: 忽略输入并把输出追加到'nohup.out'

[root@grafana alertmanager-0.27.0.linux-amd64]# 
[root@grafana alertmanager-0.27.0.linux-amd64]# jobs 
[1]+  运行中               nohup ./alertmanager --web.listen-address=:9093 --config.file=/home/alertmanager-0.27.0.linux-amd64/alertmanager.yml &
[root@grafana alertmanager-0.27.0.linux-amd64]# netstat -anptu | grep :9093
tcp6       0      0 :::9093                 :::*                    LISTEN      43740/./alertmanage 



访问web页面


http://192.168.166.9:9093




3、在prometheus指向Alertmanager


在配置文件中修改如下配置，然后重新加载prometheus即可！


  alerting:
    alertmanagers:
      - static_configs:
          - targets:
             - 192.168.166.9:9093
 
 # Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
  rule_files:
    - "/etc/prometheus/rules/*.yml"  



重新加载配置


[root@prometheus prometheus-3.0.0.linux-amd64]# pkill  prometheus 
[root@prometheus prometheus-3.0.0.linux-amd64]# 
[3]+  已完成               nohup ./prometheus --config.file=prometheus.yml
[root@prometheus prometheus-3.0.0.linux-amd64]# nohup ./prometheus --config.file=prometheus.yml &
[1] 42425
[root@prometheus prometheus-3.0.0.linux-amd64]# nohup: 忽略输入并把输出追加到'nohup.out'

[root@prometheus prometheus-3.0.0.linux-amd64]# jobs 
[1]+  运行中               nohup ./prometheus --config.file=prometheus.yml &



4、定义告警规则


创建/etc/prometheus/rules目录


[root@prometheus ~]# mkdir -p /etc/prometheus/rules


1、配置案例


CPU 使用率过高告警


告警规则


    
 
  • 
  
    假设我们要监控服务器的 CPU 使用率，当 5 分钟内平均 CPU 使用率超过 5% 时触发告警。在 Prometheus 配置文件（通常是prometheus.yml）中添加以下告警规则：
    • 



groups:
- name: cpu-alerts
  rules:
  - alert: HighCPUUsage
    expr: 100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 5
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "High CPU Usage on {{ $labels.instance }}"
      description: "CPU usage has been above 5% for the last 2 minutes on instance {{ $labels.instance }}."


规则解释


    
 
  • 
  
    alert：告警名称，这里是HighCPUUsage。
    • 
 
  • 
  
    expr：告警触发的表达式。100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)计算了 CPU 使用率（100 减去空闲 CPU 时间的平均速率乘以 100），当该值大于 80 时触发告警。
    • 
 
  • 
  
    for：表示告警持续时间。在这个例子中，告警必须持续 2 分钟才会被发送，这样可以避免短暂的 CPU 使用率高峰误触发告警。
    • 
 
  • 
  
    labels：给告警添加自定义标签，这里添加了severity标签并设置为warning，可以用于后续路由和处理告警时根据严重性进行分类。
    • 
 
  • 
  
    annotations：提供关于告警的更多描述信息，summary是告警的简短摘要，description是更详细的描述，其中使用了{{ $labels.instance }}模板变量来显示具体的实例信息。
    • 



内存使用率告警


告警规则


    
 
  • 
  
    当可用内存低于 10% 时触发告警：
    • 



groups:
- name: memory-alerts
  rules:
  - alert: LowMemory
    expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 1050 < 98
    for: 3m
    labels:
      severity: critical
    annotations:
      summary: "Low Memory on {{ $labels.instance }}"
      description: "Available memory is less than 10% on instance {{ $labels.instance }}."


规则解释


    
 
  • 
  
    expr：计算可用内存占总内存的比例，当小于 10% 时触发告警。
    • 
 
  • 
  
    for：告警持续 3 分钟才发送，以防止误报。
    • 
 
  • 
  
    labels和annotations的作用与 CPU 使用率告警中的类似，用于添加额外信息。
    • 



磁盘空间告警


告警规则


    
 
  • 
  
    假设我们要监控根目录（/）的磁盘空间，当可用磁盘空间小于 1GB 时触发告警：
    • 



groups:
- name: disk-alerts
  rules:
  - alert: LowDiskSpace
    expr: node_filesystem_avail_bytes{mountpoint="/"} < 1024 * 1024 * 1024
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Low Disk Space on {{ $labels.instance }}"
      description: "Available disk space on root partition is less than 1GB on instance {{ $labels.instance }}."


规则解释


    
 
  • 
  
    expr：通过node_filesystem_avail_bytes指标筛选出根目录的可用磁盘空间，并与 1GB（1024 * 1024 * 1024 字节）进行比较，小于该值时触发告警。
    • 
 
  • 
  
    for：告警持续 5 分钟才发送，确保磁盘空间不是短暂低于阈值。
    • 



服务不可用告警（基于 HTTP 状态码）


告警规则（假设监控一个 Web 服务）


    
 
  • 
  
    当 Web 服务在 5 分钟内的 HTTP 500 状态码请求数超过 10 次时触发告警：
    • 



groups:
- name: service-alerts
  rules:
  - alert: ServiceUnavailable
    expr: sum by (job) (increase(http_server_requests_total{status_code="500"}[5m])) > 10
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "Service Unavailable: {{ $labels.job }}"
      description: "HTTP 500 status code count has exceeded 10 in the last 5 minutes for service {{ $labels.job }}."


规则解释


    
 
  • 
  
    expr：使用increase函数计算在 5 分钟内 HTTP 500 状态码请求数的增加量，并按job标签进行求和，当总和超过 10 时触发告警。
    • 
 
  • 
  
    for：告警持续 2 分钟才发送，避免短暂的错误高峰误报。
    • 



MySQL连接数过高告警


groups:
- name: mysql-alerts
  rules:
  - alert: MySQLHighConnections
    expr: mysql_global_status_threads_connected > 100
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "MySQL High Connections on {{ $labels.instance }}"
      description: "The number of MySQL connections on instance {{ $labels.instance }} has been above 100 for the last 5 minutes."


    
 
  • 
  
    alert：定义告警名称为MySQLHighConnections。
    • 
 
  • 
  
    expr：告警触发条件表达式，当mysql_global_status_threads_connected指标的值大于 100 时触发告警。这里的阈值 100 可以根据 MySQL 服务器的实际配置和性能进行调整。例如，如果服务器配置较低，可能 50 个连接就会对性能产生较大影响，此时阈值可设为 50；如果服务器配置较高且预期会有较多并发连接，阈值可以适当提高。
    • 
 
  • 
  
    for：设置告警持续时间为 5 分钟。这意味着只有当连接数持续高于 100 达到 5 分钟时，才会触发告警。这样可以避免因瞬间的连接数高峰（如短时间内大量查询请求导致连接数短暂上升）而误触发告警。
    • 
 
  • 
  
    labels：添加自定义标签severity并设置为warning，用于后续根据告警严重性进行分类处理（例如在 Alertmanager 中配置不同的路由规则将不同严重性的告警发送到不同的接收者）。
    • 
 
  • 
  
    annotations：提供告警的详细信息。summary是告警的简短摘要，description是更详细的描述，其中{{ $labels.instance }}是一个模板变量，会在告警触发时替换为实际的实例信息（例如服务器的 IP 地址或主机名等），以便快速定位是哪个 MySQL 实例出现了连接数过高的问题。
    • 



2、常用的expr编写案例


基于指标值比较


大于阈值


    
 
  • 
  
    例如，监控 CPU 使用率（假设node_cpu_seconds_total指标记录 CPU 使用时间），当使用率超过 80% 时触发告警：
    • 



100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80


    
 
  • 
  
    这里先计算空闲 CPU 时间的平均速率（irate(node_cpu_seconds_total{mode="idle"}[5m])），然后通过100 - (...) * 100得到 CPU 使用率，最后与 80% 进行比较。
    • 



小于阈值


    
 
  • 
  
    监控可用内存（node_memory_MemAvailable_bytes），当可用内存低于 10GB 时触发告警：
    • 



node_memory_MemAvailable_bytes < 10 * 1024 * 1024 * 1024  # 10GB转换为字节


范围比较


    
 
  • 
  
    监控请求响应时间（假设http_request_duration_seconds指标记录请求耗时），当响应时间在 1 到 5 秒之间时触发告警：
    • 



http_request_duration_seconds > 1 and http_request_duration_seconds < 5


基于指标变化率


计算指标在一段时间内的增长率


    
 
  • 
  
    例如，监控网络流量（node_network_receive_bytes_total），当 5 分钟内网络接收流量增长率超过 10% 时触发告警：
    • 



(increase(node_network_receive_bytes_total[5m]) / node_network_receive_bytes_total offset 5m) > 0.1


    
 
  • 
  
    increase(node_network_receive_bytes_total[5m])计算 5 分钟内流量的增加量，node_network_receive_bytes_total offset 5m获取 5 分钟前的流量值，两者相除得到增长率并与 10%（0.1）比较。
    • 



计算指标的变化速率


    
 
  • 
  
    监控每秒新创建的进程数（process_start_time_seconds），当每秒创建进程数超过 5 个时触发告警：
    • 



irate(process_start_time_seconds[1m]) > 5


    
 
  • 
  
    irate函数计算指标在 1 分钟内的平均每秒变化速率。
    • 



基于聚合函数


求和


    
 
  • 
  
    假设监控多个服务器的磁盘 I/O 写入字节数（node_disk_writes_bytes_total），当所有服务器的总写入字节数在 5 分钟内超过 10GB 时触发告警：
    • 



sum by (job) (increase(node_disk_writes_bytes_total[5m])) > 10 * 1024 * 1024 * 1024


    
 
  • 
  
    sum by (job)按job标签对 5 分钟内写入字节数的增加量进行求和，然后与 10GB 比较。
    • 



平均值


    
 
  • 
  
    监控服务器的平均负载（node_load1），当平均负载超过 2 时触发告警：
    • 



avg by (instance) (node_load1) > 2


    
 
  • 
  
    avg by (instance)计算每个实例的平均负载并与 2 比较。
    • 



计数


    
 
  • 
  
    监控 HTTP 状态码为 500 的请求数量（http_server_requests_total），当 5 分钟内 500 状态码请求数超过 10 次时触发告警：
    • 



sum by (job) (increase(http_server_requests_total{status_code="500"}[5m])) > 10


    
 
  • 
  
    先通过increase函数计算 5 分钟内 500 状态码请求数的增加量，再按job标签求和，最后与 10 比较。
    • 



基于标签过滤


根据特定标签值筛选指标


    
 
  • 
  
    例如，只监控生产环境（env="production"）的服务器的 CPU 使用率：
    • 



100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle", env="production"}[5m])) * 100) > 80


    
 
  • 
  
    在指标选择器中添加env="production"标签过滤器来筛选特定环境下的 CPU 使用数据。
    • 



组合多个标签筛选条件


    
 
  • 
  
    监控某个特定数据中心（dc="dc1"）且应用程序为app1的服务器的内存使用率：
    • 



(node_memory_MemAvailable_bytes{dc="dc1", app="app1"} / node_memory_MemTotal_bytes{dc="dc1", app="app1"}) * 100 < 10


    
 
  • 
  
    同时使用dc和app标签来精确筛选目标服务器的内存数据。
    • 



基于时间序列偏移


比较当前值与过去某个时间的值


    
 
  • 
  
    监控当前的磁盘空间使用率（node_filesystem_usage_bytes）与 1 小时前的值，如果使用率增加超过 5% 则触发告警：
    • 



(node_filesystem_usage_bytes / node_filesystem_size_bytes) - (node_filesystem_usage_bytes offset 1h) / (node_filesystem_size_bytes offset 1h) > 0.05


    
 
  • 
  
    分别计算当前和 1 小时前的磁盘空间使用率，然后求差值并与 5%（0.05）比较。
    • 



基于逻辑运算组合条件


使用and和or连接多个条件


    
 
  • 
  
    例如，监控服务器的 CPU 使用率和内存使用率，当 CPU 使用率超过 80% 且内存使用率超过 90% 时触发告警：
    • 



(100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80) and ((node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 < 10)


    
 
  • 
  
    使用and连接了 CPU 使用率和内存使用率两个条件，只有当两个条件都满足时才触发告警。
    • 



五、实现钉钉报警


要在 Alertmanager 中配置钉钉告警，需要通过 Webhook 实现 Alertmanager 与钉钉机器人的对接。以下是详细配置步骤及解析：


一、准备工作


    
 
  1. 
  
    创建钉钉机器人
    2. 



    
 
  • 
  
    打开钉钉群聊，进入「群设置」→「智能群助手」→「添加机器人」→「自定义机器人」
    • 
 
  • 
  
    设置机器人名称，勾选「自定义关键词」（如Alertmanager，后续告警消息必须包含该关键词）
    • 
 
  • 
  
    复制生成的Webhook 地址（格式：https://oapi.dingtalk.com/robot/send?access_token=xxx）
    • 
 
  • 
  
    保存机器人，完成准备工作
    • 



二、配置 Alertmanager


    
 
  1. 
  
    编辑 Alertmanager 配置文件（通常为alertmanager.yml）
    2. 



global:
  resolve_timeout: 5m  # 告警解决后，等待多久发送恢复通知

route:
  group_by: ['alertname']  # 按alertname分组告警
  group_wait: 10s          # 同一组内第一个告警触发后，等待10s再发送（可能合并同组新告警）
  group_interval: 10s      # 同一组内再次发送告警的间隔
  repeat_interval: 1h      # 同一告警重复发送的间隔
  receiver: 'dingtalk'     # 默认接收者（对应下方receivers名称）

receivers:
- name: 'dingtalk'
  webhook_configs:
  - url: 'https://oapi.dingtalk.com/robot/send?access_token=你的钉钉机器人token'  # 替换为实际Webhook
    send_resolved: true  # 告警恢复时是否发送通知
    http_config:
      tls_config:
        insecure_skip_verify: false  # 生产环境建议设为true（验证TLS证书）

inhibit_rules:  # 抑制规则（可选，用于避免重复告警）
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance']


三、配置告警消息模板（可选但推荐）


Alertmanager 默认消息格式较简单，可自定义模板让钉钉消息更易读。


    
 
  1. 
  
    创建模板文件（如dingtalk.tmpl）：
    2. 



{{ define "dingtalk.message" }}
{
  "msgtype": "markdown",
  "markdown": {
    "title": "{{ .CommonAnnotations.summary }}",
    "text": "### 告警通知\n"+
            "#### 状态：{{ .Status | toUpper }}\n"+
            "#### 告警名称：{{ .CommonLabels.alertname }}\n"+
            "#### 详情：{{ .CommonAnnotations.description }}\n"+
            "#### 触发时间：{{ .StartsAt.Format "2006-01-02 15:04:05" }}\n"+
            "{{ if gt (len .CommonLabels.instance) 0 }}#### 实例：{{ .CommonLabels.instance }}{{ end }}"
  }
}
{{ end }}


    
 
  1. 
  
    在 Alertmanager 配置中引用模板：
    2. 



在alertmanager.yml中添加：


templates:
  - '/path/to/dingtalk.tmpl'  # 模板文件绝对路径

receivers:
- name: 'dingtalk'
  webhook_configs:
  - url: '你的钉钉Webhook'
    send_resolved: true
    http_config:
      tls_config:
        insecure_skip_verify: false
    headers: { "Content-Type": "application/json" }
    body: '{{ template "dingtalk.message" . }}'  # 引用模板


四、验证配置


    
 
  1. 
  
    检查配置文件语法：
    2. 



alertmanager --config.check-config alertmanager.yml


若输出Config is valid，说明配置无误。


    
 
  1. 
  
    重启 Alertmanager：
    2. 



systemctl restart alertmanager  # 或对应启动命令


    
 
  1. 
  
    测试告警：
    2. 



    
 
  • 
  
    手动触发一个测试告警（如通过 Prometheus 触发一个超过阈值的指标）
    • 
 
  • 
  
    查看 Alertmanager 日志（journalctl -u alertmanager）确认是否有发送记录
    • 
 
  • 
  
    检查钉钉群是否收到告警消息
    • 



五、关键配置解析


    
 
  • 
  
    Webhook 地址：钉钉机器人的唯一接口，Alertmanager 通过该地址推送告警。
    • 
 
  • 
  
    send_resolved：设为true时，告警恢复后会发送 “已解决” 通知，便于跟踪问题状态。
    • 
 
  • 
  
    消息模板：通过 Markdown 格式美化消息，包含告警状态、名称、详情等关键信息，提升可读性。
    • 
 
  • 
  
    自定义关键词：钉钉机器人要求消息必须包含创建时设置的关键词，否则会被拦截，需确保模板中包含该关键词（如Alertmanager）。
    • 



通过以上配置，Alertmanager 即可将告警信息实时推送到钉钉群，实现及时的告警通知。若出现发送失败，可检查网络连通性（是否能访问oapi.dingtalk.com）、Webhook 地址正确性或关键词匹配问题。
 
  

        # kubernetes
      
        # 容器
      
        # docker
      
        # linux
      
        # 运维
      
  
 
 Logo 
AtomGit开源社区
 
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
 
 
  
更多推荐
  
cover
 
亿乐社区官方低价货源站-豆包赋能抖音：从内容创作到运营增长的全场景应用
 
 
avatar AtomGit开源社区
 
cover
 
Kibana 中的 AI Chat 现在可以原生渲染仪表板
 
 
avatar AtomGit开源社区
 
cover
 
AI时代：浅析AI时代战争形态特征
 
 
avatar AtomGit开源社区