Cluster application state monitoring method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application provide a cluster application state monitoring method and device, electronic equipment and storage medium, and belong to the technical field of cluster servers. The method comprises: in response to a state monitoring instruction, obtaining account key information of a cluster server; logging in to the cluster server and obtaining configuration command information from a control node of the cluster server; according to the configuration command information, API authentication information of the cluster server is obtained by analysis; according to the API authentication information, a first API interface is called to query the name information of the application programs corresponding to each container in the cluster server, and a second API interface is called to query the running state of each container in the cluster server; the target name information of the application programs corresponding to the containers in an abnormal state is counted, and a state exception list file of the application programs is generated based on the target name information. The present application can realize efficient monitoring of the state of the application programs in the cluster server, and is conducive to improving the running stability of the application programs.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cluster server, and particularly relates to a cluster application state monitoring method and device, electronic equipment and storage medium. BACKGROUND

[0002] The cloud platform provides hardware-based services, provides basic computing, network and storage capabilities, and more typical cloud platforms include Openstack, AWS, Azure, Vsphere, etc. Some cloud platforms further provide services for creating kubernetes container clusters using basic resources, which provides convenience for users to containerize deploy business applications. However, the application programs running in the container cannot limit their resource usage, so there is often an imbalance in the allocation of physical machine resources. For example, if multiple application programs run on a physical machine, it is possible that an application program will occupy most of the physical resources of the physical machine, thereby causing other business application programs to be unable to normally use them, resulting in a decline in their performance.

[0003] In the related art, the general solution is to decouple the application programs, and each application program runs on a different physical machine, thereby achieving resource isolation and avoiding the situation where multiple application programs occupy the same physical machine. However, in this case, in the face of complex and large numbers of physical machines, the existing scheme is difficult to better achieve monitoring of the running state of each application program in the cluster server, resulting in a lack of operation and maintenance, low running stability of the application program, and affecting user experience. SUMMARY

[0004] The main purpose of the embodiments of the present application is to propose a cluster application state monitoring method and device, electronic equipment and storage medium, which aims to efficiently monitor the running state of the application program in the cluster server, thereby facilitating timely repair of abnormal states and being beneficial to improve the running stability of the application program.

[0005] To achieve the above purpose, a first aspect of the embodiments of the present application proposes a cluster application state monitoring method, which comprises:

[0006] In response to a state monitoring instruction, account key information of a cluster server is obtained in advance;

[0007] According to the account key information, the cluster server is logged in, and configuration command information is obtained from the control node of the cluster server;

[0008] According to the configuration command information, API authentication information of the cluster server is obtained by parsing;

[0009] According to the API authentication information, a first API interface is called to query name information of an application corresponding to each container in the cluster server, and a second API interface is called to query a running state of each container in the cluster server;

[0010] Target name information of an application corresponding to a container in an abnormal state is counted, and a state abnormality list file of the application is generated based on the target name information.

[0011] In some embodiments, the state monitoring instruction is triggered by the following steps:

[0012] A running duration of the cluster server is timed to obtain an accumulated duration;

[0013] When the accumulated duration reaches a first preset time threshold, the state monitoring instruction is issued, and the step of timing the running duration of the cluster server to obtain the accumulated duration is returned after the accumulated duration is cleared.

[0014] In some embodiments, the state monitoring instruction is triggered by the following steps:

[0015] A resource usage rate of the cluster server is detected;

[0016] When the resource usage rate is lower than a preset usage rate threshold, and a time interval from a time node when the last state monitoring instruction is issued to the present time is greater than a second preset time threshold, the state monitoring instruction is issued.

[0017] In some embodiments, the method further comprises:

[0018] Batched monitoring task information is received; the monitoring task information includes first name information of an application to be monitored;

[0019] According to the first name information, a target container running the application to be monitored is determined;

[0020] According to a running state of the target container, the application to be monitored is state-monitored.

[0021] In some embodiments, after the step of receiving the batched monitoring task information, the method comprises:

[0022] According to each monitoring task information that has been received before, the currently received monitoring task information is iteratively matched to detect whether the currently received monitoring task information is repeatedly issued;

[0023] If the currently received monitoring task information is repeatedly issued, the repeatedly issued monitoring task information is deleted.

[0024] In some embodiments, the monitoring task information is distributed in the following manner:

[0025] Detect the number of monitoring task information that needs to be issued;

