Distributed system data management method and device

Abstract

The invention provides a distributed system data management method and device, and relates to the technical field of computer networks, and the method comprises the steps: reading initial data from Prometheus through Thanos side; the initial data is queried from the Thanos side through a Thanos query, and the queried initial data is aggregated, so that target data is obtained; and querying the target data from the Thanos query through Grafana and / or the navigation control module, and displaying the queried target data. Through close integration of Thanos side and Promethus, comprehensive management and efficient utilization of monitoring data are realized, initial data can be read from Promethus, aggregation processing is carried out through Thanos query to obtain target data, and display can be carried out through Grafana and other visual tools, so that data monitoring and analysis become more visual and convenient.

Description

Technical Field

[0001] The present invention relates to the field of computer network technology, and in particular to a distributed system data management method and device. Background Art

[0002] In the field of modern information technology, distributed systems have become the core architecture for data processing and storage. With the rapid development of cloud computing, the Internet of Things (IoT) and big data technology, distributed systems are increasingly shouldering the heavy responsibility of data processing for key business of enterprises. However, existing monitoring systems (such as those based on Prometheus and Grafana) still have many shortcomings in data management, especially in data query, alarm management and visualization. In terms of data query, there is a lack of a unified interface for data query between multiple Prometheus instances, which makes the data query process complex and difficult to expand. In addition, the non-standardization of label design also brings serious problems. Once the label is modified, historical data will be difficult to trace and query uniformly, thus affecting the integrity and availability of the data. In terms of alarm management, the existing system lacks native API support, making the alarm configuration process complex and the response delay high. At the same time, the effective recording of alarm historical data has also become a problem, which makes audit and analysis difficult, and thus affects the stability and reliability of the system. In terms of visualization, although Grafana provides a variety of chart types, its flexibility is still limited and it is difficult to meet the embedding requirements of complex business logic. In addition, the integration of Grafana with the UI of existing systems also faces challenges, which limits the scalability of the system.

[0003] Therefore, a distributed system data management method and device are proposed. Summary of the invention

[0004] This specification provides a distributed system data management method and device, which realizes comprehensive management and efficient use of monitoring data through the close integration of Thanos sidecar and Prometheus. It can not only read the initial data from Prometheus and perform aggregation processing through Thanos query to obtain the target data, but also display it through visualization tools such as Grafana, making data monitoring and analysis more intuitive and convenient.

[0005] This specification provides a distributed system data management method, including:

[0006] Read initial data from Prometheus via Thanos sidecar;

[0007] Query the initial data from the Thanos sidecar through Thanos query, and aggregate the queried initial data to obtain target data;

[0008] The target data is queried from the Thanos query through Grafana and / or the navigation control module, and the queried target data is displayed.

[0009] Optionally, also include:

[0010] Query the target data from Thanos query and / or Postgre SQL through the Metric proxy, and replace the label of the target data with a unique identifier;

[0011] The target data carrying the unique identifier is displayed through the Grafana and / or the navigation control module.

[0012] Optionally, also include:

[0013] Receiving the alarm information pushed by the Prometheus through the Metric proxy, and / or querying the target data from the Postgre SQL, and replacing the labels of the alarm information and / or the target data with unique identifiers;

[0014] The alert information carrying the unique identifier and / or the target data carrying the unique identifier are processed by an Alert manager.

[0015] Optionally, also include:

[0016] Pull incremental data from the Prometheus periodically through the Thanos sidecar;

[0017] The incremental data is checked for consistency through the Thanos sidecar, and when the incremental data satisfies the consistency check, the incremental data is updated to local storage.

[0018] Optionally, performing a consistency check on the incremental data by the Thanos sidecar, and updating the incremental data to local storage when the incremental data satisfies the consistency check, includes:

[0019] Get the timestamp and version number of the incremental data;

[0020] Determine the sequence and update range of the incremental data based on the timestamp and version number;

[0021] Performing a hash value check on the incremental data to determine whether the incremental data is changed or damaged;

[0022] When it is determined that the incremental data has not been changed or damaged, the incremental data is updated to local storage according to the sequence and update range of the incremental data.

[0023] Optionally, performing a consistency check on the incremental data by the Thanos sidecar, and updating the incremental data to local storage when the incremental data satisfies the consistency check, further includes:

[0024] When it is determined that the incremental data is changed or damaged, the changed or damaged data block is pulled from Prometheus through the Thanos sidecar and replaced, and an error log is recorded.

