前言

本文来自Prometheus官网手册1234和 Prometheus简介1234

记录规则

一、配置规则

Prometheus支持两种类型的规则,这些规则可以定期配置,然后定期评估:记录规则和警报规则。 要在Prometheus中包含规则,请创建包含必要规则语句的文件,并让Prometheus通过Prometheus配置中的rule_files字段加载文件, 规则文件使用YAML。

通过将SIGHUP发送到Prometheus进程,可以在运行时重新加载规则文件。 仅当所有规则文件格式正确时才会应用更改。

二、语法检查规则

要在不启动Prometheus服务器的情况下快速检查规则文件在语法上是否正确,请安装并运行Prometheus的promtool命令行实用工具:一般下载来整个Prometheus已经包含了promtool工具。

go get github.com/prometheus/prometheus/cmd/promtool
promtool check rules /path/to/example.rules.yml

当文件在语法上有效时,检查器将已解析规则的文本表示打印到标准输出,然后以0返回状态退出。如果存在任何语法错误或无效的输入参数,则会向标准错误输出错误消息,并以1返回状态退出。

三、录制规则

录制规则允许预先计算经常需要或计算上昂贵的表达式,并将其结果保存为一组新的时间序列。 因此,查询预先计算的结果通常比每次需要时执行原始表达式快得多。 这对于仪表板尤其有用,仪表板需要在每次刷新时重复查询相同的表达式。记录和警报规则存在于规则组中,组内的规则以固定间隔顺序运行。

规则文件的语法是:

groups:
[ - <rule_group> ]

一个简单的示例规则文件将是:

groups:
- name: example
rules:
- record: job:http_inprogress_requests:sum
expr: sum(http_inprogress_requests) by (job)

3.1 <rule_group>

# 组的名称。 在文件中必须是唯一的。
name: <string> # 评估组中的规则的频率。
[ interval: <duration> | default = global.evaluation_interval ] rules:
[ - <rule> ... ]

3.2 <rule>

记录规则的语法是:

# 要输出的时间序列的名称。 必须是有效的度量标准名称。
record: <string> # 要评估的PromQL表达式。 每个评估周期都会在当前时间进行评估,并将结果记录为一组新的时间序列,其中度量标准名称由“记录”给出。
expr: <string> # 在存储结果之前添加或覆盖的标签。
labels:
[ <labelname>: <labelvalue> ]

警报规则的语法是:

# 警报的名称。 必须是有效的度量标准名称。
alert: <string> # 要评估的PromQL表达式。 每个评估周期都会在当前时间进行评估,并且所有结果时间序列都会成为待处理/触发警报。
expr: <string> # 警报一旦被退回这段时间就会被视为开启。
# 尚未解雇的警报被认为是未决的。
[ for: <duration> | default = 0s ] # 为每个警报添加或覆盖的标签。
labels:
[ <labelname>: <tmpl_string> ] # 要添加到每个警报的注释。
annotations:
[ <labelname>: <tmpl_string> ]

比如按照规则的语法来创建一个新的metric,prometheus.rules.yml:

groups:
- name: example
rules:
- record: Cpu_Usage
expr: clamp_max(((avg by (mode) ( (clamp_max(rate(node_cpu_seconds_total{mode!="idle"}[10s]),)) or (clamp_max(irate(node_cpu_seconds_total{mode!="idle"}[10s]),)) ))* ),)

再去Prometheus上进行配置,prometheus.yml:

rule_files:
- "prometheus.rules.yml"

预警规则

警报规则基于Prometheus表达式定义警报条件,并将有关触发警报的通知发送到外部服务。 每当警报表达式在给定时间点生成一个或多个向量元素时,警报将视为这些元素的标签集的活动状态。

一、定义报警规则

警报规则在Prometheus中与记录规则相同的方式配置。带警报的示例规则文件将是:

