如何在 Java 中进行日志记录

// java.util.logging
java.util.logging.Logger logger =  java.util.logging.Logger.getLogger(this.getClass().getName());
logger.info("This is an info message");
logger.severe("This is an error message"); // == ERROR
logger.fine("Here is a debug message"); // == DEBUG

FileHandler fileHandler = new FileHandler("status.log");
logger.addHandler(fileHandler);

// Log4j V1
org.apache.log4j.Logger logger = org.apache.log4j.Logger.getLogger(MyClass.getClass().getName());
logger.info("This is an info message");
logger.error("This is an error message");
logger.debug("Here is a debug message");

# contents of status.log

[INFO] 2012-11-02 21:57:53,662 MyLoggingClass - Application succesfully started on port 8080

# or

2010.03.23-mainThread --INFO -MyLoggingClass:Application succesfully started on port 8080

# or other endless possibilities

// Apache Commons Logging
org.apache.commons.logging.Log log = org.apache.commons.logging.LogFactory.getLog(MyApp.class);
log.info("This is an info message");
log.error("This is an error message");
log.debug("Here is a debug message");

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>1.7.30</version>
</dependency>

// SLF4J
org.slf4j.Logger logger = org.slf4j.LoggerFactory.getLogger(MyClass.class);
logger.info("This is an info message");
logger.error("This is an error message");
logger.debug("Here is a debug message"); //  you do not need 'logger.isDebugEnabled' checks anymore. SLF4J will handle that for you).

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-log4j12</artifactId>
    <version>1.7.30</version>
</dependency>

<dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>1.2.3</version>
</dependency>

<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>1.2.17</version>
</dependency>

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>log4j-over-slf4j</artifactId>
    <version>1.7.30</version>
</dependency>

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-api</artifactId>
    <version>2.14.0</version>
</dependency>

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.14.0</version>
</dependency>

// Log4j (version 2)
org.apache.logging.log4j.Logger logger = org.apache.logging.log4j.LogManager.getLogger(MyApp.class);
logger.info("This is an info message");
logger.error("This is an error message");
logger.debug("Here is a debug message");

// in class 1
private Logger LOG = LoggerFactory.getLogger(...);

// in class 2
private static final Logger LOGGER = ....;

// in class 3
private static Logger log = Logger.getLogger(...);

// in class 4
private Logger LOG_INSTANCE = ...;

// etc. etc.

此级别的任何内容都意味着您的 Java 进程无法继续，现在将终止。

最不有趣的日志级别，因为您不太可能在您的应用程序中使用它，而且诸如 SLF4J 之类的 API甚至不直接支持它。

请求已中止，根本原因需要尽快进行人工干预。

请求未得到令人满意的服务，需要尽快进行干预，但不一定立即进行。

要根据 ERROR 和 WARN 评估条目，您可以提出问题“需要采取什么行动”，如果这听起来不像是“天哪！现在就采取行动！” 事件类型，它会因不符合标准而降级到较低级别。

考虑一下您将闪亮的金融科技（银行）应用程序的新功能推向生产，不幸的是，每当用户尝试显示其银行帐户的最近交易时，就会触发臭名昭著的 Hibernate LazyLoadingException。这听起来像是一个非常强大的 OMG 情况，您会希望将这些错误记录为“错误” - 并触发适当的反应措施。

然后考虑一个批处理作业，它每天或每周导入事务。通常情况下，某些记录可能格式不正确，因此无法导入系统。有人，一个人，需要手动查看这些记录并修复它们。但这可能不像错误情况那样具有时间敏感性和紧迫性，因此您将选择使用 WARN 级别记录这些项目。

保持 ERROR 和 WARN 标签干净的主要原因是它使监控和对这些事件的反应变得更加简单。

或者简单地说：确保在凌晨 3 点唤醒您的操作人员，以发现正确的（某种）错误。

Info 是开发人员可能觉得最“舒服”的使用日志级别，在实践中你会发现开发人员打印出大量具有 INFO 级别的语句，从客户端活动（webapps）、进度信息（批处理作业）到相当复杂的，内部流程细节。

同样，决定什么应该是 INFO 什么应该是 DEBUG 可能是一条模糊的界线，但一般来说，流程详细信息应该与调试级别一起记录，而不是在信息中完全复制用户通过您的应用程序的旅程。日志。

从历史上看，将几乎所有内容都作为 INFO 注销的主要原因是，很难动态更改应用程序的日志级别，而不必重新启动（退回）所述应用程序。有时，开发人员和运营人员之间的组织孤岛也太大，无法轻松快速地更改日志级别。因此，开发人员选择安全起见，向控制台打印“更多”而不是更少，以便能够通过系统跟踪整个调用。

足够的介绍。让我们看一些例子。

显然，您可以使用 INFO 级别来注销应用程序状态，如下所示：

但是另一种考虑 INFO 级别的有趣方式是作为一个额外的（弱）错误案例：请求没有得到令人满意的服务，但解析细节已传递给请求者，不需要主动支持。

示例信息是“用户登录失败，用户名或密码不正确”。

您可能想要记录这些信息，因为用户（通过支持层）可能会向操作员询问他们为什么不能使用该应用程序的问题。操作人员将能够在日志文件中看到原因（即使用户已经通过应用程序前端获得了此信息）。

最后，还有两个日志级别，“调试”和“跟踪”。关于在线跟踪级别的必要性已经有很多激烈的讨论，并且 SLF4J 仅在其较晚（较新）版本之一中引入了跟踪日志级别 - 在许多社区请求之后。

