Automatic DB2 database monitoring method and system based on snapshot file

Abstract

The invention relates to the technical field of databases, provides a DB2 database automatic monitoring method and system based on a snapshot file, and realizes omnibearing monitoring coverage of the database. Compared with a traditional method, the method has the advantages that more than 300,000 operation indexes can be automatically extracted, and the monitoring comprehensiveness and the data fineness are remarkably improved. And secondly, through statistics and analysis of the historical operation data, different types of monitoring indexes can be automatically identified, and a scientific and reasonable threshold interval is set according to the type characteristics of the monitoring indexes, so that the subjectivity and randomness of traditional manual threshold setting are avoided, and the accuracy and consistency of database health state assessment are effectively improved. Finally, tens of thousands of indexes can be presented in an intuitive and logically clear mode by constructing a tree-shaped hierarchical index display model, and a user is supported to unfold, fold or screen the indexes according to a physical or logical structure of the DB2.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of database, and particularly relates to a DB2 database automatic monitoring method and system based on snapshot files. BACKGROUND

[0002] As a core basic component of various business systems, the health status of a database system directly determines the stability, reliability and performance level of the entire information system. With the continuous growth of enterprise informatization and data processing needs, databases play a key role in supporting transaction processing, data analysis and application services. Among them, DB2 databases are widely used in financial, telecommunications, government and large enterprise information systems due to their high reliability, high concurrency and rich transaction control mechanisms.

[0003] A DB2 database is composed of multiple functional modules, and there is a complex interdependence between these modules. The number of running states, configuration items and performance indicators is extremely large, covering CPU usage, buffer pool hit rate, I / O delay, transaction submission rate, lock waiting time, SQL execution statistics and other multi-dimensional data. Therefore, accurate and real-time evaluation and monitoring of the overall health status of the DB2 database has become an important challenge in database operation and management.

[0004] Currently, the industry mainly uses the following two methods to monitor DB2 databases: 1. External detection method, which indirectly reflects the running state of the database by simulating client transactions and periodically detecting response time, transaction results, etc. 2. Performance management view method, which uses the performance management view or monitoring table provided by the DB2 system to obtain part of the running indicator data to evaluate the performance.

[0005] Although the above-mentioned existing monitoring methods can reflect the running status of the database to some extent, they still have obvious deficiencies. First, the existing scheme usually relies on a small number of key indicators (such as CPU occupancy, connection number, lock waiting, etc.) preset by administrators, which cannot comprehensively cover the running status of all modules of DB2, making it difficult to find potential performance bottlenecks. Second, the selection of indicators, the acquisition period and the threshold setting often depend on the experience of operation and maintenance personnel, and lack of unified standards and automated means, resulting in unstable monitoring effect and unreasonable alarm threshold. Third, the existing technology cannot distinguish between indicators of different natures, making it difficult to achieve targeted and refined database health management.

[0006] In summary, the existing DB2 database cannot meet the high requirements of large-scale database systems in stability and performance guarantee. Therefore, there is an urgent need for a comprehensive database health evaluation method to achieve comprehensive and intelligent monitoring of the running status of the database. SUMMARY

[0007] The application provides a snapshot file-based DB2 database automatic monitoring method and system to solve the problems of insufficient monitoring range, manual experience-dependent index configuration and lack of intelligent classification in the existing DB2 database monitoring method. To solve the above technical problems, the application discloses the following technical scheme: One aspect of the application provides a snapshot file-based DB2 database automatic monitoring method, comprising: Based on the snapshot files generated at multiple time points, the data level of each running index of the DB2 database and the index values at the multiple time points are determined, and an index dataset is constructed; For each running index, the index values in the index dataset are statistically analyzed, and it is determined whether the statistical analysis result satisfies any one of a first preset condition, a second preset condition or a third preset condition, If yes, the index type of the running index is determined; Each running index is monitored by using a preset monitoring strategy corresponding to the index type thereof; A tree structure is constructed according to the data level and the monitoring result of all running indexes, and a monitoring index tree is output.

[0008] Optionally, before the step of determining the data level of each running index of the DB2 database and the index values at the multiple time points based on the snapshot files generated at the multiple time points and constructing the index dataset, the method further comprises: The snapshot files are periodically generated, the snapshot files are structured text files, and the snapshot files reflect the database state at the generation time, wherein the database state at least includes lock information, buffer pool hit rate, sorting condition, SQL execution statistics and table space state.

