Patent Description:
Conventionally, performance/failure monitoring and service assurance in telecom networks is based on the collection and analysis of numerical PM/FM counters.

An autoencoder is a type of artificial neural network used to learn efficient codings of unlabeled data (unsupervised learning). The encoding is validated and refined by attempting to regenerate the input from the encoding. The autoencoder learns a representation (encoding) for a set of data, typically for dimensionality reduction, by training the network to ignore insignificant data ("noise").

An autoencoder has two main parts: an encoder that maps the input to a code, and a decoder that reconstructs the input from the code. An optimal autoencoder would perform as close to perfect reconstruction as possible, with "close to perfect" defined by the reconstruction quality function. The simplest way to perform the copying task perfectly would be to duplicate the input. To suppress this behavior, the code space usually has fewer dimensions than the input space.

Document <CIT> discloses a method and a system for predicting time of occurrence of future server failures using server logs and a stream of numeric time-series data occurred with a particular time window. The method includes accessing plurality of server logs and stream of numeric time-series data, applying density and sequential machine learning model over a plurality of server logs for obtaining first and second outputs, respectively, and applying a stochastic recurrent neural network model over the stream of time-series data to obtain a third output. The method includes aggregating first, second, and third outputs using an ensemble model, predicting likelihood of at least one future server anomaly based on the aggregating step, and determining time of occurrence of the at least one future server anomaly by capturing server behavior characteristics using time-series network model. The server behavior characteristics include time-series patterns of the stream of numeric time-series data.

Document <NPL>, discloses a method and system for the analysis of logs emitted by computer systems with a focus on anomaly detection. The proposed approach consists in sampling the logs at regular intervals and computing numeric scores. Scores collected under normative operations are used to train a semi-supervised deep autoencoder, which serves as a baseline to classify future scores. The results obtained in detecting anomalies of two industrial systems and the public BG/L and Hadoop datasets widely used as benchmarks, indicate that the recall of AutoLog ranges between <NUM> and <NUM>, while the precision is within <NUM> and <NUM>. A comparative study with isolation forest, one-class SVM, decision tree, vanilla autoencoder and variational autoencoder demonstrates the validity of the proposal.

Document <NPL>, discloses an autoencoder model that combines an encoder-decoder structure with an attention mechanism for unsupervised log anomaly detection. The unstructured normal log data is processed by a log parser that uses a semantic analyse and clustering algorithm to parse log data into a sequence of event count vectors and semantic vectors. The encoder combines deep neural networks with an attention mechanism that learns the weights of different features to form a latent feature representation, which is further used by a decoder to reconstruct the log event sequence. If the reconstruction error is above a predefined threshold, it detects an anomaly in the log sequence and reports the result to the administrator.

It is an object of the present invention to improve the prior art.

According to a first aspect of the invention, there is provided an apparatus comprising:
one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform:.

The instructions, when executed by the one or more processors, may further cause the apparatus to perform:
marking the sequence of N log lines as not anomalous if, for each of the values of n, the difference between the output vector for the respective value of n and the count vector for the respective value of n is not larger than the threshold.

The instructions, when executed by the one or more processors, may cause the apparatus to perform:
the converting each of the log lines of the sequence of N log lines into the respective log identifier by an integer embedding algorithm.

The instructions, when executed by the one or more processors, may cause the apparatus to perform, for each of the values of n between <NUM> and N inclusive:
the arranging the front frequencies and the rear frequencies of the K different log identifiers in a count vector for the respective value of n according to the predefined order by arranging the front frequencies in a first portion of the count vector for the respective value of n according to a predefined first order, arranging the rear frequencies in a second portion of the count vector for the respective value of n according to a predefined second order, and combining the first portion of the count vector for the respective value of n and the second portion of the count vector to the count vector for the respective value of n according to a predefined rule.

The instructions, when executed by the one or more processors, may cause the apparatus to perform, for each of the values of n between <NUM> and N inclusive at least one of the following:.

