Log detection method, log alarm method, system, device and storage medium

Abstract

The application provides a log detection method, a log alarm method, a system, a device and a storage medium, and belongs to the technical field of data processing. The method comprises the following steps: acquiring log data, and starting a first time window; determining a set of marked values in the first time window, wherein the marked values in the set of marked values are determined by the number of occurrences of a configured log template, and the number of occurrences is the number of occurrences of a matching success state between the configured log template and the acquired log data in the first time window; determining an alarm log template from the log template in which the matching success state occurs, and generating alarm information based on the alarm log template; and sending the alarm information to an alarm center, so that the alarm center determines root cause alarm information of a call link based on alarm information in a second time window. The application can be used to guarantee the continuous availability of user services.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and specifically to a log detection method, a log alarm method, a log processing system, an electronic device, and a machine-readable storage medium. Background Technology

[0002] Applications such as middleware between application services can be deployed on mobile electronic devices, microservice architecture platforms, cloud service platforms, server clusters, etc. They can be used to provide users with communication services, product services, transaction services, and sensor acquisition and data processing services, and generate log data. By analyzing the log data, security threats, program vulnerabilities, service interruptions and other program problems can be discovered and handled. This can provide a foundation for the availability, reliability and data security of application services, which is also particularly important for providing continuously available user services.

[0003] With the explosive growth of user transactions, sensor activity, and machine behavior, log analysis of massive amounts of log data to find program problems within limited time and cost is extremely difficult. Furthermore, applications often do not exist in isolation but rather provide user services in conjunction with other applications in the call chain. When program problems occur, all applications in the call chain still generate log data or issue abnormal alarms, making it difficult to pinpoint the root cause of the problem or the alarm message. Consequently, it becomes difficult to resolve program problems promptly and provide continuously available user services. Summary of the Invention

[0004] The purpose of this invention is to provide a log detection method, log alarm method, system, device, and storage medium to avoid the difficulty in locating alarm information in the call chain and discovering the application and alarm information that caused the problem, which is caused by analyzing the logs of individual applications in user services. This provides log detection and alarm assurance for continuously available user services.

[0005] To achieve the above objectives, this specification adopts the following approach:

[0006] In a first aspect, embodiments of the present invention provide a log detection method applied to a stream processing engine, the log detection method comprising:

[0007] Obtain log data and open a first-time window, wherein the log data includes log data of applications in the call chain;

[0008] A set of marker values ​​is determined within the first time window. The marker values ​​in the set are determined by the number of times the configured log template appears. The number of times the configured log template and the acquired log data are successfully matched within the first time window.

[0009] From the log templates that show a successful match, determine the alarm log template, and generate alarm information using the alarm log template. The tag value corresponding to the alarm log template belongs to the numerical range configured in the alarm log template.

[0010] The alarm information is sent to the alarm center so that the alarm center can determine the root cause alarm information of the call chain based on the alarm information within the second time window.

[0011] Secondly, embodiments of the present invention provide a log alarm method applied to an alarm center, the log alarm method comprising:

[0012] Receive alarm information sent by the stream processing engine within the second time window;

[0013] Determine the similarity between the configured alarm template and the received alarm information, and perform similarity matching to determine the key alarm template corresponding to the second time window from the alarm templates that have a successful matching status;

[0014] Determine the call chain corresponding to the application identifier, which is extracted from the alarm information that successfully matches the key alarm template;

[0015] Based on the call relationship between applications in the call chain, the root cause alarm information is determined from the alarm information within the second time window, and the log alarm is executed.

[0016] Thirdly, embodiments of the present invention provide a log alarm processing system, which includes:

[0017] The acquisition module is used to acquire log data and open a first time window. The log data includes log data of applications in the call chain.

[0018] The tagging module is used to determine the tagging value set within the first time window. The tagging values ​​in the tagging value set are determined by the number of times the configured log template appears. The number of times the configured log template and the acquired log data are successfully matched within the first time window.

[0019] The determination module is used to determine the alarm log template from the log templates that have a successful matching status, and generate alarm information based on the alarm log template. The flag value corresponding to the alarm log template belongs to the numerical range configured in the alarm log template.

[0020] The sending module is used to send the alarm information to the alarm center, so that the alarm center can determine the root cause alarm information of the call link based on the alarm information within the second time window.

[0021] Fourthly, embodiments of the present invention provide an electronic device, the electronic device comprising:

[0022] At least one processor;

[0023] A memory connected to the at least one processor;

[0024] The memory stores instructions that can be executed by the at least one processor, and the at least one processor implements the aforementioned method by executing the instructions stored in the memory.

[0025] Fifthly, embodiments of the present invention provide a machine-readable storage medium storing machine instructions that, when executed on a machine, cause the machine to perform the aforementioned method.

[0026] In this invention, log data from applications in the call chain is obtained through a stream processing engine. Template matching between the log data and log templates is performed within the first open time window. A marker value is determined by the number of times a successful match occurs. Among log templates with successful matches, each marker value reflects the impact of the application causing the program problem on program calls in the call chain. It also reflects the degree of matching between alarm information and log templates for each application (the more successful matches, the higher the degree of matching). By utilizing the density of log occurrences and the relative temporal distribution of successful match occurrences, the application most severely affected by the program problem is identified. A marker value within a certain range indicates that the degree of matching between the alarm information and log templates for that application is higher than that for other applications. Finally, the stream processing engine can send alarm information from applications severely affected by program problems (the alarm information between applications in the call chain is the most prominent feature) to the alarm center. This allows the alarm to combine the alarm information of each application appearing in the call chain and the second time window to determine the root cause alarm message (and the application from which the problem originates), instead of performing log analysis on alarm information of individual applications or sending alarm information of individual applications.

[0027] In this invention, the alarm center receives the aforementioned alarm information within the second time window, finds the alarm information most similar to the alarm template, finds the key alarm template and alarm information corresponding to the second time window, and thus determines the alarm information similar to the alarm template among the alarm information of severely affected applications in the second time window. By utilizing alarm information similar to alarm templates and combining it with the call chain, the alarm information of the application that actually caused the program problem can be found, i.e., the root cause alarm information. Finding the application that generates alarm information similar to the alarm template only indicates that it is likely to be affected by program problems and has easily detectable log anomalies among applications in the call chain; it is not necessarily the actual source of the program problem. However, it can identify the call chain in which the problem originates. By combining this with the call relationships between applications within the call chain, the actual source of the program problem can be found. This avoids the situation where the log data issued by the actual source of the program problem, relative to other applications in the call chain within a time window, exhibits characteristics that are difficult to detect, identify, or statistically analyze, making it difficult to determine the root cause alarm information. Therefore, log analysis of applications in the call chain and determination of root cause alarm information can be achieved, allowing for timely resolution of program problems and providing continuously available user services.

