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

工作记录

今天是2021年8🈷️19日，星期四，线上办公第1⃣️3⃣️天
今天下午学校终于发开学通知了，8月30号正式上课啦🤗

任务清单

今天注定是写配置文件的一天，我在博客里记录我写博客，哈哈哈哈😆😆
话不能这么说，下午在写到alertmanager.yml配置文件时，由于对个别参数还拿不准，所以下午就做了个实验，把配置参数 group_interval肚里的花花肠子给捋明白了，下面咱就看看这货葫芦里到底是个啥子药🧐

任务记录

group_interval参数——我要撕开你的面纱
先说一下我的实验前提：
group_wait: 5s
group_interval: 5m
resolve_timeout: 5m
repeat_interval: 10m
报警载体：飞书webhook机器人🤖️

来吧，咱们正片开始：
假设有A与B两个报警，且A与B同属于一组警报，经过实验发现，若先触发A警报，并且在超过A警报的 for时间后，再触发B警报，那么从A警报开始发出的时间点算起，经过 group_interval时间后，A与B警报放在一起共同发出，如果这期间警报一直未恢复，则相隔 repeat_interval + group_interval时间后警报再次发出。
好，我们再往前走走：
1⃣️如果B的警报已被修复，而A的还没有修复，那么以上一次飞书发出报警信息的时间为起始时间，向后推 resolve_timeout后发出警报（除了第一次单独A发出警报消息，其余所有警报消息均为A与B合在一起发送）

👆只是个基本情况，如果你觉得这就完了，那可就错过了一个亿呦，👇进入高潮～

2⃣️玩个好玩的，玩着玩着就钻出了个光头：
我们知道，如果警报一直未恢复，则相隔 repeat_interval + group_interval时间后警报再次发出，而且知道如果B的警报已被修复，而A的还没有修复，那么以上一次飞书发出报警信息的时间为起始时间，向后推 resolve_timeout后发出警报。好，知道这些后。我们在超过 resolve_timeout而不超过 repeat_interval + group_interval时间之间修复报警B，准确是在上一个发送时间后的第7分钟修复的。你猜怎么着，报警恢复的消息居然是距离上次发送消息后的10分钟推送的，在第11分钟时，我又修复了报警A，报警A的修复信息在第15分钟精确的发送了出来
so，🤨，由此我们知道两件事：
①如果不涉及中间部分报警恢复问题，假设只有一个报警的话，如果长时间不恢复它，首先它会先经过 repeat_interval时间，再经过 group_interval时间才会重新发送
②if 0 < 报警的恢复时间 < resolve_timeout，则在 resolve_timeout时间点恢复，
if resolve_timeout < 报警的恢复时间 < repeat_interval，则在 repeat_interval时间点恢复
if repeat_interval < 报警的恢复时间 < repeat_interval + group_interval，则在 repeat_interval + group_interval时间点恢复

总结

今天基本都在写配置文档了，对知识的总结就是会激发更多的学习，通过对今天的问题的实验，我终于搞明白其中的道理了。
哈哈哈，明天继续加油干🏎🚗🚌🛵🚲🦽☁️⛽️