The instructions, when executed by the one or more processors, may further cause the apparatus to perform:.

The instructions, when executed by the one or more processors, may further cause the apparatus to perform:
sorting the log identifiers of the sequence of N log identifiers such that the points in time of the log lines on which the log identifiers are based are subsequent.

The instructions, when executed by the one or more processors, may further cause the apparatus to perform:
determining a number of different types of log lines from the plurality of log lines or from a source code of a system providing the plurality of log lines; setting K equal to or larger than the number of different types of log lines.

According to a second aspect of the invention, there is provided a method comprising:.

The method may further comprise:
marking the sequence of N log lines as not anomalous if, for each of the values of n, the difference between the output vector for the respective value of n and the count vector for the respective value of n is not larger than the threshold.

The converting may be performed by converting each of the log lines of the sequence of N log lines into the respective log identifier by an integer embedding algorithm.

For each of the values of n between <NUM> and N inclusive:
the arranging may be performed by arranging the front frequencies and the rear frequencies of the K different log identifiers in a count vector for the respective value of n according to the predefined order by arranging the front frequencies in a first portion of the count vector for the respective value of n according to a predefined first order, arranging the rear frequencies in a second portion of the count vector for the respective value of n according to a predefined second order, and combining the first portion of the count vector for the respective value of n and the second portion of the count vector to the count vector for the respective value of n according to a predefined rule.

For each of the values of n between <NUM> and N inclusive at least one of the following may apply:.

The method may further comprise:
sorting the log identifiers of the sequence of N log identifiers such that the points in time of the log lines on which the log identifiers are based are subsequent.

The method may further comprise:
determining a number of different types of log lines from the plurality of log lines or from a source code of a system providing the plurality of log lines; setting K equal to or larger than the number of different types of log lines.

The method may be a method of anomaly detection.

According to a third aspect of the invention, there is provided a computer program product comprising a set of instructions which, when executed on an apparatus, is configured to cause the apparatus to carry out the method according to the second aspect. The computer program product may be embodied as a computer-readable medium or directly loadable into a computer.

According to some embodiments of the invention, at least one of the following advantages may be achieved:.

Further details, features, objects, and advantages are apparent from the following detailed description of the preferred embodiments of the present invention which is to be taken in conjunction with the appended drawings, wherein:.

Herein below, certain embodiments of the present invention are described in detail with reference to the accompanying drawings, wherein the features of the embodiments can be freely combined with each other unless otherwise described. However, it is to be expressly understood that the description of certain embodiments is given by way of example only, and that it is by no way intended to be understood as limiting the invention to the disclosed details.

Latest with <NUM>, telecom software is increasingly virtualized and deployed on cloud infrastructure, inside virtual machines or cloud native containers. Due to the introduction of IT/cloud technology, new means of software monitoring have become available in the telecom domain, most notably computer logs, which provide an unstructured text stream of information encoding infrastructure metrics, application metrics, performance related information, failures and other events (such as errors, information, debug info).

Some example embodiments of the invention find autonomously anomalies in a stream of computer log lines, without a-priori knowledge on which log lines or which patterns in the log lines are or should be considered anomalous. In order to solve this technical problem, at least one of the following two technical problems has to be solved:.

It is challenging to apply machine learning in order to automatically find patterns in logs without having any a-priori knowledge on the content, semantics or presence of anomalies in the logs. There is no pre-defined format or content for computer logs as they are produced by arbitrary logging statements in the program code of the software modules. Therefore, a log analytics method according to some example embodiments of the invention does not have any dependency of the log structure.

According to some example embodiments of the invention, it is determined and indicated whether or not a sequence of log lines ("input log sequences") is anomalous (i.e., an anomaly, if any, is indicated for the whole input log sequence, not just for a single log line of the input log sequence).

<FIG> and <FIG> illustrate a first phase (pre-processing) and a second phase (autoencoding), respectively, of some example embodiments of the invention.

