prometheus告警处理

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

一.告警简介

1.工作流程
  • prometheus收集监测的信息

  • prometheus.yml 文件中定义 rules 文件,rules 里包含告警信息

  • prometheus 把告警信息 push 给 altermanager,alertmanager 里定义收件人和发件人

  • altermanager 发送文件到邮箱或微信

2.告警生命周期
  • 定期采集监控数据
  • 定期扫描告警规则,发现告警发给 alertmanager,prometheus 页面能看到 alert ,状态为 pending
  • 多次发送到 alertmanager,持续时长超过告警告警规则的 for 的 alert,prometheus 页面看到状态为 firing,准备发送
  • firing 状态的 alert 等待 group_interval 时间聚合发送
  • 恢复正常后,警报状态重新变回 inactive
3.告警等级
  • Inactive: 什么都没发生
  • Pending:已触发阈值,但未满足告警持续时间
  • Firing:已触发阈值,并满足for定义的持续时间。告警发送给接受者
4.通知方式
  • webhook:web回调或者http服务的推送API接口
  • wechat:通过微信 API发送
  • sns:短信
  • Pushover :通过Pushover API发送
  • email:电子邮件

二. AlertManager组件

1.特性

prometheus是组件化工具,prometheus server只负责产生告警,并不会处理告警。 AlertManager组件就是用来处理和消费告警

Alertmanager定义告警机制,通过Slack,Email,wechat等发送警报

1.1 分组

当系统停机时,可能会成百上千的报警同时生成,这个时候就需要将这些告警信息分组了

分组:是指当出现问题时,Altermanager会收到一个单一的通知

将同类型/同一种影响的短信合并为一条来发送

1.2. 抑制

抑制:是指当报警发出后,停止重复发送初始化警告引发其他错误的警告的机制

例如当警报被触发,通知整个性能不可达,可以配置Alertmanager忽略由该警报触发而产生的所有其他警报,这可以防止通知多个或多个问题不相关的其他警报。

1.3.沉默

沉默:是指在特定时间内不要发送告警信息,比如设置23点-08点不发送任何告警信息

2.AlertManager安装
2.1 下载安装
wget https://github.com/prometheus/alertmanager/releases/download/v0.24.0/alertmanager-0.24.0.linux-amd64.tar.gz

 tar xvf -C /usr/local/ alertmanager-0.24.0.linux-amd64.tar.gz
 
 cd /usr/local/
 
 ln -s alertmanager-0.24.0.linux-amd64 alertmanager
2.2 创建service脚本

vi /usr/lib/systemd/system/alertmanager.service

[Unit]
Description=alertmanager

[Service]
ExecStart=/usr/local/alertmanager/alertmanager --config.file=/usr/local/alertmanager/alertmanager.yml --storage.path=/usr/local/alertmanager/data --web.listen-address=:9093 --data.retention=120h
Restart=on-failure

[Install]
WantedBy=multi-user.target

2.3 检查配置文件
./amtool check-config alertmanager.yml


Checking 'alertmanager.yml'  SUCCESS
Found:
 - global config
 - route
 - 0 inhibit rules
 - 1 receivers
 - 0 templates
2.4 启动程序
systemctl daemon-reload

systemctl start alertmanager

systemctl enable alertmanager

3.自定义告警规则

Prometheus中的告警规则允许你基于PromQL表达式定义告警触发条件,Prometheus后端对这些触发规则进行周期性计算,当满足触发条件后则会触发告警通知

在告警规则文件中,我们可以将一组相关的规则设置定义在一个group下。在每一个group中我们可以定义多个告警规则(rule)

一条告警规则主要由以下几部分组成:

  • alert: 告警规则名称

  • expr:基于PromQL表达式定义满足告警触发的条件

  • for:

  • labels:自定义标签,允许用户指定要附加到告警上的一组附加标签

  • annotations:用于指定一组附加信息,比如用于描述告警详细信息的文字等。

    annotations的内容在告警产生时会一同作为参数发送到Alertmanager。

    summary描述告警的概要信息,description用于描述告警的详细信息。

    同时Alertmanager的UI也会根据这两个标签值,显示告警信息

