OS running log processing method and system based on AI large model, terminal and storage medium

Abstract

The invention discloses an OS operation log processing method and system based on an AI large model, a terminal and a storage medium, and the method comprises the steps: collecting system logs and business logs of a plurality of target devices in an OS cluster, and uploading the system logs and the business logs of OS operation to a cloud side server through a log search engine; according to the system log and the business log, marking the content meaning of each segment of log, and combining a trained fault analysis model to infer a fault which has occurred, and positioning a fault reason to obtain a fault analysis positioning report; and according to the fault type and the fault reason in the fault analysis positioning report, informing related maintenance personnel, and automatically collecting feedback information of the related maintenance personnel. According to the invention, the AI large model is utilized to process the OS running log, and the intelligent operation and maintenance system based on the AI large model is provided, so that the investment demand on manpower in the whole operation and maintenance process is greatly reduced, and meanwhile, the technical threshold of manual participation is also greatly reduced.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an OS runtime log processing method, system, terminal, and computer-readable storage medium based on an AI large model. Background Technology

[0002] For fault analysis and maintenance (restoration) during OS operation (the running process of the operating system), the current operation and maintenance system includes the following key steps: collecting system operation logs (manually or automatically); analyzing the logs using certain automated methods; and manually locating and restoring faults by combining the log content with the OS's business logic.

[0003] Currently, the biggest drawback of operations and maintenance (O&M) systems is the need for deep human involvement, whether it's locating faults or restoring the system to normal operation. Furthermore, O&M experience is often concentrated in specific individuals, making it a technically demanding human resource requirement. This, coupled with personnel turnover, introduces significant uncertainty into high-quality O&M.

[0004] Therefore, existing technologies still need to be improved and developed. Summary of the Invention

[0005] The main objective of this invention is to provide an OS operation log processing method, system, terminal, and computer-readable storage medium based on an AI large model. This aims to solve the problem that in the existing technology, operation and maintenance systems require deep human intervention and are highly dependent on specific personnel when locating faults and restoring the system to normal operation, which causes great uncertainty to high-quality operation and maintenance.

[0006] To achieve the above objectives, the present invention provides an OS runtime log processing method based on an AI large-scale model, the OS runtime log processing method based on an AI large-scale model comprising the following steps: The log search engine receives instructions from the natural language analysis module based on the AI ​​big model, collects system logs and business logs from multiple target devices in the OS cluster, and uploads the OS's system logs and business logs to the cloud server through the log search engine. The AI-based big data natural language analysis module annotates the meaning of each log segment according to the system log and the business log, combines the trained fault analysis model to infer the fault that has occurred, locate the cause of the fault, obtain a fault analysis and location report, and sends it to the AI-based big data fault reasoning and diagnosis module. The fault reasoning and diagnosis module based on the AI ​​big model notifies the relevant maintenance personnel based on the fault type and cause in the fault analysis and location report, automatically collects feedback information from the relevant maintenance personnel, and inputs the feedback information into the natural language analysis module based on the AI ​​big model.

[0007] Optionally, the OS runtime log processing method based on an AI large model, wherein the log search engine receives instructions from the natural language analysis module based on the AI ​​large model, collects system logs and business logs from multiple target devices in the OS cluster, and uploads the OS runtime system logs and business logs to the cloud-side server through the log search engine, further includes: Each target device in the OS cluster is assigned a unique SN number in advance, and the system logs and business logs corresponding to each target device are marked with the SN number.

[0008] Optionally, in the OS runtime log processing method based on the AI ​​large model, both the system log and the business log include a file header and file content; the file header includes: SN number, timestamp of log occurrence, process ID of the business, thread ID of the business, log level, key code identifier, and log content.

[0009] Optionally, the OS runtime log processing method based on an AI large model, wherein the log search engine receives instructions from the natural language analysis module based on the AI ​​large model, collects system logs and business logs from multiple target devices in the OS cluster, and uploads the OS runtime system logs and business logs to the cloud-side server through the log search engine, specifically including: The log search engine receives log collection instructions from the natural language analysis module based on an AI large model in the cloud server, parses the log collection instructions, and determines the target device identifier, log type, time range, and filter keywords to be collected. Based on the parsing results, the log search engine initiates log collection requests to the corresponding target devices in the OS cluster, and receives system logs and business logs from each target device in real time or in batches according to a predetermined period. The log search engine performs standardized preprocessing on the collected system logs and business logs. The standardized preprocessing includes at least format unification, timestamp synchronization, and invalid data filtering. The log search engine compresses and encrypts the preprocessed system logs and business logs, and uploads the compressed and encrypted system logs and business logs to the AI-based big data natural language analysis module on the cloud server through a secure transmission protocol.

[0010] Optionally, in the OS operation log processing method based on AI large model, the fault analysis and location report includes fault type, fault cause, device where the fault occurred, and judgment basis.

[0011] Optionally, the OS runtime log processing method based on the AI ​​large model, wherein the natural language analysis module based on the AI ​​large model annotates the meaning of each log segment according to the system log and the business log, combines the trained fault analysis model to infer the fault that has occurred, locate the cause of the fault, obtain a fault analysis and location report, and sends it to the fault reasoning and diagnosis module based on the AI ​​large model, specifically includes: The AI-based natural language analysis module inputs the system logs and business logs into the trained fault analysis model, uses the fault analysis model to understand the semantics of the log text, and automatically generates one or more tags describing the meaning of each log segment. The AI-based natural language analysis module aggregates log sequences labeled with content meaning according to time order and correlation to form event chains. It then matches these event chains with fault patterns in the knowledge base. Based on the fault analysis model, it performs causal reasoning on the successfully matched event chains to identify the log events that are the root cause and outputs a diagnostic conclusion that includes the fault type, fault cause, the device that experienced the fault, and the basis for judgment. The AI-based big data natural language analysis module integrates the diagnostic conclusions, relevant key log fragments and their meaning annotations, and event chain visualization information to generate a structured fault analysis and location report. The fault analysis and location report is then pushed to the AI-based big data fault reasoning and diagnosis module via a message queue or remote procedure call interface.

[0012] Optionally, in the OS runtime log processing method based on AI large model, the tags include at least one or more of the following: log level, service module, operation type, and event type.

[0013] Optionally, the OS runtime log processing method based on the AI ​​big data model, wherein the fault reasoning and diagnosis module based on the AI ​​big data model notifies relevant maintenance personnel according to the fault type and fault cause in the fault analysis and location report, automatically collects feedback information from relevant maintenance personnel, and inputs the feedback information into the natural language analysis module based on the AI ​​big data model, specifically including: The fault reasoning and diagnosis module based on the AI ​​big model parses the fault analysis and location report, extracts the fault type and fault cause from the fault analysis and location report, determines the relevant maintenance personnel who need to be notified according to preset rules, and sends a notification message to the relevant maintenance personnel through email, instant messaging tools or operation and maintenance alarm platform. The message contains at least the fault type, fault cause and report link. The fault reasoning and diagnosis module based on the AI ​​big model provides an interactive feedback interface to the relevant maintenance personnel while sending the notification. The interactive feedback interface collects the relevant maintenance personnel's confirmation information on the fault analysis, supplementary explanations, records of handling measures, or opinions on correcting the analysis results. The fault reasoning and diagnosis module based on the AI ​​large model performs structured processing on the collected feedback information, associates the processed feedback information with the corresponding original fault analysis and location report, and stores it as labeled training data. The stored feedback data is used periodically to incrementally train or fine-tune the natural language analysis module based on the AI ​​large model and / or the trained fault analysis model to optimize the analysis and reasoning capabilities.

[0014] Optionally, in the aforementioned OS runtime log processing method based on an AI large-scale model, the fault reasoning and diagnosis module based on the AI ​​large-scale model notifies relevant maintenance personnel based on the fault type and cause in the fault analysis and location report, and further includes: The fault reasoning and diagnosis module based on the AI ​​large model determines whether it is necessary to notify the relevant maintenance personnel based on the fault analysis and location report.

[0015] Optionally, the OS runtime log processing method based on the AI ​​large model, wherein the fault reasoning and diagnosis module based on the AI ​​large model determines whether to notify the relevant maintenance personnel based on the fault analysis and location report, further includes: If the fault reasoning and diagnosis module based on the AI ​​big model determines, based on the fault analysis and location report, that it is not necessary to notify the relevant maintenance personnel, then the fault reasoning and diagnosis module based on the AI ​​big model will directly feed back to the natural language analysis module based on the AI ​​big model for autonomous maintenance.

[0016] Optionally, the OS runtime log processing method based on AI large model, wherein the step of uploading the OS runtime system logs and business logs to the cloud-side server through a log search engine, further includes: At the edge or on the device itself, a lightweight AI model is used to perform preliminary analysis and filtering of the system logs and the business logs; The relevant critical logs and context are only uploaded to the cloud server when a potential anomaly is identified or a specific trigger condition is met; otherwise, they are archived or discarded locally.

[0017] Optionally, the OS runtime log processing method based on the AI ​​large model further includes: When the fault cause located by the fault reasoning and diagnosis module based on the AI ​​large model belongs to a known type that allows for automatic repair, an automated repair script is generated. After authorization is obtained, the automated repair script is sent to and executed on the target device through the log search engine.

[0018] Optionally, in the OS runtime log processing method based on AI large model, the target devices in the OS cluster include cloud-connectable devices and non-cloud-connectable devices.

[0019] Optionally, the OS runtime log processing method based on the AI ​​large model further includes: When the target device is a cloud-connectable device, the system logs and business logs of the cloud-connectable device are directly transmitted to the cloud-side server through the log search engine. When the target device is a device that cannot be directly connected to the cloud, the system logs and business logs of the device that cannot be directly connected to the cloud are first transmitted to the device that can be connected to the cloud through the log collection engine, and then transmitted to the cloud-side server through the log collection engine.

[0020] Furthermore, to achieve the above objectives, the present invention also provides an OS runtime log processing system based on an AI large-scale model, wherein the OS runtime log processing system based on the AI ​​large-scale model includes: The log search engine receives instructions from the natural language analysis module based on the AI ​​large model, collects system logs and business logs from multiple target devices in the OS cluster, and uploads the OS's system logs and business logs to the cloud server through the log search engine. The AI-based large-scale natural language analysis module is used to annotate the meaning of each log segment based on the system log and the business log, combine the trained fault analysis model to infer the faults that have occurred, locate the cause of the fault, obtain a fault analysis and location report, and send it to the AI-based large-scale fault reasoning and diagnosis module. The fault reasoning and diagnosis module based on the AI ​​big model is used to notify relevant maintenance personnel based on the fault type and fault cause in the fault analysis and location report, automatically collect feedback information from relevant maintenance personnel, and input the feedback information into the natural language analysis module based on the AI ​​big model.

[0021] Optionally, in the aforementioned OS runtime log processing system based on an AI large model, the log search engine includes: The instruction receiving unit is used to receive log collection instructions from the natural language analysis module based on the AI ​​large model in the cloud server, parse the log collection instructions, and determine the target device identifier, log type, time range, and filter keywords to be collected. The log collection unit is used to initiate log collection requests to the corresponding target devices in the OS cluster based on the parsing results, and to receive system logs and business logs from each target device in real time or in batches according to a predetermined period. The log preprocessing unit is used to perform standardized preprocessing on the collected system logs and business logs. The standardized preprocessing includes at least format unification, timestamp synchronization, and invalid data filtering. The log transmission unit is used to compress and encrypt the preprocessed system logs and business logs, and upload the compressed and encrypted system logs and business logs to the AI-based big model-based natural language analysis module on the cloud server through a secure transmission protocol.

[0022] Optionally, in the aforementioned OS runtime log processing system based on an AI large model, the natural language analysis module based on the AI ​​large model includes: The log parsing unit is used to input the system logs and the business logs into the trained fault analysis model, use the fault analysis model to understand the semantics of the log text, and automatically generate one or more tags describing the meaning of each log segment. The cause matching unit is used to aggregate log sequences labeled with content meanings according to time order and correlation to form an event chain, match the event chain with the fault modes in the knowledge base, perform causal reasoning on the successfully matched event chains based on the fault analysis model, identify the log events of the root cause, and output a diagnostic conclusion including fault type, fault cause, device of occurrence, and judgment basis. The report generation unit is used to integrate the diagnostic conclusions, relevant key log fragments and their meaning annotations, and event chain visualization information to generate a structured fault analysis and location report. The fault analysis and location report is then pushed to the fault reasoning and diagnosis module based on the AI ​​big model via a message queue or remote procedure call interface.