As shown in <FIG>, in the pre-processing phase, the textual input log lines are transformed into integers so that similar log lines are denoted by the same integer called log identifier (or log type). This action may be called "log line embedding" and may be performed by any suitable integer embedding algorithm, mapping the logs into integer space. (In general, the mapping may be to any one-dimensional space (e.g. the letters of the alphabet and combinations thereof such as A, B, C,. , Z, AA, AB,. ), where the members may be mapped to natural numbers. In the context of the present application such a mapping is considered as an integer embedding algorithm, too).

The number of different log identifiers (integers) that may be output by the log line embedding is limited and denoted by K. K is specific to the system (e.g., SW module) that produces the logs. Any given SW module can only produce a limited number of different types of log lines because the structure of the log lines are pre-determined by the source code of the SW module. Thus, K may be determined if the source code of the SW module is known. Thus, for example, the manufacturer of the system (e.g. SW module) may provide the value of K. Alternatively, or if the source code is not known, K can be obtained by observing a sufficiently large (diverse) amount of logs produced by the system (SW module) and determining the number of different types of log lines. Practically, the determined number of types of log lines may be considered K. In some cases, to be on the safe side, one may choose K slightly larger than the determined number of types of log lines. K may be determined in the pre-processing phase or prior to the preprocessing phase.

After the sequence of log lines is transformed into a sequence of log identifiers, N+<NUM> iterations are performed wherein the sequence of log identifiers is split into respective two parts. , the splitting is performed for all possible combinations. , if the sequence of log identifiers contains N log identifiers, in each iteration the splitting is performed after position n, wherein n has a respective value between <NUM> and N inclusive. Thus, there are iterations where the two extreme splits (n=<NUM> or n=N) are performed, where one of the two parts is empty and the other contains the entire sequence.

Then, for each split (for each value of n), a respective count vector of length <NUM> is construed by counting the occurrences of each potential log identifier (out of the K possible log identifiers) in front of the split point and behind the split point. The number of occurrences in front of and behind the split point may be denoted as front frequency and rear frequency, respectively. For each split (each value of n), the front frequencies and the rear frequencies are arranged in the respective count vector according to a predetermined order. , the predetermined order is the same for all values of n between <NUM> and N inclusive.

An example of such a predetermined order is as follows: For <NUM> ≤ i ≤ K, the i-th position in the count vector denotes the number of occurrences of log identifier i in front of the split point (the front frequency), whereas for K + <NUM> ≤ i ≤ <NUM> the i-th position in the count vector denotes the number of occurrences of log identifier i behind the split point (the rear frequency).

Then, all the count vectors for the different splits (different values of n between <NUM> and N inclusive) are fed into an Autoencoder (AE), see <FIG>. In this phase, an AE is trained on the entire set of count vectors created in the previous phase. In each AE training step, the input of the AE is a count vector, and the output of the AE is a reconstruction of the count vector (with some error). The difference between the AE's input and output (i.e., the reconstruction error) is the loss function used, in the training phase, as the training feedback for the AE. In the training phase, the autoencoding is typically (but not necessarily) repeated for a lot of sequences of N log lines generated by the same system (e.g. a software module).

The difference may be calculated, for example, as a square root from the sum of the squares of the differences of each component of the count vector and the output vector.

For inference, the architecture of <FIG> may be used, too. For inference, a new log sequence is input into the trained AE in order to detect whether the new log sequence is anomalous or not. That is, the following actions are performed on the new log sequence:.

<FIG> illustrates a method according to some example embodiments of the invention. In <FIG>, the sequence of N log lines is created subsequently from the log lines received from the system (e.g. software module). Also, the method of <FIG> creates a training feedback for each count vector. If the method is used for inference, in some example embodiments of the invention, such a training feedback need not be created. On the other hand, during the training phase, a decision between "anomaly" and "no anomaly" may be omitted in some example embodiments. In particular, in some example embodiments, the threshold for the difference between input count vector and output vector to decide whether the sequence of logs comprises an anomaly may be defined only after the training was performed.

