Logback refers to the component that performs log event output as an Appender, and the implemented Appender must inherit ch.qos.logback.core.Appender Interface

The interfaces are as follows:

   package ch.qos.logback.core;  
   import ch.qos.logback.core.spi.ContextAware;  
   import ch.qos.logback.core.spi.FilterAttachable;  
   import ch.qos.logback.core.spi.LifeCycle;  
   public interface Appender<E> extends LifeCycle, ContextAware, FilterAttachable {  
     public String getName();  
     public void setName(String name);  
     void doAppend(E event);  
   }  

The real type of the template parameter of the doAppend (E event) method depends on the logback module. In the logback classic, E is ILoggingEvent, while in the logback access module, E is AcessEvent. doAppend is the most important part of the logback framework. It is responsible for outputting logs to the specified device in a certain format.

The appender will eventually be responsible for outputting the log, but they may also leave the log formatting to the Layout or Encoder object. Each Layout and Encoder belongs to only one appender. Some Appenders have built-in fixed log formats, so layout/encoder declarations are not required. For example, SockerAppender simply serializes log events and then transmits them over the network.

AppenderBase( ch.qos.logback.core.AppenderBase )

AppenderBase is an abstract class inherited from the appender interface. It is the parent class of all Appenders currently provided by Logback. Although it is an abstract class, it actually implements the doAppender () method.

Let's take a look at the implementation of its doAppender method

   public    synchronized void doAppend(E eventObject) {  
     // prevent re-entry.  
     if (guard) {  
       return;  
     }  
     try {  
       guard = true;  
       if (   !this.started) {  
         if (statusRepeatCount++ < ALLOWED_REPEATS) {  
           addStatus(new WarnStatus(  
               "Attempted to append to non started appender [" + name + "].",this));  
         }  
         return;  
       }  
       if (getFilterChainDecision(eventObject) == FilterReply.DENY) {  
         return;  
       }  
       // ok, we now invoke the derived class's implementation of append  
       this.append(eventObject);  
     } finally {  
       guard = false;  
     }  
   }  

As you can see, the doAppend method is declared as a synchronization level. This makes it safe for different threads to use the same appender. When the doAppend method is accessed by a thread, subsequent doAppend () calls cannot be executed until the thread exits the method.

Because synchronization is not applicable to all situations, logback also provides an asynchronous implementation ch.qos.logback.core.UnsynchronizedAppenderBase

The implementation of asynchronous doAppend is discussed below. See the hyperlink for the source code:

1. First, judge whether the guard is true. If it is true, exit immediately. If it is not true, it will be assigned to true in the next step. This is to prevent the same appender from outputting other logs before calling the append () method, resulting in repeated recursion. private ThreadLocal<Boolean> guard = new ThreadLocal<Boolean>(); The type of guard is a thread exclusive object
2. Then, judge whether started is true. If false, output warning information and return. After completing the configuration, the start () method is called to detect the related attribute configuration, and the appender is activated without any exception. If the appender has any exceptions, a warning message will be recorded in the logback internal state management.
3. After a series of filtering by the filter filter bound to it, the log event can be rejected and returned, or it can be received to enter the next step.
4. Call append()
5. Set guard=false to allow subsequent doAppend() function calls.

Down there! Let's talk about the Appender implementation of Logback.

OutputStreamAppender

OutputStreamAppender Attach log events to Java io. In OutputStream. This class is the parent class of ConsoleAppender and FileAppender, where FileAppender is the parent class of RollingFileAppender. But generally speaking, you can't instantiate this Appender.

First: ConsoleAppender

Like its name, this Appender outputs the log to the console, more accurately system Out or system err.

It contains the following parameters:

Look at a simple example

   <configuration>  
     <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">  
       <!-- encoders are assigned the type  
           ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->  
       <encoder>  
         <pattern>%-4relative [%thread] %-5level %logger{35} - %msg %n</pattern>  
       </encoder>  
     </appender>  
     <root level="DEBUG">  
       <appender-ref ref="STDOUT" />  
     </root>  
   </configuration>  

Second: FileAppender

Output the log to a file. The target file depends on the file attribute. Whether to append the output depends on the append attribute.

By default, each log event will be immediately flushed to the output stream. This default method is relatively safe for data and can avoid the risk of log loss in the buffer due to the abnormal exit of the application. However, in order to increase the log throughput, you can also set the immediateFulsh property in the Encoder to false. The Encoder will be described in the next article Explained in the blog post.

Here is a simple example:

   <configuration>  
     <appender name="FILE" class="ch.qos.logback.core.FileAppender">  
       <file>testFile.log</file>  
       <append>true</append>  
       <!-- encoders are assigned the type  
           ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->  
       <encoder>  
         <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>  
       </encoder>  
     </appender>  
     <root level="DEBUG">  
       <appender-ref ref="FILE" />  
     </root>  
   </configuration>  

We just use the < timestamp > tag to get the application startup time and use it as the file name of the new log file.

   <configuration>  
     <!-- Insert the current time formatted as "yyyyMMdd'T'HHmmss" under  
         the key "bySecond" into the logger context. This value will be  
         available to all subsequent configuration elements. -->  
 <timestamp key="bySecond" datePattern="yyyyMMdd'T'HHmmss"/> 
     <appender name="FILE" class="ch.qos.logback.core.FileAppender">  
       <!-- use the previously created timestamp to create a uniquely  
           named log file -->  
       <file>log-${bySecond}.txt</file>  
       <encoder>  
         <pattern>%logger{35} - %msg%n</pattern>  
       </encoder>  
     </appender>  
     <root level="DEBUG">  
       <appender-ref ref="FILE" />  
     </root>  
   </configuration>  

The < timestamp > tag contains two necessary attributes: key and datePattern, and an optional attribute: timeReference.

