An LSTM-based numerical control system log auditing method and terminal

Abstract

The application belongs to the technical field of log auditing, and discloses a numerical control system log auditing method and terminal based on LSTM, which comprises the following steps: a new log analysis tool based on the Drain log analysis tool is used to reconstruct three types of log exclusive analyzers, and log analysis is performed into template statements and variables; the log template statements are correspondingly converted into log keys; a bidirectional long short-term memory model is used to identify the log mode; and through the prediction of the log keys within a certain window size and the calculation of the Gaussian error of the generated log, the time sequence-based abnormal detection of the log is performed. The application shows high precision on the classical data set, and the accuracy, recall rate and F value are higher than those of the traditional method. The application improves the precision of log analysis, perfects the system log processing procedure, realizes full-automatic log analysis, realizes two main abnormal models in the system, tests the hyperparameters of the model, and perfects the procedure details of log analysis to input model.

Description

Technical Field

[0001] This invention belongs to the field of log auditing technology, and in particular relates to a log auditing method and terminal for CNC systems based on LSTM. Background Technology

[0002] Currently, with the rapid development of big data technology, log auditing technology is constantly being upgraded to meet the needs of more fields.

[0003] With the increasing number of cyberattacks, attack methods and patterns are constantly evolving. Traditional rule-based log analysis techniques, due to their low efficiency, low accuracy, and inability to adapt to environmental changes, can no longer meet current cybersecurity needs. With the development of big data and artificial intelligence technologies, log analysis methods are gradually shifting from traditional rule-based analysis to machine learning-based pattern recognition.

[0004] Existing log analysis methods are mainly divided into two categories: one is based on models such as statistical analysis, machine learning, and deep learning; the other is based on expert knowledge and pattern recognition. Firstly, models based on statistical analysis, machine learning, and deep learning are currently the most popular and researched log analysis models due to their low dependence on log data and their ability to describe complex change patterns well. Secondly, methods based on expert knowledge and pattern recognition are also mainstream research methods in current log analysis. These methods analyze log data based on user experience and attack characteristics, thus having certain limitations. To overcome these shortcomings, log analysis methods based on log feature selection and machine learning have emerged. These methods can predict the most likely hosts and attack processes from large amounts of attack log data. Because traditional log analysis methods are rule-based, they are prone to false positives or false negatives. In contrast, models based on machine learning and deep learning do not preprocess the raw data, thus enabling rapid and accurate attack detection, early warning, and response when facing new attack methods and patterns.

[0005] A more advanced approach is to use deep learning for anomaly detection in CNC systems, as the system log data volume is sufficient for deep learning to learn features for processing. Furthermore, both supervised and unsupervised learning have been discussed and applied to log anomaly detection.

[0006] At the application level, machine learning-based log data analysis methods have become mainstream. For example, running machine learning-based log auditing models on big data platforms such as Hadoop and Spark has yielded significant results. However, these methods have the following drawbacks: 1. They cannot audit newly generated log data; 2. Existing machine learning algorithms have many problems when processing logs: for example, they cannot fully utilize historical data or do not consider the impact of new data; 3. Most existing research is based on a specific classification or clustering task and does not fully consider the correlation between logs; 4. Existing methods cannot handle the large amount of noise and abnormal data in logs.

[0007] In the industry, various security auditing systems already exist, such as log auditing systems and intrusion detection systems. Mature products include NSFOCUS's NIDS and QingTeng's Wanxiang. These systems can complete a full set of inspection operations, including data collection, auditing, and final anomaly detection. However, in actual deployments, these systems are mostly suitable for a single type of host, and the detected anomalies cannot be fully covered, the accuracy cannot be guaranteed, and high false positives require manual judgment. They also require relatively large-scale deployments, some even requiring joint deployment on multiple hosts.

[0008] Based on the above analysis, the problems and defects of the existing technology are as follows: the existing log auditing technology has low accuracy when parsing logs, cannot audit newly generated log data, and cannot handle a large amount of noise and abnormal data in the logs; the existing technology cannot simultaneously detect two different types of anomalies, namely execution path and parameters. Summary of the Invention

[0009] To address the problems existing in the prior art, this invention provides a log auditing method for CNC systems based on LSTM.

[0010] This invention is implemented as follows: a CNC system log auditing method based on LSTM, the LSTM-based CNC system log auditing method comprising:

[0011] Using a new log parsing tool that is an improvement on the Drain log parsing tool, three types of log-specific parsers are reconstructed to parse logs into template statements and variables; and log template statements are converted into log keys accordingly.

[0012] Log pattern recognition is performed using a bidirectional long short-term memory model: time-series-based anomaly detection is achieved by predicting log keys within a certain window size and calculating the Gaussian error of the log entries.

[0013] Furthermore, the LSTM-based CNC system log auditing method includes the following steps:

[0014] Step 1: Use the fixed-depth parse tree in the self-developed tool ReDrain to parse the logs and separate the log template statements and log parameters.

[0015] Step two involves using a predefined log template dictionary to convert log template statements into log keys (corresponding numbers). These log keys are then categorized into different sessions based on different session flags, resulting in a time-series-based log key sequence within the same session. Log variables are then divided into different log types, and variables from the same log type are input into an anomaly detection model with the same parameters. These steps yield data for feature selection.

[0016] Step 3: Construct and train the execution path anomaly detection model. Use Keras to build a two-layer Bi-LSTM neural network to train the log keys parsed from normal mode logs. Use the trained execution path anomaly detection model to detect log keys that are a mixture of normal and abnormal modes, and output the execution path anomaly detection results.

[0017] Step four involves constructing and training a parameter anomaly detection model. This model is then used to detect anomalies in key system records within the log parameter values. Overall, for reusability and usability, the parameter anomaly detection model shares a similar basic structure with the execution path anomaly detection model. However, adjustments have been made to the input and output. Furthermore, because the parameter vector type is smaller than the log key, a shorter sliding window value is chosen to improve computational efficiency.

[0018] Step 5 involves backpropagating the incorrectly predicted samples and updating the parameters. The already trained model is then retrained using the `fit` function of the Keras framework. After training and adjusting the weights, the network can successfully identify normal log key sequences.

[0019] Furthermore, the improved open-source tool Drain uses a fixed-depth parse tree to parse logs, obtaining log template statements and log parameters, including:

