Component monitoring method, system, and medium based on observability

Abstract

The application provides a component monitoring method and system based on observability, and a medium. The method comprises the following steps: obtaining a component type, configuring metadata based on the component type, associating a monitoring template, enabling the component type, and applying isolation configuration; collecting performance index data of the component based on collection parameters; querying corresponding performance index data based on a query request to obtain a query result; configuring a data source, a query expression, and a visualization type of a monitoring board to perform real-time display of the performance index data of the component; calculating a health score and abnormal situation information based on the query result, analyzing a health state level, and generating a diagnosis suggestion; obtaining multi-dimensional load indexes, calculating load values and a final load degree of each dimension, analyzing a load level, and generating load warning information; and performing multi-dimensional health evaluation through weighted scoring and abnormality detection, which can more accurately reflect the real health state of the component, reduce false positives and false negatives, and improve the accuracy of fault early warning.

Description

Technical Field

[0001] This application relates to the field of component monitoring technology, and more specifically, to a component monitoring method, system, and medium based on observability. Background Technology

[0002] Currently, information system operation and maintenance often uses observability products to monitor the operating status of various components (such as databases, message queues, caches, etc.) to understand the overall performance and health trends of the components.

[0003] In existing technologies, common component monitoring solutions include: Traditional monitoring tools, such as Zabbix and Nagios, collect component metrics through agents, but lack correlation with business context. Cloud-native monitoring solutions, such as the Prometheus + Grafana combination, support metric collection and visualization, but the component monitoring data is disconnected from business transactions; APM products, such as New Relic and Datadog, primarily focus on application-layer performance and have limited capabilities for in-depth monitoring of underlying components (such as databases and middleware).

[0004] Defects in existing technology: Existing component monitoring data is often completely disconnected from business transactions, making it difficult to accurately correlate component anomalies (such as database connection pool exhaustion or cache hit rate decline) with affected user operations during system fault diagnosis. Manual troubleshooting is inefficient and time-consuming. When making optimization decisions, it is impossible to clearly define the impact of component performance bottlenecks on business, which may lead to resource waste. When evaluating events, the inability to quantify the transaction failures or experience degradation caused by component failures makes it difficult to measure business losses.

[0005] Furthermore, existing technologies lack a unified component type management mechanism. Monitoring data for different components (MySQL, Redis, Kafka, etc.) are scattered across different systems, making it impossible to form a unified view of component health. Component health status assessments often rely on single indicator thresholds, failing to comprehensively consider multiple dimensions such as health level and load level for intelligent diagnosis. Summary of the Invention

[0006] The purpose of this application is to provide a component monitoring method, system, and medium based on observability. By performing multi-dimensional health assessment through weighted scoring and anomaly detection, it can more accurately reflect the true health status of components, reduce false alarms and missed alarms, and improve the accuracy of fault early warning.

[0007] This application also provides a component monitoring method based on observability, including the following steps: Obtain the component type, configure metadata based on the component type, associate it with the monitoring template, and enable and configure application isolation for the component type; Set the acquisition parameters, collect the component's performance metrics data based on the acquisition parameters, and report the performance metrics data to the Prometheus time series database. Receive query requests, query the corresponding performance metric data in the Prometheus time series database based on the query requests, and obtain the query results; Based on the associated monitoring template, a monitoring dashboard is generated, and the data source, query expression and visualization type of the monitoring dashboard are configured to display the performance index data of the components in real time. Based on the query results, calculate the health score and abnormal situation information, analyze the health status level, and generate diagnostic suggestions; Obtain multi-dimensional load metrics, calculate load values ​​and final load levels for each dimension, analyze load levels, and generate load warning messages.

[0008] Optionally, in the observability-based component monitoring method described in the embodiments of this application, the metadata includes type identifier, type name, type icon, type description, sorting weight, status identifier, component template association and application isolation identifier. Optionally, in the observability-based component monitoring method described in this application embodiment, collecting component performance index data based on acquisition parameters and reporting the performance index data to the Prometheus time-series database specifically includes: Configure basic data collection parameters, including component type, target component address, data collection port, and data collection account permissions; Configure data collection strategy parameters, including the collection cycle for regular indicators, the threshold for triggering sudden indicators, and the local cache duration. Configure the reporting parameters, including the Prometheus time series database address, reporting interface path, number of reporting retries and retry interval; Based on the collected basic parameters, collection strategy parameters, and reporting parameters, routine performance indicators are collected periodically using the Pull mode. After cleaning and format conversion, the collected performance index data is reported to the Prometheus time series database.

