Active intelligent operation and maintenance monitoring method for data medium station

Abstract

The invention belongs to the technical field of data processing, and discloses an active intelligent operation and maintenance monitoring method for a data center, which comprises the following steps: step 1, component modeling and topology configuration; 2, carrying out distributed health detection and data acquisition; 3, performing real-time health assessment and anomaly detection; 4, performing intelligent alarm and root cause analysis; 5, unified operation and maintenance and closed-loop control are carried out; and step 6, dynamically optimizing the intelligent operation and maintenance strategy. According to the method, a monitoring object and a dependency relationship are clarified through component modeling and topological configuration, and specific scenes, such as multi-mode acquisition, active detection, index pulling, log analysis, coverage message queue theme accumulation and database connection pool exhaustion, of distributed health detection are combined. The quantitative health score is calculated based on the preset scoring model, and by combining with the dynamic baseline learned by the ARIMA or LSTM algorithm, the module abnormity can be actively detected in different periods and weekly updating, and the problems of fault discovery lagging and incomplete monitoring coverage are solved.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of data processing, and specifically relates to an active intelligent operation and maintenance monitoring method for a data middle platform. BACKGROUND

[0002] With the acceleration of the enterprise digital transformation process, the data middle platform has become the core carrier for enterprises to carry out data integration, storage, calculation and service. It is usually composed of a large number of distributed components such as relational databases, columnar databases, Kafka message middleware, Spark distributed computing engines and API gateways. The health status of these components is directly related to the service stability and data quality of the data middle platform. However, the current operation and maintenance monitoring technology has the following significant shortcomings: first, fault discovery is lagging. Due to the lack of active monitoring mechanism, operation and maintenance personnel usually have to carry out fault troubleshooting passively after business feedback on data delay and report abnormalities. At this time, the fault has lasted for a period of time, which may cause business losses such as transaction data loss and decision delay. Second, it is difficult to locate the fault. There are complex dependency relationships between components, such as API service dependency on database and message middleware. When a fault occurs, manual inspection of multiple system logs and indicators is required, resulting in a long average repair time (MTTR), usually more than 30 minutes. Third, the monitoring coverage is not complete. Traditional monitoring focuses on server CPU, memory and other basic resources, and lacks professional monitoring means for data middle platform-specific scenarios such as message queue topic accumulation, database connection pool depletion and ETL task failure, which may miss critical abnormalities. Fourth, there is a lack of unified view and intelligent decision-making. There is no unified console to quantitatively evaluate the overall health of the data middle platform. Alarm information is scattered in various systems and is difficult to correlate and analyze. Daily inspection relies on manual work and cannot achieve automatic decision-making and processing. Fifth, the operation and maintenance strategy is fixed. The health check frequency, alarm threshold and root cause analysis logic of the existing monitoring method are statically configured and cannot be dynamically adjusted according to the fault rules of components and changes in business scenarios, resulting in over-monitoring or under-monitoring in some scenarios. Sixth, the algorithm adaptability is poor. Current time series analysis algorithms mostly use a single model without considering the volatility characteristics of different component indicators, resulting in large dynamic baseline prediction errors and prone to false alarms or missed alarms. Seventh, the root cause credibility is low. Root cause analysis only relies on link timing and does not verify historical fault data and correlation strength, resulting in large root cause determination bias in some scenarios and the need for manual secondary troubleshooting, which prolongs the fault handling time. Therefore, there is an urgent need for an active, accurate and intelligent operation and maintenance monitoring method to solve the above technical defects and improve the operation and maintenance efficiency and system reliability of the data middle platform. SUMMARY

[0003] The purpose of the present application is to provide an active intelligent operation and maintenance monitoring method for a data middle platform to solve the problems raised in the background art.

[0004] To achieve the above objectives, the present invention provides the following technical solution: a proactive intelligent operation and maintenance monitoring method for a data platform, the method comprising the following steps: Step 1: Component modeling and topology configuration. The configuration management center abstracts and defines the types of components to be monitored in the data platform, registers component instances and configures parameters, and builds the dependency topology between components. Step 2: Distributed health detection and data collection. The distributed detection scheduling engine generates health check tasks according to the configured frequency, distributes them to the detector nodes to perform multi-mode detection, and collects component health data. Step 3: Real-time health assessment and anomaly detection. Based on a preset scoring model, the collected data is normalized and weighted to obtain a quantitative health score. Combined with a dynamic baseline learned by a time series analysis algorithm, component anomalies are detected. Step 4: Intelligent alarm and root cause analysis. Based on the dependency topology, scattered alarms are aggregated into fault events, the root cause is inferred based on the dependency relationship chain, and alarm information is sent through multiple channels. Step 5: Unify operation and maintenance and closed-loop control, record full-link operation and maintenance logs, generate automated operation and maintenance reports, provide one-click full-stack detection function, and realize operation and maintenance closed loop; Step Six: Dynamic Optimization of Intelligent Operation and Maintenance Strategies. Based on historical operation and maintenance data, an operation and maintenance strategy optimization model is built. Through reinforcement learning algorithms, fault handling experience is continuously learned, and the frequency of health checks, alarm thresholds, and root cause analysis weights are dynamically adjusted. When the recurrence rate of a certain type of component fault exceeds a preset threshold, the frequency of health checks for that component is automatically increased, and the sensitivity of the corresponding alarm threshold is optimized.

