Monitoring method and management equipment

Abstract

The embodiment of the invention provides a monitoring method and management equipment, relates to the technical field of multi-cluster management, and can realize global unified query of multi-cluster monitoring data isolated by tenants. The specific scheme is applied to a management device, the management device is in communication connection with a plurality of clusters, and the content comprises: in response to a query instruction of a target tenant, determining a target cluster in the plurality of clusters, the target cluster being a cluster managed by the target tenant; querying operation index data of the target cluster; and returning a query result to the target tenant based on the operation index data.

Description

Technical Field

[0001] This application relates to the field of multi-cluster management technology, and in particular to a monitoring method and management device. Background Technology

[0002] Multi-cluster management refers to the process of unified management, monitoring, and scheduling of multiple clusters. It typically involves coordinating and controlling multiple Kubernetes clusters or other types of clusters in the same or different environments to achieve optimized resource utilization, high application availability, and cross-cluster collaboration capabilities.

[0003] How to achieve unified monitoring of multi-cluster management, so as to help quickly discover and solve problems, is an urgent problem to be solved. Summary of the Invention

[0004] This application provides a monitoring method and management device that enables global unified query of multi-cluster monitoring data with tenant isolation.

[0005] To achieve the above technical objectives, the embodiments of this application adopt the following technical solutions:

[0006] In a first aspect, embodiments of this application provide a monitoring method applied to a management device, wherein the management device is communicatively connected to multiple clusters; the clusters belong to at least one tenant, and the tenant manages at least one cluster; the method includes: in response to a query instruction from a target tenant, determining a target cluster among the multiple clusters, wherein the target cluster is a cluster managed by the target tenant; querying the operational indicator data of the target cluster; and returning the query results to the target tenant based on the operational indicator data.

[0007] Understandably, upon receiving a query command from a target tenant, the system identifies the clusters managed by that tenant. Then, based on the established communication connection with those clusters, it queries the operational metrics data of those clusters. Finally, it returns the query results to the target tenant based on the operational metrics data. Since each cluster stores its own monitoring data independently, and upon receiving a query command from a tenant, only the monitoring data of the multiple clusters managed by that tenant is queried, independent storage and tenant isolation of monitoring data are achieved. Furthermore, when a tenant manages multiple clusters, returning query results to that tenant based on the monitoring data of all the clusters managed by that tenant enables globally unified querying of monitoring data across multiple clusters.

[0008] In one possible implementation, the target cluster is a cluster managed by the target tenant that is monitored for target operating metrics, wherein the target operating metrics are the operating metrics to be queried as indicated in the query command.

[0009] Understandably, the query command issued by the tenant can include the operational metrics to be queried, and the clusters whose monitoring data to be queried can be further filtered based on these operational metrics, thereby improving the query speed.

[0010] In one possible implementation, the target cluster is determined among multiple clusters, including: determining the cluster managed by the target tenant based on a cluster information registry, wherein the cluster information registry records at least one cluster and its tenant; and determining the target cluster based on the indicator registry corresponding to each cluster managed by the target tenant, wherein the indicator registry records the monitored operating indicators in the corresponding cluster.

[0011] Understandably, the management device maintains a cluster information registry and a corresponding indicator registry for each cluster. Based on the cluster information registry, it filters the clusters managed by the tenant who sent the query command. Then, based on the indicator registry corresponding to the cluster managed by that tenant, it filters the clusters whose monitored indicators include the operational indicators given in the query command. Through these two steps of tenant filtering and operational indicator filtering, the range of clusters whose monitoring data needs to be queried is quickly narrowed down, thus improving the query speed.

[0012] In one possible implementation, the aforementioned cluster information registry also records the cluster status of at least one cluster, including running status and non-running status; determining the target cluster based on the cluster information registry includes: querying the clusters managed by the target tenant within the range of clusters that are running in the cluster information registry.

[0013] Understandably, the cluster information registry also records whether the cluster is in a normal state (i.e., running state). Since clusters that are not in a normal state are unlikely to respond to monitoring data query requests, querying monitoring data from these clusters is useless and wasteful of resources. Therefore, the operation of controlling and filtering clusters is only performed within the clusters that are in a normal state, to avoid resource waste and improve query efficiency to a certain extent.

[0014] In one possible implementation, the management device includes multiple Bloom filters corresponding one-to-one with multiple clusters, and the multiple Bloom filters are configured based on the indicator registry of multiple clusters; the determination of the target cluster based on the indicator registry corresponding to each cluster managed by the target tenant includes: determining whether each cluster managed by the target tenant is a cluster with the monitored target operating indicator by using the Bloom filters corresponding to each cluster in the cluster managed by the target tenant according to the query instruction; and determining the target cluster as the cluster with the monitored target operating indicator in the cluster managed by the target tenant.

[0015] Understandably, the management device includes multiple Bloom filters that correspond one-to-one with multiple clusters. Each Bloom filter is configured based on the metric registry of the corresponding cluster. It has a faster query speed than querying the metric registry. That is, for a specific operating metric, the Bloom filter can more quickly determine whether the monitored operating metrics of the corresponding cluster include that specific operating metric. Therefore, operating metric filtering based on Bloom filters can improve the speed of operating metric filtering.

[0016] In one possible implementation, querying the target cluster's operational metrics data includes: querying the target cluster's operational metrics data for the first target query period.

[0017] Understandably, the query instructions issued by the tenant can include a query period. By narrowing the query time range of the monitoring data based on this query period, the amount of data to be processed subsequently can be reduced, thereby improving the query speed.

[0018] In one possible implementation, the operational indicator data is the indicator data corresponding to the target operational indicator, where the target operational indicator is the operational indicator to be queried as indicated in the query command.

[0019] Understandably, the range of monitoring metrics to be queried is narrowed down according to the operational metrics specified in the query command, thereby reducing the amount of data to be processed and improving the query speed.

[0020] In one possible implementation, a cluster is deployed with a monitoring instance, and the above query targets the cluster's operational metrics data for the first target query period, including:

[0021] Pull the target cluster's operational metrics data for the first target query period from the monitoring instance deployed on the target cluster.

[0022] Understandably, each cluster deploys a monitoring instance that monitors the cluster's operational metrics and saves the corresponding metric data. When querying the cluster's operational metric data, the data is directly pulled from the monitoring instance corresponding to the cluster for quick data retrieval.

[0023] In one possible implementation, the aforementioned management device includes multiple cache shards corresponding one-to-one with multiple clusters; each cluster is deployed with a monitoring instance, which queries the target cluster's operational metrics data for the first target query period, including:

[0024] The system queries the runtime metrics data within the first target query period from the cache shards corresponding to the target cluster. The cache shards use a three-layer cache structure to store metric data; the first, second, and third layers of the three-layer cache structure represent the cluster name, metric name, and a time-series sequence of runtime metrics data with timestamps, respectively. It then determines the second target query period, which is a period outside the time frame of the queried runtime metrics data but within the first target query period. Finally, it pulls the runtime metrics data for the target cluster within the second target query period from the monitoring instances deployed on the target cluster. Based on the pulled runtime metrics data and the queried runtime metrics data, it obtains the runtime metrics data for the target cluster within the first target query period.

[0025] Understandably, the management device includes multiple cache shards corresponding one-to-one with multiple clusters. Operational metric data retrieved from a cluster is only stored in the cache shard corresponding to that cluster, enabling partitioned data storage across different clusters. When querying operational metric data for a cluster within a specific time period, the system first queries the cache shard corresponding to that cluster for that time period. Then, it retrieves only operational metric data from the monitoring instance within that time period that does not exist in the cache shard, narrowing the data retrieval time range and improving query speed. Furthermore, the cache shards employ a three-layer cache structure for metric data storage; the first, second, and third layers of the three-layer cache structure represent the cluster name, metric name, and a timestamped sequence of operational metric data, respectively, enabling fast data retrieval within the cache shards.

[0026] In one possible implementation, the method further includes: updating the runtime metrics data in the cache shard using the least recently used algorithm; and deleting the metric names in the cache shard where runtime metrics data does not exist.

[0027] Understandably, cache shards can use the Least Recently Used (LRU) algorithm to automatically delete data that has not been accessed for a long time, retaining only the most recently accessed data, thereby maintaining the size of the cache shards and reducing the use of storage resources.

[0028] In one possible implementation, query results are returned to the target tenant based on operational metric data, including:

[0029] The target aggregation algorithm is used to process the operational indicator data to obtain the query results. The target aggregation algorithm is a data processing algorithm corresponding to the processing strategy indicated by the query command. The query results are then returned to the target tenant.

[0030] Understandably, the query commands issued by a tenant can include processing strategies (e.g., calculating the average of operating metrics, selecting the largest operating metric values, etc.). By using data processing algorithms that match the processing strategy to process the operating metric data and return the processing results to the tenant, the tenant can view the operating status and performance metrics of the clusters they manage from a unified perspective, which helps to quickly identify and resolve problems.

[0031] In one possible implementation, the method further includes: periodically detecting the cluster status and updating the cluster information registry using the detection results.

[0032] It is understandable that the cluster status of each cluster is periodically detected and updated in the cluster information registry to ensure the timeliness of tenant screening.

[0033] In one possible implementation, the method further includes: periodically detecting the monitored operational metrics of the cluster; comparing the detected operational metrics with the cluster's metric registry; updating the cluster's metric registry in response to a discrepancy in the comparison results; resetting the corresponding Bloom filter for the cluster based on the updated metric registry; and terminating the process in response to a consistent comparison results.

[0034] Understandably, the monitored operational metrics of each cluster are periodically detected. When it is determined that the detected operational metrics are not completely consistent with the operational metrics previously stored in the metric registry, the metric registry of each cluster is updated, and the Bloom filter corresponding to each cluster is reset using the updated metric registry, thereby ensuring the timeliness of metric screening.

[0035] In one possible implementation, the method further includes: updating the cluster recorded in the cluster information registry in response to a cluster update operation; and updating the tenant corresponding to the cluster recorded in the cluster information registry in response to a tenant update operation.

[0036] It is understandable that when a cluster or its corresponding operations involve additions, deletions, or modifications, the corresponding changes will be updated in the cluster information registry to ensure the accuracy of subsequent tenant selection.

[0037] Secondly, embodiments of this application provide a management device. This management device includes various modules applied to the method described in the first aspect or any possible design scheme within the first aspect.

[0038] Thirdly, embodiments of this application provide a management device including a memory and a processor. The memory and the processor are coupled; the memory stores computer program code, which includes computer instructions. When the processor executes the computer instructions, it causes the management device to perform a monitoring method as described in the first aspect and any possible implementation thereof.

[0039] Fourthly, embodiments of this application provide a management device including a processor, wherein the processor executes a monitoring method as described in the first aspect and any possible implementation thereof.

[0040] For example, the aforementioned management devices may be such as servers, tablets, desktops, laptops, netbooks, etc.

[0041] Fifthly, embodiments of this application provide a computer-readable storage medium including computer instructions. When executed on a management device, the computer instructions cause the management device to perform a monitoring method as described in the first aspect and any possible implementation thereof.

[0042] Sixthly, embodiments of this application provide a computer program product including computer instructions. When the computer instructions are executed on a management device, they cause the management device to perform a monitoring method as described in the first aspect and any possible implementation thereof.

[0043] For a detailed description of the second to sixth aspects and their various implementations in the embodiments of this application, please refer to the detailed description in the first aspect and its various implementations; and for a detailed description of the beneficial effects of the second to sixth aspects and their various implementations, please refer to the beneficial effect analysis in the first aspect and its various implementations, which will not be repeated here.

[0044] These or other aspects of the embodiments of this application will become more apparent in the following description. Attached Figure Description

[0045] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application;

[0046] Figure 2 A schematic diagram of the implementation environment involved in a monitoring method provided in an embodiment of this application;

[0047] Figure 3 This is a schematic diagram of the hardware structure of a management device provided in an embodiment of this application;

[0048] Figure 4 A flowchart illustrating a monitoring method provided in an embodiment of this application;

[0049] Figure 5 A flowchart illustrating yet another monitoring method provided in an embodiment of this application;

[0050] Figure 6 A schematic diagram illustrating an indicator screening process provided in an embodiment of this application;

[0051] Figure 7This is a schematic diagram illustrating the working principle of a liveness detection component provided in an embodiment of this application;

[0052] Figure 8 A schematic diagram illustrating a process for updating an index registry, provided in an embodiment of this application;

[0053] Figure 9 A flowchart illustrating yet another monitoring method provided in an embodiment of this application;

[0054] Figure 10 This is a schematic diagram of the structure of a buffer provided in an embodiment of this application;

[0055] Figure 11 A schematic diagram illustrating an indicator data query mechanism provided in an embodiment of this application;

[0056] Figure 12 This is a schematic diagram of the structure of a monitoring device provided in an embodiment of this application. Detailed Implementation

[0057] In order to clearly describe the technical solutions of the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish the same or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" are not necessarily different.

[0058] In the description of the embodiments in this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. "And / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, "at least one" refers to one or more, and "multiple" refers to two or more.

[0059] It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0060] For ease of understanding, the relevant terms used in the embodiments of this application will be briefly introduced below:

[0061] (1) Monitoring: refers to the process of observing and recording various resources such as systems, applications, or networks in real time to obtain their operating status, performance indicators, and health status. The main goal of monitoring is to ensure the normal operation of the system, promptly identify and respond to potential problems, thereby improving the reliability and availability of services.

[0062] (2) Cluster: refers to multiple computers connected together via a network to work together to improve performance, reliability, or scalability. Clusters are managed by management software, such as Kubernetes clusters, which are groups of computing resources managed and orchestrated by Kubernetes. They typically consist of multiple nodes (including master nodes and worker nodes) and are used to deploy, manage, and scale containerized applications.

[0063] (3) Tenant: A concept in a multi-tenant architecture or cloud computing environment, referring to a single user, organization, or entity that independently uses resources within a shared infrastructure or resource pool. Each tenant is technically isolated from one another and typically has its own independent data, settings, and configurations.

[0064] (4) Kubernetes Cluster: A containerized application management platform consisting of a group of physical or virtual computing nodes, used to automate the deployment, scaling, and management of containerized applications. It consists of a control plane and worker nodes, which work together to run and manage containerized services.

[0065] (5) Prometheus Instance: This refers to an independently running Prometheus server process and its associated complete monitoring system, which includes core functional modules such as data collection, storage, querying, and alerting. It can run and be configured independently, and there are no dependencies between instances. Data aggregation can be performed through federation mechanisms or remote storage.

[0066] (6) Federation mechanism: This is the core function of Prometheus for hierarchical aggregation of monitoring data. It allows a Prometheus server to selectively fetch aggregated data from other Prometheus servers, thereby expanding the monitoring architecture.

[0067] (7) Proxy Component: In the monitoring system, it is an intermediate layer between the data source and the main monitoring service, and undertakes key functions such as data forwarding, protocol conversion, and preprocessing.

[0068] (8) Bloom filter: a space-efficient probabilistic data structure used to quickly determine whether an element may exist in a set.

[0069] (9) Cache sharding: is a technology that distributes large-scale cached data across multiple nodes, aiming to solve the capacity limitation and performance bottleneck of single-node cache.

[0070] (10) Tenant isolation: This is the core design in a multi-tenant system architecture, ensuring that the data, configuration and resources of different tenants are isolated from each other while sharing the underlying infrastructure.

[0071] This application provides a monitoring method applicable to multi-cluster, multi-tenant metric monitoring scenarios. Please refer to [link / reference]. Figure 1 This illustration shows an application scenario provided by an embodiment of this application. Figure 1 As shown, this application scenario includes a multi-cluster, multi-tenant architecture, in which a cluster belongs to at least one tenant, and a tenant manages at least one cluster, that is, there can be a many-to-many correspondence between clusters and tenants.

[0072] In a multi-tenancy system, a tenant is the core logical entity that represents an independent customer or business unit. For example, a single enterprise can be a tenant, or a department within an enterprise can be a tenant.

[0073] A cluster is a computer system deployed by a tenant according to its own business needs. It consists of multiple interconnected computers (nodes) that work together to appear as a single system to the outside world. Each node in the cluster runs its own independent server, and they are connected through a network to share resources and work together to complete tasks.

[0074] Understandably, due to limitations such as geography, business, and technology, a tenant can manage multiple clusters.

[0075] As an example: A company has a headquarters, a first branch located in a first region, and a second branch located in a second region. Due to geographical limitations, the headquarters, the first branch, and the second branch can only deploy clusters A, B, and C respectively. The company manages three clusters: cluster A, cluster B, and cluster C. The above example illustrates geographical limitations; business and technical limitations are similar and will not be elaborated upon here.

[0076] Similarly, due to different query needs at different levels within an enterprise, a cluster can belong to different tenants.

[0077] As an example: Department 1 of a company is the superior department of Department 2. Cluster A is converted to handle the business deployment of Department 2. Department 2 needs to query the operation index data of Cluster A to understand its own business situation. Department 1 needs to query the operation index data of Cluster A to understand the business situation of its subordinate Department 2. Therefore, Cluster A belongs to Department 1 and Department 2.

[0078] Alternatively, there is no hierarchical relationship between the first department and the second department of a certain enterprise. Cluster A is used to process the first business of the first department and the second business of the second department. The first department needs to query the operational indicator data related to the first business in Cluster A to understand the business situation of the first business, and the second department needs to query the operational indicator data related to the second business in Cluster A to understand the business situation of the second business. Therefore, Cluster A belongs to the first department and the second department.

[0079] Therefore, in a multi-cluster, multi-tenant architecture, the relationship between clusters and tenants is entirely based on actual applications.

[0080] This application provides a monitoring method applicable to multi-cluster, multi-tenant metric monitoring scenarios. Upon receiving a query instruction from a target tenant, the method identifies the clusters managed by that tenant. Then, based on the communication connection established with the clusters managed by the target tenant, it queries the operational metric data of those clusters. Finally, it returns the query results to the target tenant based on the operational metric data. Each cluster stores its own monitoring data separately, and upon receiving a query instruction from a tenant, it only queries the monitoring data of the multiple clusters managed by that tenant, thus achieving tenant isolation between the storage and query of monitoring data. Furthermore, by returning query results to the tenant based on the monitoring data of the multiple clusters managed by that tenant, a globally unified query of multi-cluster monitoring data can be achieved.

[0081] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0082] Please refer to Figure 2 This illustrates the implementation environment of a monitoring method provided in an embodiment of this application. For example... Figure 2 As shown, the implementation environment includes: a terminal device 201 and a management device 202, the management device 202 being connected to, for example... Figure 1 In the illustrated embodiment, multiple clusters establish communication connections. Each cluster deploys a monitoring instance, which can be deployed outside the cluster or on a node within the cluster that is distinct from the management node (or master node, control node) and worker nodes. It is a complete monitoring system designed for the cluster, used to collect, store, query, and alarm on the operational metrics data of the cluster's management node (or master node, control node) and worker nodes.

[0083] The terminal device 201 is used to send a query instruction for the target tenant to the management device 202. The query instruction may include information such as the operation indicators to be queried, the query period, and the processing strategy. The query period is used to indicate the query time range, and the processing strategy is used to indicate the expected query results, such as: querying the average value of the operation indicator data in multiple clusters under management, or querying the largest operation indicator values ​​in multiple clusters under management.

[0084] Management device 202 is used to respond to a query instruction sent by terminal device 201 to a target tenant, determine a target cluster from multiple clusters, wherein the target cluster is a cluster managed by the target tenant; query the operating indicator data of the target cluster from the monitoring instances deployed in the target cluster; and return the query results to the target tenant based on the operating indicator data.

[0085] In one possible implementation, the management device 202 can send a data query request to the monitoring instance deployed in the target cluster, the data query request specifying the query metric and query period; and then receive the operating metric data returned by the monitoring instance deployed in the target cluster.

