What conventions do you use for log categories in log4j or similar libraries ? Usually you see class names as categories, but have you used other systems ?
What about log levels ? What levels do you use and in which case ?
Update: as some of you replied, there is no 'right' answer. I'm just looking for what different conventions people use as a possible source of inspiration.
我有 3 个级别：错误、警告和详细日志，告诉程序一次在做什么。
我使用类+函数作为上下文。
我同意Vaibhav 的回答：你必须知道你为什么要记录。
因此，仅对于内部日志记录，我们遵循一种非常标准的方法：
粒度（对于经典的内部日志记录）是主要类，负责流程的主要步骤。
多年来，我们对此进行了广泛的辩论，我们唯一同意的是，没有完美的答案！
我们已经确定的是使用顶级类别名称来区分广泛的类别：例如，“操作”与用户可能关心的任何事情有关，“内部”与只有开发人员会关心的事情有关，“审计”用于跟踪有趣的事件。
除此之外，我们试图限制类别的数量，因为我们发现没有人在更详细的级别上打开/关闭它们。因此，我们尝试将它们分组到功能区域中，而不是类名，例如。查询、更新等
日志记录取决于您的要求。如果您制作的日志只是简单地关注是否存在任何问题（例如记录异常），那么您可能只需要类和函数名称。
但是，如果您有创建和审核各种跟踪的功能需求，则必须将日志记录带到完全不同的详细级别。
我们有类+方法的调试日志。
对于某些操作，我们也有特定的日志，例如，在套接字上接收到的连接。这些就是我所说的“事实日志”或“审计跟踪日志”，它们记录单一类型的事情。当然，最近我只是将这些数据保存到数据库中，因为您捕获的事实可能比一串文本复杂得多，它们可以包括特定时间的状态。即，您为您需要的每个审计滚动您自己的审计跟踪记录机制。
调试时，我们将在 log4j 中将我们正在调试的包/类设置为 DEBUG，同时将 rootlogger 保留为 ERROR，并且我们将有一个调试日志文件，希望能够排除来自应用程序其他区域的所有 gumpf 日志记录。
但实际上并没有“正确的方法”来做这些事情。机制的组合似乎不错，但这取决于您要记录的内容。