Service index monitoring and warning method, device, equipment and medium

Abstract

The invention relates to the technical field of data processing and the field of financial science and technology, and discloses a business index monitoring and warning method, which comprises the following steps of: collecting basic business index data in a business node, sending the data to a monitoring server through a message queue, and accumulatively receiving the basic business index data in a preset time window; aggregation processing is carried out when the time window ends, and a statistical result is generated; determining an alarm threshold by combining trend analysis according to the historical statistical data; and then processing the statistical result, comparing the statistical result with an alarm threshold value, generating alarm information, and finally sending the alarm information through an alarm server. According to the invention, through real-time acquisition, processing and aggregation of the business index data, the change of a complex business scene can be quickly responded; the system can generate alarm information more accurately and transmit the alarm information to a related service system in time by utilizing a dynamically adjusted alarm threshold value and trend analysis; the processing efficiency of the monitoring data can be improved.

Description

Technical Field

[0001] The present invention relates to the fields of data processing technology and financial technology, and in particular to a business indicator monitoring and alarm method, device, equipment and storage medium. Background Art

[0002] In the monitoring of financial systems, core indicators such as traffic, error rate, latency, saturation, etc. are usually key indicators for evaluating system performance. When collecting these indicators, existing monitoring systems mainly focus on the summary of basic indicators, such as the number of calls, total time consumption, success rate, etc. However, these basic monitoring are limited to basic system status and it is difficult to provide in-depth performance analysis and problem diagnosis.

[0003] For more complex business scenarios, such as booking statistics in financial insurance business, existing technologies can only derive detailed indicators such as error rate through secondary calculations, which not only increases the consumption of computing resources, but also lacks real-time performance and cannot quickly respond to business needs. In particular, for real-time analysis of business data and alarm generation, existing monitoring systems are difficult to achieve accuracy and efficiency.

[0004] In addition, the existing system monitoring solution lacks support for customized business indicators. Complex business requirements in the financial industry, especially those involving multiple data entry points, such as the calculation of life insurance reservations, often require manual scripting to handle. This method is inefficient and difficult to reuse, and the system monitoring response speed to business is therefore limited.

[0005] The existing monitoring system lacks real-time processing of data in complex business scenarios, resulting in the inability to quickly provide feedback on detailed indicators such as error rates. For personalized business indicators in the financial industry, such as data aggregation and analysis of multiple portals, the existing system is difficult to process automatically and relies on manual scripting. The existing system is unable to perform real-time, multi-dimensional, and accurate analysis of complex business indicators, which affects the system's alarm generation and performance diagnosis. Summary of the invention

[0006] The main purpose of the present invention is to provide a business indicator monitoring and alarm method, device, equipment and storage medium, aiming to solve the technical problems that the existing technology cannot automatically generate detailed business indicators in real time when processing complex business scenarios, and lacks the ability to dynamically adjust the alarm threshold, resulting in insufficient real-time and accuracy of monitoring and alarm.

[0007] To achieve the above object, the present invention provides a business indicator monitoring and alarm method, comprising:

[0008] Collect basic business indicator data in the business node and send the basic business indicator data to the monitoring server through the message queue;

[0009] Accumulating and receiving the basic business indicator data within a preset time window through the monitoring server;

[0010] At the end of the time window, all basic business indicator data accumulated and received are aggregated to generate statistical results, which include business indicator values ​​including average response time, error rate and / or request volume;

[0011] Acquire historical statistical data of the service node from the monitoring server, and determine an alarm threshold through a trend analysis module based on the historical statistical data;

[0012] Processing the statistical results according to the processing strategy configured in the monitoring server;

[0013] Compare the processed statistical results with the alarm threshold, and generate alarm information when a business indicator in the statistical results exceeds the corresponding alarm threshold;

[0014] The alarm information is sent to the alarm service end.

[0015] Furthermore, to achieve the above-mentioned purpose, the present invention provides a business indicator monitoring and alarm device, comprising:

[0016] A data collection module is used to collect basic business indicator data in the business node and send the basic business indicator data to the monitoring server through a message queue;

[0017] A data cache module, used to accumulate and receive the basic business indicator data within a preset time window through the monitoring server;

[0018] A data aggregation module is used to aggregate all basic business indicator data accumulated and received at the end of the time window to generate statistical results, wherein the statistical results include business indicator values ​​including average response time, error rate and / or request volume;

[0019] A trend analysis module, used to obtain historical statistical data of the service node from the monitoring server, and determine the alarm threshold through the trend analysis module based on the historical statistical data;

[0020] A data processing module, used to process the statistical results according to the processing strategy configured in the monitoring server;

[0021] An alarm generation module is used to compare the processed statistical results with the alarm threshold, and generate alarm information when a business indicator in the statistical results exceeds the corresponding alarm threshold;

[0022] The alarm notification module is used to send the alarm information to the alarm service end.

[0023] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and a business indicator monitoring and alarm program stored in the memory and executable on the processor, and the business indicator monitoring and alarm program, when executed by the processor, implements the steps of the business indicator monitoring and alarm method as described above.

[0024] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium, on which a business indicator monitoring and alarm program is stored, and when the business indicator monitoring and alarm program is executed by a processor, the steps of the business indicator monitoring and alarm method described above are implemented.

[0025] Beneficial effects: The present invention relates to the fields of data processing technology and financial technology, and discloses a business indicator monitoring and alarm method, which collects basic business indicator data in a business node, sends these data to a monitoring server through a message queue, accumulates and receives basic business indicator data within a preset time window, and performs aggregation processing at the end of the time window to generate statistical results; determines the alarm threshold based on historical statistical data and trend analysis; then processes the statistical results and compares them with the alarm threshold to generate alarm information, and finally sends the alarm information through the alarm server. The present invention can quickly respond to changes in complex business scenarios through real-time collection, processing and aggregation of business indicator data; using dynamically adjusted alarm thresholds and trend analysis, the system can generate alarm information more accurately and transmit the alarm information to related business systems in a timely manner; it can improve the processing efficiency of monitoring data, realize accurate monitoring and analysis of business indicators, reduce system response delays, ensure monitoring efficiency and real-time alarms in complex business scenarios, and thus improve the stability and reliability of the overall system. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0027] Figure 1 A schematic diagram of an application environment of a business indicator monitoring and alarm method in an embodiment of the present invention;

[0028] Figure 2 A flow chart of an embodiment of a method for monitoring and warning business indicators of the present invention;

[0029] Figure 3 A schematic diagram of functional modules of a preferred embodiment of the service indicator monitoring and alarm device of the present invention;

[0030] Figure 4 A schematic diagram of the structure of a computer device in one embodiment of the present invention;

[0031] Figure 5 FIG. 4 is another schematic diagram of the structure of a computer device in one embodiment of the present invention. DETAILED DESCRIPTION

[0032] It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention.

[0033] The service indicator monitoring and alarm method provided by the embodiment of the present invention can be applied in Figure 1 In the application environment, the user end communicates with the server end through the network. The server end can collect basic business indicator data in the business node through the user end, and send these data to the monitoring server end through the message queue, accumulate and receive basic business indicator data within a preset time window, and perform aggregation processing at the end of the time window to generate statistical results; determine the alarm threshold based on historical statistical data and trend analysis; then process the statistical results and compare them with the alarm threshold to generate alarm information, and finally send the alarm information through the alarm server end. The present invention can quickly respond to changes in complex business scenarios through real-time collection, processing and aggregation of business indicator data; using dynamically adjusted alarm thresholds and trend analysis, the system can generate alarm information more accurately and transmit the alarm information to related business systems in a timely manner; it can improve the processing efficiency of monitoring data, realize accurate monitoring and analysis of business indicators, reduce the response delay of the system, ensure the monitoring efficiency and real-time nature of alarms in complex business scenarios, thereby improving the stability and reliability of the overall system. Among them, the user end can be but not limited to various personal computers, laptops, smart phones, tablet computers and portable wearable devices. The server end can be implemented with an independent server or a server cluster composed of multiple servers. The present invention is described in detail below through specific embodiments.