[0023] Optionally, in the aforementioned OS runtime log processing system based on an AI large model, the fault reasoning and diagnosis module based on the AI ​​large model includes: The maintenance notification unit is used to parse the fault analysis and location report, extract the fault type and fault cause from the fault analysis and location report, determine the relevant maintenance personnel who need to be notified according to preset rules, and send a notification message to the relevant maintenance personnel via email, instant messaging tools or operation and maintenance alarm platform. The message contains at least the fault type, fault cause and report link. The feedback receiving unit is used to provide an interactive feedback interface to the relevant maintenance personnel while sending a notification. The interactive feedback interface is used to collect the relevant maintenance personnel's confirmation information on the fault analysis, supplementary explanations, records of handling measures, or opinions on the correction of the analysis results. The optimization learning unit is used to perform structured processing on the collected feedback information, associate the processed feedback information with the corresponding original fault analysis and location report, and store it as labeled training data. The stored feedback data is used periodically to incrementally train or fine-tune the AI-based natural language analysis module and / or the trained fault analysis model to optimize the analysis and reasoning capabilities.

[0024] Furthermore, to achieve the above objectives, the present invention also provides a terminal, wherein the terminal includes: a memory, a processor, and an OS runtime log processing program based on an AI large model stored in the memory and executable on the processor, wherein when the OS runtime log processing program based on an AI large model is executed by the processor, it implements the steps of the OS runtime log processing method based on an AI large model as described above.

[0025] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores an OS runtime log processing program based on an AI large model, and when the OS runtime log processing program based on the AI ​​large model is executed by a processor, it implements the steps of the OS runtime log processing method based on the AI ​​large model as described above.

[0026] In this invention, a log search engine receives instructions from a natural language processing module based on an AI-powered big data model. It collects system and business logs from multiple target devices within an OS cluster and uploads these logs to a cloud server. The AI-powered big data model-based natural language processing module annotates the meaning of each log segment based on the system and business logs, uses a trained fault analysis model to infer the occurrence of faults, locates the cause of the fault, generates a fault analysis and location report, and sends it to the AI-powered big data model-based fault reasoning and diagnosis module. The AI-powered big data model-based fault reasoning and diagnosis module notifies relevant maintenance personnel based on the fault type and cause in the fault analysis and location report, automatically collects feedback from these personnel, and inputs this feedback into the AI-powered big data model-based natural language processing module. This invention utilizes an AI-powered big data model to process OS operation logs, proposing an intelligent operation and maintenance system based on an AI-powered big data model. This significantly reduces the manpower required throughout the operation and maintenance process and also greatly lowers the technical barrier to manual intervention. Attached Figure Description

[0027] Figure 1 This is a flowchart of a preferred embodiment of the OS runtime log processing method based on an AI large model of the present invention; Figure 2 This is a schematic diagram of the intelligent operation and maintenance process in a preferred embodiment of the OS operation log processing method based on AI large model of the present invention; Figure 3 This is a schematic diagram illustrating the interaction between the log analysis AI agent and the fault decision AI agent in a preferred embodiment of the OS runtime log processing method based on the AI ​​large model of the present invention. Figure 4 This is a flowchart illustrating the specific implementation process of step S10 in a preferred embodiment of the OS runtime log processing method based on an AI large model of the present invention. Figure 5 This is a flowchart illustrating the specific implementation process of step S20 in a preferred embodiment of the OS runtime log processing method based on an AI large model of the present invention. Figure 6 This is a flowchart illustrating the specific implementation process of step S30 in a preferred embodiment of the OS runtime log processing method based on an AI large model of the present invention. Figure 7 This is a flowchart in a preferred embodiment of the OS runtime log processing method based on an AI large model of the present invention, which determines whether it is necessary to notify the relevant maintenance personnel; Figure 8 This is a flowchart illustrating the pre-upload processing of logs in a preferred embodiment of the OS runtime log processing method based on an AI large model of the present invention. Figure 9This is a flowchart of automatic fault repair in a preferred embodiment of the OS runtime log processing method based on AI large model of the present invention; Figure 10 This is a flowchart of log transmission for two target devices in a preferred embodiment of the OS runtime log processing method based on AI large model of the present invention; Figure 11 This is a flowchart of dynamic baseline early warning in a preferred embodiment of the OS runtime log processing method based on AI large model of the present invention; Figure 12 This is a flowchart of intelligent decision support in a preferred embodiment of the OS runtime log processing method based on AI large model of the present invention; Figure 13 This is a schematic diagram of the OS runtime log processing system based on an AI large model according to the present invention; Figure 14 This is another schematic diagram of the OS runtime log processing system based on the AI ​​large model of the present invention; Figure 15 This is a structural diagram of a preferred embodiment of the terminal of the present invention. Detailed Implementation

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

[0029] As enterprises deepen their digital transformation, data centers and distributed operating system (OS) clusters are growing in scale and becoming increasingly complex. In this environment, numerous target devices, including servers, virtual machines, and containers, generate massive amounts of system and business logs during operation. These logs are the core carriers of system health status, user operations, abnormal events, and business processes, and are invaluable for ensuring system stability and quickly locating faults.

[0030] Currently, the industry generally adopts two main technical approaches for analyzing and processing OS runtime logs. The first approach is based on traditional keyword matching and rule engines. Operations personnel predefine a series of error keywords or regular expression rules, which are then filtered and alerted using log collection tools (such as Elasticsearch, Logstash, Kibana stack, etc.). However, this method heavily relies on the prior knowledge of operations personnel and struggles to handle unknown and complex failure modes. When a failure is triggered by multiple seemingly unrelated log events, systems based on simple rules cannot perform effective causal correlation and reasoning, leading to high false negative or false positive rates.

[0031] The second category is based on earlier machine learning models. These methods detect anomalies in logs by constructing statistical or simple classification models. While they can identify anomalies that deviate from the baseline to some extent, their analytical capabilities are significantly limited: First, these models are often considered "black boxes," and their outputs (such as an anomaly score) lack interpretability. Operations personnel struggle to understand the underlying reasoning logic and cannot directly obtain clear answers to "what failure occurred" and "why it occurred." Second, they lack the ability to understand the deep semantics of log text. Log information is essentially semi-structured or unstructured natural language text; the same failure may have multiple different expressions, and traditional machine learning models struggle to exhaustively and effectively understand these complex semantic variations.

[0032] In recent years, large-scale artificial intelligence (AI) language models have demonstrated remarkable capabilities in natural language understanding, offering potential solutions to the aforementioned problems. However, simply applying large models to log analysis still faces challenges: on the one hand, log data has strong domain-specific characteristics, containing numerous abbreviations, codes, and specific terms, making it difficult to guarantee the accuracy of general-purpose pre-trained large models without domain adaptation; on the other hand, current technologies have not yet effectively integrated the semantic understanding capabilities of large models with fault diagnosis knowledge and actual handling procedures in the operations and maintenance field into an organic, automated closed-loop system. From log collection, semantic analysis, fault reasoning to diagnostic feedback, each stage is often fragmented, preventing the analysis results from being effectively transformed into precise handling actions and knowledge accumulation.

[0033] Therefore, there is an urgent need in this field for an OS operation log processing method that can deeply integrate the capabilities of large AI models to achieve full automation and intelligence from log understanding and intelligent reasoning to diagnostic feedback, in order to overcome the shortcomings of existing technologies and improve operation and maintenance efficiency and system reliability.

[0034] The preferred embodiment of the OS runtime log processing method based on AI large model described in this invention, such as... Figure 1 , Figure 2 and Figure 3 As shown, the OS runtime log processing method based on the AI ​​large model includes the following steps: Step S10: The log search engine receives instructions from the natural language analysis module based on the AI ​​big model, collects system logs and business logs from multiple target devices in the OS cluster, and uploads the OS's system logs and business logs to the cloud server through the log search engine.

[0035] Specifically, in an AI-based intelligent operations and maintenance system, the log search engine plays the role of both a "sensory organ" and a "neural network terminal." It is not merely a simple log collection tool, but rather the data foundation and triggering engine for the entire intelligent analysis process. The main functions of the log search engine are: Receiving and parsing intelligent instructions: Receiving natural language instructions from the upper-level AI module and understanding their intent.

[0036] Distributed collection: Collect system logs and business logs from target devices located in various places according to instructions.

[0037] Preprocessing and standardization: Cleaning and organizing the messy raw logs to make them easier for AI to understand.

[0038] Secure and efficient transmission: Reliably upload the processed log data to the cloud-based analytics platform.

[0039] Before executing step S10, each target device in the OS cluster is pre-assigned a unique serial number (SN), and the corresponding system log and business log for each target device are marked with the SN. When a device is manufactured, stored, or added to the cluster for the first time, the management system assigns it a globally unique serial number. This SN is typically written to the device's firmware (such as BIOS), hardware information file, or a protected configuration file. The cluster management system maintains a registry of "device-SN". Upon startup, the log collection agent running on each target device first reads the device's unique serial number (SN). After collecting each log entry (whether system or business log), before sending it out, the agent automatically injects a fixed field into the log data packet, with the key-value pair being "sn": "device's unique serial number". This injection process is mandatory and automated, independent of the application's own log output. This facilitates subsequent analysis of a fault mode, allowing for precise tracing of which device(s) experienced the problem. For example, AI analysis might identify a fault chain related to "disk read / write errors." Without the SN, the report might simply state "a server in the cluster experienced a disk failure," requiring manual troubleshooting by operations personnel. With the SN, the fault report can clearly state: "The server with SN XYZ-123-ABC experienced a disk failure," allowing operations personnel to take immediate action. Furthermore, when querying all logs from a specific device over the past week, quick filtering by SN is possible, significantly improving the query efficiency of the log search engine. Similarly, when training AI models, log sequences can be easily extracted by device to construct training samples.

[0040] Both the system log and the business log include a file header and file content. The file header includes: SN number, timestamp of the log occurrence, process ID of the business, thread ID of the business, log level, critical code identifier, and log content. For example, the log format is: File header section: sntimestamppid tidLevel TagContent.

[0041] Document content section: sn:d601034133126ee02b00 01-09-10:01:49.389 766 1180 Info C05a01 / PermissionManager [AddDefPermissions:119]permFilterList size: 0 .

[0042] Where sn represents the unique device identifier within the cluster, and each device has a unique sn number. timestamp represents the timestamp when the log occurred. pid represents the process ID of the application. tid represents the thread ID of the application. Level represents the log level; lower levels indicate more log content. Tag indicates the key code identifier for this log entry. Content represents the detailed log content.

[0043] like Figure 4 As shown, step S10 specifically includes: Step S11: The log search engine receives the log collection instruction from the natural language analysis module based on the AI ​​big model in the cloud server, parses the log collection instruction, and determines the target device identifier, log type, time range, and filter keywords to be collected.

[0044] Specifically, step S11 is implemented as follows: (1) Command reception and verification: The log collection command is received through a predefined application programming interface and the log collection command is encapsulated in a standardized message protocol; the received log collection command is security verified, which includes at least identity authentication and permission verification to ensure that the command source is legitimate and has the right to request the log data; after the verification is successful, the log collection command is sent to the parsing queue for subsequent processing.

[0045] (2) Command parsing and parameter extraction: A dedicated command parsing submodule is invoked. This submodule integrates or is based on a lightweight natural language processing model to perform semantic analysis on the log collection command; identify the device group described in the log collection command and map the natural language description to a specific list of device identifiers; wherein, the device identifier is the unique SN number of the device, and the natural language description includes at least one of the following: "all web servers in area A", "load balancer LB01 and its backend pool", "all nodes except the database master node"; identify and map the log type specified in the command, wherein the log type includes one or more of the following: operating system kernel log, system audit log, application log, container runtime log, and security log; parse the time description in the log collection command and convert it into an absolute start and end timestamp; wherein, the time description includes at least one of the following: "last 15 minutes", "from 10:00 AM to 2:00 PM today", "one hour before and after the last failure"; extract the explicitly specified or implicit keywords or topics in the log collection command, wherein the keywords include one or more of the following: error level, specific event ID, service name, IP address, and username.

[0046] (3) Strategy generation and instruction distribution: Combine the parsed parameters into a structured collection task description file; determine the log collection agent to be connected and its network address according to the target device identifier list; distribute the collection task description file to the log collection agent deployed on the target device to trigger the log collection operation.

[0047] Step S12: Based on the parsing results, the log search engine initiates a log collection request to the corresponding target device in the OS cluster, and receives system logs and business logs from each target device in real time or in batches according to a predetermined period.

[0048] Specifically, step S12 is implemented as follows: (1) Intelligent Request Distribution and Proxy Collaboration: The log search engine queries the maintained device-proxy routing table based on the parsed target device SN list to obtain the network endpoint of the log collection proxy on the target device. An asynchronous, non-blocking communication mode is adopted, using message queues or high-performance remote procedure call protocols such as gRPC to send collection instructions to all target proxies in parallel, rather than serially, to improve collection efficiency. The collection request includes a structured task description, which at least includes: task ID, log path / source to be collected, time range filter, content keyword filter, and collection mode.

