《Linux运维总结:prometheus+altermanager+webhook-dingtalk配置文件详解》

本文主要是介绍《Linux运维总结:prometheus+altermanager+webhook-dingtalk配置文件详解》,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

总结:整理不易,如果对你有帮助,可否点赞关注一下?

更多详细内容请参考:《Linux运维篇:Linux系统运维指南》


一、prometheus配置文件

Prometheus的配置文件是prometheus.yml,在启动时指定相关的文件,可对配置内容进行加载。

global:全局配置
alerting:告警配置
rule_files:规则配置
scrape_configs:目标拉取配置

默认prometheus配置文件内容如下:
在这里插入图片描述


1.1、global全局配置

global:scrape_interval: 15s # 全局默认的数据拉取间隔evaluation_interval: 15s # 全局默认的规则(主要是报警规则)拉取间隔

1.2、alerting告警配置

说明:用于设置Prometheus与Alertmanager的通信。在Prometheus的整体架构中,Prometheus会根据配置的告警规则触发警报并发送到独立的Alertmanager组件,Alertmanager将对告警进行管理并发送给相关的用户。

1、alertmanager单实例

alerting:alertmanagers:- static_configs:- targets:- alertmanager:9093

2、alertmanager集群

alerting:alertmanagers:- static_configs:- targets:- alertmanager01:9093- alertmanager02:9093- alertmanager03:9093		       

说明:主机名可以使用ip替换。


1.3、rule_files规则配置

说明:主要是用来设置rule_files告警规则,基于设定什么指标进行报警(类似触发器trigger)。这里设定好规则以后,prometheus会根据全局global设定的evaluation_interval参数进行扫描加载,规则改动后会自动加载。其报警媒介和route路由由alertmanager插件实现。

方式一:

rule_files:- "first_rules.yml"- "second_rules.yml"

方式二:

rule_files:- "/etc/prometheus/rules/*.yml"

告警规则文件,示例如下:
在这里插入图片描述
说明:可以在labels字段下设置标签。


1.4、scrape_configs目标拉取配置

说明:scrape_config: 定义数据抓取目标的配置。
在这里插入图片描述


1.4.1、基于static_configs静态配置

示例如下:

scrape_configs:- job_name: 'example_app'scrape_interval: 5sstatic_configs:- targets: ['app1.example.com:8080', 'app2.example.com:8080']labels:env: 'onLine'app: 'app1'

1.4.2、基于file_sd_config动态配置

