04_PQL查询语句&Altermanager告警机制
04_PQL查询语句&&Altermanager告警机制
这个是prometheus学习过程中最重要的部分
1.Prometheus数据模型以及PromQL
- counter（计数器）
这是一种累计的metric,典型的应用如：请求个数，结束任务数，出现错误。可以理解为counter理解为计数器，从0开始在理想在状态下永远是增加的。常见的监控指标，如http_requests_total,node_cpu_seconds_total都是count类型的监控指标。
例如，查询 node_network_receive_bytes_total{job=“prometheus”} 返回的结果
node_network_receive_bytes_total{app="prometheus", device="docker0", instance="localhost:9100", job="prometheus"} 1092803
node_network_receive_bytes_total{app="prometheus", device="ens160", instance="localhost:9100", job="prometheus"} 21136661
node_network_receive_bytes_total{app="prometheus", device="lo", instance="localhost:9100", job="prometheus"} 2117336
node_network_receive_bytes_total{app="prometheus", device="veth01cc1e1", instance="localhost:9100", job="prometheus"} 1092231
node_network_receive_bytes_total{app="prometheus", device="veth1887d37", instance="localhost:9100", job="prometheus"} 2742
用一个rate函数查看1H变化率的效果
一般我们需要其他的方式进行计算方式
这个一般是看变化率
rate(node_network_receive_bytes_total{job="prometheus"}[1h])
- 仪表盘类型Gauge
与 Counter 不同， Gauge （可增、可减的仪表盘）类型的指标样本数据可增可减， 典型的应⽤如：温度，运⾏的任务的个数。可以任意增、减。对这种类型的数据，我们通常关注的是当前值。比如房间⾥的⽬前的⼈数、队列⽬前积压的消息数、今年公司的收⼊和净利润。
如常见的主机内存空闲大小
2.PromQL表达式语言数据类型
有4种类型
-
瞬时变量：每一个时间序列包含单个样本，共享其时间戳表达式的返回值中只会包含该时间序列中的最新的⼀个样本值。⽽相应的这样的表达式称之为瞬时向量表达式。
-
区间变量：⼀组时间序列，每个时间序列包含⼀段时间范围内的样本数据。
这些是通过将时间选择器附加到⽅括号中的瞬时向量（例如[5m]5 分钟）⽽⽣成的。
-
标量
-
字符串
2.1瞬时查询和瞬时查询
瞬时查询⽤于类似表格的视图，瞬时查询查看的是，在同⼀个时间点，所有或者指定标签 ，在这个时间点的瞬时值，例如：选择指标名称为 node_cpu_seconds_total 的所有时间序列：
node_cpu_seconds_total
可以通过花括号{}里附加一组标签进一步过滤时间序列
如 标签名node_cpu_seconds_total job标签为prometheus，mode 为idle时间序列
node_cpu_seconds_total{job="prometheus",mode="idle"}
-
= : 选择与提供的字符串完全相同的标签。
-
!= : 选择与提供的字符串不相同的标签。
-
=~ : 选择正则表达式与提供的字符串（或⼦字符串）相匹配的标签。
-
!~ : 选择正则表达式与提供的字符串（或⼦字符串）不匹配的标签。
2.2区间查询，
区间查询主要⽤于图形，区间向量与瞬时向量的⼯作⽅式类似，唯⼀的差异在于在区间向量表达式中=我们需要定义时间选择的范围，时间范围通过时间范围选择器 [] 进⾏定义，以指定应为区间向量样本值中提取多⻓的时间范围。时间范围通过数字来表⽰，单位可以使⽤以下其中之⼀的时间单位：
s - 秒
m - 分钟
h - ⼩时
d - 天
w - 周
y - 年
- 例如选择在过去1分钟的时间序列
node_cpu_seconds_total{job="prometheus",mode='idle'}[1m]
2.3变化率
通常来说直接绘制一个原始的Counter类型的指标数据用处不大，因为他们会一直增加，我们一般不会一直关注这个类型，因为Counter一旦重置总计数就没有多大意义，因此PromQL提供了不同的函数来计算变化率
- rate函数
⽤于计算变化率的最常⻅函数是 rate() ， rate() 函数⽤于计算在指定时间范围内计数器平均每秒的增加量。因为是计算⼀个时间范围内的平均值，所以我们需要在序列选择器之后添加⼀个时间范选择器。
rate(node_memory_MemFree_bytes[10m])
- 这个rate函数通常是每隔5分钟的间隔进行抓取数据，来看到数据的变化
- irate函数
- PromQL 提供了另外⼀个灵敏度更⾼的函数 irate(v range-vector) 。irate 同样⽤于计算区间向量的增⻓率，但是其反应出的是瞬时增⻓率
irate(node_memory_MemFree_bytes[5m])
2.4聚合
聚合器分类
- max()获取分组中最大的
- avg()计算分组中所有的平均值
- stddev（）聚合数据的标准差
- count()计算出分组中的序列总和
小结一下
这里就简单的说了一下关于PQL的常用的几种方式，后续的话需要看官方文档
实例状态检测
- 每当prometheus 抓取一个标签，其中都有up和被实时抓取的job和instance。如果抓取成功就为1，如果失败就为0
2.Altermanager的告警机制
2.1Alertmanager功能介绍
Alertmanager 主要⽤于接收 Prometheus 发送的告警信息，它⽀持丰富的告警通知渠道，⽽且很容易做到告警信息进⾏去重，降噪，分组等，是⼀款前卫的告警通知系统。
Alertmanager是⼀个独⽴的告警模块，接收Prometheus server发来的警报，之后通过分组、删除重复等处理，并将它们通过路由发送给正确的接收器；告警⽅式可以按照不同的规则发送给不同的模块负责⼈，Alertmanager⽀持Email, Slack，等告警⽅式, 也可以通过webhook接⼊钉钉等国内IM⼯具。如下图所⽰：
3.2AlerManager的分类，静默，默认功能
AlertManager提供了分组，静默，告警抑制行为进行优化
警告的三种机制
- pending:告警被激活，但是低于配置的持续时间。
- firing:告警被激活且超出设置的持续时间
- inactive:既不是pending,也不是firing的时候变为inactive
prometheus触发一条警告的过程
prometheus—>触发阈值—>超出持续时间—>alertmanager—>分组|抑制|静默—>媒体类型—>邮件|钉钉|微信等。
- 官方下载
[root@prometheus-333 local]# cd alertmanager/
[root@prometheus-333 alertmanager]# ll
total 67924
-rwxr-xr-x. 1 1001 1002 38948743 Mar 7 2025 alertmanager
-rw-r--r--. 1 1001 1002 356 Mar 7 2025 alertmanager.yml
-rwxr-xr-x. 1 1001 1002 30582387 Mar 7 2025 amtool
-rw-r--r--. 1 1001 1002 11357 Mar 7 2025 LICENSE
-rw-r--r--. 1 1001 1002 311 Mar 7 2025 NOTICE
[root@prometheus-333 alertmanager]# ./alertmanager --version
alertmanager, version 0.28.1 (branch: HEAD, revision: b2099eaa2c9ebc25edb26517cb9c732738e93910)
build user: root@fa3ca569dfe4
build date: 20250307-15:05:18
go version: go1.23.7
platform: linux/amd64
tags: netgo
- 接着陪alertmanager.yaml配置文件
global:
smtp_smarthost: 'smtp.qq.com:465'
smtp_from: '3636940637@qq.com'
smtp_auth_username: '3636940637@qq.com'
smtp_auth_password: 'tqpoebdehkoyciib'
smtp_require_tls: false
route:
group_by: [alertname]
group_wait: 10s
group_interval: 10s
repeat_interval: 2m
receiver: default-receiver
receivers:
- name: 'default-receiver'
email_configs:
- send_resolved: true
to: '3636940637@qq.com'
smtp_smarthost：这⾥为163邮箱SMTP服务地址，官⽅地址为smtp.163.com，端⼝为25，同时要设置开启POP3/SMTP服务。
smtp_auth_password：这⾥为第三⽅登录邮箱的授权码，⾮邮件账⼾登录密码，否则会报错，获取⽅式在邮箱服务端设置开启POP3/SMTP服务时会提⽰。
smtp_require_tls: false ：是否使⽤ tls，根据环境不同，来选择开启和关闭。如果提⽰报错email.loginAuth failed: 530 Must issue a STARTTLS command first，那么就需要设置为 true。着重说明⼀下，如果开启了tls，提⽰报错starttls failed: x509: certificate signed by unknownauthority，需要在email_configs下配置 insecure_skip_verify: true来跳过tls验证。
route：⽤来设置报警的分发策略。Prometheus的告警先是到达alertmanager的根路由(route)，alertmanager的根路由不能包含任何匹配项，因为根路由是所有告警的⼊⼝点。另外，根路由需要配置⼀个接收器(receiver)，⽤来处理那些没有匹配到任何⼦路由的告警（如果没有配置⼦路由，则全部由根路由发送告警），即缺省接收器。告警进⼊到根route后开始遍历⼦route节点，如果匹配到，则将告警发送到该⼦route定义的receiver中，然后就停⽌匹配了。因为在route中continue默认为false，如果continue为true，则告警会继续进⾏后续⼦route匹配。如果当前告警仍匹配不到任何的⼦route，则该告警将从其上⼀级(匹配)route或者根route发出（按最后匹配到的规则发出邮件）。要查看你的告警路由树，https://www.prometheus.io/webtools/alerting/routing-tree-editor/, 将alertmanager.yml配置⽂件复制到对话框，然后点击"Draw Routing Tree"即可。
group_by: [‘alertname’]：⽤于分组聚合，对告警通知按标签(label)进⾏分组，将具有相同标签或相同告警名称(alertname)的告警通知聚合在⼀个组，然后作为⼀个通知发送。如果想完全禁⽤聚合，可以设置为group_by: […]
group_wait: 10s：当⼀个新的告警组被创建时，需要等待’group_wait’后才发送初始通知。这样可以确保在发送等待前能聚合更多具有相同标签的告警，最后合并为⼀个通知发送。
group_interval: 10s: 当第⼀次告警通知发出后，在新的评估周期内⼜收到了该分组最新的告警，则需等待’group_interval’时间后，开始发送该分组触发的新告警，可以简单理解为，group就相当于⼀个通道(channel)。
repeat_interval: 2m：
告警通知成功发送后，若问题⼀直未恢复，需再次重复发送的间隔。
receiver: ‘default-receiver’：配置缺省告警消息接收器，每个接收器下⾯都要进⾏定义。例如常⽤的 email、wechat、slack、webhook 等消息通知⽅式。
to: '397824870@qq.com’receivers：配置报警信息接收器的信息，这⾥的name值和上⾯receiver参数指定的值要对应起来。
常⽤的接收器种类有email_configs、wechat_configs、webhook_configs，例如上⾯指定了
default-receiver这个接收器，这⾥就要定义这个接收器。将这个接收器配置为email_configs（邮件
接收器），注意写法。
send_resolved：表⽰在故障恢复后也需要发通知确认。
# 检查配置文件的格式是否正确
[root@prometheus-333 alertmanager]# ./amtool check-config alertmanager.yml
Checking 'alertmanager.yml' SUCCESS
Found:
- global config
- route
- 0 inhibit rules
- 1 receivers
- 0 templates
- 配置alertmanager的service服务
[root@prometheus-server data]# cat /usr/lib/systemd/system/alertmanager.service
[Unit]
Description=Prometheus: the alerting system
Documentation=http://prometheus.io/docs/
After=prometheus.service
[Service]
ExecStart=/usr/local/alertmanager/alertmanager --config.file=/usr/local/alertmanager/alertmanager.yml
Restart=always
RestartSec=15s
[Install]
WantedBy=multi-user.target
prometheus告警规则配置
prometheus一条报警配置为
-
告警名称：⽤⼾需要为告警规则命名，当然对于命名⽽⾔，需要能够直接表达出该告警的主要内容
-
告警规则：告警规则实际上主要由 PromQL 进⾏定义，其实际意义是当表达式（PromQL）查询结果持续多⻓时间（During）后触发告警，是⼀个触发条件。
（1）、告警规则
⼀条报警规则主要由以下⼏部分组成：
-
alert ：告警规则的名称
-
expr ：是⽤于进⾏报警规则 PromQL 查询语句
-
for ：评估等待时间（Pending Duration），⽤于表⽰只有当触发条件持续⼀段时间后才发送告警，在等待期间新产⽣的告警状态为 pending
-
labels ：⾃定义标签，允许⽤⼾指定额外的标签列表，把它们附加在告警上
-
annotations ：指定了另⼀组标签，它们不被当做告警实例的⾝份标识，它们经常⽤于存储⼀些额外的信息，⽤于报警信息的展⽰之类的。
groups:
- name: example
rules:
- alert: InstanceDown
expr: up == 0
for: 1m
labels:
severity: critical
annotations:
summary: Instance has been down for more than 5 minutes
可以将上述警告规则写到一个配置文件中，告警规则⽂件编写完成后，还需要加载到prometheus主配置⽂件中才能⽣效，打开
prometheus.yml⽂件，找到如下配置：
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"
- rules/*.yml
2.5配置基于微信，钉钉的警告
- 钉钉警告配置
重点说下钉钉告警，由于alertmanager默认不⽀持钉钉告警，所以需要借助prometheus-webhookdingtalk插件来实现，⼤家可从https://github.com/timonwong/prometheus-webhook-dingtalk/下载此插件，然后进⾏安装，过程如下
- 定制一个消息模版
/usr/local/alertmanager/template/wechat.tmpl
{{ define "email.htm" }}
{{ if gt (len .Alerts.Resolved) 0 }}
{{ range .Alerts.Resolved }}
<pre>
告警已解除！
========start==========
告警状态: {{ .Status }}
告警级别: {{ .Labels.severity }} 级别
告警类型: {{ .Labels.alertname }}
故障主机: {{ .Labels.instance }}
告警主题: {{ .Annotations.summary }}
告警详情: {{ .Annotations.description }}
告警时间: {{ (.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}
恢复时间: {{ .EndsAt.Local.Format "2006-01-02 15:04:05" }}
========end==========
</pre>
{{ end }}
{{ end }}
{{ if gt (len .Alerts.Firing) 0 }}
{{ range .Alerts }}
<pre>
========start==========
告警程序: {{ .Labels.job }}
告警级别: {{ .Labels.severity }} 级别
告警类型: {{ .Labels.alertname }}
故障主机: {{ .Labels.instance }}
告警主题: {{ .Annotations.summary }}
告警详情: {{ .Annotations.description }}
告警时间：{{ .StartsAt.Local.Format "2006-01-02 15:04:05" }}
========end==========
</pre>
{{ end }}
{{ end }}
{{ end }}
{{ define "wechat.default.message" }}
{{- if gt (len .Alerts.Firing) 0 -}}
{{- range $index, $alert := .Alerts -}}
======告警通知=======
告警状态：{{ .Status }}
告警级别：{{ $alert.Labels.severity }}
告警类型：{{ $alert.Labels.alertname }}
告警应⽤：{{ $alert.Annotations.summary }}
告警主机：{{ .Labels.instance }}
告警详情：{{ .Annotations.description }}
触发阀值：{{ .Annotations.value }}
告警时间：{{ .StartsAt.Local.Format "2006-01-02 15:04:05" }}
========end=========
{{- end }}
{{- end }}
{{- if gt (len .Alerts.Resolved) 0 -}}
{{- range $index, $alert := .Alerts -}}
======恢复通知=======
告警状态：{{ .Status }}
告警级别：{{ $alert.Labels.severity }}
告警类型：{{ $alert.Labels.alertname }}
告警应⽤：{{ $alert.Annotations.summary }}
告警主机：{{ .Labels.instance }}
告警详情：{{ .Annotations.description }}
触发阀值：{{ .Annotations.value }}
告警时间：{{ .StartsAt.Local.Format "2006-01-02 15:04:05" }}
恢复时间: {{ .EndsAt.Local.Format "2006-01-02 15:04:05" }}
========end=========
{{- end }}
{{- end }}
{{- end }}
将Alertmanager整合prometheus
默认情况下prometheus server和 Alertmanager独立的两个组件，
alerting:
alertmanagers:
- static_configs:
- targets:
- 127.0.0.1:9093
编写service脚本来启动alertmanager.service
[Unit]
Description=Prometheus: the alerting system
Documentation=http://prometheus.io/docs/
After=prometheus.service
[Service]
ExecStart=/usr/local/alertmanager/alertmanager --config.file=/usr/local/alertmanager/alertmanager.yml
Restart=always
RestartSec=15s
[Install]
WantedBy=multi-user.target
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
10
0- 0
已为社区贡献1条内容
所有评论(0)