【开发日常】日志报警和数据流报警

开发中的日志报警和数据流报警

没有最好的，只有最合适的…

最近团队总结会议增加了一个吐槽的环节，可以把自己平时在工作中不满意的地方集中吐槽出来，然后收集起来，排名前三的吐槽点可以在下周计划会议中优先讨论解决。（P.S. 如果真的能够利用好这一环节的话，对整个团队带来的价值还是相当可观的）

这周我抛出的一个问题就是题目中的报警。

由于团队一开始计划就是采用分模块、CI/CD 的方式开发、部署、迭代，所以整个产品被切分为好多小模块并且docker化，使用 k8s 管理，各个模块之间通过 http 和 kafka 的方式串联起来，采集数据流入、处理、保存、最终以 web 和 API 的方式输出给用户。

产品部署在 开发、测试、demo、生产 四个大环境。

监控报警方面呢，团队采用的监控报警方式是以 特定输入 和 得到预期的输出 方式来设计开发的，忽略中间所有数据处理过程。这倒也是个简单有效的思路。然后监控到问题会分级别以邮件、电话的形式通知给 group 中的人员。

然后问题来了：

1. 邮件客户端撑爆了。测试、demo、生产 三个环境中，不管是 数据超时、数据恢复、数据断流、还是其它，每天成百上千封的邮件破天盖地而来，怕不怕！一开始认真看一下报警信息，时间一久，完全成了体力活，除非每天筛选删除邮件，不然邮箱客户端会越来越慢，最终这种报警泛滥的方式让我关掉了邮件客户端，整个世界清静了，专心开发，严重问题自然会有人来专门通知！
2. 问题排查困难。由于设计的缺陷，并没有考虑打印日志信息和级别，导致排查问题异常困难。比如：数据流数据丢失问题，没有返回数据，得到的报警信息就是某数据没得到输出，其中数据会经过好多数据流的小模块，而且 有的模块 log 信息都没有（这个玩笑开的有点大），没办法第一时间定位到问题，只能硬着头皮重新花费时间重现问题，翻阅前人源码来认真调试查找问题（说多了都是泪）。
3. 破窗原理。引发一系列其他问题。

抛出问题，没有解决方案的码农不是好的程序员。

首先，需要定义一套日志规范，尤其是日志级别、关键信息要明确；
然后，添加日志和数据流监控结合的方式，可以监控数据流健康，也可以根据日志快速定位问题，快速解决问题；
最后，报警消息对应 group 组的粒度细分，拒绝报警消息泛滥。

(仅以此献给每一个一线研发人员)

---

—2019-11-30—