Performance monitoring and exception repairing method and device, equipment and medium

Abstract

The invention relates to the technical field of big data and the field of financial science and technology, and discloses a performance monitoring and exception repairing method, which comprises the following steps of: obtaining performance data of a plurality of applications from a performance monitoring module in a production environment, and comparing the performance data in adjacent time periods according to a preset time period; generating a change rate of the target performance index; detecting whether the change rate of the target performance index exceeds a preset threshold value or not, and marking the target performance index as an abnormal state when the change rate exceeds the threshold value; and based on the target performance index of the abnormal state, generating an anomaly repair scheme and applying the anomaly repair scheme to a production environment. According to the method, by dynamically collecting the performance data of multiple applications, calculating the change rate of the target performance index in real time, automatically detecting and marking the abnormal state, generating the corresponding repair scheme and rapidly applying, the real-time performance monitoring performance and accuracy can be remarkably improved, automatic detection and repair of abnormal problems are achieved, and the efficiency is improved. And the stability and operation efficiency of the system are improved.

Description

Technical Field

[0001] The present invention relates to the fields of big data technology and financial technology, and in particular to a performance monitoring and exception repair method, device, equipment and storage medium. Background Art

[0002] As an important means of system testing, performance testing is a key measure to ensure the stable operation of the system. Especially in the financial industry, performance testing is an essential step before each project goes online and each important version is updated. In the financial field, the security and stability of the business are of vital importance. Business interruption or system performance problems may lead to immeasurable financial losses and customer loss. Therefore, performance testing has extremely high requirements in this field. However, with the continuous changes in the market and the continuous introduction of new financial products, the existing performance testing methods have exposed some shortcomings.

[0003] The business of the financial industry is changing rapidly, and various financial products and business models are constantly being innovated. For example, diversified financial products such as cash management, periodic opening, daily opening, minimum holding period products and fund products have been launched one after another. In addition, the business objects for market segments such as family trusts, private equity funds, and pension management are becoming increasingly diversified, resulting in the increasing complexity of business systems. In this context, traditional performance testing methods lack the ability to respond quickly to business changes, and the test results are prone to lose timeliness, making it difficult to reflect the actual performance of the system under new business or new policy environments.

[0004] With the abundance of financial products and frequent adjustments to regulatory policies, business rules have become increasingly complex. Existing performance testing methods often rely on a lot of manual intervention to build data models and test scenarios, which leads to rising testing costs. In addition, in complex business scenarios, it is difficult to build test scenarios that are close to the production environment. Testers need to spend a lot of time and resources to update and maintain test data and models, making the testing process less efficient.

[0005] Current operation and maintenance monitoring methods mainly focus on system-level hardware resource indicators, such as disk, memory, CPU, network and other basic system resource monitoring. Although these monitoring methods can provide basic protection for the real-time status of system resources, they lack dynamic and holistic monitoring of business interfaces and application performance, making it difficult to predict potential performance problems. With the increasing complexity of financial business processes, operation and maintenance monitoring that relies solely on hardware resources can no longer meet the comprehensive and dynamic monitoring needs of business performance. Summary of the invention

[0006] The main purpose of the present invention is to provide a performance monitoring and exception repair method, device, equipment and storage medium, aiming to solve the technical problem that the existing technology cannot realize dynamic monitoring of application performance and automatic exception repair, resulting in the system being difficult to respond to business changes and performance anomalies in a timely manner.

[0007] To achieve the above object, the present invention provides a performance monitoring and abnormality repair method, comprising:

[0008] Obtain performance data of multiple applications from the performance monitoring module in the production environment according to the preset collection frequency;

[0009] According to the preset time period, the performance data of each application in adjacent time periods are compared to generate the change rate of the target performance indicator of each application;

[0010] Detect whether the change rate of the target performance indicator of each application exceeds a preset threshold;

[0011] When the change rate of a target performance indicator of an application exceeds a preset threshold, marking the target performance indicator of the application as an abnormal state;

[0012] Based on the target performance indicators marked as abnormal states, generate corresponding abnormality repair plans;

[0013] Apply the anomaly repair solution to the production environment.

[0014] Furthermore, to achieve the above-mentioned purpose, the present invention provides a performance monitoring and abnormality repair device, comprising:

[0015] The performance data collection module is used to obtain the performance data of multiple applications from the performance monitoring module in the production environment according to the preset collection frequency;

[0016] A data analysis module is used to compare the performance data of each application in adjacent time periods according to a preset time period, and generate a change rate of the target performance indicator of each application;

[0017] An abnormality judgment module is used to detect whether the change rate of the target performance indicator of each application exceeds a preset threshold;

[0018] An abnormal marking module, used for marking the target performance indicator of an application as an abnormal state when the change rate of the target performance indicator of the application exceeds a preset threshold;

[0019] A repair solution generation module, used to generate a corresponding abnormality repair solution based on the target performance indicator marked as an abnormal state;

[0020] A repair solution application module is used to apply the abnormal repair solution to the production environment.

[0021] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and a performance monitoring and exception repair program stored in the memory and executable on the processor, wherein the performance monitoring and exception repair program, when executed by the processor, implements the steps of the performance monitoring and exception repair method described above.

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

[0023] Beneficial effects: The present invention relates to the fields of big data technology and financial technology, and discloses a performance monitoring and abnormality repair method, which obtains the performance data of multiple applications from a performance monitoring module in a production environment, and compares the performance data in adjacent time periods according to a preset time period to generate a change rate of a target performance indicator; detects whether the change rate of the target performance indicator exceeds a preset threshold, and marks the target performance indicator as an abnormal state when the threshold is exceeded; based on the target performance indicator in the abnormal state, generates an abnormality repair plan and applies it in a production environment. The present invention can significantly improve the real-time and accuracy of performance monitoring by dynamically collecting performance data of multiple applications, calculating the change rate of the target performance indicator in real time, and automatically detecting and marking abnormal states, generating corresponding repair plans and quickly applying them, realizing automatic detection and repair of abnormal problems, reducing human intervention, improving system stability and operating efficiency, and effectively responding to performance changes in complex business environments. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0025] Figure 1 A schematic diagram of an application environment of a performance monitoring and abnormality repair method in an embodiment of the present invention;

[0026] Figure 2 It is a flow chart of an embodiment of a performance monitoring and abnormality repair method of the present invention;

[0027] Figure 3 A schematic diagram of functional modules of a preferred embodiment of the performance monitoring and abnormality repairing device of the present invention;

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

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