[0034] See also Figure 2 , Figure 2 This is a flow chart of an embodiment of a method for monitoring and alarming business indicators provided by the present invention. It should be noted that although a logical sequence is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0035] like Figure 2 As shown, the business indicator monitoring and alarm method proposed by the present invention includes the following steps:

[0036] S10, collecting basic business indicator data in the business node, and sending the basic business indicator data to the monitoring server through the message queue;

[0037] In this embodiment, in the financial system, each business node (such as the service node of the online trading platform, the insurance business processing node, etc.) will generate a large number of basic business indicators, including request volume, response time, error rate, etc. Each business node will deploy a dedicated data collection module, which can usually collect business indicators in two main ways:

[0038] API interface call: The data collection module in the business node calls the data in the business system regularly or in real time through the standard API interface to collect indicator data.

[0039] Log monitoring module: The system extracts business indicators by monitoring the data in the log files generated by the service, and parses the contents of the log files to obtain various business indicators.

[0040] In the system, an API interface can be designed for each business node, through which the basic indicator data of the current node can be obtained in real time. API calls support GET or POST requests and return structured data (such as JSON format), including key information such as request volume, response time, error rate, etc.

[0041] The log monitoring module monitors the log files generated by the system, parses these logs and extracts key information from them. Each record in the log contains data such as timestamp, request type, response time, etc. Log parsing tools (such as Fluentd) can automatically extract this data and format it into a standard data format for subsequent processing.

[0042] In order to maintain stable transmission of business indicator data under high concurrency, the system uses message queue middleware (such as Kafka, RabbitMQ, etc.) to send data asynchronously. Message queue is a reliable transmission mechanism that ensures that business indicator data can be delivered to the monitoring server in an orderly and stable manner even under high concurrency. Data is encapsulated in a structured format (such as JSON or XML) and delivered through the message queue.

[0043] Set up a message queue middleware, such as Kafka, between the business node and the monitoring server. The business node encapsulates the collected basic business indicator data, formats it into JSON or XML, and sends it to the specified message queue topic through the Kafka producer module. The Kafka consumer module pulls data from the topic for processing on the monitoring server.

[0044] After the business indicator data collected by the API interface or log monitoring module is encapsulated, it is transmitted asynchronously using the message queue middleware. Kafka uses its built-in partitioning mechanism to ensure that data can be transmitted in a stable and sequential manner in high-concurrency scenarios to avoid data loss. RabbitMQ uses its reliability confirmation mechanism (ACK) to ensure that data can safely reach the monitoring server.

[0045] Example: In the financial industry, real-time monitoring of trading systems is essential to ensure the stability of the system. For example, each node in an online trading platform may generate a large amount of request volume and response time data. These business indicator data can be collected in real time through the API interface and transmitted to the monitoring server through Kafka. The monitoring server aggregates these data. When the system detects that the response time or error rate of a node is too high, it can generate an alarm in time and notify the operation and maintenance team. This real-time monitoring and data transmission mechanism ensures that the system can run stably during the peak period of financial business, and can quickly identify and solve potential performance problems.

[0046] Through the above steps, basic business indicator data can be collected and transmitted from business nodes in real time. Whether through the API interface or the log monitoring module, the data can be quickly transmitted to the monitoring server in a structured form. Using the message queue, the system can maintain the stability of data transmission in high-concurrency scenarios, ensuring that business indicators can be continuously collected and processed.

[0047] S20, accumulating and receiving the basic business indicator data within a preset time window through the monitoring server;

[0048] In this embodiment, the monitoring server needs to set a "time window", that is, a specified time period, for accumulating the received basic business indicator data. This time window can be a fixed window (such as every minute or every five minutes) or a sliding window (continuously updating the time range, real-time sliding statistics). The length of the time window can be dynamically configured according to business needs.

[0049] The monitoring server will pre-configure a fixed time interval (such as 1 minute, 5 minutes, etc.). At the beginning and end of each time window, the system will accumulate and lock the business indicator data received during the time period. At the end of the time window, all received data will enter the subsequent processing link.

[0050] Sliding time windows do not have fixed start and end times, but adjust the window in real time as data is received. The system accumulates and processes data within a rolling time range. Sliding windows are usually used in more real-time data processing scenarios, and can count data from a period of time (such as data from the past minute) at any time.

[0051] In each time window, the monitoring server will continuously receive basic business indicator data from the business node from the message queue. In order to ensure the integrity and consistency of the data, the received data will be temporarily stored in the memory or distributed cache system for accumulation.

[0052] The system can use memory cache (such as Redis) or distributed storage system (such as HBase) to store the received basic business indicator data. Through this caching mechanism, it can be ensured that at the end of the time window, all data has been completely received and can be subsequently aggregated.

[0053] In high-concurrency scenarios, the monitoring server may receive data from multiple business nodes at the same time. By using multi-threading or asynchronous processing, the system can process data streams in parallel to ensure that business indicator data can be received and accumulated quickly and safely.

[0054] Example: In a financial trading system, it is critical to monitor the transaction request volume and response time of each node in real time. By configuring a fixed time window of 1 minute on the monitoring server, the system can aggregate basic business indicator data from multiple trading nodes every 1 minute. These data can be used to analyze system load. For example, during periods of large market fluctuations, the system can monitor in real time whether the transaction request volume per minute exceeds the normal range, thereby identifying potential performance bottlenecks in advance and generating warning information in a timely manner to ensure the stable operation of the system.

[0055] By presetting the time window on the monitoring server, the system can effectively accumulate the received business indicator data within the specified time period. Whether it is a fixed time window or a sliding time window, the system can ensure the integrity and continuity of data reception, laying the foundation for subsequent data aggregation and analysis.

[0056] S30, at the end of the time window, performing aggregation processing on all basic business indicator data accumulated and received to generate statistical results, wherein the statistical results include business indicator values ​​including average response time, error rate and / or request volume;

[0057] In this embodiment, when the time window ends, the system locks and freezes all basic business indicator data received within the window. At this time, the data is summarized and aggregated to generate the final statistical results. The goal of the aggregation process is to extract useful information from the raw data by calculating and summarizing various business indicators (such as request volume, response time, error rate, etc.) for subsequent analysis and alarm use.

[0058] When the time window reaches the end, the system will immediately stop receiving new business indicator data and lock all data in the current time window. This operation ensures that all data involved in the aggregation processing are complete and consistent.

[0059] After the data is locked, the system will apply the corresponding aggregation algorithm to calculate the summary statistical results according to different business indicator types. Commonly used aggregation algorithms include:

[0060] For request volume, the aggregation algorithm calculates the sum of all requests within the time window.

[0061] For response time, the system calculates the average response time of all requests to reflect the overall performance of the system.

[0062] For the error rate, the system calculates the ratio of failed requests to total requests to obtain a statistical value of the error rate.

[0063] Through aggregation processing, the system generates statistical results within the time window. The statistical results include the core business indicators of the system, such as average response time, error rate, and request volume. These results are important indicators output by the system, which can reflect the operating status of the business node in the current time period and be used for subsequent alarms or performance analysis.

[0064] The system will store the generated statistical results in a structured format (such as JSON or XML) and save them to the database or cache of the monitoring server. In this way, the system can query and analyze historical statistical results at any time.

[0065] After generating the statistical results, the system can display the data in different dimensions according to business needs. Users can view the trend changes of data such as average response time, error rate and request volume in different time windows.

[0066] Example: In a financial trading platform, response time and error rate are key indicators for measuring system performance. For example, the system can aggregate the response time and total number of error requests for all current trading requests at the end of each minute window. Through this aggregation, the system can generate accurate statistical results, such as the average response time and error rate per minute. When these indicators exceed the preset normal range, the system can immediately generate an alarm message to notify the operation and maintenance personnel to check.

