Log monitoring method and device, electronic equipment and computer program product

Abstract

The invention discloses a log monitoring method and device, electronic equipment and a computer program product. The method relates to the field of big data operation and maintenance, and comprises the following steps: acquiring M logs stored in a log source within a preset time period, and forming N closed-loop links based on the M logs; analyzing the scene type of each closed-loop link in the N closed-loop links, performing scene classification on the N closed-loop links according to the N scene types, and constructing knowledge maps of Y groups of closed-loop links to obtain Y closed-loop link maps; obtaining Y historical closed-loop link maps in a historical time period according to the Y scene types corresponding to the Y closed-loop link maps, and comparing each historical closed-loop link map with each closed-loop link map to generate Y comparison results; and determining an alarm level according to the Y comparison results, and determining link identification alarm information based on the alarm level. Through the method and the device, the technical problem of low processing efficiency when the log is analyzed and processed in related technologies is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of big data operation and maintenance, in particular to a log monitoring method and device, electronic equipment and computer program product. BACKGROUND

[0002] With the rapid development of large model technology and the continuous expansion of air traffic business scope, the operation and maintenance challenges faced by civil aviation information systems (hereinafter referred to as air traffic systems) are becoming increasingly severe. Under this background, the traditional monitoring and log analysis method gradually exposes its limitations and is difficult to effectively cope with the complex needs of modern civil aviation information system operation and maintenance.

[0003] Firstly, air traffic systems will generate a large amount of log data every day, covering many business links from flight booking, passenger information processing to payment settlement. The types of logs are diverse, including trace logs, application logs, database operation logs, etc., and their scale and speed far exceed the conventional analysis capability, causing a heavy burden on storage and processing. In addition, the dynamic and uncertain nature of civil aviation business requires the monitoring system to quickly adapt to changing business processes and scenarios. However, traditional monitoring systems rely heavily on fixed rule sets and are difficult to adjust flexibly to respond to new business characteristics or abnormal situations, especially when business logic involves interaction between multiple systems, the difficulty of monitoring increases exponentially.

[0004] In order to identify abnormalities, traditional monitoring systems pre-set a series of rules and thresholds, although this method can handle simple and direct abnormal patterns, it is easy to fail when facing highly complex and dynamic service call chains, and the setting of rules is difficult to consider all possible abnormal paths, resulting in missed detection or false positives. With the explosive growth of data, batch processing of log data takes too long and has poor real-time performance, making it impossible to respond to large-scale service requests or quickly detect sudden abnormalities in an instant, causing monitoring blind spots and lag effects. In addition, civil aviation information systems are composed of multiple interrelated subsystems, and data flows across different technology stacks and geographic regions. Traditional monitoring systems lack effective cross-system tracking means and are difficult to track the flow of logs, making it difficult to achieve fault diagnosis.

[0005] The related art has not yet proposed an effective solution to the technical problem of low processing efficiency when analyzing and processing logs. SUMMARY

[0006] The main purpose of the present application is to provide a log monitoring method, device, electronic equipment and computer program product to solve the technical problem of low processing efficiency when analyzing and processing logs in the related art.

[0007] To achieve the above objectives, according to one aspect of this application, a log monitoring method is provided. The method includes: acquiring M logs stored in a log source within a preset time period; constructing N closed-loop links based on the M logs, where N is less than M, and N and M are positive integers; parsing the scenario type of each of the N closed-loop links; classifying the N closed-loop links according to the N scenario types to obtain Y groups of closed-loop links; constructing a knowledge graph of the Y groups of closed-loop links to obtain Y closed-loop link graphs, where Y is a positive integer; acquiring Y historical closed-loop link graphs within a historical time period based on the Y scenario types corresponding to the Y closed-loop link graphs; comparing each historical closed-loop link graph with each closed-loop link graph to generate Y comparison results, where each historical closed-loop link graph corresponds to a scenario type; the comparison method includes at least log feature comparison and keyword comparison of the closed-loop links; determining the alarm level based on the Y comparison results; and determining link identification alarm information based on the alarm level.

[0008] Optionally, constructing N closed-loop links based on M logs includes: obtaining the log protocols associated with each of the M logs to obtain M log protocols; having a log adapter parse each log according to each log protocol to obtain M log information; combining the M log information to obtain N initial closed-loop links, and using regular expressions to filter noise in the N initial closed-loop links to obtain N first processing links; obtaining a log filtering model, inputting the N first processing links into the log filtering model, and outputting N second processing links, wherein the log filtering model includes a regular expression module and a joint filtering module, and the log filtering model is used to intercept abnormal logs in the N first processing links, and the abnormal logs include at least one of the following: format abnormal logs, information missing logs, and empty logs; converting the format of the N second processing links to obtain N third processing links, and determining the N third processing links as N closed-loop links.

[0009] Optionally, parsing the scenario type of each of the N closed-loop links includes: loading a language processing model, inputting the N closed-loop links into the language processing model, and outputting N structured events. The language processing model is used to perform context parsing processing on each closed-loop link, and each structured event indicates the link information of each closed-loop link; obtaining a rule engine, constructing a rule matching model based on the rule engine, and using the rule matching model to perform rule matching on the N closed-loop links based on the N structured events to obtain N rule matching results. The rule matching results include unmatched results and matched results. Unmatched results indicate that the closed-loop link does not match the rules in the rule engine, and matched results indicate that the closed-loop link matches the rules in the rule engine; and calling a feature extraction model to extract features from the N closed-loop links to obtain N sets of semantic features. Based on the N rule matching results and the N sets of semantic features, N scenario types are generated. The feature extraction model is constructed by a word embedding module and an attention module.

[0010] Optionally, generating N scene types based on N rule matching results and N sets of semantic features includes: for a closed-loop link, obtaining scene keyword rules, constructing a keyword filtering model based on the scene keyword rules, wherein the scene keyword rules include multiple scenes and multiple rules corresponding to each scene; when the rule matching result indicates that the closed-loop link has matched the rules in the rule engine, using the keyword filtering model to extract keywords from a set of semantic features of the closed-loop link to obtain a set of keywords, and obtaining the target scene based on the set of keywords, generating a scene type based on the target scene; when the rule matching result indicates that the closed-loop link has not matched the rules in the rule engine, inferring the closed-loop link through a log inference model to generate the scene type associated with the closed-loop link.

[0011] Optionally, constructing a knowledge graph of Y closed-loop links to obtain Y closed-loop link graphs includes: receiving business requirements, determining a chain processing model based on the business requirements, wherein the business requirements include at least relational requirements and digital requirements; constructing the lineage relationship of Y closed-loop links from the chain processing model to obtain Y closed-loop link graphs.

[0012] Optionally, constructing the lineage relationships of Y closed-loop links using a chain processing model to obtain Y closed-loop link graphs includes: for a set of closed-loop links, under the condition of business requirement characterizing the association requirement, extracting the software corresponding to the preset protocol from the log information associated with each closed-loop link in the set of closed-loop links to obtain the software information of K software, where K is a positive integer; determining the K software information as service nodes, and constructing a knowledge graph based on the service nodes to obtain a first knowledge graph; extracting the software metadata of K software from the log information associated with each closed-loop link, and filling the software metadata of K software into the first knowledge graph to obtain a second knowledge graph; obtaining preset dimension labels, and performing dimensional segmentation on the second knowledge graph based on the preset dimension labels to obtain a closed-loop link graph associated with a set of closed-loop links, where the preset dimension labels are used to indicate the business type of the closed-loop link graph.

[0013] Optionally, the lineage relationship of Y closed-loop links is constructed using a chain processing model, resulting in Y closed-loop link graphs, including: for a set of closed-loop links, under the condition that business requirements represent digital requirements, extracting aviation messages from the log information associated with each closed-loop link within the set of closed-loop links, and encoding and converting the fields of preset types in the aviation messages to obtain G field vectors, where G is a positive integer; determining the G field vectors as service nodes, constructing a knowledge graph based on the service nodes to obtain a third knowledge graph, and filling the aviation data associated with the aviation messages into the third knowledge graph to obtain a fourth knowledge graph; obtaining historical flight data, and aggregating the historical flight data into the fourth knowledge graph, thus obtaining a closed-loop link graph associated with a set of closed-loop links.