[0009] Optionally, in the component monitoring method based on observability described in this application embodiment, a weighted comprehensive scoring model is constructed based on a multi-dimensional health assessment algorithm using weighted scoring and anomaly detection. The calculation formula for the weighted comprehensive scoring model, based on the calculated health score and anomaly information, is as follows: HealthScore=Σ(Indicator_i×Weight_i×NormalizationFactor_i)×TimeDecayFactor; Where: Indicator_i represents the i-th health check indicator; Weight_i represents the indicator weight; NormalizationFactor_i represents the index normalization factor; TimeDecayFactor represents the time decay factor.

[0010] Optionally, in the observability-based component monitoring method described in this application embodiment, the rule for classifying the health status level is as follows: Health: Health score ≥ 80 with no serious abnormalities, all key indicators are normal, and the system is running stably; Good: Health score 60 ≤ Health score < 80 or there are 1-2 minor abnormalities. Overall operation is normal and there are performance indicators that can be optimized. General: A health score of 40 or less and less than 60, or the presence of 2-3 moderate anomalies, indicates a performance bottleneck and requires close monitoring. Danger: Health score <40 or serious anomalies indicate a serious problem with the system, affecting business operations and triggering a high-level alarm.

[0011] Optionally, in the observability-based component monitoring method described in this application embodiment, the load level is calculated based on a multidimensional resource weighted evaluation model. The formula for the multidimensional resource weighted evaluation model is as follows: LoadLevel = f(CPU_Load, Memory_Load, Connection_Load, QPS_Load, Trend_Load) where CPU_Load: based on CPU utilization; Memory_Load: based on memory utilization; Connection_Load: based on connection pool utilization; QPS_Load: based on the ratio of query QPS to peak QPS; Trend_Load: trend load factor. The final load level is calculated using a weighted geometric mean, as shown in the formula: LoadLevel = (CPU_Load^w1×Memory_Load^w2×Connection_Load^w3×QPS_Load^w4×Trend_Load^w5)^(1 / Σw); Where w1-w5 are the weights of the load metrics for each dimension. Secondly, embodiments of this application provide an observability-based component monitoring system, comprising: a memory and a processor, wherein the memory includes a program for an observability-based component monitoring method, and when the program for the observability-based component monitoring method is executed by the processor, it implements the following steps: Obtain the component type, configure metadata based on the component type, associate it with the monitoring template, and enable and configure application isolation for the component type; Set the acquisition parameters, collect the component's performance metrics data based on the acquisition parameters, and report the performance metrics data to the Prometheus time series database. Receive query requests, query the corresponding performance metric data in the Prometheus time series database based on the query requests, and obtain the query results; Based on the associated monitoring template, a monitoring dashboard is generated, and the data source, query expression and visualization type of the monitoring dashboard are configured to display the performance index data of the components in real time. Based on the query results, calculate the health score and abnormal situation information, analyze the health status level, and generate diagnostic suggestions; Obtain multi-dimensional load metrics, calculate load values ​​and final load levels for each dimension, analyze load levels, and generate load warning messages.

[0012] Optionally, in the observability-based component monitoring system described in this application embodiment, the metadata includes type identifier, type name, type icon, type description, sorting weight, status identifier, component template association, and application isolation identifier. Optionally, in the observability-based component monitoring system described in this application embodiment, the performance index data of the component is collected based on the acquisition parameters, and the performance index data is reported to the Prometheus time series database, specifically including: Configure basic data collection parameters, including component type, target component address, data collection port, and data collection account permissions; Configure data collection strategy parameters, including the collection cycle for regular indicators, the threshold for triggering sudden indicators, and the local cache duration. Configure the reporting parameters, including the Prometheus time series database address, reporting interface path, number of reporting retries and retry interval; Based on the collected basic parameters, collection strategy parameters, and reporting parameters, routine performance indicators are collected periodically using the Pull mode. After cleaning and format conversion, the collected performance index data is reported to the Prometheus time series database.

