我打算建立一个伟大的系统。考虑日志级别命名 让我怀疑。
如果日志级别也反映它们将在日志中显示的频率，那将会很好。
例如：
现在，系统管理员永远不会在生产中打开TRACE日志记录。他可以安全地打开INIT / SHUTDOWN。如果系统中存在低流量，则为FUNC_CALL。
这个设计有什么问题？
您会用什么名字来反映频率？
（我知道WARN，INFO和ERROR。）
答案 0 :(得分：4)
我会选择更多自我描述的名字，例如：
也许不完全是这些但你明白了 - 确保绝对不可能对每个日志级别的含义感到困惑。 （我在更保守的意义上也使用了“跟踪”术语 - 函数调用列表 实际上是跟踪，所以FUNC_CALL和TRACE听起来像我的同义词）
另外一定要确保不要禁用任何人禁用的日志级别。我个人总是发现默认的错误/警告/信息级别很愚蠢，因为它们非常误导（请求不存在的项目出错？）
如果没有人（意外地）禁用EVERYTHING_IS_BROKEN_IMMEDIATE_ATTENTION_REQUIRED和RARE_IMPORTANT_EVENT级别也会很好。
不要害怕使用长名称，IDE无论如何都会自动完成它们。最好有更长的名字而不是混乱的日志。
答案 1 :(得分：1)
日志的问题是确保它们实际上不显示得太多，因为这是使系统完全停止的最可靠方法。
（日志文件已满，处理速度慢得多，因为要构建一些复杂的日志消息，一遍又一遍地重复日志条件，......）
然后，看起来FUNC_CALL和TRACE是预生产步骤的好名称，当你想看到，出于测试原因，确切地执行了什么。
但是在生产中应该只保留与功能相关的日志（通常是关于功能特性的警告和严重日志），甚至那些可能是危险的（特别是几千个实例的循环中的警告）。
实际上，无论您选择何种名称，您都必须在文档中包含有助于将您的应用程序投入生产的文件，以及您希望保持活动的确切日志级别以及哪些软件包。在做好之前需要多次尝试。
答案 2 :(得分：1)
在现有的日志记录框架（如log4j）中，严重性级别和程序中的位置是两个正交的概念。
Log4j定义了以下级别：TRACE，DEBUG，INFO，WARN，ERROR和FATAL，但也可以根据日志所在的类过滤输出。
答案 3 :(得分：1)
要记住关于日志的最重要的一点是，不应该将它们写成开发人员是受众。在几乎所有情况下，管理或操作人员都会读取日志。在许多情况下，他们将被另一个程序阅读。
因此，我总是建议通过所需响应的即时性来区分日志。安德烈的日志级别名称可能有点诙谐，但这个概念是正确的。日志级别应反映以下内容：
这最后一个有两个目的，一个是公开的，一个是微妙的。明显的目的是记录有关应用程序的运行状况和性能的一些有用信息。其次，定期输出到日志中可让操作员知道应用程序仍在正常运行。 （即，如果我在过去3小时内看到一个没有新条目的日志文件，我可能会认为它已经死了。）