[0067] By aggregating the basic business indicator data accumulated at the end of the time window, the system can generate key statistical results in a short time, such as average response time, error rate, and request volume. These statistical results provide the system with a clear business operation status, allowing the system to detect performance problems in a timely manner and respond quickly through the alarm mechanism.

[0068] S40, obtaining historical statistical data of the service node from the monitoring server, and determining an alarm threshold through a trend analysis module based on the historical statistical data;

[0069] In this embodiment, historical statistical data refers to the summary data of basic business indicators related to the business node collected by the monitoring system in a specific time period. These data usually include average response time, request volume, error rate, etc., which can reflect the operating status of the business node in the past period of time.

[0070] Historical statistical data is usually stored in the database or distributed storage system (such as Elasticsearch, HBase) of the monitoring server. These data will be stored regularly by time period during the monitoring process for subsequent analysis and query.

[0071] When trend analysis based on historical data is required, the query module of the monitoring server retrieves historical statistical data from the database. You can use API or SQL query statements to specify the time range, business node ID, and specific business indicators (such as response time, error rate) to obtain the corresponding data set.

[0072] The system determines the alarm threshold by analyzing historical statistical data and combining it with the trend analysis module. The trend analysis module is responsible for extracting change patterns (such as periodic fluctuations, long-term trends, etc.) from historical data and dynamically adjusting the system's alarm threshold based on these change patterns to ensure that the alarm can adapt to different business scenarios and data fluctuations.

[0073] The system processes and analyzes historical statistical data. Common trend analysis methods include time series analysis, moving average method, linear regression, etc. These methods can identify abnormal fluctuations or long-term change trends from historical data.

[0074] Through the trend analysis module, the system automatically adjusts the alarm threshold according to the analyzed trend. For example, when the response time is found to be increasing over a period of time, the system can dynamically adjust the alarm threshold of the indicator to avoid frequent alarms due to a fixed threshold that is too low or missed alarms due to a fixed threshold that is too high.

[0075] Example: In financial systems, such as online banking transaction systems, response time and error rate are key performance indicators. The system can identify regular fluctuations during certain business peaks by regularly acquiring historical data and combining it with trend analysis. For example, the transaction volume is usually large on the first day of each month. The system analyzes historical data to derive this trend and automatically adjusts the alarm threshold, allowing the system to monitor and alarm more accurately, thereby avoiding frequent alarms due to too low a fixed threshold, or performance problems not being discovered in time due to too high a threshold. Such a mechanism can ensure the stability of the financial system during critical business time periods.

[0076] By obtaining historical statistical data from the monitoring server and combining it with the trend analysis module to dynamically adjust the alarm threshold, the system can set the alarm standard more accurately, avoiding the problem that the fixed threshold cannot adapt to the fluctuation of business indicators. The system's use of historical data is enhanced. By analyzing the trend of the data, the system can identify potential performance problems in advance and flexibly set the alarm standard, thereby reducing false alarms and missed alarms and improving the system's alarm efficiency.

[0077] S50, processing the statistical results according to the processing strategy configured in the monitoring server;

[0078] In this embodiment, on the monitoring server, the system administrator or technician can pre-configure various processing strategies, which are used to process the statistical results of the business nodes (such as response time, error rate, request volume, etc.). The core function of the processing strategy is to analyze, process and optimize the statistical results in different dimensions. Depending on the business needs, the processing strategy may include rule configuration, threshold adjustment, anomaly detection, etc.

[0079] The processing strategy is usually configured through the visual interface of the monitoring server. System administrators can set specific processing logic for different business indicators. For example, you can set a threshold detection strategy for response time, a peak monitoring strategy for request volume, and an anomaly detection strategy for error rate. Each processing strategy can be customized and adjusted according to the needs of the business scenario.

[0080] Some processing strategies may be dynamic, that is, the system will automatically adjust according to the real-time situation. For example, the monitoring server can dynamically analyze the historical changes of business indicators and adjust the thresholds or detection criteria in the processing strategy accordingly to ensure that the system can make appropriate processing under different business load conditions.

[0081] After the statistical results are generated, the monitoring server will process them according to the pre-configured processing strategy. This processing includes further analysis of the statistical data, such as calculating the fluctuation range of certain indicators, detecting abnormal values, or comparing the data with the alarm threshold.

[0082] When the statistical results are generated, the system will execute them one by one according to the configured processing strategies. For example, for response time data, the system will execute rule detection to determine whether the response time in a certain period of time exceeds the set standard or whether there is a significant performance degradation.

[0083] For the error rate statistics, the system can use processing strategies to detect abnormal points. For example, when the error rate of a business node is higher than the historical average, the system will mark it as abnormal and generate different processing results based on the abnormality level.

[0084] If a multi-dimensional processing strategy is configured, the system will perform a more detailed analysis of the statistical results, combining multiple business indicators (such as response time, error rate, and request volume) for cross-analysis, thereby providing more accurate performance diagnosis.

[0085] Example description: In a financial transaction system, real-time monitoring of the response time and error rate of transaction requests is the key to ensuring the stability of the system operation. For example, the system administrator can configure a specific processing strategy on the monitoring server to strictly monitor the response time of transaction requests. If the response time within a certain period of time exceeds the set threshold, the system will automatically generate an alarm message according to the policy configuration and send it to the relevant operation and maintenance personnel. Similarly, for the error rate, the system can configure an anomaly detection strategy. When the error rate fluctuates abnormally, the system will analyze it through the anomaly detection mechanism and trigger different levels of alarms according to the fluctuation range of the error rate to ensure the stability and security of the financial system during business peak periods.

[0086] By processing the statistical results according to the preset processing strategy in the monitoring server, the system can achieve flexible business monitoring and anomaly detection. The configuration of this processing strategy allows system administrators to customize the analysis logic of business indicators according to business scenarios, so that the system can adapt to changes in different business scenarios.

[0087] S60, comparing the processed statistical result with the alarm threshold, and generating alarm information when a business indicator in the statistical result exceeds the corresponding alarm threshold;

[0088] In this embodiment, after the statistical results are generated, the system will compare the statistical results of various business indicators (such as response time, error rate, request volume, etc.) with the pre-set alarm threshold. This step is to detect whether a business indicator exceeds the preset range of the system, and then determine whether an alarm information needs to be generated.

[0089] Alarm thresholds are usually configured on the monitoring server and stored in a database or configuration file. When processing statistical results, the system reads the corresponding alarm thresholds from the storage and compares these values ​​with the statistical results item by item. Alarm thresholds can be fixed values ​​or dynamically adjusted through trend analysis.

[0090] The system compares the thresholds for each business metric (such as average response time, error rate, request volume, etc.). For example, if the average response time in the statistical results is 500 milliseconds, and the threshold is set to 300 milliseconds, the system will mark the metric as exceeding the threshold. Each business metric is compared independently to ensure that all key metrics can be monitored.

[0091] When the statistical result of a business indicator exceeds the corresponding alarm threshold, the system will automatically generate an alarm message. The alarm message usually includes the name of the exceeded indicator, the actual statistical value, the difference value exceeding the threshold, the business node ID, the timestamp and other information, so as to quickly locate the problem and respond.

[0092] In the comparison results, if a business indicator exceeds the set threshold, the system will immediately generate an alarm message. The generated alarm message usually contains the following content:

[0093] Business indicator name: such as response time, error rate, request volume, etc.

[0094] Actual statistical value: the specific value of the indicator that exceeds the threshold, such as the response time is 500 milliseconds.

[0095] Threshold and difference: The alarm information records the set threshold (such as 300 milliseconds) and the actual exceeded difference value (such as 200 milliseconds).

[0096] Timestamp and node information: The alarm information also includes the time when the alarm event occurred and the business node ID, which helps operation and maintenance personnel quickly locate the location and time of the problem.

[0097] The generated alarm information can be stored in the monitoring system through logs, and sent to relevant operation and maintenance personnel through message queues or notification systems. The system supports notifying the operation and maintenance team of alarm information via email, SMS, corporate WeChat or other means.