[0013] Thirdly, embodiments of this application also provide a computer-readable storage medium including an observability-based component monitoring method program, which, when executed by a processor, implements the steps of the observability-based component monitoring method as described in any of the preceding claims.

[0014] As can be seen from the above, the component monitoring method, system, and medium provided in this application embodiment obtain the component type, configure metadata based on the component type, and associate monitoring templates to enable and configure application isolation for the component type; set collection parameters, collect component performance index data based on the collection parameters, and report the performance index data to the Prometheus time-series database; receive query requests, query the corresponding performance index data in the Prometheus time-series database based on the query requests, and obtain query results; generate a monitoring dashboard based on the associated monitoring templates, configure the data source, query expression, and visualization type of the monitoring dashboard, and display the component performance index data in real time; calculate health scores and abnormal situation information based on the query results, analyze the health status level, and generate diagnostic suggestions; obtain multi-dimensional load indicators, calculate the load values ​​of each dimension and the final load level, analyze the load level, and generate load warning information; and perform multi-dimensional health assessment through weighted scoring and anomaly detection, which can more accurately reflect the true health status of components, reduce false alarms and false negatives, and improve the accuracy of fault warnings. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating the observability-based component monitoring method provided in this application embodiment; Figure 2 A flowchart illustrating the component type management process of the observability-based component monitoring method provided in this application embodiment; Figure 3 A flowchart of the health status assessment algorithm for the observability-based component monitoring method provided in this application embodiment; Figure 4 A flowchart of the load level calculation algorithm for the observability-based component monitoring method provided in this application embodiment; Figure 5 A block diagram of an observability-based component monitoring system provided in an embodiment of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0018] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0019] Please refer to Figures 1-4 As shown, this observability-based component monitoring method is used in a terminal device. The observability-based component monitoring method includes the following steps: S101: Obtain component type, configure metadata based on component type, associate with monitoring template, and enable component type and configure application isolation; S102, set the acquisition parameters, collect the performance index data of the component based on the acquisition parameters, and report the performance index data to the Prometheus time series database. S103, Receive query request, query the corresponding performance index data in the Prometheus time series database based on the query request, and obtain the query result; Specifically, this includes: receiving query requests from external modules, parsing the core parameters in the request, including component type, metric name, query time range, query precision, and filtering conditions; validating the parsed query parameters; if valid, proceeding to the next step; if valid, returning parameter error messages and correction suggestions; determining whether the query request is a high-frequency query; if it is a high-frequency query and the cache has not expired, directly retrieving the query results from the cache; if it is a low-frequency query or the cache has expired, calling the Prometheus Query API through the unified query interface to initiate a query request to the Prometheus time-series database; receiving the time-series metric data returned by Prometheus, formatting the data, and converting it into the JSON or table format required by the requesting module; analyzing the formatted query results, including metric trend analysis, outlier identification, metric statistical summary, and marking abnormal metrics that exceed the normal range and the time of their occurrence; returning the analyzed query results and anomaly marking information to the external module that initiated the query request, while storing high-frequency query results in the cache and updating the cache timestamp; and periodically cleaning up expired cached data and invalid query records to release system resources.

[0020] S104 generates a monitoring dashboard based on the associated monitoring template, configures the data source, query expression and visualization type of the monitoring dashboard, and displays the performance index data of the component in real time. S105: Calculate the health score and abnormal situation information based on the query results, analyze the health status level, and generate diagnostic suggestions; S106: Obtain multi-dimensional load metrics, calculate the load values ​​and final load levels for each dimension, analyze the load level, and generate load warning information.