[0014] To achieve the above objectives, according to another aspect of this application, a log monitoring device is provided. The device includes: a first acquisition unit, used to acquire M logs stored in a log source within a preset time period, and construct N closed-loop links based on the M logs, where N is less than M, and N and M are positive integers; a parsing unit, used to parse the scenario type of each closed-loop link in the N closed-loop links respectively, classify the N closed-loop links according to the N scenario types to obtain Y groups of closed-loop links, and construct a knowledge graph of the Y groups of closed-loop links to obtain Y closed-loop link graphs, where Y is a positive integer; a second acquisition unit, used to acquire Y historical closed-loop link graphs within a historical time period according to the Y scenario types corresponding to the Y closed-loop link graphs, compare each historical closed-loop link graph with each closed-loop link graph to generate Y comparison results, where each historical closed-loop link graph corresponds to a scenario type, and the comparison method includes at least log feature comparison and keyword comparison of the closed-loop links; and a determination unit, used to determine the alarm level according to the Y comparison results, and determine the link identification alarm information based on the alarm level.

[0015] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to execute any of the above-described log monitoring methods.

[0016] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory storing an executable program, and the processor for running the program, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement any of the above-described log monitoring methods.

[0017] According to another aspect of the present invention, a computer program product is also provided, the computer program product including a computer program, wherein the computer program, when executed by a processor, implements any of the above-described log monitoring methods.

[0018] In this embodiment, log monitoring is employed. M logs stored in a log source within a preset time period are acquired, and N closed-loop links are constructed based on these M logs, where N is less than M and N and M are positive integers. The scenario type of each of the N closed-loop links is analyzed, and the N closed-loop links are classified according to the N scenario types to obtain Y groups of closed-loop links. A knowledge graph of the Y groups of closed-loop links is then constructed, resulting in Y closed-loop link graphs, where Y is a positive integer. Based on the Y scenario types corresponding to the Y closed-loop link graphs, Y historical closed-loop link graphs within a historical time period are obtained. Each historical closed-loop link graph is compared with each current closed-loop link graph to generate Y comparison results. In this system, each historical closed-loop link graph corresponds to a scenario type. The comparison method includes at least log feature comparison and keyword comparison of the closed-loop link. The alarm level is determined based on Y comparison results, and the link identification alarm information is determined based on the alarm level. This solves the technical problem of low processing efficiency in log analysis and processing in related technologies. By constructing a closed-loop link based on multiple logs and building a knowledge graph of the closed-loop link according to the scenario type of the closed-loop link, a closed-loop link graph is obtained. The historical closed-loop link graph is compared with each closed-loop link graph, and the alarm information is determined based on the comparison results. This achieves the technical effect of improving the efficiency of log analysis and processing and the accuracy of fault location. Attached Figure Description

[0019] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0020] Figure 1This is a hardware structure block diagram of a computer terminal (or mobile device) used to implement a log monitoring method;

[0021] Figure 2 This is a flowchart of a log monitoring method provided according to an embodiment of this application;

[0022] Figure 3 This is a schematic diagram of the processing method of the log inference model provided in the embodiments of this application;

[0023] Figure 4 This is a schematic diagram of a chain processing model provided according to an embodiment of this application;

[0024] Figure 5 This is a schematic diagram of an optional log monitoring method provided according to an embodiment of this application;

[0025] Figure 6 This is an architecture diagram of the log cognitive hub provided in the embodiments of this application;

[0026] Figure 7 This is a schematic diagram of a log monitoring device provided according to an embodiment of this application;

[0027] Figure 8 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0028] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0030] It should be noted that all information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this application are information and data authorized by the user or fully authorized by all parties. For example, this system has interfaces with relevant users or organizations to provide users with corresponding operation data for them to choose to agree to or refuse automated decision results. Before obtaining relevant information, a request for obtaining the information needs to be sent to the aforementioned user or organization through the interface, and the relevant information is obtained after receiving consent from the aforementioned user or organization; if the user chooses to refuse, the expert decision-making process is initiated. Users can view the purpose of data use in real time through authorization decoding and have the right to withdraw authorization or delete data at any time. After the authorization is withdrawn, the system will terminate the relevant data processing within 24 hours.

[0031] It should be noted that the information collected in this application is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with the relevant laws, regulations and standards of the relevant regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize use or refuse use.

[0032] Example 1

[0033] According to an embodiment of this application, a method embodiment for monitoring logs is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0034] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 This is a hardware structure block diagram of a computer terminal (or mobile device) used to implement a log monitoring method, such as... Figure 1 As shown, computer terminal 10 (or mobile device) may include one or more ( Figure 1(Illustrated as 102a, 102b, ..., 102n) Processor 102 (processor 102 may include, but is not limited to, a microprocessor MCU (Microcontroller Unit) or a programmable gate array (FPGA), etc.), memory 104 for storing data, and transmission device 106 for communication functions. In addition, it may include: a display, input / output interface (I / O interface), Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS bus), network interface, keyboard, cursor control device, power supply and / or camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0035] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0036] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the log monitoring method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned log monitoring method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0037] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a network interface controller (NIC) and a network interface, which can be connected to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a radio frequency (RF) module, used for wireless communication with the Internet.

[0038] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0039] Under the aforementioned operating environment, this application provides the following: Figure 2 The log monitoring method is shown. Figure 2 This is a flowchart of a log monitoring method provided according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0040] Step S201: Obtain M logs stored in the log source within a preset time period, and construct N closed-loop links based on the M logs, where N is less than M and N and M are positive integers.

[0041] It should be noted that a log source refers to a system or component used to store log data. For example, log sources can collect and transmit data through Kafka, Elasticsearch indexes, etc. The logs stored in a log source can include logs from multiple sources such as off-shipment tracking logs, application logs, and compute node logs. Among them, the tracking log file consists of three parts: a control header, an extension area, and a content area. The control header records basic information such as time and software. The content of the control header must follow the following specifications: fields must be ordered and in the correct order; if the value of a field is missing, the separators before and after it must be retained. The extension area records the values ​​of key business fields during system runtime. This structured information is used to build a query index, which facilitates the parsing and analysis of the tracking data. The extension area is a set of (Key, Value) pairs and must follow the following specifications: use the form "Key = Value;" separated by ";", Key and Value must appear in pairs, and there is no specific order. The content area records the transmitted data stream or key business processing information.

[0042] In log analysis, a closed-loop link refers to starting from the logs of a service or component, tracing its interactions with other services within the system, and finally returning to the original service or component, forming a complete call chain or service dependency loop. For example, in a civil aviation information system, a flight booking request can start from the user interface, go through multiple background services, and finally return confirmation information to the user; this complete path constitutes a closed-loop link. To perform link analysis, it is first necessary to obtain multiple logs from the aforementioned data sources. After obtaining multiple logs within a preset time period, these logs can be identified using the LangChain framework and intelligent analysis engine, thereby constructing multiple closed-loop links, providing a foundation for subsequent full-link monitoring and fault analysis.

[0043] Step S202: Analyze the scenario type of each closed loop in the N closed loop links respectively, classify the N closed loop links according to the N scenario types to obtain Y groups of closed loop links, and construct the knowledge graph of the Y groups of closed loop links to obtain Y closed loop link graphs, where Y is a positive integer.

[0044] Specifically, after constructing the closed-loop link, the scenario type of each closed-loop link can be parsed based on log information. This means identifying the specific business scenario or operation type reflected in the closed-loop link, thereby determining the business scenario or operation type carried by each service call chain, resulting in multiple scenario types. For example, scenario types can include flight booking, baggage handling, boarding process, system communication, etc., or they can include software management relationship types and digital flight types. Then, based on the type of the closed-loop link, it is divided into different groups, enabling targeted analysis of different types of business scenarios. All closed-loop links in each group are processed, resulting in multiple closed-loop link graphs. These knowledge graphs not only store static associations between services but also reflect the real-time status and historical trends of the links through a dynamic update mechanism. Operations personnel can obtain a more intuitive view of the system's operating status, facilitating the discovery of potential performance bottlenecks and abnormal behaviors, and providing data support for anomaly detection and fault location.

[0045] It should be noted that the closed-loop link graph, also known as the lineage graph, refers to the knowledge graph of the trajectory, process and transformation of data throughout its entire life cycle from its original source to its final destination. It can provide the LangChain framework with the ability to track the flow of data (especially log data) between different systems, record their dependencies and operation history, thereby improving the efficiency of data monitoring and system operation and maintenance.

[0046] Step S203: Obtain Y historical closed-loop link maps within a historical time period based on the Y scene types corresponding to the Y closed-loop link maps. Compare each historical closed-loop link map with each closed-loop link map to generate Y comparison results. Each historical closed-loop link map corresponds to a scene type. The comparison method includes at least log feature comparison of the closed-loop link and keyword comparison of the closed-loop link.

[0047] Specifically, after obtaining multiple closed-loop link maps, closed-loop link maps constructed based on historical log data can be obtained based on the scenario types corresponding to these maps. In other words, multiple historical closed-loop link maps are obtained. These maps can reflect the structure and behavioral characteristics of service calls in each scenario type under historical conditions.