[0098] Example: In financial systems, monitoring of response time and error rate is crucial. For example, in a stock trading system, once the transaction response time exceeds a certain threshold, it may lead to transaction failure or delay, so the system needs to set a strict alarm mechanism. When the response time of a node exceeds the set alarm threshold (such as 300 milliseconds), the system will immediately generate an alarm message to notify the operation and maintenance personnel to intervene quickly to ensure the normal operation of the trading system. In addition, error rate alarms are also very important. When the error rate exceeds the threshold (such as 5%), the system notifies the relevant team via SMS or instant messaging to promptly troubleshoot the problem and avoid further expansion of system failures.

[0099] By comparing the processed statistical results with the alarm threshold and generating alarm information when the threshold is exceeded, the system can monitor key business indicators in real time and respond quickly when anomalies occur. This ensures that the system can respond to performance issues, error rate exceeding the standard, etc. in a timely manner in high-concurrency and complex business scenarios, thereby improving the system's operational stability.

[0100] S70: Send the alarm information to an alarm service end.

[0101] In this embodiment, after generating the alarm information, the system needs to encapsulate the information so that it can be sent to the alarm server for processing. The alarm information usually includes the type of business indicator that exceeds the alarm threshold, the actual statistical value, the threshold difference, the business node ID, the timestamp, etc. This information is encapsulated in a standard structured data format (such as JSON or XML) to ensure that the consistency and integrity of the data are maintained during the transmission process.

[0102] The generated alarm information is encapsulated in a structured format, usually in JSON or XML format. JSON format is more commonly used and can be quickly serialized and transmitted over the network. The encapsulated alarm information includes:

[0103] Business indicator name: such as request volume, response time, error rate, etc.

[0104] Actual statistical value: For example, the response time is 500 milliseconds.

[0105] Alarm threshold and difference: If the threshold is set to 300 milliseconds, the threshold is exceeded by 200 milliseconds.

[0106] Service node ID: used to identify the service node where the alarm occurs.

[0107] Timestamp: records the specific time when the alarm occurs to ensure timeliness.

[0108] The encapsulated alarm information needs to be sent to the alarm server through a message transmission mechanism (such as a message queue or HTTP request). The alarm server is the core module responsible for receiving, processing, and distributing alarms. Through the asynchronous transmission mechanism of the message queue, the alarm information can be efficiently and reliably transmitted to the server. Commonly used message queue systems include Kafka, RabbitMQ, etc., which can ensure the order and reliability of data transmission under high concurrency.

[0109] The system sends the encapsulated alarm information to the alarm server through the message queue middleware. Message queue middleware such as Kafka can ensure that the alarm information can still be transmitted in an orderly manner under high concurrency conditions, and confirm that the information has been successfully received through the ACK mechanism. The message receiving module of the alarm server subscribes to and pulls the alarm information from the message queue.

[0110] The message queue supports asynchronous processing of alarm information, ensuring that the system will not affect other data processing tasks while generating alarms. Asynchronous sending can also improve the overall concurrent processing capability of the system and ensure the timeliness of alarm information.

[0111] To ensure the security of alarm information, SSL / TLS encryption mechanism is usually used during the transmission process. This can ensure that the alarm information will not be stolen or tampered with during network transmission, ensuring the secure transmission of information.

[0112] Example: In financial systems, it is crucial to monitor the performance and error rate of business nodes. For example, in an online payment platform, when the error rate of a node exceeds the set threshold (such as 5%), the system will generate an alarm message and send it to the alarm server. After receiving the alarm message, the alarm server classifies it as an emergency alarm according to its urgency and immediately notifies the operation and maintenance team to handle it.

[0113] By sending alarm information to the alarm server, the system can realize centralized management and processing of business indicators that exceed the threshold. As an independent processing module, the alarm server can effectively separate the generation and processing of alarm information, improving the reliability and scalability of the system. At the same time, the use of message queues or APIs for the transmission of alarm information ensures the reliable transmission of information under high concurrency.

[0114] The present invention relates to the fields of data processing technology and financial technology, and discloses a business indicator monitoring and alarm method, which collects basic business indicator data in a business node, sends these data to a monitoring server through a message queue, accumulates and receives basic business indicator data within a preset time window, and performs aggregation processing at the end of the time window to generate statistical results; determines the alarm threshold value based on historical statistical data and trend analysis; then processes the statistical results and compares them with the alarm threshold value to generate alarm information, and finally sends the alarm information through the alarm server. The present invention can quickly respond to changes in complex business scenarios through real-time collection, processing and aggregation of business indicator data; using dynamically adjusted alarm thresholds and trend analysis, the system can generate alarm information more accurately and transmit the alarm information to relevant business systems in a timely manner; it can improve the processing efficiency of monitoring data, realize accurate monitoring and analysis of business indicators, reduce the response delay of the system, ensure the monitoring efficiency and real-time nature of alarms in complex business scenarios, thereby improving the stability and reliability of the overall system.

[0115] In one embodiment, the above S10 includes:

[0116] S101, deploying a data collection agent module in a business node;

[0117] S102, calling an API interface through the data collection agent module to collect basic business indicator data from the business node, where the basic business indicator data includes request volume, response time and / or error rate;

[0118] S103, encapsulating the basic business indicator data into a structured data format, wherein the structured data format includes a JSON format or an XML format;

[0119] S104, asynchronously sending the encapsulated business indicator data to the monitoring server through a message queue.

[0120] In this embodiment, the data collection agent module is deployed on each business node to realize the real-time collection of business indicator data. The data collection agent module acts as an intermediate layer and is responsible for collecting basic business indicators generated by the business system. This module can be flexibly deployed according to business needs.

[0121] The data collection agent module can be deployed on the business node in the form of a container, process or service. Common deployment methods include directly deploying a resident process on a virtual machine or physical server, or deploying the agent module through containerization in a microservice architecture.

[0122] After deployment, the proxy module needs to be configured to specify the types of business indicators it needs to monitor (such as request volume, response time, etc.) and the frequency of data collection. Configuration can be achieved through configuration files or command line parameters.

[0123] The proxy module collects basic business indicator data by calling the API interface provided by the business node. The API interface can return the current operating status data of the business node in real time or periodically, including request volume, response time, error rate, etc.

[0124] The API interface provided by the business node is usually a RESTful interface that supports GET or POST requests. The data collection agent module sends requests to these interfaces to obtain the current basic business indicator data of the business node.

[0125] The data returned by the API contains various business indicator information. The proxy module extracts the required business indicators from the API response, such as request volume, average response time, error rate, etc. The data can be in structured JSON or XML format.

[0126] The collected business indicator data needs to be encapsulated in a standard structured data format, such as JSON or XML. The structured data format can facilitate subsequent data transmission and processing.

[0127] After obtaining the basic business indicator data, the proxy module will encapsulate the data into a predetermined format (such as JSON or XML). The encapsulation process includes formatting the business indicator data to ensure that each data field has a clear structure and semantics. The encapsulated data will contain information such as the business indicator name, value, timestamp, and business node ID. According to the system design requirements, the data format is usually JSON or XML. These formats are widely used in data transmission and storage, with good readability and cross-platform support.

[0128] After the business indicator data collected by the business node is encapsulated, the system sends it to the monitoring server asynchronously through the message queue. Using message queues (such as Kafka or RabbitMQ) for asynchronous transmission can ensure the stability and reliability of data transmission in high-concurrency scenarios.

[0129] In the data collection agent module, the system will configure the message queue producer module to asynchronously send the encapsulated business indicator data to the queue topic specified by the monitoring server. Common message queue middleware includes Kafka, RabbitMQ, etc. They provide a reliable message delivery mechanism to ensure that data will not be lost due to network fluctuations.

[0130] The proxy module pushes the encapsulated business indicator data to the message queue topic, and the message queue ensures that the data is efficiently transmitted to the monitoring server through an asynchronous mechanism. The asynchronous transmission mode can reduce the occupation of business node resources during the data collection process and improve the efficiency of data transmission.

