CN106713014B - Monitored host in monitoring system, monitoring system and monitoring method - Google Patents

Abstract

A monitored host, a monitoring system and a monitoring method are used to provide the monitoring host with the ability to interact with an external business system. The monitored host includes a monitoring client, an agent tool module and a business module, the agent tool module provides a service interface to the business module, the business module records a key associated with each business failure category, and one-to-one keys associated with the key The corresponding fault description parameter set; when the business module fails to interact with the business system outside the host, the business module sends the key corresponding to the business failure and the value of the fault description parameter corresponding to this failure to the proxy tool module through the service interface. value; the proxy tool module writes the value of each fault description parameter into the template file corresponding to the key, generates and reports monitoring information to the monitoring server. Through the above method, it is possible to monitor the service failure caused by the failure of the non-monitored host.

Description

A monitored host in a monitoring system, a monitoring system and a monitoring method

technical field

The present application relates to the field of network technologies, and in particular, to a monitored host in a monitoring system, a monitoring system, and a monitoring method.

Background technique

Zabbix is an open source distributed monitoring system that enables data monitoring of network devices. As shown in Figure 1, the Zabbix monitoring system includes a service host and several monitored hosts, and only one monitored host is shown in Figure 1. The service host includes a Zabbix network (ie web) graphical user interface (Graphical User Interface, GUI), a Zabbix database and a Zabbix server. In a device monitoring solution implemented by Zabbix, the Zabbix client and monitoring scripts are installed on the monitored host. The user adds some configuration information such as monitoring items in the Zabbix server through the Zabbix network GUI, and configures the key of the monitoring item and the corresponding monitoring script in the configuration file of the monitoring client. The Zabbix client will synchronize some configuration information such as monitoring items from the Zabbix server, schedule the corresponding monitoring script to collect monitoring data according to the configuration information, and report the collected monitoring data to the Zabbix server. The Zabbix server stores the received monitoring data into the Zabbix database, and users can view the results of the monitoring data through the Zabbix network GUI.

A service process runs on the monitored host, and the user interacts with a business system outside the host through the service process, and the business system may be a communication system, a database system, or a web service system, and so on. Since the Zabbix system only monitors the monitored host itself, when the link between the monitored host and the business system fails or the business system fails, the Zabbix system cannot detect the fault in time. For example, the monitored host may be connected to a communication system, the monitored host may be connected to an operator's short message gateway, and users using the monitored host send short messages through the short message gateway. However, if the communication link between the monitored host and the short message gateway fails or the short message gateway itself fails, the user cannot send short messages through the monitored host, thus causing the user's short message service to fail. If there is a fault, the Zabbix system cannot know the user's short message service fault in time, so it cannot report the short message fault information to the administrator or user in time.

SUMMARY OF THE INVENTION

Embodiments of the present application provide a monitored host in a monitoring system, a monitoring system, and a monitoring method, so as to solve the problem that when a link between a monitored host and a business system fails or a business system fails, the monitoring system cannot detect the failure in time. problem of failure.

The specific technical solutions provided by the embodiments of the present application are as follows: In a first aspect, a monitored host in a monitoring system is provided, where the monitored host includes a monitoring client, an agent tool module, and a business module, and the agent tool module reports to the The business module provides a service interface, the business module records a key associated with each type of business failure, and a set of failure description parameters corresponding to the key one-to-one; the proxy tool module records the corresponding relationship between the key and the template file, in the template file Including the failure description parameter set corresponding to the key; when the interaction between the business module and the business system outside the host fails, the business module sends the key corresponding to the business failure and the failure corresponding to this failure to the proxy tool module through the service interface. The value of the description parameter; the proxy tool module writes the value of each fault description parameter into the template file corresponding to the key, and generates and reports monitoring information to the monitoring server. In the embodiment of the present invention, by adding an agent tool module to the monitored host, the agent tool module provides a service interface to the business module, defines the fault reporting process of the business module after the business fails, and realizes the monitoring system for the failure of the non-monitored host. Monitoring of business failures caused. The business module does not need to be coupled with the monitoring system. The business module only needs to define the key and all the fault description parameters in JSON format required by the abnormal business scenario according to its own business exception.

