Log data analysis method, system and equipment and computer readable storage medium

Abstract

The invention relates to the technical field of data analysis, in particular to a log data analysis method, system and device and a computer readable storage medium, and the method comprises the steps: obtaining key logs output by each node in a cluster and node information of the node, and achieving the real-time monitoring of the running state of the node; key logs are classified, target logs with partition faults are screened out, and fault related records are accurately focused; carrying out topology analysis on the partition faults, generating a network topology relation graph of the partition faults, and realizing a visual fault partition structure; time sorting is carried out on the partition faults, a timeline analysis report of the partition faults is formed, and a key time node and an evolution path are visually positioned; according to the network topology relation graph and the timeline analysis report, the partition fault is subjected to fault analysis, the fault analysis result is obtained, the partition fault root cause is accurately positioned, and the high efficiency of fault event root cause analysis is guaranteed.

Description

Technical Field

[0001] This application relates to the field of data analysis technology, and in particular to a log data analysis method, system, device, and computer-readable storage medium. Background Technology

[0002] As businesses continue to expand, RabbitMQ (Rabbit Message Queue), as the core middleware supporting message flow, is often deployed in a clustered manner to meet the requirements of high availability and high throughput. It is widely used in key business scenarios such as order processing, notification push, and data synchronization.

[0003] During the operation of a RabbitMQ cluster, partition failure is a typical and significantly harmful anomaly. Such failures can cause the cluster to split into multiple independent small clusters due to issues such as network interruption between nodes, excessive latency, or packet loss. This can lead to a chain of problems, such as interrupted message routing, backlog of queued messages, and disconnection of business services that depend on messages. Therefore, quickly completing the root cause analysis of failure events is a key step in shortening the failure impact cycle and reducing business losses.

[0004] However, root cause analysis for RabbitMQ cluster partition failures still relies on manual methods by operations and maintenance personnel. Due to limitations in personnel efficiency and multi-node data processing capabilities, in enterprise-level scenarios with a large number of cluster nodes (such as more than 8 nodes), it often takes 3 to 5 hours or even longer to complete the root cause analysis. This not only fails to meet the core requirement of enterprises to "quickly stop losses" from failures, but may also lead to an expansion of message backlog and a spread of core business interruption due to the prolonged duration of the failure, which may seriously affect business continuity.

[0005] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The main purpose of this application is to provide a log data analysis method, apparatus, device, and storage medium, which aims to solve the technical problem of insufficient efficiency in root cause analysis of fault events in partitioned fault scenarios.

[0007] To achieve the above objectives, this application provides a log data analysis method, which includes:

[0008] Obtain key logs output by each node in the cluster and node information, including fault node information involved in the partition failure and preset fault event types.

[0009] Based on fault node information and preset fault event types, key logs are classified and target logs for partition faults are filtered out.

[0010] Based on the timestamps and node information of the target logs, perform topology analysis on the partition fault and generate a network topology diagram of the partition fault;

[0011] Based on the timestamps of the target logs and the preset fault event types, the partition faults are analyzed over time to generate a timeline analysis report of the partition faults;

[0012] Based on the network topology diagram and timeline analysis report, fault analysis was performed on the partition faults, and the fault analysis results were obtained.

[0013] Furthermore, to achieve the above objectives, this application also provides a log data analysis system, which includes:

[0014] The data acquisition module is used to acquire key logs output by each node in the cluster and node information, including fault node information involved in the partition failure and preset fault event types.

[0015] The log classification module is used to classify key logs based on fault node information and preset fault event types, and filter out target logs for partition faults.

[0016] The topology analysis module is used to perform topology analysis on partition faults based on the timestamps and node information of the target logs, and generate a network topology diagram of the partition faults.

[0017] The time analysis module is used to analyze partition failures based on the timestamps of the target logs and preset failure event types, and generate a timeline analysis report of the partition failures.

[0018] The fault analysis module is used to perform fault analysis on partition faults based on the network topology diagram and timeline analysis report, and obtain the fault analysis results.

[0019] Each functional module of the log data analysis system of this application implements the steps of the log data analysis method of this application as described above during runtime.

[0020] In addition, to achieve the above objectives, this application also provides a log data analysis device, which includes a memory, a processor, and a log data analysis program stored in the memory and executable on the processor. When the log data analysis program is executed by the processor, it implements the steps of the above-described log data analysis method.

[0021] In addition, to achieve the above objectives, this application also provides a storage medium, which is a computer-readable storage medium, on which a log data analysis program is stored, and when the log data analysis program is executed by a processor, it implements the steps of the above-described log data analysis method.

[0022] This application provides a log data analysis method. By acquiring key logs output by each node in the cluster and node information, it achieves real-time monitoring of node operating status and rapid identification of abnormal nodes. Key logs are categorized, and target logs of partitioned faults are filtered out to eliminate redundant information and accurately focus on fault-related records, improving fault identification efficiency and accuracy. Topology analysis of partitioned faults generates a network topology diagram, visualizing the fault partition structure and intuitively locating the fault range, improving analysis efficiency. Time-based analysis of partitioned faults generates a timeline analysis report, clarifying the correlation of fault events among nodes, intuitively locating key time nodes and evolution paths, and accelerating the efficiency of root cause analysis and review. Based on the network topology diagram and timeline analysis report, fault analysis is performed on the partitioned faults to obtain the analysis results, accurately locating the root cause of the partitioned faults and ensuring the high efficiency of root cause analysis. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating the first embodiment of the log data analysis method of this application;

[0024] Figure 2 This is a schematic diagram of the RabbitMQ deployment architecture involved in this application;

[0025] Figure 3 This is a schematic diagram of the network partitioning topology analysis architecture involved in this application;

[0026] Figure 4 This is a schematic diagram of the log data analysis system involved in the embodiments of this application;

[0027] Figure 5 This is a schematic diagram of the log data analysis device involved in the embodiments of this application.

[0028] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0029] This application provides a log data analysis method, referring to... Figure 1 As shown, Figure 1 This is a flowchart illustrating the first embodiment of the log data analysis method of this application.

[0030] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0031] Currently, troubleshooting network partition faults in RabbitMQ mainly relies on manual operations by maintenance personnel. The core process can be divided into two categories: First, maintenance personnel obtain node information or query node logs through RabbitMQ's API (Application Programming Interface) to observe network partition-related fault logs and thus determine the topological relationship between network partitions between nodes. Second, it is necessary to manually review the node logs line by line to fully summarize the various time points of a single fault.

[0032] However, this approach has significant shortcomings in enterprise-level scenarios: First, it lacks efficiency, as manually querying APIs and sorting logs is time-consuming and the fault analysis cycle is long, making it difficult to meet the rapid fault response requirements of enterprises; second, it lacks reliability, as manual review of key logs can easily lead to misjudgment of topology relationships and omission of time nodes, affecting the accuracy of fault attribution; third, it lacks a proactive protection mechanism, requiring operations and maintenance to passively investigate faults, lacking real-time alerts, and prolonging the impact time of faults.

[0033] Therefore, there is an urgent need to build a RabbitMQ network partition fault analysis scheme that can automatically parse node topology, sort out fault timelines, and improve the efficiency and reliability of analysis. This application provides a log data analysis method, device, equipment and storage medium.

[0034] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, database system, etc., or a device capable of performing the above functions, such as a log data analysis device. The following description uses a log data analysis device as an example to illustrate this embodiment and the subsequent embodiments.

[0035] The log data analysis method of this application includes the following implementation steps S10 to S50.

[0036] Step S10: Obtain the key logs output by each node in the cluster and the node information of the nodes, including the fault node information involved in the partition failure and the preset fault event type.

[0037] In this embodiment, as an example, the application scenario can be a distributed cluster deployed across regions.

