Prometheus-Rules(规则)-基础语法

这篇具有很好参考价值的文章主要介绍了Prometheus-Rules(规则)-基础语法。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一、介绍

Prometheus规则是一种逻辑表达式,可用于定义有关监控数据的逻辑关系和约束条件。这些规则可以用于告警条件、聚合和转换等。

普罗米修斯支持两种类型的规则,可以对其进行配置,然后定期进行评估:

  • recording rules
  • alerting rules。

要在 Prometheus 中使用规则,请创建一个包含所需规则语句的文件,并让Prometheus 通过 Prometheus 配置中的 rule_files 字段加载该文件。规则文件使用YAML 格式。

Alerting规则:在满足某些条件时触发警报,例如CPU使用率超过90%。

Recording规则:使用PromQL表达式进行聚合和转换,将结果记录下来。例如计算平均响应时间。可以作为性能指标的跟踪,以便找到规律优化服务。

通过使用这些规则,您可以轻松地监控和管理您的应用程序和基础设施,并及时发现并解决任何问题。

二、配置 Prometheus 使用规则文件

需要在 Prometheus 的配置文件中的 rule_files 字段下添加配置,rule_files 字段的值是一个包含多个规则文件路径的列表,规则文件路径支撑通配符。示例如下:

prometheus.yml

...

rule_files:
  - "prometheus.rules.yml"  # 指定具体文件
  - "rules/*.yml"  # 指定 rules 目录下的所有以 .yml 结尾的文件

三、 规则文件语法

记录和警报规则存在于规则组中。组中的规则以固定的时间间隔按顺序运行,评估时间相同。
记录规则的名称必须是有效的度量值名称。警报规则的名称必须是有效的标签值。
记录规则名称需要符合正则表达式: [a-zA-Z_:][a-zA-Z0-9_:]*
警报规则名称需要符合正则表达式:[a-zA-Z_][a-zA-Z0-9_]*__(两个“_”)开头的标签名称保留供内部使用

规则文件语法

全局

groups:
  #  一个规则组的名称,在当前文件中需唯一。
  - name: example
    # 获取规则数据的频率,也就是每次查询规则的间隔时间,比如设置为 5s, 1m 等。一般按默认,默认是安装 prometheus 配置文件中全局配置的 evaluation_interval 值。
    [ interval: <duration> | default = global.evaluation_interval ]

    # 限制警报规则和记录规则可以产生的系列警报的数量。0没有限制。一般按默认
    [ limit: <int> | default = 0 ]

    # 定义这个规则组中一个一个的规则
    rules:
      [- <rule> ...]

Recording rules(记录规则)

记录规则允许您预先计算经常需要的或计算成本高昂的表达式,并将其结果保存为一组新的时间序列。

groups:
  - name: example
    rules:
      # record 字段: 输出到的时间序列的名称。必须是有效的度量值名称
    - record: code:prometheus_http_requests_total:sum
    
      # 要计算的PromQL表达式。每个评估周期都在当前时间进行评估,结果记录为一组新的时间序列,度量名称由 "record" 给出
      expr: sum by (code) (prometheus_http_requests_total)

      # labels 下配置的是存储结果之前要添加或覆盖的标签
      labels:
        [ <labelname>: <labelvalue> ]

2 Alerting rules(警报规则)

警报规则文件的语法几乎和记录规则文件语法一样,只是 rule (规则)配置中部分字段不同。

groups:
  - name: example
    rules:
      # alertname 警报的名称。必须符合有效标签名称的规则。
	- alert: <string>
	
	
	  # 要计算的PromQL表达式。
	  # 每个评估周期都会在当前时间进行评估,满足表达式条件后,所有生成的时间序列都会变为 pending 挂起/ firing alerts 触发警报。 
	  expr: <string>
	
	  # 当 expr 内书写的表达式条件满足后,警报会立刻变成 pending 状态.
	  # 持续超过 for 指定的时间后,警报会被视为触发,并转为 firing 状态。
	  # pending 和 firing 也会在 Prometheus Web 页面中看到.
	  # 如果没有此配置,
	  [ for: <duration> | default = 0s ]
	
	  # 触发警报的条件清除后,警报仍然保持触发状态多长时间。
	  [ keep_firing_for: <duration> | default = 0s ]
	
	  # 要为每个警报添加或覆盖的标签。标签值可以使用 go 的模板变量
	  labels:
	    [ <labelname>: <tmpl_string> ]
	
	  # 要添加到每个警报的注释。这个信息通常用于发送告警给某个介质(邮件,钉钉等)的内容中
	  # lavelname 的值可以使用 go 的模板变量
	  annotations:
	    [ <labelname>: <tmpl_string> ]

示例

groups:
- name: example
  rules:
  - alert: ServerDown
    expr: up == 0
    for: 10s
    labels:
      severity: page
    annotations:
      summary: Server is down

3 模板化如何使用

labels 和 annotations 字段的配置可以使用 go 语言中的模板进行模板化。

  • $labels 变量包含警报实例的标签键/值对。
  • 可以通过 $externalLabels 变量访问配置的外部标签。
  • $value 变量保存警报实例 expr 的计算结果值,注意不是返回条件表达式的 布尔值。
    例如: up == 0 中, $value 的值是 up 的计算结果,官方称为警报实例的评估值。

配置示例:

groups:
- name: example
  rules:

  # 对任何超过5分钟无法访问的实例发出警报。
  - alert: InstanceDown
    expr: up == 0
    for: 5m
    labels:
      severity: page
    annotations:
      summary: "实例: {{ $labels.instance }} 已停机"
      description: "xx 项目作业 Job:{{$labels.job}}的{{$labels.instance}}已停机超过5分钟。"

  # 针对请求延迟中值>1s的任何实例发出警报
  - alert: APIHighRequestLatency
    expr: api_http_request_latencies_second{quantile="0.5"} > 1
    for: 10m
    annotations:
      summary: "实例 {{ $labels.instance }} 请求延迟高"
      description: "{{ $labels.instance }} 的请求延迟超过 1 秒(当前值: {{ $value }}s)"