示例:

groups:
- name: queue-messages-warning
  rules:
  - alert: queue-messages-warning
    expr: sum(rabbitmq_queue_messages{job='rabbit-state-metrics'}) > 500
    labels:
      team: webhook-warning
    annotations:
      summary: High queue-messages usage detected
      description: "description"
4. 自定义通知模板

默认模板

https://github.com/prometheus/alertmanager/blob/main/template/default.tmpl

alertmanager.yml 中添加使用模板


global:
  resolve_timeout: 5m


templates:
  - './template/alertmanager-wechat.tmpl'

route:

  group_by: ['alertname','app']
  group_wait: 30s

  group_interval: 5m

  repeat_interval: 30s

  receiver: 'wechat'


receivers:

- name: 'wechat'

  wechat_configs:
    - corp_id: 'wwa28f62ad74db58ce'
      # 当前收件人是否接受告警恢复的通知
      send_resolved: true
      message: '{{ template "wechat.default.message" . }}'
      #发送给所有人
      to_user: '@all' 
      #你的应用id
      agent_id: 1000003
      #你的应用秘钥
      api_secret: 'WtXlfif6TJjmYipx7Cg6W_tx9tVFrJm_BgDHEWEGL54'
      send_resolved: true

添加模板规则

这里定义的时间为go 语言的诞生时间!!!切记不能乱填

StartsAt.Add 28800e9).Format “2006-01-02 15:04:05”

vi ./template/alertmanager-wechat.tmpl

{{ define "wechat.default.message" }}
{{- if gt (len .Alerts.Firing) 0 -}}
{{- range $index, $alert := .Alerts -}}