[0038] Optionally, distributed clusters deployed across regions include, but are not limited to, RabbitMQ clusters, such as... Figure 2 As shown, Figure 2 This is a schematic diagram of the RabbitMQ deployment architecture involved in this application. Figure 2 The document labels the access application, load balancer, and RabbitMQ cluster. The RabbitMQ cluster consists of three RabbitMQ nodes (1, 2, and 3), each equipped with a processor, network communication module, and non-transitory computer-readable storage media. The access application refers to a client application or business module that needs to interact with the RabbitMQ cluster; it is not a single software but a collection of business-related clients. The load balancer is an intermediate scheduling component deployed between the access application and the RabbitMQ cluster, its core function being traffic distribution and high availability assurance. In the following descriptions, load balancer is equivalent to a load balancer. The access application connects to the load balancer via a network link. The load balancer forwards message requests to the nodes of the RabbitMQ cluster using a preset routing strategy. RabbitMQ nodes 1-3 interact using Erlang's distributed communication mechanism, thereby achieving traffic distribution, node load control, and automatic failover in case of node failure. It should be noted that Erlang's distributed communication mechanism establishes TCP (Transmission Control Protocol) through the node network module. Protocol (Transmission Control Protocol) is the core mechanism for connecting, synchronizing cluster metadata, maintaining node heartbeats and message routing status, ensuring that the three nodes form a unified cluster to provide services to the outside world. This architecture not only improves the overall throughput and availability of the system, but also provides a clear access path and node relationship foundation for subsequent log collection, fault monitoring and topology analysis.

[0039] In actual operation, three types of reasons may cause RabbitMQ node communication interruption and trigger partition failure: network level (such as switch failure, node communication module damage) disconnecting TCP connection; resource level (such as node processor utilization exceeding 90% for 1 minute) blocking Erlang process; configuration level (such as port 4369 being blocked) preventing initial connection; after the interruption, nodes 1 and 2 and 3 lose connection, resulting in two "survival clusters". Due to untimely health checks, the load balancer mistakenly distributes message requests to the RabbitMQ faulty node, causing message duplication, loss or time sequence disorder. At this time, the local logs of each RabbitMQ node will record key information of the cluster partition, including the faulty node identifier, partition timestamp, node communication status, etc., to provide a basis for fault location.

[0040] Optionally, such as Figure 3 As shown, Figure 3This diagram illustrates the network partition topology analysis architecture involved in this application. The architecture includes a RabbitMQ cluster (containing three nodes: Node 1, Node 2, and Node 3), a log collection module, an event analysis module, a topology analysis module, a timeline analysis module, and a notification module. The log collection module acquires node information and raw logs from nodes 1 to 3 at preset intervals. The raw logs include critical logs, which are then filtered and sent to the event analysis module. The event analysis module parses the fault event type and fault node identifier, synchronizes them to the topology analysis module and the timeline analysis module, and transmits preliminary results to the notification module. The topology analysis module generates a fault topology map based on node association information, and the timeline analysis module outputs a time-series report. The results from both are integrated by the event analysis module and then pushed to the operation and maintenance terminal by the notification module. This architecture, through module division of labor and collaboration, shortens the log collection to topology analysis cycle from the traditional 1-2 hours to less than 10 minutes. The topology analysis module automatically identifies node interruption links, avoiding errors from manual drawing. The notification module pushes results in real time, solving the problems of delayed fault analysis and inaccurate topology construction in traditional architectures, ensuring that operation and maintenance personnel can quickly locate the partition range.

[0041] In this embodiment, key logs output by each node in the cluster and node information are obtained. The node information includes fault node information involved in the partition failure and preset failure event types, reflecting the abnormal state of node communication, data synchronization or cluster topology. Unrelated regular operation logs are excluded, providing complete data support for subsequent screening of partition failure target logs, avoiding the disconnect between logs and node failure correlation information, and ensuring that subsequent analysis can accurately locate fault nodes and corresponding abnormal types.

[0042] Optionally, critical logs refer to service operation logs output by cluster nodes that include timestamps and fault descriptions, and core entries for the fault period need to be filtered; fault node information includes the fault node IP (Internet Protocol), operating status, and a list of neighboring nodes; preset fault event types refer to fault classifications with clear characteristics that are predefined based on common fault causes in RabbitMQ clusters, used to accurately identify and classify abnormal events in cluster operation. Logs can then be filtered and fault frequency counted based on these preset types to help locate the root cause of partition faults.

[0043] Step S20: Based on the fault node information and preset fault event types, classify the key logs and filter out the target logs that caused the partition fault;

[0044] Optionally, the fault node information specifically refers to the fault node identifiers involved in the partition failure. The node processor first reads the fault node information and preset fault event types, calls the key logs stored in the non-transitory computer-readable storage medium, and performs preliminary filtering according to the preset fault time period; then, it matches the log keywords with the fault node IP and event type to remove irrelevant content such as normal heartbeat logs; finally, it verifies the filtering results to confirm the integrity of the logs containing fault node identifiers and event type descriptions, thereby accurately associating fault information with logs, avoiding missed judgments during manual screening, reducing the screening time from the traditional 1 hour to 5 minutes, and achieving high accuracy in target log coverage, providing accurate data for subsequent fault analysis.

[0045] Optionally, during the classification process, the fault node information is first used as the filtering condition to extract logs from the key logs of each node in the cluster whose log generation node identifier matches the fault node identifier, excluding the regular operation logs of non-fault nodes; then, based on the preset fault event type, the above-filtered logs are classified according to event characteristics. This method can accurately locate the target logs related to partition faults, avoid interference from irrelevant logs, and provide an accurate data foundation for subsequent extraction of key log information and construction of analysis datasets.

[0046] Step S30: Based on the timestamp and node information of the target log, perform topology analysis on the partition fault and generate a network topology diagram of the partition fault;

[0047] Optionally, based on the timestamps and node information of the target logs, topology analysis is performed on the partition fault to generate a network topology diagram of the partition fault. By relying on timestamp segmentation association and automatic topology drawing, the problem of time-consuming and error-prone traditional manual topology drawing is solved, and the efficiency of fault root cause location is improved.

[0048] Optionally, the target log timestamp refers to the UTC (Coordinated Universal Time) time at which the log was generated, used to anchor the fault timing; node information includes node IP, neighbor node list, and communication status; the preset topology update interval is 1 minute, the node association rule is that the normal state is connected with a solid line, the interrupted state is connected with a dashed line, and the fault node identifier color is preset to red.

[0049] Optionally, target logs within a preset time range are retrieved in ascending order of timestamps. The node identifier, communication status, and corresponding timestamp are extracted from each log entry. Duplicate logs are removed, and valid data is temporarily stored in a cache unit. The logs are then segmented by timestamp, and the communication status of each node within each segment is matched, recording the node relationships for that segment. Based on the segmented node relationships, the graph generation unit generates network topology diagrams for each time segment. The node association calculation unit is then called to verify the consistency between the node connections in the topology diagram and the target logs. If discrepancies exist, the log data is re-matched. After successful verification, the topology diagrams for each time segment are sorted by timestamp to generate a dynamic network topology diagram, which is simultaneously stored in the storage medium of the topology analysis module for later retrieval.

[0050] Step S40: Based on the timestamps of the target logs and the preset fault event types, perform time-based analysis of the partition faults to generate a timeline analysis report of the partition faults;

[0051] Optionally, based on the timestamps of the target logs and the preset fault event types, the partition faults are sorted out over time to form a timeline analysis report of the partition faults. This solves the problems of time-consuming and easy omissions in traditional manual sorting. Compared with the messy manual log records, the readability and traceability of the report are significantly improved, ensuring the efficiency of fault review.

[0052] Optionally, to meet the fault analysis needs in cluster network partition scenarios, the timeline analysis report should first define the scope of log collection, covering network connection logs, service heartbeat logs, resource scheduling logs, etc. of each node. Based on the NTP (Network Time Protocol), all log timestamps should be calibrated to ensure time sequence consistency. Then, the reports should be classified and labeled according to preset fault event types. Finally, the events should be linked in chronological order, and the nodes where the events occurred, related services, and the relationship between the fault phenomena should be labeled. This can quickly locate the partition start / recovery time, shorten the fault tracing cycle, clearly present the fault propagation path, improve the accuracy of root cause location, and quantify the fault impact range at different stages, providing data support for fault review.

[0053] Optionally, deploy tools such as Fluentd (a log collection and forwarding tool) to collect cluster node logs in real time, and synchronize the time of all nodes through the NTP service; use a rule engine (such as Logstash (a log processing tool) of ELKStack (Elasticsearch, Logstash, Kibana Stack: Elasticsearch, Logstash, Kibana technology stack)) to label the fault type according to event characteristics; store the processed data in the InfluxDB time series database, sort it by timestamp to build a timeline; visualize the timeline through Grafana (Grafana, a data visualization platform), associate the cluster topology with the partition nodes, and finally generate an analysis report containing event sequences, node status, and service impact.