The count vector based log analytics method according to an example embodiment was implemented and compared to the best state-of-the-art log analytics methods published in the scientific literature. The comparison was based on the publicly known HDFS data set, which is a benchmark for log analytics. Table <NUM> shows the performance of multiple state-of-the-art models and the count vector based log analytics method according to the example embodiment.

Based on the above comparison, some benefits of example embodiments of the invention over state-of-the-art methods are the following:.

The count vector method therefore gives a competitive advantage over existing methods, enabling it to be run at the edge, or even on devices, rather than requiring all log data to be streamed to a central computing platform, e.g. in the cloud. This enables to apply the method to sensitive data that must stay at the premise, e.g., for security use cases (applied to user activity log).

<FIG> shows an apparatus according to an example embodiment of the invention. The apparatus may be a log analytics device or an element thereof. <FIG> shows a method according to an example embodiment of the invention. The apparatus according to <FIG> may perform the method of <FIG> but is not limited to this method. The method of <FIG> may be performed by the apparatus of <FIG> but is not limited to being performed by this apparatus.

The apparatus comprises means for converting <NUM>, first means for counting <NUM>, second means for counting <NUM>, means for arranging <NUM>, first means for inputting <NUM>, means for determining <NUM>, means for checking <NUM>, means for marking <NUM>, and second means for inputting <NUM>. The means for converting <NUM>, first means for counting <NUM>, second means for counting <NUM>, means for arranging <NUM>, first means for inputting <NUM>, means for determining <NUM>, means for checking <NUM>, means for marking <NUM>, and second means for inputting <NUM> may be a converting means, first counting means, second counting means, arranging means, first inputting means, determining means, checking means, marking means, and second inputting means, respectively. The means for converting <NUM>, first means for counting <NUM>, second means for counting <NUM>, means for arranging <NUM>, first means for inputting <NUM>, means for determining <NUM>, means for checking <NUM>, means for marking <NUM>, and second means for inputting <NUM> may be a converter, first counter, second counter, arranger, first inputter, determiner, checker, marker, and second inputter, respectively. The means for converting <NUM>, first means for counting <NUM>, second means for counting <NUM>, means for arranging <NUM>, first means for inputting <NUM>, means for determining <NUM>, means for checking <NUM>, means for marking <NUM>, and second means for inputting <NUM> may be a converting processor, first counting processor, second counting processor, arranging processor, first inputting processor, determining processor, checking processor, marking processor, and second inputting processor, respectively.

Some example embodiments (e.g. used for inference) may comprise the means for checking <NUM> and the means for marking <NUM> but may not comprise the means for inputting <NUM>. Some example embodiments (e.g. used for inference) may not comprise the means for checking <NUM> and the means for marking <NUM> but may comprise the means for inputting <NUM>. Some example embodiments may comprise the means for checking <NUM>, the means for marking <NUM>, and the means for inputting <NUM>.

The means for converting <NUM> converts each log line of a sequence of N log lines into a respective log identifier to obtain a sequence of N log identifiers (S110). The log identifiers are selected among K different log identifiers. Each of the K different log identifiers is a respective integer. The sequence of N log lines may be taken from a plurality of log lines. The sequence of N log lines may e sorted, e.g. according to the time of the event reported in the respective log line.

The first means for counting <NUM>, second means for counting <NUM>, means for arranging <NUM>, first means for inputting <NUM>, means for determining <NUM>, means for checking <NUM> (if any), means for marking <NUM> (if any), and second means for inputting <NUM> (if any) perform the following actions for each value of n between <NUM> and N inclusive. The actions for different values of n may be performed consecutively or fully or partly in parallel.