[0086] Alternatively, management device 202 can directly pull the target cluster's operational metrics data from the monitoring instance of the target cluster.

[0087] The aforementioned terminal device 201 may be at least one of the following: smartphone, smartwatch, desktop computer, laptop, virtual reality terminal, augmented reality terminal, wireless terminal, and laptop computer.

[0088] The aforementioned management device 202 can be a server that provides a unified global query service for multi-cluster monitoring data. This server can be an independent physical server, such as a general-purpose server, a graphics processing unit (GPU) server, a data processing unit (DPU) server, or a server cluster or distributed file system composed of multiple physical servers. Alternatively, it can be at least one of the following cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and big data. This application embodiment does not limit this.

[0089] The monitoring method provided in this application embodiment can be applied to the management device 202 described above.

[0090] It should be noted that the number of terminal devices 201 and management devices 202 can be one or more. When there are multiple management devices 202, each terminal device communicates with at least one management device 202, and all management devices 202 communicate with all clusters and share information with each other. In this way, multiple management devices can share the query tasks, avoiding the slow query situation caused by all query tasks being concentrated on one management device.

[0091] Figure 3 This is a schematic diagram of the hardware structure of a management device provided in an embodiment of this application. See also... Figure 3 The hardware of this management device includes a processor, a basic input / output system (BIOS) chip, an out-of-band controller, and memory. The software primarily includes the BIOS, an out-of-band management module, and an operating system (OS), such as... Figure 3 As shown in the figure, this application provides a structural schematic diagram of a management device.

[0092] A processor may include a central processing unit (CPU), which contains one or more CPU cores. All data processing operations of the CPU are performed by the CPU cores. The more CPU cores a CPU contains, the faster it can process data.

[0093] The BIOS chip is a chip located on the motherboard that manages the initialization and detection of various hardware components during the power-on process. The BIOS chip includes a flash memory area.

[0094] The out-of-band management module is located within the out-of-band controller, while the operating system is located within the processor.

[0095] Out-of-band management modules can be management units for non-business modules. For example, an out-of-band management module can remotely maintain and manage the management device through a dedicated data channel. This out-of-band management module is completely independent of the management device's operating system and can communicate with the BIOS and operating system through the management device's out-of-band management interface.

[0096] For example, an out-of-band management module may include a management unit for managing the operating status of the device, a management system in the management chip, a baseboard management controller (BMC), a system management mode (SMM), etc. It should be noted that the specific form of the out-of-band management module is not limited in the embodiments of this application; the above is merely an illustrative example.

[0097] An operating system (OS) is a computer program that manages and controls the hardware and software resources of a managed device. Any other software must run with the support of an operating system. After the managed device is powered on, the BIOS first performs a series of operations, including self-test and initialization, and then boots the OS, allowing the user to use the managed device normally.

[0098] BIOS is a set of programs embedded in the BIOS chip on the motherboard within the management device. The main function of BIOS is to provide the lowest-level and most direct hardware settings and control for the management device.

[0099] Memory, also known as internal memory or main memory, is installed in memory slots on the motherboard of the management device.

[0100] It should be noted that the system architecture and application scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new application scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0101] Figure 4 This is a flowchart illustrating a monitoring method provided in an embodiment of this application. See also... Figure 4 This method is applied to a management device that communicates with multiple clusters respectively; the method includes:

[0102] S401: In response to the query command of the target tenant, determine the target cluster among multiple clusters.

[0103] The target tenant is a tenant in a multi-cluster, multi-tenant architecture. It uses its own authorized terminal device to communicate with the execution entity (such as...) of this application embodiment. Figure 2 The management device 202 in the illustrated embodiment sends a query command.

[0104] In one possible implementation, the query instruction may include a tenant identifier. When the execution entity receives the query instruction, it identifies the tenant to be queried (i.e., the target tenant) through the tenant identifier in the query instruction.

[0105] Before determining the target cluster from multiple clusters, the process also includes: validating the query command and suspending the operation if the validation fails.

[0106] The above-mentioned validation of query commands verifies whether the query command originates from an authorized terminal device of the target tenant. Responding only to queries that pass validation ensures that each tenant can only view operational metric data for the clusters they manage, preventing the leakage of sensitive tenant data and guaranteeing tenant data security.

[0107] The above-mentioned validation of the query command's validity may include:

[0108] Determine the device ID that sent the query command, send the device ID to the target tenant, and receive a message from the target tenant indicating whether the terminal device corresponding to the device ID is an authorized terminal device of the target tenant; if the terminal device corresponding to the device ID is not an authorized terminal device of the target tenant, the validity verification is determined to fail; if the terminal device corresponding to the device ID is an authorized terminal device of the target tenant, the validity verification is determined to pass.

[0109] The above-mentioned verification of the validity of the query command may further include: determining the device ID that sent the query command, matching the device ID in the authorized device ID record table corresponding to the target tenant with the device ID; determining that the validity verification failed if the matching was unsuccessful; and determining that the validity verification passed if the matching was successful.

[0110] The above device ID is a string of characters or numbers that uniquely identifies a terminal device.

[0111] In one possible implementation, the target cluster is the cluster managed by the target tenant. The process of determining the target cluster from multiple clusters includes: communicating with the target tenant to determine the cluster managed by the target tenant; and identifying the cluster managed by the target tenant as the target cluster.

[0112] Alternatively, query the clusters managed by the target tenant from the cluster information registry, where the cluster information registry records at least one cluster and its associated tenant.

[0113] S402. Query the target cluster's operational metrics data.

[0114] In one possible implementation, the target cluster has one or more data sets. After the target cluster is determined, the operational metrics data of one or more target clusters are queried.

[0115] In one possible implementation, the above query for the target cluster's operational metrics data may include: querying the operational metrics data corresponding to all monitored operational metrics of the target cluster; or querying the operational metrics data corresponding to the target operational metrics monitored by the target cluster.

[0116] The target operating metrics mentioned above can be the operating metrics to be queried as indicated in the query command, or they can be pre-specified operating metrics. The target operating metrics for different clusters can be the same or different.

[0117] In one possible implementation, one operational indicator corresponds to one indicator identifier. The query instruction includes the indicator identifier of the operational indicator to be queried, and the operational indicator to be queried is determined based on the indicator identifier.

[0118] In one possible implementation, the above query for the target cluster's operational metrics data may include: querying the target cluster's operational metrics data for a first target query period, where the first target query period is the query period indicated in the query instruction.

[0119] Understandably, by specifying query time and query metrics, the scope of metric data can be reduced, thereby improving query performance.

[0120] In one possible implementation, a monitoring instance is deployed in a cluster, and the target cluster's operational metrics data are queried based on the monitoring instance deployed in the target cluster; the monitoring instance can be a Prometheus instance.