用json格式文件发现方式发现服务,如下所示:

  - job_name: "blackbox-exporter-http"metrics_path: /probeparams:module: [http_2xx]file_sd_configs:- files:- /etc/prometheus/conf.d/blackbox-exporter-http/*.jsonrelabel_configs:- source_labels: [__address__]target_label: __param_target- source_labels: [__param_target]target_label: instance- target_label: __address__replacement: 192.168.1.111:9115

node-exporter.json文件中定义目标和标签,如下所示:

vim  node-exporter.json
[{"targets": ["192.168.1.1:9100", "192.168.1.2:9100"],"labels": {"env": "prod","region": "us-east"}},{"targets": ["192.168.1.3:9100"],"labels": {"env": "dev","region": "us-west"}}
]

用yaml格式文件发现方式发现服务,如下所示:

  - job_name: "blackbox-exporter-http"metrics_path: /probeparams:module: [http_2xx]file_sd_configs:- files:- /etc/prometheus/conf.d/blackbox-exporter-http/*.ymlrelabel_configs:- source_labels: [__address__]target_label: __param_target- source_labels: [__param_target]target_label: instance- target_label: __address__replacement: 192.168.1.111:9115

node-exporter.yaml文件中定义目标和标签,如下所示:

vim  node-exporter.yml
- targets: ['192.168.1.101:9100', '192.168.1.102:9100']labels:environment: productionteam: monitoring

1.4.3、基于consul_sd_config动态配置


1.4.4、基于其它方式动态配置


1.4.5、relabel_configs配与及使用


1.4.6、prometheus热加载

# 1、在启动时给定--web.enable-lifecycle
# 2、curl -X POST http://192.168.1.201:9090/-/reload

二、altermanager配置文件

Alertmanager 的配置主要包括三部分:

# global:全局配置,包括 resolved 超时时间、SMTP 等。
# route:告警路由规则,根据匹配条件将告警发送到不同接收器。
# receivers:接收器列表,定义各种通知渠道如 email、webhook 等。

默认配置文件如下所示:

global:# The smarthost and SMTP sender used for mail notifications.smtp_smarthost: 'localhost:25'smtp_from: 'alertmanager@example.org'# The root route on which each incoming alert enters.
route:# The root route must not have any matchers as it is the entry point for# all alerts. It needs to have a receiver configured so alerts that do not# match any of the sub-routes are sent to someone.receiver: 'team-X-mails'# The labels by which incoming alerts are grouped together. For example,# multiple alerts coming in for cluster=A and alertname=LatencyHigh would# be batched into a single group.## To aggregate by all possible labels use '...' as the sole label name.# This effectively disables aggregation entirely, passing through all# alerts as-is. This is unlikely to be what you want, unless you have# a very low alert volume or your upstream notification system performs# its own grouping. Example: group_by: [...]group_by: ['alertname', 'cluster']# When a new group of alerts is created by an incoming alert, wait at# least 'group_wait' to send the initial notification.# This way ensures that you get multiple alerts for the same group that start# firing shortly after another are batched together on the first# notification.group_wait: 30s# When the first notification was sent, wait 'group_interval' to send a batch# of new alerts that started firing for that group.group_interval: 5m# If an alert has successfully been sent, wait 'repeat_interval' to# resend them.repeat_interval: 3h# All the above attributes are inherited by all child routes and can# overwritten on each.# The child route trees.routes:# This route performs a regular expression match on alert labels to# catch alerts that are related to a list of services.- matchers:- service=~"^(foo1|foo2|baz)$"receiver: team-X-mails# The service has a sub-route for critical alerts, any alerts# that do not match, i.e. severity != critical, fall-back to the# parent node and are sent to 'team-X-mails'routes:- matchers:- severity="critical"receiver: team-X-pager- matchers:- service="files"receiver: team-Y-mailsroutes:- matchers:- severity="critical"receiver: team-Y-pager# This route handles all alerts coming from a database service. If there's# no team to handle it, it defaults to the DB team.- matchers:- service="database"receiver: team-DB-pager# Also group alerts by affected database.group_by: [alertname, cluster, database]routes:- matchers:- owner="team-X"receiver: team-X-pager- matchers:- owner="team-Y"receiver: team-Y-pager# Inhibition rules allow to mute a set of alerts given that another alert is
# firing.
# We use this to mute any warning-level notifications if the same alert is
# already critical.
inhibit_rules:
- source_matchers:- severity="critical"target_matchers:- severity="warning"# Apply inhibition if the alertname is the same.# CAUTION: #   If all label names listed in `equal` are missing #   from both the source and target alerts,#   the inhibition rule will apply!equal: ['alertname', 'instance']receivers:
- name: 'team-X-mails'email_configs:- to: 'team-X+alerts@example.org, team-Y+alerts@example.org'- name: 'team-X-pager'email_configs:- to: 'team-X+alerts-critical@example.org'pagerduty_configs:- routing_key: <team-X-key>- name: 'team-Y-mails'email_configs:- to: 'team-Y+alerts@example.org'- name: 'team-Y-pager'pagerduty_configs:- routing_key: <team-Y-key>- name: 'team-DB-pager'pagerduty_configs:- routing_key: <team-DB-key>

route字段解释如下:

receiver:每个 route 至少指向一个接收器,否则告警无处发送。
group_by:合理的分组方式,避免重复通知。常用 alertname + 其他标签。
group_interval:不短于 5 分钟,避免通知过于频繁。
repeat_interval:不短于 30 分钟,重复通知的周期。
match_re:使用正则表达式匹配告警可以实现灵活路由。

2.1、抑制规则

在alertname、dev、instance 三个标签的值相同情况下,critaical 的报警会抑制 warning 级别的报警信息。

inhibit_rules:- source_match:severity: 'critical'target_match:severity: 'warning'equal: ['alertname', 'dev', 'instance']

2.2、临时静默

除了基于抑制机制可以控制告警通知的行为以外,用户或者管理员还可以直接通过Alertmanager的UI临时屏蔽特定的告警通知。

1、进入Alertmanager U–>点击Alerts—>Silence
在这里插入图片描述
2、定义静默规则的开始时间以及持续时间和结束时间,填写当前静默规则的创建者以及创建原因后,点击Create按钮即可。
在这里插入图片描述
3、取消静默规则:对于已经生效的规则,用户可以通过手动点击Expire按钮使当前规则过期。
在这里插入图片描述


2.3、路由匹配

告警的匹配有两种方式可以选择。

1、一种方式基于字符串验证,通过设置match规则判断当前告警中是否存在标签labelname并且其值等于labelvalue。
2、第二种方式则基于正则表达式,通过设置match_re验证当前告警标签的值是否满足正则表达式的内容。

示例一:根据服务名称匹配

route:group_by: ['alertname']     #定义分组,根据label标签进行分组group_wait: 10s             #分组等待时间,也就是说在10秒内同一个组中有没有一起报警的,如果有则同时发出报警邮件,如果没有则分开发group_interval: 10s         #告警时间间隔repeat_interval: 1h         #重复告警间隔,也就是触发的一个告警在1h内没有处理则再次发一封邮件。continue: false             #若路由上的continue字段的值为false,则遇到第一个匹配的路由分支后即终止。否则,将继续匹配后续的子节点;receiver: 'webhook1'        #默认邮箱routes:                     #启用一个子路由- receiver: 'webhook1'      #接收者为webhook1group_wait: 10s           #分组等待时间match_re:                 #匹配一个正则service: mysql|db       #service标签包含mysql和db的统一发送给dba的邮箱continue: false           #若路由上的continue字段的值为false,则遇到第一个匹配的路由分支后即终止。否则,将继续匹配后续的子节点;- receiver: 'webhook2'      #接收者为webhook2group_wait: 10s           #分组时间match:         serverity: error        #将serverity标签值包含error的发送给yunwei的邮箱continue: false           #若路由上的continue字段的值为false,则遇到第一个匹配的路由分支后即终止。否则,将继续匹配后续的子节点;receivers:
- name: webhook1webhook_configs:- url: http://xx.xx.xx.xx:8060/dingtalk/webhook/sendsend_resolved: true #警报被解决之后是否通知
- name: webhook2webhook_configs:- url: http://xx.xx.xx.xx:8060/dingtalk/webhook1/sendsend_resolved: true #警报被解决之后是否通知

示例二:根据告警规则名称匹配

route:group_by: ['instance']          #根据 instance 标签分组continue: true                  #为true则还需要去匹配子路由。receiver: receiver-01routes:- receiver: 'receiver-01'match:alertname: 'InstanceDown'   #告警的名字是InstanceDown则发送给receiver-03- receiver: 'webchat'match_re:alertname: 'Cpu.*'          #告警的名字以Cpu开头的则发送给webchat- receiver: 'dingtalk'match:alertname: 'InstanceDown'   #告警的名字是InstanceDown则发送给dingtalk
receivers:                        
- name: 'receiver-01'                     email_configs:                - to: '1111@qq.com'               
- name: 'webchat'webhook_configs:- url: 'http://xx.xx.xx.xx:5000'send_resolved: true
- name: 'dingtalk'webhook_configs:- url: 'http://xx.xx.xx.xx:8060/dingtalk/webhook1/send'send_resolved: true

示例三:同一个告警信息多通道告警发送

route:group_by: ['alertname']group_wait: 30sgroup_interval: 60srepeat_interval: 24hreceiver: webchatroutes:- receiver: wechat   group_wait: 10scontinue: true       #当消息发送给微信后,继续匹配,就能把消息在发送到钉钉 - receiver: dingtalkgroup_wait: 10sreceivers:
- name: 'wechat'webhook_configs:- url: 'http://192.168.11.60:8999/webhook?key=自己的key'
- name: 'dingtalk'webhook_configs:- url: 'http://192.168.11.60:8060/dingtalk/webhook1/send'

2.4、告警分组

Alertmanager可以对告警通知进行分组,将多条告警合合并为一个通知。这里我们可以使用group_by来定义分组规则。基于告警中包含的标签,如果满足group_by中定义标签名称,那么这些告警将会合并为一个通知发送给接收器。

route:receiver: 'default-receiver'group_wait: 30sgroup_interval: 5mrepeat_interval: 4hgroup_by: [cluster, alertname]routes:- receiver: 'database-pager'group_wait: 10smatch_re:service: mysql|cassandra- receiver: 'frontend-pager'group_by: [product, environment]match:team: frontend

三、webhook-dingtalk配置文件

说明:当 receives 为钉钉时 (webhook_configs),它的告警模板不是在 alertmanager 的配置文件中指定的,而是在钉钉插件 prometheus-webhook-dingtalk 中指定的。

钉钉告警模板如下:

[root@host-monitor webhook-dingtalk]# cat template.tmpl 
{{ define "__subject" }}
[{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}]{{ end }}            {{ define "__text_alert_list" }}{{ range . }}
---
{{ if .Labels.owner }}@{{ .Labels.owner }}{{ end }}
**告警主机:** {{ .Labels.instance }}**告警级别:** {{ .Labels.severity | upper }}**告警时间:** {{ dateInZone "2006.01.02 15:04:05" (.StartsAt) "Asia/Shanghai" }}**事件信息:** 
{{ range .Annotations.SortedPairs }} - {{ .Name }}: {{ .Value | markdown | html }}
{{ end }}**事件标签:** 
{{ range .Labels.SortedPairs }}{{ if and (ne (.Name) "severity") (ne (.Name) "summary") }} - {{ .Name }}: {{ .Value | markdown | html }}
{{ end }}{{ end }}
{{ end }}
{{ end }}{{ define "__text_resolved_list" }}{{ range . }}
---
{{ if .Labels.owner }}@{{ .Labels.owner }}{{ end }}
**告警主机:** {{ .Labels.instance }}**告警级别:** {{ .Labels.severity | upper }}**告警时间:** {{ dateInZone "2006.01.02 15:04:05" (.StartsAt) "Asia/Shanghai" }}**恢复时间:** {{ dateInZone "2006.01.02 15:04:05" (.EndsAt) "Asia/Shanghai" }}**事件信息:** 
{{ range .Annotations.SortedPairs }} - {{ .Name }}: {{ .Value | markdown | html }}
{{ end }}**事件标签:** 
{{ range .Labels.SortedPairs }}{{ if and (ne (.Name) "severity") (ne (.Name) "summary") }} - {{ .Name }}: {{ .Value | markdown | html }}
{{ end }}{{ end }}
{{ end }}
{{ end }}{{ define "default.title" }}
{{ template "__subject" . }}
{{ end }}{{ define "default.content" }}{{ if gt (len .Alerts.Firing) 0 }}
**========侦测到{{ .Alerts.Firing | len  }}个故障========**
{{ template "__text_alert_list" .Alerts.Firing }}
{{ end }}{{ if gt (len .Alerts.Resolved) 0 }}
**========恢复{{ .Alerts.Resolved | len  }}个故障========**
{{ template "__text_resolved_list" .Alerts.Resolved }}
{{ end }}
{{ end }}
{{ define "ding.link.title" }}{{ template "default.title" . }}{{ end }}{{ define "ding.link.content" }}{{ template "default.content" . }}{{ end }}
{{ template "default.title" . }}
{{ template "default.content" . }}

总结:整理不易,如果对你有帮助,可否点赞关注一下?

更多详细内容请参考:《Linux运维篇:Linux系统运维指南》

这篇关于《Linux运维总结:prometheus+altermanager+webhook-dingtalk配置文件详解》的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1074974

相关文章

Conda与Python venv虚拟环境的区别与使用方法详解

《Conda与Pythonvenv虚拟环境的区别与使用方法详解》随着Python社区的成长,虚拟环境的概念和技术也在不断发展,:本文主要介绍Conda与Pythonvenv虚拟环境的区别与使用... 目录前言一、Conda 与 python venv 的核心区别1. Conda 的特点2. Python v

Spring Boot中WebSocket常用使用方法详解

《SpringBoot中WebSocket常用使用方法详解》本文从WebSocket的基础概念出发,详细介绍了SpringBoot集成WebSocket的步骤,并重点讲解了常用的使用方法,包括简单消... 目录一、WebSocket基础概念1.1 什么是WebSocket1.2 WebSocket与HTTP

java中反射Reflection的4个作用详解

《java中反射Reflection的4个作用详解》反射Reflection是Java等编程语言中的一个重要特性,它允许程序在运行时进行自我检查和对内部成员(如字段、方法、类等)的操作,本文将详细介绍... 目录作用1、在运行时判断任意一个对象所属的类作用2、在运行时构造任意一个类的对象作用3、在运行时判断

linux hostname设置全过程

《linuxhostname设置全过程》:本文主要介绍linuxhostname设置全过程,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录查询hostname设置步骤其它相关点hostid/etc/hostsEDChina编程A工具license破解注意事项总结以RHE

MySQL 中的 CAST 函数详解及常见用法

《MySQL中的CAST函数详解及常见用法》CAST函数是MySQL中用于数据类型转换的重要函数,它允许你将一个值从一种数据类型转换为另一种数据类型,本文给大家介绍MySQL中的CAST... 目录mysql 中的 CAST 函数详解一、基本语法二、支持的数据类型三、常见用法示例1. 字符串转数字2. 数字

SpringBoot中SM2公钥加密、私钥解密的实现示例详解

《SpringBoot中SM2公钥加密、私钥解密的实现示例详解》本文介绍了如何在SpringBoot项目中实现SM2公钥加密和私钥解密的功能,通过使用Hutool库和BouncyCastle依赖,简化... 目录一、前言1、加密信息(示例)2、加密结果(示例)二、实现代码1、yml文件配置2、创建SM2工具

MyBatis-Plus 中 nested() 与 and() 方法详解(最佳实践场景)

《MyBatis-Plus中nested()与and()方法详解(最佳实践场景)》在MyBatis-Plus的条件构造器中,nested()和and()都是用于构建复杂查询条件的关键方法,但... 目录MyBATis-Plus 中nested()与and()方法详解一、核心区别对比二、方法详解1.and()

Spring IoC 容器的使用详解(最新整理)

《SpringIoC容器的使用详解(最新整理)》文章介绍了Spring框架中的应用分层思想与IoC容器原理,通过分层解耦业务逻辑、数据访问等模块,IoC容器利用@Component注解管理Bean... 目录1. 应用分层2. IoC 的介绍3. IoC 容器的使用3.1. bean 的存储3.2. 方法注

MySQL 删除数据详解(最新整理)

《MySQL删除数据详解(最新整理)》:本文主要介绍MySQL删除数据的相关知识,本文通过实例代码给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录一、前言二、mysql 中的三种删除方式1.DELETE语句✅ 基本语法: 示例:2.TRUNCATE语句✅ 基本语

Python内置函数之classmethod函数使用详解

《Python内置函数之classmethod函数使用详解》:本文主要介绍Python内置函数之classmethod函数使用方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地... 目录1. 类方法定义与基本语法2. 类方法 vs 实例方法 vs 静态方法3. 核心特性与用法(1编程客