In a possible design, the proxy tool module generates a value after writing the value of each fault description parameter into the template file, where the value is a character string corresponding to the value of each fault description parameter ; Correspondingly, the monitoring information includes the key corresponding to the category of this service failure and the value.

In another possible design, the proxy tool module may report the monitoring information to the monitoring server by invoking a command line tool of the monitoring client; or, the proxy tool module may report the monitoring information to the monitoring server. The information is sent to the monitoring client, so that the monitoring client sends the monitoring information to the monitoring server.

In another possible design, the proxy tool module provides a local loopback address to the service module through the service interface, and receives the service failure information transmitted by the service module through HTTP.

The fault description parameter may use a JSON object.

In a possible scenario, the embodiment of the present invention can customize the content and format of the monitoring information as required by changing the combination of the template file and the JSON object, and report the customized monitoring information to the monitoring server, which is convenient for the system administrator View detailed business exceptions. On the other hand, since the stateless HTTP communication is used between the business module and the agent tool module, even if the process of the monitoring system fails, it will not affect the business module, thus not affecting the user's business and ensuring the business continuity. Safety.

The proxy tool module may also implement a flow control policy to limit the reporting frequency of service failures of the same category. The flow control policy includes limiting the reporting frequency of monitoring information corresponding to the same key value to be no greater than a preset value.

The agent tool module is co-located with the monitoring client.

In a second aspect, a monitoring system is provided, including: a monitoring client, an agent tool module, and a monitoring server, the monitoring client and the agent tool module run on a monitored host, and the agent tool module reports to a business module A service interface is provided; wherein, the proxy tool module has the function of implementing the proxy tool module described in the first aspect above.

A third aspect provides a monitoring method. Corresponding to the aforementioned first aspect, the business module, the agent tool module, and the monitoring server perform the functions of the corresponding modules in the first aspect.

In a fourth aspect, a monitored host in another monitoring system is provided, and the monitored host in the monitoring system has the function of implementing the behavior of the monitored host in the first aspect and any possible design. The functions can be implemented by hardware, or can be implemented by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

In one possible design, the monitored host in the monitoring system includes a transceiver and a processor, wherein the processor is configured to invoke a set of program codes to execute as described in the second aspect and any of the possible designs method.

In a fifth aspect, a computer storage medium is provided for storing computer software instructions used by the monitored host described in the above-mentioned aspects, including the program designed for executing the above-mentioned aspects.

Description of drawings

Fig. 1 is the Zabbix monitoring system architecture diagram in the prior art;

FIG. 2 is an architecture diagram of a monitoring system in an embodiment of the present application;

3 is a schematic flowchart of a monitoring method in an embodiment of the present application;

FIG. 4 is a schematic diagram of the hardware structure of the monitored host in the monitoring system according to the embodiment of the present application.

Detailed ways

In order to make the objectives, technical solutions and advantages of the present application clearer, the present application will be further described below with reference to the accompanying drawings.

As shown in FIG. 2, it is a schematic structural diagram of a monitoring system provided by an embodiment of the present invention. The monitoring system includes a monitored host 11 and a monitoring server 12, and the monitoring system is connected to a business system 14 through a network 13. Specifically, the monitored host The host includes a monitoring client 111 , an agent tool module 112 and a business module 113 . The proxy tool module 112 provides a service interface to the business module 113, the business module 113 interacts with the proxy tool module 112 through the service interface, and the business module 113 communicates with the proxy tool module 112 by calling the interface of the business system 14. business system interaction.

In a possible scenario, the user logs in to the monitored host 11 , runs an application on the host 11 , and the application accesses the external business system 14 through the business module 113 to access services provided by the business system 14 . For example, the service system 14 may be a short message system, and the service module 113 is connected to the short message center of the service system 14 through the network 13, and sends short messages externally through the short message center.

