A method, system, storage medium and device for monitoring application status

Abstract

This specification provides a method, system, storage medium and device for monitoring application status. In this method, with the help of a probe container, the operating environment of the container of the application to be tested is detected and reported to the analysis system, which increases the internal perspective so that the analysis system can determine the actual operating status of the entire instance based on the detection results, thereby being able to determine the root cause of the abnormal state of the application to be tested in combination with the monitored alarm events, thereby enhancing the automated operation and maintenance capabilities.

Description

Technical Field

[0001] The present specification relates to the field of computer technology, and in particular to a method, system, storage medium and device for monitoring application status. Background Art

[0002] As cloud computing technology continues to mature, container technology has gradually become a hot spot in the industry and is increasingly being applied to various fields. K8S (full name: Kubernetes) is an orchestration tool based on container technology that provides a series of functions such as deployment and operation, resource scheduling, and service discovery for containerized applications. The stability of applications on K8S is very important. At present, the solution idea for detecting application stability is generally to perform programmatic verification with the help of external data, such as monitoring Warning events and configuring threshold warnings. However, this way of monitoring application operation cannot define the root cause of abnormal conditions, and the operation and maintenance capabilities are poor. Summary of the invention

[0003] In a first aspect, a method for monitoring application status is provided, which is applied to a probe container, wherein a detection file is configured in the probe container, wherein the detection file is used to detect each detection item in at least one detection item, and the detection item is related to the running environment of the application to be tested; the probe container is configured in the Pod where the application to be tested is located; the method comprises: detecting the detection item according to the detection file; and reporting the detection result to an analysis system, so that the analysis system determines the root cause of the abnormal state of the application to be tested according to the detection result and the monitored alarm event.

[0004] In some embodiments, the detection item includes at least one of a dependency item of the application to be tested when it is started and a dependency item of the application to be tested when it is running.

[0005] In some embodiments, the above method also includes: periodically reporting heartbeat information to the analysis system, the heartbeat information carries a status code, and the status code is used to characterize whether the status of the probe container is abnormal; reporting the test results to the analysis system includes: if any test item is detected to be abnormal, setting the status code in the next reported heartbeat information to indicate that the test item is abnormal.

[0006] In some embodiments, if it is determined according to the detection result that no detection item is abnormal, and it is determined according to the monitored alarm event that the application to be tested is in an abnormal state, then the root cause is the abnormality of the application to be tested.

[0007] In some embodiments, the detection file is obtained from an agent program; the method further includes: detecting version information of a configuration file in a specified storage area, the configuration file being used to indicate a configuration of the detection file; if the detected version information changes, obtaining the configuration file, and creating a new agent program based on the configuration file.

[0008] In some embodiments, the probe container includes: a daemon process, used to obtain the configuration file and create a new agent program according to the configuration file; and a working process, used to detect the detection item according to the detection file.

[0009] In some embodiments, the application to be tested is deployed in a target business container, and the target business container and the probe container are created in parallel.

[0010] In a second aspect, a system for monitoring application status is provided, including a target business container, a probe container, and an analysis system, wherein the target business container and the probe container are encapsulated in the same Pod; wherein:

[0011] The target business container is used to carry the startup and operation of the application to be tested; the probe container is configured with a detection file, and the detection file is used to detect each detection item in at least one detection item, and the detection item is related to the running environment of the application to be tested; the probe container is used to detect the detection item according to the detection file, and report the detection result to the analysis system; the analysis system is used to determine the root cause of the abnormal state of the application to be tested according to the detection result and the monitored alarm event.

[0012] According to a third aspect, a computer-readable storage medium is provided, on which a computer program is stored, and when the program is executed by a processor, any method in the embodiments of the specification is implemented.

[0013] In a fourth aspect, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, any one of the methods in the embodiments of the specification is implemented.

[0014] The technical solutions provided by the embodiments of this specification may have the following beneficial effects:

[0015] In the embodiments of the present specification, a method, system, storage medium and device for monitoring application status are disclosed. In the method, the operating environment of the container of the application to be tested is detected and reported to the analysis system with the help of a probe container, thereby increasing the internal perspective and allowing the analysis system to determine the actual operating status of the entire instance based on the detection results, thereby being able to determine the root cause of the abnormal state of the application to be tested in combination with the monitored alarm events, thereby enhancing the automated operation and maintenance capabilities.

[0016] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present specification. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the specification and, together with the description, serve to explain the principles of the specification.

[0018] Figure 1 is a flow chart of a method for monitoring application status according to an exemplary embodiment of the present specification;

[0019] Figure 2 is a schematic diagram of a system for monitoring application status according to an exemplary embodiment of the present specification;

[0020] Figure 3 It is a schematic diagram of a detection solution for performing indiscriminate detection of application running environments based on a configurable probe according to an exemplary embodiment of this specification;

[0021] Figure 4 It is a hardware structure diagram of a computer device where an apparatus for monitoring application status is located according to an exemplary embodiment of this specification;

[0022] Figure 5 It is a block diagram of a device for monitoring application status according to an exemplary embodiment of the present specification. DETAILED DESCRIPTION

[0023] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with this specification. Instead, they are merely examples of devices and methods consistent with some aspects of this specification as detailed in the appended claims.

[0024] The terms used in this specification are for the purpose of describing specific embodiments only and are not intended to limit this specification. The singular forms "a", "the" and "the" used in this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0025] It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of this specification, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0026] As cloud computing technology continues to mature, container technology has gradually become a hot spot in the industry and is increasingly being applied to various fields. K8S (full name: Kubernetes) is an orchestration tool based on container technology that provides a series of functions such as deployment and operation, resource scheduling, and service discovery for containerized applications. The stability of applications on K8S is very important. At present, the solution idea for detecting application stability is generally to perform programmatic verification with the help of external data, such as monitoring Warning events and configuring threshold warnings. However, this way of monitoring application operation cannot define the root cause of abnormal conditions, and the operation and maintenance capabilities are poor.

[0027] Based on this, the embodiment of this specification provides a method for monitoring application status to solve the above problem. Next, the embodiment of this specification is described in detail.

[0028] like Figure 1 As shown, Figure 1 This is a flowchart of a method for monitoring application status according to an exemplary embodiment of the present specification, wherein the method is applied to a probe container, wherein a detection file is configured in the probe container, wherein the detection file is used to detect each detection item in at least one detection item, wherein the detection item is related to the running environment of the application to be tested; and the probe container is configured in the Pod where the application to be tested is located.

[0029] In this embodiment, the probe container and the container of the application to be tested can be provided by a container application engine. Optionally, the container application engine can be a Serverless Application Engine (SAE for short). SAE is an application-oriented PaaS (Platform as a Service) platform, and the underlying layer is multi-tenant K8S. As a cloud product, stability is one of the most concerned focuses of SAE. In this embodiment, the probe container and the container of the application to be tested are encapsulated in the same Pod. Pod is the smallest working unit of K8S. Each Pod can contain one or more containers. The containers in the Pod will be scheduled as a whole to a Node (node, which can be a physical machine or a virtual machine) to run. In the Pod, the container of the application to be tested can be called the main container or the business container, and the probe container can be regarded as an auxiliary container to complete work independent of the main container. The probe container can be a Sidecar container. Sidecar container is a type of container supported by K8S. The current Sidecar container is generally used to perform some auxiliary work required by the main container, such as collecting logs, monitoring configuration changes, etc. This embodiment implements a new function of monitoring the application running environment by configuring the Sidecar container accordingly, thereby providing a new construction idea for the stability facilities of SAE. Of course, the above container can also be provided by other container application engines, and this specification does not limit this.

