Log data alarm prompting method and device, electronic equipment and readable storage medium

Abstract

The invention relates to the technical field of data processing, and provides a log data alarm prompting method and device, electronic equipment and a readable storage medium. The method comprises the steps of performing analysis processing on to-be-processed abnormal log data to obtain an attribute field corresponding to the to-be-processed abnormal log data; performing standardization processing on the attribute field to obtain standardized abnormal data; based on a preset alarm template, performing frequency control duplicate removal processing on the standardized abnormal data to obtain a target alarm text; and performing queue transmission on the target alarm text, so that the target alarm text is displayed to the terminal equipment, thereby improving the accuracy and real-time performance of alarm information, enhancing the processing capability of abnormal logs, improving the reliability of alarm notification, improving the operation and maintenance efficiency and the fault repair speed, and improving the user experience. The timeliness and the traceability of the alarm information are ensured through a standardized format and a reliable transmission mechanism, and the service relevance and the system collaboration of the alarm information are enhanced.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, and in particular to a log data alarm prompting method, apparatus, electronic device and readable storage medium. Background Technology

[0002] In the field of log monitoring and alerting, existing technologies typically employ an Elastic Stack integrated with Elast Alert. This involves collecting logs through Beats, parsing and processing them through Logstash, storing and indexing them through Elasticsearch, and then having Elast Alert perform anomaly detection and alerting based on rules in a different markup language (YAML Ain't Markup Language). However, in complex business scenarios, this approach suffers from several drawbacks due to the lack of effective integration between the technical implementation mechanism of the log monitoring and alerting system and the business operation mechanism. These issues include high technical barriers to alert rule configuration, a disconnect between anomaly detection and business logic, a lack of fine-grained permission management for alert notifications, and complex system component collaboration.

[0003] It is evident that existing technologies suffer from a lack of effective integration between the technical implementation mechanism of log monitoring and alarm systems and the business operation mechanism, resulting in weak business relevance, low efficiency in log information distribution, insufficient accuracy in notifications, and poor system coordination. Summary of the Invention

[0004] In view of this, the present disclosure provides a log data alarm notification method, device, electronic device, and readable storage medium to solve the problems in the prior art where the lack of effective integration between the technical implementation mechanism and business operation mechanism of log monitoring and alarm systems leads to weak business correlation, low log information allocation efficiency, insufficient notification accuracy, and poor system coordination.

[0005] A first aspect of this disclosure provides a log data alarm notification method, comprising: parsing and processing abnormal log data to obtain attribute fields corresponding to the abnormal log data to be processed; standardizing the attribute fields to obtain standardized abnormal data; performing frequency control deduplication processing on the standardized abnormal data based on a preset alarm template to obtain a target alarm text; and transmitting the target alarm text in a queue to display the target alarm text on a terminal device.

[0006] In some embodiments, after performing frequency control deduplication on standardized abnormal data based on a preset alarm template to obtain the target alarm text, the method further includes: performing anomaly level evaluation on the target alarm text to obtain a target anomaly level; matching the target anomaly level with a preset set of notification objects to obtain a target notification object; and performing method selection on the target notification object based on a preset notification method to obtain a target push method, wherein the target push method is used to characterize the queue transmission method of the target alarm text.

[0007] In some embodiments, frequency control deduplication processing is performed on standardized abnormal data based on a preset alarm template to obtain target alarm text, including: extracting abnormal types from the standardized abnormal data to obtain abnormal feature data; performing frequency control deduplication processing on the abnormal feature data based on a preset time window to obtain target screening results; and filling the target screening results based on a preset alarm template to obtain target alarm text.

[0008] In some embodiments, the attribute field is standardized to obtain standardized abnormal data, including: performing context completion on the attribute field to obtain a target extended field; and performing formatted encapsulation on the target extended field to obtain standardized abnormal data.

[0009] In some embodiments, parsing the abnormal log data to be processed to obtain the attribute fields corresponding to the abnormal log data to be processed includes: performing format recognition processing on the abnormal log data to be processed to obtain the log format type; performing field extraction processing on the log format type to obtain the field extraction result; and performing structured encapsulation processing on the field extraction result to obtain the attribute fields.

[0010] In some embodiments, before parsing the abnormal log data to be processed to obtain the attribute fields corresponding to the abnormal log data to be processed, the method further includes: obtaining log data; performing association matching processing on the log data based on a preset list of abnormal keywords to obtain an initial abnormal log; and performing source marking processing on the initial abnormal log to obtain the abnormal log data to be processed.

[0011] In some embodiments, after the target alarm text is queued and transmitted to the terminal device, the method further includes: performing interface rendering processing on the terminal device in response to the terminal device display instruction to obtain a visual alarm interface; and displaying the target alarm text on the visual alarm interface in response to the alarm interface trigger instruction.

[0012] A second aspect of this disclosure provides a log data alarm notification device, comprising: a first processing module for parsing and processing abnormal log data to obtain attribute fields corresponding to the abnormal log data; a second processing module for standardizing the attribute fields to obtain standardized abnormal data; a third processing module for performing frequency control deduplication on the standardized abnormal data based on a preset alarm template to obtain a target alarm text; and a fourth processing module for queuing and transmitting the target alarm text to a terminal device.

[0013] A third aspect of this disclosure provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described above.

[0014] A fourth aspect of this disclosure provides a readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0015] The beneficial effects of this embodiment compared with the prior art are as follows: By parsing and processing the abnormal log data to be processed, the attribute fields corresponding to the abnormal log data to be processed are obtained; the attribute fields are standardized to obtain standardized abnormal data; the standardized abnormal data is frequency-controlled and deduplicated based on a preset alarm template to obtain the target alarm text; the target alarm text is queued and transmitted to the terminal device, thereby improving the accuracy and real-time performance of alarm information, enhancing the processing capability of abnormal logs, improving the reliability of alarm notifications, realizing intelligent filtering and accurate alarm of abnormal information, reducing alarm noise and false alarm rate, improving operation and maintenance efficiency and fault repair speed, and ensuring the timeliness and traceability of alarm information through standardized format and reliable transmission mechanism, enhancing the business relevance and system synergy of alarm information. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic diagram illustrating an application scenario of an embodiment of this disclosure; Figure 2 This is a flowchart illustrating a log data alarm notification method provided in an embodiment of this disclosure; Figure 3This is a flowchart illustrating another log data alarm notification method provided in this embodiment of the disclosure; Figure 4 This is a flowchart illustrating an abnormal data capture and reporting method provided in an embodiment of this disclosure; Figure 5 This is a schematic diagram of the structure of a log data alarm notification device provided in an embodiment of this disclosure; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0018] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, so as to provide a thorough understanding of the embodiments of this disclosure. However, those skilled in the art will understand that this disclosure may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this disclosure with unnecessary detail.

