Shulou(Shulou.com)06/02 Report--

This article introduces the knowledge of "what are the core components of Java log". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Java Log Foundation

Java uses a custom, extensible method to output logs. Although Java provides a basic set of logging API through the java.util.logging package, you can easily use one or more other logging solutions. Although these solutions use different methods to create log data, their ultimate goal is the same, that is, to output logs from your application to the target address.

In this section, we will explore the principles behind Java logging and show how logging can make you a better Java developer.

Java Log component

The Java log API consists of the following three core components:

Loggers:Logger is responsible for capturing events and sending them to the appropriate Appender.

Appenders: also known as Handlers, is responsible for logging log events to the target location. Before outputting log events, Appenders uses Layouts to format the events.

Layouts: also known as Formatters, it is responsible for transforming and formatting data in log events. Layouts determines the final form of data in a log record.

When Logger logs an event, it forwards the event to the appropriate Appender. Appender then uses Layout to format the log records and send them to the console, file, or other target location. In addition, Filters allows you to further specify whether an Appender can be applied to a particular log record. Filters is not required in logging configuration, but it gives you more flexibility to control the flow of log messages.

Log framework

In Java, the output log requires one or more logging frameworks that provide the necessary objects, methods, and configurations to transmit messages. Java provides a default framework in the java.util.logging package. In addition, there are many other third-party frameworks, including Log4j, Logback, and tinylog. There are other development packages, such as SLF4J and Apache Commons Logging, which provide layers of abstraction that decouple your code from the logging framework, allowing you to switch between different logging frameworks.

How to choose a logging solution depends on the complexity of your logging requirements, compatibility with other logging solutions, ease of use, and personal preferences. Logback is based on previous versions of Log4j (version 1), so their feature sets are very similar. However, Log4j refers to some improvements in the * * version (version 2), such as support for multi-API and improved performance of the Disruptor library in use. And tinylog, due to the lack of some features, runs very fast, very suitable for small projects.

Another consideration is the level of support of the framework on various Java-based projects. For example, Android programs can only use Log4j, Logback, or third-party packages to log, and Apache Tomcat can use Log4j to record internal messages, but can only use version 1 Log4j.

Abstract layer

Abstraction layers such as SLF4J decouple your application from the logging framework. The application can choose to bind to a specific logging framework (such as java.util.logging, Log4j, or Logback) at run time by adding the corresponding logging framework to the application's classpath. If the logging framework configured in the classpath is not available, the abstraction layer immediately cancels the logic that invokes the log. The abstraction layer makes it easier for us to change the existing logging framework of the project, or to integrate projects that use different logging frameworks.

Configuration

Although all Java logging frameworks can be configured through code, most of the configuration is done through external configuration files. These files determine when and how log messages are processed, and the logging framework can load these files at run time. Most of the configuration examples provided in this section use configuration files.

Java.util.logging

The default Java logging framework stores its configuration in a file called logging.properties. In this file, each line is a configuration item, which uses the form of dot marks (dot notation). Java installs a global configuration file under the lib folder of its installation directory, but when you start a Java program, you can use a separate log configuration file by specifying the java.util.logging.config.file property, as well as create and store logging.properties files in your personal project.

The following example describes how to define an Appender in a global logging.properties file:

# default file output is in user's home directory.

Java.util.logging.FileHandler.pattern =% h/java%u.log

Java.util.logging.FileHandler.limit = 50000

Java.util.logging.FileHandler.count = 1

Java.util.logging.FileHandler.formatter = java.util.logging.XmlFormatter

Log4j

Log4j version 1 makes the syntax used is very similar to that of java.util.logging. Programs that use Log4j look for a file called log4j.properties in the project directory. By default, the Log4j configuration outputs all log messages to the console. Log4j also supports configuration files in XML format, and the corresponding configuration information is stored in the log4j.xml file.

Log4j version 2 supports configurations in XML, JSON, and YAML formats, which are stored in log4j2.xml, log4j2.json, and log4j2.yaml files, respectively. Similar to version 1, version 2 looks for these files in the project directory. You can find examples of the corresponding configuration files in each version of the documentation.

Logback

For Logback, most of the configuration is done in the logback.xml file, which uses XML syntax similar to Log4j. Logback also supports configuration through the Groovy language, and the configuration information is stored in the logback.groovy file. You can find the corresponding profile example through the link to each type of profile.