[0049] (2) Dual-mode acquisition engine: When the log acquisition command requires low latency or monitoring of continuous events, the streaming acquisition mode is triggered; the log acquisition agent continuously monitors the specified log file or log stream on the target device, and immediately parses, filters and marks any new log entries; the processed log entries are pushed back to the aggregation node of the log search engine in near real-time through a persistent TCP connection or WebSocket connection; this mode is suitable for fault alarms, real-time monitoring dashboards and security event tracking scenarios. When the log acquisition command is used for offline analysis, performance report generation or historical data archiving, the batch acquisition mode is triggered; the log acquisition agent collects local log files on the target device according to a preset time window; the collected log data is locally compressed, encrypted and packaged to form one or more batches of data blocks; at a specified time point or when specific conditions are met, the data blocks are uploaded to the log search engine in batches through an efficient file transfer protocol; this mode is suitable for scenarios where timeliness requirements are not high but massive amounts of historical data need to be processed, which helps to reduce network connection overhead and cloud storage pressure.

[0050] (3) Data Preprocessing and Reliable Transmission: Before the data leaves the target device, sensitive fields in the logs are masked or hashed according to predefined rules. Format Standardization: Heterogeneous logs from different operating systems and applications are uniformly converted into a predefined standardized format. Local Caching and Resume Transmission: A temporary cache is set up on the target device. When the network is interrupted, the collected logs are temporarily stored locally; after the network is restored, transmission automatically resumes from the point of interruption to ensure that no data is lost.

[0051] In addition, the system load of target devices is monitored in real time. When high CPU / memory usage is detected on a target device, its collection mode is automatically switched from real-time streaming to low-frequency batch retrieval, or the collection accuracy is reduced, to ensure the normal operation of business applications. When the amount of log data collected according to instructions exceeds a preset threshold, a sampling mechanism is automatically activated. This sampling mechanism is not random sampling, but priority sampling based on the error level of the logs, ensuring that all ERROR and FATAL level logs are fully collected, while INFO and DEBUG level logs are sampled proportionally, controlling the amount of data without losing critical fault information.

[0052] Step S13: The log search engine performs standardized preprocessing on the collected system logs and business logs. The standardized preprocessing includes at least format unification, timestamp synchronization, and invalid data filtering.

[0053] Specifically, step S13 is implemented as follows: (1) Log parsing and format unification: Using log parsing algorithms based on clustering or decision trees, static event templates and dynamic parameter variables are extracted from the original log messages; for example, the log line "User 'admin' loggedin from IP 192.168.1.100 at 2023-10-27 10:00:01" is parsed as: Event template: "User ' <username>' logged in from IP<ip_address>at <timestamp>Parameter variables: {"username":"admin", "ip_address": "192.168.1.100"}; Field mapping and normalization: Maps the parsed fields and logs from different data sources (such as Syslog, Windows Event Log, JSON files) to a unified, general data model. This model enforces the definition of core fields such as host, service, level, message, event_id, and timestamp.

[0054] (2) High-precision timestamp synchronization: A unified time sequence is the foundation for event correlation and root cause analysis. The timestamp synchronization includes: Time zone unification and standardization: Converting all timestamps in log records to UTC time and storing them in standard formats such as ISO 8601 to eliminate time zone confusion caused by different geographical locations of target devices. Clock skew correction: To address the potential deviation of hardware clocks in various target devices in a distributed system, a clock skew correction is calculated and applied based on the difference between the local time reported by the log collection agent and the time received by the log search engine to compensate for all timestamps, aligning them as closely as possible to a globally consistent time sequence.

[0055] (3) Data Quality Cleaning and Enhancement: This process is responsible for filtering noise and enhancing data value. Invalid data filtering includes: Syntax invalidity filtering: Discarding completely messy log lines that cannot be successfully parsed by the parser. Content invalidity filtering: Filtering out meaningless debugging information, heartbeat logs, or known interference logs generated by specific sequence numbers based on predefined rules. Duplicate event compression: Compressing identical log entries generated consecutively within a very short period of time, retaining only the first and last entries, and recording the number of occurrences to avoid a flood of identical events overwhelming truly important critical logs. Standardized preprocessing also includes data enrichment steps: Metadata injection: Automatically adding rich contextual information to each log record, including but not limited to: Device information: SN number, IP address, cluster to which it belongs, geographical location. Collection information: Collection task ID, collection agent version, data reception time. Business context: By querying the configuration management database, associating the log with the corresponding business service name, responsible person, and cost center.

[0056] Step S14: The log search engine compresses and encrypts the preprocessed system logs and business logs, and uploads the compressed and encrypted system logs and business logs to the AI-based big data natural language analysis module on the cloud server through a secure transmission protocol.

[0057] Specifically, step S14 is implemented as follows: (1) Intelligent Compression and Serialization: This process aims to maximize transmission efficiency and reduce network bandwidth usage. Compression Algorithm Selection: The compression algorithm is dynamically selected based on the characteristics of the log data and network conditions. For high-bandwidth, low-latency networks, GZIP is preferred to obtain a higher compression ratio; for low-bandwidth or fast-processing scenarios, LZ4 or Snappy is preferred to reduce the CPU overhead of compression and decompression. Structured Serialization: Before compression, the structured log data is serialized into an efficient binary format, preferably Apache Avro, Protocol Buffers, or Apache Parquet. These formats not only have high compression ratios but also come with their own schema, facilitating accurate deserialization on cloud servers and avoiding the ambiguity and redundancy of parsing text formats such as JSON.

[0058] (2) End-to-end encryption: This process ensures the confidentiality of data during transmission and static storage, making it unbreakable even if intercepted. The compressed log data is encrypted using a hybrid encryption strategy: Symmetric encryption of the data itself: A one-time symmetric encryption key is dynamically generated for each transmission session, and algorithms such as AES-256-GCM are used to encrypt the compressed log data blocks at high speed. GCM mode provides both confidentiality and integrity authentication. Asymmetric encryption of the session key: The public key of the cloud server is used to encrypt the symmetric session key generated above. Data packet assembly: The encrypted log data and the encrypted session key are assembled into a secure data packet. This combines the security of asymmetric encryption with the efficiency of symmetric encryption.

[0059] (3) Reliable and Secure Transmission: This process ensures that data is delivered to the cloud server reliably and in an orderly manner; it uses secure transmission protocols for uploading, with protocol layer security: HTTPS or a secure channel based on TLS 1.3 is used for transmission, establishing an end-to-end encrypted tunnel from the log search engine to the cloud server to prevent man-in-the-middle attacks. Authentication and Authorization: A short-term access token issued by the authentication server is carried in the upload request. The cloud server verifies the legality and scope of authority of the token before receiving the data. Resume and Retry Mechanism: A unique identifier is generated for each uploaded data block. If a network interruption causes an upload failure, the log search engine will cache the failed data blocks and, after the network is restored, only re-upload the unsuccessful data blocks, not the entire task, ensuring the reliability of large data transmission.

[0060] Furthermore, log data analysis identifies frequently repeated log template strings. A shared dictionary is created for these templates and synchronized to the cloud server before data transmission. During compression, the template portion of the log data is replaced with a very short dictionary index, achieving a compression ratio far exceeding that of general compression algorithms. A strict key rotation strategy is implemented, regularly updating the cloud server key pair used for encrypting session keys. All encryption operations are performed under the protection of a trusted execution environment or hardware security modules, ensuring that the master key and session key never appear in plaintext in memory. The load status and network congestion of the cloud server are monitored in real time. When increased response latency or network packet loss is detected on the cloud server, the concurrent data upload rate is automatically reduced, and an adaptive backoff algorithm is used to smooth upload traffic, avoiding impact on cloud services.

[0061] In addition, the log search engine can also receive scheduling from the natural language analysis module (i.e., the log analysis AI agent) based on the AI ​​large model, change the log level as needed, and collect logs from more target devices within the OS cluster and upload them to the cloud server. Specifically, the log search engine receives an instruction that explicitly requests adjustment of the log output level of one or a group of target devices (e.g., from INFO to DEBUG). The log search engine does not directly operate on the target device, but instead issues a configuration update command to the log collection agent on that device. The log collection agent dynamically adjusts the log level without restarting the application or service through at least one of the following methods: for log frameworks that support dynamic configuration, the agent calls its management interface to update the log level; sends a signal to a specific application process to trigger it to reload the log configuration; in a containerized environment, it simulates changes in environment variables through the Sidecar pattern to affect the log output of associated containers; after changing the log level, the log search engine verifies whether the logs received from the device immediately contain the new level of log content.

[0062] Based on instructions from the AI ​​analysis module, the log search engine utilizes the cluster's service dependency graph or network topology to identify other target devices associated with the initially failed device. For example, when AI analysis detects a failure in the database master node (SN: DB-Primary), it instructs the log search engine to simultaneously collect logs from all connected application servers, load balancers, and database slave nodes to comprehensively assess the scope of the failure's impact. Based on the identified list of target devices, the log search engine generates new collection tasks and distributes them to the collection agents on these newly added devices, initiating log collection and uploading.

[0063] Log levels can be categorized as follows: debug: Used for debugging purposes, it provides a more detailed process record than the Info level.

[0064] Info: Records key business process nodes.

[0065] Warnning: A serious, unexpected situation has occurred.

[0066] Error: An error has occurred in the program or function.

[0067] Fatal: A major, fatal abnormality.

[0068] For example, if the log level is set to Info, then all Info / Warning / Error / Fatal level logs will be printed. Debug level logs will not be printed.

[0069] When the log search engine receives instructions from the "log analysis AI agent" and determines that more logs need to be output, it will lower the log level to ensure that the output logs contain more detailed information. In complex problems, it may be necessary to analyze logs from multiple devices jointly. The log search engine will collect more information (logs) from the target devices in the cluster according to the instructions of the "log analysis AI agent" and upload them to the cloud server for analysis by the "log analysis AI agent" module.

[0070] The log search engine enables the upper-layer AI-based natural language analysis module (log analysis AI agent) to acquire data "proactively and on demand," rather than "passively" processing all data. This is a key step in achieving intelligent operation and maintenance automation. Through command-driven precise collection, high-value, highly relevant data is uploaded to the cloud server, greatly reducing the data noise that the AI ​​model needs to process and improving the accuracy and speed of subsequent fault analysis and location. It avoids the uploading and storage of massive amounts of irrelevant logs, saving enterprises significant costs. Its distributed collection architecture and intelligent filtering capabilities enable the system to easily manage logs from tens of thousands of devices.

[0071] Step S20: The AI-based large-scale natural language analysis module annotates the meaning of each log segment according to the system log and the business log, combines the trained fault analysis model to infer the fault that has occurred, locate the cause of the fault, obtain a fault analysis and location report, and sends it to the AI-based large-scale fault reasoning and diagnosis module.

[0072] Specifically, the AI-based natural language analysis module acts as the "operations brain," not only transforming unstructured logs into structured knowledge but also serving as the decision-making starting point for the entire system to achieve an intelligent closed loop. It is primarily responsible for converting massive, messy, and technical log data into fault analysis and location reports that are clearly understandable to both humans and machines. These reports serve as "decision tokens" triggering all subsequent actions (such as notifying maintenance personnel and collecting feedback). The instructions issued by these reports can also dynamically adjust log collection strategies, achieving a complete closed loop of "analysis-decision-action-feedback." By collecting feedback from maintenance personnel, this module can be continuously fine-tuned and optimized.

[0073] For example, if the system reads "sn:d***00 01-09-10:01:49.389 766 1180 Info C05a02 / Communication[tcpCommunication:119]connect sn:d***01 failed", the AI-based natural language analysis module (log analysis AI agent) automatically infers that d***00 has failed based on the sn number. Based on the fault analysis model, it locates a fault in the communication module. Based on the detailed information, it locates a communication problem in device d***01. Based on the accumulated fault models (already analyzed fault types, each with its own judgment model), it automatically instructs the log search function to collect key logs from device d***01. It then sends the fault type and fault analysis location report to the AI-based fault reasoning and diagnosis module (fault decision AI agent).

[0074] The fault analysis and location report includes the fault type, fault cause, affected equipment, and judgment criteria; for example, the content of the fault analysis and location report: Fault type: Communication.

[0075] Cause of the fault: Port xx of device d***01 is occupied.

[0076] Generating equipment: d***00, d***01.

[0077] Judgment basis: d***01 key log: *****.

[0078] d***02 Key Log: *****.

[0079] like Figure 5 As shown, step S20 specifically includes: Step S21: The natural language analysis module based on the AI ​​large model inputs the system log and the business log into the trained fault analysis model, uses the fault analysis model to understand the semantics of the log text, and automatically generates one or more tags describing the meaning of each log segment. The tags include at least one or more of the following: log level, service module, operation type, and event type.