[0019] It should be noted that the user information (including but not limited to terminal device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties.

[0020] A log data alarm notification method and apparatus according to an embodiment of the present disclosure will now be described in detail with reference to the accompanying drawings.

[0021] Figure 1 This is a schematic diagram illustrating an application scenario of an embodiment of this disclosure. The application scenario may include terminal devices 1, 2, and 3, server 4, and network 5.

[0022] Terminal devices 1, 2, and 3 can be hardware or software. When terminal devices 1, 2, and 3 are hardware, they can be various electronic devices with displays and supporting communication with server 4, including but not limited to smartphones, tablets, laptops, and desktop computers. When terminal devices 1, 2, and 3 are software, they can be installed in the aforementioned electronic devices. Terminal devices 1, 2, and 3 can be implemented as multiple software programs or software modules, or as a single software program or software module; this disclosure does not limit this. Furthermore, various applications can be installed on terminal devices 1, 2, and 3, such as data processing applications, instant messaging tools, social platform software, search applications, shopping applications, etc.

[0023] Server 4 can be a server that provides various services, such as a backend server that receives requests sent by terminal devices with which it has established communication connections. This backend server can receive and analyze the requests sent by the terminal devices and generate processing results. Server 4 can be a single server, a server cluster consisting of several servers, or a cloud computing service center. This disclosure embodiment does not limit this.

[0024] It should be noted that server 4 can be either hardware or software. When server 4 is hardware, it can be various electronic devices that provide various services to terminal devices 1, 2, and 3. When server 4 is software, it can be multiple software programs or software modules that provide various services to terminal devices 1, 2, and 3, or it can be a single software program or software module that provides various services to terminal devices 1, 2, and 3. This disclosure does not limit the scope of the embodiments.

[0025] Network 5 can be a wired network using coaxial cable, twisted pair, and fiber optic connection, or it can be a wireless network that enables interconnection of various communication devices without wiring, such as Bluetooth, Near Field Communication (NFC), and Infrared. This disclosure does not limit the scope of the network.

[0026] Users can establish a communication connection with server 4 via network 5 through terminal devices 1, 2, and 3 to receive or send information. Specifically, server 4 can obtain pending exception log data through terminal devices 1, 2, and 3, parse and process the pending exception log data to obtain the attribute fields corresponding to the pending exception log data; perform standardization processing on the attribute fields to obtain standardized exception data; perform frequency control and deduplication processing on the standardized exception data based on a preset alarm template to obtain the target alarm text; and queue and transmit the target alarm text to display it on the terminal devices.

[0027] It should be noted that the specific types, quantities, and combinations of terminal devices 1, 2, and 3, server 4, and network 5 can be adjusted according to the actual needs of the application scenario, and this disclosure embodiment does not impose any restrictions on this.

[0028] Figure 2 This is a flowchart illustrating a log data alarm notification method provided in an embodiment of this disclosure. Figure 2 The log data alarm notification method can be provided by Figure 1 The server executes the command. For example... Figure 2 As shown, the log data alarm notification method includes: S201, parse and process the exception log data to be processed to obtain the attribute fields corresponding to the exception log data to be processed.

[0029] Specifically, the abnormal log data to be processed can be the portion of the raw log data obtained from the data source that contains abnormal information, and it can be unstructured log entries. This abnormal log data to be processed can be used as input data for subsequent analysis. Furthermore, this abnormal log data to be processed can be obtained through log file monitoring or application instrumentation, which can provide basic information for attribute field extraction and can also be used to characterize the abnormal state of the system during operation.

[0030] The attribute field can be a structured data unit extracted from the anomaly log data to be processed through parsing. The attribute field corresponding to the anomaly log data to be processed can be a key-value pair used to characterize the anomaly features, which can be used to identify the anomaly type and severity in subsequent steps. The attribute field can also include the anomaly occurrence time, anomaly type code, and descriptive information, etc., which are not limited here. This can provide standardized input for alarm rule matching and route allocation. The attribute field can also be used to characterize the specific attributes of the anomaly.

[0031] Furthermore, the parsing process can include format conversion and field extraction of the raw log data. For example, timestamps, error levels, and message content can be identified and separated from the log text using regular expressions or pattern recognition, which is not limited here.

[0032] For example, in system monitoring application scenarios, file acquisition tools can be used to obtain log data of anomalies to be processed. The log data of anomalies to be processed can be parsed to extract attribute fields such as the anomaly type "database connection timeout" and the timestamp of occurrence.

[0033] In addition, parsing can also include standardizing the encoding of the exception log data to be processed, for example, converting the text-based exception type into a numeric code to reduce storage and transmission overhead.

[0034] Furthermore, the standardized coding process can also map specified exception descriptions to unique identifiers based on a predefined coding rule table, ensuring the consistency of attribute fields.

[0035] This application embodiment parses and processes the abnormal log data to be processed. Through format conversion and field extraction, the attribute fields corresponding to the abnormal log data to be processed are obtained. The parsed attribute fields are then standardized and encoded. Through rule mapping and identifier conversion, consistent structured attribute data is generated. By parsing and processing the abnormal log data to be processed and extracting attribute fields, the abnormal log information is structured and standardized, providing basic data support for subsequent intelligent analysis and accurate alarms, and improving the efficiency and accuracy of alarm processing.

[0036] S202, standardize the attribute fields to obtain standardized outlier data.

[0037] Specifically, standardization processing can include parsing attribute fields to extract key information and converting heterogeneous data into a unified format to ensure data consistency and processability. Standardized anomaly data can be anomaly information in a unified format obtained through standardization processing. This standardized anomaly data can be represented in a structured form such as Lightweight Data Interchange Format (JavaScript Object Notation, JSON) and can contain fixed fields for subsequent intelligent analysis, routing, and notification.

[0038] Furthermore, anomaly analysis can extract fields such as timestamp, device identifier, and anomaly type from the original anomaly log information. There are no restrictions on this, and these attribute fields can come from log collection tools or network layer interception mechanisms.

[0039] In addition, standardization processing can also involve exception coding, where exception types can be converted into numeric codes according to preset coding rules. For example, text exceptions can be mapped to specific codes, reducing storage and transmission overhead.

[0040] Furthermore, standardization processing can also include data validation, which can check the integrity and validity of attribute fields to prevent invalid data from flowing into downstream processes; standardization of abnormal data can be obtained by parsing, encoding and enriching the context of attribute fields, and can be used to characterize the abnormal information obtained through processing.

[0041] This application standardizes attribute fields by unifying data formats and extracting key information to obtain standardized anomaly data. The extracted key information is then anomaly encoded using preset encoding rules and digital code conversion to generate anomaly type data with a unified identifier. The encoded anomaly data undergoes integrity verification, forming standardized anomaly data containing complete anomaly characteristics through logical checks. By standardizing attribute fields, the format and structure of anomaly data are unified, improving data consistency and processability, thereby supporting subsequent intelligent analysis and accurate alerts, reducing data processing complexity, and improving operational efficiency.

[0042] For example, in the operation and maintenance monitoring of software systems, abnormal information can be captured from multiple data sources such as application logs and network layer interception. Attribute fields can include error time, error code, error message, and device identifier. Attribute fields can be standardized, and raw abnormal information can be parsed to extract key fields such as timestamps and abnormal types. Abnormal types can be converted into numeric codes according to encoding rules to reduce storage overhead. Contextual data such as application version and operating system information can be added to enhance analyzability. Furthermore, the data can be converted into standardized abnormal data in standard JSON format.

[0043] S203, based on the preset alarm template, performs frequency control and deduplication processing on the standardized abnormal data to obtain the target alarm text.

[0044] Specifically, the preset alarm template can be a predefined format specification for generating alarm messages. This preset alarm template may include alarm titles, content structures, and variable placeholders, etc., which are not limited here. This ensures the consistency and readability of alarm information. The preset alarm template can be defined through the template configuration module in the configuration management and monitoring subsystem and can be stored in the template database. Frequency control deduplication processing can be a data filtering process based on frequency control and duplicate detection. Specifically, this frequency control deduplication processing can include setting time windows and duplicate thresholds to identify and suppress duplicate anomalies, thereby preventing alarm storms and reducing redundant notifications. This frequency control deduplication processing can be implemented through distributed caching to achieve frequency control counting, and deduplication can be determined by querying the number of occurrences of anomaly identifiers in the cache. The target alarm text can be the actual generated alarm message. This target alarm text may include formatted text content, containing an anomaly summary and handling suggestions, which can be sent to the relevant responsible persons through notification channels to promote action.

[0045] Furthermore, frequency control deduplication can also involve retrieving the count of anomaly identifiers from the cache. If the count does not exceed the threshold within a preset time window, the count can be updated and an alarm text can be generated; otherwise, the abnormal data can be discarded. In addition, the preset alarm templates can also support dynamic loading, allowing different alarm templates to be selected based on the business type. For example, a detailed stack template can be used for database anomalies, while a concise summary template can be used for business indicator anomalies.

[0046] In addition, during frequency control deduplication, anomaly identifiers can be extracted from standardized abnormal data. These identifiers can be generated based on the anomaly type and can be used to uniquely identify similar anomalies. Frequency control records in the cache can be queried. If a record exists and has not expired, the current count can be compared with a threshold. The threshold can be dynamically adjusted according to the severity of the anomaly. For example, high-severity anomalies can be prioritized by setting a lower threshold. If the threshold is not exceeded, the count can be incremented and an alarm text can be generated. Otherwise, it can be marked as a duplicate and ignored.

[0047] Furthermore, frequency control deduplication can also include a sliding window mechanism, which can maintain the history of anomalies through a cached timestamp queue to ensure that only a limited number of identical anomalies are reported within the window. In addition, contextual information in the standardized anomaly data, such as device identifiers and user sessions, can be used to enhance deduplication accuracy and prevent similar anomalies from different sources from being misjudged as duplicates.

[0048] For example, in an e-commerce order processing system, standardized abnormal data, such as "database connection timeout" exceptions, can be captured from order service logs. This standardized data can include contextual information such as timestamps, exception code 1003, high severity, and order identifiers. Frequency control and deduplication can be used to set a 1-minute time window and a threshold of 3 occurrences. When the same exception occurs for the fourth time within 1 minute, the data can be discarded, and an alarm cannot be generated. A preset alarm template can be a "business exception alarm" template, which can include placeholders for inserting exception descriptions and suggested handling. By filling in fields from the standardized abnormal data, target alarm text such as "Order service exception: database connection timeout, affecting orders -12345, it is recommended to check database load" can be generated.

[0049] This application embodiment performs frequency control and deduplication processing on standardized abnormal data based on a preset alarm template. Valid abnormal data is filtered through time window control and repetition threshold judgment. The filtered abnormal data is then template-filled, generating target alarm text through variable substitution and content formatting. Frequency control and deduplication suppress duplicate anomaly reporting, reducing alarm noise and resource waste. The preset alarm template ensures information readability and consistency, improving alarm processing efficiency and reliability. The cache-based frequency control mechanism and template-based alarm generation reduce false alarm rates and accelerate fault response speed.

[0050] S204, queue the target alarm text and display the target alarm text on the terminal device.

[0051] Specifically, queue transmission can be a process of buffering and asynchronously transmitting alarm data through distributed message middleware. It is a data transmission mechanism based on the first-in, first-out principle, which can alleviate instantaneous load peaks and ensure the reliability and order of alarm information transmission. Queue transmission can rely on standardized abnormal messages provided by the abnormal collection and standardization subsystem, and data can be sent into the message queue through message producers.

[0052] Furthermore, queue transmission can use Rocket Message Queue (RocketMQ) as a message middleware to encapsulate the target alarm text into a message object, which is then sent to the specified topic queue through the producer component. The consumer component can pull messages from the queue and parse them, ensuring that data is not lost during transmission due to network fluctuations or system failures.

[0053] For example, in system monitoring, when the business data monitoring mechanism detects an abnormal transaction failure rate, it generates a target alarm text. The target alarm text can be asynchronously sent to the message queue through queue transmission to avoid blocking the main business process. For example, in e-commerce platform operation and maintenance, abnormal alarm texts can be transmitted to downstream processing via queue to achieve efficient data flow.

[0054] In addition, the terminal device can be a user-end hardware device used to receive alarm information. It can be a physical device including a computer, mobile device or dedicated monitoring terminal, without limitation. This can provide a visual interface for alarm information, making it easy for operation and maintenance personnel to view and respond in real time. The terminal device can receive target alarm text from the queue transmission through the alarm management and distribution subsystem, and can push it after format conversion through the notification channel plugin.

[0055] Furthermore, the display process can also involve multi-channel notifications, which can convert the target alarm text into a format suitable for display on terminal devices. For example, rich text messages can be generated through instant messaging tool plugins, or rendered as HyperText Markup Language (HTML) content through email clients, to ensure that the target alarm text can be clearly presented on different devices.

[0056] For example, in operation and maintenance monitoring applications, target alarm texts can be transmitted via a queue and then sent to the mobile terminals of operation and maintenance personnel by the notification system through an instant messaging plugin. The device screen can then pop up alarm details, including anomaly descriptions and handling suggestions, to achieve real-time visual management.

[0057] This application embodiment processes the target alarm text through queue transmission. By encapsulating the message middleware and using an asynchronous transmission mechanism, it achieves buffered forwarding of alarm data. Terminal adaptation processing is performed on the alarm data in the queue, and through format conversion and multi-channel distribution, the target alarm text can be displayed on terminal devices. The queue transmission mechanism enables asynchronous and buffered processing of alarm data, avoiding system blocking and data loss, improving the reliability of target alarm text transmission. The terminal device display function ensures that the alarm content can be presented to relevant personnel in real time and clearly, improving operational efficiency and accelerating fault response speed.

[0058] According to the technical solution provided in this disclosure, the attribute fields corresponding to the abnormal log data to be processed are obtained by parsing the abnormal log data to be processed; the attribute fields are standardized to obtain standardized abnormal data; the standardized abnormal data is frequency-controlled and deduplicated based on a preset alarm template to obtain the target alarm text; the target alarm text is queued and transmitted to the terminal device, thereby improving the accuracy and real-time performance of alarm information, enhancing the processing capability of abnormal logs, improving the reliability of alarm notifications, realizing intelligent filtering and accurate alarm of abnormal information, reducing alarm noise and false alarm rate, improving operation and maintenance efficiency and fault repair speed, and ensuring the timeliness and traceability of alarm information through standardized format and reliable transmission mechanism, thereby enhancing the business relevance and system synergy of alarm information.

[0059] In some embodiments, after performing frequency control deduplication on standardized abnormal data based on a preset alarm template to obtain the target alarm text, the method further includes: performing anomaly level evaluation on the target alarm text to obtain a target anomaly level; matching the target anomaly level with a preset set of notification objects to obtain a target notification object; and performing method selection on the target notification object based on a preset notification method to obtain a target push method, wherein the target push method is used to characterize the queue transmission method of the target alarm text.

[0060] Specifically, the anomaly level assessment process can be a data processing procedure that calculates the severity of anomalies by analyzing the content of alarm text. This can quantify the priority of anomaly events to guide resource allocation. The anomaly level assessment process can perform multi-dimensional analysis on the target alarm text. The target anomaly level can be a classification or numerical value used to characterize the severity of anomalies, thereby identifying the urgency of alarms to support decision-making. The target anomaly level can be generated by the anomaly level assessment process, based on the output of an anomaly scoring mechanism.

[0061] Furthermore, the anomaly level assessment process can parse key fields in the target alarm text, such as anomaly type and / or frequency of occurrence, and score them through multiple dimensions. Reference factors may include the scope of impact and business importance. The score is calculated and mapped to a predefined level classification, such as anomaly level, which may include low, medium, high or emergency levels, etc., without limitation here.

[0062] For example, in the operation and maintenance monitoring of an online e-commerce system, the target alarm text could be "surge in database connection timeout frequency". The contextual data of the target alarm text, such as the number of errors and the proportion of affected users, can be analyzed through anomaly level assessment to calculate that the target anomaly level is high.

[0063] In addition, the preset notification object set can be a database or list storing information about potential recipients, including but not limited to roles, responsibilities, and / or contact information. This allows for the determination of the scope of entities that can be notified to support precise routing. The preset notification object set can be pre-set by the configuration management subsystem based on the business organizational structure and permission rules. The matching process can be a data processing procedure that compares the target anomaly level with the preset notification object attributes to determine the appropriate recipient. This allows for the association of alarms with responsible persons. The matching process can perform logical judgments on the target anomaly level and the preset notification object set through a rule engine. The target notification object can be a specific recipient or group selected by the matching process, thereby specifying the target of alarm information delivery. The target notification object can be generated by the matching process based on predefined allocation rules.

[0064] Furthermore, the matching process can query rules in a pre-defined set of notification objects, such as association conditions based on the type or severity of the anomaly, for example, matching high-level anomalies with the technical supervisor role, and can avoid notification overload through load balancing logic.

[0065] For example, in the operation and maintenance monitoring of online e-commerce systems, high-level target anomalies can be matched with rules in a preset set of notification objects. For instance, if the rule defines database-related anomaly notifications for team A, the matching process can retrieve information about members A in the set to obtain the target notification object, which can be a specified engineer account, ensuring accurate alarm routing.

[0066] Furthermore, the notification method can be any available information delivery channel, including but not limited to email, SMS, or instant messaging. This allows for the determination of the media options for sending target alarm texts to support multi-channel notifications. Predefined notification methods can be predefined through the configuration management subsystem based on system integration and user preferences. The method selection process can be a data processing procedure that selects the target notification channel based on the target notification object and anomaly characteristics, thereby optimizing information delivery efficiency and reliability. The method selection process can be a process of processing the target notification object and the preset notification method through a strategy engine. Among these, the target push method can be a specific transmission mechanism, including but not limited to message queues or API calls, thereby ensuring reliable delivery of alarm information. The target push method can be generated by the method selection process based on channel availability and the suitability of the target anomaly level. The queue transmission method can be a processing method that manages the alarm sending order and reliability through message queues, thereby buffering and scheduling notification tasks to avoid loss. The queue transmission method can respond to the instructions of the target push method and is implemented through message middleware such as RocketMQ.

[0067] Furthermore, the method selection process can be optimized by assessing the contact preferences and anomaly levels of the target notification recipients. For example, in case of emergency anomalies, SMS or telephone channels can be prioritized, and a plug-in system can be integrated to dynamically load notification channels.

[0068] For example, in the operation and maintenance monitoring of an online e-commerce system, the target notification recipient can be Engineer A, and the preset notification method can be email or SMS. The method selection process can select SMS as the target push method based on the high anomaly level, and can be implemented through message queues to ensure timely delivery of alarms.

[0069] According to the technical solution provided in this disclosure, a target anomaly level is obtained by performing multi-dimensional analysis and scoring on the target alarm text; the target anomaly level is matched with a preset set of notification objects, and the target notification objects are obtained through rule engine query and condition judgment; the target notification objects are selected based on a preset notification method, and the target push method is obtained through channel adaptation and strategy decision-making. In this way, by evaluating the anomaly level of the target alarm text, the quantitative and intelligent level of anomaly priority is realized, improving the efficiency of alarm processing; by matching the target anomaly level with the preset set of notification objects, the accuracy of alarm routing to relevant responsible persons is improved, and information overload is reduced; by selecting the target push method based on the preset notification method, the reliability of multi-channel notifications is optimized, and the response speed and reliability of log data alarm prompts are improved.

[0070] In some embodiments, frequency control deduplication processing is performed on standardized abnormal data based on a preset alarm template to obtain target alarm text, including: extracting abnormal types from the standardized abnormal data to obtain abnormal feature data; performing frequency control deduplication processing on the abnormal feature data based on a preset time window to obtain target screening results; and filling the target screening results based on a preset alarm template to obtain target alarm text.

[0071] Specifically, anomaly type extraction processing can be a data processing process that identifies and classifies anomaly types from standardized anomaly data through rule engines or pattern recognition, thereby distinguishing different types of anomalies for processing; among them, anomaly feature data can be a set of data that represents anomaly categories by extracting anomaly type-related feature information, thereby providing an identification basis for frequency control deduplication, and this anomaly feature data can be generated by anomaly type extraction processing.

[0072] Furthermore, the exception type extraction and processing can be based on predefined exception classification rules. For example, error logs can be classified into categories such as database exceptions, network exceptions, and / or application logic exceptions. There are no restrictions here. Exception feature data containing exception type codes and descriptions can be generated.

[0073] In addition, frequency control deduplication can be a data processing procedure that counts and filters data with the same abnormal characteristics within a specified time window, thereby reducing duplicate alarms and preventing alarm storms. The target screening result can be the set of abnormal identifiers remaining after frequency control deduplication. The basic definition is a list of unique or low-frequency abnormalities that are selected, which serves as the input for alarm generation.

[0074] Furthermore, frequency control deduplication can store abnormal feature data and counts through a distributed cache (Redis). Duplicate identifiers can be suppressed within a time window, retaining only the abnormal feature data that appears for the first time or meets the threshold condition.

[0075] In addition, the filling process can be a data processing procedure that inserts abnormal information from the target screening results into the corresponding positions of the preset alarm template, thereby generating specific alarm messages. Furthermore, the filling process can be implemented based on the field mapping in the preset alarm template. For example, information such as the abnormality type, occurrence time, and device identifier can be filled into the preset alarm template to generate easy-to-understand target alarm text.

[0076] For example, in the log monitoring of an e-commerce platform, standardized abnormal data can be "database connection timeout" exceptions. These standardized abnormal data can be classified as database exceptions through exception type extraction and processing, generating abnormal feature data. Further abnormal feature data can be generated based on this data. Within a preset 1-minute time window, duplicate abnormal feature data can be deduplicated based on frequency control; if the exception occurs multiple times within the window, only one instance is retained, resulting in the target screening result. Then, using a preset alarm template, such as "Exception type: {type}, Occurrence time: {time}, Recommendation to check database connection," the abnormal information from the target screening result can be filled into the preset alarm template to generate the target alarm text "Exception type: Database connection timeout, Occurrence time: 2023-10-01 10:00:00, Recommendation to check database connection."

[0077] According to the technical solution provided in this disclosure, abnormal feature data is obtained through rule engine parsing and pattern recognition; frequency control and deduplication processing is performed on the abnormal feature data based on a preset time window, and target screening results are obtained through counting statistics and repetition suppression; the target screening results are filled based on a preset alarm template, and target alarm text is obtained through field mapping and content formatting. In this way, by extracting abnormal types and performing frequency control and deduplication processing on standardized abnormal data, combined with filling the preset alarm template, intelligent filtering and standardized generation of alarm information are realized, reducing duplicate alarms, improving the accuracy and readability of alarms, reducing interference for operation and maintenance personnel, and improving fault response efficiency.

[0078] In some embodiments, the attribute field is standardized to obtain standardized abnormal data, including: performing context completion on the attribute field to obtain a target extended field; and performing formatted encapsulation on the target extended field to obtain standardized abnormal data.

[0079] Specifically, context completion processing can be a data processing procedure that adds extra contextual information to attribute fields. It can expand the content of attribute fields by associating with external data sources, thereby enriching the background information of abnormal data and improving the accuracy of analysis. Context completion processing can supplement attribute fields through data sources such as device registry or application configuration library.

[0080] In addition, the target extended field can be a set of extended fields containing the original attributes and context data formed through context completion processing. It can be an enhanced abnormal data unit, thereby providing complete input for formatted encapsulation. The target extended field can be obtained by enhancing the attribute field through context completion processing.

[0081] Furthermore, formatting and encapsulation can be a data processing procedure that converts target extended fields into a uniform data format and encapsulates them. Data standardization can be achieved through structural transformation, thereby ensuring that abnormal data has a consistent structure to support storage and transmission.

[0082] For example, in an e-commerce platform, when a network timeout exception occurs during order processing, the original exception information can be captured from application tracking points, and attribute fields including the occurrence timestamp, server number, exception type code, and error description text can be extracted. Context completion processing can add business module identifiers, user region information, and service version numbers to the attribute fields by querying the platform configuration database to form target extended fields. Formatting and encapsulation processing can convert the target extended fields into JSON format data containing fixed key-value pairs and add metadata headers to generate standardized exception data.

[0083] According to the technical solution provided in this disclosure, a target extended field is obtained by associating with an external data source and an information extension mechanism. The target extended field is then formatted and encapsulated. Standardized abnormal data is obtained through structure transformation and unified format encapsulation. Thus, by performing context completion and format encapsulation on the attribute fields, the abnormal data is transformed from its original heterogeneous format to a unified standard structure. Context completion enriches the background dimension of the abnormal information. Combined with format encapsulation, the standardization and uniformity of the data structure are ensured, the readability and compatibility of the abnormal data are improved, and the parsing complexity of subsequent analysis modules is reduced.

[0084] In some embodiments, parsing the abnormal log data to be processed to obtain the attribute fields corresponding to the abnormal log data to be processed includes: performing format recognition processing on the abnormal log data to be processed to obtain the log format type; performing field extraction processing on the log format type to obtain the field extraction result; and performing structured encapsulation processing on the field extraction result to obtain the attribute fields.

[0085] Specifically, format recognition processing of the abnormal log data to be processed can be a data processing procedure that analyzes the raw log data to determine its structural type. It can be used to identify the organizational form of the abnormal log data to be processed, providing a basis for subsequent field extraction. The log format type can be a classification result that identifies the structural type of the abnormal log data to be processed, such as JSON format, Extensible Markup Language (XML) format, or plain text format, etc., without limitation here. The log format type can be used to guide the selection of field extraction processing methods. The log format type can be the classification information identified from the abnormal log data to be processed through format recognition processing.

[0086] In addition, field extraction processing for log format types can be a data processing procedure that applies corresponding rules to extract specific fields from the abnormal log data to be processed based on the identified format type. This field extraction processing can be used to convert unstructured abnormal log data to be processed into a structured set of fields. Field extraction processing can be implemented based on the log format type and apply predefined extraction rules, such as obtaining key information through regular expressions or parsers. The field extraction result can be a structured data set obtained through field extraction processing, which can contain each field extracted from the abnormal log data to be processed and its corresponding value, including but not limited to timestamps, error codes and / or message content, etc. This field extraction result can be used as input data for structured encapsulation processing.

[0087] For example, in distributed system monitoring, the format of the abnormal log data to be processed can be identified. If the log format type of the abnormal log data to be processed is identified as JSON, field extraction processing can be performed based on the log format type. Fields such as timestamp, exception level and exception description can be extracted by using a JSON parser to obtain the field extraction results. Then, the field extraction results can be structured and encapsulated to convert them into a unified JSON object format to generate attribute fields.

[0088] Furthermore, format recognition processing can be achieved through pattern matching algorithms. For example, the format type can be determined by comparing the beginning of the abnormal log data to be processed with a predefined template.

[0089] Furthermore, the field extraction processing can support multiple extraction methods. For example, plain text log data can be matched using regular expressions, while structured log data can be extracted using a built-in parser.

[0090] Furthermore, structured encapsulation can add additional metadata, such as data source identifiers or processing timestamps, to enrich the content of attribute fields.

[0091] According to the technical solution provided in this disclosure, the log format type is obtained through pattern matching and structural analysis; field extraction processing is performed based on the log format type, and the field extraction results are obtained through parser application and key information extraction; the field extraction results are structurally encapsulated, and attribute fields are obtained through data reorganization and metadata addition. Thus, by performing format recognition processing on the abnormal log data to be processed, different log formats can be adapted, reducing the need for manual configuration and improving data processing efficiency; by performing field extraction processing on the log format type, key information can be efficiently extracted from unstructured data, enhancing data usability; by performing structural encapsulation processing on the field extraction results, unified attribute fields are generated, ensuring data consistency in subsequent processing steps and improving the accuracy and reliability of alarms.

[0092] In some embodiments, before parsing the abnormal log data to be processed to obtain the attribute fields corresponding to the abnormal log data to be processed, the method further includes: obtaining log data; performing association matching processing on the log data based on a preset list of abnormal keywords to obtain an initial abnormal log; and performing source marking processing on the initial abnormal log to obtain the abnormal log data to be processed.

[0093] Specifically, log data can be raw recorded information collected from various data sources, including but not limited to system operation logs, application output logs, or network device logs. This log data can be text data used to record the operating status of the software system, user operations, and / or error events; it can serve as the raw input for anomaly detection, and potential problems can be identified by analyzing this log data.

[0094] In addition, the preset list of abnormal keywords can be a predefined set of strings or patterns. This preset list of abnormal keywords can include error identifiers such as "ERROR", "FAIL", or specific business exception codes. This preset list of abnormal keywords can also be a set of rules used to filter abnormal logs. The preset list of abnormal keywords can be loaded from the rule base through configuration management, and can also be used for correlation matching processing. Correlation matching processing can compare the log data content with the preset list of abnormal keywords to identify log entries containing matching items. Correlation matching processing can be a data filtering process based on string or pattern matching, thereby reducing the amount of data and focusing on abnormal events. The initial abnormal logs can be a subset of logs filtered through keyword matching, and can be intermediate data containing potential abnormal information. The initial abnormal logs can be used as the basis for subsequent fine-grained processing.

[0095] Furthermore, matching processes can be performed in parallel using multithreading, which can improve processing efficiency and optimize the access speed of the keyword list through caching mechanisms.

[0096] In addition, source tagging can be a data augmentation process that adds identification information to log entries to indicate their source attributes, such as device code, application module, or geographic location, thereby providing contextual information to facilitate subsequent routing and allocation.

[0097] For example, log data can be obtained in real time from multiple microservice nodes through a collector, including user transaction logs and system performance logs; the preset list of abnormal keywords can include "timeout", "connection refused" and / or "out of memory", etc. The correlation matching process can scan the log content through a regular expression engine to identify entries containing the above keywords as initial abnormal logs; the source tagging process can add the server Internet Protocol Address (IP), service name and timestamp information to each initial abnormal log to generate abnormal log data to be processed.

[0098] According to the technical solution provided in this disclosure, log data is acquired and associated with a preset list of abnormal keywords. Initial abnormal logs are obtained through pattern comparison and content filtering. Source marking is applied to the initial abnormal logs, and context information is added and identifiers are injected to generate abnormal log data to be processed. Thus, by acquiring log data and performing association matching based on preset keywords, preliminary filtering of abnormal information is achieved, reducing interference from irrelevant data. Source marking enhances the context information of the abnormal log data to be processed, improving the accuracy of subsequent allocation. This improves the efficiency and accuracy of abnormal detection and reduces the cost of manual screening.

[0099] In some embodiments, after the target alarm text is queued and transmitted to the terminal device, the method further includes: performing interface rendering processing on the terminal device in response to the terminal device display instruction to obtain a visual alarm interface; and displaying the target alarm text on the visual alarm interface in response to the alarm interface trigger instruction.

[0100] Specifically, the terminal device display command can be a control signal issued by the user or the system, which can be used to initiate the interface display process of the terminal device, thereby triggering the visualization of alarm information and ensuring that the alarm content can be displayed to relevant personnel in a timely manner. The terminal device can be a computing device used to receive and display alarm information, including but not limited to personal computers, mobile terminals, and / or monitoring workstations, etc., without limitation here. The terminal device can provide a user interaction interface to facilitate maintenance personnel to view and handle alarms. The terminal device can receive alarm data transmitted from the system backend queue through a network connection. The interface rendering process can be a data processing process that transforms abstract data structures into a graphical user interface, thereby presenting the target alarm text in an intuitive visual form and improving the user's understanding efficiency. The interface rendering process can be a process of parsing and laying out the target alarm text based on a front-end framework or graphics library. Among them, the visualized alarm interface can be a user interface that dynamically displays alarm content through graphical elements, thereby centrally displaying alarm details, status, and related information, making it easy for users to quickly identify anomalies. The visualized alarm interface can be generated by the interface rendering process based on the configuration template and real-time data.

[0101] Furthermore, the interface rendering process can include parsing alarm data formats, applying style templates, and dynamically loading interface components to ensure interface consistency and responsiveness; the visual alarm interface can support interactive controls, such as filter buttons and sorting options, and can allow users to customize the view.

[0102] For example, in an operation and maintenance monitoring system application, when a user's command to open the monitoring application is detected, the interface rendering process is triggered. The target alarm text can be parsed through the front-end framework and a predefined style can be applied to generate a visual alarm interface containing an alarm list and status chart.

[0103] In addition, the alarm interface trigger command can be a specific command issued by the user or system event. It can be used to activate the detailed display of alarm content on the visual alarm interface, thereby controlling the timing and method of displaying the target alarm text and avoiding information overload.

[0104] For example, in operation and maintenance monitoring system applications, the alarm interface trigger command can be triggered by clicking the alarm card in the visual alarm interface. The alarm interface trigger command can be parsed and the interface components can be called to display the target alarm text in a structured form in the pop-up window or sidebar. The text content can include the abnormal time, source, and recommended operation, etc. The visual alarm interface can also adjust the color and icon according to the severity of the alarm.

[0105] According to the technical solution provided in this disclosure, the terminal device is rendered in response to a display command, and a visual alarm interface is obtained through data parsing and style template application. The visual alarm interface is activated in response to an alarm interface trigger command, and the target alarm text is displayed on the visual alarm interface through component calls and structured display. Thus, by responding to both the terminal device display command and the alarm interface trigger command, the dynamic generation of the visual alarm interface and the accurate display of the target alarm text are achieved. The interface rendering process transforms abstract alarm data into an intuitive graphical interface, improving the readability of alarm information and user interaction efficiency, enhancing the visual expression of alarm information, reducing the cognitive burden on maintenance personnel, and improving the speed of anomaly identification and processing. Integrated interface management further enhances usability and responsiveness.

[0106] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0107] Figure 3 This is a schematic diagram of another log data alarm notification method provided in an embodiment of this disclosure. For example... Figure 3 As shown, the log data alarm notification method includes: The various subsystems disclosed herein can be decoupled through the Remote Procedure Call (RPC) distributed service framework (Dubbo), achieve efficient data exchange through the distributed message middleware RocketMQ, and implement frequency control through the distributed cache (Redis).

