CN114840306A - Service resource availability monitoring method, device, equipment and readable storage medium - Google Patents
Service resource availability monitoring method, device, equipment and readable storage medium Download PDFInfo
- Publication number
- CN114840306A CN114840306A CN202210438457.5A CN202210438457A CN114840306A CN 114840306 A CN114840306 A CN 114840306A CN 202210438457 A CN202210438457 A CN 202210438457A CN 114840306 A CN114840306 A CN 114840306A
- Authority
- CN
- China
- Prior art keywords
- interface
- target
- container
- service
- monitoring
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 69
- 238000012544 monitoring process Methods 0.000 title claims abstract description 69
- 230000002159 abnormal effect Effects 0.000 claims abstract description 60
- 230000008569 process Effects 0.000 claims abstract description 34
- 230000015654 memory Effects 0.000 claims description 12
- 230000005856 abnormality Effects 0.000 claims description 9
- 238000004590 computer program Methods 0.000 claims description 8
- 238000005516 engineering process Methods 0.000 claims description 8
- 238000012806 monitoring device Methods 0.000 abstract description 2
- 238000013024 troubleshooting Methods 0.000 description 6
- 238000010586 diagram Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 3
- 238000010276 construction Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 230000006399 behavior Effects 0.000 description 1
- FFBHFFJDDLITSX-UHFFFAOYSA-N benzyl N-[2-hydroxy-4-(3-oxomorpholin-4-yl)phenyl]carbamate Chemical compound OC1=C(NC(=O)OCC2=CC=CC=C2)C=CC(=C1)N1CCOCC1=O FFBHFFJDDLITSX-UHFFFAOYSA-N 0.000 description 1
- 238000009960 carding Methods 0.000 description 1
- 230000006378 damage Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45562—Creating, deleting, cloning virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45591—Monitoring or debugging support
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application provides a service resource availability monitoring method, which comprises the following steps: monitoring each target interface of a target container provided by the target service in the running process of the target service; in the monitoring process, monitoring each target interface in sequence according to the running sequence of each target interface so as to judge whether the interface return value of the currently monitored target interface is abnormal or not; and if the interface return value of the currently monitored target interface is abnormal, triggering an alarm prompt aiming at the current interface, and if a subsequent interface to be monitored exists, not monitoring the subsequent interface. According to the method and the device, each service interface is automatically monitored in an automatic mode, and the availability of service resources can be timely and effectively monitored. The application also provides a service resource availability monitoring device, equipment and a computer readable storage medium.
Description
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method, an apparatus, a device, and a computer-readable storage medium for service resource availability monitoring.
Background
docker is a software running on Linux and Windows for creating, managing and arranging containers; the docker container is a specific example of operation, which can be understood as an operating environment; the docker service is providing the created docker container instance externally. Successful delivery of a docker container includes 3 major interfaces of application (app), progress request (process), docker container operating status (status).
The existing docker service can only monitor whether the docker service is abnormal or not by regularly and checking related functions of the docker service by personnel, and the frequency of the personnel checking the docker service cannot be too frequent and the docker service is missed, so that part of abnormal services provided by the docker service are not found in time frequently, and the condition of feedback or complaint of a user is caused. That is, the availability of the docker service cannot be monitored timely and effectively.
Disclosure of Invention
The application provides a service resource availability monitoring method, a service resource availability monitoring device, service resource availability monitoring equipment and a computer readable storage medium, which can timely and effectively monitor the availability of service resources.
In a first aspect, the present application provides a method for monitoring service resource availability, including:
monitoring each target interface of a target container provided by a target service in the running process of the target service;
in the monitoring process, monitoring each target interface in sequence according to the running sequence of each target interface so as to judge whether the interface return value of the currently monitored target interface is abnormal or not;
and if the interface return value of the currently monitored target interface is abnormal, triggering an alarm prompt aiming at the current interface, and if a subsequent interface to be monitored exists, not monitoring the subsequent interface.
Optionally, the target service is a docker service.
Optionally, each target interface includes a container application interface, a container creation progress query interface, and a container operation state query interface.
Optionally, the determining whether the interface return value of the currently monitored target interface is abnormal includes:
for a currently monitored target interface, if the target interface is the container application interface and the interface return value of the target interface does not include the unique identifier of the target container, determining that the interface return value of the target interface is abnormal;
if the target interface is the container creation progress query interface and the interface return value of the target interface obtained by querying within the preset time length is always a first parameter value, and the first parameter value represents that the target container is being created, it is determined that the interface return value of the target interface is abnormal;
and if the target interface is the container running state query interface and the target interface does not return the accessible webpage address, judging that the interface return value of the target interface is abnormal.
Optionally, the method further includes:
if the interface return value of the container application interface comprises the unique identifier of the target container, the container creation progress inquiry interface inquires that the interface return value of the target interface comprises a second parameter value within the preset time length by using the unique identifier, and the container operation state inquiry interface returns an accessible webpage address, the target service is normal; wherein the second parameter value characterizes the target container creation success.
Optionally, the first parameter value is 0, and the second parameter value is 1.
Optionally, monitoring each target interface of the target container provided by the target service includes:
and automatically constructing and deploying an operation platform by adopting jenkins and gitlab technology so as to monitor each target interface of a target container provided by the target service.
In a second aspect, the present application provides a service resource availability monitoring apparatus, including:
an interface monitoring unit 310, configured to monitor each target interface of a target container provided by a target service in an operation process of the target service;
an anomaly determination unit 320, configured to monitor each target interface sequentially according to an operation sequence of each target interface in the monitoring process, so as to determine whether an interface return value of a currently monitored target interface is abnormal;
the alarm triggering unit 330 is configured to trigger an alarm prompt for the current interface if the interface return value of the currently monitored target interface is abnormal, and not monitor the subsequent interface if the subsequent interface to be monitored exists.
Optionally, the target service is a docker service.
Optionally, each target interface includes a container application interface, a container creation progress query interface, and a container operation state query interface.
Optionally, when the abnormality determining unit determines whether an interface return value of the currently monitored target interface is abnormal, the abnormality determining unit is specifically configured to:
for a currently monitored target interface, if the target interface is the container application interface and the interface return value of the target interface does not include the unique identifier of the target container, determining that the interface return value of the target interface is abnormal;
if the target interface is the container creation progress query interface and the interface return value of the target interface obtained by querying within the preset time length is always a first parameter value, and the first parameter value represents that the target container is being created, it is determined that the interface return value of the target interface is abnormal;
and if the target interface is the container running state query interface and the target interface does not return the accessible webpage address, judging that the interface return value of the target interface is abnormal.
Optionally, the abnormality determining unit is further configured to:
if the interface return value of the container application interface comprises the unique identifier of the target container, the container creation progress inquiry interface inquires that the interface return value of the target interface comprises a second parameter value within the preset time length by using the unique identifier, and the container operation state inquiry interface returns an accessible webpage address, the target service is normal; wherein the second parameter value characterizes the target container creation success.
Optionally, the first parameter value is 0, and the second parameter value is 1.
Optionally, the interface monitoring unit is specifically configured to:
and automatically constructing and deploying an operation platform by adopting jenkins and gitlab technology so as to monitor each target interface of a target container provided by the target service.
In a third aspect, the present application provides an electronic device, comprising: a processor, a memory;
the memory for storing a computer program;
the processor is used for executing the service resource availability monitoring method by calling the computer program.
In a fourth aspect, the present application provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the service resource availability monitoring method described above.
In the technical scheme provided by the application, each target interface of a target container provided by the target service is monitored in the running process of the target service; in the monitoring process, monitoring each target interface in sequence according to the running sequence of each target interface so as to judge whether the interface return value of the currently monitored target interface is abnormal or not; and if the interface return value of the currently monitored target interface is abnormal, triggering an alarm prompt aiming at the current interface, and if a subsequent interface to be monitored exists, not monitoring the subsequent interface. Therefore, according to the embodiment of the application, each service interface is automatically monitored in an automatic mode, the abnormal operation condition of the target service can be found more timely, the operation state of the target service can be continuously monitored without being limited by time, and the availability of service resources can be monitored timely and effectively.
Drawings
Fig. 1 is a schematic flow chart of a service resource availability monitoring method according to the present application;
fig. 2 is another schematic flow chart of a service resource availability monitoring method shown in the present application;
fig. 3 is a schematic diagram illustrating a service resource availability monitoring apparatus according to the present application;
fig. 4 is a schematic structural diagram of an electronic device shown in the present application.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
Prior to the description of the embodiments of the present application, technical terms related to the embodiments of the present application will be described.
docker: docker is a light-weight virtualization technology, is an open-source application container running environment building platform, can be packaged and applied to a portable container in a convenient mode, and then is installed on any server running Linux or Windows and other systems. Compared with the traditional virtual machine, the docker container provides a light-weight virtualization mode, is convenient to install and is fast in starting and stopping speed.
jenkins: jenkins is an open source CI & CD software for automating various tasks including building, testing, and deploying software. jenkins supports various modes of operation, either through system bags, dockers, or through a separate program.
gitlab: gitlab is an open source application that implements a self-hosted git project repository that can access public or private projects through a Web interface.
It should be noted that, in the prior art, only people can regularly go through the related functions of the docker service, and this manual troubleshooting manner is limited by the troubleshooting frequency and the troubleshooting accuracy, and cannot timely and effectively monitor the availability of the docker service, that is, cannot timely discover the service failure of the docker service. In order to solve the problems of timeliness and accuracy of a docker service verified by people through walkthrough, the embodiment of the application provides a service resource availability monitoring method.
It should be further noted that a docker container is a specific instance of operation (i.e., an operating environment), and the successful issuing of one docker container relates to 3 main interfaces of application (application), progress request (process), and status of docker container operation (status). The interface activity detection service mainly aims to solve the problem that the failure of the on-line docker service cannot be timely found, so that the user experience is influenced or the economic loss is caused. According to the embodiment of the application, the interface of the docker service on the service carding line can be detected by adopting the interface, the interface test case of the docker service interface is compiled, the jenkins + gitlab are used for building the automatic construction and automatic deployment platform, the docker service interface automatically operates according to the requirement, the interface for monitoring the docker service interface automatically operates returns the result, and the docker service operation condition is monitored.
According to the embodiment of the application, the running state of the docker service can be continuously monitored through an automatic running mode, when the service externally provided by the docker service is abnormal, early warning can be timely achieved, and related personnel can be informed to timely troubleshoot the problems.
The following describes a service resource availability monitoring method provided in the embodiment of the present application in detail.
Referring to fig. 1, a schematic flowchart of a method for monitoring service resource availability provided in an embodiment of the present application is shown, where the method includes the following steps S101 to S103:
s101: and monitoring each target interface of a target container provided by the target service in the running process of the target service.
In the embodiment of the present application, the target service may be a docker service. The target container provided by the docker service is a docker container, the docker container is a specific running instance (i.e., a running environment), and the service interfaces related to the docker container mainly include 3 main interfaces of an application (app), a progress request (process), and a status of the docker container. The application interface is used for creating an application for the docker container; the progress query interface is used for the progress query of the container creation after the docker applies for the progress query; and the running state query interface is used for querying the running state of the docker container.
Based on this, when the target container is a docker container, each target interface of the target container may include: the system comprises a container application interface (namely an application interface), a container creation progress query interface (namely a process interface), and a container operation state query interface (namely a status interface).
It should be noted that, in the embodiment of the present application, the service type of the target service is not limited, and the target service may be a docker service, or may be other services that can create, manage, and organize a container.
In the embodiment of the present application, each target interface of the target container needs to be monitored to determine whether an operating state of each target interface is abnormal. In one implementation, "monitoring each target interface of the target container provided by the target service" in S101 may include: and automatically constructing and deploying an operation platform by adopting jenkins and gitlab technology so as to monitor each target interface of a target container provided by the target service.
In this implementation manner, an operation platform may be automatically constructed and automatically deployed by using a jenkins + gitlab automation technology, so as to implement the uninterrupted operation of the monitoring behavior, and of course, a specific monitoring duration, for example, 7 × 24 hours of uninterrupted operation, may be set, so as to continuously and uninterruptedly monitor the availability of the docker service resource, that is, implement the automated construction and periodic operation of the interface monitoring by using the platform. Through the automatic operation mode, the operation state of the docker service can be continuously monitored, and when the service externally provided by the docker service is abnormal, early warning of minute level (even shorter time) can be achieved, so that related personnel can be informed to timely troubleshoot the abnormal problem.
S102: in the monitoring process, each target interface is sequentially monitored according to the running sequence of each target interface so as to judge whether the interface return value of the currently monitored target interface is abnormal.
It should be noted that each target interface of the target container may need to run according to a certain sequence, so that each target interface may be sequentially monitored according to the running sequence thereof, and specifically, the interface return value may be monitored to determine whether the interface return value of the current interface is abnormal.
Specifically, when the target service is a docker service and each target interface is a container application interface (i.e., an application interface), a container creation progress query interface (i.e., a process interface), and a container operation state query interface (i.e., a status interface), the monitoring system may determine whether the service externally provided by the docker is normal by monitoring the return value states of the application interface, the process interface, and the status interface of the docker service.
In an implementation manner of the embodiment of the present application, the step of determining whether an interface return value of a currently monitored target interface is abnormal in S102 may include:
for a currently monitored target interface, if the target interface is a container application interface and the interface return value of the target interface does not include the unique identifier of the target container, determining that the interface return value of the target interface is abnormal; if the target interface is a container creation progress query interface and the interface return value of the target interface obtained by query within a preset time length is always a first parameter value, and the first parameter value represents that the target container is being created, judging that the interface return value of the target interface is abnormal; if the target interface is a container operation state query interface and the target interface does not return the accessible webpage address, judging that an interface return value of the target interface is abnormal.
The embodiment of the application further comprises: if the interface return value of the container application interface comprises the unique identifier of the target container, the container creation progress inquiry interface inquires that the interface return value of the target interface comprises a second parameter value within a preset time length by using the unique identifier, and the container operation state inquiry interface returns an accessible webpage address, the target service is normal; the second parameter value characterizes a success of the target container creation.
Wherein the first parameter value may be 0, and the second parameter value may be 1.
Specifically, in the above implementation, for the convenience of understanding, the normal return contents of "container application interface (i.e., application interface)", "container creation progress query interface (i.e., process interface)", and "container operation state query interface (i.e., status interface)" are exemplified below.
Regarding the application interface, docker issues an application interface, and examples of normal return contents are as follows:
0, message, operation success,
"data":{"uuid":"eci-2ze8nsv9z808w2zczvbk"}}
wherein, code is 0 and message is successful, which indicates that the application is successful; uuid in date data is the unique identification (id) of the docker container.
Regarding the process interface, the docker issues a progress query interface, and the examples of the normal return contents are as follows:
0, message, success and data, process, 1, and code
Wherein, code is 0 and message is successful, which indicates that the query is successful; the process in the data represents the creation progress of the docker container, process 0 represents container creation, and process 1 represents container creation success.
Regarding status interface, docker container operation status query interface, examples of normal return contents are as follows:
0, message, operation success,
"data":{"uuid":"eci-2ze8nsv9z808w2zczvbk","start_time":"2022-03-2818:54:52","end_time":"2022-03-2819:54:52","countdown":3583,"delay_count":3,"attribute":"1","url":"http://eci-2ze8nsv9z808w2zczvbk.cloudeci1.ichunqiu.com:80"}}
wherein, code is 0 and message is successful, which indicates that the query of the running state is successful; uuid in the data is the unique id of the docker container; the start _ time is the starting time of the container operation; end _ time is the time of automatic destruction of the container; countdown is the container remaining time; delay _ count is the number of times the container allows delay; attribute is title attribute; url is the access address of the container.
Based on this, when the target container is a docker container, if no uuid exists in the application interface return value of the docker container, or the process interface queries that the process return value is always 0 within a specified time, or the status interface does not return an accessible url address, it is proved that the docker service is abnormal, and a normal service cannot be provided to the outside.
If the apply interface of the docker container successfully returns uuid, the process interface uses the uuid to inquire that the process return value is equal to 1 within the specified time, and the status interface can normally return url parameters and can normally access, the docker service is proved to be normal, and the service can be provided to the outside.
S103: and if the interface return value of the currently monitored target interface is abnormal, triggering an alarm prompt aiming at the current interface, and if a subsequent interface to be monitored exists, not monitoring the subsequent interface.
In the embodiment of the present application, if a currently monitored target interface is a "container application interface (i.e., an application interface)", when a return value of the application interface is abnormal, an alarm prompt for the application interface needs to be sent out to notify related personnel to perform timely troubleshooting on the service abnormality; if the currently monitored target interface is a container creation progress query interface (namely, a process interface), when a return value of the process interface is abnormal, an alarm prompt aiming at the process interface needs to be sent out so as to inform related personnel to perform timely troubleshooting aiming at the service abnormality; if the currently monitored target interface is a container application interface (i.e., a status interface), when a return value of the status interface is abnormal, an alarm prompt for the status interface needs to be sent out to notify relevant personnel to perform timely troubleshooting on the service abnormality.
It should be noted that, regarding the docker service, a user or an external request first applies for the docker service, after applying for the docker service, the progress of creation of the docker container may be queried, if the progress returns to 0, it indicates that the container is being created, and if the progress returns to 1, it indicates that the container is successfully created, and after the container is successfully created, the operating state of the target container may be queried through the operating state interface. It can be seen that each interface is sequentially executed, and the sequence thereof is, in turn, a container application interface (i.e., an application interface), a container creation progress query interface (i.e., a process interface), and a container operation status query interface (i.e., a status interface).
Referring to fig. 2, another flow chart of a service resource availability monitoring method is shown. As shown in fig. 2, as long as any interface return value does not meet the aforementioned agreement, it can be determined that the docker service is abnormal. For example, if the return value of the application interface is abnormal, the subsequent flow is not executed any more, and the docker service is directly judged to be abnormal; if the return value of the application interface is normal, but the process interface does not return the parameter 1 indicating that the container is successfully created within the specified time, continuing to execute the subsequent flow, and judging that the docker service is abnormal; if the return values of the application interface and the process interface are normal, but the return value of the status interface is abnormal, judging that the docker service is abnormal.
Therefore, the method for determining the running state of the docker container service and monitoring the uninterrupted continuous running of the service by means of jenkins + gitlab is mainly based on the return value states of the apply interface, the process interface and the status interface in the docker container issuing process. Compared with a manual monitoring mode adopted by the prior art, the method and the device for monitoring the operating state of the docker service can discover the abnormal operating condition of the docker service more timely and can continuously monitor the operating state of the docker service without time limitation.
In the service resource availability monitoring method provided by the embodiment of the application, each target interface of a target container provided by a target service is monitored in the running process of the target service; in the monitoring process, monitoring each target interface in sequence according to the running sequence of each target interface so as to judge whether the interface return value of the currently monitored target interface is abnormal or not; and if the interface return value of the currently monitored target interface is abnormal, triggering an alarm prompt aiming at the current interface, and if a subsequent interface to be monitored exists, not monitoring the subsequent interface. Therefore, according to the embodiment of the application, each service interface is automatically monitored in an automatic mode, the abnormal operation condition of the target service can be found more timely, the operation state of the target service can be continuously monitored without being limited by time, and the availability of service resources can be monitored timely and effectively.
Referring to fig. 3, a schematic composition diagram of a service resource availability monitoring apparatus provided in an embodiment of the present application is shown, where the apparatus includes:
the interface monitoring unit 310 is configured to monitor each target interface of a target container provided by a target service in an operation process of the target service;
an anomaly determination unit 320, configured to monitor each target interface sequentially according to an operation sequence of each target interface in the monitoring process, so as to determine whether an interface return value of a currently monitored target interface is abnormal;
the alarm triggering unit 330 is configured to trigger an alarm prompt for the current interface if the interface return value of the currently monitored target interface is abnormal, and not monitor the subsequent interface if the subsequent interface to be monitored exists.
In an implementation manner of the embodiment of the present application, the target service is a docker service.
In an implementation manner of the embodiment of the present application, each target interface includes a container application interface, a container creation progress query interface, and a container operation state query interface.
In an implementation manner of the embodiment of the present application, when determining whether an interface return value of a currently monitored target interface is abnormal, the abnormality determining unit 320 is specifically configured to:
for a currently monitored target interface, if the target interface is the container application interface and the interface return value of the target interface does not include the unique identifier of the target container, determining that the interface return value of the target interface is abnormal;
if the target interface is the container creation progress query interface and the interface return value of the target interface obtained by querying within the preset time length is always a first parameter value, and the first parameter value represents that the target container is being created, it is determined that the interface return value of the target interface is abnormal;
and if the target interface is the container running state query interface and the target interface does not return the accessible webpage address, judging that the interface return value of the target interface is abnormal.
In an implementation manner of the embodiment of the present application, the abnormality determining unit 320 is further configured to:
if the interface return value of the container application interface comprises the unique identifier of the target container, the container creation progress inquiry interface inquires that the interface return value of the target interface comprises a second parameter value within the preset time length by using the unique identifier, and the container operation state inquiry interface returns an accessible webpage address, the target service is normal; wherein the second parameter value characterizes the target container creation success.
In an implementation manner of the embodiment of the present application, the first parameter value is 0, and the second parameter value is 1.
In an implementation manner of the embodiment of the present application, the interface monitoring unit 310 is specifically configured to:
and automatically constructing and deploying an operation platform by adopting jenkins and gitlab technology so as to monitor each target interface of a target container provided by the target service.
The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the application. One of ordinary skill in the art can understand and implement without inventive effort.
An embodiment of the present application further provides an electronic device, a schematic structural diagram of the electronic device is shown in fig. 4, where the electronic device 4000 includes at least one processor 4001, a memory 4002, and a bus 4003, and the at least one processor 4001 is electrically connected to the memory 4002; the memory 4002 is configured to store at least one computer-executable instruction, and the processor 4001 is configured to execute the at least one computer-executable instruction, thereby performing the steps of any one of the service resource availability monitoring methods as provided by any one of the embodiments or any one of the alternative embodiments of the present application.
Further, the processor 4001 may be an FPGA (Field-Programmable Gate Array) or other devices with logic processing capability, such as an MCU (micro controller Unit) and a CPU (Central processing Unit).
By applying the embodiment of the application, each service interface is automatically monitored in an automatic mode, the abnormal operation condition of the target service can be found more timely, the operation state of the target service can be continuously monitored without time limitation, and the availability of service resources can be monitored timely and effectively.
The embodiments of the present application further provide another computer-readable storage medium, which stores a computer program, where the computer program is used for implementing, when executed by a processor, the steps of any one of the service resource availability monitoring methods provided in any one of the embodiments or any one of the alternative embodiments of the present application.
The computer-readable storage medium provided by the embodiments of the present application includes, but is not limited to, any type of disk including floppy disks, hard disks, optical disks, CD-ROMs, and magneto-optical disks, ROMs (Read-Only memories), RAMs (Random Access memories), EPROMs (Erasable Programmable Read-Only memories), EEPROMs (Electrically Erasable Programmable Read-Only memories), flash memories, magnetic cards, or optical cards. That is, a readable storage medium includes any medium that stores or transmits information in a form readable by a device (e.g., a computer).
By applying the embodiment of the application, each service interface is automatically monitored in an automatic mode, the abnormal operation condition of the target service can be found more timely, the operation state of the target service can be continuously monitored without time limitation, and the availability of service resources can be monitored timely and effectively.
The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the scope of protection of the present application.
Claims (10)
1. A method for service resource availability monitoring, comprising:
monitoring each target interface of a target container provided by a target service in the running process of the target service;
in the monitoring process, monitoring each target interface in sequence according to the running sequence of each target interface so as to judge whether the interface return value of the currently monitored target interface is abnormal or not;
and if the interface return value of the currently monitored target interface is abnormal, triggering an alarm prompt aiming at the current interface, and if a subsequent interface to be monitored exists, not monitoring the subsequent interface.
2. The method of claim 1, wherein the target service is a docker service.
3. The method of claim 2, wherein each target interface comprises a container application interface, a container creation progress query interface, and a container operation status query interface.
4. The method of claim 3, wherein the determining whether the currently monitored interface return value of the target interface is abnormal comprises:
for a currently monitored target interface, if the target interface is the container application interface and the interface return value of the target interface does not include the unique identifier of the target container, determining that the interface return value of the target interface is abnormal;
if the target interface is the container creation progress query interface and the interface return value of the target interface obtained by querying within the preset time length is always a first parameter value, and the first parameter value represents that the target container is being created, it is determined that the interface return value of the target interface is abnormal;
and if the target interface is the container running state query interface and the target interface does not return the accessible webpage address, judging that the interface return value of the target interface is abnormal.
5. The method of claim 4, further comprising:
if the interface return value of the container application interface comprises the unique identifier of the target container, the container creation progress inquiry interface inquires that the interface return value of the target interface comprises a second parameter value within the preset time length by using the unique identifier, and the container operation state inquiry interface returns an accessible webpage address, the target service is normal; wherein the second parameter value characterizes the target container creation success.
6. The method of claim 5, wherein the first parameter value is 0 and the second parameter value is 1.
7. The method according to any one of claims 1 to 6, wherein monitoring each target interface of a target container provided by the target service comprises:
and automatically constructing and deploying an operation platform by adopting jenkins and gitlab technology so as to monitor each target interface of a target container provided by the target service.
8. A service resource availability monitoring apparatus, comprising:
the interface monitoring unit is used for monitoring each target interface of a target container provided by a target service in the running process of the target service;
the abnormality judgment unit is used for monitoring each target interface in sequence according to the running sequence of each target interface in the monitoring process so as to judge whether the interface return value of the currently monitored target interface is abnormal or not;
and the alarm triggering unit is used for triggering an alarm prompt aiming at the current interface if the interface return value of the currently monitored target interface is abnormal, and not monitoring the subsequent interface if the subsequent interface to be monitored exists.
9. An electronic device, comprising: a processor, a memory;
the memory for storing a computer program;
the processor configured to execute the service resource availability monitoring method according to any one of claims 1 to 7 by calling the computer program.
10. A computer-readable storage medium, on which a computer program is stored, which program, when being executed by a processor, is adapted to carry out the service resource availability monitoring method of any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210438457.5A CN114840306A (en) | 2022-04-25 | 2022-04-25 | Service resource availability monitoring method, device, equipment and readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210438457.5A CN114840306A (en) | 2022-04-25 | 2022-04-25 | Service resource availability monitoring method, device, equipment and readable storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114840306A true CN114840306A (en) | 2022-08-02 |
Family
ID=82565257
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210438457.5A Pending CN114840306A (en) | 2022-04-25 | 2022-04-25 | Service resource availability monitoring method, device, equipment and readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114840306A (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110311837A (en) * | 2019-07-12 | 2019-10-08 | 广州华多网络科技有限公司 | Online service availability detection method, device and computer equipment |
| CN111385123A (en) * | 2018-12-29 | 2020-07-07 | 广州市百果园信息技术有限公司 | WEB service distributed intelligent monitoring method, device, computer equipment and storage medium |
| WO2021137062A1 (en) * | 2020-01-02 | 2021-07-08 | International Business Machines Corporation | Improving the availability of api endpoints in container orchestration platforms |
-
2022
- 2022-04-25 CN CN202210438457.5A patent/CN114840306A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111385123A (en) * | 2018-12-29 | 2020-07-07 | 广州市百果园信息技术有限公司 | WEB service distributed intelligent monitoring method, device, computer equipment and storage medium |
| CN110311837A (en) * | 2019-07-12 | 2019-10-08 | 广州华多网络科技有限公司 | Online service availability detection method, device and computer equipment |
| WO2021137062A1 (en) * | 2020-01-02 | 2021-07-08 | International Business Machines Corporation | Improving the availability of api endpoints in container orchestration platforms |
Non-Patent Citations (6)
| Title |
|---|
| KAIYANG LV: "PCCTE: A portable component conformance test environment based on container cloud for avionics software development", 《2016 INTERNATIONAL CONFERENCE ON PROGRESS IN INFORMATICS AND COMPUTING (PIC)》, 19 June 2017 (2017-06-19) * |
| 刘国庆等: "基于Charles录制会话的HTTP接口自动化测试框架设计与实现", 《计算机应用与软件》 * |
| 刘国庆等: "基于Charles录制会话的HTTP接口自动化测试框架设计与实现", 《计算机应用与软件》, no. 06, 12 June 2019 (2019-06-12) * |
| 张世海: "《云计算虚拟化技术基础与实践》", 西安电子科技大学出版社, pages: 308 - 309 * |
| 徐世豪: "基于Hudson的APP接口自动化测试", 《中国优秀博硕士学位论文全文数据库(硕士)信息科技辑》 * |
| 徐世豪: "基于Hudson的APP接口自动化测试", 《中国优秀博硕士学位论文全文数据库(硕士)信息科技辑》, 15 May 2021 (2021-05-15) * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107660289B (en) | Automatic network control | |
| CN103635885B (en) | By providing the instant availability of prebuild environment to dispose the environment for testing | |
| CN101779217A (en) | Remote health monitoring and control | |
| CN105531680A (en) | Remote monitoring system, remote monitoring method, and program | |
| CN112698857B (en) | Method and equipment for data refreshing | |
| CN111414229A (en) | Application container exception handling method and device | |
| CN108510086A (en) | Failure counte-rplan determine method and device | |
| CN103957133A (en) | Log monitoring method and device | |
| US20090089522A1 (en) | System and method for dynamic storage device reconfiguration | |
| JP4918668B2 (en) | Virtualization environment operation support system and virtualization environment operation support program | |
| CN115632706B (en) | FC link management method, device, equipment and readable storage medium | |
| CN108347339A (en) | A kind of service restoration method and device | |
| JP2012069088A (en) | Medical information processor and software distribution system | |
| CN113094053A (en) | Product delivery method and device and computer storage medium | |
| CN112054925B (en) | Method and device for deploying background service | |
| CN115238047A (en) | Robot program for monitoring | |
| CN114338363A (en) | Continuous integration method, device, equipment and storage medium | |
| CN110275795A (en) | A kind of O&M method and device based on alarm | |
| CN108111343B (en) | Method and equipment for realizing terminal monitoring based on cloud platform and computer storage medium | |
| CN108241565A (en) | A kind of system and method for being used to implement application system automation O＆M | |
| CN109426514B (en) | Service automation deployment method and device, electronic equipment and storage medium | |
| CN114840306A (en) | Service resource availability monitoring method, device, equipment and readable storage medium | |
| CN117234660A (en) | Method for deploying and operating software under micro-service architecture based on Docker container technology | |
| CN105897487B (en) | Equipment management method and device for operation and maintenance system | |
| CN115934390A (en) | Method and system for processing application program crash and device for running application program |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20220802 |
|
| RJ01 | Rejection of invention patent application after publication |