[0020] First, based on prior knowledge of each logging framework, some expressions are defined to parse the log variables [r'(\d+\.){3}\d+'];

[0021] Secondly, log message length grouping is performed; the first flag is used for searching: the search is based on the first flag being a constant, and <*> is used to represent it when the first flag is a variable; a maxchild parameter is set to constrain the maximum child node tree of a node;

[0022] Finally, the search continues based on the similarity of the markers. When the simSeq with the largest similarity to the input log is obtained in the parse tree, it is compared with the similarity threshold st passed in the tool. If it is greater than the threshold, it is a suitable log group. If the marker of the input log is the same as the marker at the same position in the subtree, no update is performed. If the marker of the input log is different from the marker at the same position in the subtree, the different markers in the subtree are replaced with <*>. If no match is found, a new subtree and a new log group are created.

[0023] Furthermore, the log message length is the number of separated flags in the log statement; and maxchild is greater than 3.

[0024] The search continues based on the similarity of the markers as follows:

[0025]

[0026] Where seq1 represents the preprocessed log input at this point, seq2 represents the log template represented by the log group represented by the subtree in the tree; I represents the i-th flag in the input sequence; N represents the sequence length, equ as follows:

[0027]

[0028] Furthermore, the feature vectorization processing of log template statements and log parameters using different methods includes:

[0029] (1) For log keys: use template statements to perform statistics, and use the sorted number after the template statement statistics as the code of the log key; or directly perform feature processing on the log key through statistics; the log key is the log template statement;

[0030] (2) Log parameters: The obtained parameter list is preprocessed to remove flag parameters, punctuation marks, special characters and other information that cannot be used as a standard for judging parameter anomalies; the remaining parameter characters are arranged into a two-dimensional matrix, and each x on the x-axis represents a parameter of a log; the text.Tokenizer module under the Keras framework is used to count the text and convert it into a dictionary to obtain the text word frequency information within the parameter value; the built-in function is used to convert all the text in the matrix into numbers.

[0031] Furthermore, the construction and training of the execution path anomaly detection model includes:

[0032] (1) The execution path anomaly detection model is constructed as follows:

[0033] The input layer is used to input a sequence of log keys w, where w = {x}, representing the size of the sliding window. t-h ,…,x t-2 ,xt-1 In the context of log keys, x represents a log key obtained from parsing real logs, belonging to the unique log key set X; x t Indicates the next log key;

[0034] The output layer uses a softmax function for multi-class classification to transform the output of the last hidden layer into a probability distribution function, representing the probability matrix Pr(x). t =k i |x t-h ,…,x t-2 ,x t-1 The probability matrix Pr(x) t =k i ) is used to represent the probability distribution of all log keys from X; the probability distribution of all log keys from X represents the probability that the next log key belongs to a class of log keys.

[0035] (2) Training the execution path anomaly detection model includes: extracting a small number of segments from the log set under normal conditions in the target system as the training set; and using the training set to train the execution path anomaly detection model.

[0036] Furthermore, the step of using the trained execution path anomaly detection model to detect whether the target log key is normal, and obtaining the log template statement anomaly detection result, includes:

[0037] The first h parsed log keys are sent to the execution path anomaly detection model to obtain multiple log keys; the first g log keys are retained, and it is determined whether the target log key is among the retained log keys. If it is, the target log key is determined to be normal; otherwise, the target log key is abnormal.

[0038] The exception of the target log key indicates that an error has occurred at the program location represented by the log statement of the exception log key.

[0039] Furthermore, the construction and training of the parameter anomaly detection model includes:

[0040] The parameter anomaly detection model is as follows:

[0041] The input layer is used to input the parameter value vector in the timestamp of the log;

[0042] The output layer is used to output a parameter prediction vector corresponding to the dimension of the input vector based on the sequence of parameter value vectors in the most recent historical records, as a prediction for the next parameter value vector;

[0043] The training parameter anomaly detection model includes: normalizing the values ​​in each vector by using the average and standard deviation of all values ​​at the same parameter position in the training data, setting the MSE function as the loss function, and training the parameter anomaly detection model using a normal dataset.

[0044] Furthermore, the step of using a trained parameter anomaly detection model to detect whether there are anomalies in key system records within log parameter values ​​includes:

[0045] The MSE between predicted and true values ​​is calculated using a parametric anomaly detection model. The MSE calculation formula is as follows:

[0046]

[0047] Where, x t Represents the true value, x p represents the predicted value, and n represents the average value.

[0048] Choose to use the calculation function of the stats module in scipy as the confidence interval for MSE; if the error is within the high confidence interval of MSE, the corresponding log is considered normal; otherwise, the log is considered abnormal.

[0049] Another object of the present invention is to provide an information data processing terminal for performing the steps of the Bi-LSTM-based numerical control system log auditing method.

[0050] Based on the above technical solutions and the technical problems solved, the advantages and positive effects of the technical solution to be protected by this invention are as follows:

[0051] First, this invention implements an LSTM-based log anomaly detection system and updates the log parsing tool. The log anomaly detection system consists of two parts: log parsing feature extraction and anomaly detection. For log parsing feature extraction, this invention improves upon the deep parse tree-based log parsing tool Drain, which offers better performance than the traditional method Spell. To perform complete feature extraction and separate special flag bits, this invention rewrites Drain, replacing it with a new Drain-based log parsing tool, ReDrain. Anomaly detection is divided into an execution path anomaly detection model and a parameter anomaly detection model, both built on LSTM. The log key sequence is input into the execution path anomaly detection model, which outputs the probability of various log keys appearing at the next position. An alarm is triggered if a log key is not within the probability interval. The anomaly detection problem is transformed into a multi-classification problem. Parameter variables are input into the parameter anomaly detection model, which outputs a prediction of the parameter value at the next position. An alarm is triggered if the mean squared error between the true value and the predicted value exceeds the confidence interval of the Gaussian distribution of the mean squared error.

[0052] Second, considering the technical solution as a whole or from a product perspective, the technical effects and advantages of the technical solution to be protected by this invention are specifically described as follows:

[0053] This invention demonstrates high precision on classic datasets, with accuracy, recall, and F-score all exceeding those of traditional methods. Based on the log parsing tree in the open-source tool Drain, this invention rewrites three types of log-specific parsers, improving log parsing accuracy and integrating them into the system. This improves the system's log processing flow, achieving fully automated log parsing, and the tool is named ReDrain. It also implements the two main exception models within the system, tests and improves the model's hyperparameters, and refines the details of the log parsing and input process into the model.