[0005] Preferably, the abstract definition in step one specifically includes: defining the component type as at least one of data storage component, message middleware, and API service, with each component type associated with a corresponding health metric and detection method; the health metric includes component availability, response latency, and error rate, and the detection method includes database heartbeat detection query and message middleware connection status check; Meanwhile, for data storage components, data consistency verification metrics are included, which determine data consistency by comparing the data synchronization latency between master and slave points, data verification, and matching results; for message middleware, message delivery success rate metrics are included, which statistically analyze the percentage of successful delivery from the message producer to the consumer, and associate corresponding detection methods: the data storage component uses periodic data sampling verification, which is performed every 5 minutes, and the message middleware uses message trajectory tracking detection to record message flow nodes in real time.

[0006] Preferably, the construction of the dependency topology between components in step one specifically includes: automatically identifying the dependency relationships between component instances through manual input or a service discovery mechanism to form a visual service topology map; the service discovery mechanism includes real-time updating of dependency relationships based on instance status awareness of the registry center; It also includes a topology health assessment function, which calculates the "connectivity stability" of dependent links, counts the number of dependent link interruptions within 1 hour (required to be ≤1 time), and "data transmission efficiency", counts the average latency of data transmission between dependent components (required to be ≤500ms), and grades the dependent topology as excellent, good, or poor. When a dependent link is rated as "poor" for 3 consecutive times, it automatically triggers topology optimization suggestions, prompting operations and maintenance personnel to check network links or adjust component deployment locations.

[0007] Preferably, in step two, the health check task is generated using a scheduling strategy including at least one of hash scheduling, proximity scheduling, and failover; the hash scheduling ensures that the same component instance is handled by a fixed probe node, the proximity scheduling selects a probe node based on network latency, and the failover reallocates the task when a probe node is abnormal. It also includes load balancing scheduling strategies, which monitor the task execution load of each probe node in real time, including CPU utilization, memory usage, and task queue length. When the load of a node exceeds a preset threshold, new tasks are assigned to the node with the lowest load. At the same time, for data platform components deployed across regions, it includes region affinity scheduling, which prioritizes probe nodes located in the same region as the component to reduce cross-regional network transmission latency.

[0008] Preferably, the multi-mode detection in step two specifically includes: Actively probe by sending Ping requests, TCP port detection requests, and HTTP API call requests to assess component availability and response latency; Metrics retrieval involves capturing standardized metric interface data exposed by the component, including JVM memory usage, message queue depth, and number of active threads in the thread pool. Log analysis: Collect component error logs in real time or near real time, and discover potential anomalies by matching preset keywords with anomaly patterns; Business scenario-based probing: Customized probing solutions for common business scenarios of the data platform: In real-time data synchronization scenarios, simulate real data write requests to detect the synchronization time from the production end to the storage end; In offline ETL task scenarios, trigger mini ETL tasks at regular intervals to detect the task execution success rate and execution time; At the same time, log analysis includes anomaly log tracing function, which locates the dependency link node to which the anomaly log belongs by associating the component ID, timestamp and dependency topology in the log, to assist in quick troubleshooting.

[0009] Preferably, obtaining the quantified health score in step three specifically includes: normalizing the health index data to the [0,1] interval, and calculating a health score of [0,100] based on preset weights; the preset weights are configured according to the importance of the component business, wherein the availability weight of the data storage component is not less than 40%, and the response latency weight of the API service is not less than 30%; It also includes a dynamic adjustment mechanism for health scores, which adjusts weights based on the impact of recent component failures and peak business demand: when a component failure affects ≥5 downstream business systems, the weight of the component's health index is temporarily increased for 24 hours; during peak business periods, the response latency weight of API services is increased to 40%, and the availability weight of data storage components is increased to 50%; at the same time, a new "trend score" dimension is added to the health score, which calculates the slope of the health score change over the past hour and together with the current health score forms a "current score - trend score" dual-dimensional evaluation system.