• key is the name of the attribute as the name of the variable
• datePattern needs to conform to the Convention in SimpleDateFormat
• timeReference can reference the values of other variables

   <configuration>  
     <timestamp key="bySecond" datePattern="yyyyMMdd'T'HHmmss"   
 
               timeReference="contextBirth"/>  
     ...  
   </configuration>  

Third: RollingFileAppender

RollingFileAppender inherits from FileAppender and provides the function of automatic switching of log target files. For example, date can be used as the condition for log segmentation.

RollingFileAppender has two important properties. RollingPolicy is responsible for how to switch logs and triggingpolicy is responsible for when to switch logs. In order for RollingFileAppender to work, these two properties must be set. However, if the implementation class of RollingPolicy also implements the triggingpolicy interface, only RollingPolicy can be set.

Here are its parameters:

1. In the student mode, the compression of log files is not allowed or supported.
2. The file property cannot be set.

Let's take a look at what RollingPolicy is:

RollingPolicy is actually responsible for switching and renaming log files.

The interfaces are as follows:

   package ch.qos.logback.core.rolling;   
 
   import ch.qos.logback.core.FileAppender;  
   import ch.qos.logback.core.spi.LifeCycle;  
   public interface RollingPolicy extends LifeCycle {  
     /*rollover Method to complete the archiving of the current log file */  
     public void rollover() throws RolloverFailure;  
     /*getActiveFileName Method is responsible for calculating the new log file name*/  
     public String getActiveFileName();  
     /*getCompressionMode Method is responsible for the compression mode*/   
 
     public CompressionMode getCompressionMode();  
     /*Set parent appender*/   
 
     public void setParent(FileAppender appender);  
   }  

RollingPolicy has several common implementation classes:

TimeBasedRollingPolicy

TimeBasedRollingPolicy Perhaps the most popular log scrolling strategy. Its rolling strategy is time-based, for example, according to days and months.

Timebasedlollingpolicy inherits the RollingPolicy and triggingpolicy interfaces.

It contains a required attribute: fileNamePattern and several optional attributes.

Here are some common fileNamePattern values:

TimeBaseRollingPolicy supports automatic compression of log files by setting the value of fileNamePattern gz or Open at the end of zip.

For many reasons, log scrolling is not clock driven, but depends on incoming log events. If fileNamePattern is set to YYY MM DD, if the first log event request occurs at 00:30 after 24:00, the real log rolling event occurs at 00:30. However, the implementation of this delay can be ignored.

The following is a simple configuration example:

   <configuration>  
     <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">  
       <file>logFile.log</file>  
       <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">  
         <!-- daily rollover -->  
         <fileNamePattern>logFile.%d{yyyy-MM-dd}.log</fileNamePattern>  
         <!-- keep 30 days' worth of history capped at 3GB total size -->  
         <maxHistory>30</maxHistory>  
         <totalSizeCap>3GB</totalSizeCap>  
       </rollingPolicy>  
       <encoder>  
         <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>  
       </encoder>  
     </appender>   
 
     <root level="DEBUG">  
       <appender-ref ref="FILE" />  
     </root>  
   </configuration>  

SizeAndTimeBasedRollingPolicy

Sometimes you not only want to specify the scrolling strategy by time, but also want to limit the size of each log file at the same time. The TimeBasedRoolingPolicy already provides the function of limiting the size of the total log file, while SizeAndTimeBasedRollingPolicy provides a more powerful ability to limit the size of a single log file.

Take a small example:

   <configuration>  
     <appender name="ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender">  
       <file>mylog.txt</file>  
 <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> 
         <!-- rollover daily -->  
         <fileNamePattern>mylog-%d{yyyy-MM-dd}.%i.txt</fileNamePattern>  
         <!-- each file should be at most 100MB, keep 60 days worth of history, but at most 20GB -->  
 <maxFileSize>100MB</maxFileSize> 
 
         <maxHistory>60</maxHistory>  
         <totalSizeCap>20GB</totalSizeCap>  
       </rollingPolicy>  
       <encoder>  
         <pattern>%msg%n</pattern>  
       </encoder>  
     </appender>  
     <root level="DEBUG">  
       <appender-ref ref="ROLLING" />  
     </root>  
   </configuration>  

It should be noted that in this example, fileNamePattern contains not only% d but also% i, both of which are necessary identifiers.% n i stands for log index number. Today's log has been expanded to a few copies, starting with 0.

In 1.1 Before version 7, SizeAndTimeBasedFNATP was used, and then SizeAndTimeBasedRollingPolicy was adopted. SizeAndTimeBasedRollingPolicy inherited SizeAndTimeBasedFNATP.

FixedWindowRollingPolicy the log rollingpolicy for fixed windows

FixedWindowRollingPolicy

Look at the following parameters first:

Take a small example:

   <configuration>  
     <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">  
       <file>test.log</file>  
 <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> 
 <fileNamePattern>tests.%i.log.zip</fileNamePattern> 
       <minIndex>1</minIndex> 
       <maxIndex>3</maxIndex> 
       </rollingPolicy>  
 <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> 
 <maxFileSize>5MB</maxFileSize> 
       </triggeringPolicy>  
       <encoder>  
         <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>  
       </encoder>  
     </appender>  
     <root level="DEBUG">  
       <appender-ref ref="FILE" />  
     </root>  
   </configuration>  

Next, let's look at the interface of triggering policies

TriggeringPolicy Responsible for when RollingFileAppender logs roll

Interface Description:

   package ch.qos.logback.core.rolling;  
   import java.io.File;  
   import ch.qos.logback.core.spi.LifeCycle;  
   public interface TriggeringPolicy<E> extends LifeCycle {  
       /*This method determines whether log scrolling occurs*/  
     public boolean isTriggeringEvent(final File activeFile, final <E> event);  
   }  

