Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >专栏 >prometheus实战之四:alertmanager的部署和配置

prometheus实战之四:alertmanager的部署和配置

作者头像
程序员欣宸
发布于 2023-05-27 06:14:02
发布于 2023-05-27 06:14:02
2.2K00
代码可运行
举报
文章被收录于专栏:实战docker实战docker
运行总次数:0
代码可运行

欢迎访问我的GitHub

这里分类和汇总了欣宸的全部原创(含配套源码):https://github.com/zq2599/blog_demos

本篇概览

  • 本文是《prometheus实战》系列的第四篇,在《prometheus实战之三:告警规则》中曾经提到过,整个告警功能分为规则和通知两部分,前文详细说明了规则,今天要学习的就是剩下的通知部分
  • 完整的数据流如下图,告警从prometheus出发,到达alertmanager之后,根据配置,alertmanager会调用web服务的接口,而web服务自己又会向飞书服务器发送请求,从而触发飞书APP收到通知
  • 之所以选飞书作通知手段,首先是简单,其次是相对熟悉,您也可以按照自己的喜好去选择通知途径
  • 本篇要做的是把alertmanager部署好,配置好,至于后面的web服务就留在下一篇吧,咱们适当控制篇幅
  • 接下来把本篇的操作步骤按顺序列一下,然后开工,如下所示,一共八步,助您完成完全个性化的告警配置
  • 接下来就逐步完成吧

1. 编写部署alertmanager的ansible脚本

  • 关于用ansible部署软件的操作,咱们在《prometheus实战之一:用ansible部署》有详细的说明,因此关于ansible的基本设置就不在本篇赘述了,直接给出部署alertmanager的ansible脚本即可
  • ansible的改动一共有以下三步
  • hosts文件内容如下,新增了alertmanager,可见我这里是把prometheus和alertmanager部署在同一台机器上的,您可以按自己的实际情况调整
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
[prometheus-group]
prometheus ansible_host=192.168.50.134 ansible_port=22 ansible_user=prometheus ansible_password=888888
working001 ansible_host=192.168.50.134 ansible_port=22 ansible_user=prometheus ansible_password=888888
alertmanager ansible_host=192.168.50.134 ansible_port=22 ansible_user=prometheus ansible_password=888888
  • vars.yml文件内容如下,新增四个和alertmanager有关的
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
prometheus_user_home: /home/prometheus
prometheus_base_path: '{{prometheus_user_home}}/prometheus'
prometheus_url: https://github.com/prometheus/prometheus/releases/download
prometheus_version: 2.37.7
prometheus_deploy_path: '{{prometheus_base_path}}/prometheus-{{prometheus_version}}.linux-amd64'

node_exporter_base_path: '{{prometheus_user_home}}/node_exporter'
node_exporter_url: https://github.com/prometheus/node_exporter/releases/download
node_exporter_version: 1.5.0
node_exporter_deploy_path: '{{node_exporter_base_path}}/node_exporter-{{node_exporter_version}}.linux-amd64'