[0009] Optionally, the step of determining the data level of each running index of the DB2 database and the index values at the multiple time points based on the snapshot files generated at the multiple time points and constructing the index dataset comprises: For each running index, the data level is determined according to the number of spaces before the running index text in the snapshot file; The index dataset is constructed based on the corresponding data of each running index in each snapshot file, and each sample in the index dataset at least includes a running index name, an index value and a collection time.

[0010] Optionally, the step of statistically analyzing the index values in the index dataset for each running index comprises: For each running index, a plurality of data characteristics of the corresponding index value are counted, and the data characteristics at least include a value range distribution characteristic, a change frequency characteristic and a change mode characteristic.

[0011] Optionally, the judging whether the statistical analysis result meets any one of the first preset condition, the second preset condition or the third preset condition comprises: adopting a pre-trained classification model to determine whether the statistical analysis result meets the first preset condition, the second preset condition or the third preset condition.

[0012] Optionally, the determining the index type of the running index comprises: when the statistical analysis result of the running index meets the first preset condition, determining that the running index is a configuration type index, the first preset condition being that the index value is constant within a preset period; when the statistical analysis result of the running index meets the second preset condition, determining that the running index is a performance type index, the second preset condition being that the index value continuously changes within a preset range; when the statistical analysis result of the running index meets the third preset condition, determining that the running index is an event type index, the third preset condition being that the index value is a preset baseline value, or the index value returns to a preset baseline value after a sudden increase or decrease and the sudden increase or decrease is associated with any known event.

[0013] Optionally, the monitoring each running index by adopting a preset monitoring strategy corresponding to the index type of the running index comprises: when the running index is a configuration type index, monitoring by adopting a preset configuration type index strategy, and determining that the running index is abnormal when the current index value is different from the index value at the last monitoring; when the running index is a performance type index, monitoring by adopting a preset performance type index strategy, and determining that the running index is abnormal when the current index value is out of a preset running interval, the running interval being calculated based on historical index values within a preset period; when the running index is an event type index, monitoring by adopting a preset event type index strategy, and determining that the running index is abnormal when the current index value does not meet a preset event condition.

[0014] Optionally, the constructing a tree structure according to the data level and the monitoring result of all running indexes and outputting a monitoring index tree comprises: based on the data level of the running index, mounting each running index on a node in a preset tree hierarchical model to form a monitoring index tree; showing the monitoring index tree to a user and displaying a monitoring result corresponding to a selected running index of the user, the monitoring result at least including an index value and whether the index value is abnormal.

[0015] Optionally, the method further comprises: when a user performs a collection operation on any running index in the monitoring index tree, adding the running index and the monitoring result into a preset personal monitoring unit to construct a personal monitoring view of the user.

[0016] Another aspect of the present application provides a snapshot file-based DB2 database automatic monitoring system, which applies the snapshot file-based DB2 database automatic monitoring method provided in the foregoing aspect.

[0017] The snapshot file-based DB2 database automatic monitoring method and system disclosed in the present application realize all-around monitoring coverage of a database. Compared with the traditional external detection or performance view method relying on a small number of key indexes, the present application can automatically extract more than 300,000 running indexes, significantly improving the comprehensiveness of monitoring and the fineness of data, so as to more accurately reflect the overall running state of the database.

[0018] Secondly, the present application can automatically identify different types of monitoring indexes (such as performance indexes, configuration indexes, and event indexes) through statistical analysis of historical running data, and set scientific and reasonable threshold intervals according to the type characteristics, avoiding the subjectivity and randomness of the traditional manual threshold setting, and effectively improving the accuracy and consistency of the database health state evaluation.

[0019] In addition, the present application realizes the automation of the index extraction, classification and threshold setting process, greatly reduces the manual maintenance and configuration workload, and improves the efficiency and intelligent level of the database operation and maintenance management. The system can automatically complete the classification and priority determination of indexes, and dynamically display according to the user demand, so that the administrator can quickly locate the abnormal source and key performance bottleneck.

[0020] Finally, the present application builds a tree-shaped hierarchical index display model, so that tens of thousands of indexes can be presented in an intuitive and logically clear manner, supporting the user to expand, fold or filter indexes according to the physical or logical structure of DB2. This display method significantly improves the readability and interactive experience of the monitoring result, making the health management of the database more efficient, intuitive and intelligent.