[0030] 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.

[0031] The performance monitoring and abnormality repair method provided by the embodiment of the present invention can be applied in the following aspects: Figure 1 In an application environment, the user end communicates with the server end through a network. The server end can obtain the performance data of multiple applications from the performance monitoring module in the production environment through the user end, and compare the performance data in adjacent time periods according to a preset time period to generate a change rate of the target performance indicator; detect whether the change rate of the target performance indicator exceeds a preset threshold, and mark the target performance indicator as an abnormal state when the threshold is exceeded; based on the target performance indicator of the abnormal state, generate an abnormal repair plan and apply it in the production environment. The present invention can significantly improve the real-time and accuracy of performance monitoring by dynamically collecting the performance data of multiple applications, calculating the change rate of the target performance indicator in real time, and automatically detecting and marking the abnormal state, generating a corresponding repair plan and quickly applying it, so as to realize the automatic detection and repair of abnormal problems, reduce human intervention, improve the stability and operation efficiency of the system, and effectively cope with performance changes in complex business environments. 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.

[0032] See also Figure 2 , Figure 2 This is a flow chart of an embodiment of the performance monitoring and abnormality repair method provided by the present invention. It should be noted that although the logical order 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.

[0033] like Figure 2 As shown, the performance monitoring and abnormality repair method proposed by the present invention includes the following steps:

[0034] S10, acquiring performance data of multiple applications from a performance monitoring module in a production environment according to a preset collection frequency;

[0035] In this embodiment, the production environment refers to the real working environment used by an enterprise, organization or system in formal operation. This is the environment for actually serving customers, performing business operations and processing real data, which is opposite to the development environment and the testing environment.

[0036] In a production environment, all applications, services, and system components run in real business scenarios, processing real user requests and business data. The production environment is characterized by high stability, reliability, and availability, because any problems or errors will directly affect the actual business and user experience. In this embodiment, the production environment specifically refers to the real operating environment where the core business system of an enterprise or organization is located. The performance monitoring module is installed in the production environment to collect and monitor the various performance indicators of the system in real time. This means that the collected data comes from actually running applications and services, rather than test or simulation data.

[0037] For example, for a bank's business system, the production environment refers to the real operating system that processes customers' actual deposits, transfers, financial management and other operations. All data are real transaction records of users. The bank's production environment needs to monitor the performance of its applications in real time to ensure that customer operations can be processed in a timely manner and that the system can run efficiently and stably.

[0038] The performance monitoring module of the production environment refers to the monitoring module deployed in the production system, which can collect the operation data of the application in real time. The monitoring module can be integrated into the application server, or collect data through a distributed monitoring agent. Usually, the service interface call status of the application, the statistical information of SQL execution, etc. are collected. Through the performance monitoring system (such as CAT, Prometheus, etc.), each application in the production environment is monitored. The performance monitoring module usually sets up monitoring probes or data agents to monitor the key service interfaces and database execution of each application, and regularly uploads the data to the central monitoring platform for analysis.

[0039] The preset collection frequency refers to setting a time interval for collecting performance data based on specific business needs and the criticality of system performance. The collection frequency can be set to every minute, every hour, etc., and can be flexibly adjusted according to the rate of change of the business and the performance monitoring needs. The data collection task can be triggered regularly through a scheduler (such as Quartz, Cron Job, etc.). The preset collection frequency is generally determined according to the characteristics of the business system. For example, for a core business system with high frequency of access, the collection frequency can be set to once a minute; while for a low-frequency business system, the collection frequency can be longer.

[0040] Obtaining performance data for multiple applications means collecting performance indicators from multiple applications at a set collection frequency, including service interface call status, SQL execution information, response time, request success rate, number of requests per second, etc.

[0041] An application refers to a specific business or functional module running in a system, which is usually composed of one or more services, components, or microservices. An application can include a complete business system or business function, such as a payment system, customer management system, order processing system, transaction system, etc. Applications mainly refer to the following:

[0042] Independent business modules: such as financial product management, loan approval, payment gateway, etc. in the banking system.

[0043] Service or Microservice: In a microservice architecture, an application may be a collection of multiple microservices. For example, in an e-commerce platform, "order service", "user service", "payment service", etc. are all applications.

[0044] Functional components: An application can also be a collection of functional components, such as multiple core modules in a "Customer Relationship Management System (CRM)", such as "Customer Information Management", "Marketing Automation", "Sales Tracking", etc.

[0045] The main feature of applications is that they have independent business logic and are treated as an independent unit in system monitoring for performance data collection and analysis.

[0046] Performance data is collected and classified by the monitoring module and transmitted to the central monitoring platform for storage and analysis. Data collection can be implemented in a variety of ways, such as API calls, log parsing, data agents, etc. For example, use a log collection agent (such as Fluentd, Logstash) to obtain service interface call information and SQL execution logs of each application in real time, and upload them to the central data platform through HTTPAPI or message queues.

[0047] Example description: In a banking system in the financial industry, a performance monitoring module is deployed in the core business system, and the collection frequency is set to every minute. The monitoring module collects the number of calls, response time and success rate of key service interfaces in real time, and records the SQL execution information related to these interface calls. In this way, abnormal situations in the subscription or redemption transactions of bank wealth management products can be discovered in a timely manner. For example, during the peak trading period, the average response time of a certain interface is monitored to suddenly increase, or the failure rate of certain SQL executions increases abnormally. Based on the real-time collected data, the operation and maintenance team can quickly identify performance bottlenecks, generate targeted optimization plans, and repair and deploy them in a timely manner, thereby ensuring the stable operation of banking business.

[0048] By deploying the performance monitoring module in the production environment and setting a reasonable collection frequency, the performance data of multiple applications can be automatically collected to form a real-time performance monitoring system. It can respond to business changes in real time, provide more sophisticated monitoring and data collection, and improve the flexibility of system monitoring and the real-time nature of data.

[0049] S20, comparing the performance data of each application in adjacent time periods according to a preset time period, and generating a change rate of a target performance indicator of each application;

[0050] In this embodiment, the preset time period refers to a time interval set in advance by the system for periodically analyzing and comparing the performance data of the application. The time period can be set based on the needs of the specific business, such as hourly, daily, weekly or monthly. The selection of the time period needs to balance the frequency of business changes and the use of system resources. The time period can be set in the configuration file of the monitoring system and can be dynamically adjusted to adapt to the changing needs of the business. For example, a scheduler (such as Cron Jobs or Quartz Scheduler) can be used to control the periodic comparison of data.