[0054] Step S50: Based on the network topology diagram and timeline analysis report, perform fault analysis on the partition faults and obtain the fault analysis results.

[0055] Optionally, based on the node association information in the network topology diagram and the fault timing information in the timeline analysis report, fault analysis is performed on the partition faults to obtain the fault analysis results. This enables efficient integration of topology and timing information to analyze faults and achieves high efficiency in root cause analysis of fault events.

[0056] Optionally, network topology node association information includes, but is not limited to, node hierarchy, core / edge node roles, and inter-node communication link types. Fault analysis results need to integrate network topology node association information with the fault sequence in the timeline report, identify the fault initiation node, the propagation path and sequence through topology-related links, mark the impact range of core node failures on surrounding nodes, and verify the correspondence between fault repair order and topology link recovery in combination with the timeline. This allows for accurate location of the root cause node, clear presentation of the topological logic of fault propagation, rapid delineation of fault impact boundaries, reduction of ineffective troubleshooting scope, and improvement of fault analysis accuracy and efficiency.

[0057] Optionally, the cluster network topology map is imported into the fault analysis platform and associated with the fault data in the timeline analysis report; graph analysis algorithms are used to identify the fault initiation node and associated propagation links, and the fault occurrence / repair time of each node is marked by time series; the topology node status (fault / normal) and fault time series are overlaid and displayed in the platform, and fault analysis results containing root cause nodes, propagation paths, and impact range are automatically generated, and a visual analysis document is output.

[0058] In this embodiment, by acquiring key logs output by each node in the cluster and node information, the system achieves real-time monitoring of node operation status and rapid identification of abnormal nodes. Key logs are categorized, and target logs that have caused partition faults are filtered out, eliminating redundant information and accurately focusing on fault-related records, thus improving fault identification efficiency and accuracy. Topology analysis of partition faults generates a network topology diagram, visualizing the fault partition structure and intuitively locating the fault range, improving analysis efficiency. Time-based analysis of partition faults generates a timeline analysis report, clarifying the correlation of fault events among nodes, intuitively locating key time nodes and evolution paths, and accelerating the efficiency of root cause analysis and review of partition faults. Based on the node correlation information in the network topology diagram and the fault sequence information in the timeline analysis report, fault analysis is performed on the partition faults to obtain the analysis results, achieving accurate location of the root cause of the partition fault and ensuring the high efficiency of fault event root cause analysis.

[0059] Furthermore, based on the above, a second embodiment of the log data analysis method of this application is proposed. In some feasible embodiments, step S10 above: obtaining the key logs output by each node in the cluster and the node information of the nodes, further includes the following implementation steps B101 to B102.

[0060] Step B101: Obtain the key logs output by each node through the log collection channels of each node in the cluster. The log features in the key logs include preset log features, which include at least one of the following: features that record heartbeat timeouts between nodes, features that record network partitions, features that record network partitions in the Mnesia database, and features that record nodes marked as down.

[0061] Optionally, in a cluster partition failure scenario, key logs output by each node are obtained through the log collection channels of each node in the cluster. These key logs cover four types of core information: logs recording heartbeat timeouts between nodes must include the timeout node pair, timeout duration, and number of retries; logs recording the discovery of network partitions must indicate the partition detection mechanism, initial detection time, and initial partition node group; logs recording Mnesia database partitions must reflect the database table synchronization interruption status, affected table names, and partition node IDs; and logs recording nodes marked as down (failed) must include the marking trigger source, marking time, and associated nodes. This enables early detection of partition failures, rapid capture of initial fault signals through feature logs, accurate location of fault nodes and scope to avoid blind fault investigation, and clarification of fault correlations to provide direction for root cause analysis.

[0062] Optionally, deploy FluentBit (a lightweight log collection tool) as the log collection channel, configure the node log collection path, and focus on logs with characteristics such as heartbeat timeout, network partition, Mnesia partition, and node down; use Logstash to configure filtering rules to match keywords (such as "heartbeattimeout" and "networkpartitiondetected") to extract target logs; store the processed logs in Elasticsearch, associate them with node information, and build a dashboard using Kibana to display the target logs and the distribution of faulty nodes in real time.

[0063] Step B101: Obtain the node information of each node through the cluster management interface, where the node information includes at least the node identifier.

[0064] Optionally, node information includes at least a node identifier, which includes, but is not limited to, a node ID (Identifier). Node information obtained through the cluster management interface should include basic identifiers (such as node ID, hostname, IP address), role attributes (such as master / slave node, core service deployment status), operating status (such as online / offline, CPU / memory load), network configuration (such as subnet, gateway information, connected neighboring nodes), and relationships (such as service dependent nodes, data synchronization objects). This information provides a basic node profile for partition fault analysis, clarifies the location and function of each node in the cluster topology, and thus can quickly identify the node types involved in the fault. Combined with network configuration, the network boundary of the partition can be defined, the fault propagation path can be traced through neighboring node information, and the authenticity of the fault can be verified by comparing node status and log records, avoiding misjudgment due to a single signal.

[0065] Optionally, the cluster management interface (such as K8sAPI, OpenStackAPI) can be called to batch pull node information at 30-second intervals, specify the collection fields and store them in a structured manner in a time-series database; when a fault occurs, real-time synchronization is triggered to obtain the latest node status; the node information is associated with the log system through the node ID, and the node attributes, status and fault logs are displayed in the analysis platform to help locate key nodes and the scope of impact within the partition.

[0066] In this embodiment, by acquiring the key logs output by each node, the initial fault signal can be quickly captured, and the fault node and scope can be accurately located. By acquiring the node information of each node, the type of node involved in the fault can be quickly identified, providing technical support for subsequent fault location, thereby achieving high efficiency in root cause analysis of fault events.

[0067] Furthermore, based on the above, in some feasible embodiments, the preset synchronization method includes a multi-threaded synchronization method, and the above step S20 includes the following implementation steps B201-B202.

[0068] Step B201: According to the preset fault event types, classify the logs in the critical logs that belong to the heartbeat timeout event into the node communication anomaly category, the logs that belong to the cluster partition event into the cluster topology anomaly category, the logs that belong to the Mnesia partition event into the distributed database anomaly category, and the logs that belong to the node offline event into the node status anomaly category.

[0069] Optionally, in cluster partition failure scenarios, the key logs categorized according to preset failure event types include: node communication anomaly logs (including heartbeat timeout logs between nodes, recording the timeout node pairs, timeout duration, and number of retries); cluster topology anomaly logs (including cluster partition event logs, indicating the partition detection method, partition node grouping, and timing); distributed database anomaly logs (including Mnesia partition event logs, showing the database table synchronization interruption status, affected table names, and involved nodes); and node status anomaly logs (including node offline event logs, recording the triggering conditions for a node to be marked as down, the marking time, and associated judgment nodes). This achieves accurate classification of failure types, avoids analysis interference caused by mixed logs, clearly separates failure characteristics from different dimensions, facilitates targeted troubleshooting, and provides a structured foundation for subsequent cross-category correlation analysis, improving the systematic nature and efficiency of failure analysis.

[0070] Optionally, multi-dimensional filtering rules can be configured based on Logstash, using keyword matching (e.g., "heartbeattimeout" corresponds to communication anomalies, "clusterpartition" corresponds to topology anomalies, etc.).

[0071] "Mnesiapartition" corresponds to database anomalies, and "nodedown" corresponds to status anomalies. Logs are automatically categorized; type labels are added to each type of log, and node information is associated before storing them in Elasticsearch; a categorized view is built using Kibana, and logs can be filtered by category during a failure to quickly locate the distribution and timing of a certain type of anomaly, supporting multi-dimensional analysis of partition failures.

[0072] Step B202: Select logs that meet the preset partition failure conditions from the node communication anomaly, cluster topology anomaly, distributed database anomaly, and node status anomaly categories as the partition failure target logs. The preset partition failure conditions include that the log generation time is within the time interval of the cluster partition failure.

[0073] Optionally, in RabbitMQ cluster fault analysis scenarios, before filtering partition fault target logs, the collected key logs need to be divided into four categories according to the anomaly type: node communication anomaly logs (including heartbeat timeouts between nodes, TCP link disconnection records, etc.).

