Operation and maintenance method, device, equipment and product

Abstract

The application relates to the field of communication, in particular to an operation and maintenance method, device, equipment and product. The method comprises the following steps: receiving a log text containing a plurality of log records sent by a LoRa gateway; matching the log records by using a plurality of preset log templates to obtain matching information; classifying the logs according to the matching information and an event classification library to obtain a corresponding event category; performing one or more of the following on the event category: aggregation, clustering and association, to form an evidence package; carrying out root cause analysis based on the evidence package to obtain a fault root cause analysis result; and searching in a fault repair library according to the root cause analysis result to generate a corresponding fault repair suggestion. The method improves the accuracy and interpretability of root cause positioning through structured log processing.

Description

Technical Field

[0001] This application relates to the field of communications, and more particularly to an operation and maintenance method, apparatus, equipment, and product. Background Technology

[0002] LoRa gateways are commonly used relay devices in IoT systems, widely applied in industrial monitoring, smart parks, and other scenarios. LoRa gateways feature low power consumption and long transmission distances, enabling stable aggregation and forwarding of IoT terminal data. During operation, the device continuously generates log text, which accurately records the device's operating status and anomaly information, serving as crucial evidence for troubleshooting. Currently, the industry widely employs inference models to perform automated root cause analysis of LoRa gateway logs.

[0003] Existing log analysis methods suffer from severe information overload. Current technologies directly input raw log text into the inference model. Massive amounts of invalid and redundant noise data can mask a few key fault signals. This interferes with the inference model's reasoning logic, ultimately leading to unstable root cause analysis output. Summary of the Invention

[0004] This application provides an operation and maintenance method, device, equipment, and product that can effectively overcome the illusion and instability problems of reasoning models under long context forgetting and information overload.

[0005] Firstly, it provides an operation and maintenance method, including: Receive log text sent by the LoRa gateway, wherein the log text includes multiple log records; The multiple log records are matched based on multiple log templates to obtain multiple matching information; Based on the multiple matching information and the event classification library, multiple event categories are obtained; The evidence package is obtained by aggregating, clustering, and associating the multiple event categories. Root cause analysis was performed based on the evidence package to obtain the root cause analysis results; Based on the root cause analysis results, a fault repair database is searched to obtain repair suggestions.

[0006] In the above solution, log templates are used to match, classify, and cluster log records, transforming massive amounts of log text into more concise and meaningful event clusters. These clusters are then provided to the inference model for root cause analysis. This avoids directly feeding hundreds or thousands of independent log records to the inference model; instead, the log text is deeply refined to obtain deep semantics. This reduces noise, lowers the lexical consumption required by the inference model, and helps the model focus on the most relevant operational issues, rather than being overwhelmed by massive amounts of log text. This effectively overcomes the illusion and instability problems of inference models under long context forgetting and information overload, achieving accurate fault root cause location and standardized repair suggestion output, significantly improving the automation level and diagnostic accuracy of IoT gateway operation and maintenance.

[0007] In some possible designs, root cause analysis is performed based on the evidence package to obtain root cause analysis results, including: Root cause analysis is performed based on the context information of the LoRa gateway, at least one of the historical work orders, and the evidence package to obtain the root cause analysis results. The context information of the LoRa gateway includes one or more of the basic device information of the LoRa gateway and weather information. The historical work orders are retrieved from the historical fault work order database based on one or more of the work order description, device operating status, and the context information of the LoRa gateway.

[0008] The above solution uses structured event clusters as a foundation, combining the LoRa gateway's context and historical work orders to form constrained inference, avoiding information overload and long context forgetting, making root cause analysis more stable and reliable. Furthermore, by introducing gateway device information, weather, and other contextual data, joint judgments from environmental and device dimensions are achieved, improving the accuracy of fault root cause identification. Additionally, using retrieved historical work orders as prior knowledge provides the inference model with real-world operational experience references, effectively reducing illusions and erroneous inferences.

[0009] In some possible designs, after performing root cause analysis based on the evidence package and obtaining the root cause analysis results, the method further includes: The root cause analysis confidence score is obtained by weighting one or more of the following: matching confidence score, classification confidence score, clustering confidence score, and inference confidence score. The matching confidence score is the degree of credibility of the match between the log record and the log template. The classification confidence score is the degree of credibility of the log record matching the corresponding event category. The clustering confidence score is the degree of credibility of multiple event categories clustering into the same event cluster. The inference confidence score is the degree of reliability of deriving the corresponding root cause of the failure from the features of the event cluster.

[0010] In the above scheme, the confidence level of the entire process of log matching, event classification, cluster association and root cause reasoning is weighted and calculated to make the root cause analysis results quantifiable and evaluable.

[0011] In some possible designs, the root cause analysis confidence score is obtained by weighting one or more of the following: matching confidence score, classification confidence score, clustering confidence score, and inference confidence score. The root cause analysis confidence score is obtained by weighting one or more of the following: matching confidence score, classification confidence score, clustering confidence score, retrieval confidence score, and inference confidence score. The retrieval confidence score is the degree of credibility of the match between the retrieved historical work order and the LoRa gateway context information, the device operating status, and the work order description when searching in the historical fault work order database.

[0012] In some possible designs, the number of match confidence scores is multiple, and the number of match confidence scores is the same as the number of match information; the number of classification confidence scores is multiple, and the number of classification confidence scores is the same as the number of event categories; the number of clustering confidence scores is multiple, and the number of clustering confidence scores is the same as the number of event clusters; the number of retrieval confidence scores is multiple, and the number of retrieval confidence scores is the same as the number of historical work orders. The root cause analysis confidence score is obtained by weighting one or more of the match confidence scores, classification confidence scores, clustering confidence scores, and inference confidence scores, including: The root cause analysis confidence score is obtained by weighting one or more of the following: average match confidence score, average classification confidence score, average clustering confidence score, average retrieval confidence score, and inference confidence score. Specifically, the average match confidence score is obtained by averaging multiple match confidence scores, the average classification confidence score is obtained by averaging multiple classification confidence scores, the average clustering confidence score is obtained by averaging multiple clustering confidence scores, and the average retrieval confidence score is obtained by averaging multiple retrieval confidence scores.

[0013] In some possible designs, before matching the multiple log records based on multiple log templates, the method further includes: Multiple log templates are generated for the multiple record categories, wherein the multiple record categories include a first record category, and the multiple log templates include a first log template. The first log template includes an invariant part and a wildcard part. The invariant part is generated based on the parts of words that are the same in each log record of the first record category, and the wildcard part is generated based on the parts of words that are different in each log record of the first record category.

[0014] In the above solution, log templates containing fixed fields and wildcards are automatically generated based on the same and different parts of similar logs, realizing the structuring and normalization of logs, improving parsing efficiency and generalization ability. Furthermore, no manual template definition is required, reducing maintenance costs. At the same time, it provides high-quality structured data for subsequent event classification, clustering and root cause analysis, improving the overall accuracy of fault diagnosis.