[0108] The anomaly collection module can capture anomaly information (anomaly log data to be processed) in real time from various data sources (system logs, applications, etc.); the standardization processing module can perform unified format conversion on heterogeneous anomaly data (standardization processing); the intelligent analysis engine can perform pattern recognition and severity assessment on the standardized anomaly data (standardized anomaly data); the routing and allocation module can automatically allocate anomalies to the corresponding responsible persons according to predefined rules; and finally, the alarm information can be sent to the relevant responsible persons through a multi-channel notification system.

[0109] 1. Technical solution for automatic anomaly detection and reporting Anomaly capture mechanism: This disclosure implements a multi-source anomaly capture mechanism, which can capture anomaly information from different types of data sources. For example... Figure 4 The exception handling process shown can be implemented using the following technical means: Log file monitoring: Anomaly information can be collected from system log files in real-time or periodically using log collection tools. These tools support parsing various log formats (such as JSON, XML, and plain text) and can identify abnormal log entries through regular expression pattern matching.

[0110] Application event tracking: Monitoring code can be embedded at key functional points of the application. When the application executes these key functional points, the monitoring code can detect abnormal situations. When an abnormality is detected, the monitoring code can call the reporting code to send the abnormal information to the abnormality collection server.

[0111] Network layer interception: This feature captures network layer exceptions within the network framework's exception handling method (exceptionCaught) and can call alerting tools to report exception information. This allows for the detection of low-level network problems such as network connection errors and packet parsing failures.