[0121] Among them, the above-mentioned monitoring instance based on the target cluster deployment can query the target cluster's operational metric data in multiple ways.

[0122] For example, in the first implementation, considering that there is storage isolation between multiple monitoring instances deployed in different clusters due to geographical, business, and technical limitations, the operation metric data of multiple monitoring instances (child nodes) are aggregated into a master monitoring instance (master node) through a federation mechanism. The master monitoring instance then queries the operation metric data of the target cluster. Here, storage isolation can be understood as the mutual isolation of data storage spaces to ensure that they cannot be accessed or interfered with at will.

[0123] This implementation breaks down storage isolation between multiple monitoring instances, achieving centralized data storage. However, it also makes it difficult to achieve tenant isolation for data storage and querying. Moreover, in large-scale cluster scenarios, because data storage and querying are all performed on a single monitoring instance, there are issues such as slow processing speed and memory overload leading to process termination.

[0124] The second implementation involves monitoring instances only collecting runtime metric data. Data storage and subsequent query processing are handled by a third-party component via an agent or remote write. This approach ensures reliable performance in large-scale cluster scenarios. However, since the data is still stored centrally, it makes it difficult to achieve tenant isolation between data storage and querying.

[0125] To overcome the problems of the two implementation methods mentioned above, this application adopts a third implementation method: pulling the target cluster's operational metrics data from the monitoring instances deployed on the target cluster. Since the operational metrics data of each cluster are stored on its own side, and the query of operational metrics data is only directed to the tenant corresponding to the cluster, tenant isolation between data storage and query is achieved.

[0126] S403. Return query results to the target tenant based on operational indicator data.

[0127] In one possible implementation, after retrieving the operational metrics data of one or more target clusters, the operational metrics data is normalized, bad data is removed, and the processed data is returned to the target tenant as the query result.

[0128] Alternatively, based on the processing strategy in the query command, the operational indicator data can be processed to obtain the query results, which are then returned to the target tenant.

[0129] Specifically, based on the processing strategy in the query command, the query results are obtained after performing certain data processing on the operational indicator data, including:

[0130] The target aggregation algorithm is used to process the operational indicator data to obtain the query results. The target aggregation algorithm is a data processing algorithm that corresponds to the processing strategy indicated by the query command.

[0131] As an example, when the processing strategy is to determine the K largest operating indicator data in the target operating indicators, the target aggregation algorithm is the topK algorithm, which sorts all the operating indicator data in the target operating indicators in descending order and selects the K largest operating indicator data as the return result.

[0132] As an example, when the processing strategy is to determine the average value of the target performance indicator data, the target aggregation algorithm is an average value algorithm, which takes the average value of all the performance indicator data in the target performance indicator and returns the average value as the result.

[0133] The technical solution provided in this application, upon receiving a query instruction from a target tenant, determines the clusters managed by the target tenant, then queries the operational metrics data of the clusters managed by the target tenant; finally, it returns the query results to the target tenant based on the operational metrics data. Since each cluster stores its own monitoring data separately, and upon receiving a query instruction from a tenant, only the monitoring data of multiple clusters managed by that tenant is queried, the storage of monitoring data and the tenant querying it are isolated. Compared to related technologies, this ensures that the monitoring data of each tenant is not leaked to other parties, guaranteeing data privacy. Furthermore, returning query results to the tenant based on the monitoring data of multiple clusters managed by the tenant allows the tenant to view the operational status and performance metrics of the clusters they manage from a unified perspective, facilitating the rapid identification and resolution of problems.

[0134] Figure 5 This is a flowchart illustrating a monitoring method provided in an embodiment of this application. See also... Figure 5 This method is applied to a management device that communicates with multiple clusters; each cluster belongs to at least one tenant, and each tenant manages at least one cluster; the method includes:

[0135] S501. In response to receiving a query command from the target tenant, determine the cluster managed by the target tenant based on the cluster information registry.

[0136] The aforementioned cluster information registry records at least one cluster and its associated tenant. This cluster information registry can be updated over time, dynamically enabling the binding of clusters and tenants.

[0137] In one possible implementation, upon receiving a query command from a target tenant, the system first filters tenants based on a cluster information registry to determine the clusters managed by the target tenant. Specifically, the system searches the cluster information registry for the target tenant, and the clusters corresponding to the found target tenant are identified as the clusters managed by the target tenant. By filtering the clusters managed by the target tenant through a table lookup, the system ensures tenant isolation for subsequent queries.

[0138] In one possible implementation, the aforementioned cluster information registry also records the cluster status of at least one cluster, including running status and non-running status.

[0139] The above-mentioned determination of the clusters managed by the target tenant based on the cluster information registry includes: querying the clusters managed by the target tenant within the range of clusters that are in operation in the cluster information registry.

[0140] It's understandable that "running state" refers to the normal working state, and "non-running state" refers to the non-working state. Since clusters that are not in a normal state are unlikely to respond to monitoring data query requests, querying monitoring data from these clusters is useless and wasteful of resources. Therefore, clusters are only selected from those in a normal state to avoid resource waste and improve subsequent query efficiency.

[0141] In one possible implementation, the aforementioned execution entity updates the cluster information registry in response to cluster and / or tenant update operations.

[0142] The above update operations include: adding, deleting, and modifying. When adding, deleting, or modifying a cluster, the cluster information recorded in the cluster registry is updated; when adding, deleting, or modifying a tenant, the tenant corresponding to the cluster recorded in the cluster information registry is updated. The cluster information registry is updated as the clusters and tenants change, thereby ensuring the accuracy of tenant selection.

[0143] S502. Determine the target cluster based on the corresponding indicator registry of each cluster managed by the target tenant.

[0144] The query command above specifies the operating indicator to be queried, thus ensuring that the query is performed only on the operating indicator specified in the query command.

[0145] The above-mentioned registry records the monitored operational metrics in the corresponding cluster.

[0146] The target cluster mentioned above is the cluster managed by the target tenant that has its target operating metrics monitored.

[0147] Understandably, after the tenant screening process determines the clusters managed by the target tenant, the aforementioned execution entity performs indicator screening based on the indicator registry corresponding to each cluster managed by the target tenant, and identifies the target cluster from the clusters managed by the target tenant.

[0148] The aforementioned registry of metrics can be updated over time, dynamically binding clusters and monitoring metrics. It automatically filters clusters based on monitoring metrics, reducing the number of clusters requiring subsequent processing and improving query performance.

[0149] In one possible implementation, determining the target cluster based on the respective indicator registry of the clusters managed by the target tenant includes: for each cluster managed by the target tenant, querying the indicator registry corresponding to that cluster to determine whether the monitored operating indicators of that cluster include the target operating indicators, and then determining that the cluster is the target cluster.