[0010] Preferably, the time series analysis algorithm in step three includes at least one of the ARIMA algorithm and the LSTM algorithm; the dynamic baseline is the normal fluctuation range of the indicator under different time periods, and the baseline parameters are updated every 7 days; It also includes an algorithm adaptive selection mechanism, which automatically selects the optimal algorithm for each indicator by comparing the prediction errors of the ARIMA algorithm and the LSTM algorithm on different component indicators: for indicators with obvious periodic fluctuations, the ARIMA algorithm is selected first; for indicators with nonlinearity and strong abrupt changes, the LSTM algorithm is selected first; at the same time, the dynamic baseline includes abnormal scenario baseline compensation. When a sudden surge in business traffic or component expansion / contraction occurs, a "scenario-based baseline" is temporarily generated to avoid false alarms caused by environmental changes.

[0011] Preferably, step four, which aggregates scattered alarms into fault events based on the dependency topology, specifically includes: when ≥2 alarms from related components occur in the same time window, the alarms are merged into a single fault event based on the parent-child node relationship of the dependency topology; the alarm escalation strategy is: notify junior maintenance personnel if the abnormality persists for 5 minutes, and notify senior maintenance personnel if the abnormality persists for 10 minutes. It also includes an alarm priority classification mechanism, which divides alarm priorities into four levels: P0 (urgent), P1 (high), P2 (medium), and P3 (low) based on the business importance of the faulty component and the scope of the fault's impact. Different priorities correspond to different notification time limits and processing time limits: P0 level alarms require notification to the operations and maintenance manager within 1 minute and completion of preliminary investigation within 30 minutes; P1 level alarms require notification to senior operations and maintenance personnel within 3 minutes and completion of preliminary investigation within 1 hour. At the same time, the time window supports dynamic configuration and can be adjusted according to business scenarios.

[0012] Preferably, step four, which infers the root cause based on the dependency chain, specifically includes: traversing the reverse dependency chain of the dependency topology, identifying the component that first shows a decrease in health score, and determining that component as the root cause; if multiple components show a decrease in health score at the same time, the component at the bottom of the dependency chain is given priority as the root cause. It also includes root cause confidence assessment, which calculates the correlation strength and historical matching degree between the root cause component and other alarm components to give the root cause confidence. When the confidence is <60%, the "root cause verification task" is automatically triggered to further verify the root cause by simulating the suspension of the root cause component service or checking the key logs of the root cause component.

[0013] Preferably, step five of the one-click full-stack detection specifically includes: receiving detection instructions through the web interface of the operation and maintenance console, triggering all probe nodes to scan the data platform components in parallel, and generating a health report containing the health score of each component, a list of abnormal components, and repair suggestions within 10 seconds after the scan results are aggregated by streaming computing; the automated operation and maintenance report is generated at 2:00 AM every day, including the health score trend chart of the past 24 hours, abnormal event statistics, and component availability data; It also includes a customizable detection range function, allowing operations and maintenance personnel to customize the detection range by component type, business domain, or fault level, reducing the time spent on unnecessary detections; the health report adds a "Repair Solution Priority Sorting" function, which sorts solutions according to repair difficulty, repair time, and business impact, prioritizing "low-difficulty, short-time, and no-downtime" solutions; the automated operations and maintenance report adds a "Cross-Period Comparison Analysis" function, which compares the average health score and the number of abnormal events of this week with the same period of last week, and generates operations and maintenance optimization suggestions; at the same time, the report supports exporting to PDF / Excel format and can be configured to be automatically sent to a specified email address.

[0014] The beneficial effects of this invention are as follows: 1. This invention clarifies the monitoring objects and dependencies through component modeling and topology configuration. Combined with multi-mode data collection via distributed health probing, it proactively detects, pulls metrics, and analyzes logs, covering data platform-specific scenarios such as message queue topic backlog and database connection pool exhaustion. Based on a preset scoring model, a quantitative health score is calculated. Combined with a dynamic baseline learned using ARIMA or LSTM algorithms, and updated weekly across time periods, it proactively detects component anomalies, avoiding reliance on business feedback and resolving issues of delayed fault detection and incomplete monitoring coverage.

[0015] 2. This invention aggregates alarms from ≥2 related components within 5 minutes into a single fault event based on dependency topology, and escalates the alarm according to the duration of the anomaly. By traversing the reverse dependency chain, it identifies the component with the earliest declining health score, prioritizing the data storage layer component as the root cause. This reduces the workload of manually checking multiple system logs, shortens the mean time to repair (MTTR), and solves the problems of difficult troubleshooting and scattered alarm information.

[0016] 3. This invention records end-to-end operation and maintenance logs, provides one-click full-stack detection, and generates a report containing health score, anomaly list, and repair suggestions within 10 seconds. It also generates an automated report containing health score trends, anomaly statistics, and availability every morning. This enables a unified view to quantitatively assess the overall health of the data platform, replacing manual inspections, completing the operation and maintenance loop, and improving operation and maintenance efficiency and system reliability. 4. The adaptive algorithm selection, root cause confidence assessment, and dynamic optimization of operation and maintenance strategies of this invention solve the defects of poor algorithm adaptability, low root cause confidence, and rigid strategies in traditional monitoring. It enables operation and maintenance monitoring to have intelligent capabilities of "self-learning, self-optimization, and self-verification", adapting to the dynamic changes of data platform components and the diverse needs of business scenarios, further reducing operation and maintenance costs (reducing manual operation and maintenance workload by 40%) and improving the accuracy of fault handling (the root cause determination accuracy rate is increased to over 90%). Attached Figure Description