[0051] For each application, the same type of performance data is extracted for comparison in two adjacent time periods. Adjacent time periods refer to two consecutive time periods, such as the current time period and the previous time period. The comparison of performance data includes item-by-item analysis of multiple performance indicators (such as the number of service requests, response time, failure rate, etc.). At the end of each time period, the performance data of the time period is extracted from the monitoring database, and the performance data of the previous time period is retrieved at the same time. Then, through the data comparison program, the two sets of data are compared and analyzed according to the same performance indicators. For example, for the number of service requests, the difference in the total number of service requests in the two time periods can be calculated, and for the response time, the change in the average response time can be calculated.

[0052] The rate of change is the ratio of performance data changes between two adjacent time periods. For example, the rate of change of service request times, the rate of change of average response time, and the rate of change of failure rate can be calculated. The target performance indicator refers to the indicator that has a direct impact on the key performance of the business system, such as the number of requests per second, response time, etc. The rate of change can be calculated according to the following formula:

[0053] Service request number change rate = (number of requests in the current time period - number of requests in the previous time period) / number of requests in the previous time period;

[0054] Average response time change rate = (average response time of the current time period - average response time of the previous time period) / average response time of the previous time period;

[0055] Failure rate change rate = (failure rate of the current time period - failure rate of the previous time period) / failure rate of the previous time period.

[0056] After calculating each change rate, a change rate list is generated and stored in the database for use in subsequent steps.

[0057] Example: In a bank's core business system, the preset time period is every hour. The monitoring platform regularly compares the number of service requests, average response time, and failure rate of each application in adjacent time periods. When the system detects that the change rate of service requests for an application is +20%, and the change rate of the average response time is +15%, an abnormal alarm is immediately generated, indicating that the application may have a performance bottleneck. The operation and maintenance team conducts rapid troubleshooting based on the trend analysis of the change rate and log data, and promptly optimizes database queries or increases service resources to ensure timely processing of customer transaction requests.

[0058] By comparing the performance data of each application in adjacent time periods, abnormal changes in various performance indicators can be discovered in a timely manner, especially for continuous performance indicator changes, which can be warned and handled in a timely manner. The changing trend of application performance can be captured dynamically, providing a reliable data basis for anomaly detection and repair, and effectively improving the monitoring accuracy and response speed of the system.

[0059] S30, detecting whether the change rate of the target performance indicator of each application exceeds a preset threshold;

[0060] In this embodiment, for each application, the change rate of its target performance indicators (such as the number of service requests, average response time, failure rate, etc.) is analyzed. The selection of target performance indicators is usually based on the core business requirements of the application and has a significant impact on the performance of the application and user experience. The system regularly calculates and extracts the change rate of the target performance indicators of each application. The performance monitoring module can be used to automatically detect and analyze various indicators of multiple applications. The calculation of the change rate is usually stored in a dedicated monitoring database and can be accessed by the detection program at any time.

[0061] The preset threshold is a critical value set by the system for each target performance indicator, which is used to determine whether an abnormality occurs in the indicator. The setting of the preset threshold is usually based on the statistical analysis of historical performance data and the definition of business requirements. For example, the threshold of the average response time can be set to a change rate within 5%, and the threshold of the failure rate can be set to a change rate within 1%. The preset threshold of each target performance indicator is defined in the system's configuration module. The setting of the threshold can be based on multiple factors such as the average fluctuation range of historical data, the requirements of the business department, SLAs (service level agreements), etc. In actual implementation, these thresholds can be set and updated through configuration files, database configuration tables, or dynamic parameter adjustments.

[0062] Compare the rate of change of the target performance indicator of each application with the preset threshold to determine whether the rate of change exceeds the threshold. If it exceeds the threshold, it is considered that the target performance indicator has an abnormal change. The core task of the detection program is to compare each change rate with its corresponding threshold to determine whether it is abnormal. The detection program obtains the rate of change of each target performance indicator from the monitoring database and reads the corresponding preset threshold from the threshold configuration table. For each indicator, the rate of change is compared with the threshold. If a certain rate of change exceeds the preset threshold, the program will mark the indicator as "abnormal" and record the result in the anomaly detection log.

[0063] Example: In a large-scale trading system in the financial field, in order to ensure the stability of peak trading, the system sets target performance indicators for each key service interface and sets preset thresholds for each indicator. During the daily trading peak, the system automatically detects the number of service requests per minute and the rate of change of the average response time. When the average response time change rate of a certain trading interface exceeds 5%, the system immediately triggers an alarm, indicating that the interface may have insufficient resources or network delay problems. The operation and maintenance team can quickly locate the problem based on the alarm information, thereby avoiding transaction congestion or delays and ensuring the safety of customers' funds and business continuity.

[0064] By comparing the target performance indicator change rate with the preset threshold in real time, it is possible to accurately detect abnormal system performance and issue alerts or handle them in a timely manner. It is able to automatically and efficiently detect abnormal changes in applications, improving the system's stability and abnormal response capabilities.

[0065] S40, when the change rate of the target performance indicator of a certain application exceeds a preset threshold, marking the target performance indicator of the application as an abnormal state;

[0066] In this embodiment, the target performance indicator of each application (such as the number of service requests, average response time, failure rate, etc.) has been detected and compared with the preset threshold. When the calculated result of the change rate exceeds the preset threshold, it means that the target performance indicator of the application has undergone abnormal changes, which may affect the stability of the system and the normal operation of the business. Through the threshold detection module of the data comparison and monitoring system, the change rate of the target performance indicator of each application is continuously monitored. Once a certain change rate exceeds the preset threshold, the system will trigger the marking mechanism and record the abnormal information.

[0067] After confirming that the rate of change of a target performance indicator exceeds the preset threshold, the indicator needs to be marked as "abnormal state". The marking operation is used to record the detected abnormal state and provide a reference for subsequent processing steps. The abnormal state mark usually includes: the time when the abnormality occurred, the application name, the name of the target performance indicator, the rate of change exceeding the threshold and other information. The system's abnormal marking module is responsible for generating an abnormal marking record according to the preset rules. The record can be stored in the monitoring database, and the record content includes detailed information such as the application name, the name of the target performance indicator, the rate of change value, the preset threshold and the marking time. The marking operation can also trigger subsequent alarm mechanisms or automatic processing mechanisms.