SizeBasedTriggeringPolicy

SizeBasedTriggeringPolicy Check the size of the current active log file. When it reaches a certain capacity, start log scrolling.

Sizebasedtriggingpolicy only receives one parameter, maxFileSize. The default value is 10MB

Acceptable B, KB, MB, GB

SocketAppender and SSLSocketAppender

So far, the appender we talked about can only output logs to local resources. In contrast, SocketAppender is designed to output logs to remote instances. SocketAppender outputs logs in clear text, while SSLSocketAppender transmits logs in encryption.

The type of log event being serialized is LoggingEventVO Inherits the ILoggingEvent interface. Remote logging is not intrusive. After deserialization reception, log events can be processed as if they were generated locally. Multiple sockerappenders can send logs to the same log server. SocketAppender does not need to be associated with a Layout because it just sends serialized log events to the remote log server. The sending operation of SocketAppender is based on TCP protocol. Therefore, if the remote server is reachable, the log will be processed by it. If the remote server is down or unreachable, the log will be discarded. When the remote server comes back to life, log sending will restart transparently. This transparent reconnection is achieved by a "connection" thread periodically trying to connect to the remote server.

Logging events is automatically buffered by TCP protocol. This means that if the network speed is faster than the generation speed of log requests, the network speed will not affect the application. However, if the network speed is too slow, the network speed will become a limit. In extreme cases, if the remote log server is unreachable, the application will eventually block. However, if the server can reach But the server is down. In this case, the application will not block, but just lose some log events.

It should be noted that even if the SocketAppender is not linked by the logger, it will not be recycled by gc because it still has references in the connector thread. A connector thread will exit only when the network is unreachable. In order to prevent this problem of garbage collection, we should display a statement to close the SocketAppender. It will survive for a long time and create / destroy a large number of SOCS The application of the SocketAppender instance should pay more attention to this problem. However, most applications can ignore this problem. If the JVM exits the SocketAppender before it is closed, or it is garbage collected, it may lead to the loss of some log data waiting in the pipeline that has not been transmitted. In order to prevent log loss, it is often a reliable way to call socket The close method of the appender or the stop method of LoggerContext is called before exiting the application.

Let's take a look at the properties of SocketAppender:

The standard Logback Classic contains four receivers that can be used to receive logging evnets from SocketAppender.

• ServerSocketReceiver, and the SSL enabled replica SSLSeverSocketReceiver. See the detailed configuration Receivers
• Simplessocketserver, and SimpleSSLSocketServer, which allows SSL replicas.

Use SimpleSocketServer on the server side

SimpleSocketServer requires two command line parameters, port and configFile path.

   java ch.qos.logback.classic.net.SimpleSocketServer 6000 \ src/main/java/chapters/appenders/socket/server1.xml 

Simple configuration example of SocketAppender on the client:

 <configuration> 
   <appender name="SOCKET" class="ch.qos.logback.classic.net.SocketAppender"> 
     <remoteHost>192.168.0.101</remoteHost> 
     <port>8888</port> 
     <reconnectionDelay>10000</reconnectionDelay> 
     <includeCallerData>true</includeCallerData> 
   </appender> 
   <root level="DEBUG"> 
     <appender-ref ref="SOCKET" /> 
   </root> 
 </configuration> 

Use simplesssockets server on the server side

   java -Djavax.net.ssl.keyStore=src/main/java/chapters/appenders/socket/ssl/keystore.jks \ -Djavax.net.ssl.keyStorePassword=changeit \ ch.qos.logback.classic.net.SimpleSSLSocketServer 6000 \ src/main/java/chapters/appenders/socket/ssl/server.xml 

SSLSocketAppender configuration

   <configuration debug="true">  
     <appender name="SOCKET" class="ch.qos.logback.classic.net.SSLSocketAppender">  
       <remoteHost>${host}</remoteHost>  
       <port>${port}</port>  
       <reconnectionDelay>10000</reconnectionDelay>  
       <ssl>  
         <trustStore>  
           <location>${truststore}</location>  
           <password>${password}</password>  
         </trustStore>  
       </ssl>  
     </appender>  
     <root level="DEBUG">  
       <appender-ref ref="SOCKET" />  
     </root>   
 
   </configuration>  

ServerSocketAppender and SSLSeverSocketAppender

The design concept of SocketAppender and SSLSockertAppender mentioned above is to let applications actively connect to the remote log server. However, sometimes it may be inconvenient or unscientific to let applications connect to the log server during initialization. Therefore, Logback also provides ServerSocketAppender and sslserverssocketappender. SocketAppender and ServerSocketAppender serialize Logging event uses the same method. The serialized objects are ILoggingEvent. The only difference is the master-slave conversion of connection initialization. SocketAppender is the active party to establish a connection with the log server, while ServerSocketAppender is passive. It listens to connection requests from the client.

ServerSocketAppender property sheet:

Take a small example:

   <configuration debug="true">  
     <appender name="SERVER"   
 
       class="ch.qos.logback.classic.net.server.ServerSocketAppender">  
       <port>${port}</port>  
       <includeCallerData>${includeCallerData}</includeCallerData>  
     </appender>  
     <root level="debug">  
       <appender-ref ref="SERVER" />  
     </root>   
 
   </configuration>  

The main difference between this configuration and the previous SocketAppender configuration is that the < remotehost > attribute is missing, because the ServerSocketAppender does not actively open the connection with the log server, but passively waits for the connection request from the remote host.

The following is a configuration example of SSLSocketAppender:

   <configuration debug="true">  
     <appender name="SERVER"   
 
       class="ch.qos.logback.classic.net.server.SSLServerSocketAppender">  
       <port>${port}</port>  
       <includeCallerData>${includeCallerData}</includeCallerData>  
       <ssl>  
         <keyStore>  
           <location>${keystore}</location>  
           <password>${password}</password>  
         </keyStore>  
       </ssl>  
     </appender>  
     <root level="debug">  
       <appender-ref ref="SERVER" />  
     </root>   
 
   </configuration>  