[0015] In some possible designs, the multiple log records are matched based on multiple log templates to obtain multiple matching information, including: In the event of an alarm, the multiple log records are matched based on multiple log templates to obtain multiple matching information. The triggering conditions for the alarm event include any one of the following: receiving a detection signal input by the user, a successful match between the fault regular expression and the most recent log record, or an abnormality in the LoRa gateway's metrics. The metrics include one or more of the following: P95 latency and anomaly count.

[0016] In some possible designs, the method further includes: the LoRa gateway or LoRa server periodically performing structured storage on the original log text to obtain the log text.

[0017] In some possible designs, each matching information includes a log template, the number of matches, and a template timestamp, wherein the template timestamp includes the timestamp of the log record that was successfully matched with the corresponding log template.

[0018] In the above scheme, by recording log templates, matching times and template timestamps, the quantitative statistics and time-series marking of similar logs are realized, supporting high-frequency anomaly identification and time-series correlation analysis, improving the efficiency and accuracy of root cause analysis. In other words, the amount of log data can be reduced, redundancy can be reduced, information overload can be alleviated, and a reliable basis for fault tracing and interpretability can be provided.

[0019] Secondly, an operation and maintenance method is provided, including: Receive log text sent by the LoRa gateway, wherein the log text includes multiple log records; The multiple log records are matched based on multiple log templates to obtain multiple matching information; Based on the multiple matching information and the event classification library, multiple event categories are obtained; The evidence package is obtained by aggregating, clustering, and associating the multiple event categories. The evidence package is sent to the inference model to perform root cause analysis, and the root cause analysis results are obtained.

[0020] Thirdly, an operation and maintenance device is provided, including: The receiving module is used to receive log text sent by the LoRa gateway, wherein the log text includes multiple log records; The matching module is used to match the multiple log records based on multiple log templates to obtain multiple matching information; A classification template is used to classify events based on the multiple matching information and the event classification library to obtain multiple event categories. The evidence generation module is used to aggregate, cluster, and associate the multiple event categories to obtain an evidence package. The analysis module is used to perform root cause analysis based on the evidence package and obtain the root cause analysis results; The search module is used to search the fault repair library based on the root cause analysis results and obtain repair suggestions.

[0021] Fourthly, an operation and maintenance device is provided, including: The receiving module is used to receive log text sent by the LoRa gateway, wherein the log text includes multiple log records; The matching module is used to match the multiple log records based on multiple log templates to obtain multiple matching information; The classification module is used to classify events based on the multiple matching information and the event classification library to obtain multiple event categories. The evidence generation module aggregates, clusters, and associates the multiple event categories to obtain an evidence package. The sending module is used to send the evidence package to the inference model for root cause analysis and obtain the root cause analysis results.

[0022] Fifthly, a computing device is provided, comprising: a processor and a memory, wherein the processor is connected to the memory, the memory is used to store instructions, and the processor is used to read the instructions from the memory to perform the method as described in any of the first aspects.

[0023] In a sixth aspect, a program product comprising instructions is provided, the instructions being executed by a computing device to cause the computing device to perform the method as described in any of the first aspects. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the structure of a LoRa system provided in this application; Figure 2 This is a schematic diagram of the structure of a LoRa gateway provided in this application; Figure 3 This is a schematic diagram of the structure of a computing device provided in this application; Figure 4This is a schematic diagram of the structure of a computing device cluster provided in this application; Figure 5 This is a flowchart illustrating a fault analysis method provided in this application; Figure 6 This is a structural schematic diagram of an operation and maintenance device provided in this application; Figure 7 This is a schematic diagram of another maintenance device provided in this application; Figure 8 This is a schematic diagram of the structure of a computing device provided in this application; Figure 9 This is a schematic diagram of the structure of a computing device cluster provided in this application; Figure 10 This is a schematic diagram of another computing device cluster provided in this application. Detailed Implementation

[0025] See Figure 1 , Figure 1 This is a schematic diagram of the structure of a LoRa system provided in this application. Figure 1 As shown, the LoRa system of this application includes: a LoRa gateway 110, a LoRa gateway management platform 120, and an inference model 130.

[0026] LoRa gateways 110 include gateways for Long Term Evolution (LTE) systems, LTE Frequency Division Duplex (FDD) systems, LTE Time Division Duplex (TDD) systems, Universal Mobile Telecommunications System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX) systems, Wideband Code Division Multiple Access (WCDMA) systems, Global System for Mobile Communications (GSM) systems, Code Division Multiple Access (CDMA) systems, 5th Generation (5G) communication systems, or future communication networks, etc.

[0027] like Figure 2As shown, the LoRa gateway 110 includes an antenna 111, an antenna information sensor unit (AISU) 112 disposed on top of the antenna 111, a mast 113, a connection structure 114 for connecting the antenna 111 and the mast 113, a cable 115, a grounding device 116, a remote radio unit (RRU) 117, a building baseband unit (BBU) 118, and a network management system 119. The antenna 111 is used to receive and transmit electromagnetic waves to enable data exchange between the LoRa node and the RRU 117.

[0028] Antenna 111 is a passive device that converts radio frequency electrical signals into spatial electromagnetic waves. In LoRa gateway 110, it is responsible for receiving uplink radio frequency signals from LoRa nodes and radiating downlink radio frequency signals from LoRa gateway 110 into space, thereby realizing wireless data transmission between LoRa nodes and remote radio units (RRUs).

[0029] AISU 112 is a sensing module integrated on the top of the antenna, used to collect key status and environmental parameters of antenna 111 in real time, including but not limited to antenna 111 attitude (tilt angle, azimuth angle), operating temperature, vibration amplitude, standing wave ratio (VSWR) and signal strength, etc., to provide gateway network management with antenna 111 health status monitoring and fault diagnosis data, ensuring the stability and reliability of LoRa communication link.

[0030] The mast 113 is a vertical support structure used to support and fix the antenna 111 and its auxiliary components. It is usually a metal or composite material mast and is fastened to the antenna 111 through a connecting structure to provide stable physical support for the antenna 111. This ensures that the attitude and installation position of the antenna 111 meet the requirements of the communication coverage plan, while resisting external interference such as wind load and vibration.

[0031] The connecting structure 114 is a set of components that mechanically fix the antenna 111 and the mast 113. It typically includes clamps, brackets, adjusting bolts, etc. It can fine-tune and lock the antenna tilt angle and azimuth angle, ensuring the accuracy and long-term stability of the antenna installation attitude, while also having a certain degree of wind and earthquake resistance.

[0032] Cable 115 is a transmission medium used to transmit radio frequency signals and power. In LoRa gateway 110, it mainly includes radio frequency coaxial cable (used to transmit radio frequency signals between antenna and RRU) and power line (used to power AISU and other components). Its performance directly affects the transmission loss of radio frequency signals and communication quality.