[0048] Furthermore, to detect abnormal service call patterns or performance metric changes, the log data features or keyword features in the closed-loop link graph can be compared with those in the historical closed-loop link graph to obtain multiple comparison results. When comparing log features, vector retrieval can be used, that is, using the Faiss index to compare the log features of similar historical links. When comparing keywords, it can be achieved by quickly matching known rules based on the Elasticsearch inverted index. The comparison results can include changes in log features (such as response time, error rate), the appearance or disappearance of keywords (such as new exception codes or service names), and changes in service call patterns.

[0049] Step S204: Determine the alarm level based on the Y comparison results, and determine the link identification alarm information based on the alarm level.

[0050] Specifically, after comparing the closed-loop link map generated in the current time period with the closed-loop link map of the corresponding historical time period, the alarm level can be determined based on the severity and urgency of the anomalies detected in the comparison results. Then, an alarm is triggered through a dual-drive alarm engine. For example, alarm levels can be divided into multiple levels, such as critical alarm (P0), important alarm (P1), ordinary alarm (P2), and minor alarm (P3). Each level of alarm has its specific triggering conditions and handling strategies. For example, conditions that trigger high-priority alarms include three consecutive request timeouts, an error rate higher than 5%, or critical service interruption. For instance, the triggering condition for P0 level is a core business interruption, which requires sending an SMS and making a phone call to operations personnel; the triggering condition for P1 level is a localized performance degradation, which requires sending an email to operations personnel, etc. It should be noted that the dual-drive alarm engine refers to the rule engine, the pre-filtering engine, and the large model-assisted verification. It can block duplicate alarms (e.g., merging the same events within 5 minutes), define hard conditions (e.g., three consecutive timeouts) to trigger P0-level alarms, and generate probabilistic alarms for implicit risks (e.g., sudden increases / decreases in log volume, data skew, etc.).

[0051] After determining the alarm level, detailed link identification alarm information can be generated. This allows operations and maintenance personnel to take appropriate measures, such as initiating emergency response procedures, allocating additional resources, or notifying senior operations and maintenance personnel. The link identification alarm information provides a detailed view of the abnormal call chain, including the starting point of the abnormal behavior, the critical path, and the scope of impact, significantly reducing fault location time and promoting rapid response and service recovery. It should be noted that when the closed-loop link map is compared with the closed-loop link map of the corresponding historical time period, the comparison result indicates a conflict between the new link model event and the knowledge base model. This can trigger an update mechanism (such as automatic classification of newly added models) to optimize subsequent decisions.

[0052] The log monitoring method provided in this application involves acquiring M logs stored in a log source within a preset time period, constructing N closed-loop links based on these M logs (where N is less than M and N and M are positive integers), parsing the scenario type of each of the N closed-loop links, classifying the N closed-loop links according to the N scenario types to obtain Y groups of closed-loop links, and constructing a knowledge graph of the Y groups of closed-loop links to obtain Y closed-loop link graphs (where Y is a positive integer); obtaining Y historical closed-loop link graphs within a historical time period based on the Y scenario types corresponding to the Y closed-loop link graphs, and comparing each historical closed-loop link graph with each current closed-loop link graph to generate Y comparison results. Each historical closed-loop link graph corresponds to a scenario type. The comparison method includes at least log feature comparison and keyword comparison of the closed-loop link. The alarm level is determined based on Y comparison results, and the link identification alarm information is determined based on the alarm level. This solves the technical problem of low processing efficiency in log analysis and processing in related technologies. By constructing a closed-loop link based on multiple logs and building a knowledge graph of the closed-loop link according to the scenario type of the closed-loop link, a closed-loop link graph is obtained. The historical closed-loop link graph is compared with each closed-loop link graph, and the alarm information is determined based on the comparison results. This achieves the technical effect of improving the efficiency of log analysis and processing and the accuracy of fault location.

[0053] Optionally, in the log monitoring method provided in this application embodiment, constructing N closed-loop links based on M logs includes: obtaining the log protocols associated with the M logs respectively, obtaining M log protocols, and having a log adapter parse each log according to each log protocol to obtain M log information; combining the M logs through the M log information to obtain N initial closed-loop links, and using regular expressions to filter noise in the N initial closed-loop links to obtain N first processing links; obtaining a log filtering model, inputting the N first processing links into the log filtering model, and outputting N second processing links, wherein the log filtering model includes a regular expression module and a joint filtering module, and the log filtering model is used to intercept abnormal logs in the N first processing links, and the abnormal logs include at least one of the following: format abnormal logs, information missing logs, and empty logs; converting the format of the N second processing links to obtain N third processing links, and determining the N third processing links as N closed-loop links.

[0054] Specifically, when constructing a closed-loop process, the first step is to obtain the log protocol associated with each log. A log protocol refers to the specific format or convention followed by different systems or services when generating logs; for example, the Kafka protocol for tracking logs and the text protocol for compute node logs. Then, a log adapter is used to parse each log according to its associated log protocol, obtaining the corresponding structured log information. The log adapter parses the collected logs according to their respective associated log protocols. The parsing process may include standardizing log formats, extracting key fields, and identifying log types to adapt to subsequent processing flows. Log information may include key log attributes such as timestamps, hostnames, log levels, and message content.

[0055] Furthermore, based on the parsed M log messages, a closed-loop path for service calls is constructed through correlation analysis (such as using GlobalID to correlate multi-source logs). Multiple logs are then combined to obtain an initial closed-loop link. Regular expressions are then used to filter noise from this initial closed-loop link, removing log records that do not conform to preset formats or content rules. For example, logs that do not contain required fields are filtered out, or meaningless logs that may be generated by system anomalies are eliminated. This yields the first processing link, ensuring the accuracy of subsequent processing.

[0056] Furthermore, by acquiring a log filtering model, the first processing link is further filtered using this model, resulting in a corresponding second processing link. This log filtering model is a lightweight, machine learning-based model, such as LogCleaner-1B, which combines a regular expression rule module and a joint filtering module. This allows for further detection and interception of abnormal logs in the first processing link. The regular expression rule module applies static filtering rules, while the joint filtering module uses the model to examine the complex content of the logs, ensuring the comprehensiveness and accuracy of the filtering. Then, the host metadata (IP address, service name, source) and business tags (such as application, module, link relationship) in the second processing link are dynamically annotated to enhance the log context semantics. After this enhancement, the logs are then formatted to obtain the third processing link. For example, fields such as timestamp, host, log_level, and message in unstructured logs are converted to JSON (JavaScript Object Notation) format. After a series of processing and optimizations, the final confirmed closed-loop link set, i.e., the third processing link, is determined as the closed-loop link.

[0057] This embodiment obtains the log protocol and parses the logs using a log adapter. It also employs noise filtering and anomaly interception measures to ensure the quality of the closed-loop link, avoiding the impact of invalid or erroneous information on the analysis results. This provides a standardized data format for the implementation of full-link tracing, semantic parsing, lineage relationship construction, and intelligent decision-making closed loop, greatly reducing maintenance manpower costs and improving maintenance response speed.

[0058] Optionally, in the log monitoring method provided in this application embodiment, parsing the scenario type of each closed-loop link in N closed-loop links includes: loading a language processing model, inputting the N closed-loop links into the language processing model, and outputting N structured events, wherein the language processing model is used to perform context parsing processing on each closed-loop link, and each structured event is used to indicate the link information of each closed-loop link; obtaining a rule engine, constructing a rule matching model based on the rule engine, and performing rule matching on the N closed-loop links based on the N structured events to obtain N rule matching results, wherein the rule matching results include unmatched results and matched results, the unmatched results are used to indicate that the closed-loop link does not match the rules in the rule engine, and the matched results are used to indicate that the closed-loop link matches the rules in the rule engine; calling a feature extraction model to extract features from the N closed-loop links to obtain N sets of semantic features, and generating N scenario types based on the N rule matching results and the N sets of semantic features, wherein the feature extraction model is constructed by a word embedding module and an attention module.

[0059] Specifically, when parsing the scenario type of each closed-loop link, i.e., identifying the intent of each closed-loop link, a fine-tuning model can first be built based on LLMChain to obtain a language processing model. After loading this language processing model, the closed-loop link can be input into the language processing model, and the corresponding structured events can be output. The language processing model can be a LogParser-7B model, capable of understanding and parsing the contextual semantic information in the closed-loop link. The structured events are the standardized output obtained after closed-loop link analysis, containing key information and parsed features of the closed-loop link, such as service call order, time consumption, and error codes. For example, this can be implemented using the following code:

[0060] parse_chain = (

[0061] RunnableLambda(lambda x:clean_log(x))

[0062] PromptTemplate.from_template("Parsing Logs: {log} → JSON Format")

[0063] HuggingFacePipeline(model_name="meta-llama3-8b") )

[0065] Furthermore, rule matching is performed by combining a rule engine with a large model collaboration strategy. This involves acquiring a rule engine used to store and manage a series of business rules, and then building a rule matching model based on the rule engine. This model can filter known patterns using regular expressions to identify whether the closed-loop link conforms to preset business rules. The rule matching model then performs rule matching on the closed-loop link based on the aforementioned structured events, obtaining the matching results. Unmatched results indicate that certain behaviors or characteristics in the closed-loop link do not follow preset business rules, potentially indicating a fault or anomaly; matched results indicate that the closed-loop link conforms to the rules and represents normal or expected behavior.

[0066] Furthermore, a feature extraction model based on the Transformer architecture (such as Qwen-7B48) is invoked to extract features from the closed-loop link, resulting in multiple sets of semantic features. The feature extraction model includes a word embedding module and an attention module. The word embedding module is used to convert text information into numerical vectors and capture the semantic features of the log. The attention module can highlight key information in the closed-loop link. For example, the input of this model is the log text in the closed-loop link (such as ERROR: Databaseconnectiontimeout), and the output of the model is a labeled structured semantic feature (such as {"STAT_IN": "input", "protocol": "2"......}).

[0067] Finally, based on the above rule matching results and semantic features, scenario types that can reflect specific patterns or functions in the closed-loop link are generated, providing a clear perspective for subsequent fault location and decision support.

[0068] This embodiment uses a deep learning model to extract features from the closed-loop link and combines the results of rule matching to automatically identify and classify business scenarios. This simplifies the understanding of log information by operations and maintenance personnel, greatly improves the efficiency and accuracy of log analysis, and provides a solid data foundation and technical support for building an intelligent operations and maintenance decision-making closed loop, thereby improving the stability and operational efficiency of the system.

[0069] Optionally, in the log monitoring method provided in this application embodiment, generating N scene types based on N rule matching results and N sets of semantic features includes: for a closed-loop link, obtaining scene keyword rules, constructing a keyword filtering model based on the scene keyword rules, wherein the scene keyword rules include multiple scenes and multiple rules corresponding to each scene; when the rule matching result indicates that the closed-loop link has matched the rules in the rule engine, extracting keywords from a set of semantic features of the closed-loop link using the keyword filtering model to obtain a set of keywords, and obtaining a target scene based on the set of keywords, and generating a scene type based on the target scene; when the rule matching result indicates that the closed-loop link has not matched the rules in the rule engine, inferring the closed-loop link through a log inference model to generate a scene type associated with the closed-loop link.

[0070] Specifically, when generating scenario types, high-frequency words (such as GlobalID, TransactionID, Appcode, Protocol) can first be filtered based on TF-IDF (Term Frequency-Inverse Document Frequency) and Embedding similarity, and a business scenario-customized thesaurus (such as OriAppCode, DesAppCode, OriSys, MsgType, DesSys, TimeCost, Deploy, etc.) can be obtained. Scenario keyword rules are then obtained based on the above content, and a keyword filtering model based on the LangChain framework is constructed based on the scenario keyword rules.

[0071] When the rule matching result indicates that the closed-loop link has matched the rules in the rule engine, keywords can be extracted from a set of semantic features of the closed-loop link using a keyword filtering model. This involves using ConversationalRetrievalChain to achieve cross-log association, concatenating multi-source logs based on timestamps and GlobalIDs, then segmenting long logs using LangChain's TextSplitter, and extracting keywords (such as error codes and resource utilization) using Few-shot Prompt. Then, based on a set of keywords, the actual business scenario executed by the closed-loop link is obtained, i.e., the target scenario. Finally, a scenario type is generated based on the target scenario, providing a clear context for fault analysis.

[0072] If the rule matching result indicates that the closed-loop link does not match the rules in the rule engine, then it is necessary to infer the closed-loop link through the log inference model to generate the scenario type associated with the closed-loop link. Figure 3 This is a schematic diagram of the processing method of the log inference model provided in the embodiments of this application, such as... Figure 3As shown, the process first requires receiving logs from the closed-loop chain. After initial verification, these logs undergo vector transformation and prompt word engineering. Then, the log inference model is called via an interface. The model concatenates the retrieved content into the original prompt words, forming an enhanced input for context injection to achieve similarity matching. Specifically, it uses TextSplitter to segment abnormal information, generates vector indexes through embedding, and associates business entities in the logs using a vector library retrieval method. Finally, it generates the scenario type associated with the closed-loop chain. Prompt word engineering involves reorganizing the input logs, adding specific structures and formats to make them closer to the examples used during model training, thereby improving the model's understanding and response quality. It can also incorporate various forms of data, such as images and audio, as input, adding more contextual information to the prompt words to help the model better understand the problem background and improve its context awareness. It should be noted that the log inference model can be a model built on a large model, capable of deep analysis of closed-loop chains without matching rules. By understanding the semantic content and contextual information of the closed-loop chain, it can infer the business scenarios or functional types that may be involved.

[0073] This embodiment combines rule engine and large model technology to achieve multi-level and all-round scenario type identification of closed-loop links. It not only ensures efficient processing of common scenarios, but also takes into account the intelligent response to complex and rare scenarios, greatly enriching the capabilities of intelligent operation and maintenance decision-making closed loop. Through the collaborative application of LangChain framework and large model, it can not only achieve fine understanding and monitoring of service call chain, but also perform targeted resource scheduling and fault response according to scenario type, significantly improving operation and maintenance efficiency.

[0074] Optionally, in the log monitoring method provided in this application embodiment, constructing a knowledge graph of Y closed-loop links to obtain Y closed-loop link graphs includes: receiving business requirements, determining a chain processing model based on the business requirements, wherein the business requirements include at least relational requirements and digital requirements; constructing the lineage relationship of Y closed-loop links from the chain processing model to obtain Y closed-loop link graphs.

[0075] To customize data processing workflows by analyzing business needs and then construct a closed-loop lineage graph, the first step is to obtain the business requirements for building the graph. This involves constructing a knowledge graph of software relationships or a knowledge graph of digital flights. Relationships refer to the mutual calls and influences between different services or components in the data flow, such as the call order and dependencies between payment services and flight query services. Then, the specific chained processing model is determined based on the business requirements. This chained processing model refers to a data processing model built using the LangChain framework. This model consists of multiple interconnected processing modules, each responsible for a specific data processing task (such as data cleaning, feature extraction, and model inference). The modules form a chained workflow through data transfer and result feedback. Figure 4 This is a schematic diagram of the chain processing model provided according to the embodiments of this application, such as... Figure 4 As shown, the model includes a Model Input / Output module (Model I / O), capable of processing and interacting with large models, including preprocessing input data and formatting output results; a Retrieval module, which interacts with the Model I / O module to retrieve relevant information from indexes or databases; Chains, which contain multiple steps executed in sequence, each step potentially depending on the output of the previous step; a Memory module, used to store and manage the context information of the dialogue for use during processing; Agents, capable of performing complex task orchestration and decision-making, and can call the Tools module to perform external operations or obtain additional information; Tools, which provides interfaces to external systems or services, such as sending emails and querying databases; and Callbacks, which handles asynchronous events or results, returning the processing results to the Agents module or external systems.

[0076] Furthermore, the chain processing module in the aforementioned chain processing model constructs a lineage graph for each closed-loop link, thus obtaining the corresponding closed-loop link graph. This graph includes not only the order of service calls but also performance metrics and anomaly events for each node. It's worth noting that after constructing the closed-loop link graph, for ease of viewing by operations personnel, full-link visualization can be performed. This involves first displaying the log flow path along a timeline; then determining the context logs of abnormal links (e.g., the context logs of abnormal links could be the abnormal distribution of metrics from Hadoop compute nodes → Kafka → Elasticsearch); and using the Retriever component to construct an inverted index based on log data in the HBase (Hadoop Database) database. When a user inputs a query, the query is converted from a natural language question into a logical expression, such as "find logs related to a flight delay." The query statement is then parsed into a suitable format and efficiently retrieved from the HBase database. Simultaneously, the search results are sorted and optimized based on log vector similarity calculations. Finally, the aggregation results are displayed using the callback module in the aforementioned chain processing model.