After the Socket log output, let's take a look at the mail based log output

SMTPAppender

SMTPAppender You can store the logging event in one or more fixed size buffers, and then send the logging event of appropriate size to the operation and maintenance personnel by mail when the event specified by the user arrives.

The detailed properties are as follows:

• OnErrorEvaluator
• OnMarkerEvaluator
• JaninoEventEvaluator
• GEventEvaluator (powerful)

cyclicBufferTracker CyclicBufferTracker Specify a cyclicBufferTracker to track the cyclicbuffer. It is based on the implementation of discriminator. If you do not specify it, it will be created by default CyclicBufferTracker , the default setting of cyclic buffer size is 256. You can also manually specify the default CyclicBufferTracker and modify the number of logging event s received by the default buffer through the < buffersize > property. username String sends mail account, the default is null password String sends mail password, and the default is null startls Boolean. If it is set to true, the appender will Try to use the STARTTLS command. If the server supports it, the plaintext connection will be converted into an encrypted connection. Note that the connection to the log server is not encrypted at first. Default: false If SSL boolean is set to true, the appender will connect to the log server using SSL. Default: false charsetEncoding String specifies the encoding format of mail information Default: UTF-8 localhost String if the SMTP host is not configured correctly, for example, it is not a complete address. In this case, the localhost property is required to provide the full path of the server (like the fully qualified name in java). For details, see com.sun.mail.smtp The mail.smtp.localhost attribute asynchronousSending boolean in determines whether email is sent asynchronously. Default: true, send asynchronously However, in some cases, it is necessary to send the error log email to the management personnel in a synchronous manner to prevent failure to maintain the application in time. includeCallerData boolean default: false Specifies whether to include callerData in the log sessionViaJNDI Boolean SMTPAppender relies on javax.mail.Session to send mail. By default, sessionViaJNDI is false. The creation of javax.mail.Session instance depends on the configuration information of SMTPAppender itself. If it is set to true, the reference of Session is obtained through JNDI during the creation of Session. This can make your code reuse better and the configuration more concise. It should be noted that if you use JNDI to obtain the Session object, you need to ensure that the two jar packages mail.jar and activation.jar are removed jndiLocation String if sessionViaJNDI is set to true, jndiLocation specifies the resource name of JNDI. The default value is: "java:comp/env/mail/Session"

SMTPAppender only keeps the latest 256 logging events in the circular buffer. When the buffer is slow, it will start to discard the oldest logging events. Therefore, SMTPAppender can deliver up to 256 log events in a message at any time. SMTPAppender depends on JavaMail API, which in turn depends on IOC framework (dependency injection).

Original text:

You can download the JavaMail API and the JavaBeans Activation Framework from their respective websites. Make sure to place these two jar files in the classpath before trying the following examples.

Look at a small example

   <configuration>   
 
     <appender name="EMAIL" class="ch.qos.logback.classic.net.SMTPAppender">  
       <smtpHost>ADDRESS-OF-YOUR-SMTP-HOST</smtpHost>  
       <to>EMAIL-DESTINATION</to>  
       <to>ANOTHER_EMAIL_DESTINATION</to> <!-- additional destinations are possible -->  
       <from>SENDER-EMAIL</from>  
       <subject>TESTING: %logger{20} - %m</subject>  
       <layout class="ch.qos.logback.classic.PatternLayout">  
         <pattern>%date %-5level %logger{35} - %message%n</pattern>  
       </layout>   
 
     </appender>  
     <root level="DEBUG">  
       <appender-ref ref="EMAIL" />  
     </root>   
 
   </configuration>  

Custom circular buffer size: considering the default size of 256 logs, it may not be applicable, and we can also customize it.

 <configuration> 
   <appender name="EMAIL" class="ch.qos.logback.classic.net.SMTPAppender"> 
     <smtpHost>${smtpHost}</smtpHost> 
     <to>${to}</to> 
     <from>${from}</from> 
     <subject>%logger{20} - %m</subject> 
     <layout class="ch.qos.logback.classic.html.HTMLLayout"/> 
    <cyclicBufferTracker class="ch.qos.logback.core.spi.CyclicBufferTracker"> 
   <!-- send just one log entry per email -->  
       <bufferSize>1</bufferSize> 
     </cyclicBufferTracker> 
   </appender> 
   <root level="DEBUG"> 
     <appender-ref ref="EMAIL" /> 
   </root> 
 </configuration> 

Event triggering mail log sending: by default, the Evaluator specifies OnErrorEvaluator, which indicates that log sending will be triggered when an event with level error or higher occurs.

We can also write our own log trigger, as long as we inherit from the EventEvaluator interface. It mainly implements the evaluate method. Here is an example:

Function: trigger log sending request every 1024 log events.

   package chapters.appenders.mail;  
   import ch.qos.logback.core.boolex.EvaluationException;  
   import ch.qos.logback.core.boolex.EventEvaluator;  
   import ch.qos.logback.core.spi.ContextAwareBase;  
   public class CounterBasedEvaluator extends ContextAwareBase implements EventEvaluator {  
     static int LIMIT = 1024;  
     int counter = 0;  
     String name;  
     public boolean evaluate(Object event) throws NullPointerException,  
         EvaluationException {  
       counter++;  
       if (counter == LIMIT) {  
         counter = 0;  
         return true;  
       } else {  
         return false;  
       }  
     }  
     public String getName() {  
       return name;  
     }  
     public void setName(String name) {  
       this.name = name;  
     }  
   }  

