## 3 CFTL Log Parsing Method
### Algorithmic Details of CFTL
Typically, the first word in each log message contains the most important information, because the process name is typically located in the first word. For example, the first word in an error message is typically \"Error\", and it may be \"Warning\" for a warning message. Therefore, log messages should be clustered primarily based on their first words. Messages with the same first words should be partitioned into the same cluster. For some software systems, the use of the first word token as a classification mark is highly accurate. However, in other scenarios, using the first word alone for clustering is inaccurate. Different types of events may have the same first words in log records. In this case, additional information is required to improve clustering accuracy. The length of the log message is an appropriate token because the number of words in different print statements typically differs. With both the same first word and log message length, related log messages can be clustered more accurately. The proposed method employs a two-step clustering strategy: the first word is primarily considered for clustering, and the log message length is supplemented after the initial clustering process depending on the first word. In other words, clusters based on length are subclusters divided by the first word. Finally, log messages with the same first word and length are clustered into a group. **Separating. ** Although log messages in each cluster have the same first word and length, they may record different cases and are output by different log print statements. For example, almost all log messages record two connection events, with the keyword \"successful\" or \"failed\" in the log files. However, if the keyword \"successful\" or \"failed\" is not the first word, the clustering strategy in step 1 clusters them into the same group. In this step, this problem is solved using a separation mechanism. As mentioned previously, a log message always comprises two types of components: constant and variable components. The former typically contains fixed information containing the keywords of log messages, whereas the latter typically contains changing information, along with the system running and event occurrence data. In each set of log messages, if the constant components are very similar, they can easily be treated as log events. Taking the first and second log messages in the fifth row of Table 1 as an example, they have the same first word and length. However, they represent two events: an event indicating that the connection is closed, and another event indicating that the connection is reset. These two log messages are grouped in the first step, and if the common component is extracted as the log message template, the two constants \"closed\" and \"reset\" are treated as variables and, thus, represented by \"*.\" Thus, the next step is to accurately separate the variables and constants and each subgroup of log messages within an initial group. Algorithm 1 provides a pseudocode for the second step, i.e., the separation stage. The separation function is recursively called. CFTL continuously separates clustered log messages into new groups until each group contains the same constant component. After the initial clustering of the raw messages, the messages are clustered into several groups. For each group, CFTL uses the same separation rules to classify the log messages accurately. Tokens in all positions are counted, and a threshold (s) for separation is established. For example, assuming that the number of different tokens in the first position is calculated as \(n\), CFTL counts from the first token of each log. If n exceeds the preset threshold \(s\), the token at this position is most likely a variable component. Otherwise, it is considered a constant component. For variable tokens, no changes to the log messages are made, and the tokens are changed directly to the \"*\" wildcard in the extracted template. However, for constant tokens, the log messages are regrouped according to the tokens.