A cloud-native monitoring system

Abstract

The present invention relates to the field of computer technology, and in particular to a cloud-native monitoring system. The system includes: a master application and multiple slave applications; the multiple slave applications are respectively deployed in each node of the cluster, and each slave application is used to collect the resource usage data of the node based on concurrent queries, and the resource usage data includes Pod granularity data, namespace granularity data, and graphics card granularity data; the master application is used to obtain the resource usage data collected by each slave application based on a preset communication protocol, and perform node resource usage analysis and task resource usage analysis based on the resource usage data. The present invention reduces the time required for querying by concurrently querying resource usage data, significantly reduces data collection time, and improves the real-time performance of the monitoring system. At the same time, in terms of resource monitoring granularity, it can more comprehensively understand the resource usage at different levels in the cluster, provide users with more accurate data, and bring more flexibility to the monitoring system.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a cloud-native-based monitoring system. Background Art

[0002] As big data scenarios and new large models continue to emerge in the industry, meeting huge training needs has become an important challenge for machine learning platforms. In order to cope with the huge computing power required for large-scale training, cloud-native architectures with elastic expansion and high availability have gradually become the mainstream choice for machine learning platforms. In this architecture, Kubernetes has become an ideal platform for running machine learning workloads with its excellent expansion and distribution characteristics, as well as its powerful scheduling capabilities.

[0003] When running machine learning tasks on a single node, users can evaluate the execution status of the task by monitoring indicators such as the current node's CPU utilization, memory utilization, graphics core utilization, and video memory utilization. However, in a cloud-native environment, tasks are usually run simultaneously in the form of multiple containers. Although the running status can be viewed in each independent container, when the number of containers is large or multiple node tasks are running simultaneously, manually checking the status of each container becomes inconvenient and prone to omissions. Summary of the invention

[0004] In view of this, the present invention provides a cloud-native-based monitoring system to solve the problem that container status checking is inconvenient and prone to omissions.

[0005] The present invention provides a cloud-native-based monitoring system, the system comprising: a master application and multiple slave applications; the multiple slave applications are respectively deployed in each node of a cluster, each slave application is used to collect resource usage data of the node based on concurrent queries, the resource usage data includes Pod granularity data, namespace granularity data and graphics card granularity data; the master application is used to obtain the resource usage data collected by each slave application based on a preset communication protocol, and perform node resource usage analysis and task resource usage analysis according to the resource usage data.

[0006] The cloud-native monitoring system provided in this embodiment deploys multiple sub-applications in each sub-node, and each sub-application concurrently queries the resource usage data in the corresponding node, thereby reducing the time required for querying and significantly reducing the data collection time. As a result, the monitoring system is more timely and can quickly respond to changes in resource usage, thereby improving the real-time performance of the monitoring system. At the same time, in terms of resource monitoring granularity, the collection of Pod granularity data, namespace granularity data, and graphics card granularity data is implemented, thereby enabling a more comprehensive understanding of resource usage at different levels in the cluster. This fine-grained monitoring provides users with more accurate data, helps to better optimize and manage the resources of machine learning tasks, and brings more flexibility to the monitoring system.

[0007] In an optional implementation, the preset communication protocol adopts a communication protocol of a remote procedure call framework.

[0008] In this embodiment, by using a gRPC-based communication solution, the communication between the master and slave applications is made more efficient. This communication solution uses HTTP / 2 as the underlying transport protocol, implements multiplexing, header compression, and streaming, and further improves the performance of communication. The advantage of this communication solution is that it reduces communication latency while providing higher throughput, making the monitoring system more stable and reliable.

[0009] In an optional embodiment, each slave application is also used to use a cluster monitoring tool to obtain statistical data of all Pods in the cluster as Pod granularity data, and the statistical data include CPU utilization and memory usage; each slave application is also used to call an operation interface related to the namespace in the cluster, and obtain the usage of each namespace in the cluster in a multi-threaded manner as namespace granularity data; each slave application is also used to call an application programming interface based on a C language management library to obtain status data of the graphics card device as graphics card granularity data, and the status data includes graphics card core utilization and memory utilization.

