记录我在区块链互联网公司的实习生活Day25

今天是8月16日&＃xff0c;星期一&＃xff0c;线上办公第&＃x1f51f;天&＃xff0c;隐隐约约感觉要解封啦&＃xff0c;&＃x1f619;

任务清单

今天的任务只有一个主题——深入研究alertmanager的配置

任务记录

深入研究alertmanager的配置
研究到哪就写到哪吧&＃xff0c;如果公司没有分配给我新的工作&＃xff0c;那这周基本都在这上面了。
今天看了很多的文章&＃xff0c;有官方文档也有大佬们写的博客&＃xff0c;无外乎就在研究两个问题&＃xff0c;一个是路由配置&＃xff0c;一个是报警时间相关的问题

1⃣️&＃xff1a;路由配置
配置目的&＃xff1a;
满足多元化的监控报警要求&＃xff0c;比如说区块链方面的报警传给前端的同事&＃xff0c;服务器性能方面的报警则要传给运维工作人员&＃xff08;是的&＃xff0c;就是我&＃x1f920;&＃xff09;

怎么配置&＃xff1a;
下面是alertmanager.yml文件具体内容&＃xff1a;

global:resolve_timeout: 5m# default is 5mroute:group_by: [&＃39;alert&＃39;] # 与rules.yml中的group name保持一致&＃xff0c;表示 &＃96;alert&＃96;组中的警告都使用下面的路由发送group_wait: 5s # 发出警报后等待同组警报的时间group_interval: 5m # 告警时间间隔repeat_interval: 10m # 重复发送报警的时间间隔receiver: &＃39;default&＃39; # 默认根路由的接受者routes: # 子路由- receiver: &＃39;blockchain_Alert&＃39;match:project: blockchain # match匹配rules.yml文件里label定义的project&＃xff0c;project为blockchain的警报发往 &＃96;blockchain_Alert&＃96;接受者- receiver: &＃39;performance_Alert&＃39;match: # match匹配&＃xff0c;与上面的意思相同project: performancereceivers: # 各项接受者的具体配置&＃xff0c;其中决定了警报究竟去哪里
- name: &＃39;default&＃39; # 匹配receiver为‘default’的alert通过webhook发送至下面的urlwebhook_configs: - url: &＃39;http://xx.xx...&＃39;- name: &＃39;performance_Alert&＃39; # 与上面的说明一样&＃xff0c;但可以把alert传给两个不同的urlwebhook_configs:- url: &＃39;http://xx.xx...&＃39;- url: &＃39;http://xx.xx...&＃39;- name: &＃39;blockchain_Alert&＃39; # 上同啦webhook_configs:- url: &＃39;http://xx.xx...&＃39;# inhibit_rules:
# - source_match:
# severity: &＃39;critical&＃39;
# target_match:
# severity: &＃39;warning&＃39;
# equal: [&＃39;alertname&＃39;, &＃39;dev&＃39;, &＃39;instance&＃39;]


在alertmanager的路由配置中&＃xff0c;一般是由一个根路由&＃xff08;root route&＃xff09;后接若干个子路由&＃xff08;child root&＃xff09;组成&＃xff0c;当然你可以只写一个路由&＃xff0c;但考虑到日后监控报警工作的多元化&＃xff0c;因此强烈建议设置成多个子路由的形式&＃xff0c;方便后面的管理。

为了搭配alertmanager.yml文件的正常运行&＃xff0c;所以rules.yml要设置成下面这个样子&＃xff1a;

group:
- name: &＃39;alert&＃39; # 与alertmanager.yml文件中参数group_by后面的字符串保持一致&＃xff0c;同时说明以下两个alert属于同一个组&＃39;alert&＃39;rules:- alert: PrometheusTargetMissingexpr: up &＃61;&＃61; 0for: 10slabels:level: mediumproject: performance # 此处为文件alertmanager.yml中match的匹配依据annotations:description: "A Prometheus target {{$labels.job}} has disappeared. It might be crashed."- alert: BlockchainProblem_Testexpr: delta(substrate_block_height{status&＃61;"best"}[20s]) >&＃61; 2for: 0slabels:level: testproject: blockchain # 同上&＃xff0c;此处为文件alertmanager.yml中match的匹配依据annotations:description: "The change of the block height(best) within 20 seconds is greater than or equal to 2"


这么一路配置下来&＃xff0c;就能正常运行报警系统了

2⃣️&＃xff1a;报警时机&＃xff08;报警时间&＃xff09;的理解
配置目的&＃xff1a;
对alert进行实时准确的报警

具体理解&＃xff1a;
一个经典的例子如下所示&＃xff1a;

cd prometheus-2.28.1.linux-amd64/ | vim prometheus.yml
# prometheus.yml的配置大致如下global:scrape_interval: 20sevaluation_interval: 1m# -- snip --vim rules.yml
# rules.yml的关键配置如下# 此处语法大家不必较真&＃xff0c;只是个例子
ALERT NODE_LOAD_1MIF node_load1 > 20FOR 1m
# -- snip --


那么请问&＃xff0c;触发JobMissing警报所用的时间为多少&＃xff1f;&＃x1f928;
是个好问题&＃xff0c;一开始我也没有琢磨出来&＃xff0c;这也是我一直想知道的
分析这个问题应该从下面的图看起&＃xff1a;

结合下面的分析&＃xff0c;大家可以慢慢推敲出答案&＃xff1a;

1. The load of a node constantly changes, but it gets scraped by Prometheus every scrape_interval (ie. 20s)
2. Alert rules are then evaluated against the scraped metrics every evaluation_interval (ie. 1m)
3. When an alert rule expression is true (ie. node_load1 > 20), the alert switches to pending, in order to honor the FOR clause
4. At the next evaluation cycles, if the alert expression is still true, once the FOR clause is honored the alert finally switches to firing and a notification is pushed to the alert manager

公布一下答案&＃xff1a;it takes a time between 1m and 20s &＃43; 1m &＃43; 1m.

把原文挂出来分享给大家&＃xff1a;Prometheus: understanding the delays on alerting
这还有个中文翻译的版本&＃xff1a;多久可以收到prometheus的告警&＃xff1f;

通过今天的学习&＃xff0c;对alertmanager的配置又有了一个更深入的了解&＃xff0c;我的第二个项目又能升级一下啦。
明天继续加油研究&＃xff0c;顺便和师哥交流一下今天的进度&＃xff0c;继续升级我的项目&＃x1f604;