alertmanager_base_path: '{{prometheus_user_home}}/alertmanager'
alertmanager_url: https://github.com/prometheus/alertmanager/releases/download
alertmanager_version: 0.25.0
alertmanager_deploy_path: '{{alertmanager_base_path}}/alertmanager-{{alertmanager_version}}.linux-amd64'
  • 最后是执行部署的脚本install_alertmanager.yml
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
- name: 部署alertmanager
  hosts: alertmanager
  gather_facts: True
  vars_files:
  - vars.yml  
  tasks:
  - name: 停止残留的alertmanager
    ignore_errors: yes
    systemd:
      name: alertmanager
      state: stopped
    become: yes

  - name: 清理可能的alertmanager service残留文件
    file:
      path: /etc/systemd/system/alertmanager.service
      state: absent
    become: yes

  - name: 清理可能的alertmanager残留文件夹
    file:
      path: '{{alertmanager_base_path}}'
      state: absent

  - name: 新建部署文件夹
    file:
      path: '{{alertmanager_base_path}}'
      state: directory
      mode: '0755'

  - name: 下载并解压文件alertmanager-{{alertmanager_version}}.linux-amd64.tar.gz
    ansible.builtin.unarchive:
      src: '{{alertmanager_url}}/v{{alertmanager_version}}/alertmanager-{{alertmanager_version}}.linux-amd64.tar.gz'
      dest: '{{alertmanager_base_path}}'
      remote_src: yes

  - name: 生成systemd的service文件
    shell: |
      tee /etc/systemd/system/alertmanager.service <<-'EOF'
      [Unit]
      Description=Alert manager Server
      Documentation=https://prometheus.io/docs/introduction/overview/
      After=network-online.target
      [Service]
      User=prometheus
      Restart=on-failure
      ExecStart={{alertmanager_deploy_path}}/alertmanager --config.file={{alertmanager_deploy_path}}/alertmanager.yml --storage.path={{alertmanager_base_path}}/data
      [Install]
      WantedBy=multi-user.target
      
      EOF
    become: yes

  - name: 刷新服务配置
    systemd:
      daemon_reload: true
    become: yes

  - name: 将alertmanager服务设置为自启动
    systemd:
      name: alertmanager
      enabled: true
      masked: no
    become: yes      

  - name: 启动alertmanager
    systemd:
      state: started
      name: alertmanager
    become: yes      
  • 以上就是部署alertmanger所需的全部脚本了,它们都存放在ansible服务器的playbooks目录下

2. 部署alertmanager

  • ssh到ansible服务器,在playbooks目录执行以下命令即可完成部署
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
ansible-playbook install_alertmanager.yml
  • 检查服务状态,确认已经启动成功
  • alertmanager也有自己的webui,端口号是9093,浏览器打开后如下图所示,只不过现在还是空空如也的状态

3. 配置prometheus,使告警到达alertmanager

  • 目前prometheus还不知道alertmanager服务已就绪,需要修改它的配置文件prometheus.yml,让它知道alertmanager在哪里
  • 以prometheus账号的身份登录prometheus服务器,修改prometheus.yml文件,如下图,增加alertmanager的地址
  • 然后用命令systemctl restart prometheus重启prometheus服务(注意是prometheus账号)
  • 可以在prometheus的webui检查配置是否成功

4. 配置alertmanager,使通知到达web服务

  • 现在prometheus的告警可以到达alertmanager了,然后要考虑的是alertmanager如何处理这个告警,按照最初的目标,就是alertmanager会发起webhook,于是咱们就要在alertmanager上做配置,让它知道收到告警后该怎么做
  • alertmanager的告警通知配置共有以下五部分
  • 全局配置(global):一些通用的全局参数
  • 模板(templates):告警通知用的模板
  • 告警路由(route):指定特定的告警去特定的通知目标,例如A告警走webhook,B告警走邮件通知
  • 通知接受者(receivers):定义通知目标,例如webhook、邮件等
  • 抑制规则(inhibit_rules):对告警进行收敛的规则,避免产生无用告警
  • 本篇使用的配置文件route.yml如下,每个配置都有详细描述
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
global:
  # 全局配置,收到告警后,如果持续10分钟都没再收到告警,就把告警状态标记为resolved(已解决)
  resolve_timeout: 10m
route:
  # 分组,处于同一组的告警会被合并为同一个通知
  # 这里设置的是alertname相同的告警会被合并为同一个通知
  group_by: ['alertname']
  # 30秒是个时间窗口,这个窗口内,同一个分组的所有消息会被合并为同一个通知
  group_wait: 30s
  # 同一个分组发送一次合并消息之后,每隔1分钟检查一次告警,判断是否要继续对此告警做操作
  group_interval: 1m
  # 按照group_interval的配置,每隔1每分钟检查一次,等到第六次时,1*6=6,大于repeat_interval的5m,此时就会在再次发送告警
  repeat_interval: 5m
  # 指定具体的通知方式
  # 简单起见,这里只配置了顶级路由,没有针对故障的标签进行细分
  receiver: 'web.hook'
