13

这可能是一个纯粹主观的问题（如果没有组织试图将其标准化），但我的团队在这方面的挣扎比你想象的要多。

我们使用 Apache Commons Logging 作为我们的日志接口，并且在我们的开发团队中，优先级的使用经常不一致。例如，一些开发人员将任何捕获的异常记录为致命的 (log.fatal(message))，即使流程能够处理错误，而其他开发人员仅在某些原因导致程序必须停止执行时才记录为致命异常。

我想知道其他团队如何定义每个优先级。是否有人在明确尝试为此定义最佳实践的公司工作？雅加达对此有意见吗？

我的目标是向我的整个团队发送针对每个优先级的简单建议，以便我们能够以一致的方式更有效地处理笨重的应用程序日志记录。

4

7 回答 7

10

这是我们使用的（我也会说很多其他的）：

  • 致命：危及系统一致性的错误，可能需要立即关闭/重新启动 - 很少手动使用
  • 错误：不应该抛出的异常并代表系统中的错误（通常是所有未赶上特定点的异常）
  • 警告：可能发生但已被解释的异常或可能暗示逻辑/使用错误的情况 - 我们决定是否跟踪这些
  • INFO：您需要在日志中包含的任何内容，例如用户当前在做什么（在我们的 Web 应用程序中：用户正在导航到哪个页面等）
  • 调试：仅调试时间等消息，通常在日志中关闭
  • TRACE：我们不使用它，您可以将它用于更具体的调试信息

在某些情况下，我们首先将消息记录为 ERROR，以便在我们通常不希望发生的事情发生时获得通知。稍后，如果我们决定无法删除该错误的来源，我们会处理它并将日志级别更改为 WARN。

请注意，我们的测试和生产系统设置为发送 FATAL 和 ERROR 的电子邮件。因此，我们不必手动检查日志文件，而只需检查一个电子邮件收件箱。

希望有帮助。

编辑：您是否已经看过Apache Commons Logging 最佳实践？

于 2011-09-20T14:23:58.583 回答
7

我一直以此为指导；我使用 Log4j 多于 Commons Logging 但这可能仍然有帮助：

DEBUG - 真正的调试级信息；不会在生产或发货产品中看到，因为 INFO 将是最低级别；适合捕捉时间、事件发生的次数等

INFO - 生产/运输使用的最低水平；记录可能对法医调查有用的数据并确认成功的结果（“在 DB OK 中存储了 999 个项目”）；此处的所有信息都必须确保最终用户/客户可以看到并在需要时将其发送给您（没有秘密，没有亵渎！）

警告- 不是这样的错误级别，但有助于了解系统可能正在进入狡猾的领域，例如“订购产品的数量 < 0”之类的业务逻辑内容表明某处存在错误，但不是系统异常；老实说，我倾向于不经常使用它，发现事物往往更自然地适合 INFO 或 ERROR

ERROR - 将其用于异常（除非有充分的理由减少为 WARN 或 INFO）；记录完整的堆栈跟踪以及重要的变量值，没有这些值就不可能进行诊断；仅用于应用程序/系统错误，不错的业务逻辑情况

致命- 仅将其用于严重性如此高的错误，以至于它实际上会阻止应用程序启动/继续

此外 - 经常查看您的日志记录，在 DEBUG 和 INFO 级别都处于活动状态时，您希望能够通过良好的叙述，容易找到突出的事件，并确保您没有做任何过于冗长而降低可读性的事情.

还要确保您使用的模式可以为时间戳、源类和严重性等内容生成整齐的列 - 再次，它极大地提高了可读性。

于 2011-09-20T14:22:33.357 回答
2

我的看法

  • 致命：程序处于无法处理的状态，必须终止（自动或由用户）。
  • 错误：程序操作以用户可检测到的方式失败（未保存更改/无法读取文件），但程序仍然可以工作（尝试加载另一个文件）。
  • 警告：有些事情没有按计划进行，但用户没有注意到它（服务器没有响应 ping；也许当需要该服务器时，它会导致错误/致命）
  • 信息：用户操作/主要程序操作（文件加载、自动备份存储）。
  • 调试：跟踪信息。程序在运行什么部分，参数的值是什么