[0025] Optionally, the unique identifier includes a unique identifier generated by a UUID algorithm.

[0026] This specification provides a distributed system data management device, including: a central controller and several hub controllers; the central controller includes Grafana, a navigation control module, and Thanos query; the hub controller includes Thanos sidecar and Prometheus;

[0027] Read initial data from the Prometheus via the Thanos sidecar;

[0028] Querying the initial data from the Thanos sidecar through the Thanos query, and aggregating the queried initial data to obtain target data;

[0029] The target data is queried from the Thanos query through the Grafana and / or the navigation control module, and the queried target data is displayed.

[0030] Optionally, also include:

[0031] The central controller also includes Metric proxy and Postgre SQL;

[0032] Querying the target data from the Thanos query and / or the Postgre SQL through the Metric proxy, and replacing the label of the target data with a unique identifier;

[0033] The target data carrying the unique identifier is displayed through the Grafana and / or the navigation control module.

[0034] Optionally, also include:

[0035] The central controller also includes an Alert manager;

[0036] Receiving the alarm information pushed by the Prometheus through the Metric proxy, and / or querying the target data from the Postgre SQL, and replacing the labels of the alarm information and / or the target data with unique identifiers;

[0037] The alert information carrying the unique identifier and / or the target data carrying the unique identifier are processed by an Alert manager.

[0038] Optionally, also include:

[0039] Pull incremental data from the Prometheus periodically through the Thanos sidecar;

[0040] The incremental data is checked for consistency through the Thanos sidecar, and when the incremental data satisfies the consistency check, the incremental data is updated to local storage.

[0041] Optionally, performing consistency check on the incremental data by the Thanos sidecar, and updating the incremental data to local storage when the incremental data satisfies the consistency check, includes:

[0042] Get the timestamp and version number of the incremental data;

[0043] Determine the sequence and update range of the incremental data based on the timestamp and version number;

[0044] Performing a hash value check on the incremental data to determine whether the incremental data is changed or damaged;

[0045] When it is determined that the incremental data has not been changed or damaged, the incremental data is updated to local storage according to the sequence and update range of the incremental data.

[0046] Optionally, performing a consistency check on the incremental data by the Thanos sidecar, and updating the incremental data to local storage when the incremental data satisfies the consistency check, further includes:

[0047] When it is determined that the incremental data is changed or damaged, the changed or damaged data block is pulled from Prometheus through the Thanos sidecar and replaced, and an error log is recorded.

[0048] Optionally, the unique identifier includes a unique identifier generated by a UUID algorithm.

[0049] In the present invention, through the close integration of Thanos sidecar and Prometheus, comprehensive management and efficient use of monitoring data are achieved. It can not only read the initial data from Prometheus, and perform aggregation processing through Thanos query to obtain the target data, but also display it through visualization tools such as Grafana, making data monitoring and analysis more intuitive and convenient. In addition, a Metric proxy module is provided for data label replacement and alarm information processing, which further enhances the flexibility and scalability of the system. Through the Metric proxy, the label of the target data can be replaced with a unique identifier to facilitate data tracking and positioning; at the same time, the alarm information pushed by Prometheus can also be received and processed accordingly, which improves the response speed and accuracy of the system. In terms of data consistency verification and storage, the incremental data is strictly verified through the Thanos sidecar to ensure the accuracy and integrity of the data. When the incremental data meets the consistency check, it will be updated to the local storage, thereby ensuring the reliability and persistence of the data. In addition, it can also automatically handle data changes or damages, and further improve the stability and reliability of the system by re-pulling and replacing the changed or damaged data blocks, and recording error logs. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0051] Figure 1 A schematic diagram of the principle of a distributed system data management method provided in an embodiment of this specification;

[0052] Figure 2 Flowchart for data query;

[0053] Figure 3 Metric proxy data query flow chart;

[0054] Figure 4 This is the metric proxy alarm processing flow chart. DETAILED DESCRIPTION

[0055] The following description is used to disclose the present invention so that those skilled in the art can implement the present invention. The preferred embodiments described below are only examples, and those skilled in the art can think of other obvious variations. The basic principles of the present invention defined in the following description can be applied to other embodiments, variations, improvements, equivalents, and other technical solutions that do not deviate from the spirit and scope of the present invention.