[0080] Specifically, step S21 is implemented as follows: (1) Data preparation and model loading: Instead of inputting a single log into the model in isolation, multiple logs within the time window, on the same device, or on the same transaction link are combined into a log sequence with context before input; the trained fault analysis model is a large language model that has been pre-trained on a general corpus and has undergone domain incremental pre-training or comprehensive fine-tuning using massive historical operation and maintenance logs, fault reports, and technical documents; a preset system prompt word template for log analysis is provided, which guides the model to play the role of a "senior operation and maintenance expert" and follow a specific analysis framework.

[0081] The training process for the fault analysis model can be as follows: 1) Collect training data from multiple sources: Historical log repository: collects system logs and business logs spanning several years, covering various normal and abnormal scenarios.

[0082] Confirmed fault reports: The final diagnostic reports of historical faults are extracted from the operation and maintenance work order system and CMDB. The reports clearly record the root cause, scope of impact and solutions.

[0083] Operations and Maintenance Knowledge Base: Collects unstructured knowledge such as operations and maintenance manuals, architecture diagrams, system documents, and technical blogs.

[0084] By using timestamps, fault numbers, and device identifiers, log sequences are precisely linked to the final fault report, forming "problem-answer" pairs.

[0085] 2) Construction of high-quality training dataset: Log-tag pairs: Using a data annotation platform, operations and maintenance experts annotate massive log samples to form training data of "log text -> structured tags" for training models to understand log semantics.

[0086] Event chain-diagnostic conclusion pair: Experts aggregate log sequences from historical failures into event chains and label the root cause events to form training data for training causal reasoning, which is called "event chain -> diagnostic conclusion".

[0087] Command-response pairs: Based on the above data, construct a dataset for command fine-tuning.

[0088] 3) Model training: Domain-Adaptive Pre-training: Employing self-supervised learning tasks such as masked language models, the model is further pre-trained on a vast, unlabeled corpus of operational logs and documentation. Example: Masking the "503" in the sentence "The server returned a 503 status code, indicating Service Unavailable," the model learns to predict this number and its semantics.

[0089] 4) Supervised Fine-Tuning: The model is fine-tuned under supervision using a high-quality command-response dataset. At this stage, the model learns to map a log entry to a set of labels, or a chain of events to a structured diagnostic report.

[0090] 5) Reinforcement learning based on human feedback: For the same event chain, multiple potentially different diagnostic conclusions are generated. Operations experts rank these conclusions and select the most accurate and comprehensive one. This preference data is used to train a reward model, which learns to determine which diagnostic conclusion is better. Using this reward model, the SFT model is further optimized through reinforcement learning algorithms, making its output more inclined to yield higher rewards for the diagnostic conclusion.

[0091] 6) Model Validation and Deployment: Evaluation indicators: Root cause localization accuracy: Whether the root cause identified by the model is consistent with the root cause confirmed by experts.

[0092] F1 score of diagnostic conclusion: comprehensively assesses the precision and recall rate of classification of fault type, faulty equipment, etc.

[0093] Human evaluation of reasoning quality: Experts score the logic and rationality of the "judgment basis" output by the model.

[0094] Only models that reach the predetermined performance threshold in offline evaluation will be pushed to the production environment.

[0095] 7) Online learning and continuous optimization: Feedback loop: The feedback from operations and maintenance personnel in the production environment regarding the confirmation, modification, or rejection of diagnostic reports is continuously collected as new gold standard data.

[0096] Incremental training: Regularly use newly collected feedback data to incrementally train or fine-tune the model, enabling it to adapt to system changes, discover new failure modes, and achieve continuous evolution.

[0097] (2) Semantic understanding and tagging: Generate a set of structured tags for each log entry. This system includes at least the following three levels: Entity layer: Identifies and labels core entities in the logs, including: Main components: user-service, kernel, nginx; Operations: connect, read, restart; Objects: database: user_db, file: / etc / config.yaml, memory; Status / Result: timeout, permission_denied, success; Semantic layer: Based on entity relationships, it summarizes the semantic summary of the logs, including: Event types: AuthenticationFailure, NetworkTimeout, ResourceExhaustion; Scope of impact: SingleUser, ServiceWide, ClusterWide; Decision-making level: Determine the meaning of logs in the operational context, including: Action directives: Investigate Immediately, Monitor For Escalation, No Action Needed; Suspected areas: ConfigError, HardwareFailure, ExternalDependencyIssue.

[0098] (3) Advanced Reasoning and Quality Assurance: When a log entry is semantically ambiguous and may correspond to multiple labels, the model will output the Top-K most likely labels and their corresponding confidence scores. For labels with low confidence scores, the system will mark them for manual review or cross-validation with other log entries in subsequent processes.

[0099] For complex logs that are difficult to label directly, the model generates an inference chain internally before outputting the final label. For example: Log: "Request processing failed; nested exception isjava.sql.SQLException: ORA-12541: TNS:no listener".

[0100] Inference chain: The log shows an SQL exception indicating that TNS has no listener -> TNS is the network component of Oracle database -> no listener means that the client cannot connect to the database's listening port -> this indicates that the database service may not be running or there may be a network blockage.

[0101] Generate labels: Based on this reasoning, the model will generate high-precision labels, such as event type: DatabaseConnectionFailure, suspected direction: DatabaseServiceDown | NetworkIssue.

[0102] This transformed unstructured logs into semantically rich structured data, providing precise input for subsequent graph construction and causal analysis.

[0103] Step S22: The natural language analysis module based on the AI ​​big model aggregates the log sequences labeled with the meaning of the content according to the time order and correlation to form an event chain. The event chain is matched with the fault patterns in the knowledge base. Based on the fault analysis model, causal reasoning is performed on the successfully matched event chains to identify the log events of the root cause and output a diagnostic conclusion that includes the fault type, fault cause, the device that occurred, and the judgment basis.

[0104] Specifically, step S22 is implemented as follows: (1) Intelligent event chain aggregation: The log sequence with content meaning is aggregated according to time order and correlation to form an event chain; not only is it sorted according to time order, but it also weaves discrete log events into a chain through one or more of the following association keys: Global Request ID: Tracks the complete path of a user request across multiple devices.

[0105] Device topology relationships: Based on the physical or logical topology of the cluster (e.g., Web server -> application server -> database), events with causal probability on different devices are associated.

[0106] Resource dependencies: For example, associate the "insufficient disk space" log with error logs from multiple different services that subsequently attempt to write data to that disk.

[0107] Aggregate the same type of events that occur repeatedly within a short period of time, and represent them as "event X occurred N times within time T" to avoid the chain being overwhelmed by redundant events and to highlight the main logic.

[0108] (2) Pattern Matching Based on Knowledge Graph: The knowledge base is an operations and maintenance knowledge graph, where nodes represent system components, log events, or fault phenomena, and edges represent causal, dependency, or co-occurrence relationships between them. It stores two main patterns: known fault patterns: predefined, common fault scenarios and their corresponding event chain templates; historical fault cases: fault event chains that have been successfully diagnosed and verified in the past. The event chains generated in real time are used as a subgraph for similarity subgraph matching in the operations and maintenance knowledge graph. The known fault pattern or historical case with the highest matching degree will be selected as a candidate explanation for the current fault.

[0109] (3) Model-based causal reasoning and root cause identification: For the matched event chain, the fault analysis model calculates a "root cause score" for each event node in the chain. The calculation of this score is based on: chronological order: following the basic principle of "cause first, effect later". Causal strength: based on the weight of the edges in the knowledge graph, judging the probability that event A leads to event B. Fault propagation model: combining the dependencies of the system architecture, simulating the propagation path of the fault. The node located at the starting point of the propagation path has a higher root cause score. The model selects the initial event with the highest root cause score, which can most reasonably explain the entire event chain, as the root cause.

[0110] (4) Structured and interpretable diagnostic conclusion output: Output diagnostic conclusions, specifically the following structured information: Fault type: A standardized classification, such as database connection pool exhaustion, network partition, memory leak.

[0111] Cause of failure: A natural language description of the root cause, down to the specific device and event, such as the database connection pool being fully occupied due to a surge in slow queries on device SN:DB-01.

[0112] Occurring device: Clearly indicate the device SN number where the root cause occurred, as well as a list of other affected device SN numbers.

[0113] Basis for judgment: Key evidence: List several core log entries and their semantic tags that support this diagnosis.

[0114] Reasoning Logic: Briefly describe the reasoning process of the model in a readable form. For example: The connection timeout error of the application server (SN:APP-01) is due to the database server (SN:DB-01) reaching its connection limit; and the connection limit is caused by a large number of slow queries occurring at the same time.

[0115] Confidence level: A confidence score in percentage form is given, reflecting the reliability of the diagnostic conclusion.

[0116] Step S23: The natural language analysis module based on the AI ​​big model integrates the diagnostic conclusion, relevant key log fragments and content meaning annotations, and event chain visualization information to generate a structured fault analysis and location report. The fault analysis and location report is then pushed to the fault reasoning and diagnosis module based on the AI ​​big model through a message queue or remote procedure call interface.

[0117] Specifically, step S23 is implemented as follows: (1) Generation of structured fault analysis and location report: The system integrates and generates a structured fault analysis and location report, including the following core components: 1) Report header information: Report ID: A globally unique identifier used for tracking.

[0118] Generate timestamp: The time the report was created.

[0119] Time window: The time range of logs covered by the report.

[0120] 2) Execution Summary: Fault Description: Summarize the fault phenomenon in one or two sentences, such as "User login service is intermittently unavailable due to database connection pool exhaustion".

[0121] Root cause: A concise description of the root cause, such as "Slow queries on the database server (SN: DB-SRV-07) caused the connection pool to become full."

[0122] Scope of impact: Briefly describe the services, businesses, and users affected.

[0123] Urgency level: Automatically classified according to preset rules (e.g., P0-urgent / P1-high / P2-medium / P3-low).

[0124] 3) Diagnosis details: Fault event chain: Visualize the sequence and causal relationship of key events in the form of a timeline or flowchart.

[0125] Key Evidence List: This section lists the most crucial log snippets supporting the diagnosis. Each piece of evidence includes: a timestamp, device serial number, the original log content, and an AI-annotated semantic tag (e.g., event type: DatabaseConnectionTimeout).

[0126] Reasoning process explanation: Using natural language, explain step by step why the root cause is deduced from key evidence, enhancing the interpretability and credibility of the report.

[0127] 4) Context and suggestions: Related topology: Indicates the location of the affected system components in the architecture diagram.

[0128] Preliminary action recommendations: Preliminary handling recommendations for this type of failure, generated based on the knowledge base (e.g., "It is recommended to prioritize optimizing the identified slow query SQL statements").

[0129] Confidence score: The confidence level of the model in the conclusions of this report (0%-100%).

[0130] (2) Report packaging and reliable delivery: 1) Data serialization: Convert structured fault analysis and location reports into a lightweight, cross-language serialization format, preferably JSON or Protocol Buffers, to ensure data structure consistency and efficient parsing.

[0131] 2) Transmission channel selection: In high-concurrency, asynchronous scenarios: Message queues (such as Apache Kafka, RabbitMQ) are used. The natural language analysis module acts as a producer, publishing reports to specific topics, while the fault reasoning and diagnosis module acts as a consumer, subscribing to them. This approach achieves module decoupling, traffic smoothing, and ensures no message loss.

[0132] Low-latency, synchronous query scenarios: Using the remote procedure call (gRPC) interface, the natural language analysis module directly calls the API provided by the diagnostic module and synchronously waits to receive the receipt, which is suitable for scenarios that require immediate response.

[0133] 3) Ensure delivery and idempotency: Each report is assigned a unique ID, and a confirmation mechanism is initiated after it is pushed out. If no confirmation is received from the recipient, the process is retried according to the established policy.

[0134] The receiver (fault reasoning and diagnosis module) performs idempotency checks using the report ID to avoid duplicate processing caused by retransmission.

[0135] Furthermore, when the AI ​​generates an updated report for the same persistent fault, the system automatically compares the new report with the old one. Changes in diagnostic conclusions (such as root cause corrections or increased confidence levels) are highlighted in the report, helping operations personnel quickly understand the analysis progress. The event chain visualization uses a standardized graphical format: generating SVG or PNG format visualizations embedded in the report. These graphics use different shapes and colors to distinguish between "root cause events," "intermediate propagation events," and "final impact events," and provide simple legends to make the event chain clear at a glance. Based on the fault type or affected business module diagnosed in the report, the message queue system automatically routes the report to different logical processing queues. Different fault reasoning and diagnostic module instances can subscribe to different queues, thereby achieving load balancing and specialized processing of diagnostic tasks (e.g., dedicating a single instance to handle all database-related faults).

