做好监控告警的关键技巧

在《线上监控怎么做？》一文中我们探讨了做好监控的一些技巧和陷阱，本文则主要探讨做好告警的一些重要技巧。

1. 根据告警类型慎重选择告警渠道

发送告警尽量不要用邮件告警，要根据告警类型慎重选择告警渠道。
告警一般属于三种类型：
1）要求立即采取响应/行动：这类告警适用于发送到随身通信设备，如短信告警、电话告警；
2）需要知晓，但不需要立即采取行动：这类告警可以发送到内部聊天工具上，以便于后期回顾。也可以选择发送到邮件告警，但是要注意邮件分类与通知处理，因为这类告警很容易被邮件淹没、忽视；
3）记录下来用于问题回顾/诊断：这类信息可记录到日志日中，方便对它们进行分析、报告；

2. 撰写系统运行手册

在一套复杂的环境中，并非团队中的所有人都了解每套系统，一份优秀的运行手册是为一个特定的服务而撰写的。运行手册有助于快速定位告警发生的位置，它回答了下列的问题：

• 这是什么服务，这个服务做什么的？
• 谁负责这个服务？
• 这个服务有什么依赖关系？
• 它的基础设施什么样？
• 它会产生什么样的指标以及日志，这些指标和日志的含义是什么？
• 应该为它设置哪些告警，为什么要设置这些告警？

当有人响应告警时，翻开运行手册就会了解发生了什么、告警的含义以及恢复告警的方向。
但不是每一条告警都需要运行手册，复杂重要的、需要人来诊断和修复的问题才需要用到运行手册。

3. 经常重新评估告警，持续优化

告警要适度，过少的告警，会容易让人产生懈怠心理，忽略系统的一些重要问题；过多的告警，会容易让人产生告警疲劳。
我们可以从以下几方面着手时常回顾、分析、优化自己的告警：

1）是不是所有的告警都需要有人响应？
2）回顾过去一个月或一个季度的告警历史，看看它们是什么告警？响应是什么？每个告警的影响是什么？有没有可以直接删除的告警？可否修改阈值？可否修改底层监控方案让告警更加精确？
3）可以创建哪些自动化的工具以便于彻底弃用某个告警？

4. 发送告警前先尝试自我恢复

有一些告警不一定需要人为干预，可以自我恢复。例如在检测到监控指标达到某个值时，就触发执行对应的脚本处理。
举个简单的例子：磁盘使用达到85%，就调用磁盘清理脚本清理磁盘。

5. 调整告警，提升on-call体验

你在on-call时，是否有过这样的经历：

1）在on-call期间收到很多告警信息，你以为系统出现故障了，但一经与告警对应的系统业务负责人核实，对方告诉你这是他设置的常规告警，只要指标超过这个值就会发送告警，不用管它。这样的告警，真的会让人很厌恶。
2）每次on-call，都会遇到系统出现故障，on-call=应急。

以上两种，都不是正常的，需要调整优化：

1）修正假报警。常规的、偶然出现又不影响系统运行的告警，是否可以考虑设置告警抖动，减少告警次数，降低真正告警被淹没的风险。
2）推动系统稳定性和弹性建设。提升系统的代码质量和业务稳定性，建立系统紧急收缩与弹性，非常有助于降低“救火”频率，大大提升on-call体验。
3）制定更好的on-call排班计划。on-call排班应注意劳逸结合，避免长时间处于on-call状态。

同时，一个系统的on-call值班，不仅应包含SRE，还应包含研发工程师与测试工程师一起轮值on-call。因为只有研发、测试、运维三个岗位都参与on-call值班，才能在某些情况下产生“共鸣”。
只有当研发自己意识到了on-call值班带来的烦恼，才会激励他们提升自己的代码质量，研发出更好的软件；
只有测试工程师参与了on-call值班救火，才能激励他们在系统上线之前做好充分的测试工作；
SRE被on-call救火所累，才会更加坚守版本上线的风险把控，做好系统冗余与容量控制等系统稳定性工作。
一个系统的稳定性，需要每一个岗位的同事一起参与、努力。

6. 改进告警阈值

很多的告警阈值是静态阈值，如这样一条告警：“磁盘使用率超过了90%”。给出的信息就是磁盘使用率达到90%了，但是体现不出来是否存在哪个时间段磁盘使用出现了暴涨的情况。

使用一些动态的告警阈值，如百分比变化，可以提示我们类似“一夜之间磁盘使用率增长了50%”这种清理，这样可以更加方便快速找到磁盘使用率告警的原因，是正常的使用量达到了阈值，还是出现了异常情况。

7. 系统维护期告警

在对系统进行变更维护操作时，所涉及到的监控肯定会触发告警，如果团队中的人不清楚情况，他们肯定会怀疑系统出现了问题。
因此在系统变更维护时，尽量停掉相关的告警，因为这时候的告警其实没有意义。如不方便停掉告警，也请将系统维护告警的信息知会到团队中相关的同事，以免引起不必要的误会。