[0010] In an optional implementation, each sub-application is further used to filter and count the scope of the namespace according to the configuration of the query rule; each sub-application is further used to adjust the collected resource usage data according to the adjusted code logic.

[0011] In an optional embodiment, the main application is also used to obtain resource usage data collected by each slave application based on active query and timed recording to perform node resource usage analysis. The active query includes obtaining the resource usage data collected by each slave application by calling an interface service based on network interface logic. The timed recording includes obtaining the resource usage data collected by each slave application according to a preset time interval of a timed task.

[0012] In this embodiment, the monitoring system achieves low-latency optimization between master and slave nodes through two execution schemes: active query and timed recording.

[0013] In an optional embodiment, the main application is also used to filter the acquired resource usage data, and divide the resource usage data according to tasks to obtain resource usage data for each task, perform task-level resource usage analysis based on the resource usage data for each task, and store the analyzed data in a preset format.

[0014] In this embodiment, in terms of multi-granularity resource usage analysis, deeper data mining and analysis are achieved through node resource usage analysis and task resource usage analysis. The combination of scheduled recording and active query enables the monitoring system to provide real-time node resource usage and record historical data according to user needs, providing users with more comprehensive and long-term resource usage trend analysis.

[0015] In an optional implementation, the system further includes: a display module; the display module is used to display the resource usage data in a personalized manner.

[0016] In this embodiment, by setting up a display module, an intuitive resource usage display is provided, such as the resource usage analysis and display of various granularities such as task usage, namespace resource usage, and node resource usage. At the same time, users can customize the monitoring panel according to their own needs and obtain key information more conveniently.

[0017] In an optional implementation, the multiple slave applications are deployed in any cluster according to files for building container images and command line tools for operating the cluster.

[0018] In an optional implementation, the configuration file of the system performs custom configuration on the adjustment of the data serialization format file based on cluster rules.

[0019] In an optional implementation, the system expands or reduces the number of instances according to changes in load.

[0020] In terms of portability and security, this embodiment uses a cloud-native architecture solution based on Kubernetes, so that the monitoring system can automatically expand or reduce the number of instances according to changes in load. This ensures that the system can provide more resources when the load is high and effectively release resources when the load is low, thereby improving the efficiency of the system. The configuration of the monitoring system can also be defined and updated declaratively. This simplifies the configuration management process and makes it possible to modify the granularity of monitoring more flexibly. In addition, multi-environment deployment can be achieved, and the monitoring system can be easily deployed on the Kubernetes platform of different cloud service providers or private data centers. This provides greater flexibility and portability, making the system more adaptable to different deployment requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0022] Figure 1 is a schematic diagram of a cloud-native based monitoring system according to an embodiment of the present invention. DETAILED DESCRIPTION

[0023] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0024] This embodiment provides a cloud-native monitoring system, such as Figure 1 As shown, the system includes: a master application and multiple slave applications; the multiple slave applications are deployed in each node of the cluster respectively, each slave application is used to collect resource usage data of the node based on concurrent queries, and the resource usage data includes Pod granularity data, namespace granularity data and graphics card granularity data; the master application is used to obtain the resource usage data collected by each slave application based on a preset communication protocol, and perform node resource usage analysis and task resource usage analysis based on the resource usage data. Among them, Pod is the smallest unit that can be created and managed in the Kubernetes system. Pod is composed of one or more containers, and the containers in a pod share a network namespace.

