Commons Logging Priority最佳做法 [英] Commons Logging priority best practices

问题描述

这可能是一个纯粹的主观问题(如果没有组织尝试对此进行标准化)，但是我的团队为此付出的努力比您想象的要多.

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

我想知道其他团队如何定义每个优先级.有人在明确尝试为此定义最佳做法的公司工作吗?雅加达有没有考虑这个问题?

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

解决方案

这是我们使用的(我也会说很多其他东西):

• 致命:错误会危及系统的一致性，并可能需要立即关闭/重新启动-很少手动使用
• 错误:不应引发的异常，它表示系统中的错误(通常所有未捕获到特定点的异常)
• WARN:可能发生但已解决的异常情况或可能暗示逻辑/使用错误的情况-我们决定是否跟踪这些错误
• INFO:您需要在日志中输入的任何内容，例如用户当前正在做什么(在我们的Web应用程序中:用户正在导航到的页面等)
• 调试:仅调试计时等消息，通常在日志中将其关闭
• TRACE:我们不使用它，您可以将其用于更具体的调试信息

在某些情况下，我们从将消息记录为ERROR开始，以便在通常不希望发生的事情发生时获得通知.稍后，如果我们确定无法删除该错误的源，则将其处理并将日志级别更改为WARN.

请注意，我们的测试和生产系统已设置为发送关于致命和错误的电子邮件.因此，我们不必手动检查那些日志文件，而只需检查一个电子邮件收件箱.

希望有帮助.

您是否已查看 Apache Commons Logging最佳实践?

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.

解决方案

Here's what we use (and I'd say many others as well):

• FATAL: errors that endanger the consistency of the system and might require an immediate shutdown/restart - very rarely manually used
• ERROR: exceptions that should not be thrown and represent a bug in the system (normally all exceptions that are not caught up to a certain point)
• WARN: exceptions that might occur but are accounted for or situations that might imply a logic/usage error - we decide whether to track those or not
• INFO: whatever you need to have in the log, e.g. what users currently do (in our case of web applications: what page the user is navigating to etc.)
• DEBUG: debug only messages like timings etc, generally turned off in the logs
• TRACE: we don't use that, you might use it for even more specific debugging info

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?

这篇关于Commons Logging Priority最佳做法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！