[0056] The following is combined with Figure 1-4 The exemplary embodiments of the present invention are described more fully. However, the exemplary embodiments can be implemented in various forms, and it should not be understood that the present invention is limited to the embodiments set forth herein. On the contrary, providing these exemplary embodiments can make the present invention more comprehensive and complete, and it is more convenient to fully convey the inventive concept to those skilled in the art. The same reference numerals in the figures represent the same or similar elements, components or parts, and thus their repeated description will be omitted.

[0057] Under the premise of being consistent with the technical concept of the present invention, the features, structures, characteristics or other details described in a specific embodiment do not exclude that they can be combined in one or more other embodiments in a suitable manner.

[0058] In the description of specific embodiments, the features, structures, characteristics or other details described in the present invention are intended to enable those skilled in the art to fully understand the embodiments. However, it does not exclude that those skilled in the art can practice the technical solutions of the present invention without one or more of the specific features, structures, characteristics or other details.

[0059] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0060] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0061] The term "and / or" or "and / or" includes all combinations of any one or more of the associated listed items.

[0062] Figure 1 A schematic diagram of a distributed system data management method provided in an embodiment of this specification, the method may include:

[0063] S110: Read initial data from Prometheus via Thanos sidecar;

[0064] In the specific implementation of this specification, in the distributed monitoring architecture, Prometheus, as an open source system monitoring and alert tool suite, has become a leader in the monitoring field with its efficient time series database (TSDB) and flexible PromQL query language.

[0065] Thanos Sidecar specifies the address and port of Prometheus to connect to through the configuration file, so that Sidecar can establish communication with Prometheus and start reading data. Once the configuration is complete, Thanos Sidecar will regularly read monitoring data from Prometheus. These data may include various system indicators, application performance data, etc., depending on the configuration and monitoring objectives of Prometheus. After reading the data, Thanos Sidecar will perform preliminary processing on it, such as data format conversion, label processing, etc. The processed data will be uploaded by Thanos Sidecar to object storage (such as Amazon S3, Google Cloud Storage, etc.) for long-term storage. This process is real-time. As long as new monitoring data is generated in Prometheus, Sidecar will upload it to the object storage.

[0066] Thanos Sidecar also provides a query proxy function, allowing the Thanos Query component to query Prometheus's real-time data through it. In this way, even if the Prometheus instance fails, Thanos Query can still access the latest monitoring data through Sidecar.

[0067] Thanos Sidecar achieves real-time reading, processing, and storage of monitoring data through tight integration with Prometheus. This process not only improves the reliability and availability of data, but also provides a solid foundation for subsequent data query and analysis. At the same time, the introduction of Thanos Sidecar also solves the problems of Prometheus single point failure and data storage limitations, making the distributed monitoring system more stable and efficient when deployed on a large scale.

[0068] S120: query the initial data from the Thanos sidecar through Thanos query, and aggregate the queried initial data to obtain target data;

[0069] In the specific implementation of this specification, in a distributed monitoring environment, Thanos Query and ThanosSidecar work together to achieve efficient management and utilization of monitoring data. Thanos Sidecar is responsible for reading the initial monitoring data from the Prometheus instance and uploading it to the object storage for long-term storage. ThanosQuery is responsible for querying these initial data from the Sidecar and aggregating them according to demand. Specifically, ThanosQuery performs the following steps to query the initial data from Thanos Sidecar and aggregate them: Thanos Query first receives query requests from users or other monitoring components. These requests may contain specific time ranges, monitoring indicators, label filters and other conditions to specify the initial data to be queried. After receiving the query request, Thanos Query determines the Thanos Sidecar instance to be queried based on the conditions in the request. Since there may be multiple Sidecar instances, each instance is responsible for a different Prometheus data source, Query needs to correctly route the request to the corresponding Sidecar. Thanos Query communicates with Thanos Sidecar via HTTP or other protocols to send query requests. After receiving the request, Sidecar retrieves the corresponding initial data from the object storage and returns it to the Query component. After receiving the initial data returned from Sidecar, Thanos Query aggregates the data according to the aggregation conditions in the query request (such as sum, average, maximum value, minimum value, etc.). This step is the key to generating target data, which makes the monitoring data more concise, easy to understand and analyze. After aggregation, Thanos Query returns the generated target data to the user or other monitoring components. This data may be presented in the form of time series charts, alarm information, etc., to help users understand the system status, discover potential problems and take appropriate measures.

[0070] Thanos Query provides users with powerful and flexible monitoring data query and analysis capabilities by querying initial data from Thanos Sidecar and performing aggregation processing. This process not only improves the utilization and accuracy of monitoring data, but also provides a strong guarantee for the stability and reliability of distributed systems.