Loggers

Loggers is the object used to trigger log events, which is created and invoked in our Java application before Loggers passes the event to Appender. A class can contain multiple independent Loggers for different events, or you can embed a Loggers in a Loggers to create a Loggers hierarchy.

Create a new Logger

The process of creating a new Logger under different logging frameworks is more or less the same, although the specific method names may be different. When using java.util.logging, you can create a new Logger through the Logger.getLogger () .getLogger () method, which takes a string parameter that specifies the name of the Logger. If a Logger with the specified name already exists, you only need to return the existing Logger;. Otherwise, the program will create a new Logger. Usually, it is a good practice to use class.getName () as the name of the new Logger under the current class.

Logger logger = Logger.getLogger (MyClass.class.getName ())

Log events

Logger provides several ways to trigger log events. However, before you can record an event, you also need to set the level. The log level is used to determine the severity of the log, which can be used to filter log events or send them to different Appender (for more information, please refer to the "log level" section). The Logger.log () method requires a log level as a parameter in addition to log messages:

Logger.log (Level.WARNING, "This is a warning!")

Most logging frameworks provide shortcuts for outputting specific-level logs. For example, the following statement serves the same purpose as the above statement:

Logger.warning ("This is a warning!")

You can also prevent Logger from outputting messages below the specified log level. In the following example, Logger can only output log messages that are higher than the WARNING level and discard messages whose log level is lower than WARNING:

Logger.setLevel (Level.WARNING)

We have other ways to record additional information. Logp () (precise logging) allows you to specify the source class (source class) and method for each log record, while logrb () (logs that use resource bindings) allows you to specify resources to extract log messages. The entering () and exiting () methods let you record the method call information, thus tracking the execution of the program.

Appenders

Appenders forwards the log message to the desired output. It is responsible for receiving log events, formatting them using Layout, and then sending them to the corresponding destination. For a log event, we can use multiple Appenders to send events to different destinations. For example, we can send a simple log event to a specified recipient by mail while displaying it on the console.

Note that in java.util.logging, Appenders is called Handlers.

Add Appender

The Appender of most logging frameworks perform similar functions, but differ greatly in terms of implementation. If you use java.util.logging, you can use the Logger.addHandler () method to add Appender to the Logger. For example, the following code adds a new ConsoleHandler that outputs the log to the console:

Logger.addHandler (new ConsoleHandler ())

A more common way to add Appender is to use configuration files. If using java.util.logging,Appenders defines a comma-separated list, the following example outputs log events to the console and files:

Handlers=java.util.logging.ConsoleHandler, java.util.logging.FileHandler

If you use a XML-based configuration file, Appenders is added under the element, and if you use Log4j, you can easily add a new ConsoleAppender to send log messages to System.out:

Appenders Typ

This section describes some of the more general Appenders and how they are implemented in various logging frameworks.

ConsoleAppender

ConsoleAppender is one of the most commonly used Appenders, which simply displays log messages to the console. Many logging frameworks use it as the default Appender and are pre-configured in the basic configuration. For example, the configuration parameters for ConsoleAppender in Log4j are as follows.

Parameters.

Description

Filter

Used to determine whether the Appender is needed to handle log events

Layout

Used to determine how to format log records, "% m% n" is used by default, which displays one log record per line

Follow

Used to determine whether Appender needs to know about changes in the output (system.out or system.err), which does not need to be tracked by default

Name

The name used to set the Appender

IgnoreExceptions

Used to determine whether exceptions that occur during log event processing need to be logged

Target

Used to specify the output target location, using SYSTEM_OUT by default, but can also be modified to SYSTEM_ERR

The configuration file for a complete Log4j2 is as follows:

This configuration file creates a ConsoleAppender called MyAppender, which uses PatternLayout to format log events and then outputs them to System.out. The element configures the Loggers defined in the program code. Here, we have configured only one LoggerConfig, a Logger named Root, which will receive log messages with a log level above ERROR. If we use logger.error () to log a message, it will appear on the console, like this:

An unexpected error occurred.

You can also use Logback to achieve exactly the same effect:

% m% n

FileAppenders