[0112] 2. Standardized processing of abnormal information The captured raw anomaly information is standardized and converted into a uniform format anomaly message for easier subsequent processing and analysis. The standardization process includes the following steps: Anomaly analysis: Parse the raw anomaly information and extract key fields, including anomaly occurrence time, device identifier (devId), anomaly type (errorType), anomaly description, severity level, etc.

[0113] Exception coding: Exception types are encoded according to preset coding rules, converting text-based exception types into numeric codes to reduce storage and transmission overhead. For example, an "overflow memory" exception can be encoded as "1001", and a "database connection timeout" exception can be encoded as "2003".

[0114] Enrich the context: Add contextual data to the anomaly information, including device information, application version, operating system version, user identifier, etc., to help with subsequent analysis and problem localization.

[0115] Standardized format: Convert exception information into a standardized JSON format, which includes fixed fields and structure.

[0116] Standardized exception messages can be reported to the exception handling center through a reliable transmission mechanism. The reliability and efficiency of exception reporting can be ensured through the following technologies: Asynchronous reporting: Exception reporting can be done asynchronously to avoid blocking the normal execution of the application. When the network connection is unavailable, the exception information can be cached locally and reported again after the network is restored.

[0117] Message queue buffering: RocketMQ message queues can be used as a transmission channel to ensure the real-time and reliable transmission of exception information. RocketMQ's high throughput and persistence features can handle peak exception traffic and prevent data loss.

