Five ways to improve the quality of programmers’ logs

Five ways to improve the quality of programmers’ logs
Recently, a variety of new tools have emerged to help programmers understand logs, including open source projects like Scribe and Logstash, prepaid tools like Splunk, and hosting services such as SumoLogic and PaperTrail. What these tools have in common is to clean log data and extract some more valuable files from a large number of logs.
Five Tips to Improve Log Quality
But there is one thing these tools cannot help with, because they completely rely on the log data you actually input, and how to ensure the quality and quantity of data needs to be done by the user. Therefore, at critical moments, things can get tricky if you need to debug code based on partial or missing logs.
In order to reduce the occurrence of this situation, here are five suggestions to keep in mind when you record logs:
1. Hello, my (thread) name is
As in Ringo, the thread name attribute is Java One of the most underrated methods. The reason for this is that thread names are mostly descriptive. However, the problem also arises here. Similar to people themselves, when naming names, they usually give them a certain meaning. In multi-threaded logs, the thread name also plays a key role. Typically, most logging frameworks will log the name of the thread being called. Sadly, we usually see names like http-nio-8080-exec-3 simply allocated by the thread pool or container.
For some reason we have heard this misconception more than once - thread names are immutable. In contrast, in the log, the thread name plays a fundamental role and you should make sure to use it correctly. For example, combine it with specific context, such as the name of the Servlet, task related, or some dynamic context such as user or message ID.
In this case, the code interface should be like this:
Thread.currentThread().setName(ProcessTask.class.getName() + “: “+ message.getID);
The more advanced version will be loaded into the thread local of the current thread Variables, configure the log appender, and automatically add it to log entries.
This is useful when multiple threads are writing to the server log, but you need to focus on a single thread. If you are running in a distributed/SOA environment, you can even see its unique advantages.
2. Distributed identifiers
In SOA or message-driven architecture, task execution is likely to span multiple machines. When dealing with failures in this environment, connecting the relevant machines and their status will be key to understanding the situation. Most log analyzers will group these log messages so that, assuming you provide them with a unique identifier, they can be part of the actual log message.
From a design perspective, this means that from entering the system to completing the operation, each inbound operation should have its own unique ID. Note that a persistent identifier such as a user ID may not be a good container. During the course of logging a log file, a user may have multiple actions, which will make isolating a specific flow more difficult. UUIDs might be a good choice. Its value can be loaded into the actual thread name or as local storage for the TLS-thread.
3. Don’t use text + drive, don’t log + loop
Many times, you will see a piece of code running in a tight loop and performing corresponding log operations. The basic assumption is that the code can be run a limited number of times.
Probably running very well. But when the code gets unexpected input, the loop may not break. In this case, you're not just dealing with an infinite loop (although that's bad enough), you're dealing with code that is writing an infinite amount of data to disk or the network.
In a stand-alone scenario, it may cause a server to crash, but in a distributed scenario, the entire cluster is affected. So if possible, don't log in a tight loop. This is especially true when catching errors.
The following example records an exception in a while loop:
void read() {
while (hasNext()) {
try {
readData();
} catch {Exception e) {
// this isn' t recommend
logger.error(“error reading data“, e);
}
}
}
If readData throws an exception and hasNext returns true, unlimited log data will be written here. The way to fix this is to make sure that none of this is logged:
void read() {
int exceptionsThrown = 0;
while (hasNext()) {
try {
readData();
} catch {Exception e) {
if (exceptionsThrown < THRESHOLD) {
logger.error("error reading data", e);
exceptionsThrown++;
} else {
// Now the error won't choke the system.
}
}
}
}
Another approach is to remove the logging from the loop and save the first/last exception object and log it somewhere else.
4. Uncaught handlers
Westeros has the last wall of defense, and you have Thread.uncaughtExceptionHandler. So try to use them as much as possible. Without these handlers installed, you get little valuable context when an exception is thrown, and you have no control over where you have logged it before it ends.
Note that even in an uncaught exception handler, where it doesn't look like you have any way to access any variables in the (terminated) thread, you can still get a reference to the actual thread object. If you stick to step #1, you'll still get a meaningful thread.getName() value to log.
5. Capture external calls
Whenever an external API is called, the probability of JVM exception will greatly increase. This includes web services, HTTP, DB, file system, operating system, and any other JNI calls. Take every call seriously because it can explode at any time "It's very likely to happen at the same point".
Most of the time, the cause of external API failure is unexpected input, and recording it in the log is the key to fixing the code.
At this point, you can choose not to log the error and just throw an exception. In this case, just collect the relevant parameters of the call and parse them into exception error information.
Just make sure the exception is caught and logged at a higher level stack call.
Get LAMP Brothers' original PHP video tutorial CD/"Essential PHP in Details" for free. For details, please contact the official website customer service:
http://www.lampbrother.net
[Brothers IT Education] Learn PHP, Linux, HTML5, UI, Android and other video tutorials (courseware + notes + video)!
Network disk tutorial download: http://pan.baidu.com/s/1mg8ANMg

The above introduces five ways to improve the quality of programmers' logs, including aspects of content. I hope it will be helpful to friends who are interested in PHP tutorials.