[0033] The grounding device 116 is a protective component that reliably connects the metal casing of the antenna 111, cable 115 and LoRa gateway 110 to the ground. It consists of a grounding conductor, grounding electrode, etc., and is used to discharge lightning surges, static electricity accumulation and fault current, prevent equipment from being damaged by overvoltage, and at the same time ensure the safety of operators and reduce electromagnetic interference.

[0034] RRU 117 is the radio frequency processing core of LoRa gateway 110. It is responsible for modulating the baseband signal from the baseband processing unit (BBU) into a LoRa radio frequency signal and transmitting it through the antenna. At the same time, it demodulates the LoRa radio frequency signal received by the antenna into a baseband signal and transmits it to the BBU. It integrates functions such as power amplification, low noise amplification, frequency synthesis and radio frequency filtering, and is the conversion hub between wireless signals and digital baseband signals.

[0035] BBU 118 is the baseband processing core of LoRa Gateway 110. It is responsible for implementing the MAC layer and physical layer baseband processing of the LoRa protocol, including frame encapsulation / decapsulation, channel coding / decoding, modulation / demodulation control, resource scheduling and data encryption. It also interacts with the network management system to realize device management, status reporting and configuration distribution.

[0036] Network Management 119 is the management and monitoring hub of LoRa Gateway 110. It is responsible for monitoring the status of various components (AISU, RRU, BBU, etc.) within the gateway, providing fault alarms, configuring parameters, and performing performance statistics. It enables full lifecycle management of the gateway, ensuring stable network operation and maintainability.

[0037] The LoRa server 120 can be a computing device or a cluster of computing devices. The computing device can be a bare metal server (BMS), a virtual machine, or a container. A BMS refers to a general-purpose physical server, such as an ARM server or an x86 server; a virtual machine refers to a complete computer system simulated by software, possessing full hardware system functionality and running in a completely isolated environment. Any task that can be performed on a physical computer can also be performed in a virtual machine. When creating a virtual machine on a computing device, a portion of the physical machine's hard drive and memory capacity is used as the virtual machine's hard drive and memory capacity. Each virtual machine has an independent basic input / output system (BIOS), hard drive, and operating system, and can be operated like a physical machine. A container is a portable software unit that combines an application and all its dependencies into a single software package. This package is not limited by the underlying host operating system, thus eliminating the need to build complex environments and simplifying the application development and deployment process.

[0038] Figure 3This is a schematic diagram of a computing device 120 provided in an embodiment of this application. Figure 3 As shown, the computer device 120 includes a processor 122 and memory 124. The processor 122 is connected to the memory 124 via a double data rate (DDR) bus 123. Here, different memory modules 124 may use different data buses to communicate with the processor 122; therefore, the DDR bus 123 can also be replaced with other types of data buses. This embodiment does not limit the bus type. In addition, the computer device 120 also includes various I / O devices, which the processor 122 can access via the PCIe bus 125.

[0039] Processor 122 is the computing and control core of computing device 120. Processor 122 may include one or more processor cores. Processor 122 may be a very large-scale integrated circuit. An operating system and other software programs are installed in processor 122, enabling processor 122 to access memory 124 and various PCIe devices. It is understood that, in this embodiment of the invention, the core in processor 122 may be, for example, a central processing unit (CPU) or other application-specific integrated circuits (ASICs). Processor 122 may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. In practical applications, computing device 120 may also include multiple processors.

[0040] The memory controller is a bus circuit controller within the computing device 120 that controls the memory 124 and manages and plans data transfer between the memory 124 and the core. Data can be exchanged between the memory 124 and the core through the memory controller. The memory controller can be a separate chip connected to the core via the system bus. Those skilled in the art will understand that the memory controller can also be integrated into the processor 122, built into the northbridge, or be a separate memory controller chip. This embodiment of the invention does not limit the specific location or form of the memory controller. In practical applications, the memory controller can control the necessary logic to write data to or read data from the memory 124. The memory controller 124 can be a memory controller in a processor system such as a general-purpose processor, a dedicated accelerator, a GPU, an FPGA, or an embedded processor.

[0041] Memory 124 is the main memory of computing device 120. Memory 124 is typically used to store various running software in the operating system, input and output data, and information exchanged with external storage. To improve the access speed of processor 122, memory 124 needs to have the advantage of high access speed. In traditional computer system architectures, Dynamic Random Access Memory (DRAM) is typically used as memory 124. Processor 122 can access memory 124 at high speed through the memory controller, performing read and write operations on any storage unit in memory 124. In addition to DRAM, memory 124 can also be other random access memories, such as Static Random Access Memory (SRAM). Alternatively, memory 124 can also be read-only memory (ROM). For example, read-only memory can be programmable read-only memory (PROM) or erasable programmable read-only memory (EPROM). This embodiment does not limit the number or type of memory 124. Furthermore, memory 124 can be configured to have a power-saving function. The power-saving function means that when the system experiences a power outage and is then powered on again, the data stored in the memory will not be lost. Memory 124 with a power-saving function is called non-volatile memory.

[0042] Input / output (I / O) devices 127 refer to hardware capable of data transmission, or devices that interface with I / O interfaces. Common I / O devices include network cards, printers, keyboards, and mice. All external storage devices can also be used as I / O devices, such as hard drives, floppy disks, and optical discs. The processor 122 can access the various I / O devices 127 via the PCIe bus 125. It should be noted that the PCIe bus 125 is just one example and can be replaced with other buses, such as the Unified Bus (UB) bus.

[0043] The Baseboard Management Controller (BMC) 126 can perform firmware upgrades, manage the device's operating status, and troubleshoot faults. The processor 122 can access the BMC 126 via a PCIe bus or a bus such as USB or I2C. The BMC 126 can also be connected to at least one sensor. The sensor acquires status data of the computer device, including temperature data, current data, voltage data, etc. No specific limitations are made on the type of status data in this application. The BMC 126 communicates with the processor 122 via a PCIe bus or other types of bus, for example, by transmitting the acquired status data to the processor 122 for processing. The BMC 126 can also maintain the program code in the memory 122, including upgrading or restoring it. The BMC 126 can also control the power supply circuit or clock circuit within the computing device. In summary, the BMC 126 can manage the computing device in the above ways. However, the BMC 126 is only an optional device. In some implementations, the processor 122 can communicate directly with the sensors, thereby enabling direct management and maintenance of the computer equipment.

[0044] A computing cluster refers to a group of loosely or tightly coupled computers that work together, typically used to perform large jobs. Deploying a cluster is generally more cost-effective than using a single computer with comparable speed or availability, as it improves overall performance through concurrency. The computing devices are interconnected via a network, and each device runs its own instance of an operating system. In most cases, each computing device uses the same hardware and the same operating system; however, in some cases, different operating systems may run on different hardware.