[0131] By deploying the data collection agent module, this embodiment enables the system to collect business indicator data from business nodes in real time and efficiently, and standardizes it through structured data format, which facilitates subsequent data analysis and processing. Using message queue middleware for asynchronous data transmission ensures the reliability and stability of data under high concurrency conditions, and reduces the impact of the data transmission process on business node performance.

[0132] In one embodiment, the above S20 includes:

[0133] S201, determining parameters of a time window, wherein the parameters include a start time and an end time;

[0134] S202, configuring a data receiving module on the monitoring server, wherein the data receiving module is used to continuously receive basic business indicator data;

[0135] S203, verifying the integrity and consistency of the received business indicator data;

[0136] S204, caching the verified business indicator data into a storage module of the monitoring server.

[0137] In this embodiment, the time window refers to the time period set by the system for accumulating received data. Within the preset time window, all received business indicator data will be aggregated and processed. The parameters of the time window include the start time and the end time, which define the time range for data accumulation.

[0138] In the configuration module of the monitoring server, the administrator can manually or automatically set the parameters of the time window, including the start time and end time. The time window can be flexibly configured according to business needs, and can usually be set to 1 minute, 5 minutes or other suitable time periods.

[0139] In some cases, the system can use a sliding time window, which can be continuously updated to accumulate and process data from a period of time in the past in real time. This dynamic time window is particularly suitable for systems that require continuous monitoring.

[0140] The data receiving module of the monitoring server is responsible for continuously receiving basic business indicator data from each business node within the time window. The data receiving module needs to efficiently process highly concurrent incoming data streams to ensure that data is not lost or delayed.

[0141] The data receiving module can be configured to receive business indicator data from multiple business nodes. The receiving module can use multi-threading or concurrent mechanisms to process large-scale data streams, ensuring that high-concurrency data transmission requests can be received and processed in a short time.

[0142] The data receiving module usually receives the encapsulated business indicator data from each business node through a message queue (such as Kafka or RabbitMQ). The message queue provides an asynchronous transmission mechanism, and the receiving module can extract data from the message queue topic in sequence.

[0143] After receiving the business indicator data, the system will verify the integrity and consistency of the data to ensure that the received data is not lost, duplicated or erroneous. Integrity and consistency verification is an important step in data quality assurance to ensure that subsequent aggregation processing is based on accurate data.

[0144] The system checks whether the received business indicator data contains all required fields (such as business indicator name, value, timestamp, business node ID, etc.) and ensures that no data is missing or in the wrong format.

[0145] The system also verifies the consistency of the data, ensuring that the data format is uniform and the value of the field matches its type (e.g. response time should be in numeric format, timestamp should be in time format). In addition, the system checks for duplicate data and removes it if necessary.

[0146] The business indicator data that has been verified for integrity and consistency will be temporarily stored in the cache module of the monitoring server. This step ensures that the data can be quickly extracted and aggregated after the time window ends. The cache can be a memory cache (such as Redis) or a distributed storage system.

[0147] The system stores the verified data in a memory cache or distributed cache system for quick access at the end of the time window. Using a cache system can improve the efficiency of data processing and reduce storage and reading delays.

[0148] Common cache systems include memory cache (such as Redis) and distributed storage systems (such as HBase). Memory cache is suitable for data that needs to be processed quickly and stored for a short period of time, while distributed storage systems are suitable for long-term storage and distributed access of large-scale data.

[0149] In this embodiment, by accumulating and receiving business indicator data within a preset time window, the system can effectively process and aggregate a large amount of business indicator data in a short time. Integrity and consistency verification ensures the accuracy and integrity of the data, and the cache mechanism improves the efficiency of data processing. The design of the time window and cache system enables the system to cope with data flow processing in high-concurrency scenarios and ensure the real-time and stability of business monitoring.

[0150] In one embodiment, after the above S70, the method further includes:

[0151] S801, according to the urgency of the alarm information, classify the alarm level of the alarm information into emergency alarm, important alarm and common alarm, and different alarm levels correspond to different notification channels;

[0152] S802, identifying the permissions of multiple service terminals through the alarm server, and matching corresponding alarm levels for different permissions;

[0153] S803: The alarm service end sends the alarm information to the corresponding service end through a corresponding notification channel based on the alarm level.

[0154] In this embodiment, after receiving the alarm information, the system determines its urgency according to the alarm content (such as the degree of exceeding the business indicator, system status, etc.). Alarm information is usually divided into three categories: emergency alarm, important alarm and ordinary alarm, and each level of alarm information corresponds to a different notification channel.

[0155] The system classifies alarm information according to the severity of business indicators. For example, a critical alarm may be triggered when the response time exceeds the threshold, while a slight error rate may only trigger a normal alarm. Key fields in the alarm information (such as indicator type and degree of exceeding the threshold) will serve as the basis for the alarm level classification.

[0156] Different alarm levels correspond to different notification channels. Emergency alarms may be notified instantly via phone or text message, important alarms may be sent via email or IM tools, and ordinary alarms may only be notified via email or log records. The system automatically selects the corresponding notification method according to the alarm level.

[0157] The alarm server needs to identify the different business terminals that receive alarms and their permission levels. Different business terminals (such as system administrators, ordinary users, etc.) have different permissions. The system will match the corresponding alarm levels for the business terminals based on these permission levels to ensure that different roles only receive alarm information related to their responsibilities.

[0158] The alarm server will identify the permission level of each business end based on the role or permission list of the business end. For example, a system administrator can receive all levels of alarms, while ordinary users may only receive ordinary alarms.

[0159] The alarm server matches the alarm level in the alarm information with the permission level of the business end. Business ends with high permissions (such as operation and maintenance supervisors) can receive emergency alarms and important alarms, while ordinary users only receive ordinary alarms. This matching process ensures that each business end only receives alarm information that meets its permissions, avoiding interference from irrelevant alarm information.

[0160] After determining the alarm level and the matching business end permissions, the alarm server will send the alarm information to the corresponding business end through the corresponding notification channel. The notification channel can be selected according to the degree of urgency, such as SMS, phone, email, instant messaging tools, etc.

[0161] The system selects the appropriate notification channel based on the alarm level and business end permissions. For example, emergency alarms will be sent via phone or text message to ensure immediate notification; important alarms will be sent via email or corporate WeChat, and ordinary alarms can be sent via email or recorded in logs.

[0162] The alarm server will use the preset notification mechanism (such as SMS gateway, mail server, instant messaging interface) to send the alarm information to the business end. The system supports multi-channel delivery to ensure that the alarm information can reach the business end in time.

[0163] Example: In the financial system, the stability of the system is crucial, especially when it comes to capital transactions. Once the response time of a node exceeds the set threshold, the system will generate an emergency alarm message. Through the authority identification of the alarm server, the emergency alarm will be sent to the system administrator and operation and maintenance supervisor, and they will be notified urgently by SMS and phone. Ordinary users or business personnel only receive ordinary alarms and are notified of abnormal situations by email. Different levels of alarms match different authorities and notification methods to ensure that the financial system can respond quickly and reduce the impact of failures.

[0164] This embodiment divides the alarm information into different alarm levels according to their urgency, and combines it with the permission system of the business end. The system can ensure that users of different roles receive alarm information related to their responsibilities, avoiding excessive irrelevant alarms interfering with work. At the same time, different alarm levels are matched with different notification channels to ensure that the alarm information can be delivered to the relevant person in charge in a timely and effective manner in an emergency, thereby improving the system response speed and the accuracy of alarm processing.

[0165] In one embodiment, in the above S30, at the end of the time window, all the basic business indicator data accumulated and received are aggregated to generate statistical results, including:

[0166] S301, at the end of the time window, freezing all received basic business indicator data;

[0167] S302, classifying the basic business indicator data according to the business indicator type;

[0168] S303, processing the classified basic business indicator data through an aggregation module to generate corresponding statistical results;

[0169] S304, storing the statistical results in a storage module of the monitoring server.