[0077] This embodiment constructs a data processing model and generates a closed-loop lineage graph, which can not only efficiently process multi-source heterogeneous data, but also flexibly respond to the needs of different business scenarios through modular design. The generation of the closed-loop lineage graph helps operation and maintenance personnel to quickly understand and respond to system status, and realize intelligent monitoring and decision support.

[0078] Optionally, in the log monitoring method provided in this application embodiment, constructing the lineage relationship of Y groups of closed-loop links by a chain processing model to obtain Y closed-loop link graphs includes: for a group of closed-loop links, under the condition that the business requirement represents the association requirement, extracting the software corresponding to the preset protocol from the log information associated with each closed-loop link in the group of closed-loop links to obtain the software information of K software, where K is a positive integer; determining the K software information as service nodes, and constructing a knowledge graph based on the service nodes to obtain a first knowledge graph; extracting the software metadata of K software from the log information associated with each closed-loop link, and filling the software metadata of K software into the first knowledge graph to obtain a second knowledge graph; obtaining preset dimension labels, and performing dimension segmentation on the second knowledge graph based on the preset dimension labels to obtain a closed-loop link graph associated with a group of closed-loop links, wherein the preset dimension labels are used to indicate the business type of the closed-loop link graph.

[0079] To meet the requirements for relational relationships, a detailed service dependency network can be constructed by identifying and analyzing software associations in the log information, further generating a hierarchical closed-loop link graph. Since protocols are annotated in the logs, and different protocols are processed differently, association mapping and protocol customization can be performed first. This involves extracting the software corresponding to a preset protocol from the log information associated with each closed-loop link within a set of closed-loop links. In other words, information is mapped to corresponding software through protocols, and the software is annotated to obtain multiple software information entries. The preset protocol refers to the communication specifications followed during log generation and transmission, used to identify the communication methods and data formats of different software in the closed-loop link. Software information refers to the specific details of the software or services involved in the closed-loop link, including software name, version number, service address, etc. Through the preset protocol, the software information in the logs can be accurately parsed and matched, ensuring the accuracy and completeness of the closed-loop link graph construction. This allows for the identification of all software or services involved in the closed-loop link from the log information, providing a foundation for subsequent construction of service nodes and service dependencies.

[0080] Furthermore, the aforementioned software information is identified as service nodes, representing specific services or software functional components within the closed-loop chain. Then, a full-lifecycle view describing the relationships between entities (such as software and services) is constructed based on these service nodes, resulting in a first knowledge graph reflecting the static relationships of service calls within the closed-loop chain. Next, software metadata is extracted from the log information associated with each closed-loop chain and populated into the first knowledge graph to obtain a second knowledge graph. This second knowledge graph is created by linking cross-service logs, defining Span tags to record key metadata, and then storing this metadata in the first knowledge graph. Software metadata refers to additional information describing the software or service, including but not limited to service call time, response status, and error codes. The second knowledge graph not only includes the static relationships of service calls but also covers dynamic performance indicators and operational status, forming a dynamic view of the closed-loop chain.

[0081] Furthermore, to hierarchically and classify the second knowledge graph, preset dimension labels can be obtained. Based on these labels, the second knowledge graph is then segmented dimensionally, resulting in a closed-loop link relationship representation specific to the business type. This yields a closed-loop link graph, which can be a single graph or a set of graphs, depending on the type and number of preset dimension labels. It should be noted that after segmenting the second knowledge graph based on the preset dimension labels, to further identify abnormal paths, abnormal links can be marked on the segmented knowledge graph based on predefined link information, thus constructing a closed-loop link graph. Simultaneously, the Peter-Clark (PC) algorithm can be used to analyze the correlation of metrics in the closed-loop link graph, locate root cause nodes, and output an interpretability report of abnormal paths, providing the operations team with an efficient and accurate data analysis tool.

[0082] This embodiment identifies and analyzes service call relationships to construct a closed-loop link graph that includes static dependencies and dynamic performance indicators. The closed-loop link graph can not only meet the correlation requirements under business needs, but also be layered and classified according to preset dimension labels to form a business-focused closed-loop link dynamic view, which helps to quickly locate the source of failure, optimize system performance, and realize a closed loop of intelligent operation and maintenance decision-making.

[0083] Optionally, in the log monitoring method provided in this application embodiment, constructing the lineage relationship of Y closed-loop links by a chain processing model to obtain Y closed-loop link graphs includes: for a group of closed-loop links, under the condition that business requirements represent digital requirements, extracting aviation messages from the log information associated with each closed-loop link in the group of closed-loop links, and encoding and converting the fields of preset types in the aviation messages to obtain G field vectors, where G is a positive integer; determining the G field vectors as service nodes, constructing a knowledge graph based on the service nodes to obtain a third knowledge graph, and filling the aviation data associated with the aviation messages into the third knowledge graph to obtain a fourth knowledge graph; obtaining historical flight data, aggregating the historical flight data into the fourth knowledge graph, and thus obtaining a closed-loop link graph associated with a group of closed-loop links.

[0084] Specifically, when the business requirement is a digital requirement, since the flight segment information is relatively redundant, it is possible to avoid storing too much redundant information and prioritize retaining the definitions of key fields. That is, the metadata is adjusted through lightweight processing to establish a data dictionary for airports and flights. Then, using LangChain's text embedding model, the fields of preset types extracted from the aviation messages in the log information are encoded and converted to obtain multiple numerical field vectors. Among them, the preset type fields can contain key information of the digital requirement, such as the flight's departure time, arrival time, delay time, service response time, etc.

[0085] Furthermore, the aforementioned field vectors are identified as service nodes representing the digital features and performance indicators of service calls in the closed-loop chain. A knowledge graph is constructed based on these service nodes to obtain a third knowledge graph reflecting the digital demand information of service calls in the closed-loop chain. Simultaneously, a document loader can be selected to process aviation data in log format associated with aviation messages. Unstructured log data is segmented through loading, keywords are extracted using an output parser, and log patterns are defined and parsed using a StructuredOutputParser to generate structured data. This data is then injected into the third knowledge graph through knowledge injection to obtain a fourth knowledge graph. It should be noted that the aforementioned aviation data can be obtained by entity relation extraction using the BERT-BiLSTM-CRF (Bidirectional Encoder Representations from Transformers-Bidirectional Long Short-Term Memory-Conditional Random Field) model.

[0086] Furthermore, after acquiring historical flight data from the historical database, this data is aggregated into a fourth knowledge graph, thereby generating a closed-loop link graph with interconnected links. It should be noted that after obtaining the aforementioned closed-loop link graph, a trained anomaly detection model, based on Isolation Forest or One-Class SVM, can be used to identify abnormal paths in the vectors within the graph, and the anomaly information is stored in the HBase database.

[0087] This embodiment constructs a closed-loop link graph that includes digital features and aviation business data. This not only meets the digital requirements under business needs, but also provides deeper and more comprehensive data support for operation and maintenance decisions by integrating historical flight data. This helps to accurately locate performance issues related to digital requirements and optimize the stability of system services and flight operations.

[0088] This application also provides a method for monitoring logs. Figure 5 This is a schematic diagram of an optional log monitoring method provided according to an embodiment of this application, such as... Figure 5 As shown, the method includes:

[0089] To achieve intelligent analysis across the entire value chain, steps such as data collection, intelligent cognition, end-to-end tracing, and decision-making closure are required. First, multiple logs are acquired from log sources, including off-shipment tracking logs, application logs, and system performance metrics. Specifically, LangChain's Document Loaders in the collection layer can be used to access heterogeneous log sources, obtaining various logs such as real-time streams (e.g., Kafka log streams), offline files (log files on Hadoop HDFS (Hadoop Distributed File System),) and indexed data (log indexes in Elasticsearch). These logs are then identified through the LangChain framework and intelligent analysis engine, constructing multiple closed-loop chains to provide a foundation for subsequent end-to-end monitoring and fault analysis. It should be noted that Kafka real-time log streams can be accessed through LangChain's TextLoader, while HuggingFacePipeline is used for preliminary text cleaning and format conversion to ensure data standardization and consistency.

[0090] Furthermore, closed-loop link identification is performed through the log cognitive center of the cognitive layer. That is, a semantic log processing chain is constructed through LangChain, and the LogParser-7B model is dynamically loaded for log parsing. Long logs are segmented using TextSplitter, and key fields (such as error codes and resource utilization) are extracted by combining Few-shot Prompt. Alternatively, the Log-LLM model can be dynamically loaded to perform intent recognition and key field extraction for each log, such as flight number, departure time, arrival time, and error code. Intent recognition is performed by combining the rule engine and the large model, and the logs are semantically classified and anomaly detected to obtain the scenario type of the closed-loop link.

