千家信息网

如何实现基于Prometheus和Grafana的监控平台之运维告警

发表于:2026-11-01 作者:千家信息网编辑
千家信息网最后更新 2026年11月01日,本篇内容介绍了"如何实现基于Prometheus和Grafana的监控平台之运维告警"的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希
千家信息网最后更新 2026年11月01日如何实现基于Prometheus和Grafana的监控平台之运维告警

本篇内容介绍了"如何实现基于Prometheus和Grafana的监控平台之运维告警"的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!

告警方式

Grafana

新版本的Grafana已经提供了告警配置,直接在dashboard监控panel中设置告警即可,但是我用过后发现其实并不灵活,不支持变量,而且好多下载的图表无法使用告警,所以我们不选择使用Grafana告警,而使用Alertmanager。

Alertmanager

相比于Grafana的图形化界面,Alertmanager需要依靠配置文件实现,配置稍显繁琐,但是胜在功能强大灵活。接下来我们就一步一步实现告警通知。

告警类型

Alertmanager告警主要使用以下两种:

  • 邮件接收器 email_config
  • Webhook接收器 webhook_config,会用post形式向配置的url地址发送如下格式的参数。
 {
"version": "2",
"status": "",
"alerts": [{
"labels": < object > ,
"annotations": < object > ,
"startsAt": "",
"endsAt": ""
}]
}

「这次主要使用邮件的方式进行告警。」

实现步骤
  • 下载
    从GitHub上下载最新版本的Alertmanager,将其上传解压到服务器上。tar -zxvf alertmanager-0.19.0.linux-amd64.tar.gz

  • 配置Alertmanager

vi alertmanager.yml
global:
resolve_timeout: 5m
smtp_smarthost: 'mail.163.com:25' #邮箱发送端口
smtp_from: 'xxx@163.com'
smtp_auth_username: 'xxx@163.com' #邮箱账号
smtp_auth_password: 'xxxxxx' #邮箱密码
smtp_require_tls: false
route:
group_by: ['alertname']
group_wait: 10s # 最初即第一次等待多久时间发送一组警报的通知
group_interval: 10s # 在发送新警报前的等待时间
repeat_interval: 1h # 发送重复警报的周期 对于email配置中,此项不可以设置过低,否则将会由于邮件发送太多频繁,被smtp服务器拒绝
receiver: 'email'
receivers:
- name: 'email'
email_configs:
- to: 'xxx@xxx.com'

修改完成后可以使用 ./amtool check-config alertmanager.yml校验文件是否正确。

校验正确后启动alertmanager。nohup ./alertmanager &。(第一次启动可以不使用nohup静默启动,方便后面查看日志)

我们只定义了一个路由,那就意味着所有由Prometheus产生的告警在发送到Alertmanager之后都会通过名为 email的receiver接收。实际上,对于不同级别的告警,会有不同的处理方式,因此在route中,我们还可以定义更多的子Route。具体配置规则大家可以去百度进一步了解。

  • 配置Prometheus
    在Prometheus安装目录下建立rules文件夹,放置所有的告警规则文件。
alerting:
alertmanagers:
- static_configs:
- targets: ['192.168.249.131:9093']