[0017] Fig. 1 This is a software flowchart of the present invention; Fig. 2 This is a flowchart illustrating the operation and maintenance monitoring method of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] like Figs. 1-2 As shown in the figure, this embodiment of the invention provides a proactive intelligent operation and maintenance monitoring method for a data platform, which includes the following steps: Step 1: Component Modeling and Topology Configuration The configuration management hub abstracts and defines the component types to be monitored in the data platform, registers component instances and configures parameters, and builds the dependency topology between components.

[0020] Abstract definition: Define the component type as at least one of data storage component, message middleware, and API service. Each component type is associated with a corresponding health metric and detection method. The health metric includes component availability, response latency, and error rate. The detection method includes database heartbeat detection query and message middleware connection status check.

[0021] Meanwhile, a data consistency verification index is adopted for the data storage component, which determines data consistency by comparing the data synchronization latency of master and slave nodes (required to be ≤100ms), data verification and matching results; a "message delivery success rate index" is adopted for the message middleware, which counts the percentage of successful delivery from the message producer to the consumer (required to be ≥99.99%), and associates it with corresponding detection methods - the data storage component adopts periodic data sampling verification (executed once every 5 minutes), and the message middleware adopts message trajectory tracking detection (real-time recording of message flow nodes), filling the gap in monitoring the core business attributes of the data middleware components.

[0022] Dependency topology construction: Dependencies between component instances are automatically identified through manual input or service discovery mechanisms to form a visual service topology graph; the service discovery mechanism includes instance status awareness based on the registry center and real-time updates of dependencies.

[0023] The topology health assessment function is used to classify dependent topologies (excellent, good, poor) by calculating the "connectivity stability" (the number of dependent links interrupted within 1 hour, with a requirement of ≤1 time) and "data transmission efficiency" (the average latency of data transmission between dependent components, with a requirement of ≤500ms). When a dependent link is assessed as "poor" for 3 consecutive times, topology optimization suggestions are automatically triggered, prompting maintenance personnel to check network links or adjust component deployment locations to avoid the spread of faults caused by potential problems with dependent links.

[0024] Step Two: Distributed Health Detection and Data Collection The distributed probe scheduling engine generates health check tasks at the configured frequency, distributes them to probe nodes to perform multi-mode probes, and collects component health data.

[0025] Scheduling strategy: The scheduling strategy adopted includes at least one of hash scheduling, proximity scheduling, and failover; the hash scheduling ensures that the same component instance is handled by a fixed probe node, the proximity scheduling selects the probe node based on network latency, and the failover reallocates tasks when the probe node is abnormal.

[0026] A "load balancing scheduling strategy" is adopted to monitor the task execution load of each probe node in real time (including CPU utilization, memory usage, and task queue length). When the load of a node exceeds a preset threshold (CPU utilization ≥ 70% or task queue length ≥ 50), new tasks are assigned to the node with the lowest load to avoid detection delays caused by single node overload. At the same time, for data platform components deployed across regions, "regional affinity scheduling" is adopted to prioritize probe nodes located in the same region as the component, reducing cross-regional network transmission latency (requiring cross-regional detection latency ≤ 200ms and same-region latency ≤ 50ms) and improving the timeliness of detection data.

[0027] Multi-mode detection: Active probing: Sending Ping requests, TCP port check requests, and HTTP API call requests to assess component availability and response latency; Metrics retrieval: Retrieve standardized metric interface data exposed by the component, including JVM memory usage, message queue depth, and number of active threads in the thread pool; Log analysis: Collect component error logs in real time or near real time, and discover potential anomalies by matching preset keywords with anomaly patterns.

[0028] 4. Business Scenario-Based Probes: Customized probe solutions are provided for common business scenarios of the data platform (such as real-time data synchronization, offline ETL tasks, and batch API calls). In real-time data synchronization scenarios, simulate real data write requests (10 data entries per second) to detect the synchronization time from the production end to the storage end (≤2 seconds required). In offline ETL task scenarios, trigger mini ETL tasks (1000 data entries) at regular intervals to detect the task execution success rate (≥100%) and execution time (≤5 minutes required), extending from "component monitoring" to "business scenario monitoring". At the same time, log analysis adopts the "abnormal log tracing function", which locates the dependency link node to which the abnormal log belongs by associating the component ID, timestamp and dependency topology in the log, and helps to quickly investigate the business impact scope corresponding to the log.