When the host 11 itself is running normally, the link between the host and the service system 14 or the service system 14 is faulty, so that the user cannot use the short message service normally, the monitoring server needs to be informed of the occurrence of the fault in time. In order to achieve the above purpose, In the embodiment of the present invention, an agent tool module 112 is newly added on the host 11, and the agent tool module 112 provides a service interface to the business module 113. When the business module 113 detects a business failure, the agent tool module 112 is sent to the agent tool module 112 through the service interface. The service failure information is reported, so that the monitoring information of the service failure is reported to the monitoring server through the proxy tool module 112 .

In a possible scenario, the host 11 may be any physical server in a physical server cluster, and the physical server cluster may be a cloud computing physical server cluster, providing cloud services to users; in another possible scenario, the host 11 can be an independent physical server. The monitoring server 12 may run on an independent physical server.

In a possible design, the business module 113 may be a service process for processing business. Exemplarily, the service module 113 may be an NS (notification service) process that communicates with the short message center.

The service module 113 is connected to the external service system 14 to access services provided by the service system 14 . When the service access fails, the service module 113 determines the category of the service failure and the set of failure description parameters for the service failure.

It should be noted that the categories of business failures represent factors that cause business failures. Exemplarily, the categories of service failures may include link failures, invalid accounts, or service system failures, etc., and the failure description parameter set may include process identifiers, service system addresses, and failure indications, etc., which can accurately describe the cause of the service failure. gather. Different service failure categories may correspond to different sets of failure description parameters. Those skilled in the art can understand that the types of service failures and the set of fault description parameters can be flexibly defined according to different scenarios, and the embodiment of the present invention does not limit the types of service failures to the above examples.

Further, the monitoring system can describe monitoring information in a key-value format. At this time, before the monitoring system starts to run, the business module 113 can record a key associated with each business failure category, and a set of failure description parameters corresponding to the key one-to-one, and the business module 113 corresponds to each business failure category The key and the fault description parameter set corresponding to the key one-to-one are sent to the agent tool module 112. In a possible design, a key is allocated for each service failure category, and the key can uniquely identify the service failure category. For example, the service failure category is connection timeout, link no response, link port failure, etc. The corresponding key can be set freely, or can be set according to the definition rules of the task.

The proxy tool module 112 records the corresponding relationship between the key and the template file, and the template file includes the fault description parameter set corresponding to the key.

In a possible design, the proxy tool module 112 provides a RESTful interface to the business module 113, and the request content of the interface can be any data in JSON (JavaScript Object Notation) format. The proxy tool module 112 generates a template file, and each fault description parameter in the fault description parameter set is metadata in the template file. A business failure type can correspond to a template file. Among them, the JSON object is a lightweight data exchange syntax format, please refer to https://www.w3.org/TR/json-ld/ for the specific description of JSON.

The business module 113 interacts with the business system 14 through the network 13, and when the business fails, sends business failure information to the proxy tool module 112 through the service interface, and the business failure information includes the category corresponding to the current business failure. The value of each fault description parameter in the key and the fault description parameter set, where the value of each fault description parameter can accurately represent the information of the current service failure, including the service name and failure reason, etc. Specifically, it can be identified by the process identifier. Indicates the business name.

The proxy tool module 112 receives the service fault information sent by the service module 113 through the service interface, searches the template file corresponding to the key according to the corresponding relationship, and writes the value of each fault description parameter into the template file to generate monitoring information.

In a possible design, the proxy tool module 112 reads the data in JSON format provided by the business module 113 (service process) calling the RESTful interface, writes the value of each fault description parameter into the template file, and generates a final monitoring information. Specifically, the proxy tool module 112 generates a value according to the written template file, and the value is a character string corresponding to the value of each fault description parameter. Correspondingly, the monitoring information includes the failure of this service. The key corresponding to the category and the value.

