it needs to contain an identifier to identify whether the message is an early warning or a recovery, here "status", and when a recovery message is received, the content of "status" is "resolved" to facilitate the judgment of the unified message converter.

The unified message converter converts the message into an alarm message format which can be identified by Prometheus; considering the grouping strategy of Prometheus, the content is fixed by taking 'alert name' as a grouping basis; secondly, through the early warning grade division standard, the "visibility" is converted into a unified standard grade, and other basic information is converted into a cable of Prometheus.

Particularly, it is stated that "status", when "status" is recovery, it is necessary to set the endsAt item of Prometheus to rfc3339 format of the current time, and Prometheus judges whether the warning is recovered through endsAt.

The above processes all need to inject additional information such as grouping and message type information into the message according to the overall standard specification of the system, and if special service needs exist, other identifying contents can be added according to the requirements.

And sending the message to an API (application program interface) of an early warning management system Alertmanager of Prometheus for unified processing. The message will then follow the alert manager policy for subsequent processing.

According to the overall standard specification of the system, an alarm strategy meeting the standard is formulated, and the alarm strategy comprises the following steps: early warning level, grouping according to classes, and adding other identification contents according to requirements if special service requirements exist.

And after the early warning is triggered, the early warning is sent to an Alertmanager for unified processing.

And adding a unique identifier of each UUID of the new early warning to the inside of the Alertmanager component for judging the repeatability of the early warning in a later system, wherein the UUID is obtained by performing HASH operation on Labels and startsAt attributes of the early warning.

And modifying the source code of the Alertmanager, and adding a unique identification code for each early warning.

The processed early warning message is sent to the early warning data collector and the unified early warning message distributor through webhook (an external function call interface) of Alertmanager.

The early warning data collector receives the information from the Alertmanager, analyzes and splits the early warning information into database entries with single unique identification codes and inserts the database entries into the Mysql database, and if the database already contains the information, the information is not processed.

When the early warning message with the unique identification code is received again and is in a recovery state, the updating database marks the message in the recovery state.

The Mysql database stores the early warning data from the "early warning data collector".

The storage data fields include: the system comprises an early warning ID, an early warning name, a host name, an IP address, early warning information, a product type, an early warning level, early warning time, an early warning state, an early warning label, an early warning unique identification code, a claim state, a claimant, claim time, closing time and completion time.

The uniform early warning message distributor receives the message from the Alertmanager, and sends the message to E-mail, nail, short message and telephone in a mode of self-defining template according to different warning levels and grouping information.

The early warning information management platform UI is a webpage-form early warning information management system, and has the functions of allowing technicians to log in through own accounts, claim early warning information, and mark a processing process and a processing result in a comment form after the early warning information is processed; and searching and screening historical early warning information.

The implementation mode of the method is divided into a front end part and a rear end part, the front end is developed by adopting a mainstream front end framework VUE, and the rear end is compiled by adopting a Python Web framework flash.

Claims

1. Monitoring system and method based on Zabbix and Prometous, including Zabbix and Prometous two systems, characterized by that to change Zabbix monitoring system into the message format that Prometous monitoring system can discern through the unified message converter, Zabbix monitoring system and Prometous monitoring system Alertmanager's assembly.

2. The Zabbix and Prometheus based monitoring system and method of claim 1 wherein the information is received by the unified warning message distributor and sent to the warning agent.

3. The Zabbix and Prometheus based monitoring system and method of claim 1 wherein the alert manager component files messages to Mysql database simultaneously through the early warning data collector.

4. The Zabbix and Prometheus based monitoring system and method as claimed in claim 3, wherein UUID unique identifier for each new pre-alarm is added in Alertmanager for the repeated judgment of pre-alarm in the following system, and the UUID is obtained by HASH operation based on labels and startsAt attribute of pre-alarm.

5. The monitoring system and method based on Zabbix and Prometheus as claimed in claim 3, wherein Mysql database can be managed and analyzed uniformly through chart display and early warning information management platform.