[0021] The summary is provided to introduce a selection of concepts in a simplified form, which will be further described below in the detailed description. The summary is not intended to identify key or essential features of the disclosure, nor is it intended to limit the scope of the disclosure. BRIEF DESCRIPTION OF DRAWINGS

[0022] The above and other objects, features and advantages of the present application will become more apparent from the following detailed description when taken in conjunction with the accompanying drawings in which like reference characters refer to like parts throughout the figures, and in which:

[0023] Figure 1 A flowchart of a DB2 database automatic monitoring method based on snapshot files provided by an embodiment of the present application is shown in Figure 2 A flowchart of a method for implementing Figure 1 step S100 provided by an embodiment of the present application is shown in Figure 3 A flowchart of a method for monitoring according to a running index category provided by an embodiment of the present application is shown in Figure 4 A flowchart of a method for implementing Figure 1 step S500 provided by an embodiment of the present application is shown in DETAILED DESCRIPTION

[0024] Embodiments of the present disclosure will be described in more detail with reference to the drawings. Although embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided so that the present disclosure is more thorough and complete, and to fully convey the scope of the present disclosure to those skilled in the art.

[0025] The term "comprising" and variations thereof as used herein are intended to mean "including but not limited to". The term "or" as used herein is intended to mean "and / or". The term "based on" as used herein is intended to mean "based, at least in part, on". The term "one example embodiment" and "an embodiment" as used herein are intended to mean "at least one example embodiment". The term "another embodiment" as used herein is intended to mean "at least one additional embodiment". The terms "first", "second", and the like as used herein can refer to different or identical objects. Other explicit or implicit definitions can also be included below.

[0026] Figure 1 A flowchart of a DB2 database automatic monitoring method based on snapshot files provided by an embodiment of the present application is shown in Figure 1 The method includes the following steps: Step 100: Based on the snapshot files generated at multiple times, determine the data level of each running index of the DB2 database and the index value at multiple times, and construct an index dataset.

[0027] In one embodiment of the present disclosure, before step 100 is performed, snapshot files are generated in the DB2 database in a periodic trigger manner to collect the running state of the database at a specific time. The snapshot file is a structured text file that comprehensively reflects the real-time running information of the database, and at least includes core indexes such as lock information, buffer pool hit rate, sorting situation, SQL execution statistics, and table space state.

[0028] The generation of snapshot files can be achieved by executing system commands (e.g. "GET SNAPSHOT") of DB2 database or calling its management API. According to monitoring requirements, the monitoring range can be specified in the command, such as FOR DATABASE, FOR TABLESPACES, FOR LOCKS, FOR APPLICATIONS, FOR ALL, etc., so as to flexibly obtain running data of different levels and dimensions. The triggering mode of snapshot can be fixed period triggering (e.g. executed once every 5 minutes), or dynamically triggered by specific events (e.g. performance threshold exception, resource occupancy rate exceeding limit, etc.), so as to realize continuous and accurate monitoring of the running state of the database.

[0029] After the generation of snapshot files, a lightweight collection agent (Agent) deployed on the database server is automatically activated. The Agent automatically locates the generated snapshot files according to the predefined configuration parameters (such as file path, database connection information and collection period), and reads and preprocesses them. In order to guarantee the security and integrity of data transmission, the Agent sends the collected complete snapshot data to the processing and storage server of the log system through a secure network channel (such as SSH or HTTPS protocol). The server is responsible for parsing, archiving and subsequent index extraction of the received snapshot data.

[0030] In one embodiment of the present disclosure, as shown in Figure 2 The step 100 can be completed by the following steps: Step 101: For each running index, the number of spaces before the running index text in the snapshot file is determined to determine the data level.

[0031] The DB2 snapshot file is usually output in a structured text manner, in which the indexes of different levels are distinguished by the number of indentations (spaces). According to the format characteristics, the parent-child relationship between indexes can be accurately established: When there is no space at the beginning of the line, it indicates that the index is a root index, for example, Database Snapshot.

[0032] When there are two spaces in front, it indicates that the index is a child index, for example, Buffer Pool Data.

[0033] When there are four spaces in front, it indicates that the index is a grandchild index, for example, Hit Ratio.