Using a custom Evaluator

   <configuration>  
     <appender name="EMAIL" class="ch.qos.logback.classic.net.SMTPAppender">  
       <evaluator class="chapters.appenders.mail.CounterBasedEvaluator" />  
       <smtpHost>${smtpHost}</smtpHost>  
       <to>${to}</to>  
       <from>${from}</from>  
       <subject>%logger{20} - %m</subject>  
       <layout class="ch.qos.logback.classic.html.HTMLLayout"/>  
     </appender>  
     <root level="DEBUG">  
       <appender-ref ref="EMAIL" />  
     </root>   
 
   </configuration>  

Label based Evaluator

When we talked about the SMTPAppender attribute earlier, we talked about the implementation of several evaluators provided by logback. Let's take a look at the use examples below.

Specify the label of the log event in the code

   Marker notifyAdmin = MarkerFactory.getMarker("NOTIFY_ADMIN");  
   logger.error(notifyAdmin,  
     "This is a serious an error requiring the admin's attention",  
     new Exception("Just testing"));  

The first is the OnmarkerEvaluator

   <configuration>  
     <appender name="EMAIL" class="ch.qos.logback.classic.net.SMTPAppender">  
       <evaluator class="ch.qos.logback.classic.boolex.OnMarkerEvaluator">  
         <marker>NOTIFY_ADMIN</marker>  
         <!-- you specify add as many markers as you want -->  
         <marker>TRANSACTION_FAILURE</marker>  
       </evaluator>  
       <smtpHost>${smtpHost}</smtpHost>  
       <to>${to}</to>  
       <from>${from}</from>  
       <layout class="ch.qos.logback.classic.html.HTMLLayout"/>  
     </appender>  
     <root>  
       <level value ="debug"/>  
       <appender-ref ref="EMAIL" />  
     </root>   
 
   </configuration>  

Then JaninoEventEvaluator

   <configuration>  
     <appender name="EMAIL" class="ch.qos.logback.classic.net.SMTPAppender">  
       <evaluator class="ch.qos.logback.classic.boolex.JaninoEventEvaluator">  
         <expression>  
           (marker != null) &&  
           (marker.contains("NOTIFY_ADMIN") || marker.contains("TRANSACTION_FAILURE"))  
         </expression>  
       </evaluator>   
 
       ... same as above  
     </appender>  
   </configuration>  

Finally, take a look at GEventEvaluator, which uses "?." Security caller, whose function will be called only when the object is not empty.

   <configuration>  
     <appender name="EMAIL" class="ch.qos.logback.classic.net.SMTPAppender">  
       <evaluator class="ch.qos.logback.classic.boolex.GEventEvaluator">  
         <expression>  
           e.marker?.contains("NOTIFY_ADMIN") || e.marker?.contains("TRANSACTION_FAILURE")  
         </expression>  
       </evaluator>   
 
       ... same as aboveffdfdvc  
     </appender>  
   </configuration>  

The following SMTPAppender uses SSL

   <configuration>  
     <appender name="EMAIL" class="ch.qos.logback.classic.net.SMTPAppender">  
       <smtpHost>smtp.gmail.com</smtpHost>  
       <smtpPort>465</smtpPort>  
       <SSL>true</SSL>  
       <username>YOUR_USERNAME@gmail.com</username>  
       <password>YOUR_GMAIL_PASSWORD</password>  
       <to>EMAIL-DESTINATION</to>  
       <to>ANOTHER_EMAIL_DESTINATION</to> <!-- additional destinations are possible -->  
       <from>YOUR_USERNAME@gmail.com</from>  
       <subject>TESTING: %logger{20} - %m</subject>  
       <layout class="ch.qos.logback.classic.PatternLayout">  
         <pattern>%date %-5level %logger{35} - %message%n</pattern>  
       </layout>   
 
     </appender>  
     <root level="DEBUG">  
       <appender-ref ref="EMAIL" />  
     </root>   
 
   </configuration>  

The following SMTPAppender uses STARTTLS

   <configuration>   
 
     <appender name="EMAIL" class="ch.qos.logback.classic.net.SMTPAppender">  
       <smtpHost>smtp.gmail.com</smtpHost>  
       <smtpPort>587</smtpPort>  
       <STARTTLS>true</STARTTLS>  
       <username>YOUR_USERNAME@gmail.com</username>  
       <password>YOUR_GMAIL_xPASSWORD</password>  
       <to>EMAIL-DESTINATION</to>  
       <to>ANOTHER_EMAIL_DESTINATION</to> <!-- additional destinations are possible -->  
       <from>YOUR_USERNAME@gmail.com</from>  
       <subject>TESTING: %logger{20} - %m</subject>  
       <layout class="ch.qos.logback.classic.PatternLayout">  
         <pattern>%date %-5level %logger - %message%n</pattern>  
       </layout>   
 
     </appender>  
     <root level="DEBUG">  
       <appender-ref ref="EMAIL" />  
     </root>   
 
   </configuration>  

SMTPAppender and MDCDiscriminator

As mentioned earlier, the default Discriminator distributes logging event s to different buffers according to the return value.

The following is an implementation of the mdcddiscriminator using one of the logback discriminators to complete the function of distinguishing log buffers by remote host ip

   <configuration>   
 
     <appender name="EMAIL" class="ch.qos.logback.classic.net.SMTPAppender">  
       <smtpHost>ADDRESS-OF-YOUR-SMTP-HOST</smtpHost>  
       <to>EMAIL-DESTINATION</to>  
       <from>SENDER-EMAIL</from>  
 <discriminator class="ch.qos.logback.classic.sift.MDCBasedDiscriminator"> 
       <key>req.remoteHost</key> 
       <defaultValue>default</defaultValue> 
     </discriminator> 
       <subject>${HOSTNAME} -- %X{req.remoteHost} %msg"</subject>  
       <layout class="ch.qos.logback.classic.html.HTMLLayout">  
         <pattern>%date%level%thread%X{req.remoteHost}%X{req.requestURL}%logger%msg</pattern>  
       </layout>  
     </appender>  
     <root>  
       <level level="DEBUG"/>  
       <appender-ref ref="EMAIL" />  
     </root>   
 
   </configuration>  