于 2011-09-20T14:25:01.907 回答
1

这是我公司推荐的：

TRACE - 消息可能仅在开发周期中有用，并且可能过于频繁地生成，不适合在生产中使用。例如，如果我在内部循环中记录中间值，我会使用 TRACE。

DEBUG - 用于记录服务器正常运行中的各个步骤的消息。通常这些将针对开发人员而不是运营人员。

INFO - 我们希望在生产环境中记录的积极或中性消息。应该对运营人员有意义。

WARN - 指示可能危及服务器以准确和及时方式响应请求的能力的条件的消息。

错误- 指示意外行为或条件的消息。

FATAL - 指示意外行为或条件的消息，导致应用程序进程无法继续运行或存在危险。

我们希望生产中的日志设置为 INFO，并且我们希望它们被开发人员以外的人阅读。日志消息的风格是完全不同的对话......

于 2011-09-26T20:08:11.023 回答
1

如果您正在寻找行业支持的简单建议，为什么不直接查看行业简单实施/文档？

我们使用logback/ log4jAPI 作为日志级别指南=> 这使它变得简单/记录/得到行业支持：

  • 级别ALL具有最低级别，旨在打开所有日志记录。

  • 级别DEBUG指定对调试应用程序最有用的细粒度信息事件。

  • 级别ERROR指定可能仍允许应用程序继续运行的错误事件。

  • 级别FATAL指定可能导致应用程序中止的非常严重的错误事件。

  • 级别INFO指定在粗粒度级别突出显示应用程序进度的信息消息。

  • Level OFF具有最高等级，旨在关闭日志记录。

  • 级别TRACE指定比 DEBUG 更细粒度的信息事件

  • WARN级别表示潜在的有害情况。

于 2011-09-29T18:00:49.687 回答
0

我正在使用一种更简单的方法：

  • DEBUG：在生产中关闭，因此主要由开发人员用于记录某些查询、时间、参数值等。

  • INFO：记录所有内容，以便您回顾所有内容，以解释您的结果是如何计算的，以便您可以修复错误

  • 错误：需要某人（开发人员/运营）注意的一切

我不使用WARN，因为没有人会过滤所有日志文件中的 WARN 消息。如果它很重要，那么它就是 ERROR（并且有人必须关心它），如果不是，它就是 INFO（并且在出现问题之前没有人对它感兴趣）。致命的也一样。

我也不使用TRACE。在开发过程中我需要知道的一切都是调试。

于 2011-09-28T13:40:52.750 回答
0

这个答案取自我写的一篇关于日志记录最佳实践的帖子，包括您可能认为相关的日志记录级别：

在我看来，拥有：调试、信息、警告和错误日志级别就足够了。一些工程师喜欢设置额外的级别，例如详细、跟踪、警报、关键、致命，而一些有创意的开发人员甚至发明了额外的级别……</p>

请不要那样做。少即是多！

让我们讨论不同的级别：

ERROR- 指示可能很严重的系统错误的日志条目。例如，HTTP 调用失败。我的一位前同事写了一篇不错的文章，其中包括关于记录异常的部分，我建议阅读

WARN- 重大事件表明错误，但行为是预期的或不严重的。例如，在进行重试的情况下，这可能是一次失败的收费。

INFO- 与系统操作相关的有用信息。我们的生产系统已调整为将其报告为记录的最低级别。

DEBUG- 旨在用于预生产环境或本地。当您不想在合并时删除日志打印时使用此日志级别（因为它可能被证明是有用的），但也不希望它出现在生产中。应该有一个标志/环境变量可以打开调试打印（即使在生产中），但它应该很少使用。

于 2021-11-16T00:48:03.190 回答