[0034] The indexes of deeper levels can be extended in turn, and the number of spaces increases by two each time, representing a level deepening by one.

[0035] This indented structure constitutes a tree hierarchy, and each running indicator node has an inheritance relationship, thereby forming a complete "root-son-grandson" tree indicator system. By analyzing the structure, not only can the logical attribution relationship of the indicators be identified, but also a clear hierarchical basis can be provided for subsequent monitoring display and data aggregation.

[0036] Step 102: Based on the data corresponding to each running indicator in each snapshot file, an indicator dataset is constructed.

[0037] In the DB2 snapshot file, the name of each running indicator and the indicator value are separated by the symbol "=". The indicator name is in front of "=", and the indicator value is behind "=". Running indicator name: used to uniquely identify the name of the database running parameter.

[0038] Indicator value: the actual value of the indicator at the current snapshot time.

[0039] Collection time: used to mark the generation time point of the indicator value to support time series analysis.

[0040] In subsequent embodiments of the present application, an indicator type field is also added for each running indicator to distinguish indicators of different properties (such as configuration type, performance type, event type, etc.), providing a basis for subsequent automatic classification and monitoring strategy matching. Finally, the standardized data model formed can be described as: {indicator name, indicator type, indicator value, timestamp} After standardization, the system will batch write all the indicator data points obtained by parsing into a special time series database. This database structure is particularly suitable for processing a large amount of time-labeled data and can efficiently support long-period queries and statistics. As the snapshot collection continues, new indicator data will be continuously appended and written, realizing continuous accumulation and dynamic expansion of data. After weeks, months or even years of operation, a wide time span will be formed. An indicator dataset covering a wide time span will be formed.

[0041] Step 200: For each running indicator, statistical analysis is performed on the indicator values in the indicator dataset, and it is determined whether the statistical analysis result satisfies any one of the first preset condition, the second preset condition or the third preset condition.

[0042] In one embodiment disclosed in the present application, for each running indicator, a plurality of data characteristics of the corresponding indicator value are counted, and the data characteristics at least include a value range distribution characteristic, a change frequency characteristic and a change mode characteristic.

[0043] Specifically, the system periodically performs statistical calculation on each running indicator in the indicator dataset, and extracts multi-dimensional data features reflecting the change characteristics thereof. The embodiments of the present application classify these features into three categories: value range distribution features, change frequency features, and change pattern features.

[0044] Value range distribution features: used to measure the value range and fluctuation amplitude of the indicator, including maximum value, minimum value, average value, standard deviation, and quantile (such as P95, P99) and the like. These features can reflect the stability and volatility of the indicator in the long-term running process.

[0045] Change frequency features: used to measure the change activity degree of the indicator value, i.e., the number of changes of the indicator value per unit time. This feature can distinguish between static configuration indicators and performance indicators that change frequently.

[0046] Change pattern features: used to identify whether the change of the indicator has periodicity, burstiness, or event correlation. For example, some indicators may exhibit obvious daily periodic fluctuations (such as CPU utilization), while other indicators only exhibit step changes when specific events such as database restart, backup, or deadlock occur.

[0047] In one embodiment disclosed in the present application, a pre-trained classification model is used to determine whether the statistical analysis result meets the first preset condition, the second preset condition, or the third preset condition.

[0048] Specifically, after the above features are extracted, these multi-dimensional features are input into a preset classification rule engine or a lightweight machine learning model for automatic discrimination. In different embodiments, a rule-based decision tree model or an unsupervised clustering algorithm (such as K-Means) can be used to complete the indicator type identification. The core idea is to automatically determine the nature and role of the indicator in the database running system through the historical behavior features of the indicator.

[0049] The classification decision can be made according to the following three conditions: First preset condition: if the value of an indicator remains constant for a long period of time (for example, one week), it is considered to belong to a database static configuration item, such as buffer pool size, log file path, memory allocation upper limit, and the like. Such indicators generally only change when the system is reconfigured or restarted.

[0050] Second preset condition: if the value of an indicator continuously changes dynamically and fluctuates within a certain range, it reflects the system running performance, such as lock waiting time, buffer pool hit rate, SQL execution time consumption, and the like. Such indicators are the most important monitoring objects in system running.

