有时候当我看到我的日志代码时，我会想我是否做得正确。也许没有明确的答案，但我有以下疑虑：
库类
我有几个库类可能会记录一些INFO消息。致命错误则报告为异常。当前我在我的类中使用一个静态的logger实例，并将类名作为日志名称。(Log4j's: Logger.getLogger(MyClass.class))
这是正确的方式吗？也许这个库类的用户不想要从我的实现中收到任何消息，或者希望将其重定向到特定应用程序的日志。我应该允许用户从“外部世界”设置一个logger吗？如何处理这种情况？
通用日志
在某些应用程序中，我的类可能希望将日志消息写入特定的日志，而不是由类名标识。(例如：HTTP请求日志) 如何最好地实现这样的操作？一个查找服务脑海中浮现...
你的规范相当标准，看起来还不错（在我看来）。
需要注意的一点是，过多的不必要的调试调用会导致内存碎片化，因此，在使用 Log4J（以及大多数其他 Java 日志记录框架）时，最终可能会得到类似以下的代码：
if (log.isDebugEnabled()) {
log.debug("...");
}
因为构造那个日志信息（你可能并没有使用它）可能会很昂贵，特别是如果要重复执行成千上万次。
你的INFO级别日志不应该太“啰嗦”（从你的说法来看，似乎并不是）。INFO消息应该是有意义和重要的，比如应用程序的启动和停止。这些是在遇到问题时可能需要知道的事情。Debug/fine级别的日志更多地用于诊断实际问题。Debug/fine级别的日志通常只在需要时打开。Info通常一直开启。
如果有人不想从您的类中获取特定的INFO消息，则当然可以更改您的log4j配置以不获取它们。在这方面，Log4j非常简单明了（相对于Java 1.4日志而言）。
至于你提到的HTTP问题，在我的经验中，通常情况下Java日志记录并不会出现这样的问题，因为通常只需要一个类负责你感兴趣的内容，所以你只需要在一个地方进行日志记录。在（我所经历的罕见情况下），如果您想要在看似不相关的类之间共享常见的日志消息，只需插入一些易于搜索的标记即可。
12:01:00,127 INFO FILE_NAME=file1.txt - Processing starts
12:01:00,127 DEBUG FILE_NAME=file1.txt, CUSTOMER_ID=756
12:01:00,129 INFO FILE_NAME=file1.txt - Processing ends
private static final Marker sqlMarker =
MarkerManager.getMarker("SQL");
private void method1() {
logger.debug(sqlMarker, "SELECT * FROM EMPLOYEE");
}
int i=5, j=10;
logger.info("Sample output {}, {}", ()->i, ()->j);
不要使用字符串拼接。使用参数化消息，如上所示。
使用动态重新加载日志配置，这样应用程序可以自动重新加载日志配置中的更改，而无需重新启动应用程序。
不要使用 printStackTrace() 或 System.out.println()。
应用程序在退出之前应关闭记录器：
LogManager.shutdown();
<?xml version="1.0" encoding="UTF-8"?>
<Configuration monitorinterval="300" status="info" strict="true">
<Properties>
<Property name="filePath">${env:LOG_ROOT}/SAMPLE</Property>
<Property name="filename">${env:LOG_ROOT}/SAMPLE/sample
</Property>
<property name="logSize">10 MB</property>
</Properties>
<Appenders>
<RollingFile name="RollingFileRegular" fileName="${filename}.log"
filePattern="${filePath}/sample-%d{yyyy-dd-MM}-%i.log">
<Filters>
<MarkerFilter marker="SQL" onMatch="DENY"
onMismatch="NEUTRAL" />
</Filters>
<PatternLayout>
<Pattern>%d{HH:mm:ss,SSS} %m%n
</Pattern>
</PatternLayout>
<Policies>
<TimeBasedTriggeringPolicy
interval="1" modulate="true" />
<SizeBasedTriggeringPolicy
size="${logSize}" />
</Policies>
</RollingFile>
<RollingFile name="RollingFileError"
fileName="${filename}_error.log"
filePattern="${filePath}/sample_error-%d{yyyy-dd-MM}-%i.log"
immediateFlush="true">
<PatternLayout>
<Pattern>%d{HH:mm:ss,SSS} %p %c{1.}[%L] [%t] %m%n
</Pattern>
</PatternLayout>
<Policies>
<TimeBasedTriggeringPolicy
interval="1" modulate="true" />
<SizeBasedTriggeringPolicy
size="${logSize}" />
</Policies>
</RollingFile>
</Appenders>
<Loggers>
<AsyncLogger name="com"
level="trace">
<AppenderRef ref="RollingFileRegular"/>
</AsyncLogger>
<Root includeLocation="true" level="trace">
<AppenderRef ref="RollingFileError" level="error" />
</Root>
</Loggers>
</Configuration>
需要的Maven依赖项在这里：
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.8.1</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.8.1</version>
</dependency>
<dependency>
<groupId>com.lmax</groupId>
<artifactId>disruptor</artifactId>
<version>3.3.6</version>
</dependency>
<!-- (Optional)To be used when working
with the applications using Log4j 1.x -->
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-1.2-api</artifactId>
<version>2.8.1</version>
</dependency>
if (LOGGER.isDebugEnabled()) ...应该被视为已经过时了。 - Aitch在@cletus的答案中，他谈到了这个问题
if (log.isDebugEnabled()) {
log.debug("val is " + value);
}
这个问题可以通过使用SLF4J来解决。它提供了格式化帮助。
log.debug("val is {}", value);
仅当级别为debug时，才会构造消息。
因此，目前建议使用SL4J及其伴侣日志记录器Logback，以获得更好的性能和稳定性，建议使用。
value 更改为方法：getValue()。并且该方法可能需要很长时间才能完成。那么 if (log.isDebugEnabled()) {log.debug("val is " + getValues());} 与 log.debug("val is {}", getValue()); 花费的成本是否相同？ - user2256235getValue()应该在传递给log.debug()之前被评估，因此几乎没有机会。滥用API，您可以创建一个自定义的Throwable并使用log.debug(String, Trowable)，但是log.isDebugEnabled后来看起来更清晰。有关澄清，请参见https://dev59.com/0lwY5IYBdhLWcg3w0Kgs。 - serv-inc关于实例化日志记录器，我使用Eclipse Java模板设置我的日志记录器取得了一些成功：
private static Logger log = Logger.getLogger(${enclosing_type}.class);
这样做可以避免JVM弄乱堆栈跟踪，并减少（或许微不足道的）创建堆栈跟踪所带来的开销。
使用这样的模板的好处在于，如果你想对日志记录器设置统一标准，你可以与团队共享它。
看起来IntelliJ支持相同的概念，用于表示封闭类型名称的模板变量。我没有看到在NetBeans中轻松实现它的方法。
我正在审查一个应用程序的日志级别，目前我发现了一种模式：
private static final Logger logger = Logger.getLogger(Things.class)
public void bla() {
logger.debug("Starting " + ...)
// Do stuff
...
logger.debug("Situational")
// Algorithms
for(Thing t : things) {
logger.trace(...)
}
// Breaking happy things
if(things.isEmpty){
logger.warn("Things shouldn't be empty!")
}
// Catching things
try {
...
} catch(Exception e) {
logger.error("Something bad happened")
}
logger.info("Completed "+...)
}
我可能从某个地方借鉴了这个方法，但它非常实用。
它可以减少在复制、粘贴和重构时混淆日志记录器的风险，而且还能节省输入时间。
在你的代码中：
private final static Logger logger = LoggerFactory.make();
...并在LoggerFactory中：
public static Logger make() {
Throwable t = new Throwable();
StackTraceElement directCaller = t.getStackTrace()[1];
return Logger.getLogger(directCaller.getClassName());
}
对于您所描述的log4j配置，首选选项是使用 log4j配置文件。这使得您的实现用户可以按照自己的实现需求稍后覆盖您的配置。请参见此处获取非常详细的入门指南。
对于任何日志API，我们至少有以下这些日志级别： ERROR > WARN > INFO > DEBUG > TRACE
我们可以使用每个日志级别来编写不同类型的日志，以更好地理解我们收集的跟踪信息：
Trace - 最好在每个方法的入口点处编写跟踪，包括方法名称和方法参数，以及在退出点处编写返回值/对象。
注意 - 最好遵循我们的编码准则并编写模块化的方法，这样我们就不需要在方法之间编写多个日志行以打印数据。
Debug - 我们将在方法中间添加调试日志，以显示哪个if / else / switch条件得到满足，以及我们从DB获取的数据并在方法中使用等等。 注意 - 不要添加作为参数发送或作为值返回的数据，因为这些数据已经通过Trace级别打印（尽量不要多次打印相同的日志）。
信息 - 假设客户端有日志级别为信息，那么如果他们看到日志，您想向他们显示什么消息和所有内容？在信息中添加这些内容。例如 - Blabla连接成功/已删除/已修改或Blabla链接已锁定/已解锁或blabla触发了blabla节点/节点的同步。
警告 - 这是一种罕见的情况，但编写代码时我们会遇到一些非正常情况，它只是由于任何陈旧条目或任何破坏而发生，通常我们忽略此情况，但如果我们添加这样的条件并在那里添加警告日志，将会更好。例如 - 我正在从一个带有列条件的表中查询，该列不是主键或唯一的，但被告知它将始终只返回一行，因此在这种情况下，我们应该编写一个条件，如if resultSet.size > 1，并添加一些更好的消息的警告日志。
错误 - 在每个未预期的 catch 块中都应该存在错误日志，并且它应该正确地打印完整的堆栈跟踪（而不仅仅是错误消息）。此外，在 catch 块中，人们会抛出一个新的 Exception，而没有记录现有的 Exception 跟踪，这种情况下，我们无法得到实际的异常点。因此，在每个 catch 块中编写带有完整堆栈跟踪的错误日志非常重要。
override def debug(msg: => AnyRef) = if (isDebugEnabled) logger.debug(msg)http://github.com/dpp/liftweb/blob/338119b8d7a76adcb9f45e9aa8a2b946d9c81118/lift-util/src/main/scala/net/liftweb/util/Log.scala - Blair Zajac