[0068] Example: In a payment system in the financial industry, in order to ensure efficient processing of transactions, the system sets target performance indicators for key payment interfaces, such as the number of requests per second, average response time, and failure rate. During system operation, the performance monitoring platform monitors the change rate of these target performance indicators in real time. When the failure rate change rate of a payment interface exceeds the preset threshold of 1% within a certain period of time, the system automatically marks the failure rate of the payment interface as abnormal and records the time when the abnormality occurred, the application name, and the change rate value. At this point, the operation and maintenance team will conduct further analysis and optimization based on the marked abnormal status records to ensure the stability of the payment process and customer experience.

[0069] By marking abnormal status of target performance indicators that exceed preset thresholds, the system's performance anomalies can be recorded and identified in a timely manner. Anomalies can be automatically marked in real time, improving the efficiency and accuracy of anomaly detection. The system can trigger subsequent alarms and repair operations based on the marked information, ensuring that the system can respond and handle performance problems quickly when they occur, thereby improving the reliability and stability of the system.

[0070] S50, generating a corresponding abnormality repair plan based on the target performance indicator marked as an abnormal state;

[0071] In this embodiment, the target performance indicator marked as abnormal state refers to the performance indicator whose change rate has been detected to exceed the preset threshold and marked as abnormal by the system in the previous step. These indicators represent the parts of the system that may have performance problems, usually including the number of service requests, response time, failure rate, etc. When the system detects that the change rate of a certain target performance indicator exceeds the preset threshold, the abnormal marking mechanism will record the information of the abnormal state. These performance indicators marked as abnormal states will be stored in a special abnormal record database for use by the repair module.

[0072] Generate a set of targeted repair strategies or optimization plans based on the data characteristics and abnormal causes of the target performance indicators marked as abnormal. The generation of repair plans usually requires comprehensive analysis of the type of abnormal indicators, the severity of the abnormalities, and historical data to formulate appropriate repair measures. Repair plans may include adjusting system resources, optimizing code logic, adjusting database queries, redistributing loads, etc. The generation process of repair plans may include the following steps:

[0073] Abnormal analysis: Analyze the reasons for changes in target performance indicators based on abnormal marking records. The system can compare historical performance data with current data through data analysis models or preset rules to find possible factors that cause changes. For example, if the average response time increases abnormally, it may be because the SQL query performance has decreased or the system load is too high.

[0074] Generate strategy: Based on the analysis results, the system can generate a repair strategy based on the preset repair rules. For example, if it is detected that the number of service requests has increased sharply and caused the response time to increase, the repair strategy may include: adding load balancing nodes, optimizing database queries, expanding cache capacity, etc.

[0075] Optimization plan output: Generate a specific optimization plan based on the repair strategy. The plan content may include optimization steps, involved system components and expected effects, etc. The generated plan will be output and stored in the repair plan database.

[0076] Example: In a bank's core transaction system, when the system detects that the failure rate of a payment interface continues to increase and is marked as abnormal, the monitoring system will analyze the possible causes based on historical data and abnormal records. Assume that the analysis results show that the decline in database query efficiency is the main reason for the increase in response time. The system will automatically generate an optimization plan and recommend that the operation and maintenance team increase database indexes and optimize query logic to reduce response time. Through the generated repair plan, the operation and maintenance team can quickly locate the problem and implement optimization measures to ensure the smooth operation of the transaction system during peak hours.

[0077] By automatically analyzing target performance indicators marked as abnormal and generating corresponding repair plans, it is possible to respond to performance anomalies in a timely manner, improving the response speed and accuracy of repairs. By automating the repair plan generation process, the system can respond to complex business changes and performance issues more flexibly, effectively improving the overall system stability and user experience.

[0078] S60: Apply the abnormality repair solution to the production environment.

[0079] In this embodiment, after the abnormal repair plan for the target performance indicator is generated, the repair plan needs to be deployed and implemented in the production environment. This is to directly solve the marked abnormal performance problem and ensure the stable operation of the application. The process of applying the repair plan usually involves the execution, deployment and verification of the repair operation.

[0080] After the repair plan is generated, the system will perform repair operations according to the content of the plan. For example, optimizing a SQL query, adjusting the thread pool size of the server, adding cache, redistributing the load, etc. The deployment of the repair plan is usually automatically executed by the system, or manually implemented by the operation and maintenance team according to the content of the plan.

[0081] Some repair plans may involve updating system configurations, such as adjusting server resource allocation, updating load balancing configurations, etc. When implementing the repair plan, you need to simultaneously update the relevant system configurations to ensure that the repair measures are effective.

[0082] After the repair plan is applied, the system continues to monitor the repaired target performance indicators to verify the repair effect. This process may include recollecting the repaired performance data and comparing it with the previous data to check whether the repair measures have achieved the expected results.

[0083] After generating a repair plan in the performance monitoring platform, the system will automatically perform some optimization operations, such as adjusting the application's database connection pool size, updating SQL query statements, reallocating server resources, etc. After deploying the repair plan, the system will record the execution of the repair operation and continue to monitor key performance indicators to ensure the effectiveness of the optimization measures.

[0084] When the repair plan includes adding server resources or expanding cache capacity, the system will automatically generate a script for resource expansion and apply the repair plan to the production environment through automated deployment tools (such as Ansible, Chef, Kubernetes, etc.). After the application is completed, the system will re-collect the target performance indicator data of the repair and automatically verify the effect.

[0085] By automatically or manually applying the generated fix to the production environment, performance issues can be quickly fixed. After the fix is ​​completed, the system continues to monitor and verify the fix effect to ensure that the fix can effectively solve the performance anomaly.

[0086] The present invention relates to the fields of big data technology and financial technology, and discloses a performance monitoring and abnormality repair method, which obtains the performance data of multiple applications from a performance monitoring module in a production environment, and compares the performance data in adjacent time periods according to a preset time period to generate a change rate of a target performance indicator; detects whether the change rate of the target performance indicator exceeds a preset threshold, and marks the target performance indicator as an abnormal state when the threshold is exceeded; based on the target performance indicator in the abnormal state, generates an abnormality repair plan and applies it in a production environment. The present invention can significantly improve the real-time and accuracy of performance monitoring by dynamically collecting performance data of multiple applications, calculating the change rate of the target performance indicator in real time, and automatically detecting and marking abnormal states, generating corresponding repair plans and quickly applying them, realizing automatic detection and repair of abnormal problems, reducing human intervention, improving the stability and operating efficiency of the system, and effectively responding to performance changes in complex business environments.

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

[0088] S101, setting the collection frequency according to business requirements;

[0089] S102, determining multiple applications that need to be monitored based on historical performance data analysis;