[0026] When the quantity is less than a preset quantity threshold, the monitoring task information is published through a single thread; or, when the quantity is greater than or equal to the preset quantity threshold, the monitoring task information is published through multiple threads.

[0027] In some embodiments, the method further includes:

[0028] Based on the target name information, determine the developer of the application corresponding to the container in an abnormal state;

[0029] Release a fix alert to the developer.

[0030] To achieve the above objectives, a second aspect of this application provides a cluster application status monitoring device, the device comprising:

[0031] The response unit is used to respond to status monitoring commands and obtain the pre-stored account key information of the cluster server;

[0032] The acquisition unit is used to log in to the cluster server based on the account key information and obtain configuration command information from the control node of the cluster server;

[0033] The parsing unit is used to parse the configuration command information to obtain the API authentication information of the cluster server;

[0034] The calling unit is used to call the first API interface to query the name information of the application corresponding to each container in the cluster server, and call the second API interface to query the running status of each container in the cluster server, based on the API authentication information.

[0035] The output unit is used to collect the target name information of the application corresponding to the container whose running state is in an abnormal state, and generate an application state abnormality list file based on the target name information.

[0036] To achieve the above objectives, a third aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect.

[0037] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect.

[0038] The cluster application status monitoring method, apparatus, electronic device, and storage medium proposed in this application, in response to a status monitoring command, obtain pre-stored account key information of the cluster server; log in to the cluster server according to the account key information, and obtain configuration command information from the control node of the cluster server; parse the API authentication information of the cluster server according to the configuration command information; call a first API interface to query the name information of the application corresponding to each container in the cluster server according to the API authentication information, and call a second API interface to query the running status of each container in the cluster server; count the target name information of the application corresponding to the container whose running status is abnormal, and generate an application status abnormality list file based on the target name information. This application can achieve efficient monitoring of the running status of applications in the cluster server, thereby facilitating timely repair of abnormal states, improving the running stability of applications, and enhancing the user's application experience. Attached Figure Description

[0039] Figure 1 This is a flowchart of a cluster application status monitoring method provided in an embodiment of this application;

[0040] Figure 2 This is a flowchart illustrating the issuance of status monitoring instructions provided in an embodiment of this application;

[0041] Figure 3 This is another flowchart of issuing status monitoring instructions provided in an embodiment of this application;

[0042] Figure 4 This is a flowchart of another cluster application status monitoring method provided in the embodiments of this application;

[0043] Figure 5 This is a flowchart illustrating a method for filtering monitoring task information, as provided in an embodiment of this application.

[0044] Figure 6 This is a flowchart illustrating the distribution of monitoring task information provided in an embodiment of this application;

[0045] Figure 7 This is a schematic diagram of the structure of the cluster application status monitoring device provided in the embodiments of this application;

[0046] Figure 8 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0048] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0049] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0050] First, let's analyze some of the terms used in this application:

[0051] Cluster: A cluster is a group of independent computers interconnected by a high-speed network, forming a group and managed as a single system. When a client interacts with a cluster, the cluster acts like a single server. The primary purpose of cluster configuration is to improve availability and scalability. Through cluster technology, relatively high benefits in performance, reliability, and flexibility can be obtained at a lower cost.

[0052] Kubernetes (K8s) is an open-source application used to manage containerized applications across multiple hosts in a cloud platform. Kubernetes aims to make deploying containerized applications simple and efficient, providing a mechanism for application deployment, planning, updating, and maintenance. In Kubernetes, applications are deployed as containers. Each container is isolated from the others, has its own file system, and processes within containers do not interfere with each other, allowing for the differentiation of computing resources. Compared to virtual machines, containers can be deployed quickly. Because containers are decoupled from the underlying infrastructure and machine file system, they can be migrated between different clouds and different operating system versions.

[0053] An application (APP) is a computer program designed to perform one or more specific tasks. It runs in user mode, interacts with the user, and has a visual user interface. Applications are typically divided into two parts: a graphical user interface (GUI) and an engine. The GUI displays graphics and characters and provides an event-driven user interface that controls the user's operation. The engine is the core component for developing programs or systems on an electronic platform. Using the engine, developers can quickly establish and implement the necessary functions of the program, or utilize it to assist the program's operation. Generally, an engine is a supporting component of a program or system. Common program engines include game engines, search engines, and antivirus engines.