How to manage circular buffers in a busy system?

If you use a custom discriminator, you may create many new circular buffers, but maxNumberOfBuffers (default: 64). Whenever the number of buffers is greater than this value, the least recently updated buffer will be discarded by the "least recently updated algorithm". For security reasons, if the buffer is not updated within 30 minutes, it will also be discarded.

In an application with large TPS (transaction volume per second), if maxNumberOfBuffer is set too small, the number of logs per message will often be small. The reason is that the buffer may be created, destroyed and recreated. This cycle leads to a low amount of logs in the final buffer.

To prevent this vacillating effect, when SMTPAppender encounters a log event labeled "FINALIZE_SESSION", it will release the corresponding buffer. In this way, we can customize the buffer recycling strategy and no longer use the least recent update algorithm. You can also set the value of maxNumberOfBuffers to a larger value, such as 5121024, etc.

DBAppender

DBAppender Log events can be inserted into 3 data tables. They are logging_event，logging_event_property，logging_event_exception. These three data tables must exist before DBAppender works. Their SQL scripts can be found in the logback classic / SRC / main / Java / CH / QoS / logback / classic / db / script folder directory. This script is valid for most SQL databases. Except for a few, a few syntax differences need to be adjusted.

The following is the support information for logback and common databases:

Let's take a look at the table structure information of the three data tables:

logging_event

logging_event_property

logging_event_exception

Next, let's look at how to configure the database connection: the experiment shows that it takes about 10 milliseconds to insert a log without using the database connection pool technology, while it takes about 1 millisecond to use the connection pool. Therefore, it is recommended to use database connection pool to obtain database connection objects. The common one is C3P0.

The following is an example of using C3P0: (recommended)

   <configuration>  
     <appender name="DB" class="ch.qos.logback.classic.db.DBAppender">  
       <connectionSource  
         class="ch.qos.logback.core.db.DataSourceConnectionSource">  
         <dataSource  
           class="com.mchange.v2.c3p0.ComboPooledDataSource">  
           <driverClass>com.mysql.jdbc.Driver</driverClass>  
           <jdbcUrl>jdbc:mysql://${serverName}:${port}/${dbName}</jdbcUrl>  
           <user>${user}</user>  
           <password>${password}</password>  
         </dataSource>  
       </connectionSource>  
     </appender>  
     <root level="DEBUG">  
       <appender-ref ref="DB" />  
     </root>  
   </configuration>  

In addition to C3P0, you can also use the ch.qos provided by logback logback. core. db. DriverManagerConnectionSource

   <configuration  debug="true">  
     <appender name="DB" class="ch.qos.logback.classic.db.DBAppender">  
       <connectionSource class="ch.qos.logback.core.db.DataSourceConnectionSource">  
         <dataSource class="${dataSourceClass}">  
           <!-- Joran cannot substitute variables  
           that are not attribute values. Therefore, we cannot  
           declare the next parameter like the others.  
           -->  
           <param name="${url-key:-url}" value="${url_value}"/>  
           <serverName>${serverName}</serverName>  
           <databaseName>${databaseName}</databaseName>  
         </dataSource>  
         <user>${user}</user>  
         <password>${password}</password>  
       </connectionSource>  
     </appender>  
     <root level="INFO">  
       <appender-ref ref="DB" />  
     </root>   
 
   </configuration>  

Of course, you can also use JNDI to configure the data source, and then obtain the connection object from the JNDI connection pool

   <Context docBase="/path/to/app.war" path="/myapp">  
     ...  
     <Resource name="jdbc/logging"  
                 auth="Container"  
                 type="javax.sql.DataSource"  
                 username="..."  
                 password="..."  
                 driverClassName="org.postgresql.Driver"  
                 url="jdbc:postgresql://localhost/..."  
                 maxActive="8"  
                 maxIdle="4"/>  
     ...  
   </Context>  
   <configuration debug="true">  
     <appender name="DB" class="ch.qos.logback.classic.db.DBAppender">  
       <connectionSource class="ch.qos.logback.core.db.JNDIConnectionSource">  
         <!-- please note the "java:comp/env/" prefix -->  
         <jndiLocation>java:comp/env/jdbc/logging</jndiLocation>  
       </connectionSource>  
     </appender>  
     <root level="INFO">  
       <appender-ref ref="DB" />  
     </root>   
 
   </configuration>  

The following is the configuration of non connection pool. Just have a look:

This configuration will retrieve the database connection object every time the log is inserted.

   <configuration>  
     <appender name="DB" class="ch.qos.logback.classic.db.DBAppender">  
       <connectionSource class="ch.qos.logback.core.db.DriverManagerConnectionSource">  
         <driverClass>com.mysql.jdbc.Driver</driverClass>  
         <url>jdbc:mysql://host_name:3306/datebase_name</url>  
         <user>username</user>  
         <password>password</password>  
       </connectionSource>  
     </appender>  
     <root level="DEBUG" >  
       <appender-ref ref="DB" />  
     </root>  
   </configuration>  

SyslogAppender

SyslogAppender It is a very simple protocol: a syslog sender sends a small message to the syslog receiver. This receiver is usually called syslog daemon or syslog server. logback can send messages to remote receivers

Here are the configuration items

A small example

   <configuration>  
     <appender name="SYSLOG" class="ch.qos.logback.classic.net.SyslogAppender">  
       <syslogHost>remote_home</syslogHost>  
       <facility>AUTH</facility>  
       <suffixPattern>[%thread] %logger %msg</suffixPattern>  
     </appender>  
     <root level="DEBUG">  
       <appender-ref ref="SYSLOG" />  
     </root>  
   </configuration>  