[0090] S103, collecting execution data of the service interface of each application;

[0091] S104, collecting the execution data of SQL statements related to the service interface of each application;

[0092] S105: Classify and store the execution data of the service interface and the execution data of the SQL statement according to the application name.

[0093] In this embodiment, the collection frequency refers to the time interval at which the system regularly collects performance data. The collection frequency is set according to business needs to ensure that data collection can reflect the real-time status of the system without excessively occupying system resources. Business needs may include peaks and lows in transaction volume, system requirements for real-time performance, etc. The collection frequency is set through the configuration module of the monitoring system, and a scheduling tool (such as Cron Job or Quartz Scheduler) can be used to regularly trigger data collection tasks. For example, a collection frequency of once per minute is set for core applications, and a collection frequency of once per hour is set for non-core applications.

[0094] By analyzing historical performance data, determine which applications need to be included in the monitoring scope. Usually, focus on monitoring applications that have had performance anomalies in the past or are key business systems. The analysis includes indicators such as the number of service requests, response time, and failure rate of the application. Data analysis tools can be used to collect and analyze historical performance data, and combined with the business importance and the frequency of historical performance anomalies, determine the applications that need to be monitored. The analysis of historical data can be performed through the analysis module of the performance monitoring system (such as time series database analysis and machine learning analysis).

[0095] The execution data of the service interface refers to the number of service interface requests, response time, success rate and other information in the actual operation of each application. This data is collected to monitor the running status and performance of the service in real time. By deploying monitoring probes or data collection agents in each application, the execution data of each service interface is automatically collected. The collection methods can include log analysis, API calls, timed sampling, etc. The collected data is sent to the central monitoring system for further analysis.

[0096] The process of calling the application's service interface involves interactive operations with the database. Collecting the execution data of these SQL statements related to the service interface, including the number of SQL executions, time consumption, success rate, lock waiting time, etc., can provide a more comprehensive understanding of the application's performance bottlenecks. By deploying monitoring probes at the application's database access layer, or by using database audit tools (such as MySQL slow query logs, OracleAWR, etc.), SQL statement execution data is collected. The collection results are regularly uploaded to the monitoring platform through the data collection agent.

[0097] The collected data is classified and stored according to different applications for subsequent data analysis and processing. Classification storage can be based on the name or identifier of the application to ensure orderly organization and fast query of data. In the database of the central monitoring system, a data table or data storage structure classified by application is established. Data storage can be partitioned or indexed, and service interface data and SQL execution data can be stored in related tables respectively.

[0098] This embodiment can flexibly adjust the collection strategy to meet the monitoring needs of different business scenarios by setting the collection frequency according to business needs. At the same time, through historical data analysis, the applications that need to be monitored are determined, effectively reducing unnecessary system resource consumption. Classified collection of service interface data and SQL execution data, and orderly storage, make data management and analysis more efficient. The whole process builds a dynamic, flexible and accurate performance monitoring system, which provides strong support for the stability of the system and the continuous operation of the business.

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

[0100] S201, determining a current time period and a previous time period according to a preset time period;

[0101] S202, comparing the number of service requests in the current time period with the number of service requests in the previous time period, and analyzing the change rate of the number of service requests;

[0102] S203, comparing the average response time of the current time period with the average response time of the previous time period, and analyzing the change rate of the average response time;

[0103] S204, comparing the failure rate of the current time period with the failure rate of the previous time period, and analyzing the change rate of the failure rate.

[0104] In this embodiment, the preset time period refers to the time interval at which the system regularly collects and analyzes performance data, such as every hour, every day, or every week. In order to analyze the changes in performance indicators, it is necessary to divide the time into multiple consecutive cycles (such as the current cycle and the previous cycle) for data comparison. The time period for data collection and analysis is controlled by the system's time scheduling module (such as QuartzScheduler or Cron Job). For example, data is collected once a day at a fixed time, and these data are marked as "current cycle" and "previous cycle" respectively. The marking method can be a timestamp or a cycle number.

[0105] The number of service requests refers to the total number of requests processed by the system in each time period. By comparing the number of service requests in two adjacent time periods and calculating their change rate, it is used to measure whether the service request load of the application has changed significantly. The number of service requests collected in two periods is calculated using the following formula:

[0106] Service request number change rate = (number of requests in the current time period - number of requests in the previous time period) / number of requests in the previous time period. The system will store the service request number change rate calculation results in the monitoring database for subsequent analysis.

[0107] The average response time indicates the average time the system takes to process each request in each time period. By comparing the average response time of two time periods, the change rate is calculated to measure whether the performance of the application has changed. Based on the request response time data collected in each period, the average response time of each time period is calculated. Then, the average response time of the two time periods is compared, and the calculation formula is as follows:

[0108] Average response time change rate = (average response time of current time period - average response time of previous time period) / average response time of previous time period. The calculation results are stored in the database and used to generate a change rate report.

[0109] The failure rate refers to the proportion of requests that fail to be processed by the system in each time period. By comparing the failure rates of two time periods, the change rate is calculated to determine whether the success rate of the system has changed abnormally. Based on the collected data, the failure rate in each time period is calculated (the number of failed requests / the total number of requests). The failure rates of two time periods are compared, and the calculation formula is as follows:

[0110] Failure rate change rate = (failure rate of the current time period - failure rate of the previous time period) / failure rate of the previous time period. The system records the calculation results in the monitoring log for operation and maintenance personnel to monitor and analyze.

[0111] This embodiment can dynamically track the performance changes of applications and detect abnormal fluctuations in a timely manner by comparing the performance data of each application in adjacent time periods. By analyzing the change rate of service request times, average response time, and failure rate, it is possible to fully understand the changes in system load and response capabilities, and provide a reliable basis for subsequent abnormality detection and repair. The accuracy and sensitivity of monitoring are improved, and it can cope with situations where business changes are frequent.

[0112] In one embodiment, the above S30 includes:

[0113] S301, setting a corresponding preset threshold for the change rate of each target performance indicator according to historical performance data and business requirements, wherein the target performance indicator includes the number of service requests, average response time and failure rate;

[0114] S302, comparing the service request number change rate, average response time change rate and failure rate change rate with corresponding preset thresholds respectively;

[0115] S303: Determine whether there is any target performance indicator whose change rate exceeds a corresponding preset threshold.