FileAppenders writes log records to a file, which is responsible for opening and closing the file, appending log records to the file, and locking the file to prevent data from being corrupted or overwritten.

In Log4j, if you want to create a FileAppender, you need to specify the name of the target file, whether to append or overwrite, and whether the file needs to be locked when writing to the log:

...

...

In this way, we create a FileAppender called MyFileAppender and lock the file when we append the log to the file.

If you use Logback, you can also enable prudent mode to ensure file integrity. Although Prudent mode increases the time it takes to write to a file, it guarantees the integrity of the file when multiple FileAppender or even multiple Java programs write to the same file.

...

MyLog.log

True

True

% m% n

...

SyslogAppender

SyslogAppenders sends log records to the logging service of a local or remote system. Syslog is a service that receives log events from operating systems, processes, other services, or other devices. Events can range from diagnostic information to a user's failure to log in to hardware. Events for syslog are classified by device, which specifies the type of event being logged. For example, auth facility indicates that this event is related to security and authentication.

Both Log4j and Logback support SyslogAppenders built-in. In Log4j, when we create a SyslogAppender, we need to specify the host number, port number, and protocol that the syslog service listens to. The following example shows how to set up a device:

...

...

In Logback, we can achieve the same effect:

...

Localhost

five hundred and fourteen

Auth

...

Other Appender

We have introduced some of the frequently used Appenders, as well as many other Appender. They add new features or implement new functions based on some other Appender. For example, RollingFileAppender in Log4j extends FileAppender to automatically create new log files when specific conditions are met; SMTPAppender will send log contents in the form of mail; and FailoverAppender will automatically switch to other Appender during log processing, such as if one or more Appender fails.

If you want to learn more about other Appender, check out the Log4j Appender reference as well as the Logback Appender reference.

Layouts

Layouts converts the contents of logging from one form of data to another. The logging framework provides Layouts for plain text, HTML, syslog, XML, JSON, serialization, and other logs.

Note that Layouts is also known as Formatters in java.util.logging.

For example, java.util.logging provides two Layouts:SimpleFormatter and XMLFormatter. By default, ConsoleHandlers uses SimpleFormatter, which outputs plain text logging like this:

Mar 31, 2015 10:47:51 AM MyClass main

SEVERE: An exception occurred.

By default, FileHandlers uses XMLFormatter, and its output looks like this:

2015-03-31T10:47:51

1427903275893

0

MyClass

SEVERE

MyClass

Main

one

An exception occurred.

Configure Layout

We usually use configuration files to configure Layouts. Starting with Java 7, we can also use system property to configure SimpleFormatter.

For example, the most common Layouts in Log4j and Logback is PatternLayout. It allows you to decide which parts of the log event need to be output, which is done through the Conversion Pattern, which acts as a "placeholder" in the data of each log event. For example, the default PatternLayout for Log4j uses the following translation pattern:

% d {HH:mm:ss.SSS} converts the date into hours, minutes, seconds, and milliseconds,% level shows the severity of the log event,% C displays the name of the class that generated the log event,% t shows the current thread of the Logger,% m displays the time message, *,% n wraps for the next log event.

Change Layouts

If you use a different Layout in java.util.logging, you need to set the formatter property of Appender to the Layout you want. In the code, you can create a new Handler, call the setFormatter method, and then put the Handler on top of the Logger through the logger.AddHandler () method. The following example creates a ConsoleAppender that uses XMLFormatter to format the log instead of the default SimpleFormatter:

Handler ch = new ConsoleHandler ()

Ch.setFormatter (new XMLFormatter ())

Logger.addHandler (ch)

In this way, Logger outputs the following information to the console:

2015-03-31T10:47:51

1427813271000

0

MyClass

SEVERE

MyClass

Main

one

An exception occurred.

For more information, you can check the Log4j Layouts reference and the Logback Layouts reference.

Use a custom Layouts

Custom Layouts allows you to specify how Appender should output logging. Starting with Java SE 7, although you can adjust the output of SimpleLogger, there is a limitation that you can only adjust simple plain text messages. For more advanced formats, such as HTML or JSON, you need a custom Layout or a separate framework.

For more information on creating a custom Layouts using java.util.logging, you can check out the Java Logging: Formatters section of Jakob Jenkov's Java log guide.