[0025] Specifically, this embodiment uses DeamonSet to deploy multiple sub-applications to each node of the cluster. DeamonSet is a controller that monitors the node status in the cluster. Once a new node joins the cluster, the controller can trigger some operations. Therefore, this embodiment deploys the Worker sub-application to each node in the cluster through DaemonSet, so that the sub-application can collect resource usage data of the node at the same time. At the same time, this embodiment uses Deployment to deploy the main application. Deployment is a replica controller in Kubernetes, which is used to deploy applications. Among them, the system includes two executable program files, one is the main application and the other is the sub-application. After running the deployment file, they are deployed independently, that is, multiple sub-applications run independently in different nodes, and the main node and multiple sub-applications communicate using a preset communication protocol.

[0026] It should be noted that the monitoring system can be a monitoring system for a machine learning platform, that is, the monitoring system is used to monitor the workload of machine learning to ensure the execution of machine learning tasks.

[0027] The cloud-native monitoring system provided in this embodiment deploys multiple sub-applications in each sub-node, and each sub-application concurrently queries the resource usage data in the corresponding node, thereby reducing the time required for querying and significantly reducing the data collection time. As a result, the monitoring system is more timely and can quickly respond to changes in resource usage, thereby improving the real-time performance of the monitoring system. At the same time, in terms of resource monitoring granularity, the collection of Pod granularity data, namespace granularity data, and graphics card granularity data is implemented, thereby enabling a more comprehensive understanding of resource usage at different levels in the cluster. This fine-grained monitoring provides users with more accurate data, helps to better optimize and manage the resources of machine learning tasks, and brings more flexibility to the monitoring system.

[0028] In an optional implementation, the preset communication protocol adopts the communication protocol of the remote procedure call framework. Figure 1 As shown in the figure, when the main application and the sub-application communicate, a communication solution based on gRPC can be used. gRPC is a high-performance, open source RPC (Remote Procedure Call) framework that uses a binary-based protocol and adopts Protocol Buffers as the interface definition language. By defining interfaces and message types, it can easily generate codes in various languages, reducing the workload of manually writing interfaces and serialization / deserialization codes. At the same time, gRPC uses HTTP / 2 as the underlying transmission protocol, which can realize multiplexing, header compression, flow control and other features, providing lower latency and higher throughput.

[0029] In this embodiment, by adopting a communication solution based on gRPC and using binary protocols and Protocol Buffers, the communication between the master and slave applications is made more efficient. By using HTTP / 2 as the underlying transport protocol, multiplexing, header compression, and streaming are implemented, further improving the performance of communication. The advantage of this communication solution is that it reduces communication latency while providing higher throughput, making the monitoring system more stable and reliable.

[0030] In an optional implementation, each slave application is also used to use a cluster monitoring tool to obtain statistical data of all Pods in the cluster as Pod granularity data, and the statistical data include CPU utilization and memory usage; each slave application is also used to call an operation interface related to a namespace in the cluster, and obtain the usage of each namespace in the cluster in a multi-threaded manner as namespace granularity data; each slave application is also used to call an application programming interface based on a C language management library to obtain status data of a graphics card device as graphics card granularity data, and the status data includes graphics card core utilization and memory utilization.

[0031] Specifically, when performing node-level data statistics, the cluster monitoring tool Kubernetes MetricsClient is used to obtain detailed statistical information of all Pods in the cluster, including CPU utilization and memory usage, etc. When performing namespace-level data statistics, the namespace-related operation interface in the Kubernetes cluster can be called to obtain detailed usage of each namespace in the entire cluster. At the same time, when obtaining namespace-level data, multiple namespace data are obtained and processed simultaneously through multi-threading, so as to analyze the statistical data collected by the monitoring system to ensure efficient data collection and processing, and provide users with timely and comprehensive cluster resource status.

[0032] In addition, the monitoring system in the current related technology cannot monitor the status of the graphics card in the node. When running AI workloads, the graphics card is indispensable, and the expensive graphics card requires more comprehensive monitoring and scheduling to improve the utilization rate of the graphics card and reduce costs. The main method to solve the graphics card monitoring in the related technology is usually to use the monitoring plug-in provided by the graphics card manufacturer, but this also involves two problems: first, these monitoring plug-ins are limited to the graphics card part and cannot combine the graphics card status with the task; second, the deployment of the plug-in requires relevant experience to be effectively completed in the cluster. It can be seen that there are many problems with the current monitoring system for graphics card monitoring.