[0028] For example, the application identifier extracted from the alarm information corresponding to the key alarm template is microservice 2 (client application). The call chain of microservice 2 is that microservice 2 acts as a message consumer for the middleware service, and the message producer of the middleware service is microservice 1 (server application). Microservice 1 (low information density in log data) is not detected by the stream processing engine as a severely affected application, and the alarm information sent to the alarm center is the alarm information of microservice 2 (e.g., the log data contains a large number of server data timeouts). If the key alarm template determined by the alarm center at this time is an alarm template similar to the alarm information of microservice 2, and combined with the call relationship in the call chain of microservice 2, the existing alarm information (which may include alarm information of microservice 1, microservice 2, and middleware service) can be queried. Then, it can be determined that the alarm information of microservice 1 is the root cause alarm information. For example, if the problem with microservice 1 is insufficient bandwidth resources on the server node, the alarm center can instruct the service resource management system in the production environment to replace the online redundant server node. It can also instruct the service resource management system in the production environment to execute the microservice mirrored on the online redundant server node, thereby providing continuous availability assurance for user services.

[0029] Other features and advantages of the embodiments of the present invention will be described in detail in the following detailed description section. Attached Figure Description

[0030] The accompanying drawings are provided to further illustrate embodiments of the present invention and form part of the specification. They are used together with the following detailed description to explain the embodiments of the present invention, but do not constitute a limitation thereof. In the drawings:

[0031] Figure 1 This is a schematic diagram of the main method steps for log detection in an embodiment of the present invention;

[0032] Figure 2 This is a schematic diagram of an exemplary log processing flow according to an embodiment of the present invention;

[0033] Figure 3 This is an exemplary log detection scenario applied to a stream processing engine according to an embodiment of the present invention;

[0034] Figure 4 This is a schematic diagram of the main method steps for log alarms in an embodiment of the present invention;

[0035] Figure 5 This is a schematic diagram of an exemplary log alarm scenario applied to an alarm center according to an embodiment of the present invention;

[0036] Figure 6 This is a schematic diagram of an exemplary electronic device module according to an embodiment of the present invention. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of this specification clearer, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustrative and explanatory purposes only and are not intended to limit the scope of the present invention.

[0038] As mentioned earlier, anomaly detection strategies are typically used for log data generated by individual applications. These strategies examine the log data and identify the application that detects anomalies as the source of the problem. However, for applications within a call chain (such as cloud platforms, microservices, and middleware within server clusters, which are numerous and have complex call relationships), in some implementations, the dependencies and interactions between data objects and program methods between applications can lead to anomalies being detected not only by the application causing the problem but also by other applications in the same call chain. In such cases, using anomaly detection strategies that examine the log data of individual applications will struggle to determine the specific call chain causing the problem, as well as the originating application and root cause information. In other implementations, the application causing the problem may not report abnormal log data (undefined program problems, hidden security attack program problems, etc.), and other applications in the same call chain may also fail to report abnormal log data. In these situations, anomaly detection strategies may be ineffective.

[0039] Therefore, this specification provides a log detection scheme. When log data of an application in a call chain is obtained, a first time window can be triggered. Within the first time window, a log template can be matched with the log data template, and the number of times each log template successfully matches within the first time window is determined. A set of marker values ​​is obtained based on the number of occurrences. The magnitude of the marker values ​​measures the degree of matching between the log data and the log template (a high degree of matching means a relatively large number of successful matches, not necessarily high similarity after a single match). Then, relative to the application affected by the program problem, an alarm log template is determined. The alarm information generated by the alarm log template reflects the log data characteristics of the application severely affected by the program problem. This information, along with the call chain information of the application, is transmitted to the alarm center, enabling the alarm center to determine the root cause alarm information of the call chain based on the alarm information within a second time window. It should be understood that the method provided in this specification can be executed by a device with computing and instruction processing capabilities, such as a server or electronic device.

[0040] In the first aspect, please refer to Figure 1 This invention provides a log detection method that can be applied to stream processing engines. The log detection method may include:

[0041] S1) The stream processing engine can acquire log data and open a first time window, the log data including log data of applications in the call chain.

[0042] In this embodiment of the invention, the stream processing engine (or stream computing engine) can be a physical server, a server instance, or a container instance. The hardware of the instance can be a resource instance in a server cluster, consisting of processor resources and memory resources, and possessing computing and instruction processing capabilities. The resource instance is, for example, a cloud server. The stream processing engine is deployed with scripts and / or programs. When executing the scripts and / or programs, the stream processing engine can implement the aforementioned log detection method. The stream processing engine can provide log data computing and processing capabilities for user services (applications such as microservices and middleware services). For example, the stream processing engine can be delivered as a standalone data processing device product and can connect to servers in a production environment that support user services and / or log data collection, as well as to servers in that production environment used for information alarms. The stream processing engine can also be delivered as a data processing device product together with an alarm center, and can connect to servers in a production environment that support user services and / or log data collection. For example, the data processing device product can be a file server or a monitoring server / industrial control computer, etc.

[0043] In some possible implementations, log data may include timestamps, application identifiers, log files, etc. Timestamps can be used to indicate whether a first time window is open (if not already open) or to determine whether the acquired log data is within the end time of the first time window (if already open). Application identifiers may include application name, application network identifier, version identifier, etc. Log files may include log files for normal data processing information and log files for abnormal data processing information. Log files for normal data processing information may include a no-exception level identifier and no-exception data processing status information. For example, the no-exception level identifier could be a notification level identifier [INFO] or a debug level identifier [DEBUG]. The no-exception data processing status information could be completion status information for data operations (e.g., data could be image files, audio files, messages, database table data, etc.) (e.g., sending requests, receiving verification, copying, encoding / decoding, compression / decompression, etc., program stack traces), and may also include information about the call chain and (optionally) call relationships, dependencies, callback functions, and calling methods used for this data operation. Log files for abnormal data handling information can include an exception level identifier and abnormal data handling status information. For example, the exception level identifier could be a warning identifier [WARN], an error identifier [ERROR], or a severe error identifier [FATAL]. The abnormal data handling status information could be communication failure status information (e.g., inability to connect to the middleware service), data operation failure status information (e.g., message sending failure, data call failure, etc., program stack traces), and may also include information about the call chain used for this data operation, as well as (optionally) call relationships, dependencies, callback functions, and calling methods. In some possible programming language applications, a probe service can be used to report information representing the current application's call chain (URL) based on request information from microservices and middleware services.