Log level

The log level provides a way to classify and identify logs according to their severity. Java.util.logging provides the following levels, from severe to mild:

SEVERE (* level)

WARNING

INFO

CONFIG

FINE

FINER

FINEST (* level)

There are also two logging levels: ALL and OFF. ALL asks Logger to output all messages, while OFF turns off logging.

Set log level

After setting the log level, Logger automatically ignores log messages that are lower than the set level. For example, the following statement causes Logger to ignore log messages below the WARNING level:

Logger.setLevel (Level.WARNING)

Logger then logs any WARNING or higher-level log messages. We can also set the log level of Logger in the configuration file:

...

...

Conversion mode

The PatternLayout class in both Log4j and Logback supports transformation patterns, which determine how we extract information from each log event and how we format it. A subset of these patterns is shown below, and although these specific fields are the same for Log4j and Logback, not all fields use the same pattern. For more information, check out the PatternLayout documentation for Log4j and Logback.

Field name

Log4j/Logback mode

Message

% m

Level / severity

% p

Abnormal

% ex

Thread

% t

Logger

% c

Method

% M

For example, the following PatternLayout shows the log level in square brackets x, followed by the thread name and the log event message:

[% p]% t:% m

The following is an example of log output after using the above translation pattern:

[INFO] main: initializing worker threads

[DEBUG] worker: listening on port 12222 [INFO] worker: received request from 192.168.1.200 [ERROR] worker: unknown request ID from 192.168.1.200

Record stack trace information

If you've ever used exceptions in Java programs, you've probably seen stack traces. It provides a snapshot of method calls in the program, allowing you to locate exactly where the program is executed. For example, the following stack trace information is generated after the program attempts to open a file that does not exist:

[ERROR] main: Unable to open file! Java.io.FileNotFoundException: foo.file (No such file or directory)

At java.io.FileInputStream.open (Native Method) ~ [?: 1.7.0079]

At java.io.FileInputStream. (FileInputStream.java:146) ~ [?: 1.7.0079]

At java.io.FileInputStream. (FileInputStream.java:101) ~ [?: 1.7.0079]

At java.io.FileReader. (FileReader.java:58) ~ [?: 1.7.0079]

At FooClass.main (FooClass.java:47)

This example uses a class called FooClass, which contains a main method. In line 47 of the program, FileReader exclusively attempts to open a file named foo.file, and since there is no file named foo.file in the program directory, the Java virtual machine throws a FileNotFoundException. Because this method call is placed in the try-catch chunk, we can catch the exception and log it, or at least prevent the program from crashing.

Use PatternLayout to record stack trace information

At the time of this writing, in the * versions of Log4j and Logback, if there is no information in Layout about throwing exceptions, the% xEx (this stack trace information contains the package information for each method call) is automatically added to the PatternLayout. If the pattern for normal log information is as follows:

[% p]% t:% m

It becomes:

[% p]% t:% m%xEx

In this way, not only the error message will be recorded, but the complete stack trace information will also be recorded:

[ERROR] main: Unable to open file! Java.io.FileNotFoundException: foo.file (No such file or directory)

At java.io.FileInputStream.open (Native Method) ~ [?: 1.7.0079]

At java.io.FileInputStream. (FileInputStream.java:146) ~ [?: 1.7.0079]

At java.io.FileInputStream. (FileInputStream.java:101) ~ [?: 1.7.0079]

At java.io.FileReader. (FileReader.java:58) ~ [?: 1.7.0079]

At FooClass.main (FooClass.java:47)

Package query in% xEx is an expensive operation. If you record exception information frequently, you may encounter performance problems, such as:

/ /...

} catch (FileNotFoundException ex) {

Logger.error ("Unable to open file!", ex)

}

One solution is to explicitly include% ex in the schema, so that only stack trace information for exceptions is requested:

[% p]% t:% m%ex

Another way is to exclude all abnormal information in (in Log4j) by appending% xEx (none):

[% p]% t:% m%xEx {none}

Or use% nopex in Logback:

[% p]% t:% m%nopex

Output stack trace information using a structured layout

As you can see in the section "parsing multi-line stack trace information", it is most appropriate to use a structured layout to record station tracking information, such as JSON and XML. These layouts automatically decompose stack trace information according to core components so that we can easily export it to other programs or logging services. For the above station tracking information, if you use JSON format, some of the information is displayed as follows:

...

"loggerName": "FooClass"

Message: "Foo, oh no!"

"thrown": {

"commonElementCount": 0

"localizedMessage": "foo.file (No such file or directory)"

"message": "foo.file (No such file or directory)"

"name": "java.io.FileNotFoundException"

"extendedStackTrace": [{

"class": "java.io.FileInputStream"

"method": "open"

"file": "FileInputStream.java"

...

The record did not catch an exception

In general, we handle exceptions through capture. If an exception is not caught, it may cause the program to terminate. If you can keep any logs, this is a good way to help us debug why an exception occurred, so that you can find the root cause of the exception and resolve it. Here's how we can set up a default exception handler to log these errors.

There are two methods in the Thread class that we can use to specify an ExceptionHandler for uncaught exceptions:

SetDefaultUncaughtExceptionHandler allows you to handle any exception on any thread. SetUncaughtExceptionHandler allows you to set a different processing method for a given thread. ThreadGroup allows you to set a processing method. Most people use the default exception handling method.

The following is an example that sets a default exception handling method to create a log event. It requires you to pass in a UncaughtExceptionHandler:

Import java.util.logging.*

Public class ExceptionDemo {

Private static final Logger logger = Logger.getLogger (ExceptionDemo.class)

Public static void main (String [] args) {

Thread.setDefaultUncaughtExceptionHandler (new Thread.UncaughtExceptionHandler () {

Public void uncaughtException (Thread t, Throwable e) {

Logger.log (Level.SEVERE, t + "ExceptionDemo threw an exception:", e)

}

});

Class adminThread implements Runnable {

Public void run () {

Throw new RuntimeException ()

}

}

Thread t = new Thread (new adminThread ())

T.start ()

}

}

Here is an example of the output of an unhandled exception:

May 29, 2015 2:21:15 PM ExceptionDemo$1 uncaughtException

SEVERE: Thread [Thread-1 ~ 5 ~ main] ExceptionDemo threw an exception:

Java.lang.RuntimeException

At ExceptionDemo$1adminThread.run (ExceptionDemo.java:15)

At java.lang.Thread.run (Thread.java:745)

JSON

JSON (JavaScript Object Notation) is a format for storing structured data, which stores data as a collection of key-value pairs, similar to HashMap or Hashtable. JSON has portability and versatility, and most modern languages support it built-in or through prepared third-party class libraries.

JSON supports many basic data types, including strings, numbers, Boolean, arrays, and null. For example, you can use the following JSON format to represent a computer:

{

"manufacturer": "Dell"

"model": "Inspiron"

"hardware": {

"cpu": "Intel Core i7"

"ram": 16384

"cdrom": null

}

"peripherals": [

{

"type": "monitor"

"manufacturer": "Acer"

"model": "S231HL"

}

]

}

The portability of JSON makes it ideal for storing log records, and with JSON, Java logs can be read by any number of JSON interpreters. Because the data is already structured, parsing JSON logs is much easier than parsing plain text logs.

JSON in Java

For Java, there are a number of JSON implementations, one of which is JSON.simple. JSON.simple is lightweight, easy to use, and all conforms to the JSON standard.

If we want to convert the above computer object into a usable Java object, we can read the JSON contents from the file, pass it to JSON.simple, and return an Object, and then we can convert Object to JSONObject:

Object computer = JSONValue.parse (new FileReader ("computer.json"))

JSONObject computerJSON = (JSONObject) computer

In addition, to get information about key-value pairs, you can use any logging framework to record that a JSONObject,JSONObject object contains a toString () method, which converts JSON to text:

2015-05-06 14 model 54 S231HL 32878 INFO JSONTest main {"peripherals": [{"model": "S231HL", "manufacturer": "Acer", "type": "monitor"}], "model": "Inspiron", "hardware": {"cdrom": null, "ram": 16384, "cpu": "Intel Core i7"}, "manufacturer": "Dell"}

While this makes it easy to print JSONObject, if you use a structured Layouts, such as JSONLayout or XMLLayout, it can lead to unexpected results:

...

"message": "{" peripherals ": [{" model ":" S231HL "," manufacturer ":" Acer "," type ":" monitor "}]," model ":" Inspiron "," hardware ": {" cdrom ": null," ram ": 16384," cpu ":" Intel Core i7 "}," manufacturer ":" Dell "}"

...

JSONLayout in Log4j does not have built-in support for embedded JSON objects, but you can add a JSONObject field by creating a custom Layout that inherits or replaces JSONLayout. However, if you use a log management system, you need to keep in mind that many log management systems use predefined data types for certain fields. If you create a Layout and store JSONObject in the message field, it may conflict with the String data type used in the logging system. One solution is to store JSON data in one field, and then store string-type log messages in another field.

Other JSON libraries

There are many other JSON libraries besides JSON.simple,Java. JSON-java is a reference implementation developed by the creator of JSON that contains additional functionality to convert other data types, including web elements. But at present, there is no one to maintain and support JSON-java.

If you want to convert JSON objects to Java objects or vice versa, Google provides a Gson library. When using Gson, you can easily use the toJson () and fromJson () methods to parse JSON, which are used to convert Java objects to JSON strings and JSON strings to Java objects, respectively. Gson can even be applied to in-memory objects, allowing you to map to objects without source code.

Jackson

Jackson is a powerful, popular, feature-rich library that manages JSON objects in Java. Some frameworks even use Jackson as their JSONLayouts. Although it is large and complex, Jackson is easy to use for beginners and advanced users.

Logback inherits Jackson through the logback-jackson and logback-json-classic libraries, which are also part of the logback-contrib project. After integrating Jackson, you can export the log to any Appender in JSON format.

Logback Wiki explains in detail how to add JSON to logback, the example on the Wiki page uses LogglyAppender, and the configuration here can also be applied to other Appender. The following example shows how to write JSON-formatted log records to a file named myLog.json:

...

MyLog.json

...

You can also find more in-depth information about Jackson at FasterXML Wiki.

Learn more about JSON

You can learn more about JSON through the JSON home page, or through CodeAcademy by learning an interactive quick start tutorial (please note that this course is based on JavaScript, not Java). There are online tools such as JSONLint and JSON online editors that can help you parse, validate, and format JSON code.

NDC, MDC and ThreadContext

Tracking events can become difficult when dealing with multithreaded applications, especially web services. When generating log records for multiple users that exist at the same time, how can you tell which behavior is related to which log event? How to deal with logging when two users fail to open the same file or log in at the same time? You may need a way to associate logging with the only identifier in the program, which may be user ID, session ID, or device ID. And this is the opportunity for NDC, MDC and ThreadContext to use their talents.

NDC, MDC, and ThreadContext create log footprints (log trails) by adding * * data stamps to individual log records. These data stamps are also known as fish tagging, and we can distinguish logs by one or more * * values. These data stamps are managed at each thread level and continue until the end of the thread, or until the data stamp is deleted. For example, if your Web application generates a new thread for each user, you can use that user's ID to mark logging. This is a very useful method when you want to track specific requests, transactions, or users in a complex system.

Nested diagnostic context (NDC)

NDC or nested diagnostic context (Nested Diagnostic Context) is based on stack ideas, and information can be placed on or removed from the stack. The values in the stack can be accessed by Logger, and Logger does not need to show that any values are passed in the log method.

The following code example uses NDC and Log4j to associate a user name with a log record. NDC is a static class, so we can access its methods directly without instantiating a NDC object. In this example, the NDC.oush (username) and NDC.push (sessionID) methods store the current user name (admin) and session ID (1234) on the stack, while the NDC.pop () method removes some items from the stack, and the NDC.remove () method lets Java reclaim memory to avoid memory overflows.

Import java.io.FileReader

Import org.apache.Log4j.Logger

Import org.apache.Log4j.NDC

...

String username = "admin"

String sessionID = "1234"

NDC.push (username)

NDC.push (sessionID)

Try {

/ / tmpFile doesn't exist, causing an exception.

FileReader fr = new FileReader ("tmpFile")

}

Catch (Exception ex) {

Logger.error ("Unable to open file.")

}

Finally {

NDC.pop ()

NDC.pop ()

NDC.remove ()

}

The PatternLayout class of Log4j extracts values from NDC through% x converted characters. If a log event is triggered, the complete NDC stack is passed to Log4j:

After running the program, we can get the following output:

"admin 1234 ERROR-Unable to open file."

Map Diagnostic context (MDC)

The MDC or mapping diagnostic context is similar to NDC, except that MDC stores values in key-value pairs rather than in the stack. This allows you to easily reference a single key in Layout. The MDC.put (key,value) method adds a new key-value pair to the context, while the MDC.remove (key) method removes the specified key-value pair.

If we want to display the user name and session ID in the log as well, we need to use the MDC.put () method to store these two variables as key-value pairs:

Import java.io.FileReader

Import org.apache.Log4j.Logger

Import org.apache.Log4j.MDC

...

MDC.put ("username", "admin")

MDC.put ("sessionID", "1234")

Try {

/ / tmpFile doesn't exist, causing an exception.

FileReader fr = new FileReader ("tmpFile")

}

Catch (Exception ex) {

Logger.error ("Unable to open file!")

}

Finally {

MDC.clear ()

}

Once again, after we don't need to use Context, we need to use the MDC.clear () method to remove all key-value pairs from MDC, which reduces memory usage and prevents MDC from later trying to call data that has expired.

There is also a slight difference when accessing the value of MDC in the logging framework. For any key stored in the context, we can use% X (key) to access the corresponding value. In this way, we can use% X (username) and% X (sessionID) to get the corresponding user name and session ID:

"admin 1234 ERROR-Unable to open file!"

If we do not specify any keys, then the MDC context is passed to Appender as {(key, value), (key, value)}.

NDC and MDC in Logback

Unlike Log4j, Logback does not implement NDC built-in. But the slf4j-ext package provides a NDC implementation that uses MDC as the basis. Within Logback, you can use the MDC.put (), MDC.remove (), and MDC.clear () methods to access and manage MDC:

Import org.slf4j.MDC

...

Logger logger = LoggerFactory.getLogger (MDCLogback.class)

...

MDC.put ("username", "admin")

MDC.put ("sessionID", "1234")

Try {

FileReader fr = new FileReader ("tmpFile")

}

Catch (Exception ex) {

Logger.error ("Unable to open file.")

}

Finally {

MDC.clear ()

}

In Logback, you can apply the following pattern to Appender in Logback.xml, which outputs the same result as the above Log4j:

[% X {username}]% X {sessionID}%-5p -% m% n

"[admin] 1234 ERROR-Unable to open file."

Access to MDC is not limited to PatternLayout, for example, when using JSONFormatter, all values in MDC are exported:

{

"timestamp": "1431970324945"

"level": "ERROR"

"thread": "main"

"mdc": {

"username": "admin"

"sessionID": "1234"

}

"logger": "MyClass"

"message": "Unable to open file."

"context": "default"

}

ThreadContext

Version 2 of Log4j merged MDC and NDC into a single concept known as the Thread Context. The Thread Context is an evolution of MDC and NDC, presenting them respectively as the Thread Context Map and Thread Context Stack. The ThreadContext is managed through the static ThreadContext class, which is implemented similar to Log4j 1s MDC and NDC classes.

In Log4j version 2, MDC and NDC are merged into a separate component, which is called a thread context. Thread context is an evolution of MDC and NDC, which uses thread context Map to map thread context stack to represent MDC and NDC, respectively. We can manage thread context through the ThreadContext static class, which is similar in implementation to MDC and NDC in Log4j version 1.

When using the Thread Context Stack, data is pushed to and popped from a stack just like with NDC:

When using the thread context stack, we can add or remove data from the stack as NDC does:

Import org.apache.logging.Log4j.ThreadContext

...

ThreadContext.push (username)

ThreadContext.push (sessionID)

/ / Logging methods go here

ThreadContext.pop ()

...

When using thread context mapping, we can combine values and keys like MDC:

Import org.apache.logging.Log4j.ThreadContext

...

ThreadContext.put ("username", "admin")

ThreadContext.put ("sessionID", "1234")

/ / Logging methods go here

ThreadContext.clearMap ()

...

The ThreadContext class provides methods for clearing the stack, clearing MDC, and clearing all values stored in the context, corresponding to ThreadContext.clearAll (), ThreadContext.clearMap (), and ThreadContext.clearStack ().

As in MDC and NDC, we can use Layouts to access these values in the context of a thread. When using PatternLayout, the% x conversion pattern gets the value from the stack, and% X and% X (key) get the value from the diagram.

ThreadContext filtering

Some frameworks allow you to filter logs based on certain attributes. For example, the DynamicThresholdFilter of Log4j automatically adjusts the log level if the key meets certain conditions. For example, if we want to trigger TRACE-level log messages, we can create a key called trace-logging-enabled and add a filter to the log4j configuration file:

...

If ThreadContext contains a key called trace-logging-enabled, onMatch and onMismatch decide what to do with it. For onMatch and onMismatch, we have three options: ACCEPT, which handles the rules of the filter; DENY, which ignores the rules of the filter; and NEUTRAL, which defers to the next filter. In addition to these, we define a key-value pair, and when the value is true, we enable TRACE-level logging.

Now, when trace-logging-enabled is set to true, TRACE-level messages are logged even if the log level set by the root Logger is higher than TRACE,Appender.

You may also want to filter some specific logs into a specific Appender, and ThreadContextMapFilter is provided in Log4j to do this. If we want to restrict a particular Appender and log only TRACE-level messages for a user, we can add a ThreadContextMapFilter based on the username key:

...

For more information, you can check the DynamicThresholdFilter section of the Log4j and Logback documentation.

Markers

Markers allows you to add some data to individual log records. It can be used to group log records, trigger behaviors, or filter log records and output the results to a specified Appender. You can even combine Markers with ThreadContext to improve your ability to search and filter log data.

For example, suppose we have a class that can connect to the database, and if an exception occurs when opening the database, we need to log the exception as a fatal error. We can create a Marker named DB_ERROR and apply it to log events:

Import org.apache.logging.Log4j.Marker

Import org.apache.logging.Log4j.MarkerManager

...

Final static Marker DB_ERROR = MarkerManager.getMarker ("DATABASE_ERROR")

...

Logger.fatal (DB_ERROR, "An exception occurred.")

To display the Marker information in the log output, we need to add the% marker translation pattern to the PatternLayout:

[FATAL] DATABASE_ERROR: An exception occurred.

Or for Layouts in JSON and XML format, the Marker information is automatically included in the output:

...

"thread": "main"

"level": "FATAL"

"loggerName": "DBClass"

"marker": {

"name": "DATABASE_ERROR"

}

"message": "An exception occurred."

...

By automatically parsing and sorting the Marker data, the centralized log service can easily search the logs.

Markers filtering

The Marker filter allows you to decide which Marker is handled by which Logger. The marker field compares the Marker name in the log event, and if the name matches, the Logger performs subsequent actions. For example, in Log4j, we can configure an Appender to show only messages that use DB_ERROR Marker, which can be achieved by adding the following information to Appender in log4j2.xml:

If the Marker of an entry in the log record can match the marker field here, then onMatch will decide what to do with the record. If there is no match, or if there is no Marker information in the log record, then onMismatch will decide what to do with the record. For onMatch and onMismatch, there are three options: ACCEPT, which allows logging of events, DENY, which blocks events, and NEUTRAL, which does no processing of events.

In Logback, we need some more settings. First, you want to add a new EvaluatorFilter to Appender and specify the onMatch and onMismatch behavior as described above. Then, add an OnMarkerEvaluator and pass it the name of the Marker:

DATABASE_ERROR

ACCEPT

DENY

Use Markers with NDC, MDC and ThreadContext

The function of Marker is similar to that of ThreadContext in that it adds * * data to the log record, which can be accessed by Appender. If you combine the two, it will be easier for you to index and search the log data. It would be helpful if we could know when to use which technology.

NDC, MDC, and ThreadContext are used to tie related log records together. If your application handles multiple simultaneous users, ThreadContext allows you to combine a set of log records for a particular user. Because ThreadContext is different for each thread, you can use the same method to automatically group related log records.

Marker, on the other hand, is often used to mark or highlight special events. In the above example, we use DB_ERROR Marker to indicate the SQL-related exceptions that occur in the method. We can use DB_ERROR Marker to distinguish the handling of these events from other events, for example, we can use SMTP Appender to email these events to the database administrator.

This is the end of the content of "what are the core components of the Java log". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.