我们对log4j或者类似库中的日志类别使用什么约定？
通常，我们将类名视为类别，但是我们是否使用过其他系统？

日志级别如何？我们使用什么级别？在哪种情况下？

更新：正如你们中的一些人回答的那样，没有"正确"的答案。我只是在寻找人们使用不同的约定作为灵感的可能来源。

解决方案

我有3个级别：错误，警告和冗长的日志，它们一次告诉程序正在执行的操作。

我使用class + function作为上下文。

这些年来，我们对此进行了广泛的辩论，我们唯一同意的是没有完美的答案！

我们已经确定的是使用顶级类别名称来区分各大类别： "操作"与用户可能关心的任何事情有关，"内部"与开发人员只关心的事情有关，"审计"用于跟踪有趣的事件。

除此之外，我们尝试限制类别的数量，因为我们发现没有人在更详细的级别上打开/关闭它们。因此，我们尝试将它们分组为功能区域，而不是类名称。查询，更新等

日志记录取决于要求。如果我们要制作的日志仅保留有关是否存在任何问题(例如记录日志异常)的选项卡，那么我们可能只需要Class和Function名称。

但是，如果我们对创建和审核分类跟踪有功能要求，则必须将日志记录带入一个完全不同的详细程度。

我们有类+方法的调试日志。

我们还为某些操作提供了特定的日志，例如，在套接字上收到的连接。这些就是我所说的"事实日志"或者"审计跟踪日志"，它们记录的是单一类型的事物。当然，最近我只是将它们粘贴到数据库中，因为我们捕获的事实可能比一串文本复杂得多，它们可以包含特定时间的状态。即，我们为所需的每次审核滚动自己的审核跟踪记录机制。

调试时，我们将设置包/类，以便在log4j中调试到DEBUG，同时将rootlogger保留在ERROR，并且我们将拥有一个调试日志文件，该文件有望排除应用程序其他区域的所有gumpf日志记录。

但是，实际上并没有"正确的方法"来做这些事情。机制的组合看起来不错，但这取决于要记录的内容。

我同意Vaibhav的回答：我们必须知道为什么要伐木。

• 对于调试内部技术调试信息，可以使用log4j或者任何其他库(前提是它们的使用不会人为地增加函数的循环复杂性)
• 对于横向守时记录(跨整个代码)，某些面向方面的方法更适合
• 为了进行监视，我们需要进入另一个完整的日志记录级别，即KPI，需要通过发布总线(例如TIBCO)将这些信息记录到某种数据库中。

因此，仅对于内部日志记录，我们遵循一种非常标准的方法：

• 对于可能危害程序的任何错误均严重
• 有关内部进度的信息
• 可以了解一些子步骤的详细信息

粒度(对于经典内部日志记录)是主要类，负责处理的主要步骤。