[0074] The logs include: “heartbeattimeoutbetweennode1andnode2” logs, cluster topology anomaly logs (including records of nodes joining / leaving without synchronized metadata and inconsistent topology, such as “clustertopologymismatch” logs), distributed database anomaly logs (including records of Mnesia data synchronization interruption and data inconsistency, such as “Mnesiareplicationfailed” logs), and node status anomaly logs (including records of node process anomalies and resource overload, such as “nodeprocessunresponsive” logs).

[0075] Optionally, the preset partition failure condition includes that the log generation time must be within the time interval of the cluster partition failure. This time interval is determined by the timestamp of the first partition feature log (e.g., 2024-05-20 14:30:00) and the timestamp of the last partition recovery log (e.g., 2024-05-20 14:45:00), i.e., 14:30:00 to 14:45:00. This allows for the accurate location of logs directly related to the partition failure, avoiding interference from non-partition-related abnormal logs in subsequent analysis. It also provides an accurate data source for extracting log timestamps, fault node identifiers, and other information, thereby improving the efficiency and accuracy of partition failure analysis.

[0076] In this embodiment, based on the type of fault event, logs belonging to heartbeat timeout events in the critical logs are classified into the node communication anomaly category, logs belonging to cluster partition events are classified into the cluster topology anomaly category, logs belonging to Mnesia partition events are classified into the distributed database anomaly category, and logs belonging to node offline events are classified into the node status anomaly category. This achieves accurate classification of fault types and provides a structured foundation for subsequent cross-category correlation analysis. Logs that meet the preset partition fault conditions are selected from the node communication anomaly, cluster topology anomaly, distributed database anomaly, and node status anomaly categories as partition fault target logs, thereby accurately separating non-core fault logs and improving the targeting and efficiency of fault location.

[0077] Furthermore, based on the above, in some feasible embodiments, step S30 includes the following implementation steps C10 to C50.

[0078] Step C10: Extract the timestamp, log generation node identifier, fault node identifier, and inter-node connectivity status of each log from the partitioned fault target log. Then, associate the extracted timestamp, log generation node identifier, fault node identifier, and inter-node connectivity status with the static attributes of each node to construct an analysis dataset containing time, node, and connectivity dimensions.

[0079] Optionally, the timestamp refers to the precise time the log was generated, which needs to be extracted from the time field of the log body to ensure that the fault development process can be traced in chronological order later; the log generating node identifier refers to the unique identifier of the RabbitMQ node that generated the log, which is obtained from the node identifier field in the log header and is used to locate the source node of the log; the fault node identifier refers to the node identifier recorded in the log that has an anomaly, which needs to be filtered from the anomaly description content of the log to identify the abnormal node associated with each log; the inter-node connectivity status refers to the communication status between two or more nodes recorded in the log, which is specifically divided into three categories: "normal connectivity", "disconnected connectivity", and "delayed connectivity", which needs to be determined based on the communication status field or anomaly keywords in the log.

[0080] Optionally, the node static attributes are inherent attributes of nodes in the RabbitMQ cluster. Specifically, these include the node's IP address, the node's role in the cluster (master node / slave node), the cluster sub-partition to which the node belongs (e.g., partition A / partition B), and the hardware server model deployed on the node (only the specification type is recorded, not the specific product model). These attributes are pre-stored in the cluster node configuration library. During association, the "log generating node identifier" is used as the matching key to bind the extracted log information with the corresponding node's static attributes in the configuration library. For example, if the log generating node identifier is rabbit@node1, then the log's timestamp, fault node identifier, and other information are associated with the "IP (192.168.1.101), role (master node), and partition (partition A) corresponding to rabbit@node1" in the configuration library.

[0081] Optionally, the analysis dataset includes three core dimensions: "time dimension," "node dimension," and "connectivity dimension." The time dimension field is the log timestamp; the node dimension fields are the log-generating node identifier, the static attributes of the log-generating node (IP, role, partition), the faulty node identifier, and the static attributes of the faulty node; the connectivity dimension fields are the connectivity status between nodes and the nodes involved in connectivity anomalies.

[0082] This embodiment, by constructing this dataset, integrates scattered log information with the inherent attributes of nodes to form structured data support. For example, by filtering dataset records that "belong to partition A" and "connectivity status is disconnected", the specific time of communication interruption and the nodes involved in partition A can be quickly located, avoiding the problem of low analysis efficiency caused by the disconnect between log information and node attributes. At the same time, this dataset provides a complete multi-dimensional data foundation for subsequent analysis of the spread pattern of partition faults and the location of fault initiation nodes, improving the accuracy of partition fault analysis.

[0083] Step C20: Based on the timestamps of the analysis dataset, merge the same type of partition events that occur on the same node within a preset first time period into a single independent partition event;

[0084] Optionally, based on the timestamps of the analysis dataset containing time, node, and connectivity dimensions, similar partition events occurring on the same node within a preset first time period are merged into a single independent partition event. The merged independent partition event includes a unique node identifier, event type, merging time period, event frequency, and node connectivity status change trend. At the same time, core log fragments within this time period are retained, thereby effectively removing redundant log entries of the same type of event on the same node within a short period of time, avoiding interference from high-frequency repetitive data during analysis, and simplifying the fault timeline. Furthermore, by merging, the duration and frequency characteristics of the events are highlighted, which helps determine whether the fault is a momentary fluctuation or a persistent problem, improving the efficiency of subsequent timeline analysis and root cause localization.

[0085] Optionally, based on the Flink (Apache Flink: Apache Flink stream processing framework) stream processing framework, the dataset is read and analyzed, and grouped by "node identifier + event type"; a preset first time period is set (e.g., 30 seconds, which can be configured as needed), the events in each group are sorted by timestamp, the time difference between adjacent events is calculated, and if the difference is less than the preset value, they are merged; the merged event records are generated, stored in the time series database, and associated with the static attributes of the nodes for subsequent fault timeline analysis.

[0086] Step C30: Statistically analyze the independent occurrence frequency of partition events corresponding to each fault event type, and generate statistical results of nodes, event types, and occurrence frequencies;

[0087] Optionally, in a cluster partition failure scenario, the independent occurrence count of partition events corresponding to each failure event type is counted, generating statistical results of nodes, event types, and occurrence frequencies. In other words, the statistical results include the node's unique identifier, the failure event type, and the independent occurrence count of each type of event. At the same time, the node's static attributes are associated to clearly present the frequency distribution of various partition events on different nodes, enabling rapid location of high-frequency failure nodes, clarifying the distribution characteristics of different failure types, providing quantitative basis for root cause analysis, and helping to prioritize the allocation of failure handling resources to avoid over-investment in low-frequency failure nodes.

[0088] Optionally, the merged independent partition event data can be extracted from a time-series database (such as InfluxDB), grouped by "node identifier + fault event type" using InfluxQL, and the COUNT function can be used to count the number of events in each group; the node attribute table of a relational database (such as MySQL) can be called to supplement attribute information by association by node ID; the statistical results after association can be written to the analysis database, and a visualization table can be built using Grafana to intuitively display the frequency of various events on each node, supporting sorting by frequency or filtering by node attribute, so that fault analysts can quickly obtain key information.

[0089] Step C40: For each independent partition event in the statistical results, generate node identifiers and fault node identifiers based on the logs in the analysis dataset, and determine the complete set of nodes involved in the partition event;

[0090] Optionally, for each independent partition event in the statistical results, node identifiers and faulty node identifiers are generated based on the logs associated with the partition event, as well as directly affected nodes and indirectly affected nodes inferred from the connectivity status between nodes. At the same time, the role of each node and its association type in the event are marked to fully present the node range affected by the event, so as to accurately delineate the impact boundary of a single partition event, avoid focusing only on faulty nodes and omitting indirectly affected nodes, provide a basis for determining the partition cluster range in subsequent topology analysis, and help to prioritize core nodes through node role labeling, thereby improving the targeting and efficiency of fault repair.

[0091] Optionally, a single independent partition event is extracted from the statistical results, and the identifiers of the log-generating nodes and the faulty nodes of the event are obtained from the correlation analysis dataset. Based on the node connectivity status data, nodes with "connectivity interruption" associations with the faulty nodes are matched in the graph database to form an initial node set. Nodes that do not match the event timestamp are removed, and the role attributes of each node are supplemented to generate a set of event-related nodes containing node identifiers, association types, and roles, which is then stored in the analysis database for subsequent use.