receivers:
  - name: 'web.hook'
    webhook_configs:
      # alertmanager发起web请求的地址
      - url: 'http://192.168.50.134:8888/webhook'
# 告警抑制规则,可以有多条
inhibit_rules:
  # 这个规则的意思是:一旦收到critical级别的告警,那么再收到低级别(warning)的告警就没必要通知了,
  # 还有一处非常重要的比较,就是低级别告警的node标签的值,要和critical级别告警的node标签的值要相等,也就是确保两个告警的来源相同
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['node']
  • 在本篇的实战中,由于prometheus发来的告警非常简单,只是个CPU使用量过高的告警,达不到上面的抑制规则的要求(需要sererity和node两个标签),所以抑制规则就不做实际演练了
  • 注意上面配置的webhook_configs,地址是http://192.168.50.134:8888/webhook,这是咱们自己写的一个web服务,只要alertmanager收到prometheus发来的告警,就会调用这个web接口,当然了,目前此接口还未实现,留待下一篇完成

5. 简单验证

  • 现在web应用还没有开发出来,所以alertmanager收到告警去调用web接口肯定会失败的
  • 不过即便如此,我也想强行试试效果,动手吧
  • 确保您的prometheus是正常状态,然后像前文那样把应用服务器的CPU弄得很高(例如运行ffmpeg),触发告警
  • 这时候去看alertmanager的web UI,地址是http://192.168.50.134:9093/#/alerts,发现已经收到了来自prometheus的告警,证明咱们的部署和配置都是有效的了
  • 既然咱们配置了webhook,而且webhook的地址是个不存在的服务,那么alertmanager的告警通知应该会发生调用失败吧,这只是个推测,要如何确认呢?
  • 用命令journalctl _PID=767查看alertmanager日志,767是alertmanager的进程ID,内容如下所示,可见alertmanager确实根据配置向http://192.168.50.134:8888/webhook发起了web调用,遇到了connection refused错误,完全符合预期
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
May 13 10:04:40 deskmini alertmanager[767]: ts=2023-05-13T02:04:40.869Z caller=notify.go:732 level=warn component=dispatcher receiver=web.hook integration=webhook[0] msg="Notify attempt failed, will retry later" attempts=1 err="Post \"http://192.168.50.134:8888/webhook\": dial tcp http://192.168.50.134:8888/webhook: connect: connection refused"
May 13 10:09:40 deskmini alertmanager[767]: ts=2023-05-13T02:09:40.869Z caller=dispatch.go:352 level=error component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="web.hook/webhook[0]: notify retry canceled after 16 attempts: Post \"http://192.168.50.134:8888/webhook\": dial tcp http://192.168.50.134:8888/webhook: connect: connection refused"
May 13 10:09:40 deskmini alertmanager[767]: ts=2023-05-13T02:09:40.869Z caller=notify.go:732 level=warn component=dispatcher receiver=web.hook integration=webhook[0] msg="Notify attempt failed, will retry later" attempts=1 err="Post \"http://192.168.50.134:8888/webhook\": dial tcp http://192.168.50.134:8888/webhook: connect: connection refused"
  • 至此,alertmanager的部署和配置就完成了,也初步验证过基本功能都是正常的,下一篇咱们一起动手开发web服务,达到最终目标:应用服务器CPU偏高的时候,飞书APP收到告警
