Debug ：我们考虑Debug <Trace . 区别在于Debug消息是从Release版本编译而来的 . 也就是说，我们不鼓励使用Debug消息 . 允许调试消息往往会导致添加越来越多的调试消息，并且不会删除任何消息 . 随着时间的推移，这使得日志文件几乎无用，因为它在发布版本中包含了's too hard to filter signal from noise. That causes devs to not use the logs which continues the death spiral. In contrast, constantly pruning Trace messages encourages devs to use them which results in a virtuous spiral. Also, this eliminates the possibility of bugs introduced because of needed side-effects in debug code that isn't . 是的，我知道不应该在良好的代码中发生，但更安全然后抱歉 .
16 回答
天儿真好，
作为此问题的必然结果，请传达您对日志级别的解释，并确保项目中的所有人员对其级别的解释保持一致 .
看到各种日志消息，其中严重性和所选日志级别不一致，这是很痛苦的 .
尽可能提供不同日志记录级别的示例 . 并且在要在消息中记录的信息中保持一致 .
HTH
如果你可以从问题中恢复，那么这是一个警告 . 如果它阻止继续执行那么这是一个错误 .
我发现从查看日志文件的角度考虑严重性更有帮助 .
Fatal/Critical ：应立即调查的整体应用程序或系统故障 . 是的，唤醒SysAdmin . 由于我们更喜欢我们的SysAdmins警报和良好的休息，因此应该很少使用此严重性 . 如果's happening daily and that'不是BFD，那就是's lost it'的含义 . 通常，致命错误仅在进程生存期中发生一次，因此如果日志文件与进程关联，则这通常是日志中的最后一条消息 .
Error ：绝对是一个应该调查的问题 . 应自动通知SysAdmin，但不需要将其拖出床 . 通过过滤日志以查看错误及以上，您可以获得错误频率的概述，并可以快速识别可能导致一系列其他错误的启动失败 . 跟踪错误率与应用程序使用情况相比可以产生有用的质量指标，例如可用于评估总体质量的MTBF . 例如，此指标可能有助于在发布之前决定是否需要另一个beta测试周期 .
Warning ：这可能是问题，也可能不是 . 例如，预期的瞬态环境条件（如网络短缺或数据库连接）应记录为警告，而不是错误 . 查看过滤后的日志仅显示警告和错误，可以快速了解后续错误根本原因的早期提示 . 应谨慎使用警告，以免它们变得毫无意义 . 例如，丢失网络访问应该是服务器应用程序中的警告甚至是错误，但可能只是为偶尔断开连接的笔记本电脑用户设计的桌面应用程序中的信息 .
Info ：这是在正常情况下应记录的重要信息，例如成功初始化，服务启动和停止或成功完成重要事务 . 查看显示Info及更高版本的日志应该快速概述流程中的主要状态更改，提供顶级上下文，以便了解同时发生的任何警告或错误 . 没有太多的信息消息 . 我们通常有相对于Trace的<5％Info消息 .
Trace ：Trace是迄今为止最常用的严重性，应提供上下文以了解导致错误和警告的步骤 . 具有适当密度的跟踪消息使得软件更易于维护，但需要一些勤奋，因为随着程序的发展，各个Trace语句的 Value 可能会随着时间而变化 . 实现这一目标的最佳方法是让开发团队习惯定期查看日志，作为解决客户报告问题的标准部分 . 鼓励团队删除不再提供有用上下文的跟踪消息，并在需要时添加消息以了解后续消息的上下文 . 例如，记录用户输入（例如更改显示或选项卡）通常很有帮助 .
Debug ：我们考虑Debug <Trace . 区别在于Debug消息是从Release版本编译而来的 . 也就是说，我们不鼓励使用Debug消息 . 允许调试消息往往会导致添加越来越多的调试消息，并且不会删除任何消息 . 随着时间的推移，这使得日志文件几乎无用，因为它在发布版本中包含了's too hard to filter signal from noise. That causes devs to not use the logs which continues the death spiral. In contrast, constantly pruning Trace messages encourages devs to use them which results in a virtuous spiral. Also, this eliminates the possibility of bugs introduced because of needed side-effects in debug code that isn't . 是的，我知道不应该在良好的代码中发生，但更安全然后抱歉 .
这是“ Logger ”的列表 .
Apache log4j：§1，§2
FATAL：ERROR：WARN：INFO：DEBUG：TRACE：Apache Httpd（像往常一样）喜欢寻找过度杀伤力：§
Apache commons-logging：§
用于企业使用的Apache commons-logging "best practices"根据它们跨越的边界区分 debug 和 info .
边界包括：
外部边界 - 预期的例外情况 .
外部边界 - 意外异常 .
内部边界 .
重要的内部边界 .
（有关详细信息，请参阅commons-logging guide . ）
顺便说一下，我非常喜欢捕获所有内容并在以后过滤信息 .
如果您在警告级别捕获并希望获得与警告相关的一些调试信息，但无法重新创建警告，会发生什么？
捕获所有内容并稍后过滤！
即使对于嵌入式软件也是如此，除非您发现您的处理器无法跟上，在这种情况下您可能需要重新设计跟踪以提高其效率，或者跟踪会干扰时序（您可能会考虑调试一个更强大的处理器，但它开辟了一整套蠕虫） .
捕获所有内容并稍后过滤！
（顺便说一句，捕获一切也很好，因为它可以让你开发工具，而不仅仅是显示调试跟踪（我从我的绘制消息序列图表，以及内存使用的直方图 . 它还为你提供了比较的基础，如果出现问题） future（保留所有日志，无论是通过还是失败，并确保在日志文件中包含内部版本号）） .
我一直在考虑警告第一个日志级别肯定意味着存在问题（例如，可能配置文件不在应有的位置，我们将不得不使用默认设置运行） . 对我来说，错误意味着这意味着软件的主要目标现在是不可能的，我们将尝试彻底关闭 .
我认为SYSLOG级别NOTICE和ALERT / EMERGENCY对于应用程序级别的日志记录来说基本上是多余的 - 而CRITICAL / ALERT / EMERGENCY对于可能触发不同操作和通知的操作员来说可能是有用的警报级别，对于应用程序管理员来说它是完全相同的致命 . 而且我无法充分区分发出通知或某些信息 . 如果信息不值得注意，那不是真正的信息:)
我最喜欢Jay Cincotta的解释 - 追踪你的代码执行在技术支持中是非常有用的，并且应该鼓励将跟踪语句放在代码中 - 特别是与用于记录来自特定应用程序组件的跟踪消息的动态过滤机制相结合 . 然而DEBUG级别对我来说表明我们仍然在弄清楚发生了什么 - 我认为DEBUG级别输出是一个开发选项，而不是 生产环境 日志中应该出现的东西 .
然而，我喜欢在我的错误日志中看到一个日志记录级别，当戴上系统管理员的帽子和技术支持的帽子时，甚至是开发人员：OPER，用于OPERATIONAL消息 . 这用于记录时间戳，调用的操作类型，提供的参数，可能的（唯一）任务标识符和任务完成 . 它在例如使用时使用一个独立的任务被触发，这是一个真正的调用，从较大的长期运行的应用程序 . 这是我想要总是记录的东西，无论是否出现任何问题，所以我认为OPER的级别高于FATAL，所以你只能通过进入完全静音模式来关闭它 . 它不仅仅是INFO日志数据 - 日志级别经常被滥用于垃圾邮件日志，其中包含没有任何历史 Value 的小型操作消息 .
在这种情况下，该信息可以指向单独的调用日志，或者可以通过从大日志中过滤它来记录更多信息来获得 . 但是，作为历史信息，它总是需要知道正在做什么 - 没有下降到AUDIT的水平，另一个与故障或系统操作无关的完全独立的日志级别，并不真正适合上述级别（因为它需要自己的控制开关，而不是严重性分类），它肯定需要自己独立的日志文件 .
我通常订阅以下约定：
Trace - 只有当我成为"tracing"代码并试图专门找到一个函数的 part 时 .
Debug - 对人们而言不仅仅是开发人员（IT，系统管理员等）在诊断上有帮助的信息 .
Info - 通常用于记录的有用信息（服务启动/停止，配置假设等） . 信息我希望始终可用但通常在正常情况下不关心 . 这是我开箱即用的配置级别 .
Warn - 任何可能导致应用程序奇怪的事情，但我正在自动恢复 . （例如从主服务器切换到备份服务器，重试操作，丢失辅助数据等）
Error - 对 operation 而言是致命的任何错误，但不是服务或应用程序（无法打开所需文件，缺少数据等） . 这些错误将强制用户（管理员或直接用户）进行干预 . 这些通常是（在我的应用程序中）保留不正确的连接字符串，缺少服务等 .
Fatal - 强制关闭服务或应用程序以防止数据丢失（或进一步丢失数据）的任何错误 . 我保留这些仅用于最令人发指的错误和保证数据损坏或丢失的情况 .
我建议采用Syslog严重性级别：
DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY.见http://en.wikipedia.org/wiki/Syslog#Severity_levels
它们应该为大多数用例提供足够的细粒度严重性级别，并且可以被现有的日志解析器识别 . 虽然你当然可以自由地只实现一个子集，例如
DEBUG, ERROR, EMERGENCY取决于您的应用程序的要求 .让我们标准化已经存在多年的东西，而不是为我们制作的每个不同的应用程序提出我们自己的标准 . 一旦开始聚合日志并尝试检测不同模式的模式，它确实有帮助 .
我之前构建了系统使用以下内容：
错误 - 意味着某些事情严重错误，并且特定的线程/进程/序列无法继续 . 需要一些用户/管理员干预
警告 - 某些事情是不对的，但过程可以像以前一样继续进行（例如，100个集合中的一个作业失败，但其余部分可以处理）
在我 Build 的系统中，管理员正在接受指令以对ERROR做出反应 . 另一方面，我们会关注警告并确定每种情况是否需要更改系统，重新配置等 .
来自Ietf - 第10页
这些在下表中描述，并附有它们的数值 . 严重性值必须在0到7的范围内 .
您可以从中恢复的警告 . 错误你不能 . 这是我的启发式，其他人可能有其他想法 .
例如，假设您在应用程序中输入/导入名称
"Angela Müller"（请注意u上的变音符号） . 您的代码/数据库可能只有英文版（虽然它可能不应该在这个时代），因此可以警告所有"unusual"字符都已转换为普通英文字符 .与此相反，尝试将该信息写入数据库并直接返回网络关闭消息60秒 . 这更像是一个错误，而不是一个警告 .
您是否希望该消息让系统管理员在半夜起床？
是 - >错误
不 - >警告
错误是错误的，完全错误的，没有解决方法，需要修复 .
警告是可能错误的模式的标志，但也可能不是 .
话虽如此，我无法想出一个警告的好例子，这也不是一个错误 . 我的意思是，如果你遇到记录警告的麻烦，你也可以解决潜在的问题 .
但是，像“sql执行时间过长”这样的事情可能是一个警告，而“sql execution deadlocks”是一个错误，所以也许毕竟有些情况 .
我完全赞同其他人，并认为GrayWizardx说得最好 .
我可以补充的是，这些级别通常对应于它们的字典定义，所以它不会那么难 . 如果有疑问，请将其视为谜题 . 对于您的特定项目，请考虑您可能要记录的所有内容 .
现在，你能弄明白什么可能是致命的吗？你知道fatale意味着什么，不是吗？那么，列表中的哪些项目是致命的 .
好吧，这是致命的，现在让我们看看错误......冲洗并重复 .
在Fatal或者Error之下，我会建议更多信息总是好于更少，所以错误“向上” . 不确定是信息还是警告？然后发出警告 .
我确实认为致命和错误应该对我们所有人都清楚 . 其他人可能会更加模糊，但可以说，让他们做对不太重要 .
Fatal - 可以't allocate memory, database, etc - can' t继续 .
Error - 没有回复邮件，事务中止，无法保存文件等
Warning - 资源分配达到X％（比如80％） - 这表示您可能想要重新标注您的资产 .
Info - 用户登录/注销，新事务，文件包装，新d / b字段或字段已删除 .
Debug - 内部数据结构转储，带文件名和行号的任何跟踪级别 .
跟踪 - 操作成功/失败，d / b更新 .
正如其他人所说，错误是问题;警告是潜在的问题 .
在开发过程中，我经常使用警告，我可能会将相应的断言失败，但应用程序可以继续工作;这使我能够找出这种情况是否真的发生过，或者这是否是我的想象 .
但是，它可以归结为可恢复性和现实性方面 . 如果你能恢复，那可能是一个警告;如果它导致某些东西实际上失败，那就是错误 .