[0091] Furthermore, dynamic tracking of the entire link relationship is performed through the tracing layer, which means realizing cross-system log link lineage analysis. This involves using Flink to consume data and log streams in real time, and automatically associating cross-service logs based on GlobalID (GID) to build a full-lifecycle view of requests. Neo4j is used to store the dependency graph and entity relationships of storage services, associating cross-system logs based on GID (Global Identifier) ​​to build service nodes and service call relationships, and then dynamically constructing lineage relationships (such as service call order and link latency). The PC algorithm is used to analyze the correlation of indicators, locate the root cause node, and use the SHAP interpretation framework to output the interpretability report of the fault. By identifying critical paths, abnormal links are marked in real time.

[0092] Finally, a closed-loop intelligent decision-making process is achieved through the decision-making layer, realizing a self-iterative knowledge base and precise alerts. This involves constructing a dynamic knowledge base, using the RAPTOR algorithm to cluster historical logs, generating a hierarchical knowledge graph, and optimizing the knowledge base through LangChain's Self-Correction mechanism to improve decision accuracy for newly emerging model events or rule conflicts. Then, an alert noise reduction mechanism, a rule engine pre-filtering duplicate alerts, and a large model assisting in verifying implicit risks are used. Finally, a tiered alerting strategy is implemented, using different notification methods (such as phone calls, SMS, and emails) for alerts at levels P0-P3. Alerts can be visualized using Grafana to build a tracking dashboard, displaying the log flow path in real time, supporting keyword filtering and timeline display, and pushing alert information to Prometheus / Grafana via the LangChain callback module.

[0093] Figure 6 This is an architecture diagram of the log cognitive hub provided in the embodiments of this application, such as... Figure 6 As shown, the log cognitive hub can achieve multi-source log access, semantic parsing and intent recognition, and dynamic keyword modeling. The multi-source log access module first needs to perform protocol adaptation, that is, through a unified log adapter, to adapt protocols for different log sources, ensuring seamless log data access. Then, a preprocessing chain is implemented, combining regular expressions and the LogCleaner-1B model (based on BERT-Tiny fine-tuning) to filter log noise and increase the proportion of valid log data.

[0094] Semantic parsing and intent recognition are divided into semantic parsing, intent recognition, and multimodal feature extraction operations. The semantic parsing steps are as follows: A LangChain processing chain dynamically loads the model for semantic parsing, using context enhancement to achieve large-scale model parsing, thereby outputting labeled events to improve parsing accuracy and enabling chained execution. Then, the parsing chain is constructed, i.e., a fine-tuned model is built, outputting structured events for subsequent processing and storage. The intent recognition steps are as follows: Combining a rule engine and a large-scale model collaboration strategy, logs are classified to identify the underlying business intent or abnormal patterns, achieving rule matching. Logs that do not match are declared as having intent classification. The multimodal feature extraction steps are as follows: A pre-trained model based on the Transformer architecture is used to capture the semantic features of the log text through word embedding and attention mechanisms, thereby outputting labeled structured data.

[0095] Dynamic keyword modeling involves three steps: keyword library construction, context-aware extraction, and lineage relationship construction. The keyword library construction step filters high-frequency words based on log data statistics and business scenario requirements, customizing the keyword table according to the business scenario. Context-aware extraction uses ConversationalRetrievalChain to achieve cross-log association, concatenating multi-source logs based on timestamps and GlobalIDs to extract key information. The lineage relationship construction step implements a lineage relationship construction layer, using streaming data association and Flink real-time computation to achieve cross-system call chain association based on GlobalIDs, generating unified lineage relationship metadata and a dynamic lineage relationship graph storage. This generates metadata on service call order and link duration, which is stored in the Neo4j graph database.

[0096] This embodiment achieves real-time processing and intelligent analysis of large-scale log data, constructs a dynamic lineage graph, improves fault detection and response speed, reduces maintenance costs, and provides operations and maintenance personnel with intuitive fault location and decision support tools. Simultaneously, the dynamically updated knowledge base and intelligent alarm mechanism ensure that the system can adapt to constantly changing business needs and log patterns, realizing a closed loop of intelligent operations and maintenance and decision-making.

[0097] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0098] Example 2

[0099] This application also provides a log monitoring device. It should be noted that the log monitoring device of this application can be used to execute the log monitoring method provided in this application. The log monitoring device provided in this application is described below.

[0100] According to an embodiment of this application, an apparatus for implementing the above-described log monitoring method is also provided. Figure 7 This is a schematic diagram of a log monitoring device provided according to an embodiment of this application, such as... Figure 7 As shown, the device includes: a first acquisition unit 70, a parsing unit 71, a second acquisition unit 72, and a determination unit 73.

[0101] The first acquisition unit 70 is used to acquire M logs stored in the log source within a preset time period, and to form N closed-loop links based on the M logs, where N is less than M and N and M are positive integers;

[0102] The parsing unit 71 is used to parse the scenario type of each closed loop in the N closed loop links respectively, classify the N closed loop links according to the N scenario types, obtain Y groups of closed loop links, and construct the knowledge graph of the Y groups of closed loop links to obtain Y closed loop link graphs, where Y is a positive integer;

[0103] The second acquisition unit 72 is used to acquire Y historical closed-loop link maps within a historical time period based on Y scene types corresponding to Y closed-loop link maps, compare each historical closed-loop link map with each closed-loop link map, and generate Y comparison results. Each historical closed-loop link map corresponds to a scene type, and the comparison method includes at least log feature comparison of closed-loop links and keyword comparison of closed-loop links.

[0104] The determination unit 73 is used to determine the alarm level based on the Y comparison results, and to determine the link identification alarm information based on the alarm level.

[0105] The log monitoring device provided in this application embodiment acquires M logs stored in a log source within a preset time period through a first acquisition unit 70, and constructs N closed-loop links based on the M logs, where N is less than M and N and M are positive integers; a parsing unit 71 parses the scenario type of each closed-loop link in the N closed-loop links respectively, classifies the N closed-loop links according to the N scenario types, obtains Y groups of closed-loop links, and constructs a knowledge graph of the Y groups of closed-loop links to obtain Y closed-loop link graphs, where Y is a positive integer; a second acquisition unit 72 acquires Y historical closed-loop link graphs within a historical time period according to the Y scenario types corresponding to the Y closed-loop link graphs, compares each historical closed-loop link graph with each closed-loop link graph, and generates Y closed-loop link graphs. The comparison results show that each historical closed-loop link graph corresponds to a scenario type. The comparison method includes at least log feature comparison and keyword comparison of the closed-loop link. The determination unit 73 determines the alarm level based on Y comparison results and determines the link identification alarm information based on the alarm level. This solves the technical problem of low processing efficiency when analyzing and processing logs in related technologies. By constructing a closed-loop link based on multiple logs and building a knowledge graph of the closed-loop link according to the scenario type of the closed-loop link, a closed-loop link graph is obtained. The historical closed-loop link graph is compared with each closed-loop link graph, and the alarm information is determined based on the comparison results. This achieves the technical effect of improving the efficiency of log analysis and processing and the accuracy of fault location.

[0106] Optionally, in the log monitoring device provided in this application embodiment, the first acquisition unit 70 includes: a first acquisition module, used to acquire M log protocols associated with logs respectively, to obtain M log protocols, and the log adapter parses each log according to each log protocol to obtain M log information; a combination module, used to combine the M logs through the M log information to obtain N initial closed-loop links, and use regular expressions to filter noise in the N initial closed-loop links to obtain N first processing links; a second acquisition module, used to acquire a log filtering model, input the N first processing links into the log filtering model, and output N second processing links, wherein the log filtering model includes a regular expression module and a joint filtering module, and the log filtering model is used to intercept abnormal logs in the N first processing links, and the abnormal logs include at least one of the following: format abnormal logs, information missing logs, and empty logs; and a conversion module, used to convert the format of the N second processing links to obtain N third processing links, and determine the N third processing links as N closed-loop links.

[0107] Optionally, in the log monitoring device provided in this application embodiment, the parsing unit 71 includes: a loading module, used to load a language processing model, input N closed-loop links into the language processing model, and output N structured events, wherein the language processing model is used to perform context parsing processing on each closed-loop link, and each structured event is used to indicate the link information of each closed-loop link; a third acquisition module, used to acquire a rule engine, construct a rule matching model based on the rule engine, and perform rule matching on the N closed-loop links based on the N structured events to obtain N rule matching results, wherein the rule matching results include unmatched results and matched results, the unmatched results are used to indicate that the closed-loop link does not match the rules in the rule engine, and the matched results are used to indicate that the closed-loop link matches the rules in the rule engine; and a calling module, used to call a feature extraction model to extract features from the N closed-loop links to obtain N sets of semantic features, and generate N scene types based on the N rule matching results and the N sets of semantic features, wherein the feature extraction model is constructed by a word embedding module and an attention module.