[0118] Frequency control mechanism: Redis can be used to control the frequency of repeated exceptions and prevent repeated alarm storms. A time window (e.g., 1 minute) can be set for each exception type, and the same exception occurring within the same time window will only be reported once.

[0119] 3. Service Alarm Configuration Technical Solution Dynamic alarm rule configuration: It can provide flexible dynamic business alarm rule configuration capabilities, allowing users to customize alarm rules according to business needs.

[0120] Users can complete the following configurations through a visual interface: Basic rule configuration: This includes basic configuration items such as rule name, rule description, monitoring metrics, statistical frequency, and statistical sliding window.

[0121] Trigger condition configuration: Supports configuring complex condition expressions, including threshold conditions (greater than, less than, equal to), duration conditions (exceeding the threshold multiple times consecutively), etc.

[0122] Alarm Action Configuration: Configure the action to be executed after an alarm is triggered, including but not limited to sending emails, SMS messages, WeChat messages, etc., and supports multiple notification templates.

[0123] Scope of application configuration: Configure the effective time range and scope of the rules, supporting multiple dimensions such as device grouping, geographical distribution, and business module.

[0124] Rule Engine and Real-time Assessment: The system can be equipped with a high-performance rule engine to assess in real time whether business data meets alarm conditions.

[0125] The workflow of the rules engine is as follows: Rule loading: The rule engine periodically loads alarm rules from the rule configuration library, supporting dynamic updates without requiring a system restart.