[0054] This invention utilizes a novel log parsing tool to automate the process from log parsing to log anomaly detection. It improves upon the low accuracy of deep parse trees when handling similar template statements by using a dictionary and adjusting the tree depth. The output of the deep parse tree is also adjusted to be suitable for log anomaly detection input.

[0055] This invention uses a bidirectional long short-term memory model to identify log patterns, essentially predicting log statements based on time sequence. The Gaussian error of a given log entry is calculated; if the error falls within the high confidence interval of the aforementioned Gaussian distribution, the corresponding log entry is considered normal.

[0056] Third, as supplementary evidence of the inventive step of the claims of this invention, it is also reflected in the following important aspects:

[0057] The technical solution of this invention fills a technological gap in the industry both domestically and internationally:

[0058] The open-source log parsing tool Drain, both domestically and internationally, cannot be directly applied to logs due to the following drawbacks:

[0059] 1. Variable parsing heavily relies on regular expressions. Special variables require custom regular expressions. For example, separating sessions requires using `block_id` or `instance_id`.

[0060] 2. The parsing of different log types only differentiates them based on parameters. This approach is insufficient for handling single-type logs and cannot be used directly.

[0061] 3. Certain types of log parsing issues. In OpenStack log parsing, for example, due to an initial depth issue, the parsing tree depth for "Took<*>.<*> seconds to<*>the spawn the hypervisor." and "Took<*>.<*> seconds to<*>the destroy the hypervisor." runs out of depth when reaching spawn and destroy, and they are no longer used as nodes for tree construction. Therefore, Drain converts them into a template and incorrectly passes the keywords spawn and destroy as parameters.

[0062] This technical solution rewrites the ReDrain tool, introducing a new flag separation mechanism specifically for OpenStack. It uses a dictionary as input to address certain log parsing issues. However, considering the complexity of the parameters and the increased operational differences of the rewritten log parsing tool across different log types, this paper chooses to use the rewritten Drain tool as the base class. Each log type will have its own dedicated parser, which will inherit from the base class and override some functions.

[0063] For anomaly detection, Bi-LSTM was used. Since Bi-LSTM can encode information from back to front, it showed better performance than LSTM in experiments. Because the parametric model only learns normal behavior patterns, even if the detected log key sequence is normal, it will still be flagged as an error if it contains log key sequence segments not included in the training set. Therefore, this paper designed an update mechanism to retrain the model using the Keras framework's `fit` function. After training and adjusting the weights, the network can successfully identify normal log key sequences, resulting in higher anomaly detection accuracy. Attached Figure Description

[0064] Figure 1 This is a schematic diagram of the log parsing tree provided in an embodiment of the present invention;

[0065] Figure 2 This is a flowchart of a CNC system log auditing method based on Bi-LSTM provided in an embodiment of the present invention.

[0066] Figure 3 This is a schematic diagram of the original log provided in an embodiment of the present invention;

[0067] Figure 4 This is a diagram showing the parsing results of the original log tool provided in this embodiment of the invention;

[0068] Figure 5 This is a diagram showing the parsing results of the log rewriting tool provided in this embodiment of the invention;

[0069] Figure 6 This is a schematic diagram of the log key-value dictionary provided in an embodiment of the present invention;

[0070] Figure 7 This is a structural diagram of the parameter anomaly detection model provided in the embodiments of the present invention;

[0071] Figure 8 This is a large image showing the anomaly detection results of the Took<*> seconds to build instance parameter provided in this embodiment of the invention;

[0072] Figure 9 This is a small image showing the anomaly detection results of the Took<*> seconds to build instance parameter provided in this embodiment of the invention;

[0073] Figure 10 This is a schematic diagram of the "Took<*> seconds to build instance" alarm information, outlier at position 129, and outlier at position 179 provided in this embodiment of the invention.

[0074] Figure 11 This is a large image showing the abnormal detection results of the parameter "Took<*>.<*>seconds to<*>the<*>thehypervisor." provided in the embodiments of the present invention;

[0075] Figure 12 This is a small image showing the abnormal detection results of the parameter "Took<*>.<*>seconds to<*>the<*>thehypervisor." provided in the embodiments of the present invention;

[0076] Figure 13 This is a diagram illustrating the alarm message "Took<*>.<*> seconds to<*>the<*>thehypervisor.", the abnormal value at position 129, and the abnormal value at position 179 provided in this embodiment of the invention.

[0077] Figure 14 This is a structural diagram of the path anomaly detection model provided in an embodiment of the present invention;

[0078] Figure 15 This is a parameter performance comparison chart provided in the embodiments of the present invention;

[0079] Figure 16 This is a training loss variation diagram provided in an embodiment of the present invention;

[0080] Figure 17 This is an HDFS result diagram provided in an embodiment of the present invention;

[0081] Figure 18 This is an OpenStack result diagram provided in an embodiment of the present invention. Detailed Implementation

[0082] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0083] like Figures 1-2 As shown, the LSTM-based CNC system log auditing method provided in this embodiment of the invention includes the following steps:

[0084] S101 uses a fixed-depth parse tree in the self-developed tool ReDrain to parse the logs and separate the log template statements and log parameters.

[0085] S102, using a priori defined log template dictionary, log template statements are converted into log keys, i.e., corresponding numbers. Log keys are then categorized into different sessions using different session flags, resulting in a time-series-based log key sequence within the same session. Log variables are divided into different log types, and variables from the same log type are input into an anomaly detection model with the same parameters to obtain feature selection data.

[0086] S103, Construct and train the execution path anomaly detection model. Use Keras to construct a two-layer Bi-LSTM neural network to train the log keys parsed from normal mode logs. Use the trained execution path anomaly detection model to detect log keys that are a mixture of normal and abnormal modes, and output the execution path anomaly detection results.

[0087] S104, Build and train a parameter anomaly detection model, and use the trained parameter anomaly detection model to detect whether there are anomalies in the system's key records in the log parameter values.

[0088] S105, after backpropagating the incorrectly predicted samples, the parameters are updated. The already trained model is then retrained using the `fit` function of the Keras framework. After training and adjusting the weights, the network can successfully identify normal log key sequences.