[0150] In one possible implementation, the management device includes multiple Bloom filters corresponding one-to-one with multiple clusters, and these multiple Bloom filters are configured based on the metric registry of the multiple clusters; determining the target cluster based on the metric registry corresponding to each cluster managed by the target tenant includes:

[0151] Based on the query command, the system uses the Bloom filter corresponding to each cluster in the cluster managed by the target tenant to determine whether each cluster in the cluster managed by the target tenant is a cluster with the monitored target operating metric; and identifies the target cluster as the cluster with the monitored target operating metric in the cluster managed by the target tenant.

[0152] Figure 6 This is a schematic diagram of an indicator screening process provided in an embodiment of this application, such as... Figure 6 As shown, during the tenant screening phase, clusters A, B, and C are selected as clusters managed by the target tenant. Then, a query request to check whether the target operating metric exists is sent to the Bloom filters corresponding to each of clusters A, B, and C. The Bloom filters corresponding to each of clusters A, B, and C return a message statement indicating whether the target metric exists or not, thus determining that the target clusters include clusters A and B.

[0153] The process of configuring a Bloom filter in the cluster-based metric registry includes: initializing a bit array of length m, with all bits initialized to 0; using k hash functions to process all metrics in the metric registry, where each of the k hash functions maps the metric to a different position in the bit array, and these bit array positions are set to 1.

[0154] During the query, it is determined whether the values ​​of the K positions mapped by the k hash functions to the queried indicator are all 1. If all K positions are 1, the queried indicator may exist; if any position is 0, the queried indicator definitely does not exist.

[0155] Understandably, using a Bloom filter for querying has a faster query speed than querying the metric registry. That is, for a specific operational metric, a Bloom filter can more quickly determine whether the monitored operational metrics of the corresponding cluster include that specific operational metric. Therefore, operational metric filtering based on Bloom filters can improve the speed of operational metric filtering.

[0156] Figure 7 This is a schematic diagram illustrating the working principle of a liveness detection component provided in an embodiment of this application. The liveness detection component is deployed in a management device and, through communication with each cluster, periodically detects the operating status of each cluster and the currently monitored operating indicators of each cluster. For example... Figure 7As shown, the aforementioned execution entity initially distributes all cluster-related information to the cluster information registry. The cluster-related information includes cluster ID, name, tenant, and cluster status. Subsequently, through its internally deployed liveness detection component, it periodically checks the cluster status and updates the cluster information registry using the detection results. By updating the cluster status of each cluster, the timeliness of tenant screening is ensured.

[0157] Specifically, the above-mentioned activity detection component periodically detects the cluster status, including: the activity detection component periodically obtains the metric data of each cluster through interfaces such as the status API and metrics API of each cluster; when the metric data of the cluster is obtained, it is determined that the cluster is in a running state; when the metric data of the cluster cannot be obtained, it tries to obtain the metric data of the cluster again, until the metric data of the cluster cannot be obtained after a first preset number of times, at which point it is determined that the cluster is in a non-running state.

[0158] The aforementioned status API and metrics API are both interfaces used to obtain and publish metric data. Through these interfaces, you can obtain various metric data of the system or application, such as CPU utilization and memory usage.

[0159] Furthermore, the aforementioned execution entity also periodically resets the Bloom filters corresponding to the clusters through a liveness detection component. Specifically, the execution entity maintains an index table connecting clusters to Bloom filters; the monitoring metric data for each cluster is stored in its respective metric registry. Subsequently, the liveness detection component within the execution entity, based on the cluster-to-Bloom filter index table, periodically polls each cluster to reset the corresponding Bloom filters.

[0160] Figure 8 This is a flowchart illustrating an embodiment of the present application for updating an index registry. Figure 8 As shown, the process includes:

[0161] The system detects the currently monitored operational metrics of the cluster; compares the detected operational metrics with the cluster's metric registry; updates the cluster's metric registry in response to discrepancies in the comparison results; and resets the corresponding Bloom filter for the cluster based on the updated metric registry.

[0162] In this embodiment of the application, the timeliness of indicator screening is ensured by resetting the Bloom filters corresponding to each cluster.

[0163] S503, Query the target cluster's operational metrics data.

[0164] S504. Determine the query results based on operational indicator data.

[0165] S505, Return the query results to the target tenant. Steps S503-S505 above have already been described in... Figure 3 Steps S402-S403 of the illustrated embodiment have been described in detail and will not be repeated here.

[0166] The technical solution provided in this application embodiment, upon receiving a query instruction from a target tenant, filters out the clusters managed by the target tenant and monitoring the target operating indicators through tenant filtering and indicator filtering, thereby reducing the range of clusters to be queried and improving query performance.

[0167] Furthermore, Figure 9 This is a flowchart illustrating another monitoring method provided in an embodiment of this application. See also... Figure 9 This method is applied to a management device that communicates with multiple clusters; each cluster belongs to at least one tenant, and each tenant manages at least one cluster; the method includes:

[0168] S901. In response to the query command of the target tenant, determine the target cluster among multiple clusters, wherein the target cluster is the cluster managed by the target tenant.

[0169] The above step S901 has been implemented as follows: Figure 5 Steps S501-S502 of the illustrated embodiment have been described in detail and will not be repeated here.

[0170] S902. Query the runtime metrics data within the first target query period from the cache shards corresponding to the target cluster.

[0171] In one possible implementation, the aforementioned operational indicator data can be the operational indicator data of the target operational indicator.

[0172] The management device maintains a buffer. Figure 10 This is a schematic diagram of the structure of a buffer provided in an embodiment of this application. Figure 10 As shown, the cache includes multiple cache shards that correspond one-to-one with multiple clusters; the cache shards store metric data in a three-layer cache structure; the first, second, and third layers of the three-layer cache structure are the cluster name, the metric name, and the time sequence of the runtime metric data marked with a timestamp, respectively.

[0173] Since a single query for a monitoring metric typically involves many time series and a large number of data points, a three-layer caching structure can enable fast data retrieval and improve query speed.

[0174] S903. Determine the second target query period, wherein the second target query period is a period that is not in the time period of the queried operating indicator data, but is in the first target query period.

[0175] Figure 11 This is a schematic diagram of an indicator data query mechanism provided in an embodiment of this application, such as... Figure 11 As shown, the cache shard corresponding to the target cluster buffers the running indicator data of running indicator A from 8:00 to 9:00. When a query request for running indicator data of running indicator A within the first target query period (8:05-9:05) is received from the cache shard corresponding to the target cluster, the running indicator data of running indicator A within the first target query period (8:05-9:05) is queried (i.e., the running indicator data of running indicator A during 8:05-9:00). Then, the time period (9:00-9:05) that is not within the time period (8:05-9:00) of the queried running indicator data is determined, but is within the first target query period (8:05-9:05), is designated as the second target query period. After that, only the running indicator data of running indicator A within the second target query period (9:00-9:05) of the target cluster needs to be queried, thus reducing the time span of real-time queries.