[0030] The detection file configured in the probe container is used to detect each detection item in at least one detection item. That is to say, the detection file can record the detection method formulated for each detection item. For example, if the detection item includes an image, a detection method can be formulated for the image detection item, and the logic corresponding to the detection method can be recorded in the detection file. In this way, the probe container can obtain the corresponding code according to the detection file, thereby realizing the detection of the image. The detection item is related to the operating environment of the application to be tested. Since the application to be tested is placed in the main container for execution, the operating environment of the application to be tested is the operating environment of the main container, and accordingly, the detection item can be the resources required by the main container during operation, such as network, image, registration center, etc. Once these detection items related to the operating environment of the application to be tested are abnormal, the startup and operation of the application to be tested will also be abnormal. Taking the detection item as an example, if the image pull fails, the Pod startup fails, and the application to be tested cannot start normally.

[0031] In some examples, the detection item may include at least one of the dependencies of the application to be tested at startup and the dependencies of the application to be tested at runtime. The dependencies of the application to be tested at startup are the components and projects referenced by the application to be tested at startup, including network, monitoring agent, mirror, NAS (Network Attached Storage), OSS (Object Storage Service), etc.; accordingly, the dependencies of the application to be tested at runtime are the components and projects referenced by the application to be tested at runtime, including network, registration center, time, etc. By using the dependencies of the application to be tested at startup and / or at runtime as detection items, the actual operation status of the entire instance can be obtained, which provides an effective basis for judgment for the subsequent determination of whether the root cause of the abnormality of the application to be tested is an environmental problem or a user-side problem. Of course, it should be noted that the detection item can also be set according to the needs of the specific scenario.

[0032] The method comprises:

[0033] Step 101: testing the detection item according to the detection file;

[0034] After the probe container is started, it can detect the corresponding detection items according to the logic in the detection file. For example, if the detection item is the network, and the detection file includes the logic for detecting the network, the probe container can detect the network according to the detection file. Specifically, the probe container can access the SLS Endpoint (the address of the log service). If the access times out, the detection result is a network anomaly; or, if the detection item is time, and the detection file includes the logic for detecting time, the probe container can detect the time according to the detection file. Specifically, the probe container can obtain the server time and verify whether the current time is accurate by comparison. If the verification is inaccurate, the detection result is a time anomaly.

[0035] In some examples, the probe container can detect each detection item according to a certain time period. For example, after completing the detection of each detection item once, the probe container can wait for 1 minute and then start detecting each detection item again. Of course, the time period can also be set according to the needs of the specific scenario. In addition, when the detection items include the dependencies of the application to be tested at startup and the dependencies of the application to be tested at runtime, the probe container can perform periodic detection only on the dependencies of the application to be tested at startup when the application to be tested is started, and after the application to be tested is started and starts running, it can only perform periodic detection on the dependencies of the application to be tested at runtime.

[0036] Step 102: Report the detection result to the analysis system, so that the analysis system can determine the root cause of the abnormal state of the application under test according to the detection result and the monitored alarm events.

[0037] The analysis system mentioned in this step can be a system developed by the platform to automatically operate and maintain containers deployed on the platform. Optionally, the analysis system can include an operation and maintenance system, which can perceive some abnormal conditions of the application to be tested by monitoring the alarm events in SLS (Log Service), and the alarm event can be a Waring event in K8S, by configuring alarms, such as threshold alarms and / or keyword alarms. The alarm events monitored by the operation and maintenance system are observed from an external perspective, with insufficient coverage and no subdivision, while the detection items detected by the probe container of this embodiment provide observability from an internal perspective, and these detection items can be items not involved in the alarm event, or they can be fine-grained divisions of items involved in the alarm event. Therefore, after combining the detection results reported by the probe container of this embodiment, the operation and maintenance system can more comprehensively perceive the health of the operating environment of the application to be tested, so as to define the root cause of the abnormality of the application to be tested.