[0021] According to an embodiment of the present invention, the metadata includes type identifier, type name, type icon, type description, sorting weight, status identifier, component template association and application isolation identifier. According to an embodiment of the present invention, performance index data of the acquisition component is collected based on acquisition parameters, and the performance index data is reported to the Prometheus time series database, specifically including: Configure basic data collection parameters, including component type, target component address, data collection port, and data collection account permissions; Configure data collection strategy parameters, including the collection cycle for regular indicators, the threshold for triggering sudden indicators, and the local cache duration. Configure the reporting parameters, including the Prometheus time series database address, reporting interface path, number of reporting retries and retry interval; Based on the collected basic parameters, collection strategy parameters, and reporting parameters, routine performance indicators are collected periodically using the Pull mode. After cleaning and format conversion, the collected performance index data is reported to the Prometheus time series database.

[0022] According to an embodiment of the present invention, a weighted comprehensive scoring model is constructed based on a multi-dimensional health assessment algorithm using weighted scoring and anomaly detection. The calculation formula for the weighted comprehensive scoring model, based on the calculated health score and anomaly information, is as follows: HealthScore=Σ(Indicator_i×Weight_i×NormalizationFactor_i)×TimeDecayFactor; Where: Indicator_i represents the i-th health check indicator; Weight_i represents the indicator weight; NormalizationFactor_i represents the index normalization factor; TimeDecayFactor represents the time decay factor.

[0023] According to an embodiment of the present invention, the rules for classifying health status levels are as follows: Health: Health score ≥ 80 with no serious abnormalities, all key indicators are normal, and the system is running stably; Good: Health score 60 ≤ Health score < 80 or there are 1-2 minor abnormalities. Overall operation is normal and there are performance indicators that can be optimized. General: A health score of 40 or less and less than 60, or the presence of 2-3 moderate anomalies, indicates a performance bottleneck and requires close monitoring. Danger: Health score <40 or serious anomalies indicate a serious problem with the system, affecting business operations and triggering a high-level alarm.

[0024] It's important to note that for each health check item, the system uses anomaly detection algorithms (such as statistical Z-score methods or machine learning-based anomaly detection) to dynamically calculate the anomaly threshold, rather than using a fixed threshold. When an indicator exceeds the dynamic threshold range, deductions are calculated based on the degree of deviation, ultimately generating a health score from 0 to 100. The health status level classification uses a fuzzy evaluation mechanism, and the system automatically generates diagnostic suggestions based on the health check results to help operations and maintenance personnel quickly locate problems and take optimization measures.

[0025] According to an embodiment of the present invention, the load level is calculated based on a multi-dimensional resource weighted evaluation model. The formula for the multi-dimensional resource weighted evaluation model is as follows: LoadLevel = f(CPU_Load, Memory_Load, Connection_Load, QPS_Load, Trend_Load), where CPU_Load is based on CPU usage rate; Memory_Load is based on memory usage rate; Connection_Load is based on connection pool usage rate; QPS_Load is based on the ratio of query QPS to peak QPS; Trend_Load is the trend load factor. The final load level is calculated using the weighted geometric mean, and the formula is: LoadLevel = (CPU_Load^w1 × Memory_Load^w2 × Connection_Load^w3 × QPS_Load^w4 × Trend_Load^w5)^(1 / Σw); where w1 - w5 are the weights of the load metrics for each dimension. It should be noted that the load level is divided by an adaptive threshold and dynamically adjusted based on the percentile of the historical load data distribution: Low load (LoadLevel < P25): The load is below the 25th percentile of the history. Medium load (P25 ≤ LoadLevel < P75): The load is between the 25th - 75th percentile of the history. High load (LoadLevel ≥ P75): The load is above the 75th percentile of the history and requires capacity expansion or optimization. At the same time, the system will generate load warning messages according to the load level, including specific resource bottleneck analysis and capacity expansion suggestions.

[0026] As Figure 5 shown, on the second aspect, the embodiment of the present application provides an observability - based component monitoring system, which includes: a memory and a processor. The memory includes a program for the observability - based component monitoring method. When the program for the observability - based component monitoring method is executed by the processor, the following steps are implemented: Obtain the component type, configure metadata based on the component type, associate a monitoring template, and perform enabling and application isolation configuration for the component type; Set the collection parameters, collect the performance metric data of the component based on the collection parameters, and report the performance metric data to the Prometheus time - series database; Receive a query request, query the corresponding performance metric data in the Prometheus time - series database based on the query request, and obtain the query result; Based on the associated monitoring template, a monitoring dashboard is generated, and the data source, query expression and visualization type of the monitoring dashboard are configured to display the performance index data of the components in real time. Based on the query results, calculate the health score and abnormal situation information, analyze the health status level, and generate diagnostic suggestions; Obtain multi-dimensional load metrics, calculate load values ​​and final load levels for each dimension, analyze load levels, and generate load warning messages.