[0044] In some possible implementations, the first time window can be a sliding time window. The sliding time window is a reference time window used for statistical functions such as data grouping and counting. The sliding time window can have a fixed time length and a specified sliding interval. For example, the sliding interval of a 10-second sliding time window can be specified as 5 seconds. The initial start time of the sliding time window can be the moment when the log data is obtained, and the end time is limited by a fixed time length. Statistical functions can be implemented within each sliding interval.

[0045] In this embodiment of the invention, to reduce the impact on applications such as microservices and middleware services already deployed in the production environment, a probe service can be deployed to the application's production environment, and a log classification service can be deployed to the application's production environment to obtain log data that can be acquired by the stream processing engine. The aforementioned step S1) may include:

[0046] S101) The stream processing engine can communicate with the middleware service. The stream processing engine can read log data stored by the middleware service and consume log data written by the log classification service within a topic in the middleware service; wherein...

[0047] The log classification service is used to classify logs based on log data collected by the probe service and a specified program identifier field;

[0048] The probe service is used to collect log data from the application in the call chain.

[0049] In some possible implementations, the middleware service in step S101) can be the same as the middleware service in the production environment (e.g., including a message middleware service) or deployed separately. The middleware service in step S101) can be a message middleware service, such as the Kafka message middleware service.

[0050] In step S101), please refer to Figure 2 The probe service can be a constructed script / program or a probe tool deployed (on a PaaS cloud platform). It can be configured with data items that constitute log data (timestamp, application identifier, log file) and can be used to collect log data between microservices and middleware services. In some possible applications, within the Java language, the probe service can report information representing the current call chain of the application based on request information from microservices and middleware services, and use constructed methods or probe tools to trace application operations and print program stack information. The probe service can write the collected log data into a specified probe service topic in the Kafka message middleware service to produce topic data. The probe service topic can be subscribed to by the log classification service. After log data is written to the probe service topic, the Kafka message middleware service can notify the log classification service, which, upon receiving the notification, can read the log data from the probe service topic to consume the topic data.

[0051] In step S101), the log classification service can be a deployed parsing service. This service can be configured to classify logs based on the application identifier and a specified application identifier field (e.g., microservice name) in the log data. In some possible applications, a parsing service with regular expression rules can be used to identify characters representing the application identifier in the log data. Using these identified characters, a user service business classification table can be queried to determine the business classification of the log data. The log data is then written to a topic in the Kafka message middleware service under that business classification. Log data from the same business classification can all be written to topics within the same Kafka message middleware service. The business classifications can include payment business classification 1, social messaging business classification 2, and product service business classification 3, etc. Each business classification can correspond one-to-one with a topic in the Kafka message middleware service; for example, payment business classification 1 corresponds to Kafka Topic 1, social messaging business classification 2 corresponds to Kafka Topic 2, and product service business classification 3 corresponds to Kafka Topic 3.

[0052] In step S101), the stream processing engine can subscribe to various KafkaTopics in the Kafka message middleware service. After receiving a notification from the Kafka message middleware service, the stream processing engine responds to the instructions in the notification and can read log data within the topic. At this time, the log data can be categorized, which facilitates template matching using log templates under the current business category, reducing the number of log templates that need to be matched. Simultaneously, after receiving the categorized log data, the stream processing engine can trigger the opening of a first time window. Categorized log data helps increase the processing efficiency of log data within the first time window. Simultaneously with opening the first time window, a specified cache space can be initialized in the stream processing engine. This cache space can be a specified memory storage address range within the stream processing engine. In this embodiment of the invention, the log template may include text describing program problems and application parameters corresponding to the program problems. Program problems can be labeled and defined based on user service testing and debugging under business categories, such as software update failure (parameter update UPDATE), call failure (parameter class file name / microservice name, such as the database driver class file name of the application calling the database, and the database service name of the database), connection failure (parameter microservice name), etc. The log template may also include text describing hidden security attack behavior and application parameters corresponding to the attack, such as the frequency of sending and receiving normal log text being higher than the frequency threshold (at this time, the log level identifier can be [INFO], [DEBUG], parameter frequency), the duration of calling the specified microservice at equal intervals being higher than the duration threshold (parameter duration), etc.

[0053] In this embodiment of the invention, before determining the set of marker values ​​within the first time window, the aforementioned log detection method may further include:

[0054] A1) The stream processing engine can determine the log level in the acquired log data and filter the acquired log data to retain log data with the specified log level;

[0055] A2) The stream processing engine can segment the retained log data and group log data with the same number of segments into a log group.

[0056] In some possible implementations, the stream processing engine can use a parsing service with regular expression parsing rules to parse log levels in the log data (keyword identification) and filter log data based on log levels. In some applications, it can be specified that log data carrying error level identifiers [ERROR] and severe error level identifiers [FATAL] be retained, while log data carrying other log level identifiers, such as warning level identifiers [WARN], notification level identifiers [INFO], and debug level identifiers [DEBUG], be deleted. Then, the stream processing engine can use a tokenizer (by calling / configuring) to segment the log data carrying error level identifiers [ERROR] and severe error level identifiers [FATAL], determine the number of segments, and group log data with the same number of segments together, storing them separately in the aforementioned cache space according to the log group. In other possible applications, in order to discover potential hidden security attacks against user services and to discover potential undefined program problems in user services, it is possible to specify the retention of log data carrying error level indicators [ERROR] and critical error level indicators [FATAL], as well as warning level indicators [WARN], notification level indicators [INFO], and debug level indicators [DEBUG].

[0057] In this embodiment of the invention, template matching can be performed based on similarity. Before determining the set of labeled values ​​within the first time window, the aforementioned log detection method may further include:

[0058] B1) The stream processing engine can determine the similarity between the configured log template and the acquired log data;

[0059] B2) The stream processing engine can perform similarity matching to determine whether each log template has a successful matching state; wherein, if there is an i-th log template whose similarity to the acquired log data is higher than the similarity threshold, then the i-th log template is determined to have a successful matching state, and the number of times the i-th log template has a successful matching state is recorded, where i is a positive integer.