[0126] Data collection: Collect business data in real time from data sources, including performance metrics, business metrics, log data, etc.

[0127] Rule matching: Match business data with alarm rules to determine whether the triggering conditions are met.

[0128] Action Trigger: When the conditions are met, a predefined alarm action is triggered, an alarm notification is generated and sent to relevant personnel.

[0129] The rule engine also supports a variety of complex conditional expressions, including: Simple threshold condition: Central Processing Unit (CPU) utilization is greater than 90%.

[0130] The conditions are: (CPU utilization greater than 90% and memory utilization greater than 85%) or response time greater than 3000 milliseconds.

[0131] Duration condition: CPU utilization is greater than 90% for 5 consecutive minutes.

[0132] Trend condition: CPU usage has been rising continuously over the past 10 minutes with a slope greater than 5% / minute.

[0133] 4. Business Data Monitoring Technical Solution Multi-dimensional data monitoring mechanism: A multi-dimensional business data monitoring mechanism can be used to comprehensively monitor various business indicators. The monitoring data collection process includes the following steps: Data Acquisition: Collect raw data from business systems through agent programs or monitoring clients, including performance metrics (CPU, memory, disk utilization), business metrics (transaction volume, response time, error rate), and custom metrics.

[0134] Data preprocessing: Cleaning, transforming, and aggregating the collected raw data to generate standardized data points.