The first means for counting <NUM> counts for each of the K different log identifiers occurrences of the respective log identifier among the first n log identifiers of the sequence of N log identifiers (S120). Thus, the first means for counting <NUM> obtains a front frequency of the respective log identifier for the respective value of n.

The second means for counting <NUM> counts for each of the K different log identifiers occurrences of the respective log identifier among the N-n log identifiers of the sequence of N log identifiers (S130) following the first n log identifiers of the sequence of N log identifiers, i.e. of the remaining log identifiers after the first means for counting <NUM> has counted the occurrences. Thus, the second means for counting <NUM> obtains a rear frequency of the respective log identifier for the respective value of n.

The means for arranging <NUM> arranges the front frequencies and the rear frequencies of the K different log identifiers in a count vector for the respective value of n according to a predefined order (S140). The first means for inputting <NUM> inputs the count vector for the respective value of n into an autoencoder (S150). Thus an output vector for the respective value of n is obtained from the autoencoder. The means for determining <NUM> determines a difference between the output vector for the respective value of n and the count vector for the respective value of n (S160).

If the apparatus comprises the means for checking <NUM> and the means for marking <NUM>, it may perform the following actions:
The means for checking <NUM> checks whether the difference between the output vector for the respective value of n and the count vector for the respective value of n is larger than a threshold (S170). If the difference between the output vector for the respective value of n and the count vector for the respective value of n is larger than the threshold (S170 = yes), the means for marking <NUM> marks the sequence of N log lines as anomalous (S180).

If the apparatus comprises the second means for inputting <NUM>, it may perform the following action:
The second means for inputting <NUM> inputs the difference between the output vector for the respective value of n and the count vector for the respective value of n into the autoencoder as a respective reconstruction error (S190).

If the apparatus comprises the means for checking <NUM>, the means for marking <NUM>, and the second means for inputting <NUM>, S190 and the pair of S170 and S180 may be performed in an arbitrary sequence. They may be performed fully or partly in parallel.

<FIG> shows an apparatus according to an example embodiment of the invention. The apparatus comprises at least one processor <NUM>, at least one memory <NUM> storing instructions that, when executed by the at least one processor <NUM>, cause the apparatus at least to perform the method according to <FIG> and related description.

In some example embodiments, if an anomaly is detected from the log files, a root cause analysis is performed to identify the root cause of the anomaly. If the root cause is identified in the system (e.g. the telco network) providing the logs, the root cause is mitigated to remove the anomaly. In some example embodiments, the root cause of a log anomaly may be identified automatically by correlating the anomalous logs with previous log lines. The correlation may identify that one or more anomalous log lines are usually preceded by some other log lines. The content of the other log lines may be indicative of the root cause of the anomalous log lines (for example, anomalous log lines indicating errors in a network protocol layer may be systematically preceded by log lines that indicate that a certain network interface card had failed - the co-occurrence of the two log lines suggest that the network interface card failure, which is the content of the preceding logs, is the root cause behind the network protocol layer errors). In such a case, in some example embodiments, the system may automatically restart the interface card in order to mitigate the root cause.

For each value of n between <NUM> and N, the arrangement of the front and rear frequencies in the respective count vector is the same. However, there are various options for such an arrangement. For example, a first portion of the count vector may comprise the frequencies ("front frequency") of occurrences of the log identifiers in the first n log lines, and a second portion of the count vector may comprise the frequencies ("rear frequency") of occurrences of the log identifiers in the remaining log lines. The first and second portions may be combined to the count vector in different ways according to a predefined rule. For example, the first and second portions may be concatenated, wherein either the second portion follows the first portion, or the first portion follows the second portion. The first and second portions may be interleaved. For example, the front frequency and the rear frequency of a certain log identifier may be arranged as neighbors in the count vector. Within the first portion, the front frequencies may be arranged according to some predefined order, e.g. such that the values of the corresponding log identifiers increase (or decrease) monotonously. Within the second portion, the rear frequencies may be arranged according to some predefined order, e.g. such that the values of the corresponding log identifiers increase (or decrease) monotonously. The arrangement of the front frequencies in the first portion and the arrangement of the rear frequencies in the rear portion may be the same or different from each other.