[0054] UUID: An abbreviation for Universally Unique Identifier, is a software construction standard and part of the Open Software Foundation's work on distributed computing environments. Its purpose is to provide all elements in a distributed system with unique identification information, eliminating the need for a central control point to assign this identification.

[0055] Cloud platforms provide hardware-based services, offering basic computing, networking, and storage capabilities. Typical cloud platforms include OpenStack, AWS, Azure, and vSphere. Some cloud platforms further offer services for creating Kubernetes container clusters using these basic resources, facilitating the containerized deployment of business applications. However, applications running in containers often suffer from uneven distribution of physical machine resources because their resource usage cannot be limited. For example, if multiple applications are running on a physical machine, one application may preempt most of the machine's physical resources, causing other business applications to malfunction and resulting in performance degradation.

[0056] In related technologies, the common solution is to decouple applications, with each application running on a different physical machine, thereby achieving resource isolation and preventing multiple applications from competing for the same physical machine. However, in this case, with a complex and numerous physical machine cluster, existing solutions struggle to effectively monitor the running status of each application within the cluster server, leading to a lack of operational maintenance, lower application stability, and a negative impact on user experience.

[0057] Based on this, embodiments of this application provide a cluster application status monitoring method, apparatus, electronic device, and storage medium. Responding to a status monitoring command, the method acquires pre-stored account key information of the cluster server; logs into the cluster server using the account key information, and obtains configuration command information from the control node of the cluster server; parses the API authentication information of the cluster server using the configuration command information; calls a first API interface to query the name information of the application corresponding to each container in the cluster server using the API authentication information, and calls a second API interface to query the running status of each container in the cluster server; statistically analyzes the target name information of the application corresponding to the container whose running status is abnormal, and generates an application status abnormality list file based on the target name information. This application can achieve efficient monitoring of the running status of applications in a cluster server, thereby facilitating timely repair of abnormal states, improving the running stability of applications, and enhancing the user's application experience.

[0058] The methods provided in this application embodiment can be executed in application scenarios involving shopping, gaming, and social networking. For example, in shopping applications, there may be issues such as application lag preventing successful payment. In this scenario, the methods provided in this application embodiment can be used to monitor the application's status, determine the time point when the problem occurs, and efficiently resolve the problems encountered by consumers during the shopping process. As another example, in gaming applications, there may be game-related issues such as bugs. In this scenario, the methods provided in this application embodiment can be used to detect the game's business processes, identify and fix related bugs, thereby improving the player's gaming experience.

[0059] The cluster application status monitoring method, device, electronic device, and storage medium provided in this application are specifically described through the following embodiments. First, the monitoring method in this application embodiment is described.

[0060] The cluster application status monitoring method provided in this application relates to the field of cluster server technology. This method can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, etc.; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing 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, CDN, and big data and artificial intelligence platforms; the software can be an application implementing the cluster application status monitoring method, but is not limited to the above forms.

[0061] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0062] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards of the relevant countries and regions. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirects to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data for the proper functioning of the embodiments of this application obtained.

[0063] Figure 1 This is an optional flowchart of the cluster application status monitoring method provided in the embodiments of this application. Figure 1The method may include, but is not limited to, steps S101 to S105.

[0064] Step S101: In response to the status monitoring command, obtain the pre-stored account key information of the cluster server;

[0065] In this step, when there is a need to monitor the running status of applications within each container of the cluster server, a status monitoring command can be triggered, enabling the relevant system or server to execute the status monitoring method provided in this embodiment. Upon receiving the status monitoring command, the pre-stored account key information of the cluster server can be obtained, facilitating login to the cluster server to obtain the relevant permissions to monitor the running status of applications. Specifically, in this embodiment, the account key information is used for login and identity verification, and it can consist of numbers, characters, etc., and this application does not limit its specific form.

[0066] It should be noted that, since there are currently dual-active or multi-active cluster servers, meaning multiple cluster servers exist in multiple different network areas, the account key information corresponding to each cluster server can be pre-configured in this embodiment. Furthermore, in this embodiment, when monitoring the status of applications within the cluster servers, it is possible to monitor a single cluster server or multiple cluster servers simultaneously; this application does not limit the specific number of servers monitored.

[0067] It should be noted that, in the embodiments of this application, the status monitoring command can be triggered by the user or by the program itself.