[0029] Step 3: Real-time health assessment and anomaly detection Based on a pre-defined scoring model, the collected data is normalized and weighted to obtain a quantitative health score. Combined with a dynamic baseline learned by a time series analysis algorithm, component anomalies are detected.

[0030] Quantitative health score calculation: The health index data is normalized to the range of [0,1], and a health score of [0,100] is calculated by weighting according to preset weights; the preset weights are configured according to the importance of the component business, wherein the availability weight of the data storage component is not less than 40%, and the response latency weight of the API service is not less than 30%.

[0031] A dynamic health score adjustment mechanism is adopted, which adjusts the weights based on the impact of recent component failures and peak business demand: When a component failure affects ≥5 downstream business systems, the weight of the component's health index is temporarily increased (up to 20%) for 24 hours to ensure that the health status of high-impact components receives priority attention; During peak business periods (such as e-commerce promotions and monthly report generation periods, which can be preset through configuration), the response latency weight of API services is increased to 40%, and the availability weight of data storage components is increased to 50%, matching the core business requirements for component performance; At the same time, the health score adopts a "trend score" dimension, which calculates the slope of the health score change over the past hour (e.g., a decrease of ≥5 points every 10 minutes is considered rapid deterioration), and together with the current health score, forms a "current score - trend score" dual-dimensional evaluation system (e.g., if the current score is 80 points but the trend score is "rapidly deteriorating", the overall evaluation is "warning status"), avoiding ignoring potential risks based solely on the current score.

[0032] Dynamic baseline and anomaly detection: The time series analysis algorithm includes at least one of the ARIMA algorithm and the LSTM algorithm; the dynamic baseline is the normal fluctuation range of the indicator under different time periods (weekdays, holidays, business peak periods), and the baseline parameters are updated every 7 days.

[0033] An "adaptive algorithm selection mechanism" is adopted. By comparing the prediction errors of the ARIMA and LSTM algorithms on different component metrics (using the root mean square error (RMSE) as the evaluation standard), the optimal algorithm is automatically selected for each metric: For metrics with obvious periodic fluctuations (such as daily API service visits), the ARIMA algorithm (RMSE ≤ 5%) is preferred, leveraging its accurate prediction capability for linear periodic data; for nonlinear and highly volatile metrics (such as message queue depth), the LSTM algorithm (RMSE ≤ 8%) is preferred, utilizing its deep learning characteristics to capture complex fluctuation patterns; at the same time, the dynamic baseline adopts "abnormal scenario baseline compensation". When a sudden surge in business traffic occurs (such as a 200% increase in traffic) or when a component is expanded / contracted, a temporary "scenario-based baseline" is generated (lasting for 2 hours after the scenario ends), avoiding false alarms caused by environmental changes and improving the accuracy of anomaly detection.

[0034] Step 4: Intelligent Alarms and Root Cause Analysis Based on the dependency topology, scattered alarms are aggregated into fault events, the root cause is inferred based on the dependency relationship chain, and alarm information is sent through multiple channels.

[0035] Alarm aggregation: When ≥2 alarms from related components occur within the same time window (within 5 minutes), the alarms are merged into a single fault event based on the parent-child node relationship of the dependency topology.

[0036] An "alarm priority grading mechanism" is adopted, which combines the business importance of the faulty component (e.g., the core transaction database is marked as P0 level, and non-core log storage is marked as P3 level) and the scope of the fault's impact (affecting ≥10 downstream systems is "large-scale impact", and <3 is "small-scale impact") to divide alarm priorities into four levels: P0 (urgent), P1 (high), P2 (medium), and P3 (low). Different priorities correspond to different notification timeliness and processing time limits: P0 level alarms require notification to the operations and maintenance manager within 1 minute and completion of preliminary investigation within 30 minutes; P1 level alarms require notification to senior operations and maintenance personnel within 3 minutes and completion of preliminary investigation within 1 hour to ensure that core faults are handled with priority. At the same time, the time window supports dynamic configuration and can be adjusted according to business scenarios (e.g., during peak business periods, the time window is shortened to 3 minutes to avoid the expansion of faults caused by alarm aggregation delays).

[0037] Alarm escalation strategy: Notify junior operations and maintenance personnel if the anomaly persists for 5 minutes, and notify senior operations and maintenance personnel if the anomaly persists for 10 minutes.

[0038] Root cause analysis: Traverse the reverse dependency chain of the dependency topology, identify the component that first shows a decrease in health score, and determine that component as the root cause; if multiple components show a decrease in health score at the same time, prioritize determining the component at the bottom of the dependency chain (data storage layer) as the root cause.