[0136] Step S30: The fault reasoning and diagnosis module based on the AI ​​big model notifies the relevant maintenance personnel according to the fault type and fault cause in the fault analysis and location report, automatically collects the feedback information of the relevant maintenance personnel, and inputs the feedback information into the natural language analysis module based on the AI ​​big model.

[0137] Specifically, the fault reasoning and diagnosis module based on the AI ​​large model (i.e., the fault decision AI agent) is responsible for transforming the analysis conclusions into actual operation and maintenance actions and managing the entire subsequent process. It is the "decision and execution hub" for realizing the closed loop of automated operation and maintenance. The fault reasoning and diagnosis module based on the AI ​​large model is mainly responsible for receiving structured fault analysis and location reports and performing the following core functions: Decision-making and notification: Decide who to notify, how to notify, and implement the notification.

[0138] Feedback collection: Proactively interact with maintenance personnel to collect and process feedback.

[0139] Knowledge loop: Transforming feedback into learning materials for AI models to drive system evolution.

[0140] The fault reasoning and diagnosis module based on the AI ​​big model ensures that the results of intelligent analysis can be efficiently and accurately transformed into real-world operation and maintenance actions, and through collaboration with humans, ultimately forms an intelligent operation and maintenance ecosystem that can continuously improve itself.

[0141] like Figure 6 As shown, step S30 specifically includes: Step S31: The fault reasoning and diagnosis module based on the AI ​​large model parses the fault analysis and location report, extracts the fault type and fault cause from the fault analysis and location report, determines the relevant maintenance personnel who need to be notified according to preset rules, and sends a notification message to the relevant maintenance personnel through email, instant messaging tools or operation and maintenance alarm platform. The message contains at least the fault type, fault cause and report link.

[0142] Specifically, step S31 is implemented as follows: (1) Intelligent report parsing and key information extraction: Structured field reading: Read information directly from the structured parts of the report, such as the "fault_type" and "root_cause" fields in JSON format.

[0143] Unstructured text understanding: For non-text summaries in the report, the module's own LLM capabilities are used to extract key information, ensuring accurate extraction even with minor changes in the report format.

[0144] Contextual information extraction: In addition to fault type and cause, the following key contextual information is automatically extracted for subsequent decision-making: Scope of impact: Determine whether it is a single device failure or a cluster-level failure.

[0145] Urgency level: Read the urgency level (e.g., P0 / P1 / P2) assessed by AI in the report.

[0146] Core devices / services involved: Extract a list of the devices and affected business services where the root cause occurred.

[0147] (2) Dynamic routing decisions based on rules and context: Rule engine query: The preset rules are a dynamically configurable rule engine, and the rule factors include: Fault type (e.g., network problem, database problem, application code problem).

[0148] Faulty device (e.g., device serial number, cluster to which it belongs).

[0149] Affected services (e.g., order services, payment gateways).

[0150] Time (e.g., working hours, non-working hours, holidays).

[0151] Urgency level.

[0152] Dynamic routing logic: Primary Matching: Match the person in charge or the main maintenance team based on the "faulty device" and "fault type".

[0153] Escalation strategy: If the issue remains unresolved outside of working hours or for an extended period without confirmation, the notification will be automatically escalated to the second tier or team leader.

[0154] Broadcast strategy: For faults with a wide impact (cluster level), in addition to notifying the person directly responsible, copy the relevant business parties, architects or all members of the operation and maintenance team.

[0155] (3) Personalized and contextualized message generation: Channel-adaptive content generation: Instant messaging tools: Generate concise message cards that highlight the fault title, root cause, urgency level, and "Act Now" button, linking to a detailed report.

[0156] Email: Generate fully formatted emails that include a summary, detailed diagnosis, impact analysis, and action recommendations.

[0157] SMS: Generates minimal text messages containing key alert information and short links.

[0158] Personalized message input: Use the name of the maintenance personnel in the message and clearly state their role in this failure (e.g., "Zhang San, as the database administrator, you need to pay attention to this issue immediately").

[0159] The message content should include at least: [Urgency Level] + [Fault Title]; A concise description of the [fault type] and [root cause]; [Time of Occurrence] and [Scope of Impact]; [Direct Redirect Link]: Points to an interactive, full fault report page; [Quick Action Buttons] (such as in email and chat tools): For example, confirm acceptance, fixed, false alarm.

[0160] (4) Reliable push and receipt management: Send notification messages via email, instant messaging tools, or operations and maintenance alarm platforms: Failure retry mechanism: If message sending fails (e.g., network problems, interface rate limiting), the system will automatically retry according to the exponential backoff strategy until success or the maximum number of retries is reached.

[0161] Delivery and Read Receipts: Monitor the delivery status of messages. For high-priority alarms, track whether maintenance personnel clicked the report link as indirect evidence of "read".

[0162] Alarm suppression and noise reduction: In a short period, the module intelligently deduplicates multiple related reports for the same root cause fault, preventing message bombardment for maintenance personnel. New notifications are only sent when the diagnostic conclusion fundamentally changes or the fault escalates.

[0163] In addition, the system records the efficiency and success rate of handling historical faults. When a new fault occurs, the model recommends the "best" maintenance personnel who are most likely to respond quickly and resolve the fault type, serving as a reference for routing decisions. The fault reasoning and diagnosis module automatically retrieves and appends 1-3 of the most commonly used initial troubleshooting commands or repair script links from the knowledge base based on the fault type, helping maintenance personnel to quickly get started.

[0164] Step S32: While sending the notification, the fault reasoning and diagnosis module based on the AI ​​large model provides an interactive feedback interface to the relevant maintenance personnel. Through the interactive feedback interface, the module collects the relevant maintenance personnel's confirmation information on the fault analysis, supplementary explanations, records of handling measures, or opinions on the correction of the analysis results.

[0165] Specifically, step S32 is implemented as follows: (1) Presentation and integration of interactive feedback interface: Provide maintenance personnel with an interactive feedback interface, including: Seamless integration: This interface can be seamlessly embedded into notification messages in multiple formats.

[0166] Embedded Web Components: An interactive micro-frontend application can be directly embedded in the message card of an email or chat tool, allowing users to operate it without having to navigate to another page.

[0167] Deep link: Provides a direct link to a standalone feedback ticket page, which is pre-populated with all the context information for this fault.

[0168] Regardless of how it is opened, the interface is automatically associated with the report ID of this fault, the full text of the fault analysis and location report, and relevant key log fragments, ensuring that the feedback and the problem are accurately matched.

[0169] (2) Structured and guided feedback collection: The collection and confirmation of information, supplementary explanations, records of handling measures, or suggestions for correction are achieved through the following structured components: Diagnostic accuracy assessment: Provides radio buttons for maintenance personnel to evaluate the AI ​​diagnostic conclusions: completely correct, partially correct, or incorrect. If partially correct or incorrect is selected, a detailed explanation field will be forced to pop up, requiring the user to specify the inaccurate parts.

[0170] Root Cause Correction: Provides a text input box that allows maintenance personnel to enter their confirmed true root cause. This input box supports rich text and can upload attachments such as images and log files as evidence.

[0171] Handling Action Record: Provide a standardized form to guide maintenance personnel in recording actions taken (e.g., restarting the service, rolling back the version, optimizing SQL), commands or scripts used, time of resolution, and root cause classification (select from a predefined list, such as: code defect, configuration error, hardware failure, third-party issue).

[0172] Provide an open text area for maintainers to record any observations, follow-up suggestions, or temporary solutions that are not covered.

[0173] (3) Dynamic interaction and intelligent assistance: The interactive feedback interface supports dynamic and intelligent interaction processes: Conditional forms: Dynamically show or hide relevant fields based on the user's selection.

[0174] Example: The "Root Cause Correction" field becomes required only when the user selects "Incorrect Diagnosis".

[0175] Smart pre-population: Based on the fault type, attempt to pre-populate the "handling measures" field.

[0176] Example: For the "database connection pool exhausted" fault, the interface can pre-populate measures such as "optimize identified slow query statements", and the user only needs to confirm or modify them.

[0177] Conversational Interaction: A chatbot is integrated into the interface, allowing maintenance personnel to provide feedback using natural language. Example: Maintenance personnel can enter: "The analysis is basically correct, but the root cause is not the slow query, but the network interruption at the time, which has been automatically restored." The AI ​​will automatically parse this text and structure it into the corresponding "Diagnostic Accuracy Assessment" and "Root Cause Correction" fields.

[0178] In addition, lightweight gamification mechanisms can be introduced, such as awarding points or publicly recognizing maintenance personnel who provide high-quality, detailed feedback to encourage active participation; for feedback marked as "incorrect diagnosis," the system can automatically create a peer review task for another senior engineer to review, ensuring the accuracy of the feedback itself and maintaining the quality of the knowledge base.

[0179] Once maintenance personnel submit feedback through the interface, the status of the fault (e.g., confirmed, fixed, false alarm) will be updated in real time. This status update will be automatically broadcast to all relevant parties through the original notification channel to ensure team information synchronization and avoid duplication of work.

[0180] When a maintenance worker's recorded handling measures are marked as effective and universally applicable, the system will prompt: "Save this measure to the knowledge base for reference in the future for similar faults?" After confirmation, the measure will be automatically converted into a standard operating procedure entry in the knowledge base and associated with this type of fault mode.

[0181] Step S33: The fault reasoning and diagnosis module based on the AI ​​large model performs structured processing on the collected feedback information, associates the processed feedback information with the corresponding original fault analysis and location report, and stores it as labeled training data. The stored feedback data is used periodically to incrementally train or fine-tune the natural language analysis module based on the AI ​​large model and / or the trained fault analysis model to optimize the analysis and reasoning capabilities.

[0182] Specifically, step S33 is implemented as follows: (1) Structured processing and correlation of feedback data: The collected feedback information is structured, including: Information extraction and normalization: Automatically extract key fields from the raw feedback data submitted through the interactive feedback interface, such as diagnostic accuracy assessment, root cause after correction, handling measures, and root cause classification; extract key information and clean the text of text-based feedback (such as correction suggestions) and transform it into a regular format.

[0183] Tag generation: The root cause confirmed or corrected by maintenance personnel is used as the "standard tag" for the fault; the handling measures and root cause classification selected by maintenance personnel are used as the "handling plan tag" for the fault scenario.

[0184] Data association and tagging: The generated tags are precisely associated with the original fault analysis and location report and the corresponding original log sequence to form a complete, tagged data sample; the data sample is then assigned a data quality score, based on factors such as the qualifications of the feedback provider, the level of detail in the feedback, and whether it has undergone peer review.

[0185] (2) Construction and management of incremental training datasets: Create a versioned dataset: Store the processed data samples in a versioned incremental training dataset; each sample contains a complete context: raw logs -> AI preliminary analysis report -> human feedback / labels; Data screening and balancing: Before building the training set, the data is screened, prioritizing samples with high data quality scores; special attention is paid to and oversampling of samples that the AI ​​previously diagnosed incorrectly (diagnostic accuracy was assessed as "incorrect") to specifically address the weaknesses of the model; ensure that the distribution of various faults in the dataset is relatively balanced to avoid the model being biased towards common fault types.

[0186] (3) Continuous fine-tuning and optimization of the model: Regularly utilize stored feedback data for incremental training or fine-tuning. Fine-tuning the AI-based natural language analysis module involves improving the accuracy of its log labeling and preliminary event chain analysis. For example, using labeled log data and event chain data, supervised fine-tuning of the AI-based natural language analysis module will make its future labeling and preliminary inference closer to human expert judgment. Optimizing the fault analysis model involves improving the accuracy of its causal inference and root cause localization. Using the original log sequence and its corresponding standard label (root cause) as a "question-answer" pair, fine-tuning the fault analysis model, especially enabling it to learn from errors and understand why the initial inference path was wrong and what the correct causal chain should be.

[0187] The process is an automated, periodic (e.g., weekly / monthly) offline training task. After training is completed, a new version of the model is generated and compared with the old model in a shadow environment. Only when the performance of the new model (e.g., root cause localization accuracy) is significantly better than that of the old model will it be deployed to the production environment to complete the smooth upgrade.

[0188] Furthermore, the process of model diagnosing faults and receiving feedback is constructed as a reinforcement learning scenario. If the model's diagnostic conclusion is marked as "completely correct" by maintenance personnel, it receives a positive reward; if marked as "incorrect," it receives a negative reward. This human feedback data is used to train a reward model, which in turn optimizes the fault analysis model's decision-making process through reinforcement learning algorithms, making its output more inclined to obtain higher rewards (i.e., more accurate) in diagnostic conclusions. When the validated feedback data contains new fault modes or corrects old fault modes, the system automatically or after review adds nodes to the operations and maintenance knowledge graph or modifies the relationships between existing nodes and edges. For example, if multiple feedbacks confirm that a specific "cache avalanche" pattern is caused by both events A and B, rather than solely by event A as previously thought, the causal relationships in the knowledge graph will be updated. After continuous model version updates, key performance indicators in the production environment are continuously tracked, such as average diagnostic accuracy, the proportion of correct first-time diagnoses, and the "completely correct" feedback rate of diagnostic reports by maintenance personnel. These indicators quantify and validate the effectiveness of the feedback learning mechanism, and adjust the incremental training strategy and frequency accordingly.