[0051] The third precondition: If a certain indicator is at the baseline value or zero value most of the time, but suddenly spikes when a specific event (such as database deadlock, insufficient disk space, or log full) occurs, it is classified as an event-based indicator.

[0052] After the classification is completed, the system will attach the classification results to the corresponding operating metrics in the form of metadata tags. This tag can be used not only for subsequent monitoring strategy selection, but also to help users quickly distinguish the metric types in the visualization interface.

[0053] Furthermore, this invention proposes a continuous learning mechanism. Initially, an unsupervised clustering model can be used to automatically group the indicators, and then administrators can label the clustering results based on experience. As runtime increases, the classification model can be periodically retrained and optimized based on newly accumulated data to adapt to changes in database load patterns. For example, during system peak periods or after hardware upgrades, the fluctuation characteristics of performance indicators may change significantly, and the system can automatically adjust classification parameters to maintain the accuracy and timeliness of classification results.

[0054] Through the above mechanism, this invention can automatically identify the type characteristics of hundreds of thousands of operational indicators in the DB2 database without manual intervention, forming a scalable and learnable indicator classification system. This classification method based on historical features and machine learning significantly improves the intelligence level of the monitoring system.

[0055] If the statistical analysis results meet any one of the first, second, or third preset conditions, then proceed to step 300.

[0056] To enhance the reliability and adaptability of classification, a confidence level determination mechanism can be further introduced. When the statistical characteristics of a certain operational indicator do not fully meet any preset conditions, or its classification confidence level is lower than a threshold (e.g., 0.6), the operational indicator is temporarily marked as uncertain and enters the subsequent continuous learning or manual review process. As time goes by and data accumulates, the characteristics of these indicators can be re-analyzed and the classification results updated.

[0057] Step 300: Determine the indicator type for the operating indicators.

[0058] like Figure 3 As shown, when the statistical analysis results of the operating indicators meet the first preset condition, the operating indicators are determined to be configuration indicators.

[0059] The first preset condition is that the index value is constant within a preset period, i.e., the index value remains constant and has no significant change within a preset period (such as a week or a month). When the minimum value and the maximum value of an operation index within the period are completely consistent, or the change amplitude is lower than a preset threshold (such as 0.5%), it is indicated that the value of the index is stable and independent of the fluctuation during operation, and generally reflects the static configuration state of the database. Such an index is determined as a configuration index, for example, a buffer pool size, a log file path, a maximum number of connections, and the like. The main feature of the configuration index is that it can only change when the database is restarted, the parameters are adjusted, or the system is upgraded.

[0060] When the statistical analysis result of the operation index meets the second preset condition, the operation index is determined as a performance index. The second preset condition is that the index value continuously changes within a preset range, i.e., the index value continuously and dynamically changes during operation, and the fluctuation amplitude is within a preset reasonable interval. For example, the CPU usage, the lock waiting time, the buffer pool hit rate, and the SQL execution time are continuously fluctuated with the change of the system load, but no abnormal peak value occurs. The change trend of such an index has a certain regularity and predictability, and therefore is classified as a performance index. The performance index reflects the real-time operation health status of the database, and is the core object of performance optimization and abnormality detection. The system can set a dynamic threshold and an abnormality detection model according to the fluctuation trend, so as to realize fine-grained performance monitoring.

[0061] When the statistical analysis result of the operation index meets the third preset condition, the operation index is determined as an event index. The third preset condition is that the index value is a preset baseline value, or the index value returns to the preset baseline value after a sudden increase or decrease, and the sudden increase or decrease is associated with any known event. This condition is mainly used to identify indexes with burstiness or event-driven characteristics, i.e., the index value remains a certain baseline value (such as 0 or a fixed constant) most of the time, but a short-term dramatic fluctuation (sudden increase or decrease) occurs when a specific event occurs, and then returns to the original baseline value. Furthermore, if the sudden change behavior has a significant correlation with the database operation events (such as deadlocks, insufficient log space, backup start, connection exception, and the like) in time, the index is determined as an event index. For example, deadlocks detected is 0 most of the time, and becomes a non-zero value only when a deadlock occurs; log_full instantaneously increases when the log space is exhausted, and returns to 0 after recovery. The event index is usually used for alarm triggering and fault location, and can be linked with the system log to form an automatic early warning mechanism.