[0039] The system employs "root cause confidence assessment," calculating the "correlation strength" (e.g., after a root cause component fails, the trigger latency of downstream component alarms is ≤1 minute and the trigger rate is ≥90%) and "historical matching degree" (in the past, the component was the root cause in ≥70% of similar failures), to provide a root cause confidence score (e.g., high correlation strength + high historical matching degree, confidence score ≥90%; low correlation strength + low historical matching degree, confidence score ≤40%). When the confidence score is <60%, a "root cause verification task" is automatically triggered to further verify the root cause by simulating a pause of the root cause component service (in a non-production environment) or checking the key logs of the root cause component, reducing false positives. Simultaneously, for cloud-native deployed components, "container / virtual machine layer root cause tracing" is used. When a component alarms, the system automatically checks the resource limits of its container (whether CPU / memory exceeds quota) and the hardware status of the virtual machine (whether disk I / O and network bandwidth are abnormal), avoiding overlooking underlying resource failures and achieving three-layer root cause tracing: "component-container-virtual machine."

[0040] Step 5: Unified Operation and Closed-Loop Control Record end-to-end operation and maintenance logs, generate automated operation and maintenance reports, provide one-click full-stack detection function, and realize operation and maintenance closed loop.

[0041] One-click full-stack detection: Receive detection commands through the web interface of the operation and maintenance console, trigger all probe nodes to scan the data platform components in parallel, and generate a health report containing the health score of each component, a list of abnormal components, and repair suggestions within 10 seconds after the scan results are aggregated by streaming computing.

[0042] The "Custom Detection Scope" feature allows operations and maintenance personnel to customize the detection scope by component type (e.g., only detecting data storage components), business domain (e.g., only detecting transaction-related components), or fault level (e.g., only detecting components currently in an alarm state). This reduces the time spent on unnecessary detections (custom scope detection requires a report to be generated within 5 seconds), improving operational efficiency. The health report uses a "Repair Solution Priority Ranking" system, which prioritizes solutions based on repair difficulty (e.g., solutions that can be resolved by restarting the component are marked as "low difficulty," while those requiring code modification are marked as "high difficulty"), repair time (low difficulty requires ≤5 minutes, high difficulty requires ≤2 hours), and business impact (whether service interruption is required during repair). Solutions with "low difficulty, short time, and no service interruption" are given priority, assisting operations and maintenance personnel in making quick decisions.

[0043] Automated operation and maintenance reports: generated daily at 2:00 AM, including health trend charts, abnormal event statistics, and component availability data for the past 24 hours.

[0044] The system employs "cross-cycle comparative analysis" to compare the average health score of this week with the same period last week (an improvement of ≥2% is considered "optimization," and a decrease of ≥2% is considered "deterioration") and the number of abnormal events (a reduction of ≥10% is considered "optimization"). It also generates "Operation and Maintenance Optimization Suggestions" (e.g., if an increase in abnormal events is concentrated in a certain type of component, it is recommended to strengthen preventive inspections of that component). Furthermore, the reports can be exported to PDF / Excel format and can be configured to be automatically sent to a specified email address (e.g., the email address of the operations manager or technical director), enabling efficient synchronization and archiving of operation and maintenance data.

[0045] Step Six: Dynamic Optimization of Intelligent Operation and Maintenance Strategies. Based on historical operation and maintenance data, an operation and maintenance strategy optimization model is built. Through reinforcement learning algorithms, fault handling experience is continuously learned, and the frequency of health checks, alarm thresholds, and root cause analysis weights are dynamically adjusted.

[0046] Model building and training: A sample library was built based on the operation and maintenance data of the past 6 months (including fault type, handling solution, handling time and recurrence rate). The DQN (Deep Q Network) reinforcement learning algorithm was used to train and optimize the model. The model uses "shortest fault handling time" and "lowest recurrence rate" as objective functions. The model parameters were retrained after handling 100 faults to ensure that the model is adapted to the latest fault patterns.

[0047] Dynamic strategy adjustment: When the failure recurrence rate of a certain type of component exceeds a preset threshold (e.g., ≥3 recurrences per month), the health check frequency of that component will be automatically increased (up to 3 times the original frequency), and the sensitivity of the corresponding alarm threshold will be optimized (e.g., reducing the anomaly judgment deviation by 20%) to strengthen the monitoring of high-frequency failure components; when the failure recurrence rate of a certain type of component (e.g., Kafka message middleware) drops from 3 times per month to less than 1 time, its health check frequency will be automatically reduced to 70% of the original frequency to avoid resource waste.

[0048] Strategy Validation and Application: The strategy optimization results need to generate an "Optimization Report" to record the comparison of key indicators before and after optimization (such as inspection frequency, alarm threshold, recurrence rate, and processing time). It also supports maintenance personnel to manually confirm whether to apply the optimization strategy (it will be automatically applied if there is no rejection within 72 hours by default). It takes into account both intelligence and human controllability, forming an iterative closed loop of maintenance strategy of "data collection - model training - strategy optimization - effect verification".