[0170] In this embodiment, when the time window ends, the system freezes all business indicator data received in the window to ensure that the data stops updating and modification at this moment. The purpose of this step is to lock the data in the time window to prevent any subsequent new data from affecting the accuracy of the aggregation processing.

[0171] After the time window ends, the system stops receiving new business indicator data and locks the data set within the current time window. This freezing mechanism ensures that all data is complete and belongs to the same time window.

[0172] Before freezing, the system ensures that all data packets have been received completely. If data transmission fails before the time window ends, the system triggers a retry mechanism to ensure that the received data is complete and correct.

[0173] Before aggregation, the system will classify the data according to different business indicator types. Common business indicator types include request volume, response time, and error rate. These indicators represent the system load, performance, and stability.

[0174] In the frozen data set, the system will classify and store the data according to the business indicator type. For example, the request volume, response time, and error rate will be processed separately. The classified data will help with subsequent aggregation processing, ensuring that each business indicator can be analyzed and calculated separately.

[0175] Data classification can be achieved through data labels of business indicators. For example, each data packet will be marked with its corresponding indicator type (such as request volume or response time). The system extracts and classifies the corresponding data by reading these labels.

[0176] The aggregation module is responsible for processing the classified business indicator data. Each business indicator (such as request volume, response time, and error rate) will be calculated using different aggregation algorithms to generate statistical results within the time window. The statistical results are a comprehensive overview of the business system status and reflect the system's operating performance within the time window.

[0177] The system calculates the total number of requests received in the time window. The aggregated result can reflect the load of the system. For response time, the aggregation module calculates the average response time of each request to reflect the overall performance of the system. The system calculates the error rate, which is the ratio of failed requests to the total number of requests in the time window. This result can show the stability of the system and the frequency of errors.

[0178] The generated statistical results will be stored in the storage module of the monitoring server for subsequent analysis, alarm triggering, and historical data query. The storage module can be a memory cache, a distributed storage system, or a persistent database.

[0179] The aggregated statistical results will be formatted as structured data (such as JSON or XML format) and stored in the storage module of the monitoring server. The storage module can be a memory cache (such as Redis) for short-term storage, or a distributed storage system (such as HBase, Elasticsearch) for long-term storage and historical queries. In some cases, the statistical results need to be persisted, and the system will store them in a persistent database (such as MySQL or PostgreSQL) for subsequent trend analysis and auditing.

[0180] In this embodiment, by aggregating the business indicator data within the time window, the system can generate accurate statistical results, which can clearly reflect the operating status of the system within the specified time period. The freezing mechanism ensures the integrity of the data, and the classification and aggregation processing mechanism improves the system's processing efficiency for various business indicators. The storage of statistical results can provide data support for subsequent alarms and trend analysis, thereby improving the monitoring capability and stability of the system.

[0181] In one embodiment, the above S40 includes:

[0182] S401, determining the time range and business indicator type of historical statistical data;

[0183] S402, based on the time range and the business indicator type, obtaining corresponding historical statistical data from a storage module of the monitoring server, wherein the historical statistical data is business indicator data in a time series format;

[0184] S403, analyzing the historical statistical data to determine the average value of each business indicator, and setting a basic alarm threshold for the corresponding business indicator according to the average value;

[0185] S404, analyzing the historical statistical data through a trend analysis module to determine a change trend of the business indicator;

[0186] S405: According to the change trend of the business indicator, the corresponding basic alarm threshold is adjusted to generate a final alarm threshold.

[0187] In this embodiment, before performing historical data analysis, the system first needs to determine the time range of the analysis and the type of business indicator to be analyzed. The time range defines the past time period to be analyzed (such as the past week or the past month), while the business indicator type defines the indicators that the system focuses on (such as request volume, response time, and error rate).

[0188] System administrators or automated scripts can set time ranges based on business needs. Common settings include the past 24 hours, the past week, or a time period dynamically set based on business needs.

[0189] Business indicator types include response time, request volume, error rate, etc. The system selects the indicator type that needs to be analyzed according to business needs to ensure accurate monitoring of changes in key system indicators.

[0190] The system retrieves historical statistical data corresponding to the set time range and business indicator type from the storage module of the monitoring server. Historical data is usually stored in a time series format, and each data point corresponds to a specific business indicator value for a certain period of time.

[0191] Historical statistical data is generally stored in distributed storage systems or persistent databases, such as Elasticsearch, HBase, or SQL databases. These data are stored in a time series format and can reflect the changes in business indicators in different time periods.

[0192] The system obtains historical statistics from the storage module through the query interface. The query results return historical data that meets the time range and business indicator type for subsequent analysis. The data in time series format includes the correspondence between timestamps and business indicator values, such as the number of requests per minute or the error rate per hour.

[0193] The system performs a preliminary analysis of the historical statistical data obtained and calculates the average value of each business indicator. Based on these average values, the system sets basic alarm thresholds for the corresponding business indicators as the standard for subsequent judgment of whether an alarm is needed.

[0194] The system summarizes historical statistical data and calculates the average value of business indicators in each time period. For example, the system can calculate the average response time, request volume, and error rate in the past week. The average value is used as a preliminary reference for the basic alarm threshold.

[0195] Based on the average value, the system will set a basic alarm threshold for each business indicator. For example, if the average value of the historical response time is 300 milliseconds, the system may set 350 milliseconds as the basic alarm threshold, and an alarm will be triggered if the value exceeds this value.

[0196] The system further uses the trend analysis module to conduct in-depth analysis of historical data to identify changing trends in business indicators. Trend analysis can reveal cyclical fluctuations, growth trends or other anomalies.

[0197] The system can use time series analysis models, linear regression, or moving average methods to perform trend analysis on historical data. This analysis can identify long-term change patterns in business indicators, such as whether there is fluctuation or continuous growth. Through analysis, the system can identify trends in business indicators, such as a significant increase in request volume in certain periods of time, or a long-term downward trend in response time. These trends provide a basis for dynamic adjustment of alarm thresholds.

[0198] Based on the identified change trends, the system dynamically adjusts the basic alarm threshold. The final alarm threshold reflects the current trend of the business indicator, ensuring that the system can trigger an alarm when there is an abnormal fluctuation and avoid false alarms or missed alarms caused by fixed thresholds that are not suitable for the current business situation.

[0199] If trend analysis shows that a business metric is fluctuating widely, the system will adjust the basic alarm threshold based on the fluctuation. For example, if historical data shows that the response time is gradually increasing, the system will increase the alarm threshold to avoid frequent alarms. Similarly, if the system finds that a metric is decreasing, the threshold may be lowered accordingly. The adjusted alarm threshold serves as the final alarm standard, ensuring that the system can generate alarm information in a timely and accurate manner based on the current business situation. For example, the alarm threshold for response time can be adjusted from the basic 350 milliseconds to 400 milliseconds to adapt to the gradual increase in response time.

[0200] Example: In financial systems, changes in transaction request volume and response time are extremely important. By analyzing historical data from the past month, the system found that the transaction volume in the first week of each month was significantly higher than in other time periods, and the response time also increased significantly during peak trading periods. Based on this trend, the system dynamically adjusted the alarm threshold, raising the peak response time alarm threshold from 300 milliseconds to 400 milliseconds, ensuring that the system can flexibly respond to alarm needs based on fluctuations in transaction volume and avoid interference from excessive alarms.

[0201] This embodiment determines the alarm threshold based on historical statistical data and trend analysis modules. The system can dynamically adjust the alarm standard according to changes in business indicators to avoid frequent false alarms or missed alarms caused by fixed thresholds not being suitable for current business conditions. This flexible threshold setting mechanism improves the system's alarm accuracy and responsiveness, ensuring that the business system can generate alarms and take measures in a timely manner when there is high load or abnormal fluctuations.

[0202] In one embodiment, the above S60 includes:

[0203] S601, comparing the business indicators in the statistical results with the alarm thresholds one by one;

[0204] S602, determining whether each business indicator is greater than a corresponding alarm threshold;