[0089] Overall, the parameter anomaly detection model in S104 shares a similar basic structure with the execution path anomaly detection model for reusability and usability. However, adjustments have been made to the inputs and outputs. Furthermore, because the parameter vector type is smaller than the log key, the sliding window value is shortened to improve computational efficiency.

[0090] The CNC system log auditing method based on Bi-LSTM provided in this embodiment of the invention specifically includes:

[0091] 1. Log Analysis

[0092] 1.1 Log parsing principles

[0093] Each log entry is printed by a log statement, recording a specific system time that occurred. The content includes flags such as address and total time, as well as a header provided by the logging framework, containing information such as a timestamp, log level (for logging errors / messages / debugging), and the component that generated the log message. These are fixed, built-in parts of the logging framework, making it easy to construct the header structure for different logging frameworks and facilitating parsing. Conversely, statements written by developers with variable content present structuring difficulties because they consist of fixed strings and variable values. The fixed string portion displays the event template for the log message; events of the same type remain unchanged. The goal of log parsing is to convert each log statement into variable parameters and the corresponding event template.

[0094] 1.2 Fixed-Depth Parse Tree

[0095] Fixed-depth parse tree algorithms first define some expressions based on prior knowledge of each logging framework, such as those for parsing message headers. <date> <time> <pid> <level> <component> : <content>The structured expression parses the log variable [r'(\d+\.){3}\d+']. A dataset typically requires only a few simple regular expressions. Upon reaching the parsing step, the first level of the parse tree represents grouping by log message length, where message length represents the number of separated markers in the log statement. This process presupposes that log statements with the same template have the same log word length.

[0096] After the initial judgment based on the length of log words, the next step is to use the first flag for searching. The search is based on the first flag being a constant. When the first flag is a variable, it is represented by <*>, thus eliminating cases where the first step involved a variable. For example, in the statement "Delete VM life cycle event", the first-level node is Delete, and the second-level node is VM. Drain also sets a maxchild parameter to constrain the maximum number of child nodes a node can have. If a node has maxchild children, any unmatched flag will be matched using the internal special symbol <*>. This improves efficiency and prevents excessively long subtrees from causing long parsing times. The root level occupies one maxchild, meaning maxchild must be at least 3; otherwise, the entire tree would only contain the root node and a node representing the length.

[0097] The subsequent search will be performed based on the similarity of the markers, using the following formula:

[0098]

[0099] In the formula, seq1 represents the preprocessed log input at this point, and seq2 represents the log template represented by the log group represented by the subtree in the tree. I represents the i-th flag in the input sequence. N is the sequence length, and equ is Equation 2:

[0100]

[0101] When the flags are the same, the above formula equals 1. After finding the simSeq in the parse tree that is the largest with the input log, it is compared with the similarity threshold st passed in to the tool. If it is greater than the threshold, it is considered a suitable log group. Additionally, Drain processes the input log and flags that exist at the same position in the subtree. When two flags are the same, no update is performed. When the flags are different, the different flags in the subtree are replaced with <*>. If no flag is found, a new subtree and a new log group are created.

[0102] 1.3 Feature Extraction

[0103] After the above analysis, this invention will obtain the separated log template statements and log parameters, thus solving the structured problem. However, the processing result at this point is not in a form that a neural network can recognize, and the parameter list also includes statements treated as variables. Since LSTM can only accept vector-based input, this invention also needs to vectorize the log template. The feature extraction process involves converting the string into quantifiable numbers to construct a matrix as a feature vector. For log keys and parameters, due to their different formation methods and meanings, two different featureization methods are used.

[0104] 1.3.1 Log Key Encoding

[0105] We use template statements for statistical analysis, and the sorted numbers resulting from the template statements are used as the encoding for the log keys. This operation assumes a limited number of log templates in the system. Since the program that outputs the log statements is written by developers, the types of logs should be constant and small in scale, barring any new component additions or program modifications. Therefore, we can directly use statistical characterization.

[0106] 1.3.2 Log Parameter Encoding

[0107] Unlike log key encoding, parameter values ​​lack template correspondence and statistical methods. Parameter values ​​are dynamically generated by actual events during program execution, making them impossible to quantify or directly correlate. The parameter values ​​contain numerous variables, such as image ID, runtime, and target ID. Using an integer permutation encoding approach would result in an extremely sparse matrix. Another approach is to customize the LSTM model and input processing for each log template, given that the parameter positions and types are identical across templates. However, considering the 29 log templates in the HDFS log system, 40 in OpenStack, and the sheer number of templates in Linux and Windows logs and components, this method presents a massive implementation challenge. This invention preprocesses the parameter list after log parsing, removing flag parameters, punctuation marks, and special characters—information that cannot be used as anomaly criteria—to prevent affecting character accuracy. The remaining parameter characters form a two-dimensional matrix, where each x-axis represents a log parameter. The `text.Tokenizer` module from the Keras framework is then used to statistically analyze the text and convert it into a dictionary, thus obtaining the word frequency information within the parameter values. However, in practice, it was found that the above operations are unnecessary if the matrix contains no text and consists entirely of numeric variables. A built-in function was then used to convert all text within the matrix into numbers. It's worth noting that the sequence processed by the built-in function is not a uniform length sequence. When further input into the neural network, it needs to be padded with zeros to achieve the maximum length, thus forming a uniform length sequence.

[0108] 2 Anomaly Detection Model

[0109] After obtaining the feature selection data, it is necessary to construct a corresponding knowledge graph to transform the complex and raw long data into concise triple data, which is beneficial for subsequent situational awareness work.

[0110] 2.1 Execution Path Anomaly Detection Model

[0111] This invention first describes the input and output of the execution path anomaly detection model and its structure. Since the number of log statements in the system is relatively constant and pre-integrated by the system developers, the total number of different log keys is also constant. X = {x1, x2, x3, ..., x...} t } represents a unique set of log keys parsed by a log parsing tool after log generation (distinguished by session flags within the same session). When a log entry is parsed as a log key, the sequence of log keys reveals a path representing the order in which programs run within the session. Let k i This represents a log key at any position in a log key sequence. Note that k... i It will be any log key in the unique log key set X. It will also be determined by the sequence of log keys preceding it.

[0112] Using the above method, the anomaly detection problem of log key sequences is transformed into a multi-class classification problem, where each log key in the unique set X represents a class. The execution path anomaly detection model is thus used as a multi-class classifier. Its input is a sequence of log keys of the sliding window size. The output is a probability distribution of all log keys from X, representing the probability that an upcoming log key belongs to each class.