[0116] In this embodiment, the preset threshold is a reference value for judging whether the rate of change of the target performance indicator is abnormal. The setting of the preset threshold is based on the statistical analysis of historical data and the specific needs of the business to ensure monitoring sensitivity while reducing false alarms. The fluctuation range and common change rate of each target performance indicator are extracted from the historical performance data. In combination with business needs, a reasonable change rate threshold is set. For example, the business system may hope that the change rate of response time is controlled within 5% and the change rate of failure rate is within 1%.

[0117] For each target performance indicator, calculate its change rate and compare these change rates with the corresponding preset thresholds. The purpose of this step is to detect whether there is a situation that exceeds the preset threshold to determine whether there is a performance anomaly. The system automatically extracts the change rate data of each target performance indicator from the monitoring database (such as the change rate of the number of service requests, the change rate of the average response time, and the change rate of the failure rate). Then, compare each change rate with its corresponding threshold. This comparison can be achieved through preset rules, such as:

[0118] If the service request times change rate > the preset threshold, the indicator is considered abnormal;

[0119] If the average response time change rate is greater than the preset threshold, the indicator is considered abnormal;

[0120] If the failure rate change rate > the preset threshold, the indicator is considered abnormal.

[0121] After comparing the change rates of all target performance indicators, the system needs to determine whether the change rate of any indicator exceeds its corresponding preset threshold. If there is a situation that exceeds the threshold, the system will record and trigger the exception handling process. By traversing the comparison results of each target performance indicator, check whether the condition of "change rate > preset threshold" is met. If so, the system will mark the performance indicator as abnormal and generate an abnormal status record for subsequent processing steps.

[0122] This embodiment can detect system performance anomalies in a timely manner by comparing the change rate of each target performance indicator with a preset threshold in real time. Through accurate threshold setting and real-time monitoring, false positives and missed positives are reduced, and the stability and performance reliability of the system are improved.

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

[0124] S401, when the change rate of any target performance indicator exceeds the corresponding preset threshold, marking the target performance indicator of the application as an abnormal state;

[0125] S402: Determine the severity level of the abnormal state according to the rate of change of the target performance indicator.

[0126] In this embodiment, when the system detects that the rate of change of a target performance indicator exceeds a preset threshold, the indicator needs to be marked as "abnormal state". This mark indicates that the system has detected that the indicator is abnormal and may require further analysis and processing. Target performance indicators may include the number of service requests, average response time, and failure rate. The system monitors the rate of change of each target performance indicator in real time, and automatically generates an abnormal mark when the rate of change exceeds the corresponding preset threshold. The content of the mark includes: application name, indicator name, rate of change value, threshold information, etc. This process is usually completed automatically by the anomaly detection module, and the results will be recorded in the anomaly log.

[0127] After marking as "abnormal state", the system needs to further determine the severity of the abnormality based on the size of the rate of change. The severity level is used to indicate the urgency of the abnormality, for example, it can be divided into "level 1", "level 2", "level 3", etc. The criteria for determining severity are usually based on the sensitivity of the business and the historical performance of the system. The system compares the rate of change of the target performance indicator that exceeds the threshold with the predefined grade standard. For example:

[0128] When the change rate is greater than 10%, it is marked as "Level 1 Severe";

[0129] When the rate of change is between 5% and 10%, it is marked as “Level 2 Severe”;

[0130] When the change rate is less than 5%, it is marked as "Level 3 Severity".

[0131] The system stores the severity information of each abnormal state together with other labeled data in the monitoring database for use in subsequent repair and optimization steps.

[0132] This embodiment can quickly identify and assess the urgency of abnormalities by marking abnormal states in real time and determining the severity level based on the rate of change. In this way, the operation and maintenance team can reasonably allocate resources and prioritize tasks based on the severity of the abnormality, reducing system downtime and business interruption risks. It can significantly improve the efficiency of system monitoring and abnormal response capabilities, ensuring efficient and stable operation of the system.

[0133] In one embodiment, the above S50 includes:

[0134] S501, assigning a processing priority to each target performance indicator data marked as abnormal according to the abnormality level of each target performance indicator;

[0135] S502, sending the abnormal data of the target performance indicator marked as abnormal state to the abnormal processing end in sequence according to the processing priority;

[0136] S503: Generate a corresponding exception repair plan for the target performance indicator data marked as an abnormal state through the exception processing end.

[0137] In this embodiment, after determining the abnormal state and severity of the target performance indicator, a corresponding processing priority is assigned to each abnormal mark according to different abnormal severity. Abnormal states with high severity will be assigned a higher processing priority so that they can be resolved as soon as possible. The system automatically assigns a processing priority to each performance indicator marked as an abnormal state based on the preset abnormality level and business rules. Generally, the processing priority can be divided into "high", "medium" and "low" levels. The allocation strategy can be based on the scope of impact of the abnormality, the urgency of the business, etc.

[0138] According to the processing priority of each abnormal state, the abnormal data is sent to the exception handling end in priority order. The exception handling end is a system module or team that is specifically responsible for generating repair plans. After the system assigns a processing priority to each abnormal state, it will package the data in the order of priority and send it to the exception handling end. The sending method can be implemented through message queues, API requests, or other data transmission mechanisms. After receiving the data, the exception handling end analyzes and repairs them one by one according to the priority.

[0139] After receiving the abnormal data, the exception handling end generates a corresponding repair plan based on the data type and abnormal information. The generation of the repair plan can be based on historical experience, predefined repair rules, or through automated analysis tools (such as AI models). After receiving the abnormal data, the exception handling end analyzes the specific content of the data (such as the size of the change rate, the cause of the abnormality, etc.) and selects an appropriate repair strategy. The repair plan may include adjusting system resources, optimizing database operations, increasing server load capacity, reconfiguring cache, etc.

[0140] In this embodiment, by assigning processing priorities according to the degree of abnormality, the system can reasonably allocate resources, give priority to high-severity abnormalities, and reduce the impact on the business. The abnormal data is sent to the abnormality processing end in sequence, achieving orderly and efficient data transmission. The abnormality processing end generates targeted repair solutions based on the abnormal data, improving the accuracy and automation level of the repair.

[0141] In one embodiment, after the above S60, the method further includes:

[0142] S701, recollecting performance data of the target performance indicator marked as abnormal from the performance monitoring module according to the preset collection frequency;

[0143] S702, analyzing the change rate of the target performance indicator marked as abnormal in the current adjacent time period based on the re-collected performance data;

[0144] S703, judging the effectiveness of the anomaly repair solution based on the change rate in the current adjacent time period;

[0145] S704: If the change rate of the target performance indicator in the current adjacent time period does not exceed the corresponding preset threshold, the abnormal state mark of the target performance indicator is removed.

