阅读日志文件可能会非常令人沮丧，因为从本质上讲，他们的内容对开发者来说，就像是问题本身一样。
（例如：“google是你的朋友”还是“某些错误代码比别人更多”或“记住警告和错误是非常不同的”）？
让开发人员偶尔排查生产问题。 这将为您的日志logging创造奇迹。 🙂
（1）分布式环境中的问题（2）大量的debugging信息分散在协同服务器和不同日志文件中（3）没有解释文档日志（4）没有在谷歌（5）没有线索（6）乒乓球员，而不是供应商的支持。
我对服务器日志的习惯是：定期检查他们，并调查/解决我发现的问题。 我主动做到这一点 – 不要等到用户在系统中断时才大声嚷嚷。 这是有效的主要原因，真正归结为几个老的说法：
小洞不补，大洞吃苦。 很明显，如果你在小问题上解决问题，那么你就是超前的，用户/pipe理层对你的咆哮的理由就会减less。 这是好事。
实践使得完美。 我认为这对系统pipe理员来说是更大的优势。 通过定期进入并主动阅读日志，您将获得经验和熟悉。 你正在学习那些神秘的日志消息是什么意思 – 哪些是微不足道的，哪些是重要的。 调查消息的过程中，你不会立即明白（这将是很多，他们一开始！）教你很多关于操作系统的内部和运行的应用程序。
通常当我得到一个新的系统来pipe理时，日志中会有很多错误，其中很多会经常发生。 之前的pipe理员经常耸耸肩，以“不太确定这是怎么一回事，但用户从来没有抱怨过，所以我没有认为它已经足够修复了”。
我使用这样的系统的目标是每周重新访问日志，直到我解决或理解每一个新出现的错误。 然后放松我的日志评论每月。 清理日志更容易阅读！
一个好的程序支持日志级别 。 通常，日志没有时间戳是毫无价值的。
大多数Linux发行版都附带了一个logwatch工具。 学会使用它并configuration它的忽略设置。 诀窍是适当地设置痛苦的阈值，以便没有任何关键的被忽略，但不是那么垃圾，pipe理员写邮件规则文件和忽略logwatch邮件。
我不相信任何通用的提示可以被用来解释错误日志，除了你必须逐个研究每个错误，例如用谷歌或者通过阅读来理解它。
为了处理像syslog这样的东西，特别是在聚合很多机器时，可以提出一个通用的build议。 保留要忽略的模式列表，以及立即提示的模式列表。 生成排除“忽略”消息的每日报告。 （或者甚至实时观看日志文件，排除可忽略的消息）。 使用此报告可将其添加到忽略列表和警报列表。 对于识别为真实错误的模式，请实时向pipe理员发送警报。 理想情况下，您的忽略列表应该足够彻底，以便您可以阅读所经历的消息，并且您的警报列表应该足够简单，以便您可以调查每个警报。 能够处理来自不能立即修复的破坏系统的警报洪水。 值得保留另外两层模式 – 那些值得重新审视但不可能成为问题的模式，那些值得警惕但不能干扰某人的模式。
在Unix环境下如果做不到这一点，很可能是最重要的（代价高昂的，破坏性的）普遍的监督。
请参阅开发人员随应用程序交付的日志文件的文档。
什么？ 没有文件？ 一个态度调整工具的时间
更严重的是，logging日志文件以及如何解释它们需要成为开发人员的任务之一。 他们的工作不是在代码完成的时候完成的，当操作人员可以运行应用程序并保持运行的时候就完成了，这意味着文档，交接会议，可pipe理性devise等等。
不要对日志文件做出假设。
字段格式需要检查。 例如：date是dd / mm / yy还是mm / dd / yy？ 是数字字段十进制，hex，八进制或其他东西？ 时间戳是一致的（其他人已经提到了设备之间同步时间的重要性：检查它是否已经同步或者计算出时间戳的来源并纠正它）？
所有的设备/进程是否都在相同的日志级别进行日志logging，以及您期望的日志级别？
日志在同一软件的不同版本之间是否一致？ （检查日志输出是否与以前的版本一致，并且文档应该在testing新软件版本的列表中，但是可以忽略）