再说一次，这两者之间的界限可能很模糊，但让我们快速浏览一下：

调试

内部流程的高级细节。这仅在调查特定问题期间打开，然后再次关闭。根据所使用的日志库，可能无法在不弹跳（重新启动）应用程序的情况下执行此操作，这可能是不可接受的。

TRACE - 比调试更多的细节或保留在特定环境中使用

您可以看到跟踪级别与调试级别一样详细，或者您可以决定将跟踪级别与某些环境（即 DEV 或 TEST 环境）结合起来，在那里开发人员可以发疯并随意注销他们想要的任何东西，知道“跟踪”在生产中将始终被禁用。（虽然这也可以通过不同的日志配置/配置文件轻松实现）

不过，如果您想看看一个勤奋使用 TRACE 日志记录框架的框架，那么只需看看Spring Framework。当使用 Spring 的事务管理时，您将只能看到真正的数据库事务边界，当您启用 TRACE 日志级别时：

在谈论日志文件时，一种常见的方法是为不同的用例使用单独的文件。这意味着应用程序通常会记录到多个日志文件。

您可能有一个error.log（文件名模式为 <appname>.<instance-name>.YYYYMMDD.ZZZ.error.log），由监控和警报系统以及操作人员使用。显然，您只需要该日志文件中的条目，即您想要发出警报的条目，即您的 ERROR 或 WARN 语句。

你可以有另一个日志文件名为info.log建立或status.log（与<应用程序名称>。<实例名称>的文件名模式.YYYYMMDD.ZZZ.status.log），其中包含有关应用进展或用户活动的上述信息，以及例如 trace.log 文件，只要您想对日志记录发疯。

当记录到单独的文件时，有一个命令行实用程序（如log-merger，或只是一个普通的旧 bash 脚本）来动态合并这些单独的日志文件以获得特定的时间戳是有意义的。

假设你有两个文件：

错误日志

和

状态日志

运行日志合并实用程序后，可以按如下方式即时查看它们：

您当然也可以选择从一开始就将所有内容都记录到一个文件中。

然而，有一个警告：经验表明开发人员经常错误地假设，仅仅因为日志语句具有时间/位置相关性 - 这可能会违反直觉，尤其是当我们刚刚谈到合并日志文件时。

下面是一个示例：假设您有一个使用 Hibernate 的应用程序。它启动到某个点然后挂起，您看不到更多日志消息。该应用程序根本无法启动。

您看到的最后一条日志消息如下：

很容易假设某些东西必须被 JPA 或 Hibernate 破坏，仅仅因为这是您的最后一条日志消息。事实上，它可能是 Hibernate，但您的应用程序也可能在尝试启动另一个部分/第三方框架时挂起，但尚未将内容注销。

因此，当您快速得出结论时要小心，这通常发生在高压情况下：当生产中出现严重错误时。通过位置/时间戳日志文件关联并不自动意味着它IS相关，只知道它CAN是。

MDC.put("requestId", "lknwelqk-12093alks-123nlkasn-5t234-lnakmwen");

logger.info("Hi, my name is: Slim Shady!");

[lknwelqk-12093alks-123nlkasn-5t234-lnakmwen] - Hi, my name is: Slim Shady!

2018-09-11 09:35:57.062 ERROR 15516 --- [           main] o.apache.catalina.core.StandardService   : Failed to start connector [Connector[HTTP/1.1-8080]]

org.apache.catalina.LifecycleException: Failed to start component [Connector[HTTP/1.1-8080]]
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:167)
        at org.apache.catalina.core.StandardService.addConnector(StandardService.java:225)
        at org.springframework.boot.web.embedded.tomcat.TomcatWebServer.addPreviouslyRemovedConnectors(TomcatWebServer.java:256)
        at org.springframework.boot.web.embedded.tomcat.TomcatWebServer.start(TomcatWebServer.java:198)
        at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.startWebServer(ServletWebServerApplicationContext.java:300)
        at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.finishRefresh(ServletWebServerApplicationContext.java:162)
        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:553)
        at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:140)
        at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:759)
        at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:395)
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:327)
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1255)
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1243)
        at com.marcobehler.MarcobehlerRootApplication.main(MarcobehlerRootApplication.java:26)
Caused by: org.apache.catalina.LifecycleException: Protocol handler start failed
        at org.apache.catalina.connector.Connector.startInternal(Connector.java:1020)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
        ... 13 common frames omitted
        ...

2018-09-11  17:44:49.179 ERROR 24745 --- [           main] o.s.b.d.LoggingFailureAnalysisReporter   :

***************************
APPLICATION FAILED TO START
***************************

Description:

Embedded servlet container failed to start. Port 8080 was already in use.

Action:

Identify and stop the process that's listening on port 8080 or configure this application to listen on another port.

从正常情况到本指南中讨论的设置（即统一日志记录实践、日志库等）需要一些时间。特别是如果您正在谈论多个现有的遗留应用程序，您都希望将它们迁移到某种程度相同的日志记录策略。即使不考虑管理支持等所有问题，您也需要为多个版本的所有应用程序缓慢迁移。

一种方法可能是开始时将所有内容都放入同一个日志文件中，当重新访问代码和日志记录配置时，它会修改所有日志记录以满足新标准。不幸的是，这只是一个粗略的指针，因为完整详细的迁移指南超出了本指南的范围。