[0038] In some examples, the probe container can periodically report heartbeat information to the analysis system, and the heartbeat information carries a status code, which is used to characterize whether the state of the probe container is abnormal. Specifically, when the probe container is operating normally, it reports heartbeat information to the analysis system every certain time length m, and the heartbeat information carries a status code "200" indicating that the probe container is in a normal state (that is, the probe container is operating normally and no abnormality is detected in any detection item); if the probe container exits, the probe container sends SIGTERM (termination signal) and waits for 30s. At this time, the heartbeat information reported by the probe container carries a status code "201" indicating that the probe container is in an exit state; if the probe container does not report heartbeat information after the certain time length m and the state indicated by the last reported status code is not an exit state, the analysis system can determine that the probe container is in an abnormal state. Among them, the value of m can be set according to the needs of the specific scenario. In this way, the analysis system can also perceive the health status of the probe container.

[0039] Correspondingly, the detection results of the probe container can also be added to the heartbeat information and reported to the analysis system. That is, if the probe container detects that any detection item is abnormal, the probe container will set the status code in the next reported heartbeat information to indicate that the detection item is abnormal. For example, when the probe container detects that the network detection item is abnormal, the next reported heartbeat information will carry the status code "-1" indicating the network abnormality; and when the probe container detects that the Load detection item is abnormal, the next reported heartbeat information will carry the status code "605" indicating the Load abnormality.

[0040] The analysis system can define whether the abnormality of the application under test is caused by the abnormality of the operating environment or the abnormality of the configuration, parameters, etc. of the application under test itself according to the detection results and the monitored alarm events. In some examples, if it is determined according to the detection results that there is no abnormality in the detection item, and it is determined according to the monitored alarm events that the application under test is in an abnormal state, then the root cause of the abnormal state of the application under test is the abnormality of the application under test. For example, when the instance startup is determined to be abnormal according to the monitored alarm events, if it is determined according to the detection results that there is no abnormality in the detection item, it indicates that the problem of the abnormal instance startup is not caused by the dependency of the application under test not being ready at startup, then the problem should be caused by the abnormal startup of the application under test itself, that is, the root cause is not the abnormality of the operating environment, but the abnormality of the application under test itself; on the contrary, if it is determined according to the detection results that the detection item of the monitoring agent is abnormal, it indicates that the problem should be caused by the dependency of the monitoring agent in the operating environment of the application under test not being ready, that is, the root cause is the abnormality of the operating environment. In this way, the analysis system can perform corresponding operation and maintenance operations based on the determined root cause, such as triggering Pod restart or container reconstruction, to quickly resolve the problem.

[0041] The solution of this embodiment uses a probe container to detect the operating environment of the container of the application to be tested and report it to the analysis system, thereby adding an internal perspective so that the analysis system can determine the actual operating status of the entire instance based on the detection results, and thus can determine the root cause of the abnormal state of the application to be tested in combination with the monitored alarm events, thereby enhancing the automated operation and maintenance capabilities.

[0042] Furthermore, in order to realize the real-time hot update of the detection function of the probe container, in some examples, the above detection file can be obtained from the agent program; the above method also includes: detecting the version information of the configuration file in the specified storage area, the configuration file is used to indicate the configuration of the detection file; if the detected version information changes, the configuration file is obtained, and a new agent program is created according to the configuration file. The agent program can be considered as a functional plug-in, and the probe container obtains the detection file from the agent program to determine which detection items need to be detected and which detection method to execute. The configuration file is used to indicate the configuration of the detection file and can be saved in OSS. When the version information of the configuration file changes, it means that the configuration of the detection file has changed. Then, the probe container can pull the configuration file from OSS and create a new agent program according to the configuration file to realize the detection function according to the updated detection file. In this way, the process of adding custom logic is simplified. For example, the original detection items only include network, monitoring agent and registration center. If you want to add the configuration for detecting the image detection item, you only need to update the configuration file so that the updated configuration file is used to indicate that the detection file includes the logic corresponding to the code for detecting the network, monitoring agent, registration center and image. This facilitates the expansion of the detection function of the probe container.