groups:
- name: example
rules:
- alert: HighErrorRate
expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
for: 10m
labels:
severity: page
annotations:
summary: High request latency
  • for子句:使Prometheus在第一次遇到新的表达式输出向量元素和将此警告作为此元素的触发计数之间等待一段时间。 在这种情况下,Prometheus将在每次评估期间检查警报是否继续处于活动状态10分钟,然后再触发警报。 处于活动状态但尚未触发的元素处于pending状态。
  • labels子句:允许指定要附加到警报的一组附加标签。 任何现有的冲突标签都将被覆盖。 标签值可以是模板化的。
  • annotations子句:指定一组信息标签,可用于存储更长的附加信息,例如警报描述或Runbook链接。 注释值可以是模板化的。

二、模板

可以使用控制台模板化标签和注释值。 $labels变量保存警报实例的标签键/值对,$value保存警报实例的评估值。

# 要插入触发元素的标签值:
{{ $labels.<labelname> }}
# 要插入触发元素的数值表达式值:
{{ $value }}

例子:

groups:
- name: example
rules: # 对于任何无法访问> 5分钟的实例的警报。
- alert: InstanceDown
expr: up ==
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." # 对中值请求延迟> 1s的任何实例发出警报。
- alert: APIHighRequestLatency
expr: api_http_request_latencies_second{quantile="0.5"} >
for: 10m
annotations:
summary: "High request latency on {{ $labels.instance }}"
description: "{{ $labels.instance }} has a median request latency above 1s (current value: {{ $value }}s)"

三、在运行时检查警报

要手动检查哪些警报处于活动状态(待处理或触发),请导航至Prometheus实例的"Alerts"选项卡。 这将显示每个定义的警报当前处于活动状态的确切标签集。

对于待处理和触发警报,Prometheus还存储ALERTS{alertname="<alert name>",alertstate ="pending|firing",<additional alert labels>}形式的合成时间序列。 只要警报处于指示的活动(挂起或触发)状态,样本值就会设置为1,并且当不再是这种情况时,系列会标记为过时。

四、发送提醒通知

Prometheus的警报规则很好地解决了现在的问题,但并不是一个完全成熟的通知解决方案。 需要另一层来在简单警报定义之上添加摘要,通知速率限制。 其中Alertmanager承担了这一角色,可以被配置为周期性地向Alertmanager实例发送关于警报状态的信息,然后该实例负责调度正确的通知。另外Prometheus可以配置为通过其服务发现集成自动发现可用的Alertmanager实例。

模板例子

Prometheus支持在警报的注释和标签以及服务的控制台页面中进行模板化。 模板能够针对本地数据库运行查询,迭代数据,使用条件,格式化数据等.Prometheus模板语言基于Go模板系统

一、简单的警报字段模板

alert: InstanceDown
expr: up ==
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."

对于每个触发的警报,将在每次规则迭代期间执行警报字段模板,因此请保持所有查询和模板的轻量级。 如果您需要更复杂的警报模板,建议您改为链接到控制台。

二、简单的迭代

这将显示实例列表以及它们是否已启动:

{{ range query "up" }}
{{ .Labels.instance }} {{ .Value }}
{{ end }}

特别的.变量包含每个循环迭代的当前样本的值。

三、展示一个值

{{ with query "some_metric{instance='someinstance'}" }}
{{ . | first | value | humanize }}
{{ end }}

Go和Go的模板语言都是强类型的,因此必须检查是否返回了样本以避免执行错误。 例如,如果抓取或规则评估尚未运行,或者主机已关闭,则可能会发生这种情况。包含的prom_query_drilldown模板处理此问题,允许格式化结果,并链接到表达式浏览器

四、使用命令行URL参数

{{ with printf "node_memory_MemTotal{job='node',instance='%s'}" .Params.instance | query }}
{{ . | first | value | humanize1024}}B
{{ end }}

如果以console.html?instance = hostname的身份访问,.Params.instance将评估为hostname

五、高级迭代