[0027] It should be noted that the system includes the following components: Component Type Management Module: Supports unified management of various component types (database, message queue, cache, security components, AI models, computing power, etc.), employing a template-based component type configuration system. Each component type can be configured with the following metadata: Type ID and Type Name: Used to uniquely identify and display the component type. Type Icons: Supports custom icon resources for visual management of types; Type Description: Records a detailed description and purpose of the component type; Sort weight: Supports custom sorting, enabling flexible organization of type lists; Status indicator: Supports enabling / disabling status control to achieve type lifecycle management; Component Template Association: Each component type can be associated with multiple monitoring templates. The templates contain predefined metric panel configurations, health assessment rules, and load calculation algorithms. Application Isolation (AppID): Supports multi-tenant isolation, allowing different applications to have independent component type configurations; This module employs a three-tiered architecture—component type → component template → template details—to achieve standardized definition and personalized extension of component types. When creating a component instance, the system automatically loads the corresponding monitoring template based on the component type, quickly building a customized monitoring dashboard for the new instance. This solves the technical problems of scattered component type management and repetitive configuration in traditional monitoring systems.

[0028] The probe acquisition module is deployed on the target host via Agent Target to collect performance metrics of components (such as MySQL connection count, query QPS, InnoDB buffer pool hit rate, etc.) and report the metric data to the Prometheus time series database. The indicator query module, based on the Prometheus Query API, supports PromQL expression queries, enabling range queries (query_range), instant queries (query), and series queries, providing data sources for dashboards. Component Dashboard Module: Creates an independent monitoring dashboard for each component instance. The dashboard supports multi-panel configuration, and each panel can be configured with data source, query expression, and visualization type (time series chart, pie chart, statistics, etc.) to achieve personalized visualization of component metrics. Health status assessment module: It adopts a multi-dimensional health assessment algorithm based on weighted scoring and anomaly detection, rather than a simple threshold range judgment.

[0029] The business association module associates component monitoring data with the OpenTelemetry Trace context. It appends component performance metrics to the business call chain via TraceID, enabling end-to-end correlation analysis of "component anomaly - service call - user operation". Component performance metrics (such as database query time and cache hit rate) are appended to the Trace as Span Attributes. The Trace ID allows direct location of the associated business services and user operations (such as order payment requests) of the abnormal component, providing data support for precise business impact-oriented decision-making.

[0030] According to an embodiment of the present invention, the metadata includes type identifier, type name, type icon, type description, sorting weight, status identifier, component template association and application isolation identifier. According to an embodiment of the present invention, performance index data of the acquisition component is collected based on acquisition parameters, and the performance index data is reported to the Prometheus time series database, specifically including: Configure basic data collection parameters, including component type, target component address, data collection port, and data collection account permissions; Configure data collection strategy parameters, including the collection cycle for regular indicators, the threshold for triggering sudden indicators, and the local cache duration. Configure the reporting parameters, including the Prometheus time series database address, reporting interface path, number of reporting retries and retry interval; Based on the collected basic parameters, collection strategy parameters, and reporting parameters, routine performance indicators are collected periodically using the Pull mode. After cleaning and format conversion, the collected performance index data is reported to the Prometheus time series database.

[0031] In summary, the beneficial effects or advantages of the present invention are as follows: Unified component monitoring view: Through a hierarchical system of component type-dashboard-metrics, unified monitoring and management of various components such as MySQL, Redis, Kafka, and LLM is achieved, solving the problems of scattered component data and lack of a unified view, and improving operation and maintenance efficiency.

[0032] Intelligent health status assessment: Based on a weighted scoring model and anomaly detection algorithm, the multi-dimensional health assessment can more accurately reflect the true health status of components compared to a single threshold judgment, reducing false alarms and false negatives and improving the accuracy of fault warnings.