[0113] (1) Model input: Assume x t It is the next log key. Used to predict x. t The input to the probability is a sequence of log keys w, where w = {x}, determined by the size of the sliding window. t-h ,…,x t-2 ,x t-1 Each x is obtained by parsing real logs and belongs to the unique log key set X. It's worth noting that network communication logs such as "GET<*>Http Status" or those requiring repeated processing will generate multiple duplicate log keys. In other words, log keys in w may be duplicated.

[0114] (2) Model output: The output is a probability matrix Pr(x) t =k i |x t-h ,…,x t-2 ,x t-1 The output layer uses a softmax function for multi-class classification to transform the output of the last hidden layer into a probability distribution function, representing Pr(x). t =k i ).

[0115] (3) Training Phase: A small subset of logs from the normal state of the target system is selected as the training set. For each log sequence of the size of a sliding window in the training set, the model uses the difference between the log key at the next position and the predicted log key as the loss to update the weights within the hidden layers. Assume a log file from the same session is parsed into a sequence of log keys: {x 22 ,x5,x 11 ,x9,x 11 ,x 26 Assuming a sliding window value h = 3, and training_x and training_y are generated based on this sliding window value, then the model's training_x will be {{x}. 22 ,x5,x 11 },{x5,x 11 ,x9},{x 11 ,x9,x 11 }}, train_y will be {{x9,x 11 ,x 26 }}. Learning is performed using only the normal dataset.

[0116] (4) Detection phase: In order to detect a target log key x t (Parsing from a target log statement) Whether it can be considered normal or abnormal, this invention will send the first h parsed log keys to the model, that is, w = {x t-h ,…,x t-2 ,x t-1 The output is a probability distribution Pr(x). t =k i |x t-h ,…,x t-2 ,x t-1 This describes the probability that, given a historical context, each log key will choose a unique set of log keys as the next log key. It's important to note that the upcoming log key is not unique. If the system is establishing communication, subsequent log entries might be "Reconnect<*> for answer" or "GET<*> Http Status". Both are normal system behaviors. The model can learn this behavior through training, provided that this pattern has occurred during training. Therefore, the operation of this invention for the probability matrix of each output log key is to sort all possible log keys and calculate their probabilities Pr(x). t =k i The algorithm selects the top g log keys. If a key falls within the top g range, its value is considered normal. Otherwise, the corresponding log entry is considered abnormal, meaning that the program location represented by the log statement that generated that key has encountered an anomaly.

[0117] 2.2 Parameter Anomaly Detection Model

[0118] Overall, the parameter anomaly detection model shares a similar basic structure with the execution path anomaly detection model for reusability and usability considerations. However, adjustments have been made to the input and output. Furthermore, because the parameter vector type is smaller than the log key, this invention shortens the sliding window value to improve computational efficiency.

[0119] 1) Model Input: The input for each time step is simply a vector of parameter values ​​at that timestamp. This invention normalizes the values ​​in each vector by using the average and standard deviation of all values ​​at the same parameter position in the training data. However, this invention does not do this during the validation phase because outlier parameter values ​​already existing in the log set will uniformly affect the average value at that position. This increased average value might cause outliers that were originally large to appear as normal due to the increased average value. However, during the detection phase, since the input is a phase-specific parameter value, the above method will directly display outliers, which will then be removed in the next detection.

[0120] 2) Model output: Based on the sequence of parameter value vectors from the most recent historical records, the output is a parameter prediction vector corresponding to the dimension of the input vector, which serves as a prediction for the next parameter value vector.

[0121] 3) Training Process: For complex parameter sequences, the training process optimizes the weights of the network layers to minimize training loss. This improves the fit, i.e., reduces the error between the predicted values ​​and the true parameter vector. Unlike path anomaly detection, which directly predicts the parameters at the corresponding positions, path anomaly detection predicts each key value in a unique log key set. The latter requires using a softmax function in a fully connected layer to convert the predicted values ​​into predicted probabilities at each position, while the former directly outputs the predicted values ​​using a fully connected layer. Therefore, in non-multi-class classification problems, mean squared loss (MSE) can be directly used to compare the difference between predicted and true values ​​during training, minimizing the error. Therefore, the MSE function is set in the loss function. Only normal datasets are used to learn normal patterns.

[0122] 4) Anomaly Detection Phase: The error between the predicted value and the observed actual vector is measured using the mean squared error (MSE). This invention does not use a specific magic error threshold; instead, it uses a normal training set to find the corresponding MSE threshold, which is a Gaussian distribution of the mean squared error. The validation set is composed of a normal dataset and anomaly datasets. This invention uses a model trained on the training set to calculate the MSE between the predicted value (and the previously generated parameter vector values ​​in the test set) and the true value. At each time step, the error between the predicted vector and the actual vector in the validation set is modeled as a Gaussian distribution. The MSE calculation formula is as follows:

[0123]

[0124] x t x is the true value. p The value is the predicted value, and n represents the average of the above calculations.

[0125] In practical use, if the error falls within the high confidence interval of the Gaussian distribution, the corresponding log is considered normal. Otherwise, it is considered abnormal. The confidence interval for the Gaussian distribution is calculated using the `stats` module in SciPy.

[0126] By detecting key system records such as execution time and execution target within parameter values, this method can detect various types of performance anomalies.

[0127] 3 Overall Technical Route

[0128] ReDrain, a new log parsing tool improved upon Drain, parses logs into template statements and variables. The template statements are then converted into log keys. Predictions are made within a certain window size based on these log keys, enabling time-series-based anomaly detection. False positive log keys are later returned for online model updates.

[0129] The original parsed log sample is a network communication log collected from the OpenStack API, such as... Figure 3 As shown:

[0130] The parsing of the raw log is as follows Figure 4 As shown, EvenId is not correctly mapped to the template, and there is no instance_id for separating sessions.

[0131] After restructuring, two new columns, `Id_flag` and `time_para`, were added, representing `instance_id` and the time interval from the previous log entry, respectively. The log template and log key are now correctly mapped. The parsed content is as follows: Figure 5 As shown:

[0132] The original parsing tool outputs EventId directly from the hash of the log template, which cannot directly correspond to the numerical feature extracted from the EventId. This paper introduces a mechanism to store a key-value dictionary. After the initial parsing, a dictionary of log keys and event templates for that parsing is saved. This dictionary is also generated using `enumerate`. Before the initial parsing, the correspondence between log keys and event templates is unpredictable because `enumerate` uses a set, resulting in unordered values. The dictionary initialized after the initial parsing ensures that the correspondence between log keys and event templates remains consistent in subsequent parsing. New log templates encountered in subsequent parsings are sequentially incremented and updated in the log keys. The generated and maintained conversion dictionary is as follows: Figure 6 As shown.

[0133] Additionally, to separate the sessions used for model training later, a flag was added (a special flag in variables for HDFS and OpenStack; for Linux, the process generating the log is distinguished by the flag). The time interval between two log entries also needs to be added to the parameter list later.

[0134] In the original log parsing tool, the authors set the parameters as input_dir (input directory), output_dir (output directory), log_file (log file name), log_format (log message structure), regex (regular expression for matching), st (similarity), and depth (depth). Different parameters were passed for different log types. Considering the excessive complexity of parameters and the increased operational differences of the rewritten log parsing tool across different log types, this paper chooses to use the rewritten Drain tool as the base class. Each log type will have its own dedicated parser, which will inherit from the base class and override some functions.

[0135] The overall structure of the parameter anomaly detection model is similar to that of the execution path anomaly detection model, employing two hidden layers and a fully connected layer before the output to convert the output of the previous hidden layer into a predicted value for the corresponding position. However, the number of neurons has been modified. Since even the lowest-key HDFS log set has 29 keys, the dataset used for training the parameter anomaly detection model in actual detection will be the total number of logs divided by the number of log keys. Therefore, if the input dataset for training is insufficient, it will affect the performance of the parameter anomaly detection model. Thus, the number of neurons is increased to better learn the data relationships within the limited dataset. The number of neurons, 'a', is increased from 64 to 100. Simultaneously, the loss function of the connected layers is changed from classification cross-loss entropy to MSE. Furthermore, since the method for judging anomalies is to calculate the MSE difference between the predicted and true values, predicted values ​​near the true values ​​are also considered normal. Therefore, the accuracy of consistency judgment is not used in the fully connected layers. The activation function remains ReLU.

[0136] Since the input consists of all parameters under the same log key, the parameters in a single log entry are no longer one-dimensional data like the log key itself; the input must be determined by the number of parameters in each log entry. Furthermore, missing parameters due to parsing errors need to be padded in the vector; otherwise, the model's input dimension will be incorrect. Also, because the number of parameter types decreases within each time window, the dimension of a single vector within that window increases. Therefore, we choose to shorten the time window. This reduces model training time and improves model detection performance. Since the number of prediction categories to be detected has decreased, this operation will not affect the model's detection accuracy.

[0137] The output dimension also corresponds to the number of parameters in each log entry, representing the predicted value for each position within the parameters. Figure 7 This is a schematic diagram of the network structure.

[0138] Model performance evaluation

[0139] Log parameters from the OpenStack dataset were used to test the model's performance, primarily for the following reasons:

[0140] OpenStack logging parameters are relatively simple. The main parameters are time-based parameters such as "Took<*>.<*> seconds to build instance." which declares the time spent building an instance, or "Took<*>.<*> seconds to <*> the spawn the hypervisor." which declares the operation time. Alternatively, there are time-based parameters such as "Total vcpu:<*>VCPU, used:<*>.<*>VCPU" which declares the allocation and usage of space. Logs after an injection exception also exhibit noticeable abnormal characteristics, primarily appearing as time anomalies or excessively long intervals between log entries.

[0141] The OpenStack dataset was collected with complete author labels, and the instance_id of the session with abnormal parameters was provided separately. This makes it easier to observe whether the corresponding model has detected anomalies and to locate the instance where the anomaly occurred.

[0142] In the OpenStack dataset, outliers differ significantly from normal data, making them easy to observe and convenient for evaluating model performance.

[0143] This article uses two types of log declaration times from logs with anomaly tags for detection: "Took 51.59 seconds to build instance" and "Took 50.72 seconds to spawn the instance on the hypervisor". Compared to normal logs, the abnormal logs show a significant deviation in declaration times. Normal logs have declaration times around 20 seconds, while abnormal logs have at least 30 seconds. This is related to the fact that the original log set author limited the network speed from the controller to the two different compute nodes to simulate potential performance anomalies caused by a DoS attack.

[0144] "Took<*>seconds to build instance": Figure 8 The first is the overall detection plot. The horizontal line represents the confidence interval thresholds corresponding to the Gaussian distribution of MSE; values ​​exceeding 98% and 99% are considered false positives. The X-axis represents the ID of the VM being created (i.e., different VM creation instances), and the y-axis represents the MSE between parameter value vectors and between the predicted output vector from the model. This can be seen from... Figure 8 The data shows two main peaks, with significant differences from the confidence interval. This aligns with two more obvious anomalies in the actual logs. Following these two peaks is a value exceeding the interval, corresponding to a value marked as an anomaly on an actual date but with a smaller time difference than the previous two.

[0145] Specifically, observe the abnormal peaks as follows: Figure 9 As can be seen, the anomaly exhibits a certain persistence along the x-axis. This is because this paper uses a time window of 3 to predict the next parameter value vector. The anomaly first appears in the sequence [x1,x2,x3]→[x4], where the MSE between x4 and the predicted value is too large, leading to an anomaly report. The next sequence, [x2,x3,x4]→[x5], includes the x4 anomaly, which will also affect the prediction performance of the entire sequence, causing the MSE between the predicted and actual values ​​to exceed the range, thus generating an error. Therefore, this paper considers only the first occurrence of an anomaly sequence value within a short period to be a true error, but... Figure 9 The log parameter sequence after adding one to the time window will trigger an alarm.

[0146] Based on actual error reports Figure 10 As you can see, the corresponding anomaly sequence is printed out. We can see that the first anomaly occurs in log number 129. The subsequent anomalies 130 and 132 are considered to be caused by the inclusion of the outlier value from 129 in the input sequence. Verifying the location of the anomaly itself reveals that position 129 is indeed a value significantly exceeding the confidence interval, and position 130 is also a genuine anomaly. The alarm at position 132 is caused by the presence of two outliers in the sequence [[42.810.0][30.32 0.0][20.69 0.0]], leading to a deviation of the predicted vector from the normal vector. In practical applications, this problem does not occur because, to prevent affecting subsequent parameter anomaly detection, this paper replaces the anomaly parameter value sequence with the average value sequence, i.e., the normal sequence. This avoids the problem of the anomaly parameter sequence affecting subsequent sequences, ensuring that each alarm is a genuine anomaly.