[0135] Data storage: The processed data is stored in a time-series database (such as Elasticsearch), supporting efficient storage and querying of time-series data.

[0136] Data analysis: Analyzing stored data, including anomaly detection, trend prediction, and pattern recognition.

[0137] Anomaly detection and scoring mechanism: The severity of anomalies can be calculated using a multi-dimensional anomaly scoring algorithm. The scoring algorithm considers the following factors: Anomaly frequency: The number of times the same anomaly occurs within a unit of time; the higher the frequency, the higher the score.

[0138] Scope of impact: The number of users, devices, or business volume affected by the anomaly; the larger the scope, the higher the score.

[0139] Business Importance: The importance of the business functions affected by the anomaly; core business anomalies receive higher scores.

[0140] Time factor: The time period in which the anomaly occurred (such as peak or off-peak business hours). Anomalies during peak hours receive higher scores.

[0141] The formula for calculating the anomaly score is as follows: Anomaly score = Occurrence frequency weight × Frequency score + Impact scope weight × Scope score + Business importance weight × Importance score + Time factor weight × Time score.

[0142] The severity level of an anomaly can be determined based on the anomaly score, categorized into four levels: low, medium, high, and urgent. Different levels correspond to different handling strategies and notification methods.

[0143] 5. Role-based alarm configuration technical solution Automatic assignee matching mechanism: A rule-based automatic assignee matching mechanism can automatically assign exceptions to the most suitable personnel based on the exception characteristics.

[0144] Automatic allocation can be achieved through the following steps: Anomaly analysis: Analyze anomaly information and extract anomaly features, including anomaly type, anomaly severity, anomaly source module, affected devices, etc.

[0145] Rule matching: Match abnormal features with predefined assignment rules to find all rules that meet the conditions.

[0146] Person in charge selection: Based on the person in charge information defined in the rules, determine the person who needs to be notified.

[0147] Notification Sending: Send an exception notification to the responsible person through the configured notification channel.

[0148] The system supports multiple responsible person matching rules, including: Matching based on exception type: Specific types of exceptions (such as database exceptions) are automatically assigned to the corresponding expert teams, such as the Database Administrator (DBA) team.

[0149] Severity-based matching: High-severity anomalies are simultaneously reported to the technical lead to ensure that important anomalies receive sufficient attention.

[0150] Time-based matching: The notification recipients are determined based on the time the exception occurs. During working hours, regular employees are notified, and during non-working hours, on-duty engineers are notified.

[0151] Load balancing-based matching: Considering the current workload of engineers, new exceptions are assigned to engineers with lighter workloads to achieve a balanced distribution of workload.

[0152] Multi-channel intelligent notification system: This system supports a multi-channel intelligent notification mechanism, enabling alarm information to be sent to relevant personnel through different channels. Supported notification channels include: Instant messaging tools: Send instant message notifications.

[0153] SMS notification: Send SMS alerts via SMS gateway to ensure that important alarms reach offline users.

[0154] Email notification: Send detailed alert emails via mail server, including anomaly details and analysis suggestions.

[0155] Telephone notification: For emergency alarms, it supports automatically dialing a phone number to play a voice alarm.

[0156] A plug-in design allows each notification channel to function as an independent plugin, implementing a unified channel interface. This enables the expansion to include new notification channels without requiring modifications to the core code.

[0157] The system supports multi-level notification policies, adopting different notification strategies based on the severity of the anomaly: Low-severity anomalies: Send email notifications only to avoid disturbing technical staff.

[0158] Moderate severity anomalies: Send email and instant message notifications to ensure that technical staff can detect them in a timely manner.

[0159] High-severity anomalies: Send email, instant message, and SMS notifications to ensure that technical staff can respond promptly.

[0160] In cases of exceptional urgency or severity: notify personnel through all available channels, including telephone, to ensure immediate action by technical staff.

[0161] According to the technical solution provided in this disclosure, intelligent analysis of log content avoids the uploading of invalid or redundant information, ensuring the accuracy of reported content; it provides a highly flexible and dynamically adjustable business alarm rule configuration interface; it can not only define simple threshold alarms, but also set refined rules for complex business events from multiple dimensions such as level, type, and scope of impact; rules can be dynamically triggered based on real-time monitoring data, reducing reliance on fixed thresholds and manual intervention; it establishes a hybrid data monitoring mechanism that combines the comprehensiveness of timed polling with the timeliness of real-time detection; it can calculate abnormal events. It calculates scores and assesses severity, providing a quantitative basis for subsequent prioritization and assignment; it can accurately deliver alarm notifications to responsible persons in different roles based on the severity and type of the anomaly and matching predefined responsible person association rules; it supports sending differentiated alarm content through multiple interface channels, ensuring that information can be delivered efficiently and that the content has high action guidance value for the recipient; it improves operation and maintenance efficiency, shortens fault repair time, reduces alarm noise and false alarm rate, realizes precise and intelligent scheduling of operation and maintenance resources, enhances adaptability, reduces maintenance costs, and improves the standardization and traceability of fault management.

[0162] The following are embodiments of the apparatus disclosed herein, which can be used to execute embodiments of the method disclosed herein. For details not disclosed in the apparatus embodiments of this disclosure, please refer to the embodiments of the method disclosed herein.