<table>
{{ range printf "node_network_receive_bytes{job='node',instance='%s',device!='lo'}" .Params.instance | query | sortByLabel "device"}}
<tr><th colspan=>{{ .Labels.device }}</th></tr>
<tr>
<td>Received</td>
<td>{{ with printf "rate(node_network_receive_bytes{job='node',instance='%s',device='%s'}[5m])" .Labels.instance .Labels.device | query }}{{ . | first | value | humanize }}B/s{{end}}</td>
</tr>
<tr>
<td>Transmitted</td>
<td>{{ with printf "rate(node_network_transmit_bytes{job='node',instance='%s',device='%s'}[5m])" .Labels.instance .Labels.device | query }}{{ . | first | value | humanize }}B/s{{end}}</td>
</tr>{{ end }}
<table>

在这里,我们遍历所有网络设备并显示每个网络设备的网络流量。由于range操作未指定变量,因此循环内部.Params.instance不可用,现在是循环变量。

六、定义可重用模板

Prometheus支持定义可重用的模板。 当与控制台库支持结合使用时,这一功能特别强大,允许跨控制台共享模板。

{{/* Define the template */}}
{{define "myTemplate"}}
do something
{{end}} {{/* Use the template */}}
{{template "myTemplate"}}

模板仅限于一个参数。 args函数可用于包装多个参数。

{{define "myMultiArgTemplate"}}
First argument: {{.arg0}}
Second argument: {{.arg1}}
{{end}}
{{template "myMultiArgTemplate" (args )}}

模板参考

官网说明Prometheus模板参考

规则的单元测试

使用promtool来测试规则:

# 单个测试文件
./promtool test rules test.yml # 多个测试文件
./promtool test rules test1.yml test2.yml test3.yml

一、测试文件格式

# 这是要考虑进行测试的规则文件列表。
rule_files:
[ - <file_name> ] # 可选的, 默认 = 1m
evaluation_interval: <duration> # 下面列出组名称的顺序将是规则组的评估顺序(在给定的评估时间)。 订单仅适用于下面提到的组。
# 下面不需要提到所有组。
group_eval_order:
[ - <group_name> ] # 所有测试都列在这里。
tests:
[ - <test_group> ]

1.1 <test_group>

# 系列数据
interval: <duration>
input_series:
[ - <series> ] # 上述数据的单元测试 # 警报规则的单元测试。 我们从输入文件中考虑警报规则。
alert_rule_test:
[ - <alert_test_case> ] # 单元测试PromQL表达式。
promql_expr_test:
[ - <promql_test_case> ]

1.2 <series>

# 这遵循通常的系列符号 '<metric name>{<label name>=<label value>, ...}'
# 例子:
# series_name{label1="value1", label2="value2"}
# go_goroutines{job="prometheus", instance="localhost:9090"}
series: <string> # 这使用扩展表示法。
# 扩展符号:
# 'a+bxc' becomes 'a a+b a+(2*b) a+(3*b) … a+(c*b)'
# 'a-bxc' becomes 'a a-b a-(2*b) a-(3*b) … a-(c*b)'
# 例子:
# . '-2+4x3' becomes '-2 2 6 10'
# . ' 1-2x4' becomes '1 -1 -3 -5 -7'
values: <string>

1.3 <alert_test_case>

Prometheus允许为不同的警报规则使用相同的警报名称。 因此,在此单元测试中,必须在单个<alert_test_case>下列出alertname的所有触发警报的并集。

# 这是从必须检查警报的时间= 0开始经过的时间。
eval_time: <duration> # 要测试的警报的名称。
alertname: <string> # 在给定评估时间在给定警报名称下触发的预期警报列表。 如果您想测试是否不应该触发警报规则,那么您可以提及上述字段并将“exp_alerts”留空。
exp_alerts:
[ - <alert> ]

1.4 <alert>

# 这些是预期警报的扩展标签和注释。
# 注意:标签还包括与警报关联的样本标签(与您在`/alerts`中看到的标签相同,没有系列`__name__`和`alertname`)
exp_labels:
[ <labelname>: <string> ]
exp_annotations:
[ <labelname>: <string> ]

1.5 <promql_test_case>

# 表达评估
expr: <string> # 这是从必须检查警报的时间= 0开始经过的时间。
eval_time: <duration> # 在给定评估时间的预期样品。
exp_samples:
[ - <sample> ]