When testing this example, you need to allow the remote syslog daemon to receive external request s. The default is rejected.

SiftingAppender

By name, SiftingAppender provides the function of filtering logs. You can filter the logs through the data of users' sessions, and then distribute them to different log files.

Let's take a look at an example to illustrate:

   <configuration>  
     <appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender">  
       <!-- in the absence of the class attribute, it is assumed that the  
           desired discriminator type is  
           ch.qos.logback.classic.sift.MDCBasedDiscriminator -->  
       <discriminator>  
         <key>userid</key>  
         <defaultValue>unknown</defaultValue>  
       </discriminator>  
       <sift>  
         <appender name="FILE-${userid}" class="ch.qos.logback.core.FileAppender">  
           <file>${userid}.log</file>  
           <append>false</append>  
           <layout class="ch.qos.logback.classic.PatternLayout">  
             <pattern>%d [%thread] %level %mdc %logger{35} - %msg%n</pattern>  
           </layout>  
         </appender>  
       </sift>  
     </appender>  
     <root level="DEBUG">  
       <appender-ref ref="SIFT" />  
     </root>  
   </configuration>  
   logger.debug("Application started");  
   MDC.put("userid", "Alice");  
   logger.debug("Alice says hello");  

This example stores logs with different user IDs in different log files by setting the MDC attribute.

SiftingAppender accomplishes these functions by creating a built-in appender, using < sift > < appender > < / appender > < / sift >. The SiftingAppender is responsible for managing the life cycle of these child Appenders. The SiftingAppender automatically closes and removes expired Appenders. If the built-in appender has not performed log output within the time specified by the timeout attribute, it will be considered expired.

In this example, if the discriminator is not specified, mdcbaseddediscriminator will be used by default. If the value of the specified key is null, then < DefaultValue > will be used

SitingAppender has the following two properties

Setting an appropriate timeout and maxAppenderCount is not so easy. If it is too small, the built-in appender will be destroyed shortly after birth, and if it is too large, it will consume too many resources. Therefore, in many cases, we can also manually close the built-in appender by generating a marker to finalize_ The session log event. When the SiftingAppender sees the log event of this tag, it will end the bound appender. However, the destruction of the appender is not real-time, but wait a few seconds to prevent the loss of unprocessed logs. This is similar to the four wave process of TCP protocol.

Look at a small example

   import org.slf4j.Logger;  
   import static ch.qos.logback.classic.ClassicConstants.FINALIZE_SESSION_MARKER;  
     void job(String jobId) {  
       MDC.put("jobId", jobId);  
       logger.info("Starting job.");  
       ... do whather the job needs to do  
       // will cause the nested appender reach end-of-life. It will  
       // linger for a few seconds.  
       logger.info(FINALIZE_SESSION_MARKER, "About to end the job");  
       try {  
         .. perform clean up  
       } catch(Exception e);   
 
         // This log statement will be handled by the lingering appender.  
         // No new appender will be created.  
         logger.error("unexpected error while cleaning up", e);  
       }  
     }  

AsyncAppender

Async appender records ILoggingEvents asynchronously. It is only equivalent to an event allocator, so it needs to cooperate with other Appenders to make a difference.

Note that AsyncAppender caches event s in BlockingQueue , a worker thread created by AsyncAppender will always get events from the head of the queue and then assign them to the adder uniquely associated with AsyncAppender. By default, if 80% of the queue is full, AsyncAppender will discard the log events of TRACE, DEBUG and INFO.

When the application is closed or redeployed, the AsyncAppender must be closed to stop, recycle and reuse the worker thread, and refresh the logging events in the buffer queue. What if you close AsyncAppender? You can close all Appenders, including AsyncAppender, by closing LoggerContext. AsyncAppender will wait for worker thread to refresh all log events within the time set by maxFlushTime property. If you find that the buffered event is discarded when the LoggerContext is closed, you may need to increase the waiting time. Setting maxFlushTime to 0 means that AsyncAppender waits until the worker thread flushes out all buffered events.

According to the exit mode of the JVM, the work of the worker thread in processing the buffered events can be interrupted, resulting in the stranding of the remaining unprocessed events. The common reason for this phenomenon is when the LoggerContext is not completely closed, or when the JVM terminates those atypical control flows (unknown). In order to avoid the interruption of the working thread due to these conditions, a shutdown hook can be inserted when the JVM is running. The function of this hook is to close the LoggerContext when the JVM starts shutdown.

The following is the property sheet of AsyncAppender

By default, the maximum capacity of event queue is 256. If the queue is full, your application will be blocked until the queue can accommodate new logging event s. Therefore, when the AsyncAppender work queue is full, it can be called pseudo synchronization.

The following four situations can easily lead to the occurrence of AsyncAppender pseudo synchronization status:

• There are a large number of threads in the application
• A large number of logging events are generated per second
• Each logging event contains a large amount of data
• High latency in child Appenders

In order to avoid pseudo synchronization, improving queueSizes is generally effective, but it consumes the available memory of the application.

Having said so much, let's take a look at a small example

   <configuration>  
     <appender name="FILE" class="ch.qos.logback.core.FileAppender">  
       <file>myapp.log</file>  
       <encoder>  
         <pattern>%logger{35} - %msg%n</pattern>  
       </encoder>  
     </appender>  
     <appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">  
       <appender-ref ref="FILE" />  
     </appender>  
     <root level="DEBUG">  
       <appender-ref ref="ASYNC" />  
     </root>  
   </configuration>  

Write your own Appender

You can simply create your own appender by inheriting the parent class AppenderBase. AppenderBase has implemented support for filters, status and other functions shared by most Appenders. All we have to do is implement the append(Object evenObject) method.