[0062] Step 400: For each operation index, a preset monitoring strategy corresponding to the type of the index is used for monitoring; After the running index type identification is completed (i.e., the classification results of the configuration class index, the performance class index, and the event class index are configured), the corresponding monitoring strategy is automatically matched according to the index category, the adaptive binding of the monitoring strategy is realized, and the monitoring process has dynamic adjustment and fine identification capabilities.

[0063] In one embodiment disclosed in the present application, as shown in Figure 3 (1) For the configuration class running index, the preset strategy focuses on identifying the stability and consistency of system configuration. Since such an index should remain constant under normal circumstances (for example, database version number, parameter configuration, path definition, etc.), whether there is an exception is determined by comparing the current collected value with the last recorded value. Once it is detected that the current index value is inconsistent with the last collected value, it is considered that the configuration has changed, triggering the "configuration has changed" alarm. This strategy can timely detect unauthorized configuration modification or parameter drift, and prevent inconsistency risks in the running environment.

[0064] (2) For the performance class running index, a monitoring strategy based on adaptive threshold of historical data is adopted. Specifically, first, the historical index data in the recent preset time window (for example, the last 30 days) is used to calculate the 5th percentile value (P5) and the 95th percentile value (P95) of the index, forming a dynamic running interval [P5, P95]. This interval can be updated with time, reflecting the fluctuation range of the index under normal conditions. When the current index value exceeds the running interval, or deviates from the interval for a certain period of time, it is determined that the running index has performance anomalies. For example, when the CPU usage is long-term higher than the historical normal upper limit, or the IO waiting time is significantly increased, performance alarms can be triggered. Through this adaptive interval judgment mechanism, there is no need to manually set a fixed threshold, and it can effectively cope with performance fluctuations in different business scenarios.

[0065] (3) For the event class running index, a fast detection strategy based on Boolean condition or counting threshold is adopted, which is used to identify sudden or critical events. Typical event class indexes include deadlocks detected (deadlock detected), log_full (log full), etc. The characteristics of such indexes are that most of the time they are in the baseline state (such as 0 or False), and only when a specific event occurs, they will instantaneously increase. In view of this characteristic, a simple and efficient event condition is set, for example: when the number of deadlocks is greater than 0 within 5 minutes, or the log usage rate is more than 90%, an abnormal event is immediately determined, and a serious alarm is triggered. This strategy can quickly respond in the early stage of failure, avoiding chain errors or data damage caused by delayed processing.

[0066] ​Furthermore, this invention also includes an alarm execution mechanism. Upon receiving real-time operational indicator data, it automatically compares it with the corresponding monitoring strategy. Once an indicator value is detected to violate preset conditions, an alarm workflow is triggered. This workflow can notify administrators in real time via various notification methods (including email, SMS, DingTalk, or the operations and maintenance management platform). Administrators can then quickly locate and respond to the issue, achieving fully automated closed-loop management from indicator collection, classification, monitoring to anomaly alarms.

[0067] Step 500: Construct a tree structure based on the data hierarchy and monitoring results of all operational metrics, and output the monitoring metric tree.

[0068] This step aims to construct a hierarchical tree structure model with semantic hierarchy based on the hierarchical relationships between operational metrics and their monitoring results, and output it in the form of a monitoring metric tree to achieve visualized management of the database system's operational status. Through this step, hundreds of thousands of operational metrics can be organized and presented according to logical hierarchy, enabling administrators to quickly understand and locate monitoring results in a structured manner, significantly improving monitoring readability and management efficiency.

[0069] In one embodiment of the present invention, such as Figure 4 As shown, step S500 can be implemented using the following method: Step S501: Based on the data hierarchy of the operational indicators, each operational indicator is attached to a node in the preset tree hierarchy model to form a monitoring indicator tree.

[0070] First, based on the indentation hierarchy information (data hierarchy) reflected in the snapshot file, the hierarchical position of each metric in the data structure is determined. In this embodiment, a tree-like hierarchical model corresponding to the database architecture is predefined. The root node of this model represents the database instance itself, which can contain multiple first-level child nodes, such as modules for memory, storage, connections, SQL execution, and lock management. Each module can be further subdivided into multi-level nested hierarchical structures. For example, under the memory module, it is further divided into buffer pool nodes, and under the buffer pool node, it contains specific pool objects, such as IBMDEFAULTBP. Subsequently, each operational metric is automatically mounted to the corresponding node position according to its semantics and source module, thus forming a complete and hierarchical monitoring metric tree. For example, the metric "bp_hit_ratio" (buffer pool hit rate) will be mounted under the path "Memory → Buffer Pool Node → IBMDEFAULTBP", while the metric "lock_waits" (lock wait count) will be mounted under the "Lock Management → Waits" node.

