syslog - 日志行分类

Question

一个非常通用的问题;在程序员的背景下，考虑到过程（程序）的操作方面。

是否存在任何类型的最佳实践/指南来对消息进行分类，特别是在SaaS /多租户（服务器）软件环境中，由于用户操作或配置错误而产生错误和警告。由于软件的性质，我不得不处理的大部分模块都是无状态的;即当由于用户错误而发生错误时，很难区分它和操作错误（如网络配置错误等）。

我想知道的是你们中的一些经验丰富的人。在这里使用什么是合理的逻辑，以便让操作男孩/女孩轻松地对这些信息进行分类，并找出问题？

Answer 1

从管理和日志分析/分类角度来看，只有三个方面：

• 使标签字段/程序名称可配置。然后，可以配置多个实例以使用app/user_1，app/user_2等日志标记，从而允许在syslog级别上进行快速简单的过滤。
• 从左到右构建消息，因此可以使用简单的搜索模式或正则表达式过滤不同类别的日志行。例如。 config error - cannot parse line 123或runtime warning - lost connection to DB xyz
• 对于非常结构化的日志，您还可以查看'structured data' field in syslog-protocol。到目前为止它很少使用且没有工具支持，但它允许具有命名空间和非常清晰的键值属性的应用程序日志消息。

Answer 2

• 识别服务器和服务器类型（名称，IP地址等）
• 按严重程度分类，确保所有时钟按顺序同步 正确地订购消息。
• 添加消息/错误代码以在监控工具中过滤/创建一些规则。
• 放置一个模块（在一台服务器上使用多个模块时使用）
• 提供一个类别，用于解决网络等常规服务。

我猜你会把不同机器上的日志与他们的系统日志守护者一起收集到负责监督/监控的中央机器。

Answer 3

大多数* nix进程使用半标准格式“Month Day 24H-Time host process_name [pid]：message”登录到syslog（或至少应该）。 Syslog包含指示消息严重性的方法，使用它们（但请记住，严重性来自系统的预期，而不是应用程序）。

如果消息是调试问题，那么它通常是“Function_Name File_Name Line_No Error_Code Error_Desc”;否则消息的格式完全取决于程序。

对于多租户系统，“消息”部分通常以某种形式的租户标识开始，然后是实际的日志消息。