Commons Logging 优先级最佳实践
这可能是一个纯粹主观的问题（如果没有组织试图标准化这个问题），但我的团队在这个问题上的挣扎比你想象的要多。
我们使用 Apache Commons Logging 作为日志记录接口，并且我们的开发团队中优先级的使用通常不一致。例如，一些开发人员将任何捕获的异常记录为 fatal (log.fatal(message))，即使流程能够处理错误，而其他开发人员仅在某些情况导致程序因某种原因而必须停止执行时才记录为 fatal。
我想知道其他团队如何定义每个优先级。是否有人在一家明确尝试为此定义最佳实践的公司工作？雅加达是否对此进行了权衡？
我的目标是向我的整个团队发送针对每个优先级的简单建议，以便我们能够以一致的方式更有效地处理笨重的应用程序日志记录。
This may be a purely subjective question (if no organization has attempted to standardize this), but my team struggles with this more than you would think.
We use Apache Commons Logging as our logging interface and often the use of priority is not consistent across our development team. For example, some developers log any caught exception to fatal (log.fatal(message)) even though the flow is able to handle the error whereas others only log to fatal when something cause the program to necessarily cease execution for whatever reason.
I would like to know how other teams define each priority. Does anyone work at a company that explicitly tries to define best practices for this? Has Jakarta weighed in on this?
My goal would be to send a simple recommendation for each priority out to my whole team so that we can more effectively handle our unwieldy application logging in a consistent fashion.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
这是我们使用的（我也会说许多其他的）：
在某些情况下，我们首先将消息记录为错误，以便在发生我们通常不希望发生的事情时收到通知。稍后，如果我们确定无法删除该错误的来源，我们会对其进行处理并将日志级别更改为 WARN。
请注意，我们的测试和生产系统设置为发送有关致命和错误的电子邮件。因此，我们不必手动检查这些日志文件，而只需检查一封电子邮件收件箱。
希望有帮助。
编辑：您是否已经看过 Apache Commons Logging 最佳实践？
Here's what we use (and I'd say many others as well):
In some cases we start with logging messages as ERROR, in order to get the notification when something we'd normally not like to happen occurs. Later, if we decide that the source for that error can not be removed, we handle it and change the log level to WARN.
Note that our test and production systems are set up to send an email for FATAL and ERROR. Thus we don't have to check the log files for those manually but only have to check one email inbox.
Hope that helps.
Edit: did you already have a look at the Apache Commons Logging best pratices?
我一直以此为指导方针；我使用 Log4j 多于 Commons Logging，但这可能仍然有帮助：
DEBUG - 用于真正的调试级别信息；不会在生产或发货的产品中看到，因为 INFO 将是最低级别；适合捕获时间、事件发生次数等
INFO - 生产/运输使用的最低级别；记录可能对法医调查有用的数据并确认成功的结果（“在 DB OK 中存储了 999 项”）；这里的所有信息必须确保最终用户/客户看到它并向您发送它（如果需要的话）（没有秘密，没有亵渎！）
警告 - 不是错误级别，但了解系统可能进入危险领域是有用的，例如业务逻辑内容，如“订购产品的数量<0”，这表明某处存在错误，但不是系统异常；老实说，我倾向于不那么频繁地使用它，发现事情往往更自然地适合 INFO 或 ERROR
ERROR - 将其用于例外情况（除非有充分的理由减少为 WARN 或 INFO） ;记录完整的堆栈跟踪以及重要的变量值，否则诊断就不可能；仅用于应用程序/系统错误，而不是不良的业务逻辑情况
致命 - 仅将其用于严重程度如此之高的错误，以至于它实际上阻止应用程序启动/继续
此外 - 经常检查您的日志记录，无论是当 DEBUG 和 INFO 级别处于活动状态时，您希望能够遵循良好的叙述，易于找到突出的事件，并确保您没有做任何有损可读性的过于冗长的事情。
还要确保您使用的模式能够为时间戳、源类和严重性等内容提供整齐的列——同样，它极大地提高了可读性。
I have always used this as a guideline; I use Log4j more than Commons Logging but this may still be helpful:
DEBUG - for genuinely debug-level info; will not be seen in production or shipped product, as INFO will be the minimum level; good for capturing timings, number of occurrences of events, etc
INFO - minimum level for production/shipped usage; record data likely to be useful in forensic investigations and to confirm successful outcomes ("stored 999 items in DB OK"); all info here must be such that you would be OK with end users/customers seeing it and sending you it, if need be (no secrets, no profanity!)
WARN - not an error level as such, but useful to know the system may be entering dodgy territory, e.g. business logic stuff like "number of ordered products < 0" which suggests a bug somewhere, but isn't a system exception; I tend not to use it that much to be honest, finding things tend to be more natural fits to INFO or ERROR
ERROR - use this for exceptions (unless there's a good reason to reduce to WARN or INFO); log full stacktraces along with important variable values without which diagnosis is impossible; use only for app/system errors, not bad business logic circumstances
FATAL - only use this for an error of such high severity that it literally prevents the app from starting / continuing
Additionally - review your logging often, both with DEBUG and INFO levels active, you want to be able to follow a good narrative through, with prominent events easy to find, and to make sure you're not doing anything too verbose which detracts from readability.
Also ensure you use a pattern which leads to neat columns for things like timestamps, source-classes and severity - again, it helps readability massively.
我的看法
My take
这是我公司的建议：
TRACE - 消息可能仅在开发周期中有用，并且可能生成得太频繁，不适合在生产中使用。例如，如果我正在记录
内部循环中的中间值，我会使用 TRACE。
DEBUG - 用于记录服务器正常运行中各个步骤的消息。通常这些是针对开发人员而不是运营人员。
信息 - 我们希望在生产环境中记录的积极或中立的消息。对操作人员应该有意义。
警告 - 指示可能危及服务器准确及时响应请求的能力的情况的消息。
错误 - 指示意外行为或情况的消息。
FATAL - 指示意外行为或情况的消息，该行为或情况导致应用程序进程无法继续运行或存在危险。
我们希望生产中的日志设置为 INFO，并且我们希望它们能够被开发人员以外的人读取。日志消息的风格是完全不同的对话......
This is what my company recommends:
TRACE - Messages probably only useful during the development cycle, and possibly generated far too frequently for suitable use in production. For example, if I were logging
intermediate values in an inner loop, I’d use TRACE.
DEBUG - Messages used to log various steps in the normal running of the server. Typically these would be aimed at developers rather than operations staff.
INFO - Messages of a positive or neutral nature which we would expect to be logged in a production environment. Should be meaningful to operations staff.
WARN - Messages indicating a condition possibly endangering the ability of the server to respond to requests in an accurate and timely fashion.
ERROR - Messages indicating an unexpected behaviour or condition.
FATAL - Messages indicating an unexpected behaviour or condition which leaves the continued running of the application process impossible or dangerous.
We expect the logs in production to be set at INFO, and we expect them to be read by people other than the developers. Style of log messages is a whole other conversation...
如果您正在寻找行业支持的简单建议，为什么不直接查看行业简单的实施/文档呢？
我们使用
logback/log4jAPI 作为 日志级别指南 =>这使得它变得简单/记录/得到行业的支持：级别ALL具有最低的可能等级，旨在打开所有日志记录。
级别DEBUG指定对调试应用程序最有用的细粒度信息事件。
级别错误指定可能仍允许应用程序继续运行的错误事件。
级别 FATAL 指定非常严重的错误事件，可能会导致应用程序中止。
级别INFO指定在粗粒度级别突出显示应用程序进度的信息性消息。
级别OFF具有最高可能的等级，旨在关闭日志记录。
级别 TRACE 指定比 DEBUG 更细粒度的信息事件
Level WARN 表示潜在有害的情况。
If you are looking for a simple recommendation that is supported by the industry, why not just look at the industry simple implementation/documentation?
We use a
logback/log4jAPI as a logging level guide => which makes it simple / documented / supported by the industry:Level ALL has the lowest possible rank and is intended to turn on all logging.
Level DEBUG designates fine-grained informational events that are most useful to debug an application.
Level ERROR designates error events that might still allow the application to continue running.
Level FATAL designates very severe error events that will presumably lead the application to abort.
Level INFO designates informational messages that highlight the progress of the application at coarse-grained level.
Level OFF has the highest possible rank and is intended to turn off logging.
Level TRACE designates finer-grained informational events than the DEBUG
Level WARN designates potentially harmful situations.
我正在使用一种更简单的方法：
DEBUG：在生产中关闭，因此主要由开发人员用来记录某些查询、计时、参数值等。
INFO：记录所有内容，以便您了解回顾一切来解释你的结果已计算，以便您可以修复错误
错误：需要某人（开发人员/运营）注意的所有内容
我不'使用WARN，因为没有人会过滤所有日志文件中的 WARN 消息。如果它很重要，那么它就是错误（并且必须有人关心它），如果不重要，它就是信息（并且在出现问题之前没有人对它感兴趣）。致命一击也一样。
我也不使用TRACE。在开发过程中我需要知道的一切都是DEBUG。
I'm using a simpler approach:
DEBUG: Turned off in production, thus mainly used by the developer to log certain queries, timings, parameter values, etc.
INFO: Log everything so that you know in retrospect everything to explain how your results were computed and so that you can fix bugs
ERROR: Everything that needs someones (developer/operations) attention
I don't use WARN, because no-one ever filters all log files for WARN messages. If it is important, then it is ERROR (and someone has to care about it), if not, it is INFO (and no-one is interested in it until there is a problem). Same for FATAL.
I also don't use TRACE. Everything I need to know during development is DEBUG.
这个答案取自我写的一篇关于日志记录最佳实践（包括日志记录）的文章您可能会发现相关的级别：
在我看来，具有以下级别就足够了：调试、信息、警告和错误日志级别。
一些工程师喜欢有额外的级别，如详细、跟踪、警报、关键、致命，而一些富有创造力的开发人员甚至发明了额外的级别……
请不要这样做。少即是多！
让我们讨论不同的级别：
错误- 指示可能很严重的系统错误的日志条目。例如，HTTP 调用失败。我的一位前同事写了一篇不错的文章，其中包括有关记录异常的部分，我建议阅读WARN- 重大事件指示错误，但行为要么是预期的，要么不是关键的。例如，如果需要重试，这可能是一次失败的充电。INFO- 与系统操作相关的有用信息。我们的生产系统经过调整，将其报告为记录的最低级别。DEBUG- 旨在在预生产环境或本地使用。当您不想在合并时删除日志打印（因为它可能有用），但也不希望它出现在生产中时，请使用此日志级别。应该有一个标志/环境变量可以打开调试打印（即使在生产中），但应该很少使用。This answer is taken from a post that I wrote about Logging best practices including logging levels that you may find relevant:
In my opinion, it’s sufficient to have: debug, info, warn and error log levels.
Some engineers like to have additional levels like verbose, trace, alert, critical, fatal, and some creative developers even invent additional levels…
Please don’t do that. Less is more!
Let’s discuss the different levels:
ERROR- Log entries that indicate a system error that may be critical. For example, an HTTP call failed. A former colleague of mine wrote a nice piece that includes a section on logging exceptions which I recommend readingWARN- Significant events indicate an error, but the behavior is either expected or not critical. This could be a failed charge where there’s a retry in place, for example.INFO- Useful information related to the operation of the system. Our production systems are tuned to report this as the minimum level logged.DEBUG- Intended to be used in pre-prod environments or locally. Use this log level when you don’t want to remove a log-print when merging (because it may prove useful), but also don’t want it to show up in production. There should be a flag/environment-variable that can turn on debug printing (even in production) but it should be used scarcely.