=========  监控告警 =========
告警程序:     Alertmanager
告警类型:    {{ $alert.Labels.alertname }}
告警级别:    {{ $alert.Labels.severity }} 级
告警状态:    {{ .Status }}
故障主机:    {{ $alert.Labels.instance }} {{ $alert.Labels.device }}
告警主题:    {{ .Annotations.summary }}
告警详情:    {{ $alert.Annotations.message }}{{ $alert.Annotations.description}}
主机标签:    {{ range .Labels.SortedPairs  }}  [{{ .Name }}: {{ .Value  | html }} ] {{- end }} 
故障时间:    {{ (.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}


{{- end }}
{{- end }}

{{- if gt (len .Alerts.Resolved) 0 -}}
{{- range $index, $alert := .Alerts -}}

========= 告警恢复 =========
告警程序:     Alertmanager
告警主题:    {{ $alert.Annotations.summary }}
告警主机:    {{ .Labels.instance }}
告警类型:    {{ .Labels.alertname }}
告警级别:    {{ $alert.Labels.severity }} 级
告警状态:    {{   .Status }}
告警详情:    {{ $alert.Annotations.message }}{{ $alert.Annotations.description}}
故障时间:    {{ (.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}
恢复时间:    {{ (.EndsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}

{{- end }}
{{- end }}
{{- end }}

三.配置告警信息

1. Prometheus配置告警规则
1. 1 配置alertmanager地址

要实现Prometheus向Alertmanager中发送信息,只需要配置alertmanager连接地址即可

vi prometheus.yml

# Alertmanager 配置

alerting:
  alertmanagers:
  - static_configs:
  	# altermanager连接地址
    - targets: ['10.10.10.100:9093']
1.2 添加告警规则
  • 添加 rule_files 配置

在实际环境中,告警规则肯定有很多,比如对服务器异常进行告警,就有宕机、CPU使用率超过100%、内存使用率超过80%、硬盘使用率超过80%等等

最好创建一个文件夹,针对每个监控对象,创建一个配置文件。

告警规则配置在独立的文件中,文件格式为yml,并在prometheus.yml文件的rule_files模块中进行引用,prometheus启动时,会在rule_files定义的文件或目录下查找规则配置文件并加载

vi prometheus.yml

# 服务器加载规则文件的路径

rule_files:
 - "/etc/prometheus/sd_config/alert_rules/*.yml"
  • 创建告警规则文件

进入 rule_files配置的文件路径下创建

vi /etc/prometheus/sd_config/alert_rules/alert_memory.yml

# 相关的规则设置定义在一个group下。在每一个group中我们可以定义多个告警规则(rule)
groups:
# name:组名。报警规则组名称
- name: alters
  # rules:定义规则
  rules:
  # alert:告警规则的名称
  - alert: NodeMemoryUsage 
  
    # expr:基于PromQL表达式告警触发条件,用于计算是否有时间序列满足该条件。
    expr: 100 - (node_memory_MemFree_bytes+node_memory_Cached_bytes+node_memory_Buffers_bytes) / node_memory_MemTotal_bytes * 100 > 20
    
    # for:评估等待时间,可选参数。用于表示只有当触发条件持续一段时间后才发送告警。在等待期间新产生告警的状态为pending。
    for: 1m
    
    # labels:自定义标签,允许用户指定要附加到告警上的一组附加标签。
    labels:
      # severity: 指定告警级别。有三种等级,分别为warning、critical和emergency。严重等级依次递增。
      severity: emergency

    # annotations: 附加信息,比如用于描述告警详细信息的文字等
    # annotations的内容在告警产生时会一同作为参数发送到Alertmanager。
    annotations:
      # summary描述告警的概要信息
      # description用于描述告警的详细信息。
      summary: "内存使用过高"
      description: "{{ $labels.instance }} 内存使用大于 80% (当前值: {{ $value }})"

2.Alertmanager配置告警机制
wechat 告警通知

vi alertmanager.yml文章来源地址https://www.toymoban.com/news/detail-401710.html

# 全局配置,全局配置,包括报警解决后的超时时间、SMTP 相关配置、各种渠道通知的 API 地址等等。
global:
  # 告警超时时间
  resolve_timeout: 5m
# 路由配置,设置报警的分发策略,它是一个树状结构,按照深度优先从左向右的顺序进行匹配。
route:
  # 接受者名称,对应下面receivers中的name
  receiver: 'wechat'

  # 用于将传入警报分组在一起的标签。
  # 基于告警中包含的标签,如果满足group_by中定义标签名称,那么这些告警将会合并为一个通知发送给接收器。
  group_by: ['alertname']
  # 发送通知的初始等待时间
  group_wait: 30s

  # 上下两组发送告警的间隔时间。
  group_interval: 5m
  # 如果已发送通知,则在再次发送通知之前要等待多长时间,通常约3m或更长时间
  repeat_interval: 30s


# 配置告警消息接受者信息
# 例如常用的 email、wechat、slack、webhook 等消息通知方式
receivers:
# 接受者名称
- name: 'wechat'
  # webhook URL
  wechat_configs:
      #企业ID (我的企业-->CorpId[在底部])
    - corp_id: 'wwa28f62ad74db58ce'
      #发送给所有人
      to_user: '@all' 
      #应用id (企业微信-->自定应用-->AgentId)
      agent_id: 1000003
      #应用秘钥 (企业微信-->自定应用--)
      api_secret: 'WtXlfif6TJjmYipx7Cg6W_tx9tVFrJm_BgDHEWEGL54'
      
      # 当前收件人是否接受告警恢复的通知
      send_resolved: true

到了这里,关于prometheus告警处理的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

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

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

相关文章

  • 网络安全等级保护测评:工作流程及工作内容

    **一、** 网络安全等级保护测评过程概述 网络安全等级保护测评工作过程包括四个基本测评活动: 测评准备活动、方案编制活动、现场测评活动、报告编制活动 。而测评相关方之间的沟通与洽谈应贯穿整个测评过程。每一项活动有一定的工作任务。如下表。 01 基本工作流程

    2024年02月06日
    浏览(55)
  • 机器学习工作流程

    机器学习的定义 机器学习的工作流程 获取到的数据集的特性 1、什么是机器学习 机器学习是 从数据中自动分析获得模型,并利用模型对未知数据进行预测。 2、机器学习工作流程 机器学习工作流程总结 1、获取数据 2、数据基本处理 3、特征工程 4、机器学习(模型训练)

    2024年02月04日
    浏览(68)
  • AES工作流程

    工作流程 模式 1:加密 ⚫ 复位EN 重置AES模块 ⚫ 设置模式寄存器mode[1:0]=00,设置流数据处理模式寄存器CHMOD[1:0] ⚫ 写AES_KEYRx寄存器,CTR和CBC模式下写AES_IVRx寄存器 ⚫ 写EN=1,使能AES ⚫ 写AES_DINR 寄存器4次 ⚫ 等待CCF标志置起 ⚫ 从AES_DOUTR分4次读出加密结果 ⚫ 对于同一个key,重

    2024年02月01日
    浏览(48)
  • SpringMVC的工作流程

    SpringMVC的工作流程图 SpringMVC的工作流程 1. 用户通过客户端向服务器发送请求,请求会被 SpringMVC的前端控制器DispatcherServlet所拦截。 2. DispatcherServlet拦截到请求后,会调用HandlerMapping处理器映射器。 3. 处理器映射器根据请求URL找到具体的处理器,生成处理器对象及处理器拦

    2024年01月24日
    浏览(50)
  • HTTPS的工作流程

    hi,大家好,好久不见,今天为大家带来HTTPS协议的工作流程 HTTPS也是应用层协议,让我们再来回忆一下TCP/IP五层协议模型 HTTPS 也是一个应用层协议. 是在 HTTP 协议的基础上引入了一个加密层. HTTP协议在传输的时候是以文本的形式传输的,就可能会导致被劫持,这里的劫持包括但不限于

    2024年02月06日
    浏览(64)
  • RabbitMQ工作流程详解

    (1)生产者连接RabbitMQ,建立TCP连接(Connection),开启信道(Channel) (2)生产者声明一个Exchange (交换器),并设置相关属性,比如交换器类型、是否持久化等 (3)生产者声明一个队列井设置相关属性,比如是否排他、是否持久化、是否自动删除等 (4)生产者通过bindingKey (绑定Key) 将交换器

    2024年02月13日
    浏览(46)
  • STM32 工作流程

    工作流程: 上电后,芯片复位启动 MCU通过指令/数据总线从FLASH中读取指令或数据,配合解析执行,然后再通过RAM和通用寄存器(R0~R12的内部寄存器)处理可变数据 根据执行的指令,配置和操作外设的寄存器,从而驱动对应的外设实现具体的功能 配合上层组合逻辑,结合外设

    2024年02月11日
    浏览(41)
  • 软件测试工作流程

    流程体系介绍 在以往的项目工作中,我参与过,需求评审、测试计划制定、测试用例编写、测试用例执行、测试脚本编写、测试脚本的执行,进行回归测试、验收测试、编写阶段性测试报告等工作 需求分析,需求评审(RPD、产品原型图) 制定测试计划、评审测试计划、优化

    2024年02月05日
    浏览(44)
  • 简述springMVC工作流程

    Spring MVC是一个基于Java的开源MVC框架,用于构建Web应用程序。它通过将应用程序分解为模型(Model)、视图(View)和控制器(Controller)三个部分,以提高应用程序的可维护性和可扩展性。以下是Spring MVC的基本工作流程: 客户端发送请求: 客户端通过浏览器或其他客户端发送

    2024年02月05日
    浏览(50)
  • SpringCloud Gateway工作流程

    具体的流程: 用户发送请求到网关 请求断言 ,用户请求到达网关后,由Gateway Handler Mapping(网关处理器映射)进行Predicates(断言),看一下哪一个符合路由规则,选择对应的过滤器进行处理 上面是使用 application.yml 对网关进行路由规则的制定 - id: api_route : 这是路由的标识符

    2024年03月23日
    浏览(30)

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

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

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

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

二维码1

领取红包

二维码2

领红包