[0043] In an optional embodiment, the above hot update operation can be implemented by combining a daemon process with a working process, that is, the probe container can include a daemon process and a working process, wherein the daemon process is used to obtain a configuration file and create a new agent program according to the configuration file; the working process is used to detect the detection item according to the detection file. The daemon process is a special process that runs in the background. In this embodiment, the daemon process of the probe container can continuously poll the configuration file. If the version information of the configuration file changes, the configuration file is pulled, a new agent program is created according to the configuration file, and then the original agent program is closed, thereby realizing the update of the detection logic executed by the working process. In this way, the upgrade and update of the probe container can be completed by modifying the configuration file, reducing the update cost during version upgrade. In addition, the time interval for the daemon process to poll the configuration file can be greater than the time interval for the working process detection. Optionally, the time interval for the daemon process to poll the configuration file can be set to 5 minutes, and the time interval for the working process detection can be set to 1 minute. In this way, while realizing version control, data interaction is minimized.

[0044] In other embodiments, the detection logic of various detection items related to the operating environment of the application to be tested can also be recorded in the detection file, so that the probe container has the ability to detect various detection items, and then the detection items that the probe container currently needs to perform detection operations are configured through environment variables. In this way, the probe container can determine whether to detect a certain detection item through the environment variable.

[0045] In addition, in the current Sidecar mode of K8S, the business container is generally started after the Sidecar container configuration is initialized to ensure that the business container can normally access other dependent services when it is started. Since the probe container in this specification provides the function of monitoring the application running environment, which is different from the functions implemented by other Sidecar containers, in some optional embodiments of this specification, the application to be tested is deployed in the target business container, and the target business container can be created in parallel with the probe container. Through such a startup sequence, the creation of the business container is not blocked, which facilitates the deployment of the container application engine.

[0046] Corresponding to the above method embodiment, this specification also provides an embodiment of a system for monitoring application status, such as Figure 2 As shown, Figure 2 2 is a schematic diagram of a system for monitoring application status according to an exemplary embodiment of the present specification, wherein the system includes a target business container 21, a probe container 22 and an analysis system 23, wherein the target business container 21 and the probe container 22 are encapsulated in the same Pod 24; wherein:

[0047] The target service container 21 is used to carry the startup and operation of the application to be tested;

[0048] The probe container 22 is configured with a detection file, the detection file is used to detect each detection item in at least one detection item, and the detection item is related to the operating environment of the application to be tested; the probe container 22 is used to detect the detection item according to the detection file, and report the detection result to the analysis system 23;

[0049] The analysis system 23 is used to determine the root cause of the abnormal state of the application to be tested according to the detection results and the monitored alarm events.

[0050] The implementation process of the functions and effects of each unit in this embodiment is specifically described in the implementation process of the corresponding steps in the above method, which will not be repeated here.

[0051] In order to explain the solution of this specification in more detail, a specific embodiment is introduced below:

[0052] In this embodiment, SAE provides users with the function of quickly deploying applications. In order to improve stability, SAE adds a Sidecar container as a probe in the Pod where the user application is located. The Sidecar container is created in parallel with the business container of the user application, thereby performing indiscriminate detection of the application running environment based on the configured probe.

[0053] Figure 3 3 is a schematic diagram of a detection scheme shown in this embodiment, which includes three parts, namely a first part 301, a second part 302, and a third part 303, wherein:

[0054] The first part 301 represents the operation performed by the working process of the Sidecar container. A detection file is configured in the Sidecar container. The detection file includes codes for detecting each detection item, namely, detection rules. The working process can execute the corresponding detection rules to perform periodic detection on the detection items such as application deployment state dependencies (network, monitoring agent, image, NAS, OSS, etc.) and application running state dependencies (network, registration center, time, etc.); the working process periodically generates heartbeat information and reports the heartbeat information to the analysis system. The heartbeat information carries a status code representing the probe status. Therefore, if the probe container is in a normal state, the heartbeat information carries a status code representing that the probe container is in a normal state. If the probe container detects that any detection item is abnormal, the heartbeat information carries a status code indicating that the detection item is abnormal.