[0045] Figure 4 This is a schematic diagram of the computing device cluster provided in this embodiment. For example... Figure 4As shown, the computing device cluster includes multiple computing devices, such as 250A, 250B, 250C, 250D, and 250E. These computing devices provide computing resources. A single computing device can contain multiple processors or processor cores, each of which may be a computing resource; therefore, one physical computing device can provide multiple computing resources. Computing nodes 250A, 250B, 250C, 250D, and 250E are interconnected via network 272. Additionally, computing device 260, acting as a scheduler, is also connected to network 272. In operation, scheduler 260 can control the execution of jobs submitted to the computing device cluster, for example, splitting a job into multiple tasks and distributing them to different computing nodes for execution.

[0046] Jobs can be submitted to the computing device cluster from any suitable source. This embodiment does not limit the location of job submission, nor does it limit the specific mechanism by which users submit jobs. Figure 4 For example, user 232 can submit job 236 from enterprise 230 to the computing device cluster. Specifically, in this example, user 232 operates client computer 234 to submit job 236 to the computing device cluster. In this example, enterprise 230 is connected to the computing device cluster via network 272, which can be the Internet or other networks. Therefore, the user can submit jobs to the computing device cluster from a remote location. These jobs are typically large jobs requiring parallel processing of significant computing resources; this embodiment does not limit the nature or number of jobs. A job may contain multiple computing tasks, which can be allocated to multiple computing resources for execution. Most tasks are executed concurrently or in parallel, while some tasks depend on data generated by other tasks. This embodiment does not limit the number of tasks or the data of tasks that can be executed in parallel.

[0047] In a computing device cluster, multiple jobs typically await execution simultaneously. Allocating too many computing resources to a single job can negatively impact the performance of other jobs. Therefore, a scheduler 260 is configured in the computing device cluster. The scheduler 260 controls the allocation of computing resources to jobs awaiting execution, ensuring that high-priority jobs are executed first. The scheduler 260 monitors the execution status of jobs and adjusts resource allocation for those jobs according to a policy. For example, the scheduler 260 can obtain this policy by accessing information in a database 262. In addition to the policy, the database 262 also stores configuration files for each executing job and job awaiting execution, which can indicate information such as job processing time.

[0048] Inference model 130 refers to an algorithmic model that has been trained, possesses specific reasoning logic and computational capabilities, and is able to analyze, judge, or predict reasoning requests and output reasoning results. The inference model can be any of the following: Mixture of Experts (MoE) model, transformer model, multimodal fusion model, retrieval enhancement model, large language model (LLM), etc.

[0049] The LoRa gateway management platform 120 and the inference model 130 can be deployed on the same computing device or in the same computing device cluster. Alternatively, they can be deployed on different computing devices or in different computing device clusters. For example, the LoRa gateway management platform 120 can be deployed on an on-premises computing device within an enterprise, while the inference model 130 can be deployed on a public cloud platform. Another example is that both the LoRa gateway management platform 120 and the inference model 130 can be deployed on a private cloud within an enterprise.

[0050] See Figure 5 , Figure 5 This is a flowchart illustrating a fault analysis method provided in this application. Figure 5 As shown, the fault analysis method of this application includes: S101: The LoRa server receives log text sent by the LoRa gateway.

[0051] Log text is structured or raw, unstructured text data generated in real time by the LoRa gateway during operation. It comprehensively records the device's data transmission and reception status, operational behavior, abnormal events, and operating parameters, serving as raw record data reflecting the device's operating status and locating faults. When the LoRa server receives raw, unstructured log text, it can structure and store it to obtain the final log text. Conversely, when the LoRa server receives structured log text, the LoRa gateway can structure and store it to obtain the final structured log text, and then send the structured log text to the LoRa server.

[0052] The log text consists of multiple log records. Each log record is the basic data unit that makes up the log text. Each log record corresponds to an operation, data interaction, or state change of the LoRa gateway, objectively retaining relevant information about the device's operation.

[0053] Log entries can be one or more of the following: basic status logs, data interaction logs, link communication logs, and exception / fault logs. Basic status logs can record the gateway's own start / stop, online status, and hardware status. For example, a basic status log entry might be "2026-06-08 09:00:00 Gateway startup completed," or "2026-06-08 11:30:22 Gateway memory usage normal," etc. Data interaction logs record data exchange between the gateway and terminals / servers. For example, a data interaction log entry might be "2026-06-08 10:20:15 Terminal 001 data report successful," or "2026-06-08 14:10:05 Data forwarding to server completed," etc. Link communication logs are used to record information such as wireless link connection and signal quality. For example, a link communication log entry might be: 2026-06-08 10:20:15 Terminal 001 Signal Strength -70dBm, 2026-06-08 15:22:18 Wireless Link Connection Normal, etc. Anomaly / Fault logs are used to record problems such as communication interruptions, data anomalies, and device errors. For example, anomaly / fault log entry might be: 2026-06-08 10:21:03 Terminal 002 Link Disconnected, 2026-06-08 16:05:40 Data Parsing Failed, etc.

[0054] S102: The LoRa server generates a log template based on the log text.

[0055] Log templates are standard formatted text abstracted from log records of the same record category. The record category is a grouping of logs based on their content; log records within the same category have largely consistent semantics and format. For example, "2026-06-08 09:00:00 Gateway startup completed" and "2026-06-08 12:15:20 Gateway startup completed" are multiple log records of the same record category. Similarly, "2026-06-08 10:20:15 Terminal 001 data report successful" and "2026-06-08 10:21:10 Terminal 003 data report successful" are also multiple log records of the same record category.

[0056] The log template consists of a constant part and a wildcard part. The constant part is generated based on the common words in the log records of the same record category, while the wildcard part is generated based on the different words in the log records of the same record category.

[0057] For example, a log template could be: {Time} Gateway startup complete; In this template, {time} is the wildcard part, and "Gateway startup complete" is the constant part. This log template can be generated based on the following log records of the same category: 2026-06-08 09:00:00 Gateway startup complete; 2026-06-08 12:15:20 Gateway startup complete.

[0058] Here, "2026-06-08 09:00:00" and "2026-06-08 12:15:20" are the different parts of the two log records, so they can be replaced with the wildcard part "{time}". "Gateway startup completed" is the same part of the two log records, so it can be retained as the unchanged part.

[0059] For example, a log template could be: {Time} Terminal {Terminal Number} Data reporting successful; In this template, {Time} and {Terminal Number} are wildcard parts, while "Terminal" and "Data Report Successful" are constants. This log template can be generated based on the following log records of the same category: 2026-06-08 10:20:15 Terminal 001 successfully reported data; 2026-06-08 10:21:10 Terminal 003 successfully reported data.

[0060] Here, "2026-06-08 10:20:15" and "2026-06-08 10:21:10" are the different parts of the two log records, so they can be replaced with the wildcard part "{time}". "001" and "003" are also different parts of the two log records, so they can be replaced with the wildcard part "{terminal number}". "Terminal" is the common part of the two log records, so it can be retained as the unchanged part. "Data reported successfully" is the common part of the two log records, so it can be retained as the unchanged part.