[0189] Furthermore, such as Figure 7 As shown, the fault reasoning and diagnosis module based on the AI ​​large model notifies the relevant maintenance personnel according to the fault type and cause in the fault analysis and location report. Prior to this, it also includes: Step S41: The fault reasoning and diagnosis module based on the AI ​​large model determines whether it is necessary to notify the relevant maintenance personnel based on the fault analysis and location report; Step S42: If the fault reasoning and diagnosis module based on the AI ​​big model determines that it is not necessary to notify the relevant maintenance personnel based on the fault analysis and location report, then the fault reasoning and diagnosis module based on the AI ​​big model directly feeds back to the natural language analysis module based on the AI ​​big model for autonomous maintenance.

[0190] In other words, if a certain fault occurs, what methods can be used to analyze it? If it is a particularly clear case, then autonomous maintenance can be carried out. For example, if a communication failure occurs between device A and device B, check the logs of device B and find that it was caused by a restart of device B. Check the logs of device B's restart and locate that the temperature is too high. Then turn on the air conditioner in the room where device B is located.

[0191] Furthermore, such as Figure 8 As shown, before uploading the OS's system logs and business logs to the cloud server via a log search engine, the process also includes: Step S51: At the edge or on the device locality, use a lightweight AI model to perform preliminary analysis and filtering of the system logs and the business logs; Step S52: Only when a potential anomaly is identified or a specific triggering condition is met will the relevant key logs and context be uploaded to the cloud server; otherwise, they will be archived or discarded locally (automatically cleaned up periodically to release storage space).

[0192] Cloud-based servers no longer need to process massive amounts of raw log data, most of which is invalid. They only need to focus on deep reasoning and correlation analysis of high-value anomaly events reported from the edge that have already undergone preliminary screening. This allows the limited AI computing power of cloud-based servers to be concentrated on the most complex and critical diagnostic tasks, improving the throughput and efficiency of the entire system's analysis tasks. This greatly reduces the pressure on cloud-based servers (significantly reducing network bandwidth and cloud storage costs), while also reducing the potential risk of data leakage during transmission and cloud storage, and better meeting data privacy requirements.

[0193] Furthermore, such as Figure 9 As shown, the OS runtime log processing method based on the AI ​​large model also includes: Step S61: When the fault cause located by the fault reasoning and diagnosis module based on the AI ​​large model belongs to a known type that allows automatic repair, an automated repair script is generated. Step S62: After obtaining authorization, the automated repair script is sent to and executed on the target device through the log search engine.

[0194] The system maintains a "self-healing fault knowledge base," which defines the mapping relationship between fault types, root causes, and standardized repair scripts (e.g., fault type: "service unresponsive," root cause: "process exited unexpectedly," repair script: "sudo systemctl restart").<service_name> Dynamic script generation: When the AI ​​diagnoses a fault, the fault reasoning and diagnosis module queries the knowledge base. If a match is found, the variables for the repair script are dynamically populated and instantiated based on contextual information such as the specific faulty device and service name, generating a specific script that can be executed immediately. For operations with extremely low risk and extremely high success rate (such as cleaning temporary files), execution can be performed immediately after diagnosis; for common operations, a notification is sent to maintenance personnel, who can trigger the operation by simply clicking "Approve Execution"; for high-risk operations (such as restarting the database or modifying core configurations), a formal change order needs to be created and approved by an administrator with higher privileges before execution.

[0195] Furthermore, after the script executes, the system does not immediately consider it successful. It waits for a pre-defined cooling-off period and then automatically triggers a round of health checks (e.g., rerunning diagnostics, checking if service ports are listening, and querying whether key business metrics have recovered). If the verification is successful: the status is marked as "Automatically repaired" in the fault report, and relevant personnel are notified. If the verification fails: the status is marked as "Automatic repair failed," the alarm is immediately escalated, and the execution log is provided to maintenance personnel as a new context to assist them in performing manual repair.

[0196] Furthermore, the target devices in the OS cluster include cloud-connectable devices and non-cloud-connectable devices; such as Figure 10 As shown, the OS runtime log processing method based on the AI ​​large model also includes: Step S71: When the target device is a cloud-connectable device (a device that can successfully communicate with the cloud-side server), the system logs and business logs of the cloud-connectable device are directly transmitted to the cloud-side server through the log search engine. Step S72: When the target device is a device that cannot be directly connected to the cloud (a device that cannot directly access the Internet or the address of a cloud-side server), the system logs and business logs of the device that cannot be directly connected to the cloud are first transmitted to the device that can be connected to the cloud through the log collection engine, and then transmitted to the cloud-side server through the log collection engine.

[0197] When a log search engine needs to collect logs from devices that cannot be directly connected to the cloud, it first intelligently assigns one or more "relay cloud-connectable devices" based on metadata such as cluster topology and network region. These relay devices are typically located on the same internal network and have cloud connectivity. An internal channel is established: the collection agent on the non-directly cloud-connectable device securely transmits log data to the log collection agent on the relay device via the internal network (e.g., LAN, VPC). This process also uses encryption protocols to ensure secure internal network transmission. The agent on the relay device acts as a log gateway, receiving logs from one or more non-directly cloud-connectable devices. It deduplicates, compresses, and batch-aggregates the logs, then forwards them uniformly to the cloud server through its own cloud-connection channel. This eliminates monitoring blind spots caused by network isolation. Logs from virtual machines in the cloud, development machines in the office, production servers on isolated network segments, and IoT gateways can all be uniformly incorporated into the analysis platform.

[0198] Furthermore, such as Figure 11 As shown, the present invention may further include a performance baseline learning step: Step S81: Continuously analyze system logs and business logs during normal operation to establish dynamic performance and behavior baselines; Step S82: When the real-time log data deviates significantly from the baseline, even if no explicit fault rule is triggered, a potential risk warning is generated and submitted to the AI-based big data natural language analysis module for processing.

[0199] Using statistical process control or machine learning anomaly detection algorithms (such as Isolation Forest and Local Outlier Detection) to determine whether real-time log data deviates significantly from the baseline is not merely about "exceeding a threshold," but rather about determining whether it exceeds the range of historical normal fluctuations. When a deviation is detected, the generated potential risk warning is a structured signal. This allows for the capture of subtle, early signs of deteriorating system health minutes or even hours before a failure occurs (e.g., before service becomes completely unavailable), providing the operations team with a valuable "golden window" to mitigate risks before users perceive the failure, thus preventing business interruption and economic losses at their source.

[0200] Furthermore, such as Figure 12 As shown, the present invention may further include: Step S91: The fault reasoning and diagnosis module generates preliminary processing suggestions by querying the historical fault knowledge base or the fault propagation simulation results based on the graph model. Step S92: Based on the preliminary processing suggestions, the fault analysis and location report, and the collected feedback information, automatically generate an incident report form that conforms to the IT service management specifications, and automatically submit the incident report form to the operation and maintenance management work order system.

[0201] The fault reasoning and diagnosis module uses the "fault type" and "root cause" of the current fault as query conditions, performing a semantic search in the historical fault knowledge base, rather than simple keyword matching. It identifies historically valid and effective handling measures and solutions for similar faults from the database, prioritizing these as current recommendations. Taking the current fault point (e.g., database master node failure) as input, it performs simulations on the system architecture dependency graph model to predict the possible path of fault propagation. Based on the simulation results, it not only provides suggestions for fixing the root cause (restarting the database) but also generates preventative and mitigation suggestions. The suggestions from the knowledge base and graph simulation are deduplicated and integrated. Finally, they are sorted according to their effectiveness (historical success rate), urgency, and operational risk, and output to operations personnel.

[0202] In accordance with ITSM specifications, information from multiple parties is automatically integrated and populated into the corresponding fields of the incident report. The format, fields, and status flow of the report fully comply with ITIL and other IT service management standards, ensuring that it can be directly understood and processed by the existing operations and maintenance team and management system. The completed incident report is used as data payload, automatically creating a new work order in the work order system and automatically assigning it to the corresponding processing group or responsible person. When the work order is marked as "resolved," the fault is considered to be completely closed, and all data is automatically archived. The AI ​​analysis results are automatically converted into standardized management documents, avoiding the need for operations and maintenance personnel to manually copy and relay AI reports, and eliminating information distortion caused by poor communication. This ensures that the handling process for each fault is standardized, transparent, and traceable, significantly improving the standardization level and operational efficiency of the operations and maintenance team.

[0203] This invention is based on AI large-scale model technology and designs an AI agent module for fault location and maintenance of cluster systems. Leveraging the capabilities of the AI ​​agent, it achieves a design with minimal resource consumption for intelligent operation and maintenance. The AI ​​agent automatically generates fault tickets and automatically notifies relevant maintenance personnel based on the type of fault ticket. To protect privacy (logs may contain sensitive information), the log analysis AI agent and the fault decision AI agent are separated. Only the fault decision AI agent directly faces the operation and maintenance personnel, who can only access a limited number of fault cause logs, thus avoiding the leakage of sensitive information. Based on feedback from the operation and maintenance personnel, and leveraging the self-learning capabilities of the AI ​​large-scale model, the operation and maintenance model is automatically updated.

[0204] The technical effects that this invention can bring are as follows: (1) Achieving a fundamental shift in the operation and maintenance paradigm: achieving proactive early warning and automatic repair: Traditional operation and maintenance involves manual intervention only after a fault occurs. However, this invention elevates operation and maintenance to a new level of prediction and prevention, enabling the identification of potential risks before a fault occurs and the automatic completion of the entire process from diagnosis to repair after a fault occurs. This achieves a fundamental paradigm shift from passive response to proactive operation, greatly ensuring business continuity.

[0205] (2) The accuracy and efficiency of fault location have been improved by orders of magnitude: By introducing natural language analysis based on AI large model, the system can understand the deep semantics of logs and perform correlation analysis and causal reasoning like human experts, directly and accurately locate the root cause, rather than just listing the phenomena. This solves the pain points of high false alarms and high false alarms of traditional keyword and rule-based methods, as well as the inability of junior maintenance personnel to quickly locate complex root causes, and greatly shortens the fault location time.

[0206] (3) Constructing a complete automated closed loop of "perception-analysis-decision-execution": This invention is a complete system that integrates log collection, intelligent analysis, diagnostic decision-making, and feedback learning. Each link is closely connected. The output of the natural language analysis module based on the AI ​​big model drives the decision of the fault reasoning and diagnosis module based on the AI ​​big model. The instructions of the fault reasoning and diagnosis module based on the AI ​​big model can schedule the collection behavior. The collected feedback is used to optimize the natural language analysis module based on the AI ​​big model. This closed-loop system enables the operation and maintenance process to operate automatically, efficiently, continuously and self-optimize, significantly reducing manual intervention and realizing the automation of operation and maintenance work.

[0207] (4) Break down data silos and achieve full-domain and full-link observability: By supporting a smart log collection engine for hybrid network environments (compatible with cloud-connectable and non-cloud-connectable devices), the solution achieves unified collection and analysis of log data from all environments (cloud, edge, and terminal) within the enterprise. Combined with AI’s cross-device event correlation capabilities, it can draw a complete fault propagation chain and provide full-link, unified-perspective observability from user requests to backend services, completely eliminating monitoring blind spots.

[0208] (5) Driving the continuous accumulation and systematization of operation and maintenance knowledge to build organizational intelligence: This invention automatically transforms the individual experience of operation and maintenance personnel in handling faults (such as the correction of AI diagnosis and effective handling measures) into standardized digital assets that are available to the system through structured feedback collection and model incremental learning mechanism. This realizes a strong closed loop of "learning from practice and optimizing in learning", which enables the organization's operation and maintenance knowledge to be continuously accumulated, systematized and inherited, and ultimately builds an operation and maintenance brain with collective wisdom and continuous evolution.

[0209] Furthermore, such as Figure 13 As shown, based on the above-mentioned OS runtime log processing method based on AI large-scale models, the present invention also provides an OS runtime log processing system based on AI large-scale models, wherein the OS runtime log processing system based on AI large-scale models includes: Log search engine 50 is used to receive instructions from the natural language analysis module based on AI large model, collect system logs and business logs from multiple target devices in the OS cluster, and upload the OS running system logs and business logs to the cloud server through the log search engine. The AI-based large-scale natural language analysis module 60 is used to annotate the meaning of each log segment according to the system log and the business log, combine the trained fault analysis model to infer the fault that has occurred, locate the cause of the fault, obtain a fault analysis and location report, and send it to the AI-based large-scale fault reasoning and diagnosis module. The fault reasoning and diagnosis module 70 based on the AI ​​big model is used to notify relevant maintenance personnel based on the fault type and fault cause in the fault analysis and location report, automatically collect feedback information from relevant maintenance personnel, and input the feedback information into the natural language analysis module based on the AI ​​big model.

