Spring boot uses logback, logstash and elk to record log files

Under spring boot, try to log to logstash using log4j, and add log4j in Src / main / resources directory The custom output log file from the properties file failed. In application Configuring logging path in YML succeeded in printing logs, but failed to debug successfully. Logs are recorded in files. For online reference, it is said that spring boot uses logback to record logs by default. Log4j failed after many attempts, so logback was used to record. Finally, the test was successful.

1. Doubts about the path of spring boot log file?

Logging. Is also configured Path and logging The file attribute is configured as follows:

Test. Is only generated in the project root path The log file will not be generated under the specified path (the expected log path is: logging. Path + logging. File).

Reason: logging. In spring boot Path and logging Only one of the two properties, file, needs to be configured. If it is configured at the same time, use logging File attribute.

When loggin. Is configured When the path property is, spring. Net will be generated under this path Log file, i.e. the default log file name spring. Is used at this time log。

When loggin. Is configured File attribute, a log file with the specified name will be generated under the specified path. The default is the relative path of the project, which can be logging File specifies the absolute path.

logging:

2. Reasons for logback replacing log4j:

Excerpt from the following on the network:

Logback and log4j are very similar. If you are familiar with log4j, you will be handy with logback soon. Here are some advantages of logback over log4j:

1. The kernel of logback is rewritten faster, and the performance is improved by more than 10 times on some key execution paths. Moreover, not only the performance of logback is improved, but also the initial memory load is smaller.

2. Very fully tested logback has been tested for several years and countless hours. The logback test is at a completely different level. In the author's view, this is a simple and important reason to choose logback instead of log4j.

3. Logback classic naturally implements slf4j. Logback classic implements slf4j. You can't feel logback classic when using slf4j. Moreover, because logback classic naturally implements slf4j, it is very easy to switch to log4j or others. It only needs to be provided as another jar package, and there is no need to move the code implemented through slf4 japi.

4. The official website has more than 200 pages of documents.

5. Automatically reload the configuration file. When the configuration file is modified, logback classic can automatically reload the configuration file. The scanning process is fast and safe, and it does not need to create another scanning thread. This technology fully ensures that the application can run happily in the Jee environment.

6. Lilith is the observer of log events, which is similar to the chainsaw of log4j. Lilith can also handle a large number of log data.

7. Cautious mode and very friendly recovery. In cautious mode, multiple fileappender instances run in multiple JVMs and can safely write the same log file. Rollingfileappender has some limitations. Logback's fileappender and its subclasses, including rollingfileappender, can recover from I / O exceptions very friendly.

8. Configuration files can handle different situations. Developers often need to judge that different logback configuration files are in different environments (development, test and production). These configuration files only have small differences, which can be realized through,, and. In this way, one configuration file can adapt to multiple environments.

9、 Filters (filter). Sometimes, it is necessary to diagnose a problem and print a log. In log4j, only the log level can be reduced, but this will print a large number of logs and affect the application performance. In logback, you can continue to maintain the log level and eliminate some special circumstances. For example, when Alice logs in, her log will be marked at the debug level, while other users can log in To continue playing at the warn level. To achieve this function, you only need to add four lines of XML configuration. Refer to mdcfilter.

10. Siftingappender (a very versatile appender) can be used to split log files according to any given running parameters. For example, siftingappender can distinguish log events, follow up user sessions, and then each user will have a log file.

11. Automatically compress the printed logs. When generating new files, rollingfileappender will automatically compress the printed log files. Compression is an asynchronous process, so even for large log files, the application will not be affected during compression.

12. The stack tree has a package version. When logback logs the stack tree, it will bring the package data.

13. Automatically remove old log files. You can control the maximum number of log files generated by setting timebasedrollingpolicy or the maxhistory property of sizeandtimebasedfnatp. If maxhistory 12 is set, those log files older than 12 months will be automatically removed.

In short, logback is better than log4j. Let's build all our applications on logback!

3. Introduce logback into the project

Add package dependency, Maven style:

4. Add logback xml

Add logback XML file to Src / main / resources directory, and the system will automatically load and read logback XML configuration.

logback. xml:

5. Logstash logback encoder version problem

In spring boot, if you use logstash logback encoder, you may need to tell Maven the specific version number to avoid package dependency conflicts. For example, you can set the dependencies of logback core, logback classic, and logback access as follows:

6. Logstash service setup

reference resources:

1.logstash-logback-encoder