[0163] Figure 5 This is a schematic diagram of a log data alarm notification device provided in an embodiment of this disclosure. Figure 5 As shown, the log data alarm notification device includes: The first processing module 501 is used to parse and process the abnormal log data to be processed, and obtain the attribute fields corresponding to the abnormal log data to be processed. The second processing module 502 is used to standardize the attribute fields to obtain standardized outlier data; The third processing module 503 is used to perform frequency control deduplication on standardized abnormal data based on a preset alarm template to obtain the target alarm text. The fourth processing module 504 is used to queue and transmit the target alarm text so that the target alarm text is displayed on the terminal device.

[0164] According to the technical solution provided in this disclosure, the attribute fields corresponding to the abnormal log data to be processed are obtained by parsing the abnormal log data to be processed; the attribute fields are standardized to obtain standardized abnormal data; the standardized abnormal data is frequency-controlled and deduplicated based on a preset alarm template to obtain the target alarm text; the target alarm text is queued and transmitted to the terminal device, thereby improving the accuracy and real-time performance of alarm information, enhancing the processing capability of abnormal logs, improving the reliability of alarm notifications, realizing intelligent filtering and accurate alarm of abnormal information, reducing alarm noise and false alarm rate, improving operation and maintenance efficiency and fault repair speed, and ensuring the timeliness and traceability of alarm information through standardized format and reliable transmission mechanism, thereby enhancing the business relevance and system synergy of alarm information.

[0165] In some embodiments, the log data alarm notification device is further configured to: perform anomaly level evaluation processing on the target alarm text to obtain a target anomaly level; match the target anomaly level with a preset set of notification objects to obtain a target notification object; and perform method selection processing on the target notification object based on a preset notification method to obtain a target push method, wherein the target push method is used to characterize the queue transmission method of the target alarm text.

[0166] In some embodiments, the third processing module 503 is specifically used to: extract abnormal types from standardized abnormal data to obtain abnormal feature data; perform frequency control deduplication on the abnormal feature data based on a preset time window to obtain target screening results; and fill the target screening results based on a preset alarm template to obtain target alarm text.

[0167] In some embodiments, the second processing module 502 is specifically used to perform context completion processing on the attribute field to obtain the target extended field; and to perform formatting and encapsulation processing on the target extended field to obtain standardized abnormal data.

[0168] In some embodiments, the first processing module 501 is specifically used to perform format recognition processing on the abnormal log data to be processed to obtain the log format type; perform field extraction processing on the log format type to obtain the field extraction result; and perform structured encapsulation processing on the field extraction result to obtain the attribute field.

[0169] In some embodiments, the log data alarm notification device is further configured to: acquire log data; perform association matching processing on the log data based on a preset list of abnormal keywords to obtain an initial abnormal log; and perform source marking processing on the initial abnormal log to obtain abnormal log data to be processed.

[0170] In some embodiments, the log data alarm notification device is further configured to: perform interface rendering processing on the terminal device in response to a terminal device display instruction to obtain a visual alarm interface; and display the target alarm text on the visual alarm interface in response to an alarm interface trigger instruction.

[0171] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this disclosure.

[0172] Figure 6 This is a schematic diagram of the electronic device 6 provided in an embodiment of this disclosure. Figure 6 As shown, the electronic device 6 of this embodiment includes a processor 601, a memory 602, and a computer program 603 stored in the memory 602 and executable on the processor 601. When the processor 601 executes the computer program 603, it implements the steps in the various method embodiments described above. Alternatively, when the processor 601 executes the computer program 603, it implements the functions of each module / unit in the various device embodiments described above.

[0173] Electronic device 6 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 6 may include, but is not limited to, processor 601 and memory 602. Those skilled in the art will understand that... Figure 6 This is merely an example of electronic device 6 and does not constitute a limitation on electronic device 6. It may include more or fewer components than shown, or different components.

[0174] The processor 601 may be a central processing unit (CPU), or 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.

[0175] The memory 602 can be an internal storage unit of the electronic device 6, such as a hard disk or RAM of the electronic device 6. The memory 602 can also be an external storage device of the electronic device 6, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc., equipped on the electronic device 6. The memory 602 can also include both internal and external storage units of the electronic device 6. The memory 602 is used to store computer programs and other programs and data required by the electronic device.

[0176] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0177] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable storage medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0178] The above embodiments are only used to illustrate the technical solutions of this disclosure, and are not intended to limit it. Although this disclosure 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 spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be included within the protection scope of this disclosure.

Claims

1. A method for alerting log data, characterized in that, include: The abnormal log data to be processed is parsed to obtain the attribute fields corresponding to the abnormal log data to be processed. The attribute fields are standardized to obtain standardized outlier data; Based on the preset alarm template, the standardized abnormal data is subjected to frequency control and deduplication to obtain the target alarm text; The target alarm text is queued and transmitted, so that the target alarm text is displayed on the terminal device.

2. The log data alarm notification method according to claim 1, characterized in that, After performing frequency control deduplication on the standardized abnormal data based on the preset alarm template to obtain the target alarm text, the method further includes: The target alarm text is subjected to anomaly level assessment to obtain the target anomaly level; The target anomaly level is matched with a preset set of notification objects to obtain the target notification object; The target notification object is processed by selecting a method based on a preset notification method to obtain a target push method, wherein the target push method is used to characterize the queue transmission method of the target alarm text.

3. The log data alarm notification method according to claim 1, characterized in that, The standardized abnormal data is subjected to frequency control and deduplication based on a preset alarm template to obtain the target alarm text, including: The standardized abnormal data is subjected to anomaly type extraction processing to obtain abnormal feature data; Based on a preset time window, the abnormal feature data is subjected to frequency control deduplication to obtain the target screening result; The target screening results are populated based on the preset alarm template to obtain the target alarm text.

4. The log data alarm notification method according to claim 1, characterized in that, The standardization process for the attribute fields to obtain standardized outlier data includes: The attribute fields are then subjected to context completion processing to obtain the target extended fields; The target extended field is formatted and encapsulated to obtain the standardized abnormal data.

5. The log data alarm notification method according to claim 1, characterized in that, The process of parsing the exception log data to be processed yields the attribute fields corresponding to the exception log data, including: The format recognition process is performed on the abnormal log data to be processed to obtain the log format type; The log format type is subjected to field extraction processing to obtain the field extraction results; The extracted field results are then structured and encapsulated to obtain the attribute fields.

6. The log data alarm notification method according to claim 1, characterized in that, Before parsing and processing the exception log data to be processed to obtain the attribute fields corresponding to the exception log data, the process further includes: Retrieve log data; The log data is correlated and matched based on a preset list of abnormal keywords to obtain an initial abnormal log. The initial exception log is processed by source marking to obtain the exception log data to be processed.

7. The log data alarm notification method according to claim 1, characterized in that, After queuing and transmitting the target alarm text to the terminal device, the method further includes: In response to a terminal device display command, the terminal device performs interface rendering processing to obtain a visual alarm interface; In response to the alarm interface trigger command, the target alarm text is displayed on the visual alarm interface.

8. A log data alarm notification device, characterized in that, include: The first processing module is used to parse and process the abnormal log data to be processed, and obtain the attribute fields corresponding to the abnormal log data to be processed. The second processing module is used to standardize the attribute fields to obtain standardized abnormal data; The third processing module is used to perform frequency control deduplication on the standardized abnormal data based on a preset alarm template to obtain the target alarm text. The fourth processing module is used to queue and transmit the target alarm text so that the target alarm text is displayed on the terminal device.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images