[0071] Step S502: Display the monitoring indicator tree to the user and show the monitoring results corresponding to the selected operating indicator.

[0072] The constructed monitoring index tree is output through a standardized interface. Specifically, structured data of the index tree can be provided to an external system through a RESTful API (RESTful application program interface), or can be displayed in an interactive visualization manner in a front-end user interface. A user can browse the index hierarchy by expanding or folding nodes, gradually deepening from the overall running state of the database to specific modules and specific indexes, and achieving hierarchical navigation from macro to micro. At the same time, on each node or index item, real-time monitoring result information is displayed, including the current index value, the latest collection time, whether an exception occurs, and the exception level, etc. If a certain index is monitored as an abnormal state, the node will be identified in the interface in a color highlight or icon prompt manner, facilitating the user to identify it immediately.

[0073] This hierarchical monitoring result display method fully matches the logical and physical organization structure of the database system, and can effectively solve the cognitive burden and management confusion problems caused by the "flat display" of a large number of indexes in traditional monitoring systems. Through the construction and output of the monitoring index tree, not only the orderly management of hundreds of thousands of running indexes is achieved, but also the monitoring results have good navigability and context traceability. Management personnel can intuitively master the overall health status of the database without complex searching, and can quickly locate the module and reason of the abnormal index along the hierarchical structure.

[0074] In summary, the embodiment of the application realizes the structured organization and visual output of multi-dimensional running data of the database system by constructing a monitoring index tree based on the running index hierarchy, greatly improving the understandability of monitoring information and the decision support capability. This tree-shaped index organization mode is not only suitable for DB2 databases, but also can be extended to the running state monitoring scenarios of other complex systems, such as large databases or distributed computing platforms like Oracle, PostgreSQL, etc., and has good universality and engineering application value.

[0075] In one embodiment of the present disclosure, further provided are personalized collection and customized monitoring functions based on the monitoring index tree, so that users can quickly construct monitoring views that meet their own focus. This function not only improves the human-computer interaction experience of the monitoring system, but also significantly improves the flexibility and efficiency of monitoring configuration.

[0076] Specifically, when the user browses the monitoring indicator tree in the front-end interface, the system provides an interactive favorite icon beside each indicator node, for example, in the form of a star or heart symbol. When the user clicks on the favorite icon, the system immediately records the operation and associates the user ID with the globally unique identifier of the running indicator through the interface call between the front-end and the back-end. The association information is stored in the user configuration database as the basic data for subsequent personalized monitoring view construction.

[0077] On this basis, the system provides a personal monitoring unit module for the user to centrally manage all the running indicators collected by the user. After entering the editing interface of the personal monitoring dashboard, the user can directly call and display the collected indicator data through the system's preset favorite folder component library. The favorite folder component is designed in a drag-and-drop interaction, and the user can drag any collected indicator from the component library to the dashboard canvas, thereby generating a corresponding visual display module, such as a value card, a line chart, a column chart, or an alarm indicator light. This mechanism greatly simplifies the building process of the personalized monitoring view, enabling the user to build a dedicated monitoring interface for a specific business or system module in a relatively short time.

[0078] In addition, to improve the flexibility of the monitoring experience, the application supports user-defined configuration of the collected indicators in the personal monitoring view. The user can assign priority labels to different collected indicators, and the system will prioritize the display of high-priority indicators when loading the dashboard, so as to quickly discover key performance changes or potential abnormalities.

[0079] Through the above-mentioned collection mechanism, the user can quickly aggregate the core indicators that they care most about in a view without manually searching from tens of thousands of indicators, thereby realizing personalized monitoring.

[0080] The embodiment of the application further provides a DB2 database automatic monitoring system based on snapshot files, which applies the DB2 database automatic monitoring method based on snapshot files provided by the foregoing embodiment, which will not be described here.

[0081] The above has described the embodiments of the present disclosure, and the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and changes are obvious to those skilled in the art without departing from the scope and spirit of the described embodiments. The selection of terms used herein is intended to best explain the principles, practical applications, or technical improvements of the technology in the market, or to enable other ordinary skilled persons in the art to understand the embodiments disclosed herein.