[0055] The second part 302 represents the operations performed by the daemon process of the Sidecar container. The working process of the Sidecar container obtains the detection items and corresponding detection rules from the Agent program; the daemon process continuously polls the configuration file saved in the OSS. If the version information of the configuration file changes, the configuration file is pulled, and a new Agent program is created according to the configuration file, and then the original Agent program is closed, thereby realizing the hot update of the detection logic executed by the working process. Specifically, the Sidecar container can support hot upgrade of global configuration and hot loading of application configuration, wherein the global configuration is the configuration for the version of the Sidecar container. SAE can update the version of the Sidecar container to improve the function of the Sidecar container. In this embodiment, the hot upgrade of the global configuration can be achieved by changing the configuration file saved in OSS. In this way, it can support the specified users to use the target version of the Sidecar container, while other users use another version, thereby playing the role of grayscale release of versions; application configuration is the configuration for the effective detection items. In this embodiment, various detection items and corresponding detection logic can be pre-configured in the Sidecar container. The effective detection item can be controlled by environment variables. The Sidecar container only detects the effective detection items, thereby realizing configuration management of the detection items.

[0056] The third part 303 represents the operations performed by the analysis system. The analysis system obtains the detection results reported by the Sidecar container and performs data visualization processing on these detection results, such as displaying these detection results in the form of graphs, so as to achieve real-time observability of the health status of the user application running environment. At the same time, the analysis system accurately defines the root cause of the problem on the environment side or the user side based on the detection results and the monitored K8S Warning events, so as to execute the corresponding operation and maintenance logic to achieve automated operation and maintenance. For example, when the K8S Warning event monitored by the analysis system represents an abnormal instance startup, if the detection result represents that there is no abnormal detection item, it indicates that the root cause is the abnormal startup of the user application itself. At this time, the analysis system can notify the user to change the configuration of the application or modify the corresponding parameters. If the detection result represents an abnormal detection item, it indicates that the root cause is an abnormality on the running environment side, such as the application deployment state dependency is not ready. At this time, the analysis system executes the corresponding operation and maintenance logic according to the detection item, such as container restart or Pod reconstruction, so as to quickly solve the problem.

[0057] The solution of this embodiment uses configurable probes to perform indiscriminate detection and reporting of the container environment within the user instance and take corresponding operation and maintenance operations, thereby ensuring the healthy status of the Pod dimension deployment and operation in the real user environment regardless of language and application, and thereby representing the actual operation status of the entire instance, eliminating problems caused by the user's own application, and fundamentally solving the problem of defining the root cause of the problem, improving stability coverage, and enhancing automated operation and maintenance capabilities.

[0058] Moreover, the detection logic of various dependent indicators in the application deployment state and running state in the probe of this embodiment is pluggable and configurable, and supports real-time hot update, so the entire environment detection can be continuously iterated to achieve more comprehensive coverage.

[0059] Corresponding to the embodiments of the aforementioned method, this specification also provides embodiments of a device for monitoring application status and a terminal used therein.

[0060] The embodiments of the device for monitoring the application status of this specification can be applied to computer devices, such as servers or terminal devices. The device embodiments can be implemented by software, hardware, or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by the processor of the file processing in which it is located reading the corresponding computer program instructions in the non-volatile memory into the memory and running them. From the hardware level, such as Figure 4 As shown in the figure, it is a hardware structure diagram of the computer device where the device for monitoring the application status of the embodiment of this specification is located, except Figure 4 In addition to the processor 410, memory 430, network interface 420, and non-volatile memory 440 shown, the server or electronic device where the device 431 is located in the embodiment may also include other hardware according to the actual function of the computer device, which will not be described in detail.

[0061] Accordingly, an embodiment of the present specification further provides a computer storage medium, in which a program is stored. When the program is executed by a processor, the method in any of the above embodiments is implemented.

[0062] The embodiments of this specification may take the form of a computer program product implemented on one or more storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing program code. Computer-usable storage media include permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include but are not limited to: phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device.