[0061] In one specific implementation, the LoRa server can use Drain3 to extract log templates.

[0062] S103: The LoRa server matches multiple log records based on multiple log templates to obtain multiple matching information and multiple matching confidence levels.

[0063] The matching information includes the number of matches and the template timestamp. The number of matches is the total number of log records successfully matched by the given log template. The template timestamp includes the timestamps of the log records that were successfully matched by the corresponding log template.

[0064] Match confidence score measures the degree of certainty between a log record and a log template. It quantifies how well a log record matches a log template; a higher confidence score indicates a stronger match. For example, categorical confidence score can be a value between 0 and 1. A categorical confidence score of 0 indicates a 0% match between the log record and the log template, while a categorical confidence score of 1 indicates a 100% match.

[0065] Matching information can be calculated as follows: Assume log records include: 2026-06-08 09:00:00 Gateway startup completed; 2026-06-08 12:15:20 Gateway startup completed; 2026-06-08 10:20:15 Terminal 001 data report successful; 2026-06-08 10:21:10 Terminal 003 data report successful. The log template includes: {Time} Gateway startup completed; {Time} Terminal {Terminal Number} data report successful.

[0066] First, the LoRa server matches the log template "{Time} Gateway Startup Complete" with the four log records mentioned above. It is determined that the log template "{Time} Gateway Startup Complete" matches the log records "2026-06-08 09:00:00 Gateway Startup Complete; 2026-06-08 12:15:20 Gateway Startup Complete". Therefore, it can be determined that matching information 1 includes the log template "{Time} Gateway Startup Complete", the number of matches is 2, and the template timestamps are "2026-06-08 09:00:00 and 2026-06-08 12:15:20".

[0067] Secondly, the LoRa server matches the log template "{Time} Gateway startup complete; {Time} Terminal {Terminal ID} data reporting successful" with the four log records mentioned above. It determines that the log template "{Time} Gateway startup complete; {Time} Terminal {Terminal ID} data reporting successful" matches the log records "2026-06-08 10:20:15 Terminal 001 data reporting successful; 2026-06-08 10:21:10 Terminal 003 data reporting successful". Therefore, it can be determined that matching information 2 includes the log template "{Time} Gateway startup complete; {Time} Terminal {Terminal ID} data reporting successful", the number of matches is 2, and the template timestamps are "2026-06-08 10:20:15 and 2026-06-08 10:21:10".

[0068] Here, if a log record matches a log template, the matching confidence between the log template and the log record is calculated; otherwise, if a log record does not match a log template, there is no need to calculate the matching confidence between the log template and the log record.

[0069] The following section will use the first log template and the first log record as an example to explain in detail how to match log templates and log records.

[0070] Method 1: The LoRa server transforms the first log template into a first feature vector using classic NLP semantic vector modeling, and the first log record into a second feature vector using the same method. Then, it calculates the cosine similarity between the first and second feature vectors. If the cosine similarity is greater than a first threshold, the first log template and the first log record are considered a match. The first threshold can be set empirically. In this case, the cosine similarity between the first log template and the first log record represents the classification confidence between them.

[0071] Method 2: The LoRa server segments the first log template into multiple first-level words, and segments the first log record into second-level words. The LoRa server matches the first word in each of the first and second-level words, and so on, until the last word in each of the first and second-level words is matched. Then, based on the number of matched words and the total number of words in the first-level words, a matching ratio is calculated. If the matching ratio is greater than a second threshold, a match is determined between the first log template and the first log record. The second threshold can be set empirically. The matching ratio between the first log template and the first log record is then the classification confidence score between them.

[0072] It is understandable that the methods one and two described above are merely specific examples, and many more methods can be used in practical applications. The examples above only illustrate the matching method between the first log template and the first log record; the matching methods between other log templates and log records are similar and will not be elaborated here.

[0073] Matching multiple log records using multiple log templates can be triggered upon the occurrence of an alarm event. The triggering conditions for an alarm event include any one of the following: receiving a detection signal input by the user, a successful match between a fault regular expression and the most recent log record, or an anomaly in the LoRa gateway's metrics. Metrics include one or more of the following: P95 latency, anomaly count, etc. In this case, log text for a time window preceding the alarm event can be obtained, and this time window's log text can be matched against multiple log templates.

[0074] S104: The LoRa server classifies events based on multiple matching information and an event classification library to obtain multiple event categories.

[0075] The event classification library is a predefined, standardized set of fault events designed for IoT gateway operation and maintenance scenarios. It supports versioned iterative updates and serves as the core reference for event classification. For example, the event classification library may include one or more of the following: queue timeout, sudden increase in network latency, CPU saturation, proxy disconnection, sudden drop in traffic, authentication failure, telemetry data interruption, firmware restart, domain name resolution failure, etc. The event category can be any one of the events in the event classification library.

[0076] Classification confidence quantifies how credible it is that a match is assigned to a particular event category. A higher confidence score indicates a more reliable match between the match and the event category. For example, classification confidence can be a value between 0 and 1. A classification confidence score of 0 indicates 0% reliability between the match and the event category, while a classification confidence score of 1 indicates 100% reliability.

[0077] Multiple event categories can be calculated as follows: The LoRa server inputs the first matching information and event classification library into a small language model (e.g., Llama 3.1 or Mistral Nemo) to obtain the first event category. Then, the LoRa server inputs the second matching information and event classification library into the small language model to obtain the second event category, and so on, until the LoRa server inputs the last matching information and event classification library into the small language model to obtain the last event category.

[0078] S105: The LoRa server aggregates, clusters, and associates one or more of multiple event categories to obtain evidence packages and multiple cluster confidence scores.

[0079] A LoRa server can aggregate multiple event categories in several ways: It can deduplicate identical event categories and record information such as the number of times each event is triggered, the start time, and the end time. Alternatively, it can aggregate event categories from the same source, such as those from the same LoRa node or LoRa gateway.

[0080] The LoRa server clusters multiple event categories as follows: The LoRa server calculates temporal correlation, semantic correlation, device context correlation, and historical co-occurrence correlation. Then, it weights these correlations to obtain a correlation score. Finally, it clusters the multiple event categories based on the correlation score, resulting in multiple event clusters. Temporal correlation indicates the proximity of event categories in terms of occurrence time. The closer the occurrence times of event categories, the stronger the correlation; the further apart the occurrence times, the weaker the correlation. Semantic correlation indicates the similarity of the meanings of event categories. The more similar the semantics between event categories, the stronger the correlation; the greater the semantic differences, the weaker the correlation. Contextual correlation indicates the correlation of LoRa gateway context information. The more similar the LoRa gateway context information for event categories, the stronger the correlation; the greater the differences in LoRa gateway context information, the weaker the correlation. Historical co-occurrence correlation indicates whether event categories have occurred together in historical faults. The more times event categories have occurred together in historical faults, the stronger the correlation; the fewer times they have occurred together, the weaker the correlation.