The log lines of a sequence of N log lines are typically sorted in time (the time of the event reported in the log line) when they are received from the system. If it is not known whether or not the sequence of N log lines is sorted in time or if it is known that the N log lines are not sorted in time, in some example embodiments, the log lines are sorted in time before the detection of anomalous behavior is started based on the (sorted) sequence of log lines. However, it is not necessary that the log lines of the sequence of log lines are sorted in time. They may be sorted according to some other criterion, or they may be unsorted.

If there are several input log sequences, they may be processed independently from each other, which enables massive parallelization over multiple log data sources. Some of the input log sequences may comprise one or more of the same log lines, or the input log sequences may not have any log lines in common.

Some example embodiments are explained with respect to a <NUM> network. However, the invention is not limited to <NUM>. It may be used in other communication networks, too, e.g. in previous of forthcoming generations of 3GPP networks such as <NUM>, <NUM>, or <NUM>, etc. It may be used in non-3GPP communication networks, too, such as in wired communication networks. It may be used in any system which produces a number of log lines.

Names of network elements, network functions, protocols, and methods are based on current standards. In other versions or other technologies, the names of these network elements and/or network functions and/or protocols and/or methods may be different, as long as they provide a corresponding functionality. The same applies correspondingly to the terminal.

If not otherwise stated or otherwise made clear from the context, the statement that two entities are different means that they perform different functions. It does not necessarily mean that they are based on different hardware. That is, each of the entities described in the present description may be based on a different hardware, or some or all of the entities may be based on the same hardware. It does not necessarily mean that they are based on different software. That is, each of the entities described in the present description may be based on different software, or some or all of the entities may be based on the same software. Each of the entities described in the present description may be deployed in the cloud.

According to the above description, it should thus be apparent that example embodiments of the present invention provide, for example, a means for service assurance or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).

Implementations of any of the above described blocks, apparatuses, systems, techniques or methods include, as non-limiting examples, implementations as hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof. Each of the entities described in the present description may be embodied in the cloud.

It is to be understood that what is described above is what is presently considered the preferred example embodiments of the present invention. However, it should be noted that the description of the preferred example embodiments is given by way of example only and that various modifications may be made without departing from the scope of the invention as defined by the appended claims.

Claim 1:
Apparatus comprising:
one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform:
converting each log line of a sequence of N log lines among a plurality of log lines into a respective log identifier among K different log identifiers to obtain a sequence of N log identifiers;
for each value of n between <NUM> and N inclusive:
for each of the K different log identifiers: counting occurrences of the respective log identifier among the first n log identifiers of the sequence of N log identifiers to obtain a front frequency of the respective log identifier for the respective value of n; and
for each of the K different log identifiers: counting occurrences of the respective log identifier among the N-n log identifiers of the sequence of N log identifiers following the first n log identifiers of the sequence of N log identifiers to obtain a rear frequency of the respective log identifier for the respective value of n;
arranging the front frequencies and the rear frequencies of the K different log identifiers in a count vector for the respective value of n according to a predefined order;
inputting the count vector for the respective value of n into an autoencoder to obtain, from the auto encoder, an output vector for the respective value of n;
determining a difference between the output vector for the respective value of n and the count vector for the respective value of n; and at least one of the following:
checking whether the difference between the output vector for the respective value of n and the count vector for the respective value of n is larger than a threshold and marking the sequence of N log lines as anomalous if the difference between the output vector for the respective value of n and the count vector for the respective value of n is larger than the threshold; or
inputting the difference between the output vector for the respective value of n and the count vector for the respective value of n into the auto encoder as a respective reconstruction error;
wherein each of the K different log identifiers is a respective integer.