Logging is an important topic in software development, especially if you need to analyze bugs and other unexpected events in your production environment. Implementing your logging often seems easy. But as you probably experienced yourself, logging is far more complex than it might seem. That’s why you can find lots of articles about it here on the blog.
As an experienced developer, you should know the different logging frameworks available, common pitfalls and best practices and, of course, of the types of log files used in common deployment scenarios. In this article, I will focus on the last part. I will tell you about 4 different types of logs that you can find in almost all development or production environments.
Let’s start with the most common type of log: the application log.
Most developers think of this log when they talk about logging. The reason for that is simple. Their application produces this log. It contains all kinds of error messages, warnings or other events written by the application. These messages can provide logical, high-level information that is connected to specific use cases. Typical examples are:
The application log is probably the most important type of log mentioned in this article because you have full control over it. That means that you are responsible for writing the messages.
Each log message needs to provide useful information that helps you understand the behavior of your application. If you want to learn more about application logs, you should take a look at Eric’s article in which he describes a great set of best practices for application logging.
The next interesting and important type is the log of your web or application server.
Most enterprise applications get deployed to a web server, e.g., Apache Tomcat, or an application server, e.g., Wildfly or WebSphere Liberty. Their log files provide you with information about technical issues and the current status of the server.
The configuration and capabilities of each server differ, and I will not explain them in details in this article. But please make sure to check the documentation of your server and configure it accordingly. Getting the right information from your server can make the difference between identifying potential problems in time and a server outage.
The garbage collector provides automatic memory management. It keeps track of all objects instantiated within a JVM and removes the ones that are no longer used. That is a highly complex task, and there are several different garbage collector implementations available.
In general, the garbage collection process in Java is very efficient. It’s so efficient that there are lots of applications that use the default implementation with its standard configuration. But if your application has to handle high load or uses lots of complex object structures, the performance of your application might decrease over time. That often happens when the garbage collector needs to spend more and more time to manage the available memory. The garbage collector log provides you with the necessary information to analyze all garbage collector activities.
The garbage collector log is deactivated by default. You need to activate it with a set of command line properties.
If you’re using JDK 8 or earlier, you can do that using the following properties:
-XX:+PrintGCDetails -Xloggc:
Starting with JDK 9, you need to use the following properties instead:
class=”prettyprint”-Xlog:gc*:file=<gc-log-file-path>
After you started your application with these command line properties, your garbage collector will write detailed information about all operations. Unfortunately, the content and format of the generated garbage collector log depend on the vendor and version of your JVM and the garbage collection algorithm.
All of the previously discussed logs are written by the JVM or by an application that’s running within the JVM. In addition to these logs, you should also be familiar with the logs written by your operating system.
As a Java developer, you will most likely never write to these logs yourself. But your operating system writes certain events to these logs. Other applications, that are part of your deployment, might do that as well. So the system logs are a good place to get an overview of external events.
If you’re running your application on Windows, this is the event log. On Linux, you should know the syslog service and its successors.
Windows’ event log contains important hardware and software events in the categories application, security, setup, system and forwarded events.
Especially the events of the application and the system category can be helpful to understand events that occurred outside of your application. The application category contains events that were reported by other applications running on your local Windows system. Hardware and driver related events belong to the system category.
You can learn more about Windows’ event log in this article.
Linux’s syslog service and its successors provide a highly configurable logging system. It writes messages triggered by applications or the operating system to a file or sends them to a remote system.
The used logging service and its configuration depend on your Linux distribution. Please check the documentation to learn more about your specific operating system.
Ian Shields wrote a great introduction to Linux system logging. I recommend you read his Learn Linux, 101: System logging guide, if you’re looking for a general introduction.
Logging is an important topic with lots of different facets. In this article, I summarized 4 important logs that you should know as a Java developer:
Stackify’s Application Performance Mangement tool, Retrace, offers Java users greater application insights with integrated logging and code profiling. With integrated centralized and structured logging, access all of your application logs from a single place across all applications and servers. Start your free, two week trial of Retrace today.
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to [email protected]
