阅读日志文件可能会非常令人沮丧，因为从本质上讲，它们的内容不仅反映了问题本身，也反映了编写它们的开发人员的情况。
你有什么一般用途解释错误日志的技巧（例如：“google 是你的朋友”或“一些错误代码比其他情况发生得更多”或“记住警告和错误是非常不同的”）？
答案1
让开发人员偶尔排除生产问题。这将为您的日志记录带来奇迹。:)
答案2
当您同时遇到以下所有情况时，会出现一种特定的常见情况：（1）分布式环境中的问题（2）大量的调试信息分散在协作服务器和不同的日志文件中（3）没有用于解释日志的文档（4）谷歌上没有任何内容（5）没有线索（6）乒乓球运动员而不是供应商的支持。
- 首先，确保整个环境的时间是同步的（ntp）。如果不是，就别想从日志文件中找出主机间的关系了。
- 不要从随机日志中挑选随机“错误”来责怪。按时间顺序阅读日志，记住“错误”行可能是正常软件操作的结果，并且一直存在。
- 将正确操作的日志与问题情况的日志进行比较。它们在什么时候不再匹配？（vimdiff 可能有用）
- 如果在测试用例期间您可以插入自己的自定义日志消息，请使用它。（如 syslog 中的记录器）
- 在分析时，如果您发现自己在许多巨大的日志之间来回切换，试图捕捉操作流程 - 尝试合并日志。（使用 sed 将时间放在第一列。使用 cat+sort 合并多个文件。当然还有 grep -viE 用于过滤不必要的行。）
答案3
我处理服务器日志的习惯是：定期查看它们，并调查/解决我发现的问题。我会主动这样做 - 而不是等到用户抱怨系统中断。这种方法之所以有效，主要原因可以归结为几句老话：
小洞不补，大洞吃苦。 显然，如果您在问题还小的时候就解决问题，那么您就走在了前面，用户/管理层就没有理由对您大喊大叫了；这是一件好事。
熟能生巧。 我认为这是系统管理员的一大优势。通过定期主动阅读日志，您可以获得经验和熟悉度。您将了解这些神秘的日志消息的含义 - 哪些是微不足道的，哪些是大事。调查您无法立即理解的消息（一开始会有很多！）的过程可以让您了解操作系统及其上运行的应用程序的内部情况。
通常当我管理一个新系统时，日志中会有相当多的错误，其中许多错误相当频繁地重复出现。前任管理员经常会耸耸肩，说“不太清楚那是什么，但用户从未抱怨过，所以我认为它还没有坏到需要修复的程度！”
对于此类系统，我的目标是每周重新查看日志，直到我解决或理解了出现的每个新错误；然后将日志审查放宽到每月一次。干净的日志更容易阅读！
答案4
我不相信有任何通用的技巧可以解释错误日志，除非你必须逐个研究每个错误，例如使用谷歌或阅读源代码，以理解它。
对于处理类似 syslog 的东西，尤其是在聚合许多机器时，可以提出一个通用建议。保留一个要忽略的模式列表和一个要立即发出警报的模式列表。生成一份排除“忽略”消息的每日报告。（甚至可以实时查看日志文件，排除可忽略的消息）。使用此报告添加到忽略列表和警报列表中。对于被识别为真实错误的模式，实时向管理员发出警报。理想情况下，您的忽略列表应该足够详尽，以便您可以阅读遗漏的消息，并且您的警报列表应该足够简单，以便您可以调查您收到的每条警报。能够处理来自您无法立即修复的损坏系统的大量警报。值得保留两个额外的模式级别 - 那些值得审查但不太可能成为问题的模式，以及那些值得发出警报但不会打扰某人的模式。
在 Unix 环境中未能做到这一点可能是最严重的（代价高昂且具有破坏性的）常见疏忽。