[0081] A LoRa server can associate multiple event categories by generating a time-sliding window and counting the number of times two event categories appear simultaneously within that window. If the number of simultaneous occurrences of two event categories exceeds a threshold, the two event categories are considered associated. The time-sliding window can be set as needed, for example, 5 minutes, 10 minutes, etc.

[0082] It is understood that the above aggregation, clustering, and association can be performed individually or in combination, without specific limitations here.

[0083] Cluster confidence is a quantitative value of the similarity between event categories within a corresponding event cluster. The higher the cluster confidence, the closer the relationship between event categories within the cluster, and the more reliable the clustering result.

[0084] S106: The LoRa server performs root cause analysis based on the evidence packet to obtain the root cause analysis results and the root cause analysis confidence level.

[0085] Root cause analysis results can be calculated using the following methods, which will be described in detail below.

[0086] Method 1: The LoRa server performs root cause analysis based on the evidence packets to obtain the root cause analysis results.

[0087] Method 2: The LoRa server performs root cause analysis based on the context information and evidence packets of the LoRa gateway to obtain the root cause analysis results.

[0088] The context information of a LoRa gateway includes one or more of the following: basic device information of the LoRa gateway and weather information.

[0089] Basic device information for a LoRa gateway may include one or more of the following: gateway identifier, device EUI, MAC address, SN serial number, hardware model, product series, channel specification, physical installation address, area code, latitude and longitude, building / location number, project, maintenance group, management node, firmware version, system version, operating status, system configuration, operating frequency band, spreading factor, transmit power, channel number, antenna specification, receive sensitivity, LoRaWAN protocol version, terminal operating mode, wired IP address, gateway, DNS, signal strength, base station information, connected cloud platform address, port, communication protocol (MQTT / PF, etc.), encryption status, link keep-alive interval, etc.

[0090] Weather information includes one or more of the following: ambient temperature, relative humidity, precipitation, wind speed and direction, visibility, fog, ultraviolet radiation, and air pressure.

[0091] Method 3: The LoRa server performs root cause analysis based on historical work orders and evidence packets to obtain the root cause analysis results.

[0092] Historical work orders are retrieved from the historical fault work order database based on one or more of the following: work order description, device operating status, and LoRa gateway context information.

[0093] The historical fault ticket database can include multiple historical tickets. Each historical ticket can include a ticket description, device operating status, LoRa gateway context information, etc. Furthermore, each historical work order can also include basic event information, such as the alarm event identifier, alarm event type, work order description, time window for obtaining log text, severity level of the alarm event, etc.; behavioral context, such as matching information, event category, event cluster, etc.; LoRa gateway context when the alarm event occurred, such as gateway identifier, device EUI, MAC address, SN serial number, hardware model, product series, channel specification, physical installation address, area code, latitude and longitude, building / location number, project, maintenance group, management node, firmware version, system version, operating status, system configuration, operating frequency band, spreading factor, transmit power, channel number, antenna specification, receive sensitivity, LoRaWAN protocol version, terminal operating mode, wired IP address, gateway, DNS, signal strength, base station information, connected cloud platform address, port, communication protocol, etc.; and handling information, such as root cause analysis results, troubleshooting operations, executed solutions, handling results, etc.

[0094] The LoRa server generates a text semantic vector based on the current work order description, a device status vector based on the current device operating status, and a context feature vector based on the current LoRa gateway context information. These three vector types are then concatenated or weighted and fused to generate a comprehensive retrieval vector. Each historical work order in the historical fault work order database is pre-vectorized into historical text semantic vectors, historical device status vectors, and historical context feature vectors. These three vector types are then concatenated or weighted and fused to generate a historical comprehensive retrieval vector. The similarity between this comprehensive retrieval vector and each historical comprehensive retrieval vector is then calculated. The LoRa server selects the N historical work orders with the highest similarity based on the vector similarity.

[0095] Method 4: Root cause analysis is performed based on the context information of the LoRa gateway, historical work orders, and evidence packets to obtain the root cause analysis results.

[0096] Root cause analysis confidence can be calculated by weighting one or more of the following: match confidence, classification confidence, clustering confidence, retrieval confidence, and inference confidence. The calculation methods for inference confidence include at least the following: Method 1: The LoRa server calculates the root cause analysis confidence score by weighting one or more of the following: match confidence score, classification confidence score, clustering confidence score, and inference confidence score. Further, the LoRa server averages multiple match confidence scores to obtain an average match confidence score, averages multiple classification confidence scores to obtain an average classification confidence score, and averages multiple clustering confidence scores to obtain an average clustering confidence score. Finally, the average clustering confidence score, average classification confidence score, average clustering confidence score, and retrieval confidence score are weighted to obtain the root cause analysis confidence score.

[0097] Method 2: The LoRa server calculates the root cause analysis confidence score by weighting one or more of the following: match confidence score, classification confidence score, cluster confidence score, retrieval confidence score, and inference confidence score. Further, the LoRa server averages multiple match confidence scores to obtain an average match confidence score, averages multiple classification confidence scores to obtain an average classification confidence score, averages multiple cluster confidence scores to obtain an average cluster confidence score, and averages multiple retrieval confidence scores to obtain an average retrieval confidence score. Finally, the average cluster confidence score, average classification confidence score, average cluster confidence score, average retrieval confidence score, and retrieval confidence score are weighted to obtain the root cause analysis confidence score.

[0098] S107: The LoRa server searches for fault repair libraries based on the root cause analysis results and obtains repair suggestions.

[0099] The fault repair library stores repair suggestions for various LoRa gateway faults. The library may contain one or more repair suggestions. These suggestions are standardized fault handling guidelines stored in the library, used by operations and maintenance personnel for troubleshooting, device repair, and risk mitigation. Furthermore, each repair suggestion in the library can be converted into a repair feature vector using a vector embedding algorithm.

[0100] Repair suggestions can be obtained as follows: The LoRa server converts the root cause analysis results into root cause feature vectors using a vector embedding algorithm. Cosine similarity is then calculated between each root cause feature vector and multiple repair feature vectors in the fault repair database. The server selects the cosine similarity with the highest similarity and uses this as the final repair suggestion. Furthermore, the correspondence between the current root cause analysis results and repair suggestions can be stored to update the fault repair database.

[0101] In the above solution, log templates are used to match, classify, and cluster log records, transforming massive amounts of log text into more concise and meaningful event clusters. These clusters are then provided to the inference model for root cause analysis. This avoids directly feeding hundreds or thousands of independent log records to the inference model; instead, the log text is deeply refined to obtain deep semantics. This reduces noise, lowers the lexical consumption required by the inference model, and helps the model focus on the most relevant operational issues, rather than being overwhelmed by massive amounts of log text. This effectively overcomes the illusion and instability problems of inference models under long context forgetting and information overload, achieving accurate fault root cause location and standardized repair suggestion output, significantly improving the automation level and diagnostic accuracy of IoT gateway operation and maintenance.