rule_files:
- rules/*.yml

在rules文件夹下建立告警规则文件 service_down.yml,当服务器下线时发送邮件。

groups:
- name: ServiceStatus
rules:
- alert: ServiceStatusAlert
expr: up == 0
for: 2m
labels:
team: node
annotations:
summary: "Instance {{ $labels.instance }} has bean down"
description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 2 minutes."
value: "{{ $value }}"

「配置详解」

alert:告警规则的名称。
expr:基于PromQL表达式告警触发条件,用于计算是否有时间序列满足该条件。
for:评估等待时间,可选参数。用于表示只有当触发条件持续一段时间后才发送告警。在等待期间新产生告警的状态为PENDING,等待期后为FIRING。
labels:自定义标签,允许用户指定要附加到告警上的一组附加标签。
annotations:用于指定一组附加信息,比如用于描述告警详细信息的文字等,annotations的内容在告警产生时会一同作为参数发送到Alertmanager。

配置完成后重启Prometheus,访问Prometheus查看告警配置。

  • 测试
    关闭node_exporter,过2分钟就可以收到告警邮件啦,截图如下: Alertmanager的告警内容支持使用模板配置,可以使用好看的模板进行渲染,感兴趣的可以试试!
The More

node exporter的一些计算语句

  • CPU使用率(单位为percent)
    (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
  • 内存已使用(单位为bytes)
    node_memory_MemTotal_bytes - node_memory_MemFree_bytes - node_memory_Cached_bytes - node_memory_Buffers_bytes - node_memory_Slab_bytes
  • 内存使用量(单位为bytes/sec)
    node_memory_MemTotal_bytes - node_memory_MemFree_bytes - node_memory_Cached_bytes - node_memory_Buffers_bytes - node_memory_Slab_bytes
  • 内存使用率(单位为percent)
    ((node_memory_MemTotal_bytes - node_memory_MemFree_bytes - node_memory_Cached_bytes - node_memory_Buffers_bytes - node_memory_Slab_bytes)/node_memory_MemTotal_bytes) * 100
  • server1的内存使用率(单位为percent)
    ((node_memory_MemTotal_bytes{instance="server1"} - node_memory_MemAvailable_bytes{instance="server1"})/node_memory_MemTotal_bytes{instance="server1"}) * 100
  • server2的磁盘使用率(单位为percent)
    ((node_filesystem_size_bytes{fstype=~"xfs|ext4",instance="server2"} - node_filesystem_free_bytes{fstype=~"xfs|ext4",instance="server2"}) / node_filesystem_size_bytes{fstype=~"xfs|ext4",instance="server2"}) * 100
  • uptime时间(单位为seconds)
    time() - node_boot_time
  • server1的uptime时间(单位为seconds)
    time() - node_boot_time_seconds{instance="server1"}
  • 网络流出量(单位为bytes/sec)
    irate(node_network_transmit_bytes_total{device!~"lo|bond[0-9]|cbr[0-9]|veth.*"}[5m]) > 0
  • server1的网络流出量(单位为bytes/sec)
    irate(node_network_transmit_bytes_total{instance="server1", device!~"lo|bond[0-9]|cbr[0-9]|veth.*"}[5m]) > 0
  • 网络流入量(单位为bytes/sec)
    irate(node_network_receive_bytes_total{device!~"lo|bond[0-9]|cbr[0-9]|veth.*"}[5m]) > 0
  • server1的网络流入量(单位为bytes/sec)
    irate(node_network_receive_bytes_total{instance="server1", device!~"lo|bond[0-9]|cbr[0-9]|veth.*"}[5m]) > 0
  • 磁盘读取速度(单位为bytes/sec)
    irate(node_disk_read_bytes_total{device=~"sd.*"}[5m])

"如何实现基于Prometheus和Grafana的监控平台之运维告警"的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注网站,小编将为大家输出更多高质量的实用文章!

单位 配置 时间 文件 邮件 使用率 内存 内容 网络 规则 监控 参数 方式 更多 服务器 条件 警报 邮箱 服务 附加 数据库的安全要保护哪些东西 数据库安全各自的含义是什么 生产安全数据库录入 数据库的安全性及管理 数据库安全策略包含哪些 海淀数据库安全审计系统 建立农村房屋安全信息数据库 易用的数据库客户端支持安全管理 连接数据库失败ssl安全错误 数据库的锁怎样保障安全 手冲咖啡和咖啡机区别 互联网加科技 蓝思科技飞鸽互联网 广州互联网科技公司 善班互联网科技有限公司 融贸通互联网科技 互联网金融 科技创新 上海万想互联网科技 左右互联网络科技 深圳互联网科技怎么样 深圳市运趣互联网科技有限公司 互联网金融科技公司干啥的 港股科技和互联网 燊美集互联网科技有限公司 企晟互联网信息科技有限公司 西安有哪些互联网高科技企业 互联网科技平台产品运营 湖北辰鑫科技互联网 科技信息时代互联网发展 恒生互联网科技趋势 紫鲸互联网科技 未来的互联网科技 广州互联网络科技有限公司 成都仁贤领冠互联网科技有限公司 世界互联网科技公司市值排名 宜昌元轩互联网科技有限公司 消费医药和互联网科技 广东工业互联网大赛深圳学泰科技 西安有哪些互联网高科技企业 互联网科技创业计划的风险分析
0