The proxy tool module 112 reports the generated monitoring information to the monitoring server 12 through the monitoring client 111 .

The proxy tool module 112 can call the command line tool of the monitoring client 111 in a synchronous or asynchronous manner, and report the monitoring information to the monitoring server 12; The monitoring information is sent to the monitoring client 111 , so that the monitoring client 111 sends the monitoring information to the monitoring server 12 .

In order to improve the monitoring efficiency of the monitoring system and avoid repeated and high-frequency reporting of the same fault, the proxy tool module 112 may also have a flow control function to limit the number of times the same monitoring information is repeatedly sent. For example, the proxy tool module 112 executes a flow control policy, and the flow control policy includes limiting the reporting frequency of monitoring information corresponding to the same key value to be no greater than a preset value. It is understood by those skilled in the art that the above-mentioned preset value can be flexibly set by the system administrator according to requirements, and preferably, the reporting frequency can be set according to the importance of the service.

In a possible design, the agent tool module 112 may be deployed independently, or may be deployed in combination with the monitoring client 111 .

The proxy tool module 112 provides a local loopback address (eg: 127.0.0.1) to the business module 113 through the RESTful service interface, and receives the business transmitted by the business module 113 through the HyperText Transfer Protocol (HTTP, HyperTextTransfer Protocol) mode accident details. Specifically, for the description of Representational state transfer (REST) architecture and RESTful interface, please refer to https://zh.wikipedia.org/wiki/REST and https://en.wikipedia.org/wiki/RESTful.

The embodiment of the present application provides a monitored host 11 in a monitoring system, an agent tool module 112 (AgentTool) is newly added to the host 11, and the above solution solves the problem of the service module 113 reporting faults after a service failure . On the one hand, the business module 113 does not need to be coupled with the monitoring system, and the business module 113 only needs to define the key and all the fault description parameters in JSON format required by the abnormal business scenario according to its own business exception scenario. On the other hand, by changing the combination of template files and JSON objects, the content and format of monitoring information can be customized as needed, and customized monitoring information can be reported to the monitoring server, so that system administrators can view detailed business exceptions. On the other hand, since the stateless HTTP communication is used between the business module 113 and the proxy tool module 112, even if the process of the monitoring system fails, the business module will not be affected, so that it will not affect the user's business. business security.

In this embodiment of the present invention, the monitoring system may be a Zabbix system, and the aforementioned command line tool may be Zabbix Sender, which may transmit Key/Value parameters.

Based on the architecture of the monitoring system shown in FIG. 2 , the monitoring method provided by the embodiment of the present application will be described below.

Referring to FIG. 3 , a monitoring method is provided in an embodiment of the present application.

Step 301: The service module accesses the service system through the network, and determines the key corresponding to the service failure category and the set of failure description parameters of the service failure according to possible abnormal conditions of the service.

The business failure category represents the factors that caused the business failure. Exemplarily, the categories of service failures may include link failures, invalid accounts, or service system failures, etc., and the failure description parameter set may include process identifiers, service system addresses, and failure indications, etc., which can accurately describe the cause of the service failure. gather. Different service failure categories may correspond to different sets of failure description parameters. Each fault description parameter in the fault description parameter set can be in JSON format.

An example is as follows:

Key: smn-001-001

JSON body: set of fault description parameters

{

"Subject":"Channel Checking",

"ServiceName":"SMN-NS"

"ServiceAddress": "127.0.0.1"

"Error": "Error"

}

Step 302: The service module sends the key corresponding to each service failure category and the failure description parameter set corresponding to the key one-to-one to the agent tool module.

In a possible design, the proxy tool module provides a RESTful interface to the business module.

Step 303: The proxy tool module receives the key sent by the business module and the fault description parameter set corresponding to the key one-to-one, and records the correspondence between the key and the template file, where the template file includes the fault description parameter set corresponding to the key.

The proxy tool module generates a template file, and each fault description parameter in the fault description parameter set is a dynamic variable in the template file, which is used to represent metadata. A business failure type can correspond to a template file.