[0146] In this embodiment, after the abnormal repair plan is applied, in order to monitor the repair effect, the system needs to re-collect the data of the target performance indicators that have been marked as abnormal according to the original collection frequency. The purpose of this step is to obtain the latest performance data to further evaluate the effectiveness of the repair measures. The performance monitoring module continues to collect data for all target performance indicators marked as abnormal according to the set collection frequency. The collected data includes the number of service requests, average response time, failure rate, etc. The system will store these data in the performance monitoring database.

[0147] Process and analyze the re-collected performance data and calculate the latest change rate of the target performance indicator. The purpose of this step is to compare the changes before and after the repair to determine whether the performance has returned to normal. The system extracts the re-collected performance data from the monitoring database and calculates the change rate of the number of service requests, the change rate of the average response time, and the change rate of the failure rate according to the previous method. The system compares these change rates with the change rates before the repair and records the latest change rate.

[0148] By analyzing the latest change rate after the repair, it is determined whether the applied abnormal repair plan is effective. The criterion for judging effectiveness is usually whether the change rate is lower than the preset threshold or whether there is a significant improvement. The system compares the re-collected change rate with the preset threshold. If the change rate drops below the preset threshold or is significantly reduced compared to the change rate before the repair, the repair plan is determined to be effective. The judgment result will be recorded in the system's repair record database.

[0149] If the latest change rate of the target performance indicator does not exceed the corresponding preset threshold after repair, it can be considered that the indicator has returned to normal, and the system needs to cancel the abnormal state mark. The system automatically checks the latest change rate of each target performance indicator marked as abnormal. If all change rates do not exceed the threshold, the corresponding abnormal state mark is removed. The system updates the status in the performance monitoring database and records the time and conditions for the abnormality to be eliminated.

[0150] Example description: In a bank's loan approval system, the system detected an abnormal response time of the approval interface and applied a repair solution of database index optimization. After the repair was completed, the system re-collected the average response time data of the interface at a collection frequency of every 10 minutes. The system calculated and compared the response time change rate in the current time period and found that the change rate dropped from 5% to 2%, which was lower than the preset 3% threshold. The system automatically canceled the abnormal mark of the interface and recorded the detailed information of the repair completion. This method helped the bank to repair performance bottlenecks in a timely manner and ensured the efficient operation of loan approval.

[0151] In this embodiment, by re-collecting and analyzing data after the application of the repair solution, the system can dynamically determine the effectiveness of the repair measures to ensure that the performance indicators return to normal after the repair. If the repair is effective, the system will automatically cancel the abnormal mark to avoid unnecessary alarms or repeated processing. This method improves the automation of performance exception processing, helps to ensure the stable operation of the system, and reduces the need for manual intervention.

[0152] In one embodiment, a performance monitoring and abnormality repair device is provided, and the performance monitoring and abnormality repair device corresponds one-to-one with the performance monitoring and abnormality repair method in the above embodiment. Figure 3 , Figure 3 This is a functional module diagram of a preferred embodiment of the performance monitoring and abnormality repair device of the present invention. Performance data collection module 10, data analysis module 20, abnormality judgment module 30, abnormality marking module 40, repair solution generation module 50 and repair solution application module 60. The functional modules are described in detail as follows:

[0153] The performance data collection module 10 is used to obtain the performance data of multiple applications from the performance monitoring module in the production environment according to a preset collection frequency;

[0154] The data analysis module 20 is used to compare the performance data of each application in adjacent time periods according to a preset time period, and generate a change rate of the target performance indicator of each application;

[0155] An abnormality judgment module 30 is used to detect whether the change rate of the target performance indicator of each application exceeds a preset threshold;

[0156] The abnormal marking module 40 is used to mark the target performance indicator of a certain application as an abnormal state when the change rate of the target performance indicator of the application exceeds a preset threshold;

[0157] A repair solution generating module 50, for generating a corresponding abnormality repair solution based on the target performance indicator marked as an abnormal state;

[0158] The repair solution application module 60 is used to apply the abnormal repair solution to the production environment.

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

[0160] Setting the collection frequency according to business needs;

[0161] Identify multiple applications that need to be monitored based on historical performance data analysis;

[0162] Collect execution data of each application's service interface;

[0163] Collect the execution data of SQL statements related to the service interface of each application;

[0164] The execution data of the service interface and the execution data of the SQL statement are classified and stored according to the application name.

[0165] In one embodiment, the data analysis module 20 is specifically used for:

[0166] According to the preset time period, determine the current time period and the previous time period;

[0167] Compare the number of service requests in the current time period with the number of service requests in the previous time period, and analyze the change rate of the number of service requests;

[0168] Compare the average response time of the current time period with the average response time of the previous time period, and analyze the change rate of the average response time;

[0169] The failure rate of the current time period is compared with the failure rate of the previous time period, and the change rate of the failure rate is analyzed.

[0170] In one embodiment, the abnormality determination module 30 is specifically used to:

[0171] According to historical performance data and business needs, a corresponding preset threshold is set for the change rate of each target performance indicator, wherein the target performance indicator includes the number of service requests, average response time and failure rate;

[0172] Compare the service request number change rate, average response time change rate and failure rate change rate with corresponding preset thresholds respectively;

[0173] Determine whether the change rate of any target performance indicator exceeds the corresponding preset threshold.

[0174] In one embodiment, the abnormality marking module 40 is specifically configured to:

[0175] When the change rate of any target performance indicator exceeds the corresponding preset threshold, marking the target performance indicator of the application as an abnormal state;

[0176] The severity level of the abnormal state is determined according to the magnitude of the rate of change of the target performance indicator.

[0177] In one embodiment, the repair solution generating module 50 is specifically configured to:

[0178] According to the abnormality level of each target performance indicator, a processing priority is assigned to each target performance indicator data marked as abnormal;

[0179] Sending the abnormal data of the target performance indicators marked as abnormal states to the abnormal processing end in sequence according to the processing priority;

[0180] The exception processing end generates a corresponding exception repair solution for the target performance indicator data marked as an abnormal state.

[0181] In one embodiment, the repair solution application module 60 is specifically used to:

[0182] According to the preset collection frequency, recollecting the performance data of the target performance indicator marked as abnormal from the performance monitoring module;

[0183] Based on the re-collected performance data, analyzing the change rate of the target performance indicator marked as abnormal in the current adjacent time period;

[0184] Based on the rate of change within the current adjacent time period, determining the effectiveness of the anomaly repair solution;