[0092] Step C50: For each set of nodes, take the nodes of the set as vertices and the connectivity states between the nodes as edges to obtain the network topology graph.

[0093] Optionally, in a cluster partition failure scenario, for each node set, a network topology graph is formed using the nodes of the node set as vertices and the connectivity states between the nodes as edges. Specifically, each node in the node set is labeled with its unique identifier, role, and subnet; the connectivity states between nodes are labeled with their styles and attributes corresponding to the connectivity states, and the timestamps of edge state changes are also labeled. This fully presents the connection relationships within the node set and the connectivity state during a failure, forming a network topology graph. This transforms abstract node associations and connectivity data into intuitive graphics, clearly showing the node connection breakpoints during a partition failure, quickly locating partition boundaries, assisting in identifying root cause nodes, avoiding the logical blind spots of pure text analysis, and significantly improving the intuitiveness and efficiency of root cause analysis.

[0094] Optionally, node information and connectivity status of the node set are extracted from the analysis database, and vertices (nodes) and edges (connectivity relationships) are created using the Neo4j graph database. Vertex attributes include node identifier and role, and edge attributes include connectivity status and timestamp. The visualization engine is called to read the graph database data, render the edge style according to the connectivity status, and display the topology graph in the graphical interface. It supports clicking on vertices to view the details of the associated logs, providing visualization support for root cause analysis.

[0095] Optionally, the network topology diagram can be optimized in layout, and legends can be added to obtain and save the optimized topology diagram. The optimized topology diagram is saved in image format, which eliminates the visual clutter of the initial topology diagram, makes the node grouping and connection relationships more intuitive, and lowers the barrier to graphical interpretation, making it easier for analysts to quickly understand the topology structure and fault status. Saving in image format facilitates cross-tool sharing and report embedding, supports offline analysis, reduces information transmission costs in team collaboration, and further improves the efficiency and accuracy of root cause localization.

[0096] Optionally, based on the node function types of the RabbitMQ cluster, preset hierarchical rules are set, and the arrangement of each node in the preliminary topology diagram is adjusted in the order of "core service node, subordinate service node, traffic scheduling node (load balancer), client node (access application)". The number of crossovers between nodes is calculated to shorten the visual length of the link between the core service node and the subordinate service node, and to avoid link crossovers between nodes at different levels. For faulty nodes involved in partition faults recorded in the preliminary topology diagram, preset visual markers are used for differentiated labeling, and faulty node identifiers are marked next to the nodes. Links with a "disconnected" connection status between nodes are marked with orange dashed lines. Links with a "normal" connectivity status are marked with a solid green line, generating a network topology diagram that includes node hierarchy, link connectivity status, and the location of faulty nodes. In the layout optimization scenario of the RabbitMQ cluster network topology diagram, the preset hierarchy rules refer to setting the hierarchical arrangement standards of nodes in the topology diagram in advance based on the functional type, core role, and data / request flow logic of the nodes in the cluster. This ensures that the position of each node can intuitively reflect its role and interaction order in the cluster, avoiding topology chaos caused by disordered arrangement, and finally obtaining a network topology diagram that clearly presents the cluster topology structure, the relationship between nodes, and the location of faulty nodes.

[0097] Optionally, the node arrangement can be optimized using D3.js's forceSimulation layout algorithm, and the layout area can be divided according to subnet attributes; visual rules can be defined using JavaScript; and HTML can be added.

[0098] (HyperTextMarkupLanguage) Legend elements and associated style descriptions; call the html2canvas library to convert the optimized SVG topology map into PNG (PortableNetworkGraphics) format, save it to the specified path via backend API (such as PythonFlask), and the file name includes the event ID and generation time to ensure traceability.

[0099] In this embodiment, based on the selected partition fault target logs, an analysis dataset containing time, node, and connectivity dimensions is formed, achieving a deep correlation between dynamic fault data and static node attributes, providing structured and highly correlated data support for subsequent timeline organization and topology analysis. Based on the timestamps of the analysis dataset, partition events of the same type occurring on the same node within a preset first time period are merged into a single independent partition event, effectively removing redundant duplicate logs of the same type of event on the same node within a short period, avoiding interference from high-frequency duplicate data during analysis. The independent occurrence frequency of partition events corresponding to each fault event type is statistically analyzed, generating a node, event type, and... By analyzing the statistical results of the frequency of occurrence, high-frequency fault nodes can be quickly located, and the distribution characteristics of different fault types can be clarified. For each independent partition event, node identifiers and fault node identifiers are generated based on the logs in the analysis dataset to determine the entire set of nodes involved in the partition event, accurately delineating the influence boundary of a single partition event, and providing a basis for determining the range of partition clusters in subsequent topology analysis. Using the nodes of the node set as vertices and the connectivity states between the nodes of the node set as edges, a network topology graph is obtained, transforming abstract node association and connectivity data into intuitive graphics, avoiding the logical blind spots of pure text analysis, and significantly improving the intuitiveness and efficiency of root cause analysis.

[0100] Furthermore, based on the content of any of the above embodiments, in some feasible embodiments, step S40 above includes the following implementation steps C401-C403.

[0101] Step C401: Based on the analysis dataset, obtain the timestamp of each individual partition event;

[0102] Optionally, in the RabbitMQ cluster partition failure analysis scenario, the timestamp of each independent partition event is obtained based on the analysis dataset. An independent partition event refers to a single partition failure in the cluster caused by the same communication anomaly (such as a disconnection of links between nodes or a heartbeat timeout), involving a fixed set of nodes and with no temporal overlap. If the set of nodes involved in partition failures occurring in different time periods is completely different, or if the interval between partition failures of the same set of nodes exceeds a preset time threshold, they are determined to be different independent partition events. This allows for accurate differentiation of multiple independent partition failures in the cluster, avoiding misjudging multiple communication anomaly records of the same partition event as multiple events, or missing independent partition events in different time periods. At the same time, using the timestamp of the first record of the event as the event timestamp can accurately reflect the start time of the partition failure, providing an accurate time reference for subsequent analysis of the duration, spread speed, and cause correlation of partition events, thus improving the accuracy of partition failure tracing.

[0103] Step C402: Sort each independent partition event in ascending order of the partition event timestamp, and merge events of the same fault event type in the same node set within the preset second time period to obtain the sorted partition events;

[0104] Optionally, each independent partition event is sorted in ascending order by the timestamp of the partition event, and events of the same fault event type in the same node set within a preset second time period are merged to obtain sorted partition events. This ascending order clearly presents the temporal logic of the fault evolution, avoiding causal misjudgment caused by temporal confusion. Merging the same node set and the same type of events within a short period of time eliminates redundant information, simplifies the timeline, and enables analysts to quickly focus on the duration of the fault and the changing trend of the node set, thereby efficiently identifying the root cause.

[0105] Optionally, the event sequence is arranged in ascending order of timestamps. Each event is labeled with the merged time range (e.g., start / end time, taken from the first and last timestamps of the merged event), the fault event type (e.g., cluster partition / Mnesia partition), the complete set of nodes involved (e.g., including node identifiers and roles), the number of events before merging, and the merging basis (preset second time period). At the same time, the nodes with changes in the status of key nodes in the event are retained (e.g., the first node to experience a connectivity interruption).

[0106] Optionally, in a cluster partition failure scenario, the filtered independent event data is extracted from the relational database and sorted in ascending order by timestamp; a preset second time period (e.g., 5 minutes) is set, and the events are grouped by "node set + failure type". The time difference between events within the group is calculated, events with an interval less than the preset value are merged, and the time range and number of events are updated; the sorted and merged event sequence is stored in the time series database, associated with the optimized topology map, and a coherent failure timeline is generated through visualization tools for direct use in root cause analysis.

[0107] Step C403: For each sorted partition event, mark the corresponding node connectivity status to form a timeline analysis report of partition failure.

[0108] Optionally, in a cluster partitioning failure scenario, for each sorted partitioning event, the corresponding inter-node connectivity status is marked to form a partitioning failure timeline analysis report. This allows for an intuitive presentation of the complete evolution logic of the failure from the initial connectivity anomaly to partition formation and subsequent state changes, clarifying the causal relationship between connectivity anomalies and partitioning events (such as a node interruption followed by a cluster partition). This avoids separating states and events during analysis, helps to quickly locate the root cause (such as continuous connectivity interruptions concentrated in a certain subnet, pointing to a network link problem), and significantly improves the efficiency of root cause analysis.

