最近行业里流行降本增效。本文就一个现实中经常发生的日志成本的案例进行讨论，讨论该如何降本。

背景

假如存在一家IoT公司，它拥有1亿的在线设备（长连接着云端）。这些设备每21秒会向云端发送心跳，以进行连接的保活。假如1次连接的保活，在云端产生1条日志，那么1台设备1天产生的日志量是：24 * 60 * 60 / 21 = 4114条，假设1条日志100字节，所以：

• 1台设备1天保活日志数：24 * 60 * 60 / 21 = 4114条
• 1条日志占用100字节，1台设备1天产生保活日志：4114 * 100 = 411400byte
• 1天内1亿的设备产生日志：411400 * 100000000 ≈ 37.4T

我们来看下该保活日志内容： 2021-02-12:12:32:12 application-abc-prod INFO com.platform.cloud.impl keep alive, deviceId:1a2b3b3p8

从日志内容来看，没有什么“营养”，纯粹是为方便程序员debug。

这是问题吗？

一行没有营养的日志每天产生37.4T的日志，是个问题吗？对谁是个问题？

对于写那行代码的人来说，并不是问题，因为日志量大小本身并不是他的KPI。

对于运维可能是个问题，因为他们可能因此需要增加存储服务扩容的工作。但是从另一个方面来看不是个问题，因为他们有借口招更多的人。

对于大数据团队可能是个问题，因为他们发现数据清洗pipeline比之前更慢了，进而导致每日报表都被延迟了。但是从另一个角度来看不是个问题，因为这是一个表现的机会——在人员不变的情况下优化清洗速度的机会。

这对于关心成本的人来说是个问题。谁关心成本呢？这不是本文讨论的话题。

如何面对问题？

事后面对

事后面对指的是事情已经发生了，即大量无用配置已经产生了。只能采取补救止血措施。

作为运维，需要对于日志量进行多维度监控与告警。可以包括以下维度：

• 应用维度
• 实例维度
• 设备维度：部分设备可能有Bug，会死循环会不停进行连接请求

告警内容可以包括：

• 进行环比对比，出现突增
• 进行环比对比，突降

在收到告警后，找到相应的应用的owner，让其检查日志是否合理，不合理则需要制定改进措施。

同时，每周都向相应的owner发送日志量报告，让其了解当前生产环境的日志量情况。

Code Review时面对

Code Review时，有经验的人会看出日志问题，但是这种方式并不可靠。

写代码时，就避免

指的是在程序员写在log.info("无营养日志")的那一时刻，IDE就提醒程序员：这行日志每日将产生4114条日志，将占所有日志总量的80%，请注意！

当然，除了在IDE时提醒，我们可以在Code Review时，review机器人自动对该行代码进行评论。

这个实现起来难度会比较大。

但是并不是没有思路。笔者的思路如下，仅供参考，欢迎交流：

我们要知道，只有被请求到API，API执行时，被执行到的代码才会打日志。所以，只要能知道打日志的代码在过去一段时间内，在生产环境的相应的API被请求了多少次，我们就可以预测到增加1行日志会增加多少日志了。进而在IDE里提示，或者Code Review进行评论。

而对于那些完全新增的API，就没有办法预测了，因为没有历史纪录。

以上只是思路，具体实现方法今后有机会实现再说。

小结

日志成本通常不会被人留意。它通常就一个人身上的慢性病，时间长了，谁知道会发展什么样呢？

进行日志降本的最简单的办法就是增加对于日志量的监控与告警。个人认为在写下那行打日志的代码进行干预才是终极方案。

Last modified on 2023-04-22