[0068] For example, in some possible embodiments, the method can be configured to execute on an electronic device, which can receive user interaction commands to relevant components, and these interaction commands can be used as status monitoring commands. Here, the relevant components can be components configured in the underlying system of the electronic device or components configured in the relevant monitoring application, and their implementation can be flexibly set as needed. For example, in some embodiments, the component can be a component in the electronic device with voice interaction capabilities, which can recognize the user's voice data through voice recognition technology. The user can interact with the electronic device through voice, such as saying to the electronic device, "Check the running status of the application in the cluster server," thereby issuing a status monitoring command for a specific application.

[0069] In other possible embodiments, the component can also be a touch component. In this case, the user's tapping of the corresponding touch component on the electronic device screen can be regarded as issuing a status monitoring command. Of course, it is understood that the form in which the user initiates the status monitoring command in this application embodiment is not limited to the above situation. In some embodiments, the received user touch, swipe, or other operations on a designated screen area of ​​the electronic device can also be used as the triggering condition for the status monitoring command. This application does not impose specific limitations on this.

[0070] Step S102: Log in to the cluster server according to the account key information and obtain configuration command information from the control node of the cluster server;

[0071] In this step, after obtaining the account key information of the cluster server, you can log in to the cluster server using this information to remotely monitor the status of applications running in each container within the cluster server. Specifically, for example, configuration command information can be obtained from the control node of each cluster server. It can be understood that for a cluster server, a node is a service (instance) that can perform data storage, indexing, and searching functions. Each node has a unique name as its identifier, typically using a UUID by default. These nodes include both control nodes and standalone nodes. For example, a cluster server built on Kubernetes includes a Master node and Node nodes. The Master node is the control node of the cluster server; every Kubernetes cluster needs a Master node to manage and control the entire cluster server. Essentially, all Kubernetes control commands are sent to the Master node, which is responsible for the execution process. In other words, almost all commands executed by the cluster server run on the Master node. The Kubernetes API Server process runs on the Master node. This process provides the crucial HTTP REST interface service and is the sole entry point for all resource creation, deletion, modification, and query operations in Kubernetes, as well as the entry point for cluster server control. The Master node also includes the Kubernetes Scheduler process, which is primarily responsible for resource scheduling.

[0072] In this step, configuration command information can be obtained from the control node of the cluster server. For example, in a Kubernetes cluster, the kube configuration information can be found from the master node; this configuration information is the configuration command information.

[0073] It should be noted that in the embodiments of this application, each control node and single-machine node can be implemented by either a physical host or a virtual machine, and this application does not impose any restrictions on this.

[0074] Step S103: Based on the configuration command information, parse the API authentication information of the cluster server to obtain it;

[0075] In this step, after obtaining the configuration command information from the control node, the configuration command information can be parsed to obtain the API authentication information of the cluster server. The API authentication information is the permission verification credential required when using the relevant API interfaces on the cluster server; that is, only after obtaining the API authentication information can the relevant API interfaces on the cluster server be called. In this embodiment, the cluster server can be pre-configured with API interfaces of various functional types. As an optional implementation, the cluster server can respond to user-issued custom commands, actively create multiple interface resources based on the API object's programming declaration file (such as a YAML file), and configure corresponding attributes and business processes for each interface resource. Specifically, taking Kubernetes as an example, before using the Kubernetes API interface object, users can generally write their own corresponding API (Application Programming Interface) object's YAML file and submit it to Kubernetes, so that the designed functions can be executed during subsequent calls.

[0076] Step S104: Based on the API authentication information, call the first API interface to query the name information of the application corresponding to each container in the cluster server, and call the second API interface to query the running status of each container in the cluster server.

[0077] In this step, based on the API authentication information, one API interface in the cluster server can be called to query the name information of the applications running in each container within the cluster server. In this embodiment, this API interface is referred to as the first API interface. Furthermore, another API interface in the cluster server is called to query the running status of each container within the cluster server. In this embodiment, this API interface is referred to as the second API interface. For example, for a cluster server built on Kubernetes, two related API interfaces, CoreV1Api and AppsV1Api, can be called. The main function of CoreV1Api is to obtain the service information of all containers in the Kubernetes cluster server. By parsing the service information, the name information of the applications running within the containers can be obtained. The main function of AppsV1Api is to obtain the dependencies (replicas) of all containers in each Kubernetes cluster. By verifying the status of the replicas, the running status of the containers can be obtained. Specifically, in this embodiment, the obtained replicas can be transmitted to other established status monitoring systems to match and verify the relevant running parameters of the container, thereby determining its corresponding running status, and then transmitted back through the AppsV1Api interface.

