Getting started with Xiaobai learning to log

Preface

Only a bald head can become stronger.
The text has been included in my GitHub repository, welcome to Star: https://github.com/ZhongFuCheng3y/3y

I remember that I wrote an article before reading the "Alibaba Java Development Manual". Since I didn't have much contact with the "log" during my self-study before, I put aside the "log protocol" in the "Manual".

And I wrote an article before: What is the difference between the project I did in the company and the one I did in school? It is mentioned in the article: the company's project will not have e.printStackTrace(); this kind of code exists. Because the printed error message has no date, grade, etc., it is inconvenient to analyze.

It is a very, very common operation to check logs on the server at work, so I wrote a Linux command commonly used in work at the beginning, and it talked about the Linux commands commonly used when checking logs.

I thought, since I have been in contact with the log for a while, I might as well look back at the "Manual" to see if there is anything to pay attention to, so I have this note.

One, the basis of Java logging

When I taught myself before, I would only write the following code to troubleshoot problems:

try {
   // doSomething
} catch (Exception e) {
    e.printStackTrace();
}
----------
// 查看某个数据的值时：
System.out.println(xxxx);

When I went to the company, I found that all the above codes were missing, and the rest was:

LOGGER.info("begin to run Java3y:{}", id);
----
LOGGER.error("excepiton occurs when run Java3y {}, exception{}", id, e.toString());

If you use e.printStackTrace();, it is not convenient to analyze the information printed in the control:

Getting started with Xiaobai learning to log
It is inconvenient
to analyze the information printed in the control and we record the information graded and timed on the disk of the server. If there is a problem, you can find the relevant log according to the corresponding information (this is very convenient for troubleshooting):

Getting started with Xiaobai learning to log

Let's take a look at the log information on the server and look at what a general log looks like:

Getting started with Xiaobai learning to log
What is the length of the log?
For example: Now someone reports that the user seems to be unable to receive the SMS, given the sending time and user ID, we can find out the sending status of the user in our system on the log (for example, the picture Above: state: 81, we think it is a successful state)

So, here comes the question, where do we log? The answer is actually given in the "Manual":

Log carefully. Production environment disable output debug log; selectively output info log; if the
use warn to record business behavior when just on the line information, be sure to pay attention to the log output problems, avoid server disk
explode, and remember to delete these observations Log.
Outputting a large number of invalid logs is not conducive to improving system performance and quickly locating error points. When recording logs, please think: Are these
logs really viewed? What can you do when you see this log? Can it bring benefits to troubleshooting?

1What is RBI?

The most common way to log is to print out relevant information during program execution, which is used to quickly locate and troubleshoot problems. I understood it this way at the beginning, but it can be extended a bit.

For the system I am working on, we also use logs to manage the execution link of the system. For example, I want to push a notification message now. The notification message is actually the following:

Getting started with Xiaobai learning to log
This is how the notification message
process looks like:

First, someone called the interface provided by my RPC (or I called my own interface) and found that this was a notification message. So I assembled the corresponding Task and put it in the message queue asynchronously
Another system takes the task from the message queue, processes the task (for example, whether it is blocked at night, whether it is forced to send, etc.), and then calls the HTTP interface to hand the task to the downstream
There are actually a lot of things done downstream, the entire link is very long (for example, the SDK library needs to be called, Android and IOS do different processing) the

entire link,
and we hope that after the push is completed, we can count some indicators (exposure Volume, click rate, conversion rate) and so on. Ever since, it is necessary to make a log in some key positions (professional point is called management)

After the entire link is opened, collect these points (logs) and place them on the real-time streaming platform (storm/flink) for cleaning/filtering. If you need to use it in real time, put it in Redis, and put it in Hive offline.

2. Manual specification

2.1 Log framework using facade mode

[Mandatory] The API in the logging system (Log4j, Logback) cannot be used directly in the application, but the API in the logging framework
SLF4J should be used, and the log framework of the facade mode is used, which is conducive to maintenance and unified log processing methods of various types.

Facade Mode I also wrote a note before: Learn Facade Mode in three minutes!

In fact, to put it bluntly, I hope to abstract a layer of API so that it does not require extensive changes when switching specific log frameworks.

This we can understand when we learn JDBC:

No matter if I connect to MySQL, Oracle or SQL Server, my interface will always be the same, and I don’t need to change my Java API when switching databases.

I took a look at the company’s project and adopted SLF4J+Logback

2.2 Calling RPC interface using Throwable class interception

[Mandatory] When calling RPC, second-party packages, or related methods of dynamically generated classes, the Throwable
class must be used to intercept exceptions .

When I was investigating the problem before, there was a problem that couldn't be sorted out. I didn't enter the catch module during DeBug. Later, my senior said: "Why don't you try to change to Throwable?

try {

} catch (Throwable e) {

}

I was very suspicious and said: "Why change to Throwable? Can we use Exception to catch all exceptions? Exception is a subclass of Throwable, but Exception already includes all Java exceptions."

As we all know, Throwable has two subclasses:

Error (usually we will ignore this... Under normal circumstances, an Error program will not run)
Exception

The  Throwable class is the superclass of all errors and exceptions in the Java language

The above rules are also explained in the "Manual":

Description: The method is called through the reflection mechanism. If the method cannot be found, a NoSuchMethodException is thrown.
Under what circumstances will NoSuchMethodError be thrown ? When the second party package type of conflict, the arbitration mechanism may result in the introduction of unintended class version of a method signature does not match
with, or bytecode modification framework: dynamically create or modify classes (such as the ASM), a corresponding method is modified signature. These cases, which
make the code compile time is right, but when code is run, throws NoSuchMethodError.

The rough meaning is that: when calling RPC, second-party packages, or related methods of dynamically generated classes, Error may be thrown directly, and catch Exception cannot be caught.

Students who want to see examples can read this article:

https://zhuanlan.zhihu.com/p/57950399
At last

This article seems a bit short...

Reference materials (download address of Alibaba Development Manual):

https://github.com/alibaba/p3c
The good article found when looking up the information:
https://www.cnblogs.com/chenhongliang/p/5312517.html
https://www.cnblogs.com/crazyacking/p/5456347.html