[0033] Based on this, in this implementation, by calling the C-based NVIDIA Management Library (NVML) API (Application Programming Interface), various states of NVIDIA GPU devices can be obtained. This includes data such as GPU core utilization and memory utilization required for the monitoring system. This achieves comprehensive statistics of graphics card resources, provides users with accurate GPU performance information, and facilitates more refined system monitoring and optimization.

[0034] In an optional implementation, each sub-application is also used to filter and count the scope of the namespace according to the configuration of the query rules; each sub-application is also used to adjust the collected resource usage data according to the adjusted code logic. Specifically, the monitoring system also supports the configuration of query rules, that is, the user can configure the namespace range for filtering statistics as needed, so that each sub-application can filter and count the scope of the namespace according to the configuration of the query rules, thereby achieving more flexible monitoring data customization. At the same time, the configuration file of the monitoring system can also be modified as needed to control whether the monitoring service of the specified granularity is turned on. In addition, the sub-application code logic can also be adjusted to add or modify indicators in the process of collecting device resource usage data, so as to obtain more information about the NVIDIA GPU device status and Kubernetes resource status. For example, an example of configuration parameters is as follows:

[0035] EnableModule:

[0036] namespaceanalyze: "enable"

[0037] jobanalyze: "enable"

[0038] remainresources: "enable"

[0039] resourcesservice: "enable"

[0040] In an optional embodiment, the main application is also used to obtain resource usage data collected by each slave application based on active query and timed recording to perform node resource usage analysis. The active query includes obtaining the resource usage data collected by each slave application by calling an interface service based on network interface logic. The timed recording includes obtaining the resource usage data collected by each slave application according to a preset time interval of a timed task.

[0041] Among the related technologies, the Kubernetes Dashboard component is usually used to comprehensively count the running status of containers in the Kubernetes cloud native platform. It supports viewing the CPU and memory usage of each Pod. However, this component only supports real-time monitoring information and cannot view historical data. As the number of cluster nodes increases, the Kubernetes Dashboard also has a display delay problem when counting node resource usage.

[0042] Based on this, in this implementation, the main application acquires data using a query method that combines real-time (active) and scheduled query methods, such as Figure 1 As shown, real-time resource usage analysis is used when querying remaining resources, and the resource usage of each node in the cluster is recorded in the database in the form of a scheduled task at other times, thereby alleviating statistical data delays and excessive pressure on the single-node query interface to a certain extent.

[0043] Specifically, the active query solution is implemented using Web interface logic. When the main application is started, the logic will run simultaneously. After the main application is running, the resource usage can be queried by calling the interface service, that is, when the interface is called, an additional query is performed and the latest real-time data statistics are returned. For the scheduled query solution, a scheduled task function is pre-set in the monitoring system. This function can automatically run the specified method function at the set time interval, that is, through the preset scheduled task, the main application can obtain and store the resource usage data collected by each sub-application through the scheduled task at the specified time interval. Therefore, the monitoring system achieves low-latency optimization between master and slave nodes through two execution schemes: active query and scheduled recording.

[0044] In an optional implementation, the main application is also used to filter the acquired resource usage data, and divide the resource usage data according to tasks to obtain resource usage data for each task, perform task-level resource usage analysis based on the resource usage data for each task, and store the analyzed data in a preset format. Specifically, by acquiring resource usage data, the CPU, memory, graphics card utilization, and video memory utilization of all Pods can be collected. There may be some unnecessary data in the acquired data, so the acquired data can be filtered according to pre-set rules. In addition, when a machine learning task is executed, there may be multiple Pods executing the same task, so the resource usage data of the same task can be integrated according to the task name executed by the node, so as to more clearly understand the resource consumption at the task level. At the same time, the acquired data and analysis results can be stored in the database in a preset unified format to facilitate users to query the task running status. As a result, the monitoring system achieves a comprehensive insight into task resources, and also provides users with a convenient and clear query interface through a standardized data format. Among them, such as Figure 1 As shown, when storing data in a public database, an ORM (Object-Relational Mapping) framework can be used, such as the GORM implementation in the GO language, which can make database operations simpler and more flexible.