[0033] Accurate load identification: Employing a nonlinear load assessment algorithm based on multidimensional resource weighting and trend analysis, using weighted geometric mean and adaptive threshold division, it can more accurately identify component resource bottlenecks and provide a scientific basis for capacity expansion decisions.

[0034] Business-related fault location: By associating component monitoring data with business traces, when a component malfunctions, the affected business services and user operations can be quickly located, reducing troubleshooting time from hours to minutes and improving fault response efficiency.

[0035] Flexible indicator visualization: Based on the unified query interface of Prometheus and PromQL, it supports custom dashboard configuration. Operation and maintenance personnel can flexibly configure the monitoring panel according to business needs, which improves the adaptability and scalability of the monitoring system.

[0036] Reduce business losses: By quantifying the impact of component failures on business (such as "MySQL connection pool exhaustion caused 100 order payment failures"), the operations team can handle failures based on the priority of business impact, thereby reducing business losses.

[0037] A third aspect of the present invention provides a computer-readable storage medium including an observability-based component monitoring method program, which, when executed by a processor, implements the steps of the observability-based component monitoring method as described in any of the preceding claims.

[0038] This invention discloses a component monitoring method, system, and medium based on observability. It acquires component types, configures metadata based on component types, and associates monitoring templates to enable and configure application isolation for component types. It sets collection parameters, collects component performance metrics data based on these parameters, and reports the performance metrics data to a Prometheus time-series database. It receives query requests, queries the Prometheus time-series database for corresponding performance metrics data, and obtains query results. It generates a monitoring dashboard based on the associated monitoring templates, configures the data source, query expression, and visualization type of the dashboard, and displays the component's performance metrics data in real time. Based on the query results, it calculates health scores and anomaly information, analyzes health status levels, and generates diagnostic suggestions. It acquires multi-dimensional load metrics, calculates load values ​​for each dimension and the final load level, analyzes the load level, and generates load warning information. Through weighted scoring and anomaly detection, it performs multi-dimensional health assessment, which can more accurately reflect the true health status of components, reduce false alarms and false negatives, and improve the accuracy of fault warnings.

[0039] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0040] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0041] In addition, in the various embodiments of the present invention, each functional unit can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0042] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0043] Alternatively, if the integrated units of the present invention are implemented as software functional modules and sold or used as independent products, they can also be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

Claims

1. A component monitoring method based on observability, characterized in that, include: Obtain the component type, configure metadata based on the component type, associate it with the monitoring template, and enable and configure application isolation for the component type; Set the acquisition parameters, collect the component's performance metrics data based on the acquisition parameters, and report the performance metrics data to the Prometheus time series database. Receive query requests, query the corresponding performance metric data in the Prometheus time series database based on the query requests, and obtain the query results; Based on the associated monitoring template, a monitoring dashboard is generated, and the data source, query expression and visualization type of the monitoring dashboard are configured to display the performance index data of the components in real time. Based on the query results, calculate the health score and abnormal situation information, analyze the health status level, and generate diagnostic suggestions; Obtain multi-dimensional load metrics, calculate load values ​​and final load levels for each dimension, analyze load levels, and generate load warning messages.

2. The component monitoring method based on observability according to claim 1, characterized in that, The metadata includes type identifier, type name, type icon, type description, sorting weight, status identifier, component template association, and application isolation identifier.

3. The component monitoring method based on observability according to claim 2, characterized in that, Set the acquisition parameters, collect performance metric data of the component based on the acquisition parameters, and report the performance metric data to the Prometheus time series database. Specifically, this includes: Configure basic data collection parameters, including component type, target component address, data collection port, and data collection account permissions; Configure data collection strategy parameters, including the collection cycle for regular indicators, the threshold for triggering sudden indicators, and the local cache duration. Configure the reporting parameters, including the Prometheus time series database address, reporting interface path, number of reporting retries and retry interval; Based on the collected basic parameters, collection strategy parameters, and reporting parameters, routine performance indicators are collected periodically using the Pull mode. After cleaning and format conversion, the collected performance index data is reported to the Prometheus time series database.