[0185] If the change rate of the target performance indicator in the current adjacent time period does not exceed the corresponding preset threshold, the abnormal state mark of the target performance indicator is eliminated.

[0186] 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 4 As 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 performance monitoring and abnormality repair method service side.

[0187] 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 on the user side of a performance monitoring and abnormality repair method

[0188] 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 when the processor executes the computer program, the following steps are implemented:

[0189] Obtain performance data of multiple applications from the performance monitoring module in the production environment according to the preset collection frequency;

[0190] According to the preset time period, the performance data of each application in adjacent time periods are compared to generate the change rate of the target performance indicator of each application;

[0191] Detect whether the change rate of the target performance indicator of each application exceeds a preset threshold;

[0192] When the change rate of a target performance indicator of an application exceeds a preset threshold, marking the target performance indicator of the application as an abnormal state;

[0193] Based on the target performance indicators marked as abnormal states, generate corresponding abnormality repair plans;

[0194] Apply the anomaly repair solution to the production environment.

[0195] 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:

[0196] Obtain performance data of multiple applications from the performance monitoring module in the production environment according to the preset collection frequency;

[0197] According to the preset time period, the performance data of each application in adjacent time periods are compared to generate the change rate of the target performance indicator of each application;

[0198] Detect whether the change rate of the target performance indicator of each application exceeds a preset threshold;

[0199] When the change rate of a target performance indicator of an application exceeds a preset threshold, marking the target performance indicator of the application as an abnormal state;

[0200] Based on the target performance indicators marked as abnormal states, generate corresponding abnormality repair plans;

[0201] Apply the anomaly repair solution to the production environment.

[0202] 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.

[0203] 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).

[0204] 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.

[0205] 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 performance monitoring and abnormality repair method, characterized in that: The following steps are involved: Obtain performance data of multiple applications from the performance monitoring module in the production environment according to the preset collection frequency; According to the preset time period, the performance data of each application in adjacent time periods are compared to generate the change rate of the target performance indicator of each application; Detect whether the change rate of the target performance indicator of each application exceeds a preset threshold; When the change rate of a target performance indicator of an application exceeds a preset threshold, marking the target performance indicator of the application as an abnormal state; Based on the target performance indicators marked as abnormal states, generate corresponding abnormality repair plans; Apply the anomaly repair solution to the production environment.

2. The performance monitoring and abnormality repair method according to claim 1, characterized in that: According to the preset collection frequency, the performance data of multiple applications is obtained from the performance monitoring module in the production environment, including: Setting the collection frequency according to business needs; Identify multiple applications that need to be monitored based on historical performance data analysis; Collect execution data of each application's service interface; Collect the execution data of SQL statements related to the service interface of each application; The execution data of the service interface and the execution data of the SQL statement are classified and stored according to the application name.

3. The performance monitoring and abnormality repair method according to claim 1, characterized in that: According to the preset time period, the performance data of each application in adjacent time periods are compared to generate the change rate of the target performance indicator of each application, including: According to the preset time period, determine the current time period and the previous time period; Compare the number of service requests in the current time period with the number of service requests in the previous time period, and analyze the change rate of the number of service requests; Compare the average response time of the current time period with the average response time of the previous time period, and analyze the change rate of the average response time; The failure rate of the current time period is compared with the failure rate of the previous time period, and the change rate of the failure rate is analyzed.

4. The performance monitoring and abnormality repair method according to claim 1, characterized in that: Detect whether the change rate of the target performance indicator of each application exceeds the preset threshold, including: According to historical performance data and business needs, a corresponding preset threshold is set for the change rate of each target performance indicator, wherein the target performance indicator includes the number of service requests, average response time and failure rate; Compare the service request number change rate, average response time change rate and failure rate change rate with corresponding preset thresholds respectively; Determine whether the change rate of any target performance indicator exceeds the corresponding preset threshold.

5. The performance monitoring and abnormality repair method according to claim 1, characterized in that: When the change rate of a target performance indicator of an application exceeds a preset threshold, marking the target performance indicator of the application as an abnormal state includes: When the change rate of any target performance indicator exceeds the corresponding preset threshold, marking the target performance indicator of the application as an abnormal state; The severity level of the abnormal state is determined according to the magnitude of the rate of change of the target performance indicator.

6. The performance monitoring and abnormality repair method according to claim 1, characterized in that: Based on the target performance indicators marked as abnormal, generate corresponding abnormal repair plans, including: According to the abnormality level of each target performance indicator, a processing priority is assigned to each target performance indicator data marked as abnormal; Sending the abnormal data of the target performance indicators marked as abnormal states to the abnormal processing end in sequence according to the processing priority; The exception processing end generates a corresponding exception repair solution for the target performance indicator data marked as an abnormal state.

7. The performance monitoring and abnormality repair method as claimed in claim 1, characterized in that: After the abnormal repair solution is applied to the production environment, the method further includes: According to the preset collection frequency, recollecting the performance data of the target performance indicator marked as abnormal from the performance monitoring module; Based on the re-collected performance data, analyzing the change rate of the target performance indicator marked as abnormal in the current adjacent time period; Based on the rate of change within the current adjacent time period, determining the effectiveness of the anomaly repair solution; If the change rate of the target performance indicator in the current adjacent time period does not exceed the corresponding preset threshold, the abnormal state mark of the target performance indicator is eliminated.

8. A performance monitoring and abnormality repair device, characterized in that: The performance monitoring and abnormality repair device comprises: The performance data collection module is used to obtain the performance data of multiple applications from the performance monitoring module in the production environment according to the preset collection frequency; A data analysis module is used to compare the performance data of each application in adjacent time periods according to a preset time period, and generate a change rate of the target performance indicator of each application; An abnormality judgment module is used to detect whether the change rate of the target performance indicator of each application exceeds a preset threshold; An abnormal marking module, used for marking the target performance indicator of an application as an abnormal state when the change rate of the target performance indicator of the application exceeds a preset threshold; A repair solution generation module, used to generate a corresponding abnormality repair solution based on the target performance indicator marked as an abnormal state; A repair solution application module is used to apply the abnormal repair solution to the production environment.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and a performance monitoring and exception repair program stored in the memory and executable on the processor. When the performance monitoring and exception repair program is executed by the processor, the steps of the performance monitoring and exception repair 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 performance monitoring and exception repair program, which, when executed by a processor, implements the steps of the performance monitoring and exception repair method according to any one of claims 1 to 7.

Images