[0045] In this embodiment, in terms of multi-granularity resource usage analysis, deeper data mining and analysis are achieved through node resource usage analysis and task resource usage analysis. The combination of scheduled recording and active query enables the monitoring system to provide real-time node resource usage and record historical data according to user needs, providing users with more comprehensive and long-term resource usage trend analysis.

[0046] In an optional embodiment, the system further includes: a display module; the display module is used to display the resource usage data in a personalized manner. Specifically, the display module provided in the monitoring system can visualize the collected data, and the display module provides users with an intuitive display of resource usage. The display module not only includes resource usage analysis panels of various granularities, such as task usage, namespace resource usage, and node resource usage, but also can meet the personalized monitoring needs of users.

[0047] In this embodiment, by setting up a display module, an intuitive resource usage display is provided, such as the resource usage analysis and display of various granularities such as task usage, namespace resource usage, and node resource usage. At the same time, users can customize the monitoring panel according to their own needs and obtain key information more conveniently.

[0048] In an optional embodiment, the multiple slave applications are deployed in any cluster based on the files for building container images and the command line tools for operating the cluster. The configuration file of the system customizes the adjustment of the data serialization format file based on the cluster rules. The system expands or reduces the number of instances according to the change in load. The load situation is determined based on the acquired resource usage data. After the load situation is determined, the number of container instances can be adjusted according to the preset conditions and the current load situation.

[0049] Specifically, through cloud native technology, the monitoring system can realize a one-click automatic process from container image packaging to deployment through the provided files for building container images, such as Dockerfile files, and command line tools for operating clusters, such as Kubernetes' kubectl command. Without additional configuration, the monitoring system can be easily deployed to any Kubernetes cluster.

[0050] Moreover, when the monitoring system is deployed in different clusters, the configuration files of the monitoring system can be flexibly adjusted according to the actual situation of the cluster, such as specifying the nodes for deploying sub-applications, configuring resource usage data, and adding labels to the monitoring system. When making adjustments, the data serialization format file, i.e., the Yaml file, can be adjusted according to the Kubernetes rules. The flexibility of this custom configuration enables the monitoring system to better adapt to the needs of different environments. In this embodiment, the configuration file list is expressed as follows:

[0051] deploy

[0052] cluster-role-binding.yaml

[0053] cluster-role.yaml

[0054] config-map.yaml

[0055] platform-monitor-master.yaml

[0056] platform-monitor-worker.yaml

[0057] service-account.yaml

[0058] service.vaml

[0059] In terms of portability and security, this embodiment uses a cloud-native architecture solution based on Kubernetes, so that the monitoring system can automatically expand or reduce the number of instances according to changes in load. This ensures that the system can provide more resources when the load is high and effectively release resources when the load is low, thereby improving the efficiency of the system. The configuration of the monitoring system can also be defined and updated declaratively. This simplifies the configuration management process and makes it possible to modify the granularity of monitoring more flexibly. In addition, multi-environment deployment can be achieved, and the monitoring system can be easily deployed on the Kubernetes platform of different cloud service providers or private data centers. This provides greater flexibility and portability, making the system more adaptable to different deployment requirements.

[0060] The monitoring system of this embodiment performs excellently in monitoring the resource usage of the cloud-native machine learning platform, provides high timeliness, flexibility, and visual display, and provides users with a better monitoring experience.

[0061] This embodiment provides a solution for low-latency monitoring data acquisition in multi-node scenarios, significantly improving the timeliness of monitoring data. At the same time, configurable multi-granularity status monitoring and customized status display boards are introduced to improve the readability of monitoring data. Users can choose different monitoring granularities according to their needs and customize the display boards to make monitoring data easier to understand and analyze. The monitoring system also efficiently integrates the data of the Kubernetes API and NVML library to associate graphics card resources with general resources (CPU, memory). This integration effectively enhances the reference significance of monitoring data, provides users with a more comprehensive and targeted resource usage analysis, and provides a more reliable basis for decision-making. In addition, the cloud-native architecture based on Kubernetes enables the system to have elastic scaling, load balancing, configuration management, fault recovery and self-healing capabilities. It can also be easily deployed on different cloud service providers or private data centers with excellent portability. Finally, the monitoring system supports the monitoring of indicators in the existing system, and can also support more Nvidia and Kubernetes system resource indicators. In the future, based on the existing logical templates, more monitoring granularities can be easily added to provide a more comprehensive monitoring service for the system.

[0062] Those of ordinary skill in the art will appreciate that the modules and processing steps of each example described in conjunction with the embodiments disclosed in the embodiments of the present invention can be implemented with electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention. In addition, each functional unit in each embodiment of the present invention can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit.

[0063] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the contents of each embodiment of the present invention.

[0064] It will be appreciated by those skilled in the art that the functional modules / units in the system disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. In hardware implementations, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or temporary medium). As known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer. In addition, it is well known to those of ordinary skill in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0065] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

[0066] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A cloud-native monitoring system, It is characterized in that The monitoring system is a monitoring system for a machine learning platform, and the system includes: a plurality of nodes arranged in a cluster, the plurality of nodes including a master node, a master application is deployed in the master node, and slave applications are deployed in other nodes other than the master node; Each slave application is used to collect node resource usage data based on concurrent queries, where the resource usage data includes Pod granularity data, namespace granularity data, and graphics card granularity data; The master application is used to obtain resource usage data collected by each slave application based on a preset communication protocol, and perform node resource usage analysis and task resource usage analysis according to the resource usage data; The main application is also used to filter the acquired resource usage data, and divide the resource usage data according to tasks to obtain resource usage data for each task, perform task-level resource usage analysis based on the resource usage data for each task, and store the analyzed data in a preset format; The system expands or reduces the number of instances according to changes in load; Each sub-application is also used to filter and count the scope of the namespace according to the configuration of the query rule; Each sub-application also adjusts the collected resource usage data based on the adjusted code logic.

2. The system according to claim 1, It is characterized in that The preset communication protocol adopts the communication protocol of the remote procedure call framework.

3. The system according to claim 1, Features: Each slave application is also used to obtain statistical data of all Pods in the cluster as Pod granularity data using a cluster monitoring tool, wherein the statistical data includes CPU utilization and memory usage; Each slave application is also used to call the namespace-related operation interface in the cluster and obtain the usage of each namespace in the cluster as namespace granularity data in a multi-threaded manner; Each slave application is further used to call an application programming interface of a management library based on C language to obtain status data of a graphics card device as graphics card granularity data, wherein the status data includes graphics card core utilization and memory utilization.

4. The system according to claim 1, Features: The main application is also used to obtain the resource usage data collected by each slave application based on active query and timed recording to perform node resource usage analysis. The active query includes obtaining the resource usage data collected by each slave application by calling the interface service based on the network interface logic. The timed recording includes obtaining the resource usage data collected by each slave application according to the time interval of the preset timed task.

5. The system according to claim 1, It is characterized in that The system further comprises: a display module; The display module is used to display the resource usage data in a personalized manner.

6. The system according to claim 1, It is characterized in that The multiple slave applications are deployed in any cluster according to the file for building the container image and the command line tool for operating the cluster.

7. The system according to claim 1, It is characterized in that The configuration file of the system performs custom configuration on the adjustment of the data serialization format file based on cluster rules.

Images