[0205] S603, if any business indicator is greater than the corresponding alarm threshold, generate alarm information including the business indicator type, actual statistical value, difference value exceeding the threshold, business node information and timestamp;

[0206] S604: If all business indicators are not greater than the corresponding alarm thresholds, no alarm information is generated.

[0207] In this embodiment, after the system processes and generates statistical results, the system compares the statistical results of each business indicator (such as request volume, response time, error rate, etc.) with the pre-set alarm thresholds one by one. This step ensures that each key business indicator is monitored to avoid missing potential abnormal situations.

[0208] The system first extracts the values ​​of various business indicators from the statistical results, such as total request volume, average response time, and error rate. Each business indicator will be compared with the corresponding alarm threshold as a separate value.

[0209] The system extracts pre-set or dynamically adjusted alarm thresholds from the storage module or cache. These thresholds may be fixed values ​​or dynamically calculated by the trend analysis module.

[0210] Each business indicator will be compared with its corresponding alarm threshold to determine whether the indicator exceeds the alarm standard. The comparison adopts simple logical judgment, for example: if (business indicator > alarm threshold), the system performs the corresponding operation.

[0211] For each business indicator, the system will determine whether it exceeds the corresponding alarm threshold based on the comparison result. This step is used to identify whether there is an abnormal situation and decide whether to generate an alarm.

[0212] The system will perform logical judgment operations based on the comparison results. If the value of a business indicator is greater than the corresponding alarm threshold, the business indicator is considered to be in an abnormal state and an alarm needs to be triggered. If there are multiple business indicators, the system will judge each indicator one by one to ensure that all key performance indicators can be monitored.

[0213] When the statistical result of any business indicator exceeds the corresponding alarm threshold, the system will generate an alarm message. The alarm message contains detailed business indicator type, actual statistical value, difference exceeding the threshold, business node that triggered the alarm, and the timestamp of the alarm triggering. This information helps system administrators quickly locate and solve problems.

[0214] When a business indicator is detected to exceed the alarm threshold, the system will automatically generate an alarm message. The alarm message is stored in a structured manner. Common formats include JSON and XML. The contents of the alarm message include:

[0215] Business indicator type: Indicates which indicator triggered the alarm (such as request volume, response time, error rate).

[0216] Actual statistical value: The actual value that triggers the alarm, such as a response time of 500 milliseconds.

[0217] Difference value exceeding the threshold: The difference between the alarm threshold and the actual value, for example, exceeding the threshold by 200 milliseconds.

[0218] Business node information: records which business node triggered the alarm to help quickly locate the problem node.

[0219] Timestamp: records the time when the alarm is triggered, helping operation and maintenance personnel to identify the specific time when the alarm occurs.

[0220] Alarm information storage and sending: The generated alarm information will be stored in the alarm module of the monitoring system and sent to relevant operation and maintenance personnel through message queues, emails or instant messaging tools.

[0221] If the statistical results of all business indicators do not exceed the alarm threshold, there is no need to generate an alarm. The system will record these normal business states in the monitoring log for future query.

[0222] If all business indicators do not exceed the threshold, the system will not generate any alarm information, and the normal business status will be recorded in the system log or no operation will be performed to ensure that system resources are not wasted.

[0223] Sometimes the system will record the current normal status in the monitoring log for subsequent analysis. For example, it may record "all business indicators are within the normal range" for use in historical trend analysis.

[0224] In this embodiment, by comparing the business indicators in the statistical results with the alarm thresholds one by one, the system can achieve accurate business monitoring and quickly generate alarm information when abnormal situations are detected. This mechanism ensures that the system can efficiently process business indicators in high-concurrency scenarios and promptly discover and respond to system performance issues. By accurately generating alarm information containing business nodes, timestamps, and difference values, operation and maintenance personnel can quickly locate problems and take repair measures, reducing system downtime and business impact.

[0225] In one embodiment, a business indicator monitoring and alarm device is provided, and the business indicator monitoring and alarm device corresponds one-to-one with the business indicator monitoring and alarm method in the above embodiment. Figure 3 , Figure 3 This is a functional module diagram of a preferred embodiment of the business indicator monitoring and alarm device of the present invention. Data collection module 10, data cache module 20, data aggregation module 30, trend analysis module 40, data processing module 50, alarm generation module 60 and alarm notification module 70. Each functional module is described in detail as follows:

[0226] The data collection module 10 is used to collect basic business indicator data in the business node and send the basic business indicator data to the monitoring server through the message queue;

[0227] The data cache module 20 is used to accumulate and receive the basic business indicator data within a preset time window through the monitoring server;

[0228] A data aggregation module 30 is used to aggregate all basic business indicator data accumulated and received at the end of the time window to generate statistical results, wherein the statistical results include business indicator values ​​including average response time, error rate and / or request volume;

[0229] A trend analysis module 40, configured to obtain historical statistical data of the service node from a monitoring server, and determine an alarm threshold through a trend analysis module based on the historical statistical data;

[0230] A data processing module 50, configured to process the statistical results according to a processing strategy configured in the monitoring server;

[0231] An alarm generating module 60 is used to compare the processed statistical result with the alarm threshold, and generate an alarm message when a business indicator in the statistical result exceeds the corresponding alarm threshold;

[0232] The alarm notification module 70 is used to send the alarm information to the alarm service end.

[0233] In one embodiment, the data collection module 10 is specifically used for:

[0234] Deploy data collection agent modules in business nodes;

[0235] Calling an API interface through the data collection agent module to collect basic business indicator data from the business node, wherein the basic business indicator data includes request volume, response time and / or error rate;

[0236] Encapsulating the basic business indicator data into a structured data format, wherein the structured data format includes a JSON format or an XML format;

[0237] The encapsulated business indicator data is asynchronously sent to the monitoring server through the message queue.

[0238] In one embodiment, the data cache module 20 is specifically used for:

[0239] Determine parameters of the time window, the parameters including a start time and an end time;

[0240] Configure a data receiving module on the monitoring server, wherein the data receiving module is used to continuously receive basic business indicator data;

[0241] Verify the integrity and consistency of received business indicator data;

[0242] The verified business indicator data is cached in the storage module of the monitoring server.

[0243] In one embodiment, the alarm notification module 70 is specifically used to:

[0244] According to the urgency of the alarm information, the alarm level of the alarm information is divided into emergency alarm, important alarm and ordinary alarm, and different alarm levels correspond to different notification channels;

[0245] Identify the permissions of multiple business terminals through the alarm server, and match corresponding alarm levels for different permissions;

[0246] The alarm service end sends the alarm information to the corresponding service end through the corresponding notification channel based on the alarm level.

[0247] In one embodiment, the data aggregation module 30 is specifically configured to:

[0248] At the end of the time window, all received basic business indicator data are frozen;

[0249] Classifying the basic business indicator data according to business indicator types;

[0250] The classified basic business indicator data is processed through the aggregation module to generate corresponding statistical results;

[0251] The statistical results are stored in a storage module of the monitoring service end.

[0252] In one embodiment, the trend analysis module 40 is specifically used to:

[0253] Determine the time range and business indicator type for historical statistics;

[0254] Based on the time range and the business indicator type, obtaining corresponding historical statistical data from a storage module of the monitoring server, wherein the historical statistical data is business indicator data in a time series format;

[0255] Analyze the historical statistical data to determine the average value of each business indicator, and set a basic alarm threshold for the corresponding business indicator according to the average value;

[0256] Analyze the historical statistical data through a trend analysis module to determine the change trend of the business indicators;

[0257] According to the changing trend of the business indicator, the corresponding basic alarm threshold is adjusted to generate the final alarm threshold.

[0258] In one embodiment, the alarm generation module 60 is specifically configured to:

[0259] Compare the business indicators in the statistical results with the alarm thresholds one by one;

[0260] Determine whether each business indicator is greater than the corresponding alarm threshold;