[0078] Step S105: Collect the target name information of the application corresponding to the container whose running state is in an abnormal state, and generate an application state abnormality list file based on the target name information.

[0079] In this step, after determining the running status of each container in the cluster server, the containers in abnormal states can be identified. Since the containers are currently in abnormal states, the applications running within them will also be affected and become abnormal, requiring timely handling and repair. In this embodiment, the name information of the application corresponding to each container in an abnormal state can be obtained and recorded as the target name information. Then, an application status abnormality list file can be generated based on the target name information. This file can record each application in an abnormal state in a list format. After outputting the status abnormality list file, simply monitoring the list in this file is sufficient to determine which application has an abnormal alarm, thereby conveniently and efficiently notifying relevant personnel to perform timely repair work, which is beneficial to improving the repair efficiency and operational stability of the application.

[0080] Specifically, in some embodiments, the developer of the abnormal application can be identified based on the application's target name information, and then a repair alert can be sent to the developer to prompt them to perform timely maintenance on the application and fix the vulnerabilities.

[0081] Specifically, please refer to Figure 2 In some embodiments, the status monitoring command is triggered through the following steps:

[0082] Step S201: The runtime of the cluster server is timed to obtain the cumulative runtime;

[0083] Step S202: When the accumulated duration reaches the first preset time threshold, the status monitoring instruction is issued, and the accumulated duration is cleared to zero before returning to the step of timing the runtime of the cluster server to obtain the accumulated duration.

[0084] In this embodiment, as mentioned above, the status monitoring command can be triggered by the user or automatically by the program. For automatic triggering, this embodiment can achieve this through timed triggering. Specifically, for example, the status monitoring command can be triggered once at regular intervals. It should be noted that this embodiment does not limit the time interval between two status monitoring commands.

[0085] In practical implementation, the runtime of the cluster server can be timed to obtain the cumulative duration. A time interval, denoted as the first preset time threshold (e.g., 15 minutes or 10 minutes), is pre-set. Then, each time the cumulative duration reaches the first preset time threshold, a status monitoring command is issued, and the cumulative duration is reset to zero. In this way, the application status can be monitored every time the first preset time threshold is reached, and the entire implementation logic is simple, requiring no complex program development.

[0086] Specifically, please refer to Figure 3 In some embodiments, the status monitoring command is triggered through the following steps:

[0087] Step S301: Detect the resource utilization rate of the cluster server;

[0088] Step S302: When the resource utilization rate is lower than the preset utilization rate threshold, and the time interval between the last time node of the status monitoring command and the current time is greater than the second preset time threshold, the status monitoring command is issued.

[0089] In this embodiment, for cases where status monitoring commands are triggered automatically, the overall resource utilization of the cluster servers can also be considered when issuing them. It is understood that when the cluster servers are under peak business conditions, frequent status monitoring will consume some server resources and may affect normal business processing. Therefore, ideally, monitoring commands should be generated when the cluster servers are relatively idle and the business pressure is not high. Thus, in this embodiment, the resource utilization of the cluster servers can be detected in real time, including data such as the CPU utilization of each physical machine. Furthermore, a preset utilization threshold can be set in advance. If the current resource utilization is higher than the preset threshold, it indicates that the current cluster server is under heavy business, and status monitoring commands can be withheld; conversely, if the current resource utilization is lower than the preset threshold, it indicates that the current cluster server is under light business, and status monitoring commands can be issued.

[0090] Of course, it should be noted that issuing status monitoring commands based on the resource utilization of cluster servers may result in the resource utilization of the cluster servers being lower than the preset utilization threshold for a period of time. To prevent the continuous issuance of status monitoring commands, which would lead to repeated and uninterrupted execution of status monitoring jobs and waste of system monitoring resources, this embodiment of the application can set a second preset time threshold, stipulating that the time interval between two issuances of status monitoring commands should not be less than the second preset time threshold. Thus, when it is detected that the resource utilization of the cluster server is lower than the preset utilization threshold, the time node of the last issuance of the status monitoring command will be determined first, and then the time interval between the last issuance of the status monitoring command and the current time will be determined. If the time interval is less than or equal to the second preset time threshold, no status monitoring command will be issued this time. If the time interval is greater than the second preset time threshold, a status monitoring command will be issued this time.

[0091] Specifically, please refer to Figure 4 In some embodiments, the method further includes:

[0092] Step S401: Receive monitoring task information sent in batches; the monitoring task information includes the first name information of the application to be monitored;