[0060] In some possible implementations, in step B1), the stream processing engine can obtain log data from the aforementioned cache space. This log data can be obtained after step S1) or step S101). To increase the processing efficiency of log data and the accuracy of template matching, the obtained log data can also be the log data after processing in step A1) or step A2). In some possible applications, the stream processing engine can call / configure a word vector conversion service, such as a conversion service implemented with conversion algorithms like Word2vec or FastText, which can convert the text in the log files corresponding to each microservice or middleware service into numerical vectors (i.e., word vectors). The aforementioned step B1) may include:

[0061] B101) The stream processing engine can convert the configured log template and the acquired log data into numerical vectors respectively. The numerical vector of the configured log template can be obtained in advance before step B1), which can reduce the real-time computing pressure and increase processing efficiency.

[0062] The B102 stream processing engine can calculate the similarity between the numerical vectors.

[0063] In some applications, the stream processing engine can determine the similarity between numerical vectors based on the distance between them. In other potential applications, the stream processing engine can call / configure natural language processing models such as LSTM and BERT to perform semantic parsing on log data, obtain word vectors, and calculate similarity based on Manhattan distance. This allows the engine to determine the similarity between the acquired log data and various log templates.

[0064] In step B2), the log template may also include a unique identifier for the template. The stream processing engine can record the number of occurrences corresponding to the unique identifier. If the similarity between the i-th log template and the obtained log data is higher than the similarity threshold, it can be considered that the program problem of the microservice or middleware service in the obtained log data is similar to the i-th log template. That is, the i-th log template and the obtained log data are in a successful matching state. Each time a successful matching state occurs, the occurrence count record corresponding to the unique identifier of the i-th log template can be increased by 1.

[0065] In this embodiment of the invention, it is adaptable to various user service types, and the probe service is configured to record log data as a character-parseable text structure during collection, and template matching can also be performed based on the same number of characters. Before determining the set of marker values ​​within the first time window, the aforementioned log detection method may further include:

[0066] B1') The stream processing engine can use a parsing service with regular expression parsing rules to determine the characters in the text of the log file in the acquired log data, such as characters associated with program operations like registration, start sending, connection failure, call error, and heartbeat recording;

[0067] The B2') stream processing engine can perform matching of the same number of characters to determine whether each log template has a successful match. Specifically, if the number of characters that the i-th log template has in common with the text in the log file in the log data is higher than the configured character count threshold, then the i-th log template is determined to have a successful match, and the number of times the i-th log template has a successful match is recorded. The log file can be a key-value text file (e.g., key-value pairs in a .json file), which is beneficial to the execution efficiency of template matching.

[0068] In this embodiment of the invention, after the number of occurrences of the configured log template is determined, the aforementioned log detection method may further include:

[0069] S2) The stream processing engine can determine the set of marker values ​​within the first time window. The marker values ​​in the set are determined by the number of times the configured log template appears. The number of times the configured log template and the acquired log data are successfully matched within the first time window.

[0070] In some possible implementations, a set of flag values ​​can be initialized to count the occurrences of successful matching statuses for each log template. The flag values ​​in the set can correspond one-to-one with the log templates; the flag values ​​can be the number of occurrences or mappings of those occurrences. In some possible applications, step S2) may include any of the following:

[0071] The S201 stream processing engine can calculate numerical values ​​(percentage values) based on linear relationships, and these calculated values ​​can be used as marker values ​​for log templates.

[0072] S202) The stream processing engine can calculate the frequency of occurrence based on the number of times the current (i) log template appears in each sliding interval, and use the minimum and maximum frequency of occurrence in all sliding intervals as the marker value of the current log template in the first time window.

[0073] The S203 stream processing engine can calculate the total number of occurrences of each log template across all sliding intervals, and use this total number of occurrences as the marker value for each log template within the first time window. Understandably, the method for calculating the marker value can be selected and designed based on statistical requirements and the effectiveness of its use in a production environment.

[0074] In this embodiment of the invention, after template matching is completed, the tag values ​​of each log template can be compared within a first time window. The aforementioned log detection method may further include:

[0075] S3) The stream processing engine can determine an alarm log template from log templates that show a successful match, and generate alarm information using the alarm log template. The tag value corresponding to the alarm log template belongs to the numerical range configured in the alarm log template. In some possible applications, the log template can also be configured with transmission parameters. These parameters can be used to replace log information such as log files, application identifiers, and call chains in the log data. The log template after replacing the transmission parameters will carry the log information of microservices in the log data, thus enabling the generated alarm information to include more semantic information related to program problems or attack behaviors. In other possible applications, the names, unique identifiers, and other application identifiers of microservices or middleware in the user service, as well as text describing (occurring) program problems or attack behaviors, can be annotated in the log template, which is more conducive to real-time processing efficiency. In this case, the data format of the alarm information can be provided by the alarm center, and the alarm information can be directly formed using the annotated information in the log template and encapsulated into a message that can be sent to the alarm center according to this data format.

[0076] In some possible implementations, the aforementioned log templates can be configured with a numerical range, which can be used to measure whether the magnitude of the marker value indicates a program problem or a hidden security attack. If the marker value is the total number of occurrences of each log template within the first time window, the numerical range can be higher than the lowest value of the total number of occurrences, and the aforementioned step S3) may include:

[0077] S301) When the total number of occurrences of a certain log template within the first time window is higher than the minimum value of the total number of occurrences (i.e., it falls within the value range configured in the alarm log template), the stream processing engine can determine that the certain log template is an alarm log template.

[0078] Furthermore, it can be determined that the call chain containing the application identifier in the alarm information corresponding to the alarm log template has a program problem or is being attacked by a hidden security attack. At this time, the microservice or middleware service with the application identifier in the alarm information corresponding to a certain log template is severely affected by the program problem or the hidden security attack. Thus, the alarm information generated by the alarm log template can locate the call chain with the program problem or the hidden security attack while identifying the microservice or middleware service severely affected by the program problem or the hidden security attack.

[0079] In some possible implementations, if a similarity score higher than a similarity threshold is considered a successful match, then step S3) may further include:

[0080] The S302 stream processing engine can compare the similarity between any two log templates in the log templates that have a successful matching status and the acquired log data, and iteratively determine the log template with the highest similarity. The log template with the highest similarity is the alarm log template.

[0081] Specifically, the similarity between the alarm log template and the acquired log data is greater than the similarity between any log template in the successfully matched log template state and the acquired log data. In step S302, a similarity comparison can be performed on a certain log template that was determined to be an alarm log template in step S301), so that when a certain log template is multiple log templates, the log template most similar to the acquired log data can be determined.

