0

一个非常笼统的问题；在程序员的上下文中，考虑到过程（程序）的操作方面。

是否有任何类型的最佳实践/指南来分类消息，特别是在 SaaS / 多租户（服务器）软件环境的上下文中，由于用户操作或错误配置会产生错误和警告。由于软件的性质，我必须处理的大多数模块都是无状态的；即当由于用户错误而发生错误时，很难将其与操作错误（如网络配置错误等）区分开来。

我想知道的是你们中的一些有经验的人；为了便于操作男孩/女孩对这些消息进行分类和发现问题，这里要采用什么合理的逻辑？

4

3 回答 3

2

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

  • 使标签字段/程序名称可配置。然后可以配置多个实例以使用诸如 等的日志标签app/user_1，app/user_2从而允许在 syslog 级别上进行快速简单的过滤器。
  • 从左到右构造您的消息，因此可以使用简单的搜索模式或正则表达式过滤不同类别的日志行。例如config error - cannot parse line 123或runtime warning - lost connection to DB xyz
  • 对于非常结构化的日志，您还可以查看syslog-protocol 中的“结构化数据”字段。到目前为止，它很少使用并且没有工具支持，但它允许应用程序日志消息带有命名空间和非常清晰的键值属性。
于 2012-02-17T13:35:14.483 回答
0
  • 识别服务器和服务器类型（名称、IP 地址等）
  • 按严重性分类，确保所有时钟同步，以便正确排序消息。
  • 放置消息/错误代码以在您的监控工具中过滤/创建一些规则。
  • 放置一个模块（如果一个服务器上有多个模块，则使用）
  • 放置一个用于处理网络等一般服务的类别。

我猜你会用他们的系统日志守护程序从不同的机器收集日志到一个负责监督/监控的中央机器。

于 2012-02-17T12:45:59.797 回答
0

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

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

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

于 2012-02-17T13:37:26.790 回答