[0093] Step S402: Determine the target container running the application to be monitored based on the first name information;

[0094] Step S403: Based on the running status of the target container, perform status monitoring on the application to be monitored.

[0095] In this embodiment, in addition to monitoring the running status of applications across the entire cluster server dimension as described in the foregoing embodiments, status monitoring can also be performed on selected applications based on monitoring task information issued by the user. This improves the flexibility and operability of monitoring tasks, and can effectively meet the monitoring needs of applications with special requirements, such as those with higher stability requirements, while minimizing system monitoring resources. Specifically, when a user has a need for status monitoring of specific applications, monitoring task information can be issued. This monitoring task information can be issued in batches, and this application does not limit the specific quantity.

[0096] The monitoring task information includes the name information of the application to be monitored, which is denoted as the first name information in this embodiment. Based on the first name information, the container responsible for running the application to be monitored can be matched, which is denoted as the target container in this application. In this way, the status monitoring of the application to be monitored can be performed based on the running status of the target container, realizing separate monitoring jobs for some applications and improving the flexibility of the monitoring system.

[0097] Specifically, please refer to Figure 5 In some embodiments, after the step of receiving the batch-issued monitoring task information, the method includes:

[0098] Step S501: Based on the previously received monitoring task information, traverse and match the currently received monitoring task information to detect whether the currently received monitoring task information has been sent repeatedly.

[0099] Step S502: If the currently received monitoring task information is sent repeatedly, delete the repeatedly sent monitoring task information.

[0100] In this embodiment, to prevent the re-issuance of already issued monitoring task information and avoid resource waste and invalid monitoring, filtering can be performed after each issuance of monitoring task information and before executing the corresponding monitoring task. Specifically, for a currently received set of monitoring task information, it can be iterated and matched against previously received monitoring task information. If a matching monitoring task information is found, it indicates that the monitoring task information has been re-issued. In this case, the re-issued monitoring task information can be deleted, and the monitoring task will not be executed repeatedly. Conversely, if a monitoring task information does not match any previously issued information, the monitoring task can be executed.

[0101] Specifically, please refer to Figure 6 In some embodiments, the monitoring task information is distributed in the following manner:

[0102] Step S601: Detect the number of monitoring task information that needs to be issued;

[0103] Step S602: When the quantity is less than a preset quantity threshold, the monitoring task information is published through a single thread; or, when the quantity is greater than or equal to the preset quantity threshold, the monitoring task information is published through multiple threads.

[0104] In this embodiment, the method for distributing monitoring task information can be determined based on its specific quantity. It is understood that when the number of monitoring task information items is small, it indicates a low monitoring workload, and a single thread can meet the system's monitoring needs. However, when the number of monitoring task information items is large, a single thread cannot meet the frequency of batch distribution of multiple monitoring task information items by the monitoring system. Therefore, multi-threading can be used for distribution. For example, threading and queue can be used to implement multi-threaded batch distribution, and the number of threads can be customized; this application does not impose specific limitations on this. Specifically, in this embodiment, a preset quantity threshold can be set for the number of monitoring task information items. When the number of monitoring task information items is less than the preset quantity threshold, the monitoring task information is published using a single thread; when the number of monitoring task information items is greater than or equal to the preset quantity threshold, the monitoring task information is published using multiple threads.

[0105] Please see Figure 7 This application also provides a cluster application status monitoring device that can implement the above-described cluster application status monitoring method. The device includes:

[0106] The response unit is used to respond to status monitoring commands and obtain the pre-stored account key information of the cluster server;

[0107] The acquisition unit is used to log in to the cluster server based on the account key information and obtain configuration command information from the control node of the cluster server;

[0108] The parsing unit is used to parse the configuration command information to obtain the API authentication information of the cluster server;

[0109] The calling unit is used to call the first API interface to query the name information of the application corresponding to each container in the cluster server, and call the second API interface to query the running status of each container in the cluster server, based on the API authentication information.

[0110] The output unit is used to collect the target name information of the application corresponding to the container whose running state is in an abnormal state, and generate an application state abnormality list file based on the target name information.

[0111] In some embodiments, the status monitoring command is triggered through the following steps:

[0112] The runtime of the cluster server is timed to obtain the cumulative runtime;

[0113] When the accumulated duration reaches the first preset time threshold, the status monitoring instruction is issued, and the accumulated duration is cleared to zero before returning to the step of timing the runtime of the cluster server to obtain the accumulated duration.