[0082] It should be noted that in some possible applications, if no matching log template is found, the stream processing engine can generate alarm information from the log files in the acquired log data according to the undefined template and send it to the alarm center. This allows the alarm center to send the information to the designated user device (computer, mobile electronic device, etc.), where the user can manually annotate it to define and form a new log template.

[0083] In this embodiment of the invention, after generating alarm information, the aforementioned log detection method may further include:

[0084] S4) The stream processing engine can send the alarm information to the alarm center so that the alarm center can determine the root cause alarm information of the call chain based on the alarm information in the second time window.

[0085] In some possible implementations, the stream processing engine can be configured with the interface information of the alarm center, and the alarm information can be sent as a message to the alarm center based on the interface information, so that the alarm center can determine the root cause of the alarm information.

[0086] In an exemplary log detection scenario for a stream processing engine disclosed in this embodiment of the invention, please refer to... Figure 3User services can include microservices Q1 to Q6 and middleware services K1 to K2. Microservice Q2 is a data retrieval service, while microservices Q1 and Q3 are database services. Middleware services K1 to K2 can be interface proxy node services, and microservices Q4 to Q6 are application services such as payment, image viewing, and music playback. There can be multiple call chains. For example, microservice Q2 calls middleware service K2, and middleware service K2 calls microservice Q3, denoted as call chain Q2→K2→Q3; microservice Q2 calls middleware service K1, and middleware service K1 calls microservice Q1, denoted as call chain Q2→K1→Q1; microservice Q6 calls middleware service K2, and middleware service K2 calls microservice Q3, denoted as call chain Q6→K2→Q3, and so on. If microservice Q3 has a program problem, such as a server node going offline, the log level identifier for microservice Q6 can be [FATAL], and the log level identifiers for middleware services K2 and microservice Q2 can be [ERROR]. The probe service can generate log data Log1, Log2, Log3, etc. The stream processing engine can write the log data classified and grouped by the log classification service into the cache space. When log data Log1 is written, a first time window Wa is opened. At this time, log data such as Log1, Log3, Log6, Log7, Log9, etc. can be written into the cache space. The sliding step of the first time window Wa is ST, and the sliding window size can be 3ST. The stream processing engine can call various log templates from the log template library. In the sliding window w0, log templates 1, 2, 3, etc. are matched with the log data (Log1, Log3, Log6) respectively to determine the similarity of each log template. For example, the similarity between log template 1 and log data (Log1, Log3, Log6) is p01, p02, p03 respectively, and the similarity between log template 2 and log data (Log1, Log3, Log6) is p04, p05, p06 respectively.

[0087] In this log detection scenario, sliding window w1 is the sliding window after sliding window w0. In sliding window w1, log templates 1, 2, 3, etc., are matched with log data (Log3, Log6, Log7) to determine the similarity of each log template. For example, the similarity between log template 1 and log data (Log3, Log6, Log7) is v01, v02, v03 respectively. The similarity p02 and p03 can be the same as or different from the similarity v01 and v02 (e.g., conversion, detection of fluctuations). However, if any similarity in any sliding window is higher than the similarity threshold, the label value of the log template can be increased by 1. For example, in sliding window w0, if the similarity p07 and p09 are higher than the similarity threshold, then log template 3 appears twice, and 2 can be added to the label value set sig. In sliding window w0, if the similarity p07 and p09 are higher than the similarity threshold, then log template 3 still appears twice, and 2 can still be added to the label value set sig. The stream processing engine can filter the tag values ​​of log templates to determine whether they fall within a numerical range, such as whether the total number of occurrences exceeds the configured threshold. Then, among the filtered log templates, it determines the maximum similarity of each log template in the first time window, compares the maximum similarity of each log template, determines the alarm log template sig_max (e.g., a log template describing an offline database service), generates alarm information, and sends the alarm information to the alarm center. After a period of time, the application identifier in the sent alarm messages may include the identifier of microservice Q6 (microservice Q6 is unavailable compared to other microservices, such as being unable to play music, and will send alarm messages intensively), as well as the identifiers of microservice Q2 and middleware service K2 (microservice Q2 and middleware service K2 are still available, and will send alarm messages sparsely). Microservice Q3, being offline (its state no longer changes), cannot have its log data collected. The probe service (which mainly collects data based on changes in program state) may send alarms once or a few times (within a time window) and then stop, or send alarms at equal intervals. The sent alarm messages may also include alarm messages with very low information density that contain the identifier of microservice Q3. However, the program problem of microservice Q3 seriously affects microservice Q6 in the call chain Q6→K2→Q3. The stream processing engine can use alarm messages containing the identifier of microservice Q6 to transmit the location information of the severely affected call chain to the alarm center.

[0088] Under the same inventive concept as the aforementioned solutions in this specification, this specification also provides a log alarm solution. This solution can determine the similarity between alarm information received within a second time window and alarm templates configured in the alarm center. Among alarm information from applications severely affected by program problems or hidden security attacks, it identifies key alarm information that successfully matches the template. Based on locating the call chain and the distribution of alarm information from applications along the call chain, it finds the root cause alarm information and executes log alarms for that root cause alarm information. This enables timely detection of program problems or hidden security attacks in user services, providing continuous and available user service assurance. Simultaneously, it provides alarm information compression, issuing only root cause alarm information, not all alarm information, and avoiding the frequent issuance of repetitive alarm information.

[0089] In the second aspect, please refer to Figure 4 This invention provides a log alarm method that can be applied to an alarm center. The log alarm method may include:

[0090] The L1 alarm center can receive alarm information sent by the stream processing engine within the second time window.

[0091] In this embodiment of the invention, the alarm center can be a physical server, a server instance, or a container instance. The hardware of the instance can be a resource instance in a server cluster, consisting of processor resources and memory resources, and possessing computing and instruction processing capabilities. The resource instance is, for example, a cloud server. The alarm center is deployed with scripts and / or programs, which, when executed, enable the aforementioned log alarm method. The alarm center can provide the computing and processing capabilities for alarm information sent by the stream processing engine. For example, the alarm center can be delivered as a standalone data processing device product and can connect to servers in a production environment that support sending user service alarm information, as well as to servers in that production environment used for resource management (which can be used to implement a resource management system, which can be instructed by the alarm center / manually to recover microservices or middleware services with program problems or attacks). The alarm center can also be delivered as a data processing device product along with a stream processing engine, and can connect to servers in a production environment that support user services and / or log data collection, as well as servers used for resource management. For example, the data processing device product can be a file server, a monitoring server, or an industrial control computer, etc.