4. The component monitoring method based on observability according to claim 3, characterized in that, A weighted comprehensive scoring model is constructed based on a multi-dimensional health assessment algorithm that incorporates weighted scoring and anomaly detection. The calculation formula for the weighted comprehensive scoring model, based on the calculated health score and anomaly information, is as follows: HealthScore=Σ(Indicator_i×Weight_i×NormalizationFactor_i)×TimeDecayFactor; Where: Indicator_i represents the i-th health check indicator; Weight_i represents the indicator weight; NormalizationFactor_i represents the index normalization factor; TimeDecayFactor represents the time decay factor.

5. The component monitoring method based on observability according to claim 4, characterized in that, The rules for classifying the health status levels are as follows: Health: Health score ≥ 80 with no serious abnormalities, all key indicators are normal, and the system is running stably; Good: Health score 60 ≤ Health score < 80 or there are 1-2 minor abnormalities. Overall operation is normal and there are performance indicators that can be optimized. generally A health score of 40 or less and a health score of less than 60, or the presence of 2-3 moderate anomalies, indicates a performance bottleneck and requires close monitoring. Danger: Health score <40 or serious anomalies indicate a serious problem with the system, affecting business operations and triggering a high-level alarm.

6. The component monitoring method based on observability according to claim 5, characterized in that, The load level is calculated based on a multidimensional resource weighted evaluation model. The formula for the multidimensional resource weighted evaluation model is as follows: LoadLevel = f(CPU_Load, Memory_Load, Connection_Load, QPS_Load, Trend_Load) where CPU_Load: based on CPU utilization; Memory_Load: based on memory utilization; Connection_Load: based on connection pool utilization; QPS_Load: based on the ratio of query QPS to peak QPS; Trend_Load: trend load factor. The final load level is calculated using a weighted geometric mean, as shown in the formula: LoadLevel = (CPU_Load^w1×Memory_Load^w2×Connection_Load^w3×QPS_Load^w4×Trend_Load^w5)^(1 / Σw); Where w1-w5 are the weights of the load metrics for each dimension.

7. A component monitoring system based on observability, characterized in that, The system includes: a memory and a processor, wherein the memory includes a program for an observability-based component monitoring method, and when the program for the observability-based component monitoring method is executed by the processor, it performs the following steps: Obtain the component type, configure metadata based on the component type, associate it with the monitoring template, and enable and configure application isolation for the component type; Set the acquisition parameters, collect the component's performance metrics data based on the acquisition parameters, and report the performance metrics data to the Prometheus time series database. Receive query requests, query the corresponding performance metric data in the Prometheus time series database based on the query requests, and obtain the query results; Based on the associated monitoring template, a monitoring dashboard is generated, and the data source, query expression and visualization type of the monitoring dashboard are configured to display the performance index data of the components in real time. Based on the query results, calculate the health score and abnormal situation information, analyze the health status level, and generate diagnostic suggestions; Obtain multi-dimensional load metrics, calculate load values ​​and final load levels for each dimension, analyze load levels, and generate load warning messages.

8. The component monitoring system based on observability according to claim 7, characterized in that, The metadata includes type identifier, type name, type icon, type description, sorting weight, status identifier, component template association, and application isolation identifier.

9. The component monitoring system based on observability according to claim 8, characterized in that, Based on the collected parameters, the performance metrics data of the component are collected and reported to the Prometheus time-series database. Specifically, this includes: Configure basic data collection parameters, including component type, target component address, data collection port, and data collection account permissions; Configure data collection strategy parameters, including the collection cycle for regular indicators, the threshold for triggering sudden indicators, and the local cache duration. Configure the reporting parameters, including the Prometheus time series database address, reporting interface path, number of reporting retries and retry interval; Based on the collected basic parameters, collection strategy parameters, and reporting parameters, routine performance indicators are collected periodically using the Pull mode. After cleaning and format conversion, the collected performance index data is reported to the Prometheus time series database.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes an observability-based component monitoring method program, which, when executed by a processor, implements the steps of the observability-based component monitoring method as described in any one of claims 1 to 6.

Images