[0071] S130: query the target data from the Thanos query through Grafana and / or the navigation control module, and display the queried target data.

[0072] In the specific implementation of this specification, in the distributed monitoring system, the collaboration of Grafana and Thanos Query provides users with a powerful tool to extract valuable information from complex monitoring data. When a user needs to query and display specific monitoring data, Grafana will first interact with Thanos Query.

[0073] Users build query requests based on their needs through the Grafana interface. This includes selecting monitoring indicators, setting time ranges, applying label filters, etc. These request parameters will be collected by Grafana and organized into a format that Thanos Query can understand. After building the query request, Grafana will communicate with Thanos Query through its built-in query engine or API interface. After receiving the request, Thanos Query will query the corresponding target data from ThanosSidecar based on the parameters in the request. During the query process, Thanos Query will aggregate and filter the initial data obtained from the Sidecar according to the aggregation conditions and filtering rules set by the user to generate target data that meets the user's needs. Thanos Query returns the processed target data to Grafana. After receiving the data, Grafana will parse it and prepare the data format for display. Grafana presents the parsed target data to users in an intuitive and easy-to-understand way through its rich chart types and customized display templates. Users can view the trends, outliers and other information of the monitoring data in real time through the Grafana interface. In this process, navigation control modules (such as Grafana's sidebar, top navigation bar, etc.) provide users with convenient interface navigation and operation control. Users can use these modules to quickly switch different monitoring panels, adjust query parameters, view historical data, etc., so as to more efficiently use Grafana and Thanos Query to query and display monitoring data.

[0074] The integration of Grafana and Thanos Query, as well as the assistance of the navigation control module, provide users with an efficient, intuitive and easy-to-use monitoring data query and display platform. This not only improves user work efficiency, but also provides strong support for the stability and reliability of distributed systems.

[0075] Optionally, also include:

[0076] Query the target data from Thanos query and / or Postgre SQL through the Metric proxy, and replace the label of the target data with a unique identifier;

[0077] The target data carrying the unique identifier is displayed through the Grafana and / or the navigation control module.

[0078] In the specific implementation of this specification, Figure 2 As shown in the figure, in order to meet the needs of in-depth analysis and efficient display of monitoring data, Metric Proxy is designed to query target data from data sources such as Thanos Query and PostgreSQL at the same time. These target data may include time series data, performance indicators, event logs, etc., depending on the configuration of the monitoring system and user needs.