[0049] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0050] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A proactive intelligent operation and maintenance monitoring method for a data platform, characterized in that: The method includes the following steps: Step 1: Component modeling and topology configuration. The configuration management center abstracts and defines the types of components to be monitored in the data platform, registers component instances and configures parameters, and builds the dependency topology between components. Step 2: Distributed health detection and data collection. The distributed detection scheduling engine generates health check tasks according to the configured frequency, distributes them to the detector nodes to perform multi-mode detection, and collects component health data. Step 3: Real-time health assessment and anomaly detection. Based on a preset scoring model, the collected data is normalized and weighted to obtain a quantitative health score. Combined with a dynamic baseline learned by a time series analysis algorithm, component anomalies are detected. Step 4: Intelligent alarm and root cause analysis. Based on the dependency topology, scattered alarms are aggregated into fault events, the root cause is inferred based on the dependency relationship chain, and alarm information is sent through multiple channels. Step 5: Unify operation and maintenance and closed-loop control, record full-link operation and maintenance logs, generate automated operation and maintenance reports, provide one-click full-stack detection function, and realize operation and maintenance closed loop; Step Six: Dynamic Optimization of Intelligent Operation and Maintenance Strategies. Based on historical operation and maintenance data, an operation and maintenance strategy optimization model is built. Through reinforcement learning algorithms, fault handling experience is continuously learned, and the frequency of health checks, alarm thresholds, and root cause analysis weights are dynamically adjusted. When the recurrence rate of a certain type of component fault exceeds a preset threshold, the frequency of health checks for that component is automatically increased, and the sensitivity of the corresponding alarm threshold is optimized.

2. The proactive intelligent operation and maintenance monitoring method for a data platform according to claim 1, characterized in that: The abstract definition in step one specifically includes: defining the component type as at least one of data storage component, message middleware, and API service, and associating each component type with corresponding health indicators and detection methods; the health indicators include component availability, response latency, and error rate, and the detection methods include database heartbeat detection query and message middleware connection status check; Meanwhile, for data storage components, data consistency verification metrics are included, which determine data consistency by comparing the data synchronization latency between master and slave points, data verification, and matching results; for message middleware, message delivery success rate metrics are included, which statistically analyze the percentage of successful delivery from the message producer to the consumer, and associate corresponding detection methods: the data storage component uses periodic data sampling verification, which is performed every 5 minutes, and the message middleware uses message trajectory tracking detection to record message flow nodes in real time.

3. The proactive intelligent operation and maintenance monitoring method for a data platform according to claim 1, characterized in that: Step one, constructing the dependency topology between components, specifically includes: automatically identifying the dependency relationships between component instances through manual input or a service discovery mechanism to form a visual service topology diagram; the service discovery mechanism includes instance status awareness based on a registry center and real-time updates of dependency relationships; It also includes a topology health assessment function, which calculates the connectivity stability of dependent links, counts the number of dependent link interruptions and data transmission efficiency within 1 hour, and counts the average data transmission latency between dependent components, and classifies dependent topologies as excellent, good, or poor; when a dependent link is assessed as "poor" for 3 consecutive times, it automatically triggers topology optimization suggestions, prompting operations and maintenance personnel to check network links or adjust component deployment locations.

4. The proactive intelligent operation and maintenance monitoring method for a data platform according to claim 1, characterized in that: In step two, a health check task is generated, and the scheduling strategy used includes at least one of hash scheduling, proximity scheduling, and failover. The hash scheduling ensures that the same component instance is handled by a fixed probe node, the proximity scheduling selects a probe node based on network latency, and the failover reallocates the task when a probe node is abnormal. It also includes load balancing scheduling strategies, which monitor the task execution load of each probe node in real time, including CPU utilization, memory usage, and task queue length. When the load of a node exceeds a preset threshold, new tasks are assigned to the node with the lowest load. At the same time, for data platform components deployed across regions, it includes region affinity scheduling, which prioritizes probe nodes located in the same region as the component to reduce cross-regional network transmission latency.

5. The proactive intelligent operation and maintenance monitoring method for a data platform according to claim 1, characterized in that: The multi-mode detection described in step two specifically includes: Actively probe by sending Ping requests, TCP port detection requests, and HTTP API call requests to assess component availability and response latency; Metrics retrieval involves capturing standardized metric interface data exposed by the component, including JVM memory usage, message queue depth, and number of active threads in the thread pool. Log analysis: Collect component error logs in real time or near real time, and discover potential anomalies by matching preset keywords with anomaly patterns; Business scenario-based probing: Customized probing solutions for common business scenarios of the data platform: In real-time data synchronization scenarios, simulate real data write requests to detect the synchronization time from the production end to the storage end; In offline ETL task scenarios, trigger mini ETL tasks at regular intervals to detect the task execution success rate and execution time; At the same time, log analysis includes anomaly log tracing function, which locates the dependency link node to which the anomaly log belongs by associating the component ID, timestamp and dependency topology in the log, to assist in quick troubleshooting.

