Understand your Computer System using Logs 📃
System.out.println(“works upto here”);
You, as a programmer may have written above code segment to figure out what is going on your code (here, it is in Java). Generally, we use this kind of tricks when we are trying to debug the code. What we have tried by doing so is to understand the code, execution flow and identify errors in the code. The systematic way of recording and understanding computer system execution is system logs. System logs are not used just for debugging. They are used for more challenging computer system related use cases. Some of them are, system monitoring, workflow modelling, performance investigations and anomaly detection . Let’s see how can we use system logs to understand our computer systems and how powerful they are when it is used as big data.
What is log data?
Computer systems generate system logs that consist of run-time information of the system. Generally, a log file contains a series of log lines representing different events that occurred in the system. The system log is an output written to a file using a separate code segment describing the current run-time information of the system. Following is the Apache SLF4J way of logging in Java.
LOGGER.info(“Participated to a new round of number” + roundNumber + “with rank as “ + nodeRank);Given below is the possible raw log line that will be written to the log file by executing above code segment.
2019–11–18 20:18:29,467 [INFO] distributedConsensus.LeaderCandidate Participated to a new round of number 13 with rank as 263A log file may contain hundreds or thousands of log similar to above example, describing the story of your computer system. These log lines can be error messages, warnings, debug level messages or general info messages or other kind of log message. To make the logging easy and consistent, logging frameworks like SLF4J, Logback are used in Java programming. Log4js and Winston are logging tools commonly used in Node.Js. These logging frameworks gives you a set of APIs to achieve easy, consistent and robust logging experience. They can be configured to embed additional information like date, time, verbosity level and currently running process to the log message (as shown in the example) without explicitly specifying in the log message.
A Bird’s-eye view on a log line
A generated log line may contain different header fields (depending on the logging framework used, configurations and the information the programmer wants to store with the log) and a log message written in natural language that consists of detailed information about the system event that the programmer wants to log about.
In the above example, 2019–11–18 20:18:29,467 [INFO] distributedConsensus.LeaderCandidate can be identified as the set of space separated header fields. These fields are embed to the log line because the programmer have configured the logging framework to do so.Participated to a new round of number 13 with rank as 263 is the natural language log message that consists the system event information that the programmer wanted to log. Contents of this part is completely depend on the system event that the programmer logs and their use of (English) language. To get the real advantages of log data, it is important that the mentioned information in log data can be easily understood by humans.
Understanding log data
Log data can be considered as one of the semi-structured form of big data because a raw log line consists of structured headers and unstructured log message. Even though we have lot of log data that describe the whole story of our systems, it is very difficult to understand the log data by reading the log. This is mainly because the log message part is written by a human with his/her use of (mostly) English language. It is not that difficult to identify the header fields of log line because that part of the log line has a structure defined by the logging framework. In the above example we can easily understand that 2019–11–18 is the date, 20:18:29,467 is the timestamp, [INFO] is the verbosity level and distributedConsensus.LeaderCandidateis the process or the component that execute this event.
The real hard part of understating log data is understanding the natural language log message which has the most important information obout the system event that is logged. Therefore, a major attention is given to structuring the natural language log message. By observing above code segment that generated the log line, we can understand that the programmer logs a event related to a “participation in a round “. We can also see that the event may happen in different situations and therefore, values of parameters (roundNumber, nodeRank) specified in the code may vary from one log line to another. This is because they are dynamically decided information of the particular event.
In the log analysis research domain the Participated to a new round of number ..... with rank as ..... part is identified as the constant part or fixed part of the log message because it can be found in any log message occurrence of the "participation in a round " type of event. This constant part of a log message is totally depend on the words and language used by the programmer who logs the system event. The real-life use of this constant part of the log message is, it is a general representative for all the log messages of “participation in a round “ type of event. With that said, depending on the values given to the variables (roundNumber and nodeRank in our example) in logging code statement the log messages of same event differ from one another. Therefore, the values(13 and 263, 34 and 134 … in above example) appear in the places of this variables of the logging code are identified as variable parts or mutable parts. Most of the times, these variable parts consist of numeric values but that is not true for all the cases. The variable parts of a log message are carrying dynamic run-time information of the system and hence very valuable source of information.
What if we can separate the constant part from the variable parts of log messages that are in our log file. If it is possible, we can generate a well structured , more understandable log report than the raw log file. This structured log report can be represented as a table that have different columns describing the identifies fields of log lines and the rows representing each log line instance.
This kind of log report is for more understandable than a raw log file. That is why a lot of techniques and methods have been suggested to generate a structured log report from the log file. Some techniques used in current log analysis systems are, frequent pattern mining methods, log data clustering, heuristic-based methods that capture patterns in log lines etc. More details about log structuring methods will be described in future article.
Happy reading…!