1.6 <sample>

# 通常系列表示法中的样本标签 '<metric name>{<label name>=<label value>, ...}'
# 例子:
# series_name{label1="value1", label2="value2"}
# go_goroutines{job="prometheus", instance="localhost:9090"}
labels: <string> # promql表达式的期望值。
value: <number>

二、例子

这是用于通过测试的单元测试的示例输入文件。 test.yml是遵循上述语法的测试文件,alerts.yml包含警报规则。将alerts.yml放在同一目录中,运行./promtool test rules test.yml。

2.1 <test.yml>

# This is the main input for unit testing.
# Only this file is passed as command line argument. rule_files:
- alerts.yml evaluation_interval: 1m tests:
# Test .
- interval: 1m
# Series data.
input_series:
- series: 'up{job="prometheus", instance="localhost:9090"}'
values: '0 0 0 0 0 0 0 0 0 0 0 0 0 0 0'
- series: 'up{job="node_exporter", instance="localhost:9100"}'
values: '1+0x6 0 0 0 0 0 0 0 0' #
- series: 'go_goroutines{job="prometheus", instance="localhost:9090"}'
values: '10+10x2 30+20x5' #
- series: 'go_goroutines{job="node_exporter", instance="localhost:9100"}'
values: '10+10x7 10+30x4' # # Unit test for alerting rules.
alert_rule_test:
# Unit test .
- eval_time: 10m
alertname: InstanceDown
exp_alerts:
# Alert .
- exp_labels:
severity: page
instance: localhost:
job: prometheus
exp_annotations:
summary: "Instance localhost:9090 down"
description: "localhost:9090 of job prometheus has been down for more than 5 minutes."
# Unit tests for promql expressions.
promql_expr_test:
# Unit test .
- expr: go_goroutines >
eval_time: 4m
exp_samples:
# Sample .
- labels: 'go_goroutines{job="prometheus",instance="localhost:9090"}'
value:
# Sample .
- labels: 'go_goroutines{job="node_exporter",instance="localhost:9100"}'
value:

2.2 <alerts.yml>

# This is the rules file.

groups:
- name: example
rules: - alert: InstanceDown
expr: up ==
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." - alert: AnotherInstanceDown
expr: up ==
for: 10m
labels:
severity: page
annotations:
summary: "Instance {{ $labels.instance }} down"
description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."