[0176] S904. Pull the operational metrics data of the target cluster for the second target query period from the monitoring instance deployed in the target cluster. There is one monitoring instance deployed for each cluster.

[0177] S905. Based on the retrieved and queried operational indicator data, obtain the operational indicator data of the target cluster during the first target query period.

[0178] It should be noted that the operational metrics data of the target cluster retrieved during the second target query period needs to be saved and integrated into the corresponding cache shard of the target cluster. For example, the operational metrics data of the target cluster A during the second target query period (9:00-9:05) should be saved in the corresponding cache shard of the target cluster. This cache shard will automatically integrate the operational metrics data of operational metrics A from 8:05-9:00 and from 9:00-9:05 to form the operational metrics data of operational metrics A from 8:00-9:05, thus laying the foundation for subsequent data queries.

[0179] In one possible implementation, the runtime metrics data in the cache shard is updated using the Least Recently Used algorithm, and metric names that do not exist in the cache shard are deleted.

[0180] Cache shards can use the Least Recently Used (LRU) algorithm to automatically move data that has not been accessed for a long time and retain only the most recently accessed data, thereby maintaining the size of the cache shards and reducing the use of storage resources.

[0181] S906. Return query results to the target tenant based on operational indicator data.

[0182] The above step S906 has been implemented as follows: Figure 4 Step S403 of the illustrated embodiment has been described in detail and will not be repeated here.

[0183] The technical solution provided in this application embodiment stores the past query performance index data of each cluster in the cache. When a query request for performance index data is received, the cached performance index data is first matched, and the time range that is not matched is extracted before querying. This reduces the time span of real-time query and improves query performance.

[0184] Figure 12 This is a schematic diagram of a monitoring device provided in an embodiment of this application. The monitoring device is applied to a management device, which is communicatively connected to multiple clusters; each cluster belongs to at least one tenant, and each tenant manages at least one cluster. See also... Figure 12 The monitoring device shown includes a determination module 1201, a query module 1202, and a result return module 1203. Among them,

[0185] The determination module 1201 is used to determine the target cluster among multiple clusters in response to the query command of the target tenant, wherein the target cluster is the cluster managed by the target tenant;

[0186] The query module 1202 is used to query the operational metrics data of the target cluster;

[0187] The result return module 1203 is used to return query results to the target tenant based on the operational indicator data.

[0188] The technical solution provided in this application, upon receiving a query instruction from a target tenant, determines the clusters managed by the target tenant, then queries the operational metrics data of the clusters managed by the target tenant; finally, it returns the query results to the target tenant based on the operational metrics data. Since each cluster stores its own monitoring data separately, and upon receiving a query instruction from a tenant, only the monitoring data of multiple clusters managed by that tenant is queried, the storage of monitoring data and the tenant querying it are isolated. Compared to related technologies, this ensures that the monitoring data of each tenant is not leaked to other parties, guaranteeing data privacy. Furthermore, returning query results to the tenant based on the monitoring data of multiple clusters managed by the tenant allows the tenant to view the operational status and performance metrics of the clusters they manage from a unified perspective, facilitating the rapid identification and resolution of problems.

[0189] In some possible implementations, the target cluster is the cluster managed by the target tenant, which is the cluster whose target operating metrics are being monitored, where the target operating metrics are the operating metrics to be queried as indicated in the query command.

[0190] In some possible implementations, the determining module 1201 includes: a first determining unit and a second determining unit, wherein:

[0191] The first determining unit is used to determine the cluster managed by the target tenant based on the cluster information registry, wherein the cluster information registry records at least one cluster and its tenant.

[0192] The second determining unit is used to determine the target cluster based on the indicator registry corresponding to each cluster managed by the target tenant, wherein the indicator registry records the monitored operating indicators in the corresponding cluster.

[0193] In some possible implementations, the cluster information registry also records the cluster status of at least one cluster, including running status and non-running status.

[0194] The first determining unit is specifically used to: query the clusters managed by the target tenant within the clusters that are in the running state in the cluster information registry.

[0195] In some possible implementations, the management device includes multiple Bloom filters that correspond one-to-one with multiple clusters, and these multiple Bloom filters are configured based on the indicator registry of multiple clusters;

[0196] The aforementioned second determining unit includes: a first determining subunit and a second determining subunit, wherein:

[0197] The first determining subunit is used to determine, based on the query command, whether each cluster in the cluster managed by the target tenant is a cluster of the monitored target operating metrics through the Bloom filter corresponding to each cluster in the cluster managed by the target tenant.

[0198] The second determination subunit is used to determine the target cluster from the clusters managed by the target tenant that have their target operating metrics monitored.

[0199] In some possible implementations, the query module 1202 includes: a query unit, wherein:

[0200] The query unit is used to query the operational metrics data of the target cluster during the first target query period.

[0201] In some possible implementations, the operational indicator data is the indicator data corresponding to the target operational indicator, where the target operational indicator is the operational indicator to be queried as indicated in the query command.

[0202] In some possible implementations, a cluster deployment includes a monitoring instance and a query unit, including:

[0203] The first pull subunit is used to pull the target cluster's operational metrics data for the first target query period from the monitoring instances deployed on the target cluster.

[0204] In some possible implementations, the management device includes multiple cache shards corresponding one-to-one with multiple clusters; one monitoring instance is deployed for each cluster; the aforementioned query unit includes: a query subunit, a third determination subunit, a second pull subunit, and a fourth determination subunit, wherein:

[0205] The query subunit is used to query the runtime metric data within the first target query period from the cache shard corresponding to the target cluster. The cache shard stores the metric data in a three-layer cache structure. The first, second, and third layers of the three-layer cache structure are the cluster name, the metric name, and the time sequence of runtime metric data marked with a timestamp, respectively.

[0206] The third determining subunit is used to determine the second target query period, wherein the second target query period is a period that is not in the time period of the queried operation indicator data, but is in the first target query period;

[0207] The second pull subunit is used to pull the target cluster's operational metrics data for the second target query period from the monitoring instances deployed on the target cluster.

[0208] The fourth determination subunit is used to obtain the target cluster's operational indicator data for the first target query period based on the retrieved and queried operational indicator data.

[0209] In some possible implementations, the above apparatus further includes: a first update unit; wherein the first update unit is configured to update the runtime metric data in the cache shard using a least recently used algorithm; and to delete metric names in the cache shard where runtime metric data does not exist.