Template file example:

Step 304: The system administrator logs in to the monitoring server through the graphical user interface of the monitoring system, and creates keys and monitoring indicators.

In a possible design, the agent tool module can send the key and the fault description parameter set to the monitoring server, and the monitoring server creates the key and monitoring indicators, and the monitoring indicators can be in text format for presenting the received monitoring information.

Step 305: The business module accesses the business system through the network, and when a business failure is found, the service interface provided by the agent tool module is invoked, and the business failure information is sent to the agent tool module, where the business failure information includes the key corresponding to the category of the current business failure and the value of each fault description parameter in the fault description parameter set, wherein the value of each fault description parameter can accurately represent the information of the current service failure, including the service name and the failure reason.

Step 306: The agent tool module receives the service failure information sent by the service module through the service interface, searches for the template file corresponding to the key according to the corresponding relationship, and writes the values of the respective failure description parameters into the template file to generate monitoring information.

Step 307: The agent tool module sends the monitoring information to the monitoring server.

Specifically, the proxy tool module reads the data in JSON format in the fault description parameter set, and writes the value of each fault description parameter into the template file to generate a value, where the value is the character corresponding to the value of each fault description parameter string. The proxy tool module uses the key corresponding to the business failure type and the generated value as the input parameters of the command line tool, and calls the command line tool of the monitoring client to send the monitoring information (that is, the key and the generated value) to the monitoring service end.

Specifically, the proxy tool module may call the command line tool of the monitoring client in a synchronous or asynchronous manner, and report the monitoring information to the monitoring server; or, the proxy tool module may send the monitoring information to the monitoring client, so that the monitoring client sends the monitoring information to the monitoring server.

A JSON-based remote call protocol (JSON-remote protocol call, JSON-RPC) may be used between the proxy tool module and the monitoring server.

Examples of monitoring information are as follows:

key: smn-001-001

value:

Senior Alert: Channel Checking

Components SMN-NS 127.0.0.1

Error: Can not connect channel

Step 308: The monitoring server receives the monitoring information, and when it is determined that the service fails, triggers an alarm and notifies the system administrator.

In the embodiment of the present invention, by adding an agent tool module to the monitored host, the agent tool module provides a service interface to the business module, and defines the fault reporting process of the business module 113 after a business failure, so as to realize the monitoring system for the non-monitored host. Monitoring of business failures caused by failures. On the one hand, the business module does not need to be coupled with the monitoring system, and the business module only needs to define the key and all the fault description parameters in JSON format required by the abnormal business scenario according to its own business exception. On the other hand, by changing the combination of template files and JSON objects, the content and format of monitoring information can be customized as needed, and customized monitoring information can be reported to the monitoring server, so that system administrators can view detailed business exceptions. On the other hand, since the stateless HTTP communication is used between the business module and the agent tool module, even if the process of the monitoring system fails, it will not affect the business module, thus not affecting the user's business and ensuring the business continuity. Safety.

Corresponding to the aforementioned monitoring system and monitoring method, an embodiment of the present invention provides a monitored host, including the aforementioned monitoring client, an agent tool module, and a service module. Each module in the monitored host executes the functions in the aforementioned monitoring system and monitoring method, which will not be repeated in this embodiment of the present invention.

Corresponding to the aforementioned monitoring system and monitoring method, an embodiment of the present invention provides another monitored host, including the aforementioned monitoring client and an agent tool module. Each module in the monitored host executes the functions in the aforementioned monitoring system and monitoring method, which will not be repeated in this embodiment of the present invention. At this time, the service module may be located on another host that has a network connection relationship with the monitored host.

Based on the same inventive concept, referring to FIG. 4 , the embodiment of the present application further provides a monitored host 400 in another monitoring system, including a transceiver 401, a processor 402, and a memory 403. The transceiver 401 and the memory 403 are all the same as the The processor 402 is connected. It should be noted that the connection between the various parts shown in FIG. 4 is only a possible example. There is no connection with the storage 403, or other possible connection methods are also possible.