Claims

1. A method for automatic monitoring of a DB2 database based on snapshot files, characterized in that, The method comprises the following steps: determining the data level of each running index of the DB2 database and the index value at each time point based on the snapshot files generated at the time points, and constructing an index data set; statistically analyzing the index values in the index data set for each running index, and determining whether the statistical analysis result satisfies any one of a first preset condition, a second preset condition or a third preset condition; if yes, determining the index type of the running index; monitoring each running index by using a preset monitoring strategy corresponding to the index type of the running index; constructing a tree structure according to the data levels and monitoring results of all running indexes, and outputting a monitoring index tree.

2. The method of claim 1, wherein, Before the step of determining the data level of each running index of the DB2 database and the index value at each time point based on the snapshot files generated at the time points, and constructing an index data set, the method further comprises the following steps: periodically generating snapshot files, wherein the snapshot files are structured text files reflecting the database state at the time of generation, and the database state at least includes lock information, buffer pool hit rate, sorting condition, SQL execution statistics and table space state.

3. The method of claim 2, wherein, The step of determining the data level of each running index of the DB2 database and the index value at each time point based on the snapshot files generated at the time points, and constructing an index data set comprises the following steps: for each running index, determining the data level according to the number of spaces before the running index text in the snapshot file; constructing an index data set based on the data corresponding to each running index in each snapshot file, wherein each sample in the index data set at least includes the running index name, the index value and the collection time.

4. The method of claim 1, wherein, The step of statistically analyzing the index values in the index data set for each running index comprises the following steps: for each running index, statistically analyzing a plurality of data characteristics of the corresponding index value, wherein the data characteristics at least include the value range distribution characteristic, the change frequency characteristic and the change mode characteristic.

5. The method of claim 1, wherein, The step of determining whether the statistical analysis result satisfies any one of the first preset condition, the second preset condition or the third preset condition comprises the following steps: determining whether the statistical analysis result satisfies the first preset condition, the second preset condition or the third preset condition by using a pre-trained classification model.

6. The method of claim 1, wherein, The step of determining the index type of the running index comprises the following steps: when the statistical analysis result of the running index satisfies the first preset condition, determining that the running index is a configuration type index, wherein the first preset condition is that the index value is unchanged within a preset period; when the statistical analysis result of the running index satisfies the second preset condition, determining that the running index is a performance type index, wherein the second preset condition is that the index value continuously changes within a preset range; when the statistical analysis result of the running index satisfies the third preset condition, determining that the running index is an event type index, wherein the third preset condition is that the index value is a preset baseline value, or the index value returns to the preset baseline value after a sudden increase or sudden decrease and the sudden increase or sudden decrease is associated with any known event.

7. The method of claim 6, wherein, The step of monitoring each running index by using a preset monitoring strategy corresponding to the index type of the running index comprises the following steps: When the running index is a configuration class index, a preset configuration class index strategy is adopted for monitoring, and when the current index value is different from the index value at the last monitoring, it is determined that the running index is abnormal; When the running index is a performance class index, a preset performance class index strategy is adopted for monitoring, and when the current index value is beyond a preset running interval, it is determined that the running index is abnormal, and the running interval is calculated based on historical index values in a preset time period; When the running index is an event class index, a preset event class index strategy is adopted for monitoring, and when the current index value does not meet a preset event condition, it is determined that the running index is abnormal.

8. The method of claim 7, wherein, The tree structure is constructed according to the data level and the monitoring result of all the running indexes, and a monitoring index tree is output, including: Based on the data level of the running index, each running index is mounted on a node in a preset tree hierarchical model to form a monitoring index tree; The monitoring index tree is displayed to the user, and the monitoring result corresponding to the selected running index of the user is displayed, and the monitoring result at least includes an index value and whether an abnormality occurs.

9. The method of claim 1, wherein, The method further includes: When the user performs a collection operation on any running index in the monitoring index tree, the running index and the monitoring result are added to a preset personal monitoring unit to construct a personal monitoring view of the user.

10. A DB2 database automatic monitoring system based on snapshot files, characterized in that, The system applies the DB2 database automatic monitoring method based on the snapshot file according to any one of claims 1 to 9.

Images