Let's take an example

   package chapters.appenders;  
   import java.io.IOException;  
   import ch.qos.logback.classic.encoder.PatternLayoutEncoder;  
   import ch.qos.logback.classic.spi.ILoggingEvent;  
   import ch.qos.logback.core.AppenderBase;  
   public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> {  
     static int DEFAULT_LIMIT = 10;  
     int counter = 0;  
     int limit = DEFAULT_LIMIT;  
     PatternLayoutEncoder encoder;  
     public void setLimit(int limit) {  
       this.limit = limit;  
     }  
     public int getLimit() {  
       return limit;  
     }  
     @Override  
     public void start() {  
       if (this.encoder == null) {  
         addError("No encoder set for the appender named ["+ name +"].");  
         return;  
       }  
       try {  
         encoder.init(System.out);  
       } catch (IOException e) {  
       }  
       super.start();  
     }  
     public void append(ILoggingEvent event) {  
       if (counter >= limit) {  
         return;  
       }  
       // output the events as formatted by our layout  
       try {  
         this.encoder.doEncode(event);  
       } catch (IOException e) {  
       }  
       // prepare for next event  
       counter++;  
     }  
     public PatternLayoutEncoder getEncoder() {  
       return encoder;  
     }  
     public void setEncoder(PatternLayoutEncoder encoder) {  
       this.encoder = encoder;  
     }  
   }  

This example tells us two points

1. All properties are set transparently in the configuration file through setter/getter. The start() method will be called automatically when logback reads the configuration file configuration, and is responsible for checking whether the relevant properties are set incorrectly.
2. AppenderBase.doAppend() will call the append() method of the subclass to complete the log output. In particular, you can also call layout to format the log in the append() method.

After talking about so many things about logbakc classic, let's take a look at logback access

Most appenders existing in logback classic have similar equivalents in logback access. Most of them are similar, except that ILogginEvent becomes AccessEvent. Let's talk about their differences

In SMTPAppender, the Evaluator attribute is used by default. URLEvaluator is used. Let's take a look at an example

   <appender name="SMTP"  
     class="ch.qos.logback.access.net.SMTPAppender">  
     <layout class="ch.qos.logback.access.html.HTMLLayout">  
       <pattern>%h%l%u%t%r%s%b</pattern>  
     </layout>  
 <Evaluator class="ch.qos.logback.access.net.URLEvaluator"> 
     <URL>url1.jsp</URL> 
     <URL>directory/url2.html</URL> 
   </Evaluator> 
     <from>sender_email@host.com</from>  
     <smtpHost>mail.domain.com</smtpHost>  
     <to>recipient_email@host.com</to>  
   </appender>  

When the current URL matches one of the paths specified by multiple < URL > tags, it will trigger the sending of an email.

In DBAppender, there are also differences. First, only two tables are used, access_event and access_event_header. Their creation sql scripts can be found in logback access / SRC / main / Java / CH / QoS / logback / access / db / script.

See the structure in the table below

access_event

access_event_header

In DBAppender, all attributes supported in the classic module are supported in the access module, and access also provides one more attribute

Here is an example

   <configuration>  
     <appender name="DB" class="ch.qos.logback.access.db.DBAppender">  
       <connectionSource class="ch.qos.logback.core.db.DriverManagerConnectionSource">  
         <driverClass>com.mysql.jdbc.Driver</driverClass>  
         <url>jdbc:mysql://localhost:3306/logbackdb</url>  
         <user>logback</user>  
         <password>logback</password>  
       </connectionSource>  
       <insertHeaders>true</insertHeaders>  
     </appender>  
     <appender-ref ref="DB" />  
   </configuration>  

In the SiftingAppender, although most of them are similar, the default value of Discriminator is different. Logback access uses AccessEventDiscriminator by default instead of mdcbaseddediscriminator

The following is the Discriminator section of its configuration

   <Discriminator class="ch.qos.logback.access.sift.AccessEventDiscriminator">  
         <Key>id</Key>  
         <FieldName>SESSION_ATTRIBUTE</FieldName>  
         <AdditionalKey>username</AdditionalKey>  
         <defaultValue>NA</defaultValue>  
   </Discriminator>  

The value of < fieldname > can be set to COOKIE, REQUEST_ATTRIBUTE, SESSION_ATTRIBUTE, REMOTE_ ADDRESS, LOCAL_ PORT, REQUEST_ One of the URIs. And cookie, request_ ATTRIBUTE, SESSION_ If attribute is set to three values, the < AdditionalKey > ID must be set to get the attribute. When the value corresponding to the key set by AdditionalKey is Null, the value set by < DefaultValue > is used as the default value. The value set by < key > is equivalent to the obtained value. The key obtained in the child appender is equivalent to the key in the key value key value pair.

Here is a complete example:

   <configuration>  
     <appender name="SIFTING" class="ch.qos.logback.access.sift.SiftingAppender">  
       <Discriminator class="ch.qos.logback.access.sift.AccessEventDiscriminator">  
         <Key>id</Key>  
         <FieldName>SESSION_ATTRIBUTE</FieldName>  
         <AdditionalKey>username</AdditionalKey>  
         <defaultValue>NA</defaultValue>  
       </Discriminator>  
       <sift>  
         <appender name="ch.qos.logback:logback-site:jar:1.1.7" class="ch.qos.logback.core.FileAppender">  
           <file>byUser/ch.qos.logback:logback-site:jar:1.1.7.log</file>  
           <layout class="ch.qos.logback.access.PatternLayout">  
             <pattern>%h %l %u %t \"%r\" %s %b</pattern>  
           </layout>  
         </appender>  
       </sift>  
     </appender>  
     <appender-ref ref="SIFTING" />  
   </configuration>