[0108] Optionally, in the log monitoring device provided in this application embodiment, the parsing unit 71 includes: a fourth acquisition module, used to acquire scene keyword rules for a closed-loop link, and construct a keyword filtering model based on the scene keyword rules, wherein the scene keyword rules include multiple scenes and multiple rules corresponding to each scene; a first extraction module, used to extract keywords from a set of semantic features of the closed-loop link using the keyword filtering model when the rule matching result indicates that the closed-loop link has matched the rules in the rule engine, obtain a set of keywords, obtain a target scene based on the set of keywords, and generate a scene type based on the target scene; and an inference module, used to infer the closed-loop link through the log inference model when the rule matching result indicates that the closed-loop link has not matched the rules in the rule engine, and generate a scene type associated with the closed-loop link.

[0109] Optionally, in the log monitoring device provided in this application embodiment, the parsing unit 71 includes: a receiving module, used to receive business requirements and determine a chain processing model through the business requirements, wherein the business requirements include at least relationship requirements and numerical requirements; and a construction module, used to construct the lineage relationship of Y groups of closed-loop links from the chain processing model to obtain Y closed-loop link maps.

[0110] Optionally, in the log monitoring device provided in this application embodiment, the parsing unit 71 includes: a second extraction module, used to extract software corresponding to a preset protocol from the log information associated with each closed-loop link in a set of closed-loop links, under the condition of business requirement characterizing the association relationship requirement, to obtain software information of K software, where K is a positive integer; a first determination module, used to determine the K software information as service nodes, and construct a knowledge graph based on the service nodes to obtain a first knowledge graph; a third extraction module, used to extract software metadata of K software from the log information associated with each closed-loop link, and fill the software metadata of K software into the first knowledge graph to obtain a second knowledge graph; and a fifth acquisition module, used to acquire preset dimension labels, and perform dimension segmentation on the second knowledge graph based on the preset dimension labels to obtain a closed-loop link graph associated with a set of closed-loop links, wherein the preset dimension labels are used to indicate the business type of the closed-loop link graph.

[0111] Optionally, in the log monitoring device provided in this application embodiment, the parsing unit 71 includes: a fourth extraction module, used to extract aviation messages from the log information associated with each closed-loop link in a set of closed-loop links, under the condition that the business demand represents the digital demand, and to encode and convert the fields of a preset type in the aviation messages to obtain G field vectors, where G is a positive integer; a second determination module, used to determine the G field vectors as service nodes, construct a knowledge graph based on the service nodes to obtain a third knowledge graph, and fill the aviation data associated with the aviation messages into the third knowledge graph to obtain a fourth knowledge graph; and a sixth acquisition module, used to acquire historical flight data, aggregate the historical flight data into the fourth knowledge graph, and a closed-loop link graph associated with a set of closed-loop links.

[0112] It should be noted that the first acquisition unit 70, the parsing unit 71, the second acquisition unit 72, and the determining unit 73 mentioned above correspond to steps S201 to S204 in Embodiment 1. The instances and application scenarios implemented by the above units and the corresponding steps are the same, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above units can also be part of a device and can run in the computer terminal 10 provided in Embodiment 1.

[0113] Example 3

[0114] Embodiments of this application may provide a computer terminal, which may be any computer terminal device in a group of computer terminals. Optionally, in this embodiment, the aforementioned computer terminal may also be replaced with a mobile terminal or an electronic device, etc.

[0115] Optionally, in this embodiment, the computer terminal may be located in at least one of a plurality of network devices in a computer network.

[0116] In this embodiment, the computer terminal described above can execute the following steps of the log monitoring method: acquiring M logs stored in the log source within a preset time period, constructing N closed-loop links based on the M logs, where N is less than M, and N and M are positive integers; parsing the scenario type of each of the N closed-loop links, classifying the N closed-loop links according to the N scenario types to obtain Y groups of closed-loop links, and constructing a knowledge graph of the Y groups of closed-loop links to obtain Y closed-loop link graphs, where Y is a positive integer; acquiring Y historical closed-loop link graphs within a historical time period based on the Y scenario types corresponding to the Y closed-loop link graphs, comparing each historical closed-loop link graph with each closed-loop link graph to generate Y comparison results, where each historical closed-loop link graph corresponds to a scenario type, and the comparison method includes at least log feature comparison and keyword comparison of the closed-loop links; determining the alarm level based on the Y comparison results, and determining link identification alarm information based on the alarm level.

[0117] Optionally, the computer terminal described above can execute the following steps in the log monitoring method: obtain M log protocols associated with each log, resulting in M ​​log protocols; have the log adapter parse each log according to each log protocol to obtain M log information; combine the M log information to obtain N initial closed-loop links, and use regular expressions to filter noise in the N initial closed-loop links to obtain N first processing links; obtain a log filtering model, input the N first processing links into the log filtering model, and output N second processing links, wherein the log filtering model includes a regular expression module and a joint filtering module, and the log filtering model is used to intercept abnormal logs in the N first processing links, the abnormal logs including at least one of the following: format-abnormal logs, information-missing logs, and empty logs; convert the format of the N second processing links to obtain N third processing links, and determine the N third processing links as N closed-loop links.

[0118] Optionally, the aforementioned computer terminal can execute the following steps in the log monitoring method: Loading a language processing model, inputting N closed-loop links into the language processing model, and outputting N structured events, wherein the language processing model is used to perform context parsing processing on each closed-loop link, and each structured event is used to indicate the link information of each closed-loop link; Obtaining a rule engine, constructing a rule matching model based on the rule engine, and having the rule matching model perform rule matching on the N closed-loop links based on the N structured events to obtain N rule matching results, wherein the rule matching results include unmatched results and matched results, where unmatched results indicate that the closed-loop link does not match the rules in the rule engine, and matched results indicate that the closed-loop link matches the rules in the rule engine; Calling a feature extraction model to extract features from the N closed-loop links to obtain N sets of semantic features, and generating N scene types based on the N rule matching results and the N sets of semantic features, wherein the feature extraction model is constructed by a word embedding module and an attention module.

[0119] Optionally, the aforementioned computer terminal may execute the following steps in the log monitoring method: For a closed-loop link, obtain scenario keyword rules, construct a keyword filtering model based on the scenario keyword rules, wherein the scenario keyword rules include multiple scenarios and multiple rules corresponding to each scenario; when the rule matching result indicates that the closed-loop link has matched the rules in the rule engine, use the keyword filtering model to extract keywords from a set of semantic features of the closed-loop link to obtain a set of keywords, and obtain the target scenario based on the set of keywords, and generate a scenario type based on the target scenario; when the rule matching result indicates that the closed-loop link has not matched the rules in the rule engine, infer the closed-loop link through the log inference model to generate the scenario type associated with the closed-loop link.

[0120] Optionally, the computer terminal described above can execute the program code for the following steps in the log monitoring method: receiving business requirements, determining a chain processing model based on the business requirements, wherein the business requirements include at least relational requirements and numerical requirements; constructing the lineage relationship of Y groups of closed-loop links from the chain processing model to obtain Y closed-loop link maps.

[0121] Optionally, the aforementioned computer terminal can execute the program code for the following steps in the log monitoring method: For a set of closed-loop links, under the condition that the business requirements represent the correlation requirements, extract the software corresponding to the preset protocol from the log information associated with each closed-loop link in the set of closed-loop links to obtain the software information of K software, where K is a positive integer; determine the K software information as service nodes, and construct a knowledge graph based on the service nodes to obtain a first knowledge graph; extract the software metadata of K software from the log information associated with each closed-loop link, and fill the software metadata of K software into the first knowledge graph to obtain a second knowledge graph; obtain preset dimension labels, and perform dimensional segmentation on the second knowledge graph based on the preset dimension labels to obtain a closed-loop link graph associated with a set of closed-loop links, wherein the preset dimension labels are used to indicate the business type of the closed-loop link graph.

[0122] Optionally, the aforementioned computer terminal can execute the following steps in the log monitoring method: For a set of closed-loop links, under the condition that business requirements represent digital requirements, extract aviation messages from the log information associated with each closed-loop link in the set of closed-loop links, and encode and convert the fields of the preset type in the aviation messages to obtain G field vectors, where G is a positive integer; determine the G field vectors as service nodes, construct a knowledge graph based on the service nodes to obtain a third knowledge graph, and fill the aviation data associated with the aviation messages into the third knowledge graph to obtain a fourth knowledge graph; obtain historical flight data, aggregate the historical flight data into the fourth knowledge graph, and obtain a closed-loop link graph associated with a set of closed-loop links.

