分析日志的技巧 – 搞英语 → 看世界

你好！一段时间以来，我一直在努力写一本关于调试的杂志（我们快要完成了！！！！），其中一页是关于分析日志的。我询问了一些关于 Mastodon 的提示，得到的提示远远超出了页面所能容纳的范围，所以我想我应该写一篇简短的博文。

我将在分布式系统调试的上下文中讨论日志分析（你有一堆具有不同日志文件的服务器，你需要弄清楚发生了什么）因为这是我最熟悉的。

通常日志行会包含一个请求 ID。因此，搜索失败请求的请求 ID 将显示该请求的所有日志行。

这是减少事情的好方法，也是我得到的关于分布式系统调试的第一个有用的技巧之一——我盯着仪表板上的一堆图表徒劳地试图找到模式，一位同事给了我建议（ “julia，尝试查看失败请求的日志！”）。在那种情况下，事实证明这更有效。

有时一组日志没有您需要的信息，但您可以从不同服务的关于同一请求的日志中获取该信息。

如果幸运的话，他们会共享一个请求 ID。

更常见的是，您需要根据线索和请求的时间戳手动拼凑上下文。

这真的很烦人，但我发现这通常是值得的，并且让我获得了一条关键信息。

如果您尝试根据时间关联事件，则需要注意以下几点：

将所有信息直接记在脑海中会让人非常困惑，因此我发现保留一份调试文档在我复制和粘贴信息位的地方很有帮助。

这可能包括：

有时我会重新格式化日志行以仅打印出我感兴趣的信息，以便于扫描。我在命令行上用一个简单的awk命令完成了这个：

 cat ... | awk '{print $5 - $8}'

还可以使用精美的日志分析工具（如 Splunk），让您在网络上制作表格

有时我会注意到日志中的可疑错误并想“哦，这就是罪魁祸首！！！”。但是当我搜索该消息以确保它确实是新的时，我会发现这个错误实际上在正常操作期间不断发生，并且它与我正在处理的（新）情况完全无关。

一些日志分析工具可以让您将日志行转换为图形以检测模式。

您还可以使用grep和sort制作快速直方图。例如，我经常做类似的事情：

 grep -o (some regex) | sort | uniq -c | sort -n

计算每行中有多少匹配我的正则表达式

您可以像这样使用grep删除不相关的行：

 cat file | grep -v THING1 | grep -v THING2 | grep -v THING3 | grep -v THING4

对于回复的人：是的，我们都知道你不需要在这里使用cat 🙂

或者，如果您的日志系统有某种查询语言，您可以搜索NOT THING1 AND NOT THING2 ...

通常一个错误会导致大量相关错误。深入研究后面的错误可能会浪费你很多时间——你需要从找到触发错误的第一件事开始。通常您不需要了解为什么错误级联中的第 15 件事失败的确切原因，您可以只修复原始问题并继续前进。

如果您已经对这项服务的日志行通常应该是什么样子有了直觉，有时快速滚动它们会发现一些看起来不对劲的东西。

有时调高日志级别会给你一个解释一切的关键错误信息。

但有时，您会被一百万条不相关的消息淹没，因为日志级别设置为INFO ，您需要降低日志级别。

我自己从来没有尝试过这个，但是有几个人建议将部分日志复制到电子表格中（时间戳在不同的列中）以便更容易过滤/排序。

如果有任何遗漏，请在 Twitter/Mastodon 上告诉我！我可能会编辑它以添加更多内容。