[0092] In some possible implementations, the type of the second time window can be the same as the first time window, which can be a sliding time window. When the alarm center receives an alarm message sent by the stream processing engine, if the second time window has not been opened, the alarm message can trigger the alarm center to open the second time window. If the second time window has already been opened, the alarm message can be counted within the current sliding interval.

[0093] In this embodiment of the invention, the aforementioned log alarm method may further include:

[0094] L2) The alarm center can determine the similarity between the configured alarm template and the received alarm information, and perform similarity matching to determine the key alarm template corresponding to the second time window from the alarm templates that have a successful matching status.

[0095] In some possible implementations, the alarm template may include text describing the alarm message content and the alarm information as a message data format. The alarm template can be annotated and defined based on program debugging and testing of microservices or middleware services in the user service, forming alarm templates corresponding to each microservice or middleware service. The alarm template, along with the aforementioned log template, alarm messages, and log data, can all be converted into serialized text, and the serialized text can be converted into word vectors. The similarity matching performed in step L2) above may include:

[0096] L201) If there exists a similarity between the j-th alarm template and the received alarm information that is higher than the similarity threshold, then the alarm center can determine that the j-th alarm template has a successful matching status, where j is a positive integer.

[0097] Similarly, similarity can be calculated based on the distance between the word vector of the j-th alarm template and the word vector of the received alarm information. The step L2) described above, which involves determining the key alarm template corresponding to the second time window from the alarm templates that have achieved a successful match, may include:

[0098] The L202 alarm center can compare the similarity between any two alarm templates in the successfully matched alarm template list and the received alarm information, iteratively determining the alarm template with the highest similarity. This highest similarity alarm template is the key alarm template.

[0099] The similarity between a critical alarm template and a received alarm message is greater than the similarity between any alarm template in the successfully matched alarm template group and the received alarm message. Therefore, the alarm center can locate the alarm messages of critical applications (within the most severely affected call chains) by using the critical alarm template among alarm messages from severely affected applications.

[0100] In this embodiment of the invention, the aforementioned log alarm method may further include:

[0101] L3) The alarm center can determine the call chain corresponding to the application identifier, which is extracted from the alarm information that successfully matches the key alarm template.

[0102] In some possible implementations, the application identifier extracted from the alarm information that successfully matches the key alarm template will be regarded as being in a severely affected call chain. The alarm center can use the extracted application identifier to query the call chain monitoring tool to determine the specific call chain. For example, it can extract the microservice name / global identifier or middleware service name / global identifier and query the call chain in the monitoring tool Skywalking to locate the severely affected call chain.

[0103] In this embodiment of the invention, the aforementioned log alarm method may further include:

[0104] L4) The alarm center can determine the root cause alarm information from the alarm information in the second time window based on the call relationship between applications in the call chain, and execute log alarms.

[0105] In some possible implementations, the alarm center can determine the application identifier in the call chain, put it into an identifier set, and determine the root cause alarm information through the identifier set and call relationship. In some possible applications, the aforementioned step S4) may include:

[0106] L401) Extract the application identifier and the name of microservice M1 from the alarm information within the second time window;

[0107] L402) The extracted application identifiers are used as the application identifier set. It is determined that there are application identifiers in the application identifier set that are different from the application identifiers (the names of microservice M2 and microservice M3, and the calling relationship is that microservice M2 calls microservice M1 (the call chain position of microservice M1 is before the call chain position of microservice M2), and microservice M1 calls microservice M3 (the call chain position of microservice M3 is before the call chain position of microservice M1).

[0108] L403) identifies alarm messages with a specified application identifier as root cause alarm messages; where,

[0109] In the call chain, the call chain position of the application with the specified application identifier (i.e., microservice M3 in this case) is before the call chain position of the application with any application identifier. Both the alarm information with the specified application identifier and the alarm information with any application identifier belong to the alarm information within the second time window.

[0110] In other possible applications, the alarm center can also determine the application identifier in the call chain and place it in identifier set 1. It can also extract the application identifier from the alarm information in the second time window and place it in identifier set 2. Taking the intersection of identifier set 1 and identifier set 2, it can then use the call relationship between applications to find the alarm information corresponding to the application identifier with the earliest position in the call chain in the intersection, which is used as the root cause alarm information. The call chain position of the earliest application identifier is before the call chain position of any other application identifier in the intersection. For example, if the call chain relationship is microservice N1 calling microservice N2 (microservice N2's call chain position is before microservice N1's call chain position) and microservice N2 calling microservice N3 (microservice N3's call chain position is before microservice N2's call chain position), then the name of microservice N3 can be the earliest application identifier. In this case, the alarm information of microservice N3 in the second time window is the root cause alarm information. In some exemplary applications, microservice N1 can be an application that accesses data from the application database, microservice N2 can be a database driver that establishes communication between microservice N1 and the database, and microservice N3 can be a database program that provides data access functionality to microservice N1 through microservice N2.

[0111] In some possible implementations, for non-root cause alarm information within the second time window, the alarm center can save this alarm information to a specified storage address and generate a link to access that storage address. The link can be filled into the link parameter position configured in the root cause alarm information, so that all alarm information within the second time window is compressed into the root cause alarm information and the link of the remaining alarm information. This is beneficial for discovering and locating program problems in user services and noticing hidden security attacks, while reducing bandwidth resource consumption and saving communication resources used for log analysis and monitoring in large-scale cloud platforms / server clusters.

[0112] In some possible implementations, the alarm center can send root cause alarm information via a message sending queue. Step L4) above, which involves executing log alarms, may include:

[0113] L404) Writes the root cause alarm information into the sending queue and sends the root cause alarm information in the sending queue.

[0114] The alarm center can send root cause alarm information to designated user devices and / or resource management systems, thereby enabling program problems or hidden security attacks to be detected and resolved in a timely manner, ensuring the continuous availability of user services.

[0115] In some possible implementations, a delay timer can be provided to prevent the alarm center from repeatedly sending the same root cause alarm information within a short period (within the delay time). The aforementioned step L4) of executing log alarms may also include:

[0116] L405) records the keywords of the root cause alarm information and starts the delay timer corresponding to the keywords;