[0102] See Figure 6 , Figure 6 This is a structural schematic diagram of an operation and maintenance device provided in this application. For example... Figure 6 As shown, the operation and maintenance device of this application includes: The receiving module 310 is used to receive log text sent by the LoRa gateway, wherein the log text includes multiple log records; Matching module 320 is used to match the multiple log records based on multiple log templates to obtain multiple matching information; The classification module 330 is used to classify events based on the multiple matching information and the event classification library to obtain multiple event categories; The evidence generation module 340 is used to aggregate, cluster, and associate the multiple event categories to obtain an evidence package. The sending module 350 is used to send the evidence package to the inference model for root cause analysis and obtain the root cause analysis results.

[0103] See Figure 7 , Figure 7 This is a schematic diagram of the structure of a fault analysis device provided in this application. Figure 7 As shown, the fault analysis apparatus of this application includes: The receiving module 410 is used to receive log text sent by the LoRa gateway, wherein the log text includes multiple log records.

[0104] The matching module 420 is used to match the multiple log records based on multiple log templates to obtain multiple matching information.

[0105] The classification module 430 is used to classify events based on the multiple matching information and the event classification library to obtain multiple event categories.

[0106] The evidence generation module 440 is used to aggregate, cluster, and associate the multiple event categories to obtain an evidence package. Analysis module 450 is used to perform root cause analysis based on the evidence package to obtain root cause analysis results; The suggestion module 460 is used to search the fault repair library based on the root cause analysis results and obtain repair suggestions.

[0107] The following will be based on Figure 7 The fault analysis device shown is used as an example for explanation. Figure 6 The operation and maintenance equipment shown Figure 7 The fault analysis device shown is similar.

[0108] The receiving module 410, matching module 420, classification module 430, evidence generation module 440, analysis module 450, and suggestion module 460 can all be implemented in software or hardware. For example, the implementation of the matching module 420 will be described below. Similarly, the implementation of the receiving module 410, classification module 430, evidence generation module 440, analysis module 450, and suggestion module 460 can refer to the implementation of the matching module 420.

[0109] As an example of a software functional unit, the matching module 420 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, or a container. Furthermore, the aforementioned computing instance may be one or more. For example, the matching module 420 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed within the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed within the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0110] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0111] As an example of a hardware functional unit, the matching module 420 may include at least one computing device, such as a server. Alternatively, the matching module 420 may be implemented using a central processing unit (CPU), an application-specific integrated circuit (ASIC), or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), a data processing unit (DPU), a neural network processing unit (NPU), a system-on-chip (SoC), an offload card, an accelerator card, or any combination thereof.

[0112] The matching module 420 includes multiple computing devices that can be distributed in the same region or in different regions. Similarly, the matching module 420 includes multiple computing devices that can be distributed in the same Availability Zone (AZ) or in different AZs. Likewise, the matching module 420 includes multiple computing devices that can be distributed in the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, GALs, DPUs, NPUs, SoCs, offloading cards, and accelerator cards.

[0113] It should be noted that in other embodiments, the matching module 420 can be used to execute any step in the fault analysis method, and other modules can be used to execute any step in the fault analysis method. The steps that each module is responsible for implementing can be specified as needed. By implementing different steps in the fault analysis method through operation and maintenance, most of the fault analysis device can be realized.

[0114] This application also provides a computing device 500. For example... Figure 8 As shown, the computing device 500 includes a bus 502, a processor 504, a memory 506, and a communication interface 508. The processor 504, the memory 506, and the communication interface 508 communicate with each other via the bus 502. The computing device 500 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 500.

[0115] Bus 502 can be a Peripheral Component Interconnect Express (PCIe) bus, an Extended Industry Standard Architecture (EISA) bus, a Unified Bus (Ubus or UB), a Compute Express Link (CXL) bus, a Cache Coherent Interconnect for Accelerators (CCIX) bus, etc. The Unified Bus is also known as the Lingqu Bus. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 8 The bus 502 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 502 may include a path for transmitting information between various components of the computing device 500 (e.g., memory 506, processor 504, communication interface 508).

[0116] Processor 504 may include any one or more computing devices such as a central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP) or digital signal processor (DSP), ASIC, FPGA, CPLD, NPU, SoC, offload card, accelerator card, etc.

[0117] Memory 506 may include volatile memory, such as random access memory (RAM). Processor 504 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD). Furthermore, memory 506 may also be implemented using storage class memory (SCM), phase change memory (PCM), or other types of storage media.

[0118] It is worth noting that the same type of storage medium can be configured in the same computing device to realize the function of memory 506, or two or more types of storage media can be configured to realize the function of memory 506. This application does not limit this.

[0119] The memory 506 stores executable program code, which the processor 504 executes to implement the functions of the aforementioned matching module 420, receiving module 410, classification module 430, evidence generation module 440, analysis module 450, and suggestion module 460, thereby realizing the fault analysis method. In other words, the memory 106 stores instructions for executing the fault analysis method.

[0120] Alternatively, the memory 506 stores executable code, which the processor 504 executes to implement the functions of the aforementioned maintenance device and fault analysis device, thereby realizing the fault analysis method. In other words, the memory 506 stores instructions for executing the fault analysis method.

[0121] The communication interface 508 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computing device 500 and other devices or communication networks.

[0122] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0123] like Figure 9 As shown, the computing device cluster includes at least one computing device 500. The memory 506 of one or more computing devices 500 in the computing device cluster may store the same instructions for executing fault analysis methods.

[0124] In some possible implementations, the memory 506 of one or more computing devices 500 in the computing device cluster may also store partial instructions for executing the fault analysis method. In other words, a combination of one or more computing devices 500 can jointly execute the instructions for executing the fault analysis method.

[0125] It should be noted that the memory 506 in different computing devices 500 within the computing device cluster can store different instructions, which are used to execute some functions of the operation and maintenance device and the fault analysis device, respectively. That is, the instructions stored in the memory 506 of different computing devices 500 can implement the functions of one or more modules among the matching module 420, receiving module 410, classification module 430, evidence generation module 440, analysis module 450, and suggestion module 460.

[0126] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 10 One possible implementation is shown. For example... Figure 10 As shown, the two computing devices 500A and 500B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this possible implementation, the memory 506 in computing device 500A stores instructions for executing the functions of the matching module 420. Simultaneously, the memory 506 in computing device 500B stores instructions for executing the functions of the receiving module 410, the evidence generation module 430, the generation module 440, and the analysis module 450.

[0127] Figure 10 The connection method between the computing device clusters shown can be such that, considering the fault analysis method provided in this application requires a large amount of data storage and a large amount of computation, the functions implemented by the analysis module 450 are delegated to the computing device 500B.

[0128] It should be understood that Figure 10The functions of computing device 500A shown can also be performed by multiple computing devices 500. Similarly, the functions of computing device 500B can also be performed by multiple computing devices 500.