[0079] Metric Proxy first sends a query request to Thanos Query and / or PostgreSQL based on the query conditions defined by the user or system. These conditions may include specific time ranges, monitoring indicators, label filters, etc. Thanos Query retrieves the target data that meets the conditions from the monitoring data it stores, while PostgreSQL may provide metadata or historical data related to monitoring. After obtaining the target data, Metric Proxy preprocesses it. A key step is to replace the labels in the data with unique identifiers (UIDs). This replacement helps to simplify the data model, reduce storage overhead, and improve the efficiency of data queries. The unique identifier can be a short string generated based on a hash algorithm or other forms of unique identifiers. Metric Proxy integrates data from different data sources to ensure that they are presented in a unified format and structure. This includes adjusting the timestamp, unit, precision, etc. of the data to ensure data consistency and comparability. The preprocessed data (that is, the target data with unique identifiers) will be transmitted by Metric Proxy to Grafana or other visualization tools for display. This transmission process may involve steps such as serialization, compression, and encryption of data to ensure data integrity and security. After receiving data from Metric Proxy, Grafana displays it according to the dashboard and chart configuration defined by the user. These dashboards and charts may include line charts, bar charts, pie charts, etc., which are used to intuitively display the trends, distribution and abnormalities of monitoring data. The navigation control module (such as Grafana's sidebar, top navigation bar, etc.) provides users with convenient interface navigation and operation control, allowing them to quickly locate the data area of ​​interest, adjust display parameters, or view historical data.

[0080] Metric Proxy integrates with data sources such as Thanos Query and PostgreSQL to achieve in-depth query and preprocessing of monitoring data. Grafana and its navigation control module then visualize the preprocessed data efficiently and intuitively, providing users with powerful monitoring data analysis and display capabilities.

[0081] Optionally, also include:

[0082] Receiving the alarm information pushed by the Prometheus through the Metric proxy, and / or querying the target data from the Postgre SQL, and replacing the labels of the alarm information and / or the target data with unique identifiers;

[0083] The alert information carrying the unique identifier and / or the target data carrying the unique identifier are processed by an Alert manager.

[0084] In the specific implementation of this specification, Figure 3 As shown, in order to build a system that can efficiently process multiple reliable monitoring data sources and information alerts at the same time. To manage these systems, the data source Metric includes ProxyProm designed by Etheus (for pushing alert information) and PostgreSQL (for querying target data).

[0085] As an open source system monitoring and alerting tool, Prometheus can detect anomalies in the system in real time and generate alert information. Metric Proxy is configured with an interface to receive Prometheus alert information. When Prometheus detects anomalies and generates alerts, it pushes these alert information to Metric Proxy.

[0086] As a powerful relational database, PostgreSQL may store metadata, historical data, or analysis results related to monitoring. Metric Proxy can send query requests to PostgreSQL based on the query conditions defined by the user or system, and obtain the target data that meets the conditions.

[0087] Whether it is the alert information received from Prometheus or the target data queried from PostgreSQL, Metric Proxy will preprocess the labels. The key step of preprocessing is to replace the labels with unique identifiers (UIDs). This replacement helps to simplify the data processing process and improve the efficiency and accuracy of data processing. The unique identifier can be a short string generated based on a hash algorithm or other forms of unique identification, depending on the design and requirements of the system.

[0088] The pre-processed alert information and target data (i.e. data with unique identifiers) are transmitted by Metric Proxy to Alert Manager for further processing. This transmission process may involve steps such as serialization, compression, and encryption of data to ensure data integrity and security.

[0089] Alert Manager is a core component in the monitoring and alarm management system, responsible for receiving, processing and responding to alarm information. When Alert Manager receives alarm information with unique identifiers and / or target data, it will process it according to the user-defined alarm policies and rules. The processing process may include steps such as alarm classification, deduplication, upgrade / downgrade, and notification distribution to ensure effective management and timely response of alarms. Finally, Alert Manager will feedback the processing results to the relevant personnel or systems so that they can take appropriate measures to solve the problem.

[0090] Metric Proxy integrates with Prometheus and PostgreSQL to receive, query, and preprocess alert information and target data. Subsequently, Alert Manager processes and responds to these data with unique identifiers efficiently and accurately, ensuring the stability and reliability of the monitoring and alert management system.

[0091] Optionally, also include:

[0092] Pull incremental data from the Prometheus periodically through the Thanos sidecar;

[0093] The incremental data is checked for consistency through the Thanos sidecar, and when the incremental data satisfies the consistency check, the incremental data is updated to local storage.

[0094] In the specific implementation of this specification, Figure 4As shown in the figure, in the distributed monitoring system, ThanosSidecar plays the role of a bridge and guardian to ensure the continuity and accuracy of monitoring data. It interacts with Prometheus regularly to pull the latest incremental data. These incremental data may include time series data, performance indicators, event logs, etc., which reflect the operating status of the system over the past period of time.

[0095] Thanos Sidecar is configured with an interface for communicating with Prometheus and a data pulling strategy, including the pulling time interval, data range, etc. According to the preset strategy, Thanos Sidecar will periodically send pull requests to Prometheus, which contain information such as the time range and label filter of the data to be pulled. After receiving the request, Prometheus will retrieve the incremental data that meets the conditions from its own storage according to the parameters in the request and return it to Thanos Sidecar.

[0096] After receiving the incremental data, Thanos Sidecar will perform a consistency check on it. This step is critical because it ensures that the data pulled from Prometheus is accurate and complete. Consistency checks may include data timestamp checks, data value range checks, and correlation checks between data. Through these checks, Thanos Sidecar can detect and filter out possible erroneous or abnormal data. If the incremental data meets the consistency check requirements, Thanos Sidecar will treat it as valid data and prepare for the next storage update.

[0097] After confirming that the incremental data is valid, Thanos Sidecar will update the data to its local storage. The local storage may be a disk-based storage system or other forms of persistent storage.

[0098] The update process may involve operations such as writing data, updating indexes, and maintaining metadata. These operations are to ensure that incremental data can be correctly stored and retrieved. After the update is completed, Thanos Sidecar will update its internal data status so that the latest data can be accurately reflected in subsequent data queries and retrievals.

[0099] Thanos Sidecar achieves incremental data pulling, consistency verification, and local storage updates through regular interaction with Prometheus. This process ensures the continuity and accuracy of monitoring data and provides a reliable data foundation for subsequent data analysis and visualization.

[0100] Optionally, performing a consistency check on the incremental data by the Thanos sidecar, and updating the incremental data to local storage when the incremental data satisfies the consistency check, includes:

[0101] Get the timestamp and version number of the incremental data;

[0102] Determine the sequence and update range of the incremental data based on the timestamp and version number;

[0103] Performing a hash value check on the incremental data to determine whether the incremental data is changed or damaged;

[0104] When it is determined that the incremental data has not been changed or damaged, the incremental data is updated to local storage according to the sequence and update range of the incremental data.

[0105] In a specific implementation of this specification, after receiving the incremental data pulled from Prometheus, Thanos Sidecar will first obtain the timestamp and version number of this data. The timestamp is a record of the time when the data is generated or collected, while the version number is used to identify the version or iteration number of the data. These two pieces of information are crucial for determining the order and update scope of the incremental data. Based on the obtained timestamps and version numbers, Thanos Sidecar can determine the order of incremental data. Data with newer timestamps usually indicate more recent changes in system status, and therefore should be processed first. At the same time, the version number also helps to identify updated iterations of the data to ensure that no data is missed or duplicated during the processing process.

[0106] After determining the order and update range of the incremental data, Thanos Sidecar will perform a hash value check. A hash value is a data summary that can uniquely represent the content of a piece of data. By hashing the incremental data and comparing it with the previously stored hash value, Thanos Sidecar can determine whether the data has changed or been damaged. If the hash values ​​match, it means that the data has not changed; if they do not match, it may indicate that there is a problem with the data during transmission or storage. When it is determined that the incremental data has not changed or been damaged, Thanos Sidecar will update the data to local storage according to the order and update range of the incremental data. The update process may involve operations such as data writing, index updating, and metadata maintenance. In order to ensure the integrity and consistency of the data, Thanos Sidecar will strictly adhere to the order and update range of the data during the update process to avoid data overwriting or omission. In addition, Thanos Sidecar will also record relevant information for each update operation, such as update time, update content, etc., so as to provide necessary reference and basis for subsequent data query, retrieval or troubleshooting.

[0107] Thanos Sidecar ensures the consistency and integrity of the incremental data pulled from Prometheus by obtaining the timestamp and version number of the incremental data, determining the order and update range of the data, performing hash value verification, and updating the data to local storage in sequence. This process provides a reliable data foundation for subsequent data analysis and visualization.

[0108] Optionally, performing consistency check on the incremental data by the Thanos sidecar, and updating the incremental data to local storage when the incremental data satisfies the consistency check, further includes:

[0109] When it is determined that the incremental data is changed or damaged, the changed or damaged data block is pulled from Prometheus through the Thanos sidecar and replaced, and an error log is recorded.

[0110] In the specific implementation of this specification, after Thanos Sidecar receives the incremental data pulled from Prometheus, it will first perform a consistency check. This step is critical because it ensures the accuracy and reliability of the data. Thanos Sidecar obtains the timestamp and version number of the incremental data, both of which are critical for determining the order and update range of the data. Next, Thanos Sidecar performs a hash value check on the incremental data, calculating the hash value of the data and comparing it with the previously stored hash value to determine whether the data has been changed or damaged.

[0111] When Thanos Sidecar determines that the incremental data has not been changed or damaged, it will update the incremental data to local storage according to the order and update range of the data. This step ensures the continuity and consistency of the data, providing a reliable basis for subsequent data analysis and visualization. However, if Thanos Sidecar finds that the incremental data has been changed or damaged during the hash value verification process, it will take countermeasures immediately. First, Thanos Sidecar will re-pull the changed or damaged data blocks through the Prometheus API interface. During the pulling process, Thanos Sidecar will ensure the integrity and accuracy of the data to avoid the introduction of erroneous data again. At the same time, Thanos Sidecar will record error logs, detailing the time when the data was changed or damaged, the specific information of the data block, and the operation process of re-pulling the data. These error logs are crucial for subsequent data troubleshooting and recovery. They can provide detailed data change history and operation records to help operation and maintenance personnel quickly locate the cause of the problem and take corresponding solutions. In addition, Thanos Sidecar will perform hash value verification again after re-pulling and replacing the changed or damaged data blocks to ensure that the newly pulled data blocks are accurate and complete. Thanos Sidecar will update the new data block to local storage only when it meets the consistency check requirements.

[0112] Thanos Sidecar ensures the consistency and integrity of incremental data pulled from Prometheus through a series of rigorous measures. When data is changed or damaged, Thanos Sidecar can respond quickly and re-pull the correct data block, while recording detailed error logs, providing strong support for subsequent data troubleshooting and recovery.

[0113] Optionally, the unique identifier includes a unique identifier generated by a UUID algorithm.

[0114] In the specific implementation of this specification, when Thanos Sidecar processes incremental data pulled from Prometheus, in order to ensure the uniqueness and traceability of each data block or data set, a unique identifier (UID) is usually assigned to it. This unique identifier plays an important role in data consistency verification, storage, retrieval, and error logging. Among them, the unique identifier generated by the UUID (Universally Unique Identifier) ​​algorithm is a common and effective choice. The UUID algorithm can generate a 128-bit number that is almost impossible to repeat, and this number is extremely unique in a distributed system.

[0115] In the present invention, through the close integration of Thanos sidecar and Prometheus, comprehensive management and efficient use of monitoring data are achieved. It can not only read the initial data from Prometheus, and perform aggregation processing through Thanos query to obtain the target data, but also display it through visualization tools such as Grafana, making data monitoring and analysis more intuitive and convenient. In addition, a Metric proxy module is provided for data label replacement and alarm information processing, which further enhances the flexibility and scalability of the system. Through the Metric proxy, the label of the target data can be replaced with a unique identifier to facilitate data tracking and positioning; at the same time, the alarm information pushed by Prometheus can also be received and processed accordingly, which improves the response speed and accuracy of the system. In terms of data consistency verification and storage, the incremental data is strictly verified through the Thanos sidecar to ensure the accuracy and integrity of the data. When the incremental data meets the consistency check, it will be updated to the local storage, thereby ensuring the reliability and persistence of the data. In addition, it can also automatically handle data changes or damages, and further improve the stability and reliability of the system by re-pulling and replacing the changed or damaged data blocks, and recording error logs.

[0116] A distributed system data management device provided in an embodiment of this specification may include:

[0117] A central controller and several hub controllers; the central controller includes Grafana, navigation control module, and Thanos query; the hub controller includes Thanos sidecar and Prometheus;

[0118] Read initial data from the Prometheus via the Thanos sidecar;

[0119] Querying the initial data from the Thanos sidecar through the Thanos query, and aggregating the queried initial data to obtain target data;

[0120] The target data is queried from the Thanos query through the Grafana and / or the navigation control module, and the queried target data is displayed.

[0121] Optionally, also include:

[0122] The central controller also includes Metric proxy and Postgre SQL;

[0123] Querying the target data from the Thanos query and / or the Postgre SQL through the Metric proxy, and replacing the label of the target data with a unique identifier;

[0124] The target data carrying the unique identifier is displayed through the Grafana and / or the navigation control module.

[0125] Optionally, also include:

[0126] The central controller also includes an Alert manager;

[0127] Receiving the alarm information pushed by the Prometheus through the Metric proxy, and / or querying the target data from the Postgre SQL, and replacing the labels of the alarm information and / or the target data with unique identifiers;

[0128] The alert information carrying the unique identifier and / or the target data carrying the unique identifier are processed by an Alert manager.

[0129] Optionally, also include:

[0130] Pull incremental data from the Prometheus periodically through the Thanos sidecar;

[0131] The incremental data is checked for consistency through the Thanos sidecar, and when the incremental data satisfies the consistency check, the incremental data is updated to local storage.

[0132] Optionally, performing consistency check on the incremental data by the Thanos sidecar, and updating the incremental data to local storage when the incremental data satisfies the consistency check, includes:

[0133] Get the timestamp and version number of the incremental data;

[0134] Determine the sequence and update range of the incremental data based on the timestamp and version number;

[0135] Performing a hash value check on the incremental data to determine whether the incremental data is changed or damaged;

[0136] When it is determined that the incremental data has not been changed or damaged, the incremental data is updated to local storage according to the sequence and update range of the incremental data.

[0137] Optionally, performing a consistency check on the incremental data by the Thanos sidecar, and updating the incremental data to local storage when the incremental data satisfies the consistency check, further includes:

[0138] When it is determined that the incremental data is changed or damaged, the changed or damaged data block is pulled from Prometheus through the Thanos sidecar and replaced, and an error log is recorded.

[0139] Optionally, the unique identifier includes a unique identifier generated by a UUID algorithm.

[0140] The functions of the device in the embodiment of the present invention have been described in the above method embodiment, so for details not provided in the description of this embodiment, please refer to the relevant description in the above embodiment, and no further description will be given here.

[0141] The present invention can be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. It should be understood by those skilled in the art that general data processing devices such as microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components in the embodiments of the present invention. The present invention can also be implemented as a device or apparatus program (e.g., computer program and computer program product) for executing part or all of the methods described herein. Such a program implementing the present invention can be stored on a computer-readable medium, or can have the form of one or more signals. Such a signal can be downloaded from an Internet website, or provided on a carrier signal, or provided in any other form.

[0142] The specific embodiments described above further describe the purpose, technical solutions and beneficial effects of the present invention in detail. It should be understood that the present invention is not inherently related to any specific computer, virtual device or electronic device, and various general devices can also implement the present invention. The above description is only a specific embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the protection scope of the present invention.

[0143] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referenced to each other, and each embodiment focuses on the differences from other embodiments.

[0144] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A distributed system data management method, characterized in that: include: Read initial data from Prometheus via Thanos sidecar; Query the initial data from the Thanos sidecar through Thanos query, and aggregate the queried initial data to obtain target data; The target data is queried from the Thanos query through Grafana and / or the navigation control module, and the queried target data is displayed.

2. The distributed system data management method according to claim 1, characterized in that: Also includes: Query the target data from Thanos query and / or Postgre SQL through the Metric proxy, and replace the label of the target data with a unique identifier; The target data carrying the unique identifier is displayed through the Grafana and / or the navigation control module.

3. The distributed system data management method according to claim 2, characterized in that: Also includes: receiving the alarm information pushed by the Prometheus through the Metric proxy, and / or querying the target data from the PostgreSQL, and replacing the labels of the alarm information and / or the target data with unique identifiers; The alert information carrying the unique identifier and / or the target data carrying the unique identifier are processed by an Alert manager.

4. The distributed system data management method according to claim 3, characterized in that: Also includes: Pull incremental data from the Prometheus periodically through the Thanos sidecar; The incremental data is checked for consistency through the Thanos sidecar, and when the incremental data satisfies the consistency check, the incremental data is updated to local storage.

5. The distributed system data management method according to claim 4, characterized in that: The performing consistency check on the incremental data by the Thanossidecar, and updating the incremental data to local storage when the incremental data satisfies the consistency check, includes: Get the timestamp and version number of the incremental data; Determine the sequence and update range of the incremental data based on the timestamp and version number; Performing a hash value check on the incremental data to determine whether the incremental data is changed or damaged; When it is determined that the incremental data has not been changed or damaged, the incremental data is updated to local storage according to the sequence and update range of the incremental data.

6. The distributed system data management method according to claim 5, characterized in that: The step of performing consistency check on the incremental data by the Thanossidecar and updating the incremental data to local storage when the incremental data satisfies the consistency check further includes: When it is determined that the incremental data is changed or damaged, the changed or damaged data block is pulled from Prometheus through the Thanos sidecar and replaced, and an error log is recorded.

7. The distributed system data management method according to claim 6, characterized in that: The unique identifier includes a unique identifier generated by a UUID algorithm.

8. A distributed system data management device, characterized in that: include: A central controller and several hub controllers; the central controller includes Grafana, navigation control module, and Thanos query; the hub controller includes Thanos sidecar and Prometheus; Read initial data from the Prometheus via the Thanos sidecar; Querying the initial data from the Thanos sidecar through the Thanos query, and aggregating the queried initial data to obtain target data; The target data is queried from the Thanos query through the Grafana and / or the navigation control module, and the queried target data is displayed.

9. The distributed system data management device according to claim 8, characterized in that: Also includes: The central controller also includes Metric proxy and Postgre SQL; Querying the target data from the Thanos query and / or the Postgre SQL through the Metric proxy, and replacing the label of the target data with a unique identifier; The target data carrying the unique identifier is displayed through the Grafana and / or the navigation control module.

10. The distributed system data management device according to claim 9, characterized in that: Also includes: The central controller also includes an Alert manager; receiving the alarm information pushed by the Prometheus through the Metric proxy, and / or querying the target data from the PostgreSQL, and replacing the labels of the alarm information and / or the target data with unique identifiers; The alert information carrying the unique identifier and / or the target data carrying the unique identifier are processed by an Alert manager.

Images