[0109] Optionally, each partition event is sorted in ascending order by timestamp. In addition to marking the time range, fault type, and set of nodes involved, each event also needs to accurately mark the connectivity status between nodes—including the connectivity relationship between core nodes and edge nodes (such as "node A - node B connectivity interrupted", "node C partially connected with nodes in the subnet"), key time points of connectivity status changes (such as "node D and cluster master node connectivity restored at 10:05"), and the differences in connectivity status between different nodes within the same event.

[0110] Optionally, sorted and merged partitioned event data can be extracted from a time-series database, associated with an analysis dataset containing time, node, and connectivity dimensions, and the connectivity status of corresponding nodes can be matched according to the event time range. Event information and connectivity status can be integrated using a Python script, and a report can be generated according to a preset template (including timeline, event details, and connectivity status annotation columns), such as "On July 14, 2025 at 19:23, node1 experienced a network interruption with node3". A highly readable text report can be output, such as a PDF, embedding a schematic diagram of the connectivity status changes of key nodes for direct use by analysts.

[0111] In this embodiment, by analyzing the dataset, the timestamp, fault event type, and corresponding set of nodes involved in each independent partition event are obtained, directly providing key time sequence and scope basis for root cause analysis. Each independent partition event is sorted in ascending order by timestamp, and events of the same fault event type in the same set of nodes within a preset second time period are merged to obtain sorted partition events. This allows for quick focusing on the duration of the fault and the changing trend of the node set, thereby efficiently identifying the root cause. For each sorted partition event, the corresponding inter-node connectivity status is labeled to form a partition fault timeline analysis report, which intuitively presents the complete evolution logic of the fault from the initial connectivity anomaly to partition formation and subsequent state changes, thereby significantly improving the efficiency of root cause analysis.

[0112] Furthermore, based on the content of any of the above embodiments, in some feasible embodiments, the above log data analysis method includes the following implementation steps D501 to D504 in step S50.

[0113] Step D501: Extract the logical association information and connectivity characteristics between nodes from the network topology diagram, parse the timeline analysis report and extract the temporal relationship of fault events;

[0114] Optionally, the logical association information and connectivity features between nodes can be extracted from the network topology diagram. The timeline analysis report can be parsed and the temporal relationship of fault events can be extracted. The unstructured node information and log data can be transformed into structured features, so that the logical association between nodes and the fault timing can be quantitatively analyzed, providing an accurate data foundation for subsequent root cause localization.

[0115] Optionally, using "time-node-event" as the core dimension, first clarify the basic anchor information, including the cluster node list (such as including IP / hostname), the fault start and end time (such as the first abnormal log timestamp as the start and the last recovery log as the end) and the log collection scope (RabbitMQ system log / var / log / rabbitmq and Erlang node communication log). Then, divide the stage into "fault precursor - partition occurrence - partition propagation - recovery operation". Each stage is associated with a timestamp accurate to the second, the triggering node and the fault type (such as connection_lost node disconnection, network_partition_detected partition detection, queue_unavailable queue unavailability). At the same time, the event correlation is marked. For example, after node A experiences connection_lost at 10:05:03, nodes B / C synchronously trigger network_partition_detected at 10:05:08. Finally, by summarizing multi-node collaborative events under the same timestamp and cross-timestamp causal events, the "first abnormal node" and "partition propagation path" are located.

[0116] Optionally, this can be implemented based on the ELK (Elasticsearch, Logstash, Kibana: Elastic search engine, log collection and processing tool, data visualization platform) stack: Deploy Filebeat on each RabbitMQ node, configure log collection rules, and filter logs related to network communication and partition detection using keywords such as `network_partition`, `connection`, and `node_down`. Then, use Logstash to extract core fields such as `@timestamp` (normalized to UTC time), `node_id` (node ​​identifier), `event_type` (custom fault type label), and `event_detail` (original log description). In Elasticsearch, create an index template, using `@timestamp` as the sorting field. Associate consecutive events on the same node using `node_id` and associate multi-node partition events using `event_type:network_partition_detected`. Simultaneously, utilize the terms aggregation function to count the number of fault events on each node in 10-second time windows to identify "event burst windows," such as 10:05:00-10:05. Within 10 minutes, 3 nodes trigger partition detection; finally, a timeline dashboard is built in Kibana, displaying a timeline line chart on the left (X-axis for time, Y-axis for event count, different colors representing nodes), and an event details table on the right (including timestamp, node, event type, and details). It supports clicking on a specific time point in the line chart to automatically filter events for the corresponding time period, thus greatly improving root cause localization efficiency. Traditional manual investigation requires going through logs node by node and manually aligning times (averaging 4-6 hours), while this solution, through automated timeline analysis, can locate the first abnormal node within 10 minutes, for example, identifying node A's connection_lost earlier than... Other node partition detection events clearly indicate that the partition was caused by a single node network outage; at the same time, it visualizes the fault propagation path, visually showing the diffusion sequence of "Node A disconnection → Node B / C partition detection → Node D queue unavailable" through a timeline line graph, avoiding missing the chain reaction of intermediate node failures; it also supports traceable recovery verification. After recovery operations (such as restarting nodes or adjusting the network), the operation timestamp is compared with the partition clearing log timestamp. For example, after the node restart log (10:15:00), if all nodes show network_partition_cleared at 10:15:08, the recovery can be confirmed as successful.

[0117] Step D502: According to the time sequence, match the fault events at different time nodes with the connectivity status characteristics of the corresponding node sets in the network topology diagram to obtain a table of correspondence between node association status and preset fault types in each time period;

[0118] Optionally, based on the temporal relationship of fault events, fault events at different time points are matched with the connectivity characteristics of the corresponding node sets in the network topology diagram to obtain a table of correspondence between node association states and preset fault types within each time period. Through precise matching of states and events, the root cause can be directly located. For example, if the "PARTITION" (database partition) event of nodes F and G appears simultaneously in the window where the connectivity state of node FG changes from 1 to 0 in the table, the fault source can be identified as the interruption of the FG link. This reduces the root cause analysis time from the traditional 2-3 hours to within 15 minutes, while avoiding the oversight of manually associating topology and events, providing structured data for subsequent fault mode learning, and improving the correlation between node state changes and fault types.

[0119] Optionally, the correspondence table constructed according to the time sequence of fault events is divided into time segments (e.g., a window of 30 seconds). Each segment contains three core pieces of information: the connectivity state matrix of the node set (e.g., using 0 / 1 to represent whether any two nodes are reachable, such as AB being 1 for connectivity and AC being 0 for disconnection), and details of fault events within that time period (including event types such as "network_partition").

[0120] “node_unreachable”, triggering node and specific timestamp), and the association label between status and event (e.g., “node DE connection interrupted” and “node D detected partition” have a direct causal relationship).

[0121] Optionally, first deploy network monitoring tools (such as Zabbix) to collect ICMP connectivity and port listening status between nodes, and combine this with the output of RabbitMQ's cluster_status command to build a real-time topology connectivity status database, which is updated every 10 seconds; then, based on log timestamps, divide fault events into consecutive time windows in sequence, and call the status database data to generate node connectivity snapshots for each window; finally, use a Python script to compare connectivity status changes and fault events within the same window to generate a corresponding relationship table, where connectivity status is visualized using an adjacency matrix, and event types are mapped to standardized labels (such as "PARTITION", "CONN_FAIL").

[0122] Step D503: Based on the correspondence table, locate the initial triggering conditions of partition faults, the propagation pattern of node anomalies, and the core event types that dominate the development of partition faults;

[0123] Optionally, in the RabbitMQ cluster partition fault analysis scenario, when locating key information about partition faults based on the correspondence table between node association status and preset fault types within each time period (hereinafter referred to as the "correspondence table"), the horizontal dimension of the correspondence table is "time period" (divided into 10-second intervals, such as 2024-05-20 14:30:00-14:30:10, 14:30:10-14:30:20), and the vertical dimension includes "node association status" (such as node 1-node 2 connection disconnection, node 2-node 3 connection delay), the matched preset fault type (such as heartbeat timeout event, Mnesia synchronization anomaly event), and the set of nodes involved (such as...).

[0124] {node1,node2}), data for each dimension is extracted from the analysis dataset and correlated by time period.