[0147] like Figure 10 Subsequent sequences show that the parameters at positions 179 and 184 are genuine anomaly parameters, significantly different from those at positions 182 and 183, with position 182 being a false positive. The number of anomalies also matches the number of anomaly instance labels in the dataset.

[0148] "Took<*>.<*>seconds to<*>the<*>the hypervisor.": from Figure 11 As can be seen, there are two main peaks, and when magnified, they appear as follows: Figure 12 Verify the detection results. It can be seen that there are more peaks exceeding the confidence interval compared to the previous type of log, and correspondingly, more abnormal parameter statements are printed.

[0149] Simultaneous alarm message Figure 13 In (a), 129 and 130 are true anomalies, with values ​​significantly deviating from the normal range, such as... Figure 13 (b) The anomalous instances are the same as those in the previous type of log flags. Furthermore, values ​​exceeding the confidence interval are successfully detected at positions 179 and 184, which are also very obvious parameter anomalies, such as... Figure 13 (c)

[0150] It should be noted that embodiments of the present invention can be implemented in hardware, software, or a combination of both. The hardware portion can be implemented using dedicated logic; the software portion can be stored in memory and executed by a suitable instruction execution system, such as a microprocessor or dedicated-design hardware. Those skilled in the art will understand that the above-described devices and methods can be implemented using computer-executable instructions and / or included in processor control code, for example, such code provided on a carrier medium such as a disk, CD, or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The devices and modules of the present invention can be implemented by hardware circuitry such as very large-scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field-programmable gate arrays, programmable logic devices, etc., or by software executed by various types of processors, or by a combination of the above-described hardware circuitry and software, such as firmware.

[0151] The loss function used is cross-entropy loss, and the optimizer is Adam, which currently boasts relatively good performance. Softmax activation is used at the output of fully connected layers; this function is commonly used in classification problems to convert the model output into probabilities for each location. The overall model structure is as follows: Figure 14 As shown.

[0152] First, this paper trains the model and adjusts the hyperparameters on the HDFS dataset, using the controlled variable method.

[0153] from Figure 15 The results analysis shows that as the h value increases, accuracy improves while recall decreases, and the F-measure remains largely unchanged. A hidden layer value of 2 provides the most balanced performance across the three values. Increasing the number of hidden layers may lead to overfitting, so a hidden layer value of 2 is used. Increasing `hidden_size` (i.e., increasing the number of neurons per hidden layer) shows no significant change starting from 64, with a weak upward trend. Furthermore, increasing any of the parameters except for `g` increases the complexity of the training model, training cycle, and CPU overhead. In conclusion, on the HDFS and OpenStack log datasets, selecting h=10, num_layers=2, and hidden_size=64 as baseline parameters yields good performance.

[0154] Model performance evaluation

[0155] from Figure 16 As can be seen, when the number of epochs reaches 300, the training loss has reached a relatively low level, and continuing to add epochs cannot significantly reduce it. At the same time, the training speed of epochs also incurs time losses. Therefore, this paper chooses 300 epochs.

[0156] Figure 17 as well as Figure 18 The results of the path anomaly detection model on HDFS and OpenStack datasets show that on HDFS, the model achieves 96% accuracy, 94.2% recall, and 95% F-measure, demonstrating good performance. On the OpenStack log dataset, it achieves 98% accuracy, 100% recall, and 99% F-measure, showing even better performance than the HDFS log dataset. This is because OpenStack logs are generated more regularly, starting with instance and VM lifecycle events and ending with VM deletion. Furthermore, since API node communication logs lack instance IDs, they cannot be categorized into log key sequences. This further reduces the number of log key types, simplifying the classification problem. The generated log key sequences are simpler, resulting in superior performance. This is also one of the reasons for choosing the OpenStack log dataset; its regular log format and relatively simple parsed sequences make it easier to parse.

[0157] The specific training data for the overall log is shown in Table 5-4. It can be seen that the HDFS dataset is larger than the OpenStack dataset, but the overall training set accounts for a smaller proportion of the total dataset.

[0158] Table 5-4 Number of Log Sets

[0159]

[0160] However, the same parameters have been modified for Linux in this paper. Because Linux process logs, such as ftpd logs, are all the same FTP communication logs with identical log types, while ssh process logs, in addition to identical connection logs, also show pairs of logs such as "search user check pass," "user unknown," and "authentication failure." Therefore, considering the influence of the patterns in Linux log sets, this paper uses a time window h=3 when testing the Linux dataset, and the corresponding g value is also modified to 3.

[0161] Model performance comparison

[0162] Since there are already some mature methods for log anomaly detection in academia, this paper collects the accuracy and recall of these methods on the same two datasets for comparison. This is to verify the superior performance of the model presented in this paper.

[0163] First, the evaluation metrics for each method on the HDFS dataset are shown in Table 5-5. It can be seen that PCA performs best in accuracy on the HDFS dataset, but its recall is insufficient, indicating a high number of false positives for normal log key sequences. High false positive rates are unacceptable in applications. In terms of accuracy, this method is the highest except for PCA. Considering both recall and F-measure, the proposed method is the best overall, making it the optimal solution for HDFS.

[0164] Table 5-5 HDFS Results Comparison Table

[0165]

[0166] Next, Table 5-6 shows the evaluation metrics for each method on the OpenStack dataset. It can be seen that PCA still achieves good accuracy on OpenStack, but its recall and F-measure are extremely low. This is because the normal patterns in the dataset are too regular, preventing PCA from using variance to detect anomalies. Among the remaining methods, the method presented in this paper still has the highest recall and F-measure, meaning it has the best performance.

[0167] Table 5-6 OpenStack Results Comparison Table

[0168]

[0169] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any modifications, equivalent substitutions, and improvements made by those skilled in the art within the scope of the technology disclosed in the present invention, and within the spirit and principles of the present invention, should be covered within the scope of protection of the present invention.< / content> < / component> < / level> < / pid> < / time> < / date>

Claims