The memory 403 stores a set of programs, and the processor 402 is used to call the programs stored in the memory 403 to execute the functions of the modules of the monitored host in the monitoring system and monitoring method shown in FIG. 2 and FIG. 3 .

In FIG. 4 , the processor 402 may be a central processing unit (English: central processing unit, abbreviation: CPU), a network processor (English: network processor, abbreviation: NP), or a combination of CPU and NP.

The processor 402 may further include hardware chips. The above-mentioned hardware chip may be an application-specific integrated circuit (English: application-specific integrated circuit, abbreviation: ASIC), a programmable logic device (English: programmable logic device, abbreviation: PLD) or a combination thereof. The above-mentioned PLD may be a complex programmable logic device (English: complex programmable logic device, abbreviation: CPLD), a field programmable gate array (English: field-programmable gate array, abbreviation: FPGA), a general array logic (English: generic arraylogic , abbreviation: GAL) or any combination thereof.

The memory 401 may include a volatile memory (English: volatile memory), such as random-access memory (English: random-access memory, abbreviation: RAM); the memory 401 may also include a non-volatile memory (English: non-volatile memory) ), such as flash memory (English: flash memory), hard disk (English: hard diskdrive, abbreviation: HDD) or solid-state drive (English: solid-state drive, abbreviation: SSD); the memory 401 may also include the above-mentioned types of memory. combination.

The physical server where the monitoring server is located may also adopt the hardware structure shown in FIG. 4 . This embodiment of the present invention will not be described repeatedly.

As will be appreciated by those skilled in the art, the embodiments of the present application may be provided as a method, a system, or a computer program product. Accordingly, the application may take the form of a hardware embodiment, a software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

Such computer program codes may be stored in computer readable memory which directs a computer or other programmable data processing device to function in a particular manner.

Obviously, those skilled in the art can make various changes and modifications to the embodiments of the present application without departing from the spirit and scope of the embodiments of the present application. Thus, if these modifications and variations of the embodiments of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims (17)

1. A monitored host, comprising: a monitoring client, an agent tool module and a business module, wherein the agent tool module provides a service interface for the business module,

the service module is used for recording a key associated with each service failure category and fault description parameter sets corresponding to the keys one by one;

the agent tool module is used for recording the corresponding relation between a key and a template file, and the template file comprises a fault description parameter set corresponding to the key;

the service module is also used for interacting with a service system through a network, and when a service fails, service fault information is sent to the agent tool module through the service interface, wherein the service fault information comprises keys corresponding to the type of the service failure and values of fault description parameters in a fault description parameter set;

the agent tool module is further configured to receive service fault information sent by the service module through the service interface, search a template file corresponding to the key according to the correspondence, write values of the fault description parameters into the template file, and generate monitoring information;

and the agent tool module is also used for reporting the generated monitoring information to the monitoring server through the monitoring client.

2. The monitored host according to claim 1, wherein the agent module is further configured to generate a value after writing the value of each fault description parameter into a template file, where the value is a character string corresponding to the value of each fault description parameter;

correspondingly, the monitoring information includes the key corresponding to the service failure category and the value.

3. The monitored host of claim 1,

the agent tool module is specifically used for calling a command line tool of the monitoring client and reporting the monitoring information to the monitoring server; or,

the agent tool module is specifically configured to send the monitoring information to the monitoring client, so that the monitoring client sends the monitoring information to the monitoring server.

4. The monitored host according to any one of claims 1-3, wherein the agent module is specifically configured to provide a local loopback address to the traffic module through the service interface, and receive the traffic failure information transmitted by the traffic module in a hypertext transfer protocol (HTTP) manner.

5. A monitored host according to any one of claims 1-3,

the agent tool module is further configured to execute a flow control strategy, where the flow control strategy includes that the reporting frequency of monitoring information corresponding to the same key value is limited to be not greater than a preset value.