本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2023-05-13,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
prometheus实战之五:飞书通知告警
程序员欣宸
2023/05/27
4.1K0
prometheus实战之五:飞书通知告警
prometheus实战之一:用ansible部署
欢迎访问我的GitHub 这里分类和汇总了欣宸的全部原创(含配套源码):https://github.com/zq2599/blog_demos 关于《prometheus实战》 《prometheus实战》是欣宸原创的系列文章,旨在通过实战操作来熟悉和掌握prometheus常规技能 本篇概览 本文是《prometheus实战》的开篇,咱们先把环境搭好,为后面的学习做好准备 为了简化操作,咱们就把环境规划得简单一些,如下图,准备两台Linux电脑(或者虚拟机),一台只部署prometheus,另一台
程序员欣宸
2023/05/03
6730
prometheus实战之一:用ansible部署
Prometheus安装部署+监控+绘图+告警
查看监控数据(https://grafana.com/dashboards/9276)
DevOps云学堂
2019/10/18
1.1K0
Prometheus安装部署+监控+绘图+告警
Prometheus 基础入门 (一)
Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB)。Prometheus使用Go语言开发,是Google BorgMon监控系统的开源版本。2016年由Google发起Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation), 将Prometheus纳入其下第二大开源项目。Prometheus和Heapster(Heapster是K8S的一个子项目,用于获取集群的性能数据。)相比功能更完善、更全面。
Kevin song
2023/02/09
1.4K0
Prometheus 基础入门 (一)
Prometheus监控规则与告警实践
有了上一个篇博文(prometheus部署与体验)的数据之后我们就可以进入告警规则的学习了。Prometheus 进程内置了告警判断引擎,prometheus.yml 中可以指定告警规则配置文件。
五分钟学SRE
2023/11/21
1.4K1
Prometheus监控规则与告警实践
Prometheus 监控报警系统 AlertManager 之邮件告警
注意:这里为了快速方便启动 Prometheus、Alertmanager、Node-Exporter 服务,我使用 Docker 方式启动,所以本机需要安装好 Docker 环境,这里忽略 Docker 的安装过程,着重介绍一下如何启动并配置 Prometheus 监控报警系统 集成 AlertManager,并配置 Email 发送告警信息。
哎_小羊
2019/08/14
7.4K0
思考:prometheus 告警为什么选用alertmanager?
alertmanager 主要用于接收 Prometheus 发送的告警信息,它支持多种告警通知渠道,而且很容易做到告警信息进行去重,降噪,分组等,超级好用。
猿天地
2021/03/13
3K0
实战 Prometheus 搭建监控系统
Prometheus 是一款基于时序数据库的开源监控告警系统,说起 Prometheus 则不得不提 SoundCloud,这是一个在线音乐分享的平台,类似于做视频分享的 YouTube,由于他们在微服务架构的道路上越走越远,出现了成百上千的服务,使用传统的监控系统 StatsD 和 Graphite 存在大量的局限性,于是他们在 2012 年开始着手开发一套全新的监控系统。Prometheus 的原作者是 Matt T. Proud,他也是在 2012 年加入 SoundCloud 的,实际上,在加入 SoundCloud 之前,Matt 一直就职于 Google,他从 Google 的集群管理器 Borg 和它的监控系统 Borgmon 中获取灵感,开发了开源的监控系统 Prometheus,和 Google 的很多项目一样,使用的编程语言是 Go。
Spark学习技巧
2021/03/05
1.3K0
实战 Prometheus 搭建监控系统
从零搭建Prometheus监控报警系统
Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB)。Prometheus使用Go语言开发,是Google BorgMon监控系统的开源版本。 2016年由Google发起Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation), 将Prometheus纳入其下第二大开源项目。 Prometheus目前在开源社区相当活跃。 Prometheus和Heapster(Heapster是K8S的一个子项目,用于获取集群的性能数据。)相比功能更完善、更全面。Prometheus性能也足够支撑上万台规模的集群。
kubernetes中文社区
2019/09/04
1.9K0
从零搭建Prometheus监控报警系统
构建企业级监控平台系列(二十):Prometheus Alertmanager 配置实现钉钉告警
前面介绍了 Prometheus Server配置、Operator、Exporter 、Node Exporter、标签 label、PromQL、AlertManager等相关的知识点,今天我将详细的为大家介绍Prometheus Alertmanager 配置实现钉钉告警相关知识,希望大家能够从中收获多多!如有帮助,请点在看、转发朋友圈支持一波!!!
民工哥
2023/10/27
6620
构建企业级监控平台系列(二十):Prometheus Alertmanager 配置实现钉钉告警
Alertmanager 安装与使用
Alertmanager是一个独立的告警模块,接收Prometheus等客户端发来的警报,之后通过分组、删除重复等处理,并将它们通过路由发送给正确的接收器;告警方式可以按照不同的规则发送给不同的模块负责人,Alertmanager支持Email, Slack,等告警方式, 也可以通过webhook接入钉钉等国内IM工具。
py3study
2020/07/23
5.5K0
从零搭建Prometheus监控报警系统
Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB)。Prometheus使用Go语言开发,是Google BorgMon监控系统的开源版本。 2016年由Google发起Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation), 将Prometheus纳入其下第二大开源项目。 Prometheus目前在开源社区相当活跃。 Prometheus和Heapster(Heapster是K8S的一个子项目,用于获取集群的性能数据。)相比功能更完善、更全面。Prometheus性能也足够支撑上万台规模的集群。
星哥玩云
2022/06/07
1.1K0
从零搭建Prometheus监控报警系统
Prometheus Alertmanager生产配置趟过的坑总结
Alertmanager[1] 处理由客户端应用程序(如 Prometheus server)发送的警报。它负责去重(deduplicating),分组(grouping),并将它们路由(routing)到正确的接收器(receiver)集成,如电子邮件,微信,或钉钉。它还负责处理警报的静默/屏蔽(silencing)、定时发送/不发送(Mute)和抑制(inhibition)问题。
东风微鸣
2022/12/01
1.1K0
Prometheus Alertmanager生产配置趟过的坑总结
Prometheus Alertmanager 告警集成(三)
Prometheus自身不具备告警能力,需要结合AlertManager实现监控指标告警。由Prometheus配置告警规则,当告警规则触发后,会把告警信息推送给Altermanager,AlertManager收到告警之后在根据配置的路由,根据报警级别不同分别发送给不同的receive(收件人),AlertManager可以实现email、企业微信、钉钉等报警。Prometheus作为客户端,Alertmanager负责处理来自客户端的告警通知。对告警通知进行分组、去重后,根据路由规则将其路由到不同的receiver。
Kevin song
2023/02/14
3.1K1
Prometheus  Alertmanager 告警集成(三)
使用Docker部署Prometheus实现微信邮件报警
从上图可以看出,Prometheus的主要模块包括:Prometheus server,exporters,Pushgateway,PromQL,Alertmanager以及图形界面。
肉眼品世界
2020/11/11
1.2K0
使用Docker部署Prometheus实现微信邮件报警
kubernetes(k8s) Prometheus+grafana监控告警安装部署
主机数据的采集是集群监控的基础;外部模块收集各个主机采集到的数据分析就能对整个集群完成监控和告警等功能。一般主机数据采集和对外提供数据使用cAdvisor 和node-exporter等工具。
sunsky
2020/08/20
4.6K0
kubernetes(k8s) Prometheus+grafana监控告警安装部署
prometheus监控、告警与存储
github地址:https://github.com/kubernetes/kube-state-metrics (opens new window)
章工运维
2023/05/19
1.9K0
prometheus监控、告警与存储
prometheus alertmanager 部署监控(二)
上回已经讲好快速部署prometheus alertmanager 这回接着如果配置报警,本文我主要以接入mysql报警为案例 进行全面的讲解 软加载监控报警
怀朔
2022/05/25
4580
prometheus alertmanager 部署监控(二)
prometheus (六) Alertmanager
基于 centos7.9 docker-ce-20.10.18 kubelet-1.22.3-0 kube-prometheus-0.10 prometheus-v2.32.1
Amadeus
2023/05/03
1.1K0
prometheus (六) Alertmanager
Prometheus监控神器-Alertmanager篇(1)
警报一直是整个监控系统中的重要组成部分,Prometheus监控系统中,采集与警报是分离的。警报规则在 Prometheus 定义,警报规则触发以后,才会将信息转发到给独立的组件
Kubernetes技术栈
2020/08/06
1.4K0
Prometheus监控神器-Alertmanager篇(1)
相关推荐
prometheus实战之五:飞书通知告警
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验