1. A log auditing method for CNC systems based on LSTM, characterized in that, The LSTM-based CNC system log auditing method includes: Using a new log parsing tool improved from the log parsing tool Drain, three types of log-specific parsers are reconstructed to parse logs into template statements and variables; and log template statements are converted into log keys accordingly. Log pattern recognition is performed using a bidirectional long short-term memory model: time-series-based anomaly detection is achieved by predicting log keys within a certain window size and calculating the Gaussian error of the log occurrences. The LSTM-based CNC system log auditing method includes the following steps: Step 1: Use the fixed-depth parse tree in the self-developed tool ReDrain to parse the logs and separate the log template statements and log parameters. Step 2: Using a pre-defined log template dictionary, the log template statements are converted into log keys, which are the corresponding numbers. The log keys are classified into different sessions with different session flags to obtain a time-series-based log key sequence in the same session. Log variables are divided into different log types. Variables of the same log are input into the same parameter anomaly detection model to obtain feature selection data. Step 3: Construct and train the execution path anomaly detection model. Use Keras to build a two-layer Bi-LSTM neural network to train the log keys parsed from normal mode logs. Use the trained execution path anomaly detection model to detect log keys that are a mixture of normal and abnormal modes, and output the execution path anomaly detection results. Step 4: Build and train a parameter anomaly detection model, and use the trained parameter anomaly detection model to detect whether there are any anomalies in the system's key records in the log parameter values; Step 5: After backpropagating the incorrectly predicted samples, update the parameters and refit and train the model using the fit function of the Keras framework. After training, updating and adjusting the weights, the network can successfully identify normal log key sequences. The self-developed tool ReDrain uses a fixed-depth parse tree and an improved parse tree to parse logs, obtaining log template statements and log parameters, including: First, based on prior knowledge of each logging framework, some expressions are defined to parse the log variables [r'(\d+\.){3}\d+']; Secondly, log message length grouping is performed; the first flag is used for searching: the search is based on the first flag being a constant, and <*> is used to represent it when the first flag is a variable; a maxchild parameter is set to constrain the maximum child node tree of a node; Finally, the search continues based on the similarity of the markers. When the simSeq with the largest similarity to the input log is obtained in the parse tree, it is compared with the similarity threshold st passed in the tool. If it is greater than the threshold, it is a suitable log group. If the marker of the input log is the same as the marker at the same position in the subtree, no update is performed. If the marker of the input log is different from the marker at the same position in the subtree, the different markers in the subtree are replaced with <*>. If no match is found, a new subtree and a new log group are created. The construction and training of the execution path anomaly detection model includes: (1) The execution path anomaly detection model is constructed as follows: The input layer is used to input a sequence of log keys w, where w = {x}, representing the size of the sliding window. t-h ,…,x t-2 ,x t-1 In the context of log keys, x represents a log key obtained from parsing real logs, belonging to the unique log key set X; x t Indicates the next log key; The output layer uses a softmax function for multi-class classification to transform the output of the last hidden layer into a probability distribution function, representing the probability matrix Pr(x). t =k i |x t-h ,…,x t-2 ,x t-1 The probability matrix Pr(x) t =k i ) is used to represent the probability distribution of all log keys from X; the probability distribution of all log keys from X represents the probability that the next log key belongs to any class of log keys; (2) Training the execution path anomaly detection model includes: extracting a small number of segments from the log set under normal conditions in the target system as the training set; and using the training execution path anomaly detection model. The method of using a trained parameter anomaly detection model to detect whether there are anomalies in key system records in log parameter values ​​includes: The mean square error (MSE) between the predicted and actual values ​​is calculated using a parametric anomaly detection model. The MSE calculation formula is as follows: ； Where, x t Represents the true value, x p This represents the predicted value, and n represents the average value. Choose to use the calculation function of the stats module in scipy as the confidence interval of MSE; if the error is within the high confidence interval of MSE, the corresponding log is normal; otherwise, the log is considered abnormal.

2. The LSTM-based CNC system log auditing method as described in claim 1, characterized in that, The log message length is the number of separated flags in the log statement; maxchild is greater than 3; The search continues based on the similarity of the markers as follows: ； Where seq1 represents the preprocessed log input at this point, seq2 represents the log template represented by the log group represented by the subtree in the tree; I represents the i-th flag in the input sequence; N represents the sequence length, equ as follows: 。 3. The LSTM-based CNC system log auditing method as described in claim 1, characterized in that, The feature vectorization processing of log template statements and log parameters using different methods includes: (1) For log keys: use template statements to perform statistics, and use the sorted number after the template statement statistics as the code of the log key; or, directly perform feature processing on the log key through statistics; the log key is the log template statement; (2) Log parameters: The obtained parameter list is preprocessed to remove flag parameters, punctuation marks, special characters and other information that cannot be used as a standard for judging parameter anomalies; the remaining parameter characters are arranged into a two-dimensional matrix, and each x on the x-axis represents a parameter of a log; the text.Tokenizer module under the Keras framework is used to count the text and convert it into a dictionary to obtain the text word frequency information within the parameter value; the built-in function is used to convert all the text in the matrix into numbers.

4. The LSTM-based CNC system log auditing method as described in claim 1, characterized in that, The step of using a trained execution path anomaly detection model to detect whether the target log key is normal, and obtaining the log template statement anomaly detection results, includes: The first h parsed log keys are sent to the execution path anomaly detection model to obtain multiple log keys; the first g log keys are retained, and it is determined whether the target log key is among the retained log keys. If it is, the target log key is determined to be normal; otherwise, the target log key is abnormal. The exception of the target log key indicates that an error has occurred at the program location represented by the log statement of the exception log key.

5. The LSTM-based CNC system log auditing method as described in claim 1, characterized in that, The constructed and trained parameter anomaly detection model includes: The parameter anomaly detection model is as follows: The input layer is used to input the parameter value vector in the timestamp of the log; The output layer is used to output a parameter prediction vector corresponding to the dimension of the input vector based on the sequence of parameter value vectors in the most recent historical records, as a prediction for the next parameter value vector; The training parameter anomaly detection model includes: normalizing the values ​​in each vector by using the average and standard deviation of all values ​​at the same parameter position in the training data, setting the MSE function as the loss function, and training the parameter anomaly detection model using a normal dataset.

6. An information data processing terminal, characterized in that, The information data processing terminal is used to execute the steps of the LSTM-based CNC system log auditing method according to any one of claims 1-5.

Images