[0117] L406) Before the delay timer expires, ignore new alarm information sent by the stream processing engine or in the sending queue, where the keywords of the new alarm information are the same as the keywords of the root cause alarm information;

[0118] L407) After the delay timer finishes counting down, the delay timer is set to the initialization state.

[0119] In some possible implementations, keywords such as the microservice or middleware service's topic name, program problem, and attack behavior can be extracted from the root cause alarm information. A delay timer corresponding to each keyword can be started. The timer can count from time 0 to time T, or from time T to time 0, and its initial state can be 0 or T. The ignore operation can delete newly added alarm information.

[0120] In an exemplary log alarm scenario applied to an alarm center as disclosed in this embodiment of the invention, please refer to... Figure 5Continuing from the aforementioned log detection scenario, the alarm center can cache alarm information am1, 0, am2, am3, 0, etc. (0 in the cache space AW can represent no alarm information received at equal time intervals). The alarm center can read the cached alarm information and retrieve alarm templates from the alarm template library within the second time window Wb (step size ST') for template matching. In sliding window u0, for example, the similarity between alarm template 1 and alarm information am1, 0, and am2 can be r01, 0, and r03 respectively. If the similarity r03 of alarm template 1 is higher than the similarity threshold, a successful match occurs. In sliding window u1, if the similarity f02 and f09 of alarm templates 1 and 3 are higher than the similarity threshold, a successful match occurs, and so on. Then, the alarm center can perform a similarity comparison to determine the key alarm template max corresponding to the second time window. The application identifier in the alarm information corresponding to the key alarm template max can be the identifier of microservice Q6 or the identifier of middleware service K2, rather than the identifier of microservice Q2 (microservice Q2 is still available, the database service in the call chain where microservice Q2 is located still has microservice Q1, and the alarm information of microservice Q2 has low similarity with the alarm template of the offline database service). Based on the call chain where the identifier of microservice Q6 or the identifier of middleware service K2 is located, the alarm center determines that the first microservice is microservice Q3, so that the root cause alarm information of microservice Q3 can be found. The alarm center can send the root cause alarm information to the user device and / or resource management system so that the user device and / or resource management system can restore microservice Q3, for example, by executing the microservice of microservice Q3 image backup, thereby ensuring the continuous availability of user services.

[0121] This invention provides real-time log analysis via a sliding time window and issues alarms based on the analysis results. The alarm center then performs root cause analysis on the alarms to determine the root cause alarms. The alarms within the time window are compressed, and root cause alarms with the same keywords are aggregated within a delay time. This enables log detection and alarms applied to stream processing engines and alarm centers, improving the performance of log analysis and monitoring server products. It features the ability to promptly detect and resolve program problems or hidden security attacks in user services, ensuring continuous availability of user services.

[0122] In a third aspect, embodiments of the present invention also provide a log alarm processing system under the same inventive concept as the foregoing embodiments, which can be applied to the aforementioned data processing device. This log processing alarm system includes:

[0123] The acquisition module is used to acquire log data and open a first time window. The log data includes log data of applications in the call chain.

[0124] The tagging module is used to determine the tagging value set within the first time window. The tagging values ​​in the tagging value set are determined by the number of times the configured log template appears. The number of times the configured log template and the acquired log data are successfully matched within the first time window.

[0125] The determination module is used to determine the alarm log template from the log templates that have a successful matching status, and generate alarm information based on the alarm log template. The flag value corresponding to the alarm log template belongs to the numerical range configured in the alarm log template.

[0126] The sending module is used to send the alarm information to the alarm center, so that the alarm center can determine the root cause alarm information of the call link based on the alarm information within the second time window.

[0127] Specifically, retrieving log data includes:

[0128] It communicates with the middleware service to read log data stored by the middleware service, and consumes log data written by the log classification service within the topic of the middleware service; wherein,

[0129] The log classification service is used to classify logs based on log data collected by the probe service and a specified program identifier field;

[0130] The probe service is used to collect log data from the application in the call chain.

[0131] Specifically, the log processing system also includes:

[0132] The filtering module is used to determine the log level in the acquired log data and filter the acquired log data to retain log data with the specified log level.

[0133] The grouping module is used to segment the retained log data into words and group log data with the same number of segmented words into a log group.

[0134] Specifically, the log processing system also includes:

[0135] The calculation module is used to determine the similarity between the configured log template and the acquired log data;

[0136] The calculation module is also used to perform similarity matching to determine whether each log template has a successful match status; wherein...

[0137] If the similarity between the i-th log template and the acquired log data is higher than the similarity threshold, then the i-th log template is determined to have a successful matching state, and the number of times the i-th log template has a successful matching state is recorded, where i is a positive integer.

[0138] Specifically, determining the similarity between the configured log template and the acquired log data includes:

[0139] Convert the configured log template and the acquired log data into numerical vectors respectively;

[0140] Calculate the similarity between the numerical vectors.

[0141] Specifically, among them,

[0142] The similarity between the alarm log template and the acquired log data is greater than the similarity between any log template in the successfully matched log template and the acquired log data.

[0143] The first time window is a sliding time window.

[0144] Specifically, the log processing system also includes an alarm module. The alarm module is used for:

[0145] Receive alarm information sent by the stream processing engine within the second time window;

[0146] Determine the similarity between the configured alarm template and the received alarm information, and perform similarity matching to determine the key alarm template corresponding to the second time window from the alarm templates that have a successful matching status;

[0147] Determine the call chain corresponding to the application identifier, which is extracted from the alarm information that successfully matches the key alarm template;

[0148] Based on the call relationship between applications in the call chain, the root cause alarm information is determined from the alarm information within the second time window, and the log alarm is executed.

[0149] Specifically, the similarity between the key alarm template and the received alarm information is greater than the similarity between any alarm template in the alarm templates that have achieved a successful match and the received alarm information.

[0150] Specifically, among them,

[0151] If the similarity between the j-th alarm template and the received alarm information is higher than the similarity threshold, then the j-th alarm template is determined to have a successful matching status, where j is a positive integer;

[0152] The second time window is a sliding time window.

[0153] Specifically, the alarm module is also used for:

[0154] Extract the application identifier from the alarm information within the second time window;

[0155] The extracted application identifiers are used as an application identifier set, and it is determined that there are application identifiers in the application identifier set that are different from the application identifiers.

[0156] Alarm messages with a specified application identifier are identified as root cause alarm messages; where,

[0157] In the call chain, the call chain position of the application with the specified application identifier is located before the call chain position of the application with any application identifier.

[0158] Specifically, the alarm module is also used for:

[0159] Write the root cause alarm information into the sending queue and send the root cause alarm information in the sending queue.

[0160] Specifically, the alarm module is also used for:

[0161] Record the keywords of the root cause alarm information and start the delay timer corresponding to the keywords;

[0162] Before the delay timer expires, newly added alarm information sent by the stream processing engine or in the sending queue is ignored, and the keywords of the newly added alarm information are the same as the keywords of the root cause alarm information.

[0163] After the delay timer finishes counting down, the delay timer is set to the initialization state.

[0164] In a fourth aspect, embodiments of the present invention also provide an electronic device under the same inventive concept as the foregoing embodiments. This electronic device includes: at least one processor; and a memory connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the at least one processor implements the methods in the foregoing embodiments by executing the instructions stored in the memory. Please refer to... Figure 6 An exemplary electronic device is provided, the internal structure of which can be shown in the following diagram. Figure 6As shown, the device can be a server, industrial control computer, terminal equipment, microcontroller, etc. This electronic device includes a processor A01, a network interface A02, and a memory connected via a bus. The processor A01 provides computing, instruction processing, and control capabilities. The memory includes a main memory A03 and a non-volatile storage medium A04. The non-volatile storage medium A04 stores an operating system B01 and a computer program B02. The main memory A03 provides an environment for the operation of the operating system B01 and the computer program B02 stored in the non-volatile storage medium A04. The network interface A02 is used for communication with a network. When the computer program B02 is executed by the processor A01, it implements the methods described in the foregoing embodiments.

[0165] In a fifth aspect, embodiments of the present invention also provide a machine-readable storage medium under the same inventive concept as the foregoing embodiments, storing machine instructions that, when the machine instructions are run on a machine, cause the machine to perform the methods in the foregoing embodiments.

[0166] It should be noted that the information collection, analysis, use, transmission, and storage involved in this manual shall be used for legal and reasonable purposes in accordance with the provisions of laws and regulations, and shall not be shared, disclosed, or sold outside of these legal uses, and shall be subject to supervision and management in accordance with the law.

[0167] The optional embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the embodiments of the present invention are not limited to the specific details in the above embodiments. Within the scope of the technical concept of the embodiments of the present invention, various simple modifications can be made to the technical solutions of the embodiments of the present invention, and these simple modifications all fall within the protection scope of the embodiments of the present invention.

[0168] It should also be noted that the various specific technical features described in the above embodiments can be combined in any suitable manner without contradiction. To avoid unnecessary repetition, the embodiments of the present invention will not describe the various possible combinations separately.

[0169] Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a microcontroller, chip, or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium may be non-transient and may include various media capable of storing program code, such as USB flash drives, hard disks, read-only memory (ROM), random access memory (RAM), flash memory, magnetic storage, and optical storage.

[0170] Furthermore, various different implementations of the present invention can be combined arbitrarily, as long as they do not violate the spirit of the present invention, they should also be regarded as the content disclosed in the present invention.

Claims

1. A log detection method, characterized in that, This log detection method, applied to stream processing engines, includes: Obtain log data and open a first-time window, wherein the log data includes log data of applications in the call chain; Determine the similarity between the configured log template and the acquired log data; Perform similarity matching to determine whether each log template has a successful match; where, If the similarity between the i-th log template and the acquired log data is higher than the similarity threshold, then the i-th log template is determined to have a successful matching state, and the number of times the i-th log template has a successful matching state is recorded, where i is a positive integer; A set of marker values ​​is determined within the first time window. The marker values ​​in the set are determined by the number of times the configured log template appears. The number of times the configured log template and the acquired log data are successfully matched within the first time window. From the log templates that show a successful match, determine the alarm log template, and generate alarm information using the alarm log template. The tag value corresponding to the alarm log template belongs to the numerical range configured in the alarm log template. The alarm information is sent to the alarm center so that the alarm center can determine the root cause alarm information of the call chain based on the alarm information within the second time window.

2. The log detection method according to claim 1, characterized in that, The acquisition of log data includes: It communicates with the middleware service to read log data stored by the middleware service, and consumes log data written by the log classification service within the topic of the middleware service; wherein, The log classification service is used to classify logs based on log data collected by the probe service and a specified program identifier field; The probe service is used to collect log data from the application in the call chain.

3. The log detection method according to claim 1, characterized in that, After acquiring the log data and before determining the set of marker values ​​within the first time window, the log detection method further includes: Determine the log level in the acquired log data, and filter the acquired log data to retain log data with the specified log level; The retained log data is segmented into words, and log data with the same number of segmented words are grouped into log groups.

4. The log detection method according to claim 1, characterized in that, The determination of the similarity between the configured log template and the acquired log data includes: Convert the configured log template and the acquired log data into numerical vectors respectively; Calculate the similarity between the numerical vectors.

5. The log detection method according to claim 1, characterized in that, in, The similarity between the alarm log template and the acquired log data is greater than the similarity between any log template in the successfully matched log template and the acquired log data. The first time window is a sliding time window.

6. A log processing system, characterized in that, The log processing system includes: The acquisition module is used to acquire log data and open a first time window. The log data includes log data of applications in the call chain. The tagging module is used to determine the tagging value set within the first time window. The tagging values ​​in the tagging value set are determined by the number of times the configured log template appears. The number of times the configured log template and the acquired log data are successfully matched within the first time window. The determination module is used to determine the alarm log template from the log templates that have a successful matching status, and generate alarm information based on the alarm log template. The flag value corresponding to the alarm log template belongs to the numerical range configured in the alarm log template. The sending module is used to send the alarm information to the alarm center, so that the alarm center can determine the root cause alarm information of the call chain based on the alarm information within the second time window; The calculation module is used to determine the similarity between the configured log template and the acquired log data; The calculation module is also used to perform similarity matching to determine whether each log template has a successful match status; wherein... If the similarity between the i-th log template and the acquired log data is higher than the similarity threshold, then the i-th log template is determined to have a successful matching state, and the number of times the i-th log template has a successful matching state is recorded, where i is a positive integer.

7. An electronic device, characterized in that, The electronic device includes: At least one processor; A memory connected to the at least one processor; The memory stores instructions executable by the at least one processor, which implements the method described in any one of claims 1 to 5 by executing the instructions stored in the memory.

8. A machine-readable storage medium storing machine instructions that, when executed on a machine, cause the machine to perform the method of any one of claims 1 to 5.

Images