[0210] like Figure 14 As shown in this embodiment of the OS runtime log processing system based on an AI large model, in this embodiment, the log search engine 50 includes: The instruction receiving unit 501 is used to receive log collection instructions from the natural language analysis module based on the AI ​​large model in the cloud server, parse the log collection instructions, and determine the target device identifier, log type, time range, and filter keywords to be collected. The log collection unit 502 is used to initiate a log collection request to the corresponding target device in the OS cluster based on the parsing result, and to receive system logs and business logs from each target device in real time or in batches according to a predetermined period. The log preprocessing unit 503 is used to perform standardized preprocessing on the collected system logs and business logs. The standardized preprocessing includes at least format unification, timestamp synchronization, and invalid data filtering. The log transmission unit 504 is used to compress and encrypt the preprocessed system logs and business logs, and upload the compressed and encrypted system logs and business logs to the AI-based big model-based natural language analysis module on the cloud server through a secure transmission protocol.

[0211] In this embodiment, the natural language analysis module 60 based on the AI ​​large model includes: The log parsing unit 601 is used to input the system log and the business log into the trained fault analysis model, use the fault analysis model to understand the semantics of the log text, and automatically generate one or more tags describing the meaning of each log segment. The cause matching unit 602 is used to aggregate the log sequence marked with the meaning of the content according to the time order and correlation to form an event chain, match the event chain with the fault mode in the knowledge base, perform causal reasoning on the successfully matched event chain based on the fault analysis model, identify the log event of the root cause, and output a diagnostic conclusion including fault type, fault cause, device of occurrence and judgment basis. The report generation unit 603 is used to integrate the diagnostic conclusions, relevant key log fragments and their meaning annotations, and event chain visualization information to generate a structured fault analysis and location report. The fault analysis and location report is then pushed to the fault reasoning and diagnosis module based on the AI ​​big model through a message queue or remote procedure call interface.

[0212] In this embodiment, the fault reasoning and diagnosis module 70 based on the AI ​​large model includes: The maintenance notification unit 701 is used to parse the fault analysis and location report, extract the fault type and fault cause from the fault analysis and location report, determine the relevant maintenance personnel who need to be notified according to preset rules, and send a notification message to the relevant maintenance personnel via email, instant messaging tools or operation and maintenance alarm platform. The message contains at least the fault type, fault cause and report link. The feedback receiving unit 702 is used to provide an interactive feedback interface to the relevant maintenance personnel while sending a notification, and to collect the relevant maintenance personnel's confirmation information on the fault analysis, supplementary explanations, records of handling measures, or opinions on the correction of the analysis results through the interactive feedback interface. The optimization learning unit 703 is used to perform structured processing on the collected feedback information, associate the processed feedback information with the corresponding original fault analysis and location report, and store it as labeled training data. The stored feedback data is used periodically to incrementally train or fine-tune the AI-based natural language analysis module and / or the trained fault analysis model to optimize the analysis and reasoning capabilities.

[0213] This invention designs different AI agent modules to form an intelligent operation and maintenance system. Through this solution, the labor cost and capability threshold of operation and maintenance are automatically reduced. At the same time, the intelligent operation and maintenance system minimizes the consumption of IT resources for operation and maintenance through the enhanced design of AI agents.

[0214] Furthermore, such as Figure 15 As shown, based on the above-mentioned OS operation log processing method and system based on AI large model, the present invention also provides a terminal, which includes a processor 10, a memory 20 and a display 30. Figure 15 Only some of the terminal components are shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0215] In some embodiments, the memory 20 may be an internal storage unit of the terminal, such as a hard drive or memory. In other embodiments, the memory 20 may be an external storage device of the terminal, such as a plug-in hard drive, smart media card (SMC), secure digital card (SD), flash card, etc. Further, the memory 20 may include both internal and external storage devices. The memory 20 is used to store application software and various types of data installed on the terminal, such as program code installed on the terminal. The memory 20 can also be used to temporarily store data that has been output or will be output. In one embodiment, the memory 20 stores an OS runtime log processing program 40 based on an AI large model, which can be executed by the processor 10 to implement the OS runtime log processing method based on an AI large model in this application.

[0216] In some embodiments, the processor 10 may be a central processing unit (CPU), a microprocessor, or other data processing chip, used to run program code stored in the memory 20 or process data, such as executing the OS runtime log processing method based on the AI ​​large model.

[0217] In some embodiments, the display 30 may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen. The display 30 is used to display information on the terminal and to display a visual user interface. The terminal's processor 10, memory 20, and display 30 communicate with each other via a system bus.

[0218] In one embodiment, when the processor 10 executes the OS runtime log processing program 40 based on the AI ​​large model in the memory 20, the following steps are performed: The log search engine receives instructions from the natural language analysis module based on the AI ​​big model, collects system logs and business logs from multiple target devices in the OS cluster, and uploads the OS's system logs and business logs to the cloud server through the log search engine. The AI-based big data natural language analysis module annotates the meaning of each log segment according to the system log and the business log, combines the trained fault analysis model to infer the fault that has occurred, locate the cause of the fault, obtain a fault analysis and location report, and sends it to the AI-based big data fault reasoning and diagnosis module. The fault reasoning and diagnosis module based on the AI ​​big model notifies the relevant maintenance personnel based on the fault type and cause in the fault analysis and location report, automatically collects feedback information from the relevant maintenance personnel, and inputs the feedback information into the natural language analysis module based on the AI ​​big model.

[0219] The log search engine receives instructions from the natural language analysis module based on an AI large model, collects system logs and business logs from multiple target devices in the OS cluster, and uploads the OS's system logs and business logs to the cloud server through the log search engine. Prior to this, it also includes: Each target device in the OS cluster is assigned a unique SN number in advance, and the system logs and business logs corresponding to each target device are marked with the SN number.

[0220] The system log and the business log both include a file header and a file content; the file header includes: SN number, timestamp of log occurrence, process ID of the business, thread ID of the business, log level, key code identifier, and log content.

[0221] The log search engine receives instructions from the natural language analysis module based on an AI large model, collects system logs and business logs from multiple target devices in the OS cluster, and uploads the OS's system logs and business logs to the cloud server through the log search engine. Specifically, this includes: The log search engine receives log collection instructions from the natural language analysis module based on an AI large model in the cloud server, parses the log collection instructions, and determines the target device identifier, log type, time range, and filter keywords to be collected. Based on the parsing results, the log search engine initiates log collection requests to the corresponding target devices in the OS cluster, and receives system logs and business logs from each target device in real time or in batches according to a predetermined period. The log search engine performs standardized preprocessing on the collected system logs and business logs. The standardized preprocessing includes at least format unification, timestamp synchronization, and invalid data filtering. The log search engine compresses and encrypts the preprocessed system logs and business logs, and uploads the compressed and encrypted system logs and business logs to the AI-based big data natural language analysis module on the cloud server through a secure transmission protocol.

[0222] The fault analysis and location report includes the fault type, fault cause, equipment involved, and judgment criteria.

[0223] Specifically, the AI-based large-scale natural language analysis module annotates the meaning of each log segment based on the system logs and business logs, combines this with a trained fault analysis model to infer the occurrence of faults, locate the cause of the fault, obtain a fault analysis and location report, and sends it to the AI-based large-scale fault reasoning and diagnosis module. This includes: The AI-based natural language analysis module inputs the system logs and business logs into the trained fault analysis model, uses the fault analysis model to understand the semantics of the log text, and automatically generates one or more tags describing the meaning of each log segment. The AI-based natural language analysis module aggregates log sequences labeled with content meaning according to time order and correlation to form event chains. It then matches these event chains with fault patterns in the knowledge base. Based on the fault analysis model, it performs causal reasoning on the successfully matched event chains to identify the log events that are the root cause and outputs a diagnostic conclusion that includes the fault type, fault cause, the device that experienced the fault, and the basis for judgment. The AI-based big data natural language analysis module integrates the diagnostic conclusions, relevant key log fragments and their meaning annotations, and event chain visualization information to generate a structured fault analysis and location report. The fault analysis and location report is then pushed to the AI-based big data fault reasoning and diagnosis module via a message queue or remote procedure call interface.

[0224] The tags include at least one or more of the following: log level, service module, operation type, and event type.

[0225] Specifically, the fault reasoning and diagnosis module based on the AI ​​large model notifies relevant maintenance personnel of the fault type and cause in the fault analysis and location report, automatically collects feedback information from relevant maintenance personnel, and inputs the feedback information into the natural language analysis module based on the AI ​​large model, including: The fault reasoning and diagnosis module based on the AI ​​big model parses the fault analysis and location report, extracts the fault type and fault cause from the fault analysis and location report, determines the relevant maintenance personnel who need to be notified according to preset rules, and sends a notification message to the relevant maintenance personnel through email, instant messaging tools or operation and maintenance alarm platform. The message contains at least the fault type, fault cause and report link. The fault reasoning and diagnosis module based on the AI ​​big model provides an interactive feedback interface to the relevant maintenance personnel while sending the notification. The interactive feedback interface collects the relevant maintenance personnel's confirmation information on the fault analysis, supplementary explanations, records of handling measures, or opinions on correcting the analysis results. The fault reasoning and diagnosis module based on the AI ​​large model performs structured processing on the collected feedback information, associates the processed feedback information with the corresponding original fault analysis and location report, and stores it as labeled training data. The stored feedback data is used periodically to incrementally train or fine-tune the natural language analysis module based on the AI ​​large model and / or the trained fault analysis model to optimize the analysis and reasoning capabilities.

[0226] The fault reasoning and diagnosis module based on the AI ​​big data model notifies the relevant maintenance personnel according to the fault type and cause in the fault analysis and location report. Previously, it also included: The fault reasoning and diagnosis module based on the AI ​​large model determines whether it is necessary to notify the relevant maintenance personnel based on the fault analysis and location report.

[0227] The fault reasoning and diagnosis module based on the AI ​​large model determines whether to notify the relevant maintenance personnel based on the fault analysis and location report, and then includes: If the fault reasoning and diagnosis module based on the AI ​​big model determines, based on the fault analysis and location report, that it is not necessary to notify the relevant maintenance personnel, then the fault reasoning and diagnosis module based on the AI ​​big model will directly feed back to the natural language analysis module based on the AI ​​big model for autonomous maintenance.

[0228] The process of uploading system logs and business logs of the OS to the cloud server via a log search engine previously included: At the edge or on the device itself, a lightweight AI model is used to perform preliminary analysis and filtering of the system logs and the business logs; The relevant critical logs and context are only uploaded to the cloud server when a potential anomaly is identified or a specific trigger condition is met; otherwise, they are archived or discarded locally.

[0229] The OS runtime log processing method based on the AI ​​large model also includes: When the fault cause located by the fault reasoning and diagnosis module based on the AI ​​large model belongs to a known type that allows for automatic repair, an automated repair script is generated. After authorization is obtained, the automated repair script is sent to and executed on the target device through the log search engine.

[0230] The target devices in the OS cluster include cloud-connectable devices and cloud-non-directly-connectable devices.

[0231] The OS runtime log processing method based on the AI ​​large model also includes: When the target device is a cloud-connectable device, the system logs and business logs of the cloud-connectable device are directly transmitted to the cloud-side server through the log search engine. When the target device is a device that cannot be directly connected to the cloud, the system logs and business logs of the device that cannot be directly connected to the cloud are first transmitted to the device that can be connected to the cloud through the log collection engine, and then transmitted to the cloud-side server through the log collection engine.

[0232] The present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores an OS runtime log processing program based on an AI large model, and the OS runtime log processing program based on an AI large model, when executed by a processor, implements the steps of the OS runtime log processing method based on an AI large model as described above.

[0233] In summary, this invention provides a method, system, terminal, and computer-readable storage medium for processing OS runtime logs based on an AI-based big data model. The method includes: a log search engine receiving instructions from a natural language processing module based on an AI-based big data model; collecting system logs and business logs from multiple target devices in an OS cluster; and uploading the OS runtime system logs and business logs to a cloud server via the log search engine. The AI-based big data model's natural language processing module annotates the meaning of each log segment based on the system logs and business logs, combines this with a trained fault analysis model to infer the occurrence of faults, locate the cause of the fault, obtain a fault analysis and location report, and sends it to a fault reasoning and diagnosis module based on an AI-based big data model. The AI-based big data model's fault reasoning and diagnosis module notifies relevant maintenance personnel based on the fault type and cause in the fault analysis and location report, automatically collects feedback information from relevant maintenance personnel, and inputs the feedback information into the AI-based big data model's natural language processing module. This invention utilizes an AI-based big data model to process OS runtime logs, proposing an intelligent operation and maintenance system based on an AI-based big data model, significantly reducing the manpower required throughout the operation and maintenance process, and also greatly lowering the technical threshold for manual intervention.

