{'fraction_non_alphanumeric': 0.015792997518805876, 'fraction_numerical': 0.0012602890788074514, 'mean_word_length': 5.001418104467029, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Active Meta-Learner for Log Analysis

The analysis of logs is a vital activity undertaken for cyber investigation, digital forensics and fault detection to enhance system and cyber resilience. However, performing log analysis is a complex task. It requires extensive knowledge of how the logs are generated and the format of the log entries used. Also, it requires extensive knowledge or expertise in the identifying anomalous log entries from normal or benign log entries. This is especially complex when the forms of anomalous entries are constrained by what are the known forms of internal or external attacks techniques or the varied forms of disruptions that may exists. New or evasive forms of such disruptions are difficult to define. The challenge of log analysis is further complicated by the volume of log entries. Even with the availability of such log data, labelling such log entries would be a massive undertaking. Hence this research seeks to address these challenges with its novel Deep Learning model that learns and improves itself progressively with inputs or corrections provided when available. The practical application of such model construct facilitates log analysis or review with abilities to learn or incorporate new patterns to spot anomalies or ignore false positives.


I. INTRODUCTION
The analysis of logs for anomalies is an important research topic with practical importance in the field of failure analysis [1], [2] and security threat detection [3], [4]. Logs are generated by systems or applications that are codified and configured to report relevant information about the state of the applications or software while running. Here, the application may refer to any software running to perform specific task or tasks. It could be mobile application, operating system running inside an Internet of Things (IoTs) device, a cloud compute node performing a computational task. It could also be an environment of compute nodes working collectively on multiple tasks. Such logs and their log entries are generated based on its current configuration at the time of the log generation. These entries are also affected by the state of the application during its execution and its dependent factors that may originate from within the operating environment and executing platform of the application. It would be affected by external factors like users or external systems interacting with the application.
These internal and external factors affecting the log generation may change abruptly and progressively over time resulting in corresponding log entries being included into the log generation process. These factors may originate from planned changes like planned maintenance tasks. They may also originate from unplanned activities. Additionally, these changes may be induced by benign or malicious intent. For the latter, with the intent to evade detection, even if the logs are not tampered, its entries will be elusive to classical detection techniques. These further complicates the composition of logs to be analyzed.
The objective of performing analysis on logs is done to facilitate the detection of anomalous activities so that immediate or corresponding remediation may be done to contain or remediate the issue recorded in the logs. This is part of the attempt to enhance system resiliency against system faults, degradation and intentionally induced cyber physical attacks. It is also used to facilitate the investigation or analysis of what may have induced the occurrence of such anomalous activities. The scope of this research work is on the detection of such anomalous activities from the logs.
However, log analysis and the ability to detect anomalies has several challenges and constraints to deal with before it contributes significantly to its intended objectives of keeping system resilient. This is namely in dealing with the availability of anomalous data points or patterns that in turn facilitate the codification of rules or building of models to detect such occurrences. Also, the availability of knowledge or experience in detecting or classifying these data points or patterns. While there is many research work done to develop AI algorithms to detect anomalies, however they do not include the means to refine these models through progressive updates provided by analysts or narrowly trained models. This research work seeks to address these challenges through its contribution with the following which we believe that it is novel based on our research study.
• The model construct is implement using a unique construct of Meta-learner Pattern Matcher algorithm that learns to learn with a custom Active learner that queries the oracle when a classification lacks confidence.
• This novel model that does log analysis end to end without need for intermediary log preprocessing and extends its ability to recognize new patterns without the need for retraining. The model, after receiving some expert's guidance, performs better than the existing top algorithms.
In the next section, we will cover the challenges and complexity of performing log analysis. This is followed by a review of current log analysis algorithms. A coverage of the algorithm that we have developed follows then with the details of an experimentation setup with its evaluation. This paper concludes with a conclusion and its future research direction.

II. BACKGROUND INFORMATION
In this section, we articulate the background information related to the need for the analysis of logs, its complexity and challenges with current log analysis algorithms.

A. Need for Analysis of Logs
Logs are generated by software driven applications running on systems or devices to provide information to aid developers and system engineers with their analysis of system's state and condition. It is also used as a form of audit trail to log the occurrences of events in chronological manner. The analysis of logs is also done to facilitate investigation after the occurrence of an incident related to the system that generates the logs. This incident could be in the form of system defect and a malicious or unintended breach of the system. With investigation, the log could provide the means to reconstruct the occurrence of the incident. With such forms of analysis, an investigator or system engineer would attempt to identify the occurrence of anomalous events through the logs. However, to identify such anomalies, one would need to know how to spot such anomalies from voluminous entries posted into the log files.

B. Log Analysis Challenges
The form for logs is typically unique to how the software has been developed or configured to post entries into these textual files. Also, each system or software component may adopt its own logging format and information lexicon representation that details the state of the run-time system at the time of its log posting. Such information within the logs is contextual to the environment to which the system resides in. For example, information like the IP addresses or hostnames or resource identities. Entries in the logs are dependent also on the configuration surrounding the involved system and their own respective environmental conditions. In additional to the contextual settings, the log entries are sequenced by its chronological occurrence of events or state. Hence such log entries have a time dimension.
Hence, the analysis of such log datasets requires contextual understanding of the system or component that generates such logs. Also, the analysis requires the means to classify or distinguish what is a normal log entry and what is not a normal log entry. For the latter, such information of recognizing an abnormal entry would be constrained to what may be conceivable based on the engineering design of the system involved or known instances of events that could cause an anomalous event like a cyber security breach attempt. However, there will be instances where such information or knowledge is only acquired through the occurrence of the event that in turn induces the anomalous log entries. Hence the challenges with log analysis are the need for contextual knowledge and limitedly available information about the form of anomalies that could occur.

III. RELATED WORK
In this section, we review the current log analysis algorithmic development and their strengths and limitations.

A. Multi-staged Log Processing
The current log analysis algorithmic designs typically involve multiple stages of log processing before analysis is applied. It typically starts with log parsing that converts raw logs into structured data features. These extracted features would undergo further transformation as they are typically represented as textual features and would be converted to numerical forms. Log partitioning typically follows that involves converting the contiguous log into associative partitions to improve anomaly classification. This may involve the use of time-based partitions, partitions organized by windows of similar or compatible operations or identifier-based divisions of log entries. Finally, the anomaly detection algorithm would then be applied after these pre-processing.
Thus far, there is very few developmental attempts to develop an integrated model that could ingest raw log data for immediate model training and inference. Based on our survey, one other by Hashemi and Mäntylä [5] ingresses logs directly. Our model applies its anomaly detection directly to the raw log entries.

B. Algorithms to detect Anomalous Events from Logs
Many of the log analysis algorithms have focused on the key area of detecting anomalous events from logs. From the survey work done by He et al. [6] and Chen et al. [7], the algorithms are either supervised or unsupervised machine learning algorithms. These algorithms may be based on classical machine learning algorithms or deep learning algorithms. Such algorithms are constrained by the availability of anomalous data within the training datasets. Additionally, even with the availability of anomalous data within the log datasets, the class imbalance could pose a significant challenge with the training of the model. Mislabeling of log entries could skew the model inferences to an invalid bias. Even when anomalous datapoints become available from an occurrence of an incident or knowledge of how a system fault may occur or an attack vector against the system, these models would need to undergo retraining or be reconstructed to internalize the new knowledge. Hence, current algorithmic constructs for log analysis lack a form of continuous learning needed to deal with new anomalies. Our research work deals with this problem without any need for retraining. Also, our research evaluation would compare leading deep learning algorithms that generally performs better than classical machine learning ones.

IV. MODEL
Our unique active learning model construct draws from our past work on a deep learning algorithmic construct to perform pattern matching and the inclusion of an active learning construct that we have further developed with this research work. The pattern matching construct that we are using compromises of an Autoencoder and Meta-learner Pattern Matcher that would derive pattern fingerprint based a few trace evidence. It is done so with the encoder of a trained Autoencoder trained to convert the raw log entries into vector embeddings. The model construct then performs pattern matching from the vector embeddings of the log entry being queried against a furnished sample of log entries. The furnished sample represents a form of the fingerprint representation to the sample. It performed comparatively as well as supervised machine learning models with large training dataset. Unlike what was mentioned in our previous section where many of the algorithms developed for log analysis to detect anomalies involved the use of multi-stage log processing pipeline, our model construct ingests the raw logs and performs anomaly detection through pattern matching.
The Active learning construct is placed over the meta-learner to enhance its prediction on log datasets with provided expert's guidance. This construct leverages on the meta-learner's translation of a sample of traces to a fingerprint pattern to generalize the identification of patterns without the need for model retraining. Hence, the Active learning involves retaining a list of expert selected patterns to identify both anomalous and normal log entries.

A. Autoencoder
The Autoencoder is used to perform unsupervised learning on the features of the log entries from logs originating from the specific target system or application that generates logs. Each new log generator will require a trained Autoencoder. The Autoencoder construct uses Convolutional filters to perform the character-based encoding directly from the raw log entries one line at a time. The Autoencoder consists of both the encoder and decoder that are optimized to minimize the reconstruction error.
The trained encoder of the Autoencoder that will convert the raw log entries into the vector encoding is then fed into the Meta-Learner Pattern Matcher.

B. Meta Learner Pattern Matcher
Meta Learning is a subdomain of machine learning algorithms designed to perform automatic learning. It is ideally suited for solving learning problems. Unlike popular Supervised learning or Unsupervised learning algorithms that are not optimal for this task of learning from limited data samples, Meta Learning algorithms focus on learning to learn that would result in acquiring knowledge versatility to learn new skills or adapt to new environment with minimal training examples [8].
For our meta-learning algorithm, we used the metric based Prototypical network [8] that converts the embedding from the encoder from curated samples to its corresponding pattern prototype. This approach closely resembles the nearest neighbour algorithms like k-nn or k-means clustering with kernel density estimation. The predicted probability over a set of known labels ! is a weighted sum of labels of curated and labelled set of log entry samples. The weight is generated by a kernel function " , measuring the similarity between two data samples.
However instead of a single pairwise comparison for the contrast comparison, we extended the model to perform two pairwise comparison of the encoder generated embeddings of the query point (that is the log entry being evaluated) with a given set of sample embeddings that were generated by the encoder from log entries and a null embedding that represents the origin to the embedding space. against a query point that represents the comparison to evaluate pattern matching. Our algorithm computes the prototype or centroid of the class' embedded support points is the mean vector where is the fingerprint to the selected set of patterns k. The Euclidean distance of the prototype is then compared against the query is used to compute the similarity measurement.
This is then used as inputs with forward feeding of the embeddings ( ! ) from the encoder to a fully connected neural network layer. We optimized our model's objective function by minimizing the loss when the model is given positive and negative contrastive comparisons.

C. Active Learning
The Active Learning characteristics of our algorithm involved the process of performing pattern analysis for anomalous log entries based on a limited labelled samples and × Prototype for Samples

Prototype for Query
Prototype for Null to identify the log entries that require labeling by an Oracle or human expert. A few iterations may be required to gather sets of sampled log entries that represents the fingerprints that would cover all normal and anomalous patterns. The model would start first with a selected sample of normal log entries. In our research, we first set the sample size of ten. The model then iterates through the log entries to compare the provided sample set against every log entry with the log dataset. The contrast comparison would result in either a match or not against the sample set with a Softmax confidence factor. The measure of confidence factor against a defined threshold is our query strategy to query the Oracle or a subject matter expert for their valid classification. If the confident factor falls below the threshold hold Gaussian average of 0.67, the model would set aside that log entry, which are deemed to be suspiciously normal, into the Suspicious list + that the Oracle would label subsequently. The other list gathered from the first pass of log analysis would contain the confidently classified anomalous log entries ( , ).
Initial iteration would have only one sample set of normal log entries -. Subsequent iterations with Oracle's annotations, the list of samples for -, , could grow. The following is the pseudo code to our active learning component to our model construct.
Our Active learning construct with the Meta-Learner Pattern matcher allows the model to retain its model parameters without any need for retraining. It's match capacity grows with the list of provided labelled fingerprints represented by samples of log entries V. METHODOLOGY AND ANALYSIS In our experiment setup, we designed our experiment to align with those used by other past research work to facilitate the evaluation of the effectiveness of our model. We hence chose the log datasets and evaluation metrics to match those used by others accordingly.

A. Log Datasets
For our log datasets, we used BGL [9] and HDFS [10]. These are two popular datasets typically used by researchers to evaluate their log models [7]. Both log datasets are labelled.
The HDFS log dataset was generated using 200 Amazon's EC2 nodes while performing map-reduce tasks. Each log entry has unique block identifiers with its block operations. The anomalous log entries are labelled anomalous based on a list of block_ids preidentified as anomalies. The other popular log dataset used is BGL dataset which originated from a BlueGene/L supercomputer at Lawrence Livermore National Labs. Unlike HDFS, BGL log dataset does not have any identifier that could be used to disambiguate different job executions. The labeling for the BGL log dataset file was embedded into the original dataset to indicate that certain log entries were indicators of failures. The following table summarizes the statistics for the two log datasets.

B. Evaluation Metrics
As the dataset used had binary classification labels and other research work developed their models to generate binary classification, our model was constructed with the same configuration. Additionally, most of the anomaly classification are binary that whether the log entry is normal or anomalous. We hence used precision to measure the accuracy of the model against type I error (true positive) and recall to measure the accuracy of the models against type II error (true negative). Finally, we used F1 score to measure the harmonic mean of precision and recall.
TP (True Postitive) represents the number of correctly classified anomalies against its respective labels and FP (False Positive) is the number incorrect anomaly classification. FN (False Negative) is the number of incorrect classification of log entries as normal while the label states overwise.

C. Model Preparation and Evaluation
For model preparation and evaluation, we aligned our design of experiments to match the approaches used by other leading research. We divided our datasets with the using same division namely 80% for training sets and 20% for testing sets [7]. However, we only applied a smaller subset of the training datasets to train our model. This smaller subset (of less than 20% of the training dataset) also contained a subset of the labelled anomalies as we randomly selected a segment of the original divided training set. This was so that during testing, the model would classify both seen (during training) and unseen log entries.
The encoder of the model was first trained on the designed training datasets without their respective labels. The model was then trained on contrast comparison using the normal and

13:
for p ∈ 0 ! do anomalous labeled log entries as two distinct classes. As described in the previous section, our model operates differently from the rest as it is designed to fingerprint the patterns that it is tasked to find. The classification of anomalous or normal log entry is based on the similarity of the fingerprint of a given set of log entry patterns against the instance of log entry being queried. Hence training was done through contrastive comparison with positive and negative examples. Our approach adopts the self-supervised learning training where the training of the model starts with limited data. The model was then evaluated against the test datasets from each log dataset. As our model is capable of continuous learning, the test of our model involves two or more iterations. The first iteration was the model's initial application of the model to perform log analysis. In this iteration, a select sample of the log entries were provided to the model as normal log entries. This formed the baseline pattern fingerprint for the model to recognize what is normal. We sampled these from the top of the log dataset to ensure consistency across the subsequent iterations of tests. In the second or subsequent iterations, we gave additional samples to the model to spot new anomalies that it had missed previously and samples to ignore as recognizing them as non-anomalies or normal patterns. The additional samples were identified based on the model's prediction confidence factor against the defined threshold. These samples were then labelled by the Oracle and used as new additional samples for the model to refer to either as normal or anomalies.
The model was not retrained with the additional samples. With these additional samples as new pattern fingerprints (on top of the base pattern fingerprint used in the first iteration), the model ran with a longer execution duration (with a linear growth) as it compared each log entry against a series of pattern fingerprints. For BGL, we provided additional samples to correct the model's True Positive and True Negative predictions. For HDFS, we needed only to provide one set of additional samples to improve its accuracy before the model saturates with its accuracy performance. To further evaluate the model's effectiveness in log analysis, we applied the second stage testing across three different sample sizes namely samples of three, five and ten.

D. Results and Analysis
The following tables details the test results of our model in comparison with other leading log analysis algorithms and the accuracy performance metrics for the varied sample size. Table 2. AML (Initial) is our Active Meta-Learner model used after training with no additional samples. AML (Final) is our model with additional samples given but no further training applied From the above table, our model improved significantly with both BGL and HDFS log datasets after additional samples of labelled patterns were provided. For BGL, three sample set of normal patterns and one sample set of anomalous patterns were given. For HDFS, two sample set of normal patterns and one sample set of anomalous patterns were given. The initial results had the model having only one sample set of normal patterns for both BGL and HDFS datasets were given. Its performance was bad relative to the other leading model constructs by other researchers. However, with the added sample sets, our model either exceeded or comparable results compared to other models. Our model constantly performed well across the two datasets. Our model demonstrated its ability to generalize in its pattern matching even though only one sample set of anomalous log entries were provided.
Our model did saturate in its accuracy improvement when there are close similarities to the log entry patterns like in the case of the HDFS logs. The following are the samples of the log entries that exists with both labelled types (normal and anomalous). This would explain the constraints the model has in classifying such entries looks strikingly similar except for the block_ids. To overcome such limitations, a form of semantics analysis would be to be used or included.
VI. CONCLUSION AND FUTURE DIRECTIONS Our model handles the entire log analysis pipeline with one model construct. It converts a sample of labelled log entries to a pattern fingerprint that could accurately classify logs. From our experiment, our model demonstrated that it could generalize well from samples of patterns representing anomalies and normal log entries. The model construct addresses the real-world constraints of limited labels to log entries as the threat environment undergoes constant changes through its optimized active learning construct that does not require retraining of the model.
While the model performed better than existing leading algorithms, we will continue to improve its construct to improve its accuracy performance. One approach is to extend the model to support semantic based analysis. However, our algorithmic model construct performs comparatively well even with semantic based algorithms. We will intend to extend the model beyond log analysis to other digital forensics and system resiliency anomaly detection problems.