6. A monitored host as claimed in any one of claims 1 to 3, wherein the service interface employs HTTP; the fault description parameters are object notation JSON objects.

7. A monitored host as claimed in any one of claims 1 to 3, wherein said agent module is co-located with said monitoring client.

8. A monitoring system is characterized by comprising a monitoring client, an agent tool module and a monitoring server, wherein the monitoring client and the agent tool module run on a monitored host, the agent tool module provides a service interface for a business module,

the agent tool module is used for recording the corresponding relation between the keys and a template file, wherein the template file comprises a fault description parameter set corresponding to the keys, and each key corresponds to a service failure category;

the agent tool module is also used for receiving service fault information sent by the service module through the service interface, wherein the service fault information comprises keys corresponding to the types of the service failure and values of all fault description parameters in the fault description parameter set;

the agent tool module is further configured to search a template file corresponding to the key according to the corresponding relationship, write the fault description parameter into the template file, generate monitoring information, and report the generated monitoring information to the monitoring server through the monitoring client;

and the monitoring server is used for receiving the monitoring information.

9. The monitoring system according to claim 8, wherein the agent module is further configured to generate a value after writing the value of each fault description parameter into a template file, where the value is a character string corresponding to the value of each fault description parameter;

correspondingly, the monitoring information includes the key corresponding to the service failure category and the value.

10. A monitoring system in accordance with claim 8,

the agent tool module is specifically used for calling a command line tool of the monitoring client and reporting the monitoring information to the monitoring server; or,

the agent tool module is specifically configured to send the monitoring information to the monitoring client, so that the monitoring client sends the monitoring information to the monitoring server.

11. A monitoring system according to any one of claims 8-10,

the agent tool module is specifically configured to provide a local loopback address to the service module through the service interface, and receive the service fault information transmitted by the service module in an HTTP manner.

12. A monitoring system according to any one of claims 8-10,

the agent tool module is further configured to execute a flow control strategy, where the flow control strategy includes that the reporting frequency of monitoring information corresponding to the same key value is limited to be not greater than a preset value.

13. A method for monitoring a service, comprising:

the service module records a key associated with each service failure category and a fault description parameter set corresponding to the key one by one, and sends the key corresponding to each service failure category and the fault description parameter set corresponding to the key one by one to the agent tool module;

the agent tool module records the corresponding relation between the key and the template file, and the template file comprises a fault description parameter set corresponding to the key;

the service module interacts with a service system through a network, and when a service fails, service fault information is sent to the agent tool module through the service interface, wherein the service fault information comprises keys corresponding to the type of the service failure and values of fault description parameters in a fault description parameter set;

the agent tool module receives the service fault information sent by the service module through the service interface, searches the template file corresponding to the key according to the corresponding relation, writes the value of each fault description parameter into the template file, and generates monitoring information;

and the agent tool module reports the generated monitoring information to the monitoring server through the monitoring client.

14. The monitoring method according to claim 13, wherein the value is a character string corresponding to the value of each fault description parameter, and accordingly, the monitoring information includes a key corresponding to the category in which the current service fails and the value.

15. The monitoring method of claim 13, wherein the agent module reporting the generated monitoring information to the monitoring server through the monitoring client comprises:

the agent tool module calls a command line tool of the monitoring client and reports the monitoring information to the monitoring server; or,

and the agent tool module sends the monitoring information to the monitoring client so that the monitoring client sends the monitoring information to the monitoring server.

16. The monitoring method according to any one of claims 13-15, wherein the receiving, by the agent module, the service failure information sent by the service module via the service interface comprises:

the agent tool module provides a local loopback address for the business module through the service interface and receives the business fault information transmitted by the business module in an HTTP mode.

17. A method of monitoring as claimed in any of claims 13 to 15, the method further comprising:

and the agent tool module executes a flow control strategy, wherein the flow control strategy comprises that the reporting frequency of the monitoring information corresponding to the same key value is limited to be not more than a preset value.

Images