[0234] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal that includes that element.

[0235] Of course, those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.). The program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The computer-readable storage medium can be a memory, magnetic disk, optical disk, etc.

[0236] It should be understood that the application of the present invention is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.< / timestamp> < / username>

Claims

1. A method for processing OS runtime logs based on an AI large model, characterized in that, The OS runtime log processing method based on the AI ​​large model includes: The log search engine receives instructions from the natural language analysis module based on the AI ​​big model, collects system logs and business logs from multiple target devices in the OS cluster, and uploads the OS's system logs and business logs to the cloud server through the log search engine. The AI-based big data natural language analysis module annotates the meaning of each log segment according to the system log and the business log, combines the trained fault analysis model to infer the fault that has occurred, locate the cause of the fault, obtain a fault analysis and location report, and sends it to the AI-based big data fault reasoning and diagnosis module. The fault reasoning and diagnosis module based on the AI ​​big model notifies the relevant maintenance personnel based on the fault type and cause in the fault analysis and location report, automatically collects feedback information from the relevant maintenance personnel, and inputs the feedback information into the natural language analysis module based on the AI ​​big model.

2. The OS runtime log processing method based on AI large model according to claim 1, characterized in that, The log search engine receives instructions from the natural language analysis module based on an AI large model, collects system logs and business logs from multiple target devices in the OS cluster, and uploads the OS's system logs and business logs to the cloud server through the log search engine. Prior to this, it also includes: Each target device in the OS cluster is assigned a unique SN number in advance, and the system logs and business logs corresponding to each target device are marked with the SN number.

3. The OS runtime log processing method based on AI large model according to claim 1, characterized in that, Both the system log and the business log include a file header and a file content; the file header includes: SN number, timestamp of the log occurrence, process ID of the business, thread ID of the business, log level, key code identifier, and log content.

4. The OS runtime log processing method based on an AI large model according to claim 1 or 3, characterized in that, The log search engine receives instructions from the natural language analysis module based on an AI large model, collects system logs and business logs from multiple target devices in the OS cluster, and uploads the OS's system logs and business logs to the cloud server through the log search engine. Specifically, this includes: The log search engine receives log collection instructions from the natural language analysis module based on the AI ​​large model in the cloud server, parses the log collection instructions, and determines the target device identifier, log type, time range, and filter keywords to be collected. Based on the parsing results, the log search engine initiates log collection requests to the corresponding target devices in the OS cluster, and receives system logs and business logs from each target device in real time or in batches according to a predetermined period. The log search engine performs standardized preprocessing on the collected system logs and business logs. The standardized preprocessing includes at least format unification, timestamp synchronization, and invalid data filtering. The log search engine compresses and encrypts the preprocessed system logs and business logs, and uploads the compressed and encrypted system logs and business logs to the AI-based big data natural language analysis module on the cloud server through a secure transmission protocol.

5. The OS runtime log processing method based on AI large model according to claim 1, characterized in that, The fault analysis and location report includes the fault type, fault cause, equipment involved, and judgment basis.

6. The OS runtime log processing method based on AI large model according to claim 5, characterized in that, The AI-based large-scale natural language analysis module annotates the meaning of each log segment based on the system logs and business logs, combines this with a trained fault analysis model to infer the occurrence of faults, locate the cause of the fault, obtain a fault analysis and location report, and sends it to the AI-based large-scale fault reasoning and diagnosis module. Specifically, this includes: The AI-based natural language analysis module inputs the system logs and business logs into the trained fault analysis model, uses the fault analysis model to understand the semantics of the log text, and automatically generates one or more tags describing the meaning of each log segment. The AI-based natural language analysis module aggregates log sequences labeled with content meaning according to time order and correlation to form event chains. It then matches these event chains with fault patterns in the knowledge base. Based on the fault analysis model, it performs causal reasoning on the successfully matched event chains to identify the log events that are the root cause and outputs a diagnostic conclusion that includes the fault type, fault cause, the device that experienced the fault, and the basis for judgment. The AI-based big data natural language analysis module integrates the diagnostic conclusions, relevant key log fragments and their meaning annotations, and event chain visualization information to generate a structured fault analysis and location report. The fault analysis and location report is then pushed to the AI-based big data fault reasoning and diagnosis module via a message queue or remote procedure call interface.

7. The OS runtime log processing method based on AI large model according to claim 6, characterized in that, The tags include at least one or more of the following: log level, service module, operation type, and event type.

8. The OS runtime log processing method based on AI large model according to claim 6, characterized in that, The fault reasoning and diagnosis module based on the AI ​​big data model notifies relevant maintenance personnel of the fault type and cause in the fault analysis and location report, automatically collects feedback information from relevant maintenance personnel, and inputs the feedback information into the natural language analysis module based on the AI ​​big data model, specifically including: The fault reasoning and diagnosis module based on the AI ​​big model parses the fault analysis and location report, extracts the fault type and fault cause from the fault analysis and location report, determines the relevant maintenance personnel who need to be notified according to preset rules, and sends a notification message to the relevant maintenance personnel through email, instant messaging tools or operation and maintenance alarm platform. The message contains at least the fault type, fault cause and report link. The fault reasoning and diagnosis module based on the AI ​​big model provides an interactive feedback interface to the relevant maintenance personnel while sending the notification. The interactive feedback interface collects the relevant maintenance personnel's confirmation information on the fault analysis, supplementary explanations, records of handling measures, or opinions on correcting the analysis results. The fault reasoning and diagnosis module based on the AI ​​large model performs structured processing on the collected feedback information, associates the processed feedback information with the corresponding original fault analysis and location report, and stores it as labeled training data. The stored feedback data is used periodically to incrementally train or fine-tune the natural language analysis module based on the AI ​​large model and / or the trained fault analysis model to optimize the analysis and reasoning capabilities.

9. The OS runtime log processing method based on AI large model according to claim 1, characterized in that, The fault reasoning and diagnosis module based on the AI ​​large model notifies the relevant maintenance personnel according to the fault type and cause in the fault analysis and location report. Previously, it also included: The fault reasoning and diagnosis module based on the AI ​​large model determines whether it is necessary to notify the relevant maintenance personnel based on the fault analysis and location report.

10. The OS runtime log processing method based on an AI large model according to claim 9, characterized in that, The fault reasoning and diagnosis module based on the AI ​​large model determines whether to notify the relevant maintenance personnel based on the fault analysis and location report, and then includes: If the fault reasoning and diagnosis module based on the AI ​​big model determines, based on the fault analysis and location report, that it is not necessary to notify the relevant maintenance personnel, then the fault reasoning and diagnosis module based on the AI ​​big model will directly feed back to the natural language analysis module based on the AI ​​big model for autonomous maintenance.

11. The OS runtime log processing method based on AI large model according to claim 1, characterized in that, The process of uploading system logs and business logs of the OS to the cloud server via a log search engine previously included: At the edge or on the device itself, a lightweight AI model is used to perform preliminary analysis and filtering of the system logs and the business logs; The relevant critical logs and context are only uploaded to the cloud server when a potential anomaly is identified or a specific trigger condition is met; otherwise, they are archived or discarded locally.

12. The OS runtime log processing method based on AI large model according to claim 1, characterized in that, The OS runtime log processing method based on the AI ​​large model also includes: When the fault cause located by the fault reasoning and diagnosis module based on the AI ​​large model belongs to a known type that allows for automatic repair, an automated repair script is generated. After authorization is obtained, the automated repair script is sent to and executed on the target device through the log search engine.

13. The OS runtime log processing method based on AI large model according to claim 1, characterized in that, The target devices in the OS cluster include cloud-connectable devices and cloud-non-directly-connectable devices.

14. The OS runtime log processing method based on an AI large model according to claim 13, characterized in that, The OS runtime log processing method based on the AI ​​large model also includes: When the target device is a cloud-connectable device, the system logs and business logs of the cloud-connectable device are directly transmitted to the cloud-side server through the log search engine. When the target device is a device that cannot be directly connected to the cloud, the system logs and business logs of the device that cannot be directly connected to the cloud are first transmitted to the device that can be connected to the cloud through the log collection engine, and then transmitted to the cloud-side server through the log collection engine.

15. An OS runtime log processing system based on an AI large-scale model, characterized in that, The OS runtime log processing system based on the AI ​​large model includes: The log search engine receives instructions from the natural language analysis module based on the AI ​​large model, collects system logs and business logs from multiple target devices in the OS cluster, and uploads the OS's system logs and business logs to the cloud server through the log search engine. The AI-based large-scale natural language analysis module is used to annotate the meaning of each log segment based on the system log and the business log, combine the trained fault analysis model to infer the faults that have occurred, locate the cause of the fault, obtain a fault analysis and location report, and send it to the AI-based large-scale fault reasoning and diagnosis module. The fault reasoning and diagnosis module based on the AI ​​big model is used to notify relevant maintenance personnel based on the fault type and fault cause in the fault analysis and location report, automatically collect feedback information from relevant maintenance personnel, and input the feedback information into the natural language analysis module based on the AI ​​big model.

16. The OS runtime log processing system based on an AI large model according to claim 15, characterized in that, The log search engine includes: The instruction receiving unit is used to receive log collection instructions from the natural language analysis module based on the AI ​​large model in the cloud server, parse the log collection instructions, and determine the target device identifier, log type, time range, and filter keywords to be collected. The log collection unit is used to initiate log collection requests to the corresponding target devices in the OS cluster based on the parsing results, and to receive system logs and business logs from each target device in real time or in batches according to a predetermined period. The log preprocessing unit is used to perform standardized preprocessing on the collected system logs and business logs. The standardized preprocessing includes at least format unification, timestamp synchronization, and invalid data filtering. The log transmission unit is used to compress and encrypt the preprocessed system logs and business logs, and upload the compressed and encrypted system logs and business logs to the AI-based big model-based natural language analysis module on the cloud server through a secure transmission protocol.

17. The OS runtime log processing system based on an AI large model according to claim 15, characterized in that, The AI-based large-scale natural language analysis module includes: The log parsing unit is used to input the system logs and the business logs into the trained fault analysis model, use the fault analysis model to understand the semantics of the log text, and automatically generate one or more tags describing the meaning of each log segment. The cause matching unit is used to aggregate log sequences labeled with content meanings according to time order and correlation to form an event chain, match the event chain with the fault modes in the knowledge base, perform causal reasoning on the successfully matched event chains based on the fault analysis model, identify the log events of the root cause, and output a diagnostic conclusion including fault type, fault cause, device of occurrence, and judgment basis. The report generation unit is used to integrate the diagnostic conclusions, relevant key log fragments and their meaning annotations, and event chain visualization information to generate a structured fault analysis and location report. The fault analysis and location report is then pushed to the fault reasoning and diagnosis module based on the AI ​​big model via a message queue or remote procedure call interface.

18. The OS runtime log processing system based on an AI large model according to claim 15, characterized in that, The fault reasoning and diagnosis module based on the AI ​​large model includes: The maintenance notification unit is used to parse the fault analysis and location report, extract the fault type and fault cause from the fault analysis and location report, determine the relevant maintenance personnel who need to be notified according to preset rules, and send a notification message to the relevant maintenance personnel via email, instant messaging tools or operation and maintenance alarm platform. The message contains at least the fault type, fault cause and report link. The feedback receiving unit is used to provide an interactive feedback interface to the relevant maintenance personnel while sending a notification. The interactive feedback interface is used to collect the relevant maintenance personnel's confirmation information on the fault analysis, supplementary explanations, records of handling measures, or opinions on the correction of the analysis results. The optimization learning unit is used to perform structured processing on the collected feedback information, associate the processed feedback information with the corresponding original fault analysis and location report, and store it as labeled training data. The stored feedback data is used periodically to incrementally train or fine-tune the AI-based natural language analysis module and / or the trained fault analysis model to optimize the analysis and reasoning capabilities.

19. A terminal, characterized in that, The terminal includes: a memory, a processor, and an OS runtime log processing program based on an AI large model stored in the memory and executable on the processor. When the OS runtime log processing program based on an AI large model is executed by the processor, it implements the steps of the OS runtime log processing method based on an AI large model as described in any one of claims 1-14.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an OS runtime log processing program based on an AI large model, which, when executed by a processor, implements the steps of the OS runtime log processing method based on an AI large model as described in any one of claims 1-14.

Images