我遵循的日志记录实践 - 16elt

无论您正在开发哪种软件，您肯定会在某种程度上利用日志记录，可能每天都在使用。你写了很多日志，你也读了很多日志，这是我们拥有的最基本的可观察性工具。

不是所有的日志都是应该记录的
有许多陷阱会导致无用、浪费和混乱的日志。因此，我遵循一组特定的实践，这些实践使我能够编写更好的日志，同时在整个系统中保持一致。你应该记住，日志记录是为开发人员准备的，你将是唯一一个阅读它们的人，所以当你要记录一些东西时，问问自己：

• 这个日志真的需要吗？它是否依赖于我无法从同一流程中的其他日志中获得的重要信息？
• 我要记录一个在生产中可能很大的对象吗？如果是这样，我可以只记录该对象的一些指标吗？例如，它的长度，或者挑选一些重要的属性来记录。
• 我将要记录的信息是否有助于我调试/理解流程？

如何记录？
首先，令人惊讶的是，经验法则并不那么明显，我会说您应该使您的日志在整个系统中保持一致。一致性导致可预测性，这会导致您在查找日志时不必总是查看它们的定义方式。

1、日志级别
每当您编写日志时，选择正确的日志级别很重要。我个人主要使用 ERROR、WARNING、INFO 或 DEBUG（是的，还有更多）。
日志级别 TLDR

• 错误：部分流程失败，我们希望就此失败向我们的值班人员发送警报。
• 警告：不一定表示失败，而是应该调查的意外行为。
• INFO：记录流程中的主要事件，以帮助阅读它的开发人员了解正在执行的内容。
• DEBUG：与 INFO 类似，但更详细，包括对对象、数据结构等的检查。

2、记录节俭
无论您使用什么服务进行日志记录，都需要花钱，而快速烧钱的方法是记录整个 json 对象，该对象在您的开发环境中相对较小，但在生产环境中会爆炸。

巨大的对象日志没有帮助，很难阅读它们。巨大的对象日志在那里，因为它更容易投入一切，而不是思考什么是最重要/有用的属性来记录。巨大的对象日志将花费你很多钱，这取决于你的规模。
我们以 AWS CloudWatch 服务为例，目前日志摄取的价格是每 GB 0.5 美元。每次调用流程时，您都会为所有 1000 个客户记录那个巨大的 json，您已经每月为那个 json 日志单独支付几千美元。

你应该怎么做？

• 选择对记录最重要和最有用的属性，这些属性将实际帮助您调试流程的继续。
• 有时，您只需要知道对象是否为空，只需记录它——而不是整个对象。

3、日志唯一性
系统中的每条日志消息都应该是唯一的。如果我在特定服务中查询日志，我会很困惑地看到服务内不同流的完全相同的日志。更重要的是，我只需要开始调试这个问题，因为日志现在正式无用了。

保持日志唯一性的一种方法是将服务名称和函数名称表示为日志的前缀，如果这样做 - 可以保证唯一性，或者至少可以将日志复制的范围从整个服务缩小到只是一个功能。

网友讨论：
1、(从JVM的角度来看...)

我们发现，把日志看作是发生在应用程序内部的有趣事件的流，并把框架作为你的代码的第一类公民来输出，是完全有益的--这意味着永远不要依赖全局单项，而是使用一个已知的事件接口，通过构造函数注入来传递。这也允许你为你的事件编写测试，并轻松地将它们与收集指标的系统挂钩，或从测试和构建管道中创建自动的生活文档。

还建议尽量减少日志记录，永远不要依赖随机的（由人类组成的）非结构化信息，使用结构化的日志记录（通常通过JSON或类似的）是你的朋友，还有严格的类型和命名的事件对象--这允许你使用许多不同的工具来查询日志的特定匹配字段，而不用求助于野生的重码模式，当有人进入并纠正你的语法时，会意外地改变（当然，你只有在凌晨3点出错时才会发现）。

控制日志格式还可以让你控制敏感值（PII）的输出，这对防止日志刮擦攻击至关重要--我曾经看到过一个聪明的Splunk查询，它刮擦了一家银行的日志，查询出有最多入账的人的姓名和账号。那是相当可怕的!

编辑：主题中还有人提到了分布式跟踪，这也会给你的日志带来超能力（特别是当与APM工具结合时）。对于http来说，X-B3追踪/span头信息是很好的，添加起来相当便宜，但希望OpenTelemetry会足够成熟，以使一个更强大的跨技术标准。

2、良好的日志记录绝对是一门艺术，这些是一些很好的原则。日志级别的良好使用对我来说很重要，尽管在调试级别使日志过于嘈杂很容易，这会大大降低效率。
我主要在 Web 开发的前端工作，其中许多业务逻辑（以及因此可能出错的大部分地方）都移到了后端。有一些工具可以将前端日志发送到某个地方，但由于它最终出现在浏览器开发工具中，因此很容易泄露实现细节。

3、在过去的 10 年里，整个行业如雨后春笋般涌现，致力于让非开发人员更容易使用和理解日志。Splunk 和 ELK 等大型企业工具专门用于让其他人可以阅读日志。似乎是一个很大的疏忽。