[0125] Optionally, the earliest abnormal time period in the filter table is examined, and the matching records of "node association status" and "preset fault type" within that time period are checked. If only "node1 and node2 disconnect" exists within that time period and matches the "heartbeat timeout event," and there are no other node association anomalies, then by combining the log details of that time period in the analysis dataset, the initial triggering condition of the partition fault is determined to be "the heartbeat response between node1 and node2 times out (e.g., exceeding the preset 30-second threshold), causing the two nodes to disconnect for the first time, triggering the initial anomaly of the cluster partition." At the same time, non-related abnormal records within that time period (e.g., temporary CPU overload logs of node3) need to be excluded to ensure that the triggering condition directly corresponds to the first related anomaly. The development path of the partition fault is fully restored from the three dimensions of time, space, and event type, avoiding the positioning deviation caused by relying solely on a single log or node data. In addition, the clear initial triggering condition, diffusion pattern, and core event type provide accurate technical basis for subsequent development of targeted fault recovery strategies, improving the efficiency and targeting of cluster fault handling.

[0126] Optionally, the process can be automated using a Python script. Specifically, the corresponding relational table data is read, the windows are sorted by timestamp, the first abnormal state window is identified by matrix difference operation, and the initial triggering condition is marked. The windows are traversed by time axis, the abnormal propagation path of the nodes is recorded by a directed graph, and a diffusion tree diagram is generated. The frequency of event types and the number of affected nodes are counted by Pandas, and the core events are output after sorting.

[0127] Step D504: Organize the initial triggering conditions, diffusion patterns, and core event type ranges into the fault analysis results for the partitioned fault.

[0128] Optionally, the initial triggering conditions, diffusion patterns, and core event type ranges can be organized into the fault analysis results of the partitioned faults, transforming scattered data into structured conclusions. This significantly shortens the time required for root cause analysis, greatly improves the accuracy of root cause location, and avoids the omission of key nodes or events during manual analysis. The clear diffusion patterns can quickly guide operations and maintenance to block the spread of faults, while the core event types directly point to the optimization direction, greatly reducing the recurrence rate of similar faults.

[0129] Optionally, the initial triggering conditions should clearly define the details of the fault source, including the precise time of the first anomaly (e.g., 15:08:22), the abnormal node pair (e.g., node PQ), the initial fault event (e.g., a sudden increase in the packet loss rate of the PQ link leading to connection_timeout), and the corresponding connection status change (PQ changes from 1 to 0); the propagation pattern should be sorted out according to the time axis of the anomaly propagation path (e.g., PQ interruption occurred before 15:08:35, QR disconnection occurred at 15:08:35, and RS became unreachable at 15:08:48), and the propagation mode should be summarized (e.g., gradual propagation along adjacent nodes in the cluster topology, without jumping across levels); the core event types should focus on key impact events, such as network_partition_detected and node_unreachable (e.g., triggering 5 node association status updates, driving the fault propagation), and the proportion and frequency of each type of affected nodes should be marked.

[0130] Optionally, based on Python, the system reads the previously generated table of node association status and fault type correspondence, calls Pandas to extract the time, node, and event data of the initial triggering conditions, uses the NetworkX library to draw a diffusion path diagram and summarize the pattern, and counts the frequency and impact range of event types to filter core events. Finally, a structured report containing textual conclusions and visual charts (such as diffusion path time sequence diagrams) is generated and automatically pushed to the operation and maintenance management platform without the need for manual secondary processing.

[0131] This embodiment analyzes the network topology diagram and extracts the logical associations and connectivity features between nodes. It also analyzes the timeline analysis report and extracts the temporal relationships of fault events. Through structured extraction, the accuracy of node association features and fault timing is ensured, improving the efficiency of fault analysis. Based on the temporal relationships of fault events, fault events at different time points are matched with the connectivity status of the corresponding node sets in the network topology diagram, resulting in a correspondence table between node association features and preset fault types for each time period. Based on this correspondence table, the initial triggering conditions of partition faults, the propagation patterns of node anomalies, and the core event types that dominate the development of partition faults are located, achieving automation and precision in partition fault location. The initial triggering conditions, propagation patterns, and core event type ranges are organized into the fault analysis results for partition faults. By structuring the key elements of partition faults, misjudgments of the fault scope and omissions of root causes in traditional troubleshooting are avoided, ensuring the efficiency of partition fault root cause analysis, shortening partition fault location time, and improving the accuracy and timeliness of cluster partition fault handling.

[0132] Furthermore, based on the content of any of the above embodiments, in some feasible embodiments, the above log data analysis method includes the following implementation steps E60 to E70 after step S50.

[0133] Step E60: Based on the preset partition fault labeling rules, perform automatic label generation processing on the fault analysis results to generate feature labels corresponding to the fault analysis results;

[0134] Optionally, the preset partition fault labeling rules refer to the label classification and judgment criteria set in advance based on common attributes of RabbitMQ partition faults, including but not limited to fault root cause labels, impact scope labels, and severity labels. Fault root cause labels include "heartbeat timeout caused partition", "Mnesia synchronization anomaly caused partition", and "link interruption caused partition". The judgment rule is that if the "core event type is heartbeat timeout" in the fault analysis result and the heartbeat response between faulty nodes exceeds 30 seconds, then the "heartbeat timeout caused partition" label is matched; if the core event type is Mnesia synchronization anomaly and the data synchronization delay exceeds 60 seconds, then the "heartbeat timeout caused partition" label is matched. The label "Mnesia synchronization anomaly causing partition" is used for identification purposes. The impact scope label includes "single-node partition," "two-node partition," and "multi-node partition (≥3 nodes)," determined by matching the number of elements in the fault node set in the fault analysis results. For example, if the number of nodes is 1, it is a "single-node partition," and if the number of nodes is ≥3, it is a "multi-node partition." The severity label includes "low-risk (no business impact)," "medium-risk (partial business delay)," and "high-risk (business interruption)," determined by the fault analysis results: if the "application message processing delay < 100ms" is "low-risk," and if the "message loss > 5 messages" is "high-risk."

[0135] Specifically, when performing automatic tag generation, key data is first extracted from the fault analysis results, such as core event type, number of fault nodes, and message processing delay / loss. Then, the above rules are matched one by one. For example, if the fault analysis results show "core event is heartbeat timeout, 2 fault nodes, message delay 50ms", then the feature tag set is automatically generated: {heartbeat timeout triggers partition, dual-node partition, low risk (no business impact)}.

[0136] Step E70: Associate the feature labels with the network topology elements of the network topology relationship diagram to obtain a mapping table between the feature labels of the associated fault analysis results and the network topology elements.

[0137] Optionally, network topology elements refer to identifiable core components in the network topology diagram, including RabbitMQ nodes (including node name / IP), inter-node links (including link status), and topology levels (core service layer / subordinate service layer, etc.), avoiding a general reference to the topology diagram. Association is based on the core logic of "matching label dimensions with topology element attributes": Fault root cause labels are associated with "faulty nodes": for example, the label "heartbeat timeout triggers partition" is associated with the "nodes involved in the heartbeat timeout" recorded in the network topology diagram; Impact scope labels are associated with "inter-node links": for example, the label "two-node partition" is associated with the "connection links between faulty nodes" in the topology diagram; Severity labels are associated with "topology levels": for example, "high risk (… The system uses the tag "Service Interruption" to associate the "core service layer node carrying core business" in the topology diagram. This results in a "Mapping Table of Feature Tags and Network Topology Elements for Associated Partition Fault Analysis Results." The table contains at least three columns: the feature tag name, the associated network topology element (including element identifier), and a description of the element's location in the topology diagram (e.g., "first node on the left of the core service layer"). This ensures precise binding between fault analysis results and the topology diagram. When users view the mapping table later, they can quickly locate the corresponding faulty node, link, and layer in the topology diagram using the feature tag, avoiding the low efficiency of fault location caused by the disconnect between tags and topology. Simultaneously, the structured mapping table provides a clear basis for subsequent fault reproduction and root cause tracing.

[0138] In this embodiment, automatic tagging enables rapid filtering via tags, further shortening fault recovery time; by directly associating tags with topology elements through a mapping table, abnormal elements in the topology can be directly located, improving association efficiency and ensuring the accuracy and timeliness of cluster fault handling.