[0261] If any business indicator is greater than the corresponding alarm threshold, an alarm message is generated containing the business indicator type, actual statistical value, difference value exceeding the threshold, business node information and timestamp;

[0262] If all business indicators are not greater than the corresponding alarm threshold, no alarm information is generated.

[0263] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4As shown. The computer device includes a processor, a memory, a network interface and a database connected via a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external user terminal through a network connection. When the computer program is executed by the processor, it realizes the functions or steps of a service indicator monitoring and alarm method service side.

[0264] In one embodiment, a computer device is provided. The computer device may be a user terminal, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor, a memory, a network interface, a display screen and an input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it realizes the functions or steps of a user-side of a business indicator monitoring and alarm method

[0265] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the following steps when executing the computer program:

[0266] Collect basic business indicator data in the business node and send the basic business indicator data to the monitoring server through the message queue;

[0267] Accumulating and receiving the basic business indicator data within a preset time window through the monitoring server;

[0268] At the end of the time window, all basic business indicator data accumulated and received are aggregated to generate statistical results, which include business indicator values ​​including average response time, error rate and / or request volume;

[0269] Acquire historical statistical data of the service node from the monitoring server, and determine an alarm threshold through a trend analysis module based on the historical statistical data;

[0270] Processing the statistical results according to the processing strategy configured in the monitoring server;

[0271] Compare the processed statistical results with the alarm threshold, and generate alarm information when a business indicator in the statistical results exceeds the corresponding alarm threshold;

[0272] The alarm information is sent to the alarm service end.

[0273] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0274] Collect basic business indicator data in the business node and send the basic business indicator data to the monitoring server through the message queue;

[0275] Accumulating and receiving the basic business indicator data within a preset time window through the monitoring server;

[0276] At the end of the time window, all basic business indicator data accumulated and received are aggregated to generate statistical results, which include business indicator values ​​including average response time, error rate and / or request volume;

[0277] Acquire historical statistical data of the service node from the monitoring server, and determine an alarm threshold through a trend analysis module based on the historical statistical data;

[0278] Processing the statistical results according to the processing strategy configured in the monitoring server;

[0279] Compare the processed statistical results with the alarm threshold, and generate alarm information when a business indicator in the statistical results exceeds the corresponding alarm threshold;

[0280] The alarm information is sent to the alarm service end.

[0281] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can refer to the relevant descriptions on the server side and the user side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0282] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0283] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by 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.

[0284] It should be noted that if software tools or components other than those of the Company appear in the embodiments of the present application, they are only used for illustration and do not represent actual use. The above-described embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them; although the present invention has been described in detail with reference to the above-mentioned embodiments, a person of ordinary skill in the art should understand that the technical solutions described in the above-mentioned embodiments can still be modified, or some of the technical features thereof can be replaced by equivalents; and these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. A business indicator monitoring and alarm method, characterized in that: The following steps are involved: Collect basic business indicator data in the business node and send the basic business indicator data to the monitoring server through the message queue; Accumulating and receiving the basic business indicator data within a preset time window through the monitoring server; At the end of the time window, all basic business indicator data accumulated and received are aggregated to generate statistical results, which include business indicator values ​​including average response time, error rate and / or request volume; Acquire historical statistical data of the service node from the monitoring server, and determine an alarm threshold through a trend analysis module based on the historical statistical data; Processing the statistical results according to the processing strategy configured in the monitoring server; Compare the processed statistical results with the alarm threshold, and generate alarm information when a business indicator in the statistical results exceeds the corresponding alarm threshold; The alarm information is sent to the alarm service end.

2. The business indicator monitoring and alarm method according to claim 1, characterized in that: Collecting basic business indicator data in the business node and sending the basic business indicator data to the monitoring server through the message queue includes: Deploy data collection agent modules in business nodes; Calling an API interface through the data collection agent module to collect basic business indicator data from the business node, wherein the basic business indicator data includes request volume, response time and / or error rate; Encapsulating the basic business indicator data into a structured data format, wherein the structured data format includes a JSON format or an XML format; The encapsulated business indicator data is asynchronously sent to the monitoring server through the message queue.

3. The business indicator monitoring and alarm method according to claim 1, characterized in that: The basic business indicator data is accumulated and received by the monitoring server within a preset time window, including: Determine parameters of the time window, the parameters including a start time and an end time; Configure a data receiving module on the monitoring server, wherein the data receiving module is used to continuously receive basic business indicator data; Verify the integrity and consistency of received business indicator data; The verified business indicator data is cached in the storage module of the monitoring server.

4. The business indicator monitoring and alarm method according to claim 1, characterized in that: After sending the alarm information to the alarm server, the method further includes: According to the urgency of the alarm information, the alarm level of the alarm information is divided into emergency alarm, important alarm and ordinary alarm, and different alarm levels correspond to different notification channels; Identify the permissions of multiple business terminals through the alarm server, and match corresponding alarm levels for different permissions; The alarm service end sends the alarm information to the corresponding service end through the corresponding notification channel based on the alarm level.

5. The business indicator monitoring and alarm method as described in claim 1, characterized in that: At the end of the time window, all basic business indicator data accumulated and received are aggregated to generate statistical results, including: At the end of the time window, all received basic business indicator data are frozen; Classifying the basic business indicator data according to business indicator types; The classified basic business indicator data is processed through the aggregation module to generate corresponding statistical results; The statistical results are stored in a storage module of the monitoring service end.

6. The business indicator monitoring and alarm method according to claim 1, characterized in that: Acquiring historical statistical data of the service node from the monitoring server, and determining an alarm threshold through a trend analysis module based on the historical statistical data, including: Determine the time range and business indicator type for historical statistics; Based on the time range and the business indicator type, obtaining corresponding historical statistical data from a storage module of the monitoring server, wherein the historical statistical data is business indicator data in a time series format; Analyze the historical statistical data to determine the average value of each business indicator, and set a basic alarm threshold for the corresponding business indicator according to the average value; Analyze the historical statistical data through a trend analysis module to determine the change trend of the business indicators; According to the changing trend of the business indicator, the corresponding basic alarm threshold is adjusted to generate the final alarm threshold.

7. The business indicator monitoring and alarm method according to claim 1, characterized in that: The processed statistical result is compared with the alarm threshold. When a business indicator in the statistical result exceeds the corresponding alarm threshold, an alarm message is generated, including: Compare the business indicators in the statistical results with the alarm thresholds one by one; Determine whether each business indicator is greater than the corresponding alarm threshold; If any business indicator is greater than the corresponding alarm threshold, an alarm message is generated containing the business indicator type, actual statistical value, difference value exceeding the threshold, business node information and timestamp; If all business indicators are not greater than the corresponding alarm threshold, no alarm information is generated.

8. A business indicator monitoring and alarm device, characterized in that: The business indicator monitoring and alarm device includes: A data collection module is used to collect basic business indicator data in the business node and send the basic business indicator data to the monitoring server through a message queue; A data cache module, used to accumulate and receive the basic business indicator data within a preset time window through the monitoring server; A data aggregation module is used to aggregate all basic business indicator data accumulated and received at the end of the time window to generate statistical results, wherein the statistical results include business indicator values ​​including average response time, error rate and / or request volume; A trend analysis module, used to obtain historical statistical data of the service node from the monitoring server, and determine the alarm threshold through the trend analysis module based on the historical statistical data; A data processing module, used to process the statistical results according to the processing strategy configured in the monitoring server; An alarm generation module is used to compare the processed statistical results with the alarm threshold, and generate alarm information when a business indicator in the statistical results exceeds the corresponding alarm threshold; The alarm notification module is used to send the alarm information to the alarm service end.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and a business indicator monitoring and alarm program stored in the memory and executable on the processor. When the business indicator monitoring and alarm program is executed by the processor, the steps of the business indicator monitoring and alarm method described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that: The storage medium stores a business indicator monitoring and alarm program, and when the business indicator monitoring and alarm program is executed by the processor, the steps of the business indicator monitoring and alarm method according to any one of claims 1 to 7 are implemented.

Images