Prometheus学习系列(五)之Prometheus 规则(rule)、模板配置说明的更多相关文章

  1. prometheus学习系列五: Prometheus配置文件

    在prometheus监控系统,prometheus的职责是采集,查询和存储和推送报警到alertmanager.本文主要介绍下prometheus的配置文件. 全局配置文件简介 默认配置文件 [ro ...

  2. prometheus学习系列十一: Prometheus 报警规则配置

    prometheus监控系统的的报警规则是在prometheus这个组件完成配置的. prometheus支持2种类型的规则,记录规则和报警规则, 记录规则主要是为了简写报警规则和提高规则复用的, 报 ...

  3. prometheus学习系列十一: Prometheus和AlertManager的高可用

    前面的系列中, prometheus和alertmanager都是单机部署的,会有单机宕机导致系统不可用情况发生.本文主要介绍下prometheus和alertmanager的高可用方案. 服务的高可 ...

  4. prometheus学习系列九: Prometheus AlertManager使用

    在Prometheus的报警系统中,是分为2个部分的, 规则是配置是在prometheus中的, prometheus组件完成报警推送给alertmanager的, alertmanager然后管理这 ...

  5. prometheus学习系列十一: Prometheus 安全

    prometheus安全 我们这里说的安全主要是基本认证和https2种, 目前这2种安全在prometheus中都没有的, 需要借助第三方软件实现, 这里以nginx为例. 基本认证 配置基本认证 ...

  6. prometheus学习系列十一: Prometheus pushgateway的使用

    由于网络问题或者安全问题,可能我们的数据无法直接暴露出一个entrypoint 给prometheus采集. 这个时候可能就需要一个pushgateway来作为中间者完成中转工作.  promethe ...

  7. prometheus学习系列十一: Prometheus exporter详解

    exporter详解 前面的系列中,我们在主机上面安装了node_exporter程序,该程序对外暴露一个用于获取当前监控样本数据的http的访问地址, 这个的一个程序成为exporter,Expor ...

  8. prometheus学习系列十: Prometheus AlertManager配置文件说明

    alertmanager配置文件说明 alertmanager是通过命令行标记和配置文件配置的,命令行标记配置不可变的系统参数,配置文件定义抑制规则.通知路由和通知接收器.可以通过官方提供的routi ...

  9. prometheus学习系列一: Prometheus简介

    Prometheus简介 prometheus受启发于Google的Brogmon监控系统(相似kubernetes是从Brog系统演变而来), 从2012年开始由google工程师Soundclou ...

  10. prometheus学习系列十一: Prometheus 采集器的编写

    在前面的文章已经写了官方的几个exporter的使用了. 在实际使用环境中,我们可能需要收集一些自定义的数据, 这个时候我们一般是需要自己编写采集器的. 快速入门编写一个入门的demo 编写代码 fr ...

随机推荐

  1. 走近深度学习,认识MoXing:初识华为云ModelArts的王牌利器 — MoXing

    [摘要] 本文为MoXing系列文章第一篇,主要介绍什么是MoXing,MoXing API的优势以及MoXing程序的基本结构. MoXing的概念 MoXing是华为云深度学习服务提供的网络模型开 ...

  2. 硬核评测:企业上云的极速存储挑战,华为云全新极速IO云硬盘性能评测

    来源:至顶网 作者:董培欣 借助华为云全新一代极速IO云硬盘开启邀测的时机,至顶网评测实验室展开了一次华为云极速IO云硬盘与超高IO云硬盘的性能对比测试活动,并且尝试通过相关测试成绩,对云硬盘的应用能 ...

  3. 带着canvas去流浪系列之五 绘制K线图

    [摘要] 用canvas原生API实现百度Echarts 示例代码托管在:http://www.github.com/dashnowords/blogs 一. 任务说明 使用原生canvasAPI绘制 ...

  4. L1 loss, L2 loss以及Smooth L1 Loss的对比

    总结对比下\(L_1\) 损失函数,\(L_2\) 损失函数以及\(\text{Smooth} L_1\) 损失函数的优缺点. 均方误差MSE (\(L_2\) Loss) 均方误差(Mean Squ ...

  5. JS中的运算符_函数学习

    js中的运算符:     算数运算符:     + - * / % ++ --          逻辑运算符:     & | !  && || < > <= ...

  6. 200G网盘资源分享

    今日偶得大量网盘资源,遂写一博文以分享! 来源:HACK学习呀,微信公众号:HACK学习呀 文件名 链接 提取密码 2015cracer入侵入门到精通视频教程 点我查看 trf3 一笔√带过入侵教程 ...

  7. 一元建站-基于函数计算 + wordpress 构建 serverless 网站

    前言 本文旨在通过 快速部署一个 wordpress 网站到阿里云函数计算平台 这个示例来展示 serverless web 新的开发模式, 包括 FUN 工具一键初始化 NAS, 同步网站到 NAS ...

  8. 3个Spring Boot项目调优的方式

    前言 作为一名工程师,项目调优这事,是必须得熟练掌握的事情. 在SpringBoot项目中,调优主要通过配置文件和配置JVM的参数的方式进行.   一.修改配置文件 关于修改配置文件applicati ...

  9. android之 xml文件一般用到的属性

    android:layout_above 将该控件的底部至于给定ID的控件之上android:layout_below 将该控件的顶部至于给定ID的控件之下android:layout_toLeftO ...

  10. Linux vi与vim使用

    vi与vimvi编辑器是所有Unix及Linux系统下标准的编辑器,他就相当于windows系统中的记事本一样,它的强大不逊色于任何最新的文本编辑器.他是我们使用Linux系统不能缺少的工具.由于对U ...