[0123] Optionally, Figure 8 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 8 As shown, the electronic device may include: one or more ( Figure 8 Only one of the components is shown: processor 802, memory 804, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module, and display.

[0124] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the log monitoring method and apparatus in this application embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned log monitoring method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0125] The processor can access the information and application programs stored in the memory via the transmission device to execute the steps described above in the log monitoring method.

[0126] This application provides a log monitoring solution. By constructing a closed-loop link based on multiple logs, and building a knowledge graph of the closed-loop link according to the scenario type, a closed-loop link graph is obtained. The historical closed-loop link graph is compared with each closed-loop link graph, and alarm information is determined based on the comparison results. This achieves the technical effect of improving the efficiency of log analysis and processing and the accuracy of fault location.

[0127] Those skilled in the art will understand that Figure 8 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 8 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 8 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 8 The different configurations shown.

[0128] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0129] Example 4

[0130] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the log monitoring method provided in Embodiment 1.

[0131] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0132] Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: obtaining M logs stored in the log source within a preset time period, constructing N closed-loop links based on the M logs, where N is less than M, and N and M are positive integers; parsing the scenario type of each closed-loop link in the N closed-loop links respectively, classifying the N closed-loop links according to the N scenario types to obtain Y groups of closed-loop links, and constructing a knowledge graph of the Y groups of closed-loop links to obtain Y closed-loop link graphs, where Y is a positive integer; obtaining Y historical closed-loop link graphs within a historical time period according to the Y scenario types corresponding to the Y closed-loop link graphs, comparing each historical closed-loop link graph with each closed-loop link graph to generate Y comparison results, where each historical closed-loop link graph corresponds to a scenario type, and the comparison method includes at least log feature comparison and keyword comparison of the closed-loop links; determining the alarm level based on the Y comparison results, and determining link identification alarm information based on the alarm level.

[0133] This application also provides a computer program product, which, when executed on a data processing device, is suitable for performing log monitoring method steps.

[0134] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0135] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0136] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of units or modules may be electrical or other forms.

[0137] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0138] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0139] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0140] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for monitoring logs, characterized in that, include: Get M logs stored in the log source within a preset time period, and construct N closed-loop links based on the M logs, where N is less than M and N and M are positive integers; The scenario type of each of the N closed-loop links is analyzed, and the N closed-loop links are classified according to the N scenario types to obtain Y groups of closed-loop links. A knowledge graph of the Y groups of closed-loop links is constructed to obtain Y closed-loop link graphs, where Y is a positive integer. Based on the Y scene types corresponding to the Y closed-loop link maps, obtain Y historical closed-loop link maps within a historical time period. Compare each historical closed-loop link map with each closed-loop link map to generate Y comparison results. Each historical closed-loop link map corresponds to a scene type. The comparison method includes at least log feature comparison of the closed-loop link and keyword comparison of the closed-loop link. The alarm level is determined based on the Y comparison results, and the link identification alarm information is determined based on the alarm level.

2. The method according to claim 1, characterized in that, Based on the M logs, N closed-loop links are constructed, including: The log protocols associated with the M logs are obtained respectively, resulting in M ​​log protocols. The log adapter then parses each log according to each log protocol to obtain M log information. The M logs are combined to obtain N initial closed-loop links, and regular expressions are used to filter noise from the N initial closed-loop links to obtain N first processing links. Obtain a log filtering model, input the N first processing links into the log filtering model, and output N second processing links. The log filtering model includes a regular expression module and a joint filtering module. The log filtering model is used to intercept abnormal logs in the N first processing links. Abnormal logs include at least one of the following: format abnormal logs, missing information logs, and empty logs. The N second processing links are format-converted to obtain N third processing links, and the N third processing links are determined as the N closed-loop links.

3. The method according to claim 1, characterized in that, The scenario types for each of the N closed-loop links are analyzed separately, including: Load the language processing model, input the N closed-loop links into the language processing model, and output N structured events. The language processing model is used to perform context parsing processing on each closed-loop link, and each structured event is used to indicate the link information of each closed-loop link. Obtain a rule engine, construct a rule matching model based on the rule engine, and perform rule matching on the N closed-loop links based on the N structured events using the rule matching model to obtain N rule matching results. The rule matching results include unmatched results and matched results. The unmatched results are used to indicate that the closed-loop link does not match the rules in the rule engine, and the matched results are used to indicate that the closed-loop link matches the rules in the rule engine. The feature extraction model is invoked to extract features from the N closed-loop links to obtain N sets of semantic features. Based on the N rule matching results and the N sets of semantic features, the N scene types are generated. The feature extraction model is constructed by a word embedding module and an attention module.

4. The method according to claim 3, characterized in that, The N scene types generated based on the N rule matching results and the N sets of semantic features include: For a closed-loop link, obtain the scenario keyword rules, and construct a keyword filtering model based on the scenario keyword rules. The scenario keyword rules include multiple scenarios and multiple rules corresponding to each scenario. When the rule matching result indicates that the closed-loop link has matched the rule in the rule engine, the keyword filtering model is used to extract keywords from a set of semantic features of the closed-loop link to obtain a set of keywords, and the target scene is obtained by matching the set of keywords, and the scene type is generated based on the target scene; If the rule matching result indicates that the closed-loop link does not match the rule in the rule engine, the closed-loop link is inferred through the log inference model to generate the scenario type associated with the closed-loop link.

5. The method according to claim 1, characterized in that, Constructing the knowledge graph of the Y groups of closed-loop links yields Y closed-loop link graphs, including: Receive business requirements, determine a chain-like processing model based on the business requirements, wherein the business requirements include at least relationship requirements and numerical requirements; The lineage relationship of the Y groups of closed-loop links is constructed using the chain processing model, resulting in the Y closed-loop link maps.

6. The method according to claim 5, characterized in that, The lineage relationship of the Y groups of closed-loop links is constructed using the chain processing model, resulting in the following Y closed-loop link maps: For a set of closed-loop links, when the business requirement represents the association requirement, the software corresponding to the preset protocol is extracted from the log information associated with each closed-loop link in the set of closed-loop links to obtain the software information of K software, where K is a positive integer; K pieces of software information are identified as service nodes, and a knowledge graph is constructed based on the service nodes to obtain the first knowledge graph; Extract the software metadata of the K software from the log information associated with each closed-loop link, and populate the software metadata of the K software into the first knowledge graph to obtain the second knowledge graph; Obtain preset dimension labels, and perform dimensional segmentation on the second knowledge graph based on the preset dimension labels to obtain the closed-loop link graph associated with the set of closed-loop links, wherein the preset dimension labels are used to indicate the business type of the closed-loop link graph.

7. The method according to claim 5, characterized in that, The lineage relationship of the Y groups of closed-loop links is constructed using the chain processing model, resulting in the following Y closed-loop link maps: For a set of closed-loop links, when the business requirement represents the digital requirement, aviation messages are extracted from the log information associated with each closed-loop link in the set of closed-loop links, and the fields of the preset type in the aviation messages are encoded and converted to obtain G field vectors, where G is a positive integer; The G field vectors are determined as service nodes, a knowledge graph is constructed based on the service nodes to obtain a third knowledge graph, and the aviation data associated with the aviation message is filled into the third knowledge graph to obtain a fourth knowledge graph; Historical flight data is acquired and aggregated into the fourth knowledge graph, which is a closed-loop link graph associated with a set of closed-loop links.

8. A log monitoring device, characterized in that, include: The first acquisition unit is used to acquire M logs stored in the log source within a preset time period, and to form N closed-loop links based on the M logs, where N is less than M and N and M are positive integers; The parsing unit is used to parse the scenario type of each closed loop in the N closed loop links respectively, classify the N closed loop links according to the N scenario types to obtain Y groups of closed loop links, and construct the knowledge graph of the Y groups of closed loop links to obtain Y closed loop link graphs, where Y is a positive integer; The second acquisition unit is used to acquire Y historical closed-loop link maps within a historical time period according to the Y scene types corresponding to the Y closed-loop link maps, compare each historical closed-loop link map with each closed-loop link map, and generate Y comparison results. Each historical closed-loop link map corresponds to a scene type, and the comparison method includes at least log feature comparison of the closed-loop link and keyword comparison of the closed-loop link. The determining unit is used to determine the alarm level based on the Y comparison results, and to determine the link identification alarm information based on the alarm level.

9. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, executes the log monitoring method according to any one of claims 1 to 7.

10. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the steps of the log monitoring method according to any one of claims 1 to 7.

Images