[0210] In some possible implementations, the above result return module 1203 includes: a processing unit and a return unit;

[0211] The processing unit is used to process the running indicator data using the target aggregation algorithm to obtain the query results. The target aggregation algorithm is a data processing algorithm corresponding to the processing strategy indicated by the query command.

[0212] The return unit is used to return the query results to the target tenant.

[0213] In some possible implementations, the above apparatus further includes: a second updating unit; wherein the second updating unit is used to periodically detect the cluster status of the cluster and update the cluster information registry using the detection results.

[0214] In some possible implementations, the above apparatus further includes: a third update unit; wherein the third update unit is configured to: periodically detect the monitored operating metrics of the cluster; compare the detected operating metrics with the cluster's metric registry; update the cluster's metric registry in response to a discrepancy in the comparison results; and reset the Bloom filter corresponding to the cluster based on the updated metric registry.

[0215] In some possible implementations, the above apparatus further includes: a fourth update unit; wherein the fourth update unit is configured to: update the cluster recorded in the cluster information registry in response to a cluster update operation; and update the tenant corresponding to the cluster recorded in the cluster information registry in response to a tenant update operation.

[0216] This application also provides a management device, which includes a processor and a memory coupled together. The memory stores computer program instructions, and the processor invokes these instructions to execute the monitoring method described in the above embodiments.

[0217] This application also provides a computer-readable storage medium storing computer program instructions for causing a management device to perform the monitoring method shown in the above embodiments.

[0218] This application also provides a computer program product, including computer program instructions, which, when run on a management device, cause the management device to perform the monitoring method shown in the above embodiments.

[0219] In this application, the management device, computer-readable storage medium, or computer program product provided in the embodiments are all used to execute the corresponding methods described above. Therefore, the beneficial effects they can achieve can be referred to in the beneficial effects of the corresponding methods described above, and will not be repeated here.

[0220] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device (such as an electronic device) can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device (such as an electronic device), and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

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

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

[0223] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0224] If the aforementioned integrated units are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.

[0225] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A monitoring method, characterized in that, It is applied to management devices, which are communicatively connected to multiple clusters respectively; The cluster belongs to at least one tenant, and the tenant manages at least one of the clusters; The monitoring method includes: In response to a query command from a target tenant, a target cluster is determined from the plurality of clusters, wherein the target cluster is a cluster managed by the target tenant; Query the operational metrics data of the target cluster, which represent the cluster's operational status and performance indicators; The query results are returned to the target tenant based on the operational metrics data.

2. The method according to claim 1, characterized in that, The target cluster is the cluster managed by the target tenant that has its target operating metrics monitored, wherein the target operating metrics are the operating metrics to be queried as indicated in the query instruction.

3. The method according to claim 2, characterized in that, The step of determining the target cluster among the plurality of clusters includes: Based on the cluster information registry, the cluster managed by the target tenant is determined, wherein the cluster information registry records at least one cluster and its associated tenant; The target cluster is determined based on the indicator registry corresponding to each cluster managed by the target tenant, wherein the indicator registry records the monitored operating indicators in the corresponding cluster.

4. The method according to claim 3, characterized in that, The cluster information registry also records the cluster status of at least one of the clusters, including running status and non-running status; Determining the target cluster based on the cluster information registry includes: querying the clusters managed by the target tenant within the range of clusters in the running state in the cluster information registry.

5. The method according to claim 3, characterized in that, The management device includes multiple Bloom filters that correspond one-to-one with the multiple clusters, and the multiple Bloom filters are configured based on the indicator registry of the multiple clusters; The step of determining the target cluster based on the respective indicator registry of the clusters managed by the target tenant includes: Based on the query instruction, the Bloom filter corresponding to each cluster in the cluster managed by the target tenant is used to determine whether each cluster in the cluster managed by the target tenant is a cluster of the monitored target operating indicators. The target cluster is identified by monitoring the target operating metrics within the cluster managed by the target tenant.

6. The method according to claim 1, characterized in that, The query of the target cluster's operational metrics data includes: Query the operational metrics data of the target cluster during the first target query period.

7. The method according to claim 6, characterized in that, The operational indicator data is the indicator data corresponding to the target operational indicator, wherein the target operational indicator is the operational indicator to be queried as indicated in the query instruction.

8. The method according to claim 6 or 7, characterized in that, A cluster is deployed with one monitoring instance. The query for the target cluster's operational metrics data during the first target query period includes: Pull the operational metrics data of the target cluster for the first target query period from the monitoring instance deployed in the target cluster.

9. The method according to claim 6 or 7, characterized in that, The management device includes multiple cache shards that correspond one-to-one with the multiple clusters; A cluster is deployed with one monitoring instance. The query for the target cluster's operational metrics data during the first target query period includes: The system queries the runtime metrics data within the first target query period from the cache shard corresponding to the target cluster. The cache shard stores metrics data in a three-layer cache structure. The first, second, and third layers of the three-layer cache structure are the cluster name, the metrics name, and the time sequence of runtime metrics data marked with a timestamp, respectively. Determine a second target query period, wherein the second target query period is a period that is not within the time period of the queried operational indicator data, but is within the first target query period; Pull the operational metrics data of the target cluster for the second target query period from the monitoring instance deployed in the target cluster; Based on the retrieved and queried operational indicator data, the operational indicator data of the target cluster during the first target query period are obtained.

10. The method according to claim 9, characterized in that, The method further includes: updating the runtime metric data in the cache shard using the least recently used algorithm; and deleting metric names in the cache shard that do not contain runtime metric data.

11. The method according to claim 1, characterized in that, The step of returning query results to the target tenant based on the operational metric data includes: The target aggregation algorithm is used to process the operational indicator data to obtain the query result, wherein the target aggregation algorithm is a data processing algorithm corresponding to the processing strategy indicated by the query command; Return the query results to the target tenant.

12. The method according to claim 4, characterized in that, The method further includes: periodically detecting the cluster status of the cluster and updating the cluster information registry using the detection results.

13. The method according to claim 5, characterized in that, The method further includes: Periodically detect the monitored operational metrics of the cluster; The detected operational metrics are compared with the cluster's metric registry. In response to inconsistent comparison results, update the cluster's metric registry; The Bloom filter corresponding to the cluster is reset based on the updated metrics registry.

14. The method according to claim 5, characterized in that, The method further includes: In response to the cluster update operation, the cluster information recorded in the cluster information registry is updated; in response to the tenant update operation, the tenant corresponding to the cluster recorded in the cluster information registry is updated.

15. A management device, characterized in that, It includes a memory and a processor; the memory and the processor are coupled; the memory is used to store computer program code, the computer program code including computer instructions; wherein, when the processor invokes the program instructions to perform the method as described in any one of claims 1-14.

Images