[0129] This application also provides another computing device cluster. The connection relationships between the computing devices in this computing device cluster can be similarly referred to... Figure 9 and Figure 10 The connection method of the computing device cluster is different in that the memory 506 of one or more computing devices 500 in the computing device cluster can store the same instructions for executing the fault analysis method.

[0130] In some possible implementations, the memory 506 of one or more computing devices 500 in the computing device cluster may also store partial instructions for executing the fault analysis method. In other words, a combination of one or more computing devices 500 can jointly execute the instructions for executing the fault analysis method.

[0131] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to perform a fault analysis method.

[0132] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center that includes one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to perform a fault analysis method.

[0133] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of this application.

Claims

1. An operation and maintenance method, characterized in that, include: Receive log text sent by the LoRa gateway, wherein the log text includes multiple log records; The multiple log records are matched based on multiple log templates to obtain multiple matching information; Based on the multiple matching information and the event classification library, multiple event categories are obtained; The evidence package is obtained by aggregating, clustering, and associating the multiple event categories. Root cause analysis was performed based on the evidence package to obtain the root cause analysis results; Based on the root cause analysis results, a fault repair database is searched to obtain repair suggestions.

2. The method according to claim 1, characterized in that, Root cause analysis is performed based on the evidence package to obtain the root cause analysis results, including: Root cause analysis is performed based on the context information of the LoRa gateway, at least one of the historical work orders, and the evidence package to obtain the root cause analysis results. The context information of the LoRa gateway includes one or more of the basic device information of the LoRa gateway and weather information. The historical work orders are retrieved from the historical fault work order database based on one or more of the work order description, device operating status, and the context information of the LoRa gateway.

3. The method according to claim 2, characterized in that, After performing root cause analysis based on the evidence package and obtaining the root cause analysis results, the method further includes: The root cause analysis confidence score is obtained by weighting one or more of the following: matching confidence score, classification confidence score, clustering confidence score, and inference confidence score. The matching confidence score is the degree of credibility of the match between the log record and the log template. The classification confidence score is the degree of credibility of the log record matching the corresponding event category. The clustering confidence score is the degree of credibility of multiple event categories clustering into the same event cluster. The inference confidence score is the degree of reliability of deriving the corresponding root cause of the failure from the features of the event cluster.

4. The method according to claim 3, characterized in that, The root cause analysis confidence score is obtained by weighting one or more of the following: matching confidence score, classification confidence score, clustering confidence score, and inference confidence score: The root cause analysis confidence score is obtained by weighting one or more of the following: matching confidence score, classification confidence score, clustering confidence score, retrieval confidence score, and inference confidence score. The retrieval confidence score is the degree of credibility of the match between the retrieved historical work order and the LoRa gateway context information, the device operating status, and the work order description when searching in the historical fault work order database.

5. The method according to claim 4, characterized in that, The number of match confidence scores is multiple, and the number of match confidence scores is the same as the number of match information scores. The number of classification confidence scores is multiple, and the number of classification confidence scores is the same as the number of event categories. The number of clustering confidence scores is multiple, and the number of clustering confidence scores is the same as the number of event clusters. The number of retrieval confidence scores is multiple, and the number of retrieval confidence scores is the same as the number of historical work orders. A weighted calculation is performed based on one or more of the match confidence scores, classification confidence scores, clustering confidence scores, and inference confidence scores to obtain the root cause analysis confidence score, including: The root cause analysis confidence score is obtained by weighting one or more of the following: average match confidence score, average classification confidence score, average clustering confidence score, average retrieval confidence score, and inference confidence score. Specifically, the average match confidence score is obtained by averaging multiple match confidence scores, the average classification confidence score is obtained by averaging multiple classification confidence scores, the average clustering confidence score is obtained by averaging multiple clustering confidence scores, and the average retrieval confidence score is obtained by averaging multiple retrieval confidence scores.

6. The method according to any one of claims 1 to 5, characterized in that, Before matching the multiple log records based on multiple log templates, the method further includes: Multiple log templates are generated for multiple record categories, wherein the multiple record categories include a first record category, and the multiple log templates include a first log template. The first log template includes an invariant part and a wildcard part. The invariant part is generated based on the parts of words that are the same in each log record of the first record category, and the wildcard part is generated based on the parts of words that are different in each log record of the first record category.

7. The method according to any one of claims 1 to 6, characterized in that, The multiple log records are matched based on multiple log templates to obtain multiple matching information, including: In the event of an alarm, the multiple log records are matched based on multiple log templates to obtain multiple matching information. The triggering conditions of the alarm event include any one of the following: receiving a detection signal input by the user, a successful match between the fault regular expression and the most recent log record, or an abnormality in the LoRa gateway's metrics. The metrics include one or more of the following: P95 latency and anomaly count.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: the LoRa gateway or LoRa server periodically performing structured storage on the original log text to obtain the log text.

9. The method according to any one of claims 1 to 8, characterized in that, Each matching information includes a log template, the number of matches, and a template timestamp, wherein the template timestamp includes the timestamp of the log record that was successfully matched with the corresponding log template.

10. An operation and maintenance method, characterized in that, include: Receive log text sent by the LoRa gateway, wherein the log text includes multiple log records; The multiple log records are matched based on multiple log templates to obtain multiple matching information; Based on the multiple matching information and the event classification library, multiple event categories are obtained; The evidence package is obtained by aggregating, clustering, and associating the multiple event categories. The evidence package is sent to the inference model to perform root cause analysis, and the root cause analysis results are obtained.

11. A maintenance device, characterized in that, include: The receiving module is used to receive log text sent by the LoRa gateway, wherein the log text includes multiple log records; The matching module is used to match the multiple log records based on multiple log templates to obtain multiple matching information; A classification template is used to classify events based on the multiple matching information and the event classification library to obtain multiple event categories. The evidence generation module is used to aggregate, cluster, and associate the multiple event categories to obtain an evidence package. The analysis module is used to perform root cause analysis based on the evidence package to obtain the root cause analysis results; The search module is used to search the fault repair library based on the root cause analysis results and obtain repair suggestions.

12. A maintenance device, characterized in that, include: The receiving module is used to receive log text sent by the LoRa gateway, wherein the log text includes multiple log records; The matching module is used to match the multiple log records based on multiple log templates to obtain multiple matching information; The classification module is used to classify events based on the multiple matching information and the event classification library to obtain multiple event categories. The evidence generation module aggregates, clusters, and associates the multiple event categories to obtain an evidence package. The sending module is used to send the evidence package to the inference model for root cause analysis and obtain the root cause analysis results.

13. A computing device, characterized in that, include: A processor and a memory, wherein the processor is connected to the memory, the memory is used to store instructions, and the processor is used to read the instructions from the memory to perform the method as claimed in any one of claims 1-9.

14. A program product containing instructions, characterized in that, Includes instructions that, when executed by a computing device, cause the computing device to perform the method as described in any one of claims 1-9.

Images