[0114] In some embodiments, the status monitoring command is triggered through the following steps:

[0115] Detect the resource utilization of the cluster servers;

[0116] When the resource utilization rate is lower than a preset utilization rate threshold, and the time interval between the last time the status monitoring command was issued and the current time is greater than a second preset time threshold, the status monitoring command is issued.

[0117] In some embodiments, the apparatus further includes a sending unit, the sending unit being used for:

[0118] Receive monitoring task information sent in batches; the monitoring task information includes the first name information of the application to be monitored;

[0119] Based on the first name information, determine the target container running the application to be monitored;

[0120] Based on the running status of the target container, the application to be monitored is monitored for status.

[0121] In some embodiments, the apparatus further includes a detection unit, the detection unit being used for:

[0122] Based on the previously received monitoring task information, the currently received monitoring task information is traversed and matched to detect whether the currently received monitoring task information has been sent repeatedly.

[0123] If the currently received monitoring task information is sent repeatedly, delete the duplicate monitoring task information.

[0124] In some embodiments, the monitoring task information is distributed in the following manner:

[0125] Detect the number of monitoring task information that needs to be issued;

[0126] When the quantity is less than a preset quantity threshold, the monitoring task information is published through a single thread; or, when the quantity is greater than or equal to the preset quantity threshold, the monitoring task information is published through multiple threads.

[0127] In some embodiments, the apparatus further includes an alarm unit, the alarm unit being configured to:

[0128] Based on the target name information, determine the developer of the application corresponding to the container in an abnormal state;

[0129] Release a fix alert to the developer.

[0130] It is understandable that, such as Figure 1 The content of the cluster application status monitoring method embodiment shown is applicable to the cluster application status monitoring device embodiment. The specific functions implemented by the cluster application status monitoring device embodiment are the same as those shown in the example. Figure 1 The cluster application status monitoring method shown in the embodiment is the same, and the beneficial effects achieved are the same as those described above. Figure 1 The beneficial effects achieved by the cluster application status monitoring method embodiment shown are also the same.

[0131] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned cluster application status monitoring method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0132] Please see Figure 8 , Figure 8 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes:

[0133] The processor 801 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0134] The memory 802 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 802 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 802 and is called and executed by the processor 801 using the cluster application status monitoring method of the embodiments of this application.

[0135] The 803 input / output interface is used to implement information input and output.

[0136] The communication interface 804 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0137] Bus 805 transmits information between various components of the device (e.g., processor 801, memory 802, input / output interface 803, and communication interface 804);

[0138] The processor 801, memory 802, input / output interface 803, and communication interface 804 are connected to each other within the device via bus 805.

[0139] It is understandable that, such as Figure 1 The content of the cluster application status monitoring method embodiment shown is applicable to the embodiment of this electronic device. The specific functions implemented by the embodiment of this electronic device are the same as those shown below. Figure 1 The cluster application status monitoring method shown in the embodiment is the same, and the beneficial effects achieved are the same as those described above. Figure 1 The beneficial effects achieved by the cluster application status monitoring method embodiment shown are also the same.

[0140] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described cluster application status monitoring method.

[0141] Similarly, it is understandable that, as Figure 1 The content of the cluster application status monitoring method embodiments shown is applicable to the embodiments of this computer-readable storage medium. The specific functions implemented by the embodiments of this computer-readable storage medium are the same as those shown below. Figure 1 The cluster application status monitoring method shown in the embodiment is the same, and the beneficial effects achieved are the same as those described above. Figure 1 The beneficial effects achieved by the cluster application status monitoring method embodiment shown are also the same.

[0142] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0143] The cluster application status monitoring method, device, electronic device, and storage medium provided in this application embodiment respond to a status monitoring command by obtaining pre-stored account key information of the cluster server; logging into the cluster server based on the account key information; obtaining configuration command information from the control node of the cluster server; parsing the API authentication information of the cluster server based on the configuration command information; calling a first API interface to query the name information of the application corresponding to each container in the cluster server based on the API authentication information; calling a second API interface to query the running status of each container in the cluster server; statistically analyzing the target name information of the application corresponding to the container whose running status is abnormal; and generating an application status abnormality list file based on the target name information. This application can achieve efficient monitoring of the running status of applications in a cluster server, thereby facilitating timely repair of abnormal states, improving the running stability of applications, and enhancing the user's application experience.