四、检查规则文件语法

在不启动 Prometheus 的情况下也可以检查规则文件中的语法是否正确。

Prometheus 安装包中的 promtool 工具可以支持规则文件语法的检查。

promtool check rules /path/to/example.rules.yml

prometheus rule,Prometheus,prometheus,javascript,前端

五、发送警报通知

普罗米修斯的警报规则善于发现目前出现的问题,但它们并不是一个成熟的通知解决方案。在简单的警报定义之上,还需要另一层来添加摘要、通知速率限制、静音和警报依赖关系。在普罗米修斯的生态系统中,Alertmanager 扮演着这个角色。
下个章节详细介绍 Alertmanager 。文章来源地址https://www.toymoban.com/news/detail-717555.html

到了这里,关于Prometheus-Rules(规则)-基础语法的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Prometheus 告警规则配置

    alert.rule即告警规则,在Prometheus中,通过用户自定义的条件进行告警,自定义条件可以由 PromQL 表达式定义,当满足告警条件后,Prometheus会通过web界面进行告警,如果同时有部署Alertmanager,则可利用Alertmanager进行更为复杂的通知,如钉钉、微信、飞书等个性化渠道进行通知。

    2023年04月25日
    浏览(35)
  • prometheus实战之三:告警规则

    欢迎访问我的GitHub 这里分类和汇总了欣宸的全部原创(含配套源码):https://github.com/zq2599/blog_demos 本篇概览 本文是《prometheus实战》系列的第三篇,一起来学习prometheus的告警功能,如下图所示,整个告警功能分为规则和通知两部分,本篇是有关规则的详细介绍,至于命中规则后

    2024年02月02日
    浏览(36)
  • 【博客662】prometheus对rule规则和alert规则作单元测试

    在实际生产中,对于rules和alerts的配置有时候出于某些特殊原因,无法进行模拟,这时候就需要我们对采集规则和告警规则进行单元测试,以确保正确性 example: 要测试此规则,您可以使用以下内容创建 test.yml: 进行测试: 测试结果: 分析一下测试文件: 这表示我们要加载

    2024年02月09日
    浏览(44)
  • Easy Rules规则引擎(1-基础篇)

    最近团队在做一些 Visa 、 Master 卡的交易风控,运营团队提供了一些交易风控的规则,比如针对卡号MCC设置单笔交易限额,24小时交易限额,72小时交易限额等等,还有触发风控规则是否拦截交易还是只发告警邮件等等等。 虽然写各种条件判断也能实现,但是随着后面规则增加

    2024年02月12日
    浏览(36)
  • vue中的rules表单校验规则使用方法 :rules=“rules“

    :ref=\\\"dataForm\\\"        // 提交表单时进行校验 :rules=\\\"rules\\\"            // return 下的校验规则 :model=\\\"userForm\\\"  // 绑定表单的值 点击提交时,会先对表单的值进行校验判断,校验通过后,再进行后续操作。 el-form-item 里面使用 prop 属性绑定规则 el-form-item label=\\\"充值金额\\\"  prop=\\\"amo

    2024年02月05日
    浏览(46)
  • Prometheus服务器、Prometheus被监控端、Grafana、Prometheus服务器、Prometheus被监控端、Grafana

    day03Prometheus概述部署Prometheus服务器环境说明:配置时间安装Prometheus服务器添加被监控端部署通用的监控exporterGrafana概述部署Grafana展示node1的监控信息监控MySQL数据库配置MySQL配置mysql exporter配置mysql exporter配置prometheus监控mysql自动发现机制概述基于文件自动发现修改Prometheus使

    2024年02月14日
    浏览(44)
  • Avue组件或Element-UI动态修改rules验证规则或根据条件修改rules验证规则

    根据条件修改验证规则:el-form中若A为空,则B可为空,若A有值,则B必填,动态改变B的验证规则 在watch监听事件中,使用auve-form自带的:defaults.sync=\\\"defaults\\\"属性,来操作B的rules验证规则,此写法的效果好于el-form原生,因为设置为必填后会有必填标志* 使用watch监听A值的变化,若

    2024年02月12日
    浏览(48)
  • 规则引擎----easy rules

    将复杂的if else判断剥离出来 2.1、引入POM 2.2、编写规则 2.2.1、注解 2.2.2、表达式 2.2.3 yml配置文件 2.2.4 组合规则 2.2.5 组合规则说明 类 说明 UnitRuleGroup 要么应用所有规则,要么不应用任何规则(AND逻辑) ActivationRuleGroup 它触发第一个适用规则,并忽略组中的其他规则(XOR逻辑

    2024年02月13日
    浏览(39)
  • ElementUI 表单 rules 规则

    ElementUI组件库中表单校验默认使用的是async-validator,所以要了解ElementUI表单验证的rules规则,先了解async-validator type :验证数据类型 支持的类型如下,默认类型为string string 值必须是 String 类型,这是默认值 number 值必须是 String 类型,包含整数和小数 integer 值必须是 Number 和整

    2024年02月10日
    浏览(34)
  • 二、写规则(Rules)

    规则没有先后顺序 一般来说规则的顺序是没有先后的,除了默认target的规则。make会将第一个makefile里面的第一条规则的第一个target作为默认的target。所以,默认target的规则应该放在最前面,一般使用all作为默认target的名称。 规则的声明 第一种格式,将recipe从新行开始写,如

    2024年02月03日
    浏览(29)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包