[0139] In addition, this application also provides a log data analysis system, please refer to... Figure 4 , Figure 4 This is a schematic diagram of the log data analysis system involved in the embodiments of this application. The log data analysis system provided in this application includes:

[0140] The data acquisition module H01 is used to acquire key logs output by each node in the cluster and node information, including fault node information involved in the partition failure and preset fault event types.

[0141] The log classification module H02 is used to classify key logs based on fault node information and preset fault event types, and to filter out the target logs that caused the partition fault.

[0142] The topology analysis module H03 is used to perform topology analysis on partition faults based on the timestamps and node information of the target logs, and generate a network topology diagram of the partition faults.

[0143] The time analysis module H04 is used to analyze the time of partition failures based on the timestamps of the target logs and the preset failure event types, and generate a timeline analysis report of the partition failures.

[0144] The fault analysis module H05 is used to perform fault analysis on partition faults based on the network topology diagram and timeline analysis report, and obtain the fault analysis results.

[0145] The log data analysis system provided in this application, employing the log data analysis method described in the above embodiments, can solve the technical problem of low efficiency in log data analysis systems. Compared with the prior art, the beneficial effects of the log data analysis system provided in this application are the same as those of the log data analysis system method provided in the above embodiments, and other technical features of this log data analysis system are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0146] In addition, this application also provides a log data analysis device. Please refer to... Figure 5 , Figure 5 This is a schematic diagram of the log data analysis device involved in the embodiments of this application. Specifically, the device in the embodiments of this application can be a system for locally running log data analysis methods.

[0147] This application provides a log data analysis device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the log data analysis device method of the above embodiment 1.

[0148] The following is for reference. Figure 5 , Figure 5This is a schematic diagram of the structure of a log data analysis device according to an embodiment of this application, showing a suitable structure for implementing the log data analysis device of this application. The log data analysis device in this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The log data analysis device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0149] like Figure 5 As shown, the log data analysis device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the log data analysis device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following devices may be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the log data analysis device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a log data analysis device with various devices, it should be understood that implementing or having all of the shown devices is not required. More or fewer devices may be implemented alternatively.

[0150] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0151] The log data analysis device provided in this application, employing the log data analysis method in the above embodiments, can solve the technical problem of low efficiency in log data analysis devices. Compared with the prior art, the beneficial effects of the log data analysis device provided in this application are the same as those of the log data analysis method provided in the above embodiments, and other technical features in this log data analysis device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0152] Furthermore, this application provides a computer-readable storage medium. This computer-readable storage medium stores a log data analysis program, which, when executed by a processor, implements the steps of the aforementioned log data analysis method.

[0153] 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 system 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 system. 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 system that includes that element.

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

[0155] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a computer-readable storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0156] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A log data analysis method, characterized in that, The log data analysis method includes: Obtain key logs output by each node in the cluster and node information of the nodes, wherein the node information includes fault node information involved in the partition failure and preset fault event types; Based on the fault node information and the preset fault event type, the key logs are classified and the target logs of the partition fault are filtered out. Based on the timestamp of the target log and the node information, a topology analysis is performed on the partition fault to generate a network topology diagram of the partition fault; Based on the timestamps of the target logs and the preset fault event types, the partition faults are analyzed over time to generate a timeline analysis report of the partition faults; Based on the network topology diagram and the timeline analysis report, a fault analysis is performed on the partition fault to obtain the fault analysis results.

2. The log data analysis method as described in claim 1, characterized in that, The steps of obtaining the key logs output by each node in the cluster and the node information of the nodes include: The key logs output by each node are obtained through the log collection channels of each node in the cluster. The log features in the key logs include at least one of the following: recording the heartbeat timeout between nodes, recording the discovery of network partitions, recording the occurrence of network partitions in the Mnesia database, and recording the node being marked as down. The node information of each node is obtained through the cluster's management interface, wherein the node information includes at least a node identifier.

3. The log data analysis method as described in claim 2, characterized in that, The step of classifying the key logs based on the fault node information and the preset fault event type, and filtering out the target logs that caused the partition fault, includes: According to the preset fault event types, logs belonging to heartbeat timeout events in the key logs are classified into node communication anomaly category, logs belonging to cluster partition events are classified into cluster topology anomaly category, logs belonging to Mnesia partition events are classified into distributed database anomaly category, and logs belonging to node offline events are classified into node status anomaly category. Logs that meet preset partition failure conditions are selected from the node communication anomaly class, the cluster topology anomaly class, the distributed database anomaly class, and the node status anomaly class as partition failure target logs. The preset partition failure conditions include that the log generation time is within the time interval of the cluster partition failure.

4. The log data analysis method as described in claim 3, characterized in that, The step of performing topology analysis on the partition fault based on the timestamp of the target log and the node information to generate a network topology graph of the partition fault includes: From the partitioned fault target log, extract the timestamp, log generating node identifier, fault node identifier, and inter-node connectivity status of each log entry, and associate the extracted timestamp, log generating node identifier, fault node identifier, and inter-node connectivity status with the static attributes of each node to construct an analysis dataset containing time, node, and connectivity dimensions. Based on the timestamp of the analysis dataset, partition events of the same type occurring on the same node within a preset first time period are merged into a single independent partition event; The independent occurrence frequency of each partition event corresponding to each preset fault event type is statistically analyzed to generate statistical results including nodes, event types, and occurrence frequencies. For each independent partition event in the statistical results, the node identifier and the fault node identifier are generated based on the logs in the analysis dataset to determine the complete set of nodes involved in the partition event; For each set of nodes, a network topology graph is obtained by taking the nodes of the set as vertices and the connectivity states between the nodes as edges.

5. The log data analysis method as described in claim 4, characterized in that, The step of performing time-based analysis of the partition failure based on the timestamp of the target log and the preset failure event type to generate a timeline analysis report of the partition failure includes: Based on the analysis dataset, obtain the timestamp of each individual partition event; Each independent partition event is sorted in ascending order by its timestamp, and events of the same fault event type within the same node set in a preset second time period are merged to obtain the sorted partition events. For each sorted partition event, the corresponding connectivity status between nodes is labeled to form a timeline analysis report of the partition failure.

6. The log data analysis method as described in claim 5, characterized in that, The step of performing fault analysis on the partition fault based on the network topology diagram and the timeline analysis report to obtain the fault analysis results includes: Extract the logical association information and connectivity features between nodes from the network topology diagram, and extract the temporal relationship of fault events from the timeline analysis report; According to the time sequence, the fault events at different time nodes are matched with the connectivity status characteristics of the corresponding node sets in the network topology diagram to obtain a correspondence table between the node association status and the preset fault type in each time period; Based on the correspondence table, the initial triggering conditions of the partition fault, the propagation law of node anomalies, and the core event types that dominate the development of the partition fault are located. The initial triggering conditions, the diffusion rules, and the range of core event types are compiled into the fault analysis results of the partition fault.

7. The log data analysis method according to any one of claims 1-6, characterized in that, The step of obtaining the fault analysis results includes: Based on preset partition fault labeling rules, automatic label generation processing is performed on the fault analysis results to generate feature labels corresponding to the fault analysis results; The feature labels are associated with the network topology elements of the network topology diagram to obtain a mapping table between the feature labels and network topology elements that associate the fault analysis results.

8. A log data analysis system, characterized in that, The log data analysis system includes: The data acquisition module is used to acquire key logs output by each node in the cluster and node information of the nodes, wherein the node information includes fault node information involved in the partition failure and preset fault event types. The log classification module is used to classify the key logs based on the fault node information and the preset fault event type, and to filter out the target logs of the partition fault. The topology analysis module is used to perform topology analysis on the partition fault based on the timestamp of the target log and the node information, and generate a network topology diagram of the partition fault. The time analysis module is used to analyze the partition faults based on the timestamps of the target logs and the preset fault event types, and generate a timeline analysis report of the partition faults. The fault analysis module is used to perform fault analysis on the partition fault based on the network topology diagram and the timeline analysis report, and obtain the fault analysis results.

9. A log data analysis device, characterized in that, The log data analysis device includes a memory, a processor, and a log data analysis program stored in the memory and executable on the processor. When the processor executes the log data analysis program, it implements the steps of the log data analysis method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a log data analysis program, which, when executed by a processor, implements the steps of the log data analysis method as described in any one of claims 1 to 7.

Images