[0063] like Figure 5 As shown, Figure 5 is a block diagram of a device for monitoring application status according to an exemplary embodiment of the present specification, wherein the device is configured with a detection file, wherein the detection file is used to detect each detection item in at least one detection item, wherein the detection item is related to the running environment of the application to be tested; and the device is configured in a Pod where the application to be tested is located;

[0064] The device comprises:

[0065] A detection module 51, configured to detect the detection item according to the detection file;

[0066] The reporting module 52 is used to report the detection result to the analysis system, so that the analysis system can determine the root cause of the abnormal state of the application under test according to the detection result and the monitored alarm events.

[0067] The implementation process of the functions and effects of each module in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, which will not be repeated here.

[0068] For the device embodiment, since it basically corresponds to the method embodiment, the relevant parts can refer to the partial description of the method embodiment. The device embodiment described above is only schematic, wherein the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this specification. A person of ordinary skill in the art can understand and implement it without paying creative labor.

[0069] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0070] Those skilled in the art will readily appreciate other embodiments of the specification after considering the specification and practicing the invention claimed herein. The specification is intended to cover any variations, uses or adaptations of the specification that follow the general principles of the specification and include common knowledge or customary techniques in the art that are not claimed in the specification. The specification and examples are to be considered exemplary only, and the true scope and spirit of the specification are indicated by the following claims.

[0071] It should be understood that the present description is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present description is limited only by the appended claims.

[0072] The above description is only a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this specification should be included in the scope of protection of this specification.

Claims

1. A method for monitoring application status, applied to a probe container, wherein a detection file is configured in the probe container, wherein the detection file is used to detect each detection item in at least one detection item, wherein the detection item is related to the operating environment of the application to be tested; The probe container is configured in the Pod where the application to be tested is located; The method comprises: Testing the test items according to the test file; The detection results are reported to the analysis system, so that the analysis system can determine the root cause of the abnormal state of the application to be tested based on the detection results and the monitored alarm events. 2 . The method according to claim 1 , wherein the detection item comprises at least one of a dependency item of the application to be tested when it is started and a dependency item of the application to be tested when it is running.

3. The method of claim 1, further comprising: Periodically reporting heartbeat information to the analysis system, wherein the heartbeat information carries a status code, and the status code is used to indicate whether the status of the probe container is abnormal; The reporting of the detection result to the analysis system includes: if any detection item is detected to be abnormal, setting the status code in the next reported heartbeat information to indicate that the detection item is abnormal.

4. The method according to claim 1, if it is determined according to the detection result that no detection item is abnormal, and it is determined according to the monitored alarm event that the application to be tested is in an abnormal state, then the root cause is the abnormality of the application to be tested.

5. The method of claim 1, wherein the detection file is obtained from an agent program; The method further comprises: Detecting version information of a configuration file in a specified storage area, where the configuration file is used to indicate configuration of the detection file; If the detected version information is changed, the configuration file is obtained, and a new agent program is created according to the configuration file.

6. The method of claim 5, wherein the probe container comprises: A daemon process, used for obtaining the configuration file and creating a new agent program according to the configuration file; as well as A working process is used to detect the detection item according to the detection file. 7 . The method according to claim 1 , wherein the application to be tested is deployed in a target business container, and the target business container and the probe container are created in parallel.

8. A system for monitoring application status, comprising a target business container, a probe container and an analysis system, wherein the target business container and the probe container are encapsulated in the same Pod; wherein: The target service container is used to carry the startup and operation of the application to be tested; The probe container is configured with a detection file, the detection file is used to detect each detection item in at least one detection item, and the detection item is related to the running environment of the application to be tested; the probe container is used to detect the detection item according to the detection file, and report the detection result to the analysis system; The analysis system is used to determine the root cause of the abnormal state of the application to be tested according to the detection results and the monitored alarm events.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the method according to any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium having a computer program stored thereon, wherein when the program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images