6. The proactive intelligent operation and maintenance monitoring method for a data platform according to claim 1, characterized in that: Step three, obtaining the quantified health score, specifically includes: normalizing the health index data to the [0,1] range, and calculating a health score of [0,100] based on preset weights; the preset weights are configured according to the importance of the component business, wherein the availability weight of the data storage component is not less than 40%, and the response latency weight of the API service is not less than 30%; It also includes a dynamic adjustment mechanism for health scores, which adjusts weights based on the impact of recent component failures and peak business demand: when a component failure affects ≥5 downstream business systems, the weight of the component's health index is temporarily increased for 24 hours; during peak business periods, the response latency weight of API services is increased to 40%, and the availability weight of data storage components is increased to 50%; at the same time, a new "trend score" dimension is added to the health score, which calculates the slope of the health score change over the past hour and together with the current health score forms a "current score - trend score" dual-dimensional evaluation system.

7. The proactive intelligent operation and maintenance monitoring method for a data platform according to claim 1, characterized in that: The time series analysis algorithm in step three includes at least one of the ARIMA algorithm and the LSTM algorithm; the dynamic baseline is the normal fluctuation range of the indicator under different time periods, and the baseline parameters are updated every 7 days; It also includes an algorithm adaptive selection mechanism, which automatically selects the optimal algorithm for each indicator by comparing the prediction errors of the ARIMA algorithm and the LSTM algorithm on different component indicators: for indicators with obvious periodic fluctuations, the ARIMA algorithm is selected first; for indicators with nonlinearity and strong abrupt changes, the LSTM algorithm is selected first; at the same time, the dynamic baseline includes abnormal scenario baseline compensation. When a sudden surge in business traffic or component expansion / contraction occurs, a "scenario-based baseline" is temporarily generated to avoid false alarms caused by environmental changes.

8. The proactive intelligent operation and maintenance monitoring method for a data platform according to claim 1, characterized in that: Step four, which aggregates scattered alarms into fault events based on the dependency topology, specifically includes: when ≥2 alarms from related components occur in the same time window, the alarms are merged into a single fault event based on the parent-child node relationship of the dependency topology; the alarm escalation strategy is: notify junior maintenance personnel if the abnormality persists for 5 minutes, and notify senior maintenance personnel if the abnormality persists for 10 minutes. It also includes an alarm priority classification mechanism, which divides alarm priorities into four levels: P0 (urgent), P1 (high), P2 (medium), and P3 (low) based on the business importance of the faulty component and the scope of the fault's impact. Different priorities correspond to different notification time limits and processing time limits: P0 level alarms require notification to the operations and maintenance manager within 1 minute and completion of preliminary investigation within 30 minutes; P1 level alarms require notification to senior operations and maintenance personnel within 3 minutes and completion of preliminary investigation within 1 hour. At the same time, the time window supports dynamic configuration and can be adjusted according to business scenarios.

9. The proactive intelligent operation and maintenance monitoring method for a data platform according to claim 1, characterized in that: Step four, which involves inferring the root cause based on the dependency chain, specifically includes: traversing the reverse dependency chain of the dependency topology, identifying the component that first shows a decrease in health score, and determining that component as the root cause; if multiple components show a decrease in health score at the same time, the component at the bottom of the dependency chain is given priority as the root cause. It also includes root cause confidence assessment, which calculates the correlation strength and historical matching degree between the root cause component and other alarm components to give the root cause confidence. When the confidence is <60%, the "root cause verification task" is automatically triggered to further verify the root cause by simulating the suspension of the root cause component service or checking the key logs of the root cause component.

10. The proactive intelligent operation and maintenance monitoring method for a data platform according to claim 1, characterized in that: Step five, the one-click full-stack detection, specifically includes: receiving detection commands through the web interface of the operation and maintenance console, triggering all probe nodes to scan the data platform components in parallel, and generating a health report within 10 seconds after the scan results are aggregated by streaming computing, which includes the health score of each component, a list of abnormal components, and repair suggestions; the automated operation and maintenance report is generated at 2:00 AM every day, which includes the health score trend chart of the past 24 hours, abnormal event statistics, and component availability data; It also includes a custom detection range function, allowing operations and maintenance personnel to customize the detection range by component type, business domain, or fault level, shortening the time spent on unnecessary detections; the health report adds "Repair Solution Priority Sorting", which sorts the solutions according to repair difficulty, repair time, and business impact, prioritizing "low difficulty, short time, and no service interruption" solutions; the automated operations and maintenance report adds "Cross-Period Comparison Analysis", which compares the average health score and number of abnormal events of this week with the same period of last week, and generates operations and maintenance optimization suggestions; at the same time, the report supports exporting to PDF / Excel format and can be configured to be automatically sent to a specified email address.

Images