[0144] The embodiments described in 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 by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0145] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0146] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0147] Furthermore, although this application is described in the context of functional modules, it should be understood that, unless otherwise stated to the contrary, one or more of the functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding this application. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of conventional technology for an engineer. Therefore, those skilled in the art can implement the application set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

[0148] If a function is implemented as 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 this application, in essence, or the part that contributes to the prior art, or a 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.) 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 USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0149] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable storage medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable storage medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0150] More specific examples (a non-exhaustive list) of computer-readable storage media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable storage media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0151] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0152] In the foregoing description of this specification, the references to terms such as "one embodiment," "another embodiment," or "some embodiments," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0153] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.

[0154] The above is a detailed description of the preferred embodiments of this application, but this application is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application, and these equivalent modifications or substitutions are all included within the scope defined by the claims of this application.

Claims

1. A method for monitoring the status of cluster applications, characterized in that, The method includes: In response to status monitoring commands, retrieve the pre-stored account key information of the cluster server; Log in to the cluster server using the account key information and obtain configuration command information from the control node of the cluster server; Based on the configuration command information, the API authentication information of the cluster server is obtained by parsing. Based on the API authentication information, the first API interface is called to query the name information of the application corresponding to each container in the cluster server, and the second API interface is called to query the running status of each container in the cluster server. Collect the target name information of the application corresponding to the container whose running state is in an abnormal state, and generate an application state abnormality list file based on the target name information; The status monitoring command is triggered through the following steps: The runtime of the cluster server is timed to obtain the cumulative runtime; When the accumulated time reaches the first preset time threshold, the status monitoring instruction is issued, and the accumulated time is cleared to zero before returning to the step of timing the runtime of the cluster server to obtain the accumulated time. Detect the resource utilization of the cluster servers; When the resource utilization rate is lower than a preset utilization rate threshold, and the time interval between the last time the status monitoring command was issued and the current time is greater than a second preset time threshold, the status monitoring command is issued.

2. The method according to claim 1, characterized in that, The method further includes: Receive monitoring task information sent in batches; the monitoring task information includes the first name information of the application to be monitored; Based on the first name information, determine the target container running the application to be monitored; Based on the running status of the target container, the application to be monitored is monitored for status.

3. The method according to claim 2, characterized in that, After the step of receiving the batch-issued monitoring task information, the method includes: Based on the previously received monitoring task information, the currently received monitoring task information is traversed and matched to detect whether the currently received monitoring task information has been sent repeatedly. If the currently received monitoring task information is sent repeatedly, delete the duplicate monitoring task information.

4. The method according to claim 2, characterized in that, The monitoring task information is distributed in the following ways: Detect the number of monitoring task information that needs to be issued; When the quantity is less than a preset quantity threshold, the monitoring task information is published through a single thread; or, when the quantity is greater than or equal to the preset quantity threshold, the monitoring task information is published through multiple threads.

5. The method according to claim 1, characterized in that, The method further includes: Based on the target name information, determine the developer of the application corresponding to the container in an abnormal state; Release a fix alert to the developer.

6. A cluster application status monitoring device, characterized in that, The device includes: The response unit is used to respond to status monitoring commands and obtain the pre-stored account key information of the cluster server; The acquisition unit is used to log in to the cluster server based on the account key information and obtain configuration command information from the control node of the cluster server; The parsing unit is used to parse the API authentication information of the cluster server according to the configuration command information; The calling unit is used to call the first API interface to query the name information of the application corresponding to each container in the cluster server, and call the second API interface to query the running status of each container in the cluster server, based on the API authentication information. The output unit is used to collect the target name information of the application corresponding to the container whose running state is in an abnormal state, and generate an application state abnormality list file based on the target name information; The status monitoring command is triggered through the following steps: The runtime of the cluster server is timed to obtain the cumulative runtime; When the accumulated time reaches the first preset time threshold, the status monitoring instruction is issued, and the accumulated time is cleared to zero before returning to the step of timing the runtime of the cluster server to obtain the accumulated time. Detect the resource utilization of the cluster servers; When the resource utilization rate is lower than a preset utilization rate threshold, and the time interval between the last time the status monitoring command was issued and the current time is greater than a second preset time threshold, the status monitoring command is issued.

7. An electronic device, characterized in that, The electronic device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the cluster application status monitoring method according to any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the cluster application status monitoring method according to any one of claims 1 to 5.

Images