CN112328448A - Zookeeper-based monitoring method, monitoring device, equipment and storage medium - Google Patents

Zookeeper-based monitoring method, monitoring device, equipment and storage medium Download PDF

Info

Publication number
CN112328448A
CN112328448A CN202011193145.XA CN202011193145A CN112328448A CN 112328448 A CN112328448 A CN 112328448A CN 202011193145 A CN202011193145 A CN 202011193145A CN 112328448 A CN112328448 A CN 112328448A
Authority
CN
China
Prior art keywords
information
service
configuration
instance
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
Application number
CN202011193145.XA
Other languages
Chinese (zh)
Inventor
罗博荟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ping An Property and Casualty Insurance Company of China Ltd
Original Assignee
Ping An Property and Casualty Insurance Company of China Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Ping An Property and Casualty Insurance Company of China Ltd filed Critical Ping An Property and Casualty Insurance Company of China Ltd
Priority to CN202011193145.XA priority Critical patent/CN112328448A/en
Publication of CN112328448A publication Critical patent/CN112328448A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3003Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The application relates to the technical field of cloud monitoring, and particularly discloses a monitoring method, device, equipment and storage medium based on Zookeeper, wherein the method comprises the following steps: monitoring the Zookeeper through a monitor to acquire a state change event of the Zookeeper; processing the state change event to obtain corresponding service information, wherein the service information comprises a service name of a service end and instance information of a client; acquiring configuration information of a configuration file of a monitor, wherein the configuration information at least comprises example information of a monitored client; determining whether the configuration information in the configuration file needs to be updated according to the instance information in the service information and the instance information in the configuration information; if the fact that updating is needed is determined, the configuration information is updated according to the service information, so that the Prometheus can pull the metrics information from the service end according to the updated configuration information so as to complete monitoring, automatic discovery and automatic access monitoring are further achieved, manual maintenance cost is reduced, and user experience is improved.

Description

Zookeeper-based monitoring method, monitoring device, equipment and storage medium
Technical Field
The application relates to the technical field of cloud monitoring, in particular to a Zookeeper-based monitoring method, a monitoring device, equipment and a storage medium.
Background
At present, monitoring schemes based on Zookeeper are divided into two types, one is that a client actively reports metric information to a server to realize monitoring, but due to network delay possibly existing between the client and the server, Memory overflow (Out Of Memory, OOM) occurs due to too fast increase Of a client sending queue, or the server acquires repeated data due to failure retry; the other is that the server side actively pulls the metric information through statically configuring the instance information and the pulling interface of the Zookeeper, but the scheme cannot automatically access the monitoring system, cannot achieve the aim of automatic discovery during micro-service expansion, and has high manual maintenance cost.
Disclosure of Invention
The application provides a Zookeeper-based monitoring method, a monitoring device, equipment and a storage medium, and aims to solve the problems that the target cannot be automatically found in the existing Zookeeper monitoring scheme and the manual maintenance cost is high.
In order to achieve the above object, the present application provides a Zookeeper-based monitoring method, which is characterized in that the method is applied to a micro-service monitoring system including a Zookeeper, a Prometheus and a listener, and the Prometheus and the listener realize sharing a configuration file through a network file system; the method comprises the following steps:
monitoring the Zookeeper through the monitor to acquire a state change event of the Zookeeper;
processing the state change event to obtain corresponding service information, wherein the service information comprises a service name of a service end and instance information of a client;
acquiring configuration information of a configuration file of the monitor, wherein the configuration information at least comprises example information of a monitored client;
determining whether the configuration information in the configuration file needs to be updated according to the instance information in the service information and the instance information in the configuration information;
and if the fact that updating is needed is determined, updating the configuration information according to the service information, so that the Prometheus can pull the Metrics information from the service end according to the updated configuration information so as to complete monitoring.
In order to achieve the above object, the present application further provides a Zookeeper-based monitoring device, including:
the event monitoring module is used for monitoring the Zookeeper through the monitor program so as to obtain a state change event of the Zookeeper;
the information processing module is used for processing the state change event to obtain corresponding service information, and the service information comprises a service name of a service end and instance information of a client;
the information acquisition module is used for acquiring configuration information of a configuration file of the monitoring program, wherein the configuration information at least comprises example information of a monitored client;
an update determining module, configured to determine whether configuration information in the configuration file needs to be updated according to instance information in the service information and instance information in the configuration information;
and the updating monitoring module is used for updating the configuration information according to the service information if the updating is determined to be needed, so that the Prometheus can pull the Metrics information from the service end according to the updated configuration information to complete monitoring.
In addition, to achieve the above object, the present application also provides a computer device characterized in that the computer device comprises a memory and a processor; the memory for storing a computer program; the processor is configured to execute the computer program and implement the monitoring method provided in any one of the embodiments of the present application when executing the computer program.
In addition, to achieve the above object, the present application further provides a computer-readable storage medium storing a computer program, which when executed by a processor causes the processor to implement the monitoring method according to any one of the embodiments of the present application.
The monitoring method, the monitoring device, the computer equipment and the storage medium based on the Zookeeper are used for monitoring the state change event of the Zookeeper through a monitoring program preset in a micro-service monitoring System, and realizing the sharing of the monitoring program and the configuration File of Prometheus through a Network File System (NFS), so that the server and the client which need to be monitored can be actively discovered by monitoring the state change event of the Zookeeper and updating the configuration File of the monitoring program, the automatic access is realized for monitoring, the manual maintenance cost is reduced, and the user experience is improved.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
Fig. 1 is a schematic block diagram of a prior-art zookeeper-based microservice monitoring system provided in an embodiment of the present application;
fig. 2 is a schematic block diagram of a zookeeper-based microservice monitoring system provided in an embodiment of the present application;
fig. 3 is a schematic flowchart of a zookeeper-based monitoring method according to an embodiment of the present application;
FIG. 4 is a flowchart illustrating a sub-step of determining whether to update configuration information according to an embodiment of the present application;
FIG. 5 is a flowchart illustrating another sub-step of determining whether to update configuration information according to an embodiment of the present application;
FIG. 6 is a flowchart illustrating a sub-step of updating configuration information according to an embodiment of the present application;
fig. 7 is a schematic diagram illustrating an effect of displaying Metrics information according to an embodiment of the present disclosure;
fig. 8 is a schematic diagram illustrating another effect of the Metrics information according to the embodiment of the present application;
fig. 9 is a schematic block diagram of a zookeeper-based monitoring device provided in an embodiment of the present application;
fig. 10 is a schematic block diagram of a computer device according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some, but not all, embodiments of the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
The flow diagrams depicted in the figures are merely illustrative and do not necessarily include all of the elements and operations/steps, nor do they necessarily have to be performed in the order depicted. For example, some operations/steps may be decomposed, combined or partially combined, so that the actual execution sequence may be changed according to the actual situation. In addition, although the division of the functional blocks is made in the device diagram, in some cases, it may be divided in blocks different from those in the device diagram.
The term "and/or" as used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.
Currently, most Of microservice monitoring schemes based on Zookeeper are divided into the following two types, one is that a client actively reports metric information to a server to realize monitoring, and in the scheme, due to possible network delay between the client and the server, a client transmission queue grows too fast to cause an Out Of Memory (OOM) phenomenon, or due to failed retry, the server can acquire repeated data. The other is that the server actively pulls the metric information of the server through statically configuring the instance information and the pulling interface in the Zookeeper micro-service, and the scheme can avoid repeated data, but cannot automatically find the target to be monitored, cannot automatically access the monitoring, and has high manual maintenance cost.
Therefore, the application provides a Zookeeper-based monitoring method, a monitoring device, computer equipment and a storage medium to solve the problems. Before describing the Zookeeper-based monitoring method provided by the present application in detail, the technical names related to the present application are explained.
The noun explains:
1. the metric information: providing measurement information of some monitoring indexes, which mainly comprise jvm, cpu, load, response time, network IO size and the like of the micro service;
2. zookeeper: a distributed application program coordination service is software for providing a consistency service for distributed applications, and the provided functions comprise: configuration maintenance, domain name service, distributed synchronization, group service and the like, particularly the client implementation of a complete registration center is provided by a Curator framework, the maintenance cost is low, and the method is suitable for small and medium-sized clusters;
3. pushing the model: the client actively pushes data to the server;
4. drawing a model: the server actively pulls the data of the client;
5. prometheus: an open source monitoring service is developed and realized by using Go language, and a time sequence data storage mechanism is built in the open source monitoring service;
6. NFS: network File System (Network File System), a Network abstraction over File systems, allows remote clients to access over a Network in a manner similar to local File systems. Allowing a common file system to be shared among multiple users and providing the advantage of data concentration to minimize the required storage space.
Some embodiments of the present application will be described in detail below with reference to the accompanying drawings. The embodiments described below and the features of the embodiments can be combined with each other without conflict.
Referring to fig. 1, fig. 1 is a schematic block diagram of a prior-art zookeeper-based microservice monitoring system according to an embodiment of the present application. As shown in fig. 1, the Zookeeper is responsible for managing multiple servers (services) and clients (clients), one of the servers may correspond to multiple different clients, and when monitoring the clients based on the Zookeeper, a pull model or a push model may be used to obtain metric information from the server, so as to implement monitoring.
Therefore, the existing micro-service monitoring system of Zookeeper is firstly improved, and the monitoring method provided by the embodiment of the application is introduced based on the improved micro-service monitoring system. Referring to fig. 2, fig. 2 is a schematic block diagram of a zookeeper-based microservice monitoring system according to an embodiment of the present application. As shown in fig. 2, the improved micro-service monitoring System includes a Zookeeper, a Prometheus, and a pre-developed listener, where the Prometheus and the listener realize sharing a configuration File through a Network File System (NFS).
The monitor is used for monitoring a state change event of the Zookeeper, wherein the state change event comprises an event corresponding to a new client registration microservice, and/or an event corresponding to a change of registration metadata of the client, and/or an event corresponding to an up-line and a down-line of the client or the server.
When the client registers the microservice, registration metadata is required to be sent to the Zookeeper, wherein the registration metadata comprises instance information, pull interface information, monitoring mark information and authentication information, and the instance information comprises IP information and port information. Of course, the registration metadata may also include other information, which is not limited herein.
The IP information refers to an interconnection protocol between networks, the port information refers to a connection port for communication between a client and a server, the pull interface information refers to an interface used by the client for pulling data, the monitoring flag information refers to 'whether a monitoring flag is accessed' and is used for indicating whether the registered client needs monitoring service, and the authentication information is used for determining whether the client is authorized.
And the Prometheus is used for pulling the metric information from the server side according to the configuration information in the configuration file of the monitoring program so as to realize monitoring.
The monitoring system further comprises an alert component, a monitoring component and a storage component (Grafana), wherein the alert component is used for analyzing and processing the pulled Metrics information to determine whether the alert information exists, the monitoring component is used for obtaining the alert information from the alert component to prompt a user, and the storage component is used for storing the pulled Metrics information for subsequent analysis and use.
It should be noted that the above-mentioned micro-service monitoring system based on Zookeeper may be deployed in a server to realize monitoring of a plurality of clients and corresponding servers, where a server may be deployed in a server including the micro-service monitoring system, or a server different from the micro-service monitoring system, and a client may be deployed in a terminal device.
The terminal device may include a fixed terminal such as a mobile phone, a tablet computer, a notebook computer, a palm top computer, a Personal Digital Assistant (PDA), and a Digital TV, a desktop computer, and the like. The servers may be, for example, individual servers or clusters of servers.
Referring to fig. 3, fig. 3 is a schematic flow chart of a Zookeeper-based monitoring method according to an embodiment of the present application. The monitoring method based on the Zookeeper can be applied to a server, automatic access monitoring of an automatically found target is achieved, manual maintenance cost is reduced, and user experience is improved.
As shown in fig. 3, the Zookeeper-based monitoring method includes steps S101 to S105.
S101, monitoring the Zookeeper through the monitor to acquire a state change event of the Zookeeper.
The monitor is a pre-developed program module, is deployed in the Zookeeper-based micro-service monitoring system, and is used for monitoring the state change event of the Zookeeper. The listener may specifically be a separately developed program module, or may certainly be a component redefined based on a monitoring component in the Zookeeper. Wherein, redefining the monitoring component in the Zookeeper can save development resources and further save labor cost.
Illustratively, a monitoring component of the Zookeeper may be selected, redefined to obtain a state change event of the Zookeeper, and configured to share a configuration file with promemeus through NFS.
Wherein the state change event comprises: a new client registers an event corresponding to the microservice, and/or an event corresponding to the change of the registered metadata of the client, and/or an event corresponding to the up-line and down-line of the client or the server; the state change event records service information including a service name of the service end, registration metadata of the client, and the like.
And the client sends registration metadata to the Zookeeper when registering the microservice, wherein the registration metadata comprises instance information, pull interface information, monitoring mark information and authentication information, and the instance information comprises IP information and port information. Of course, the state change event may also include other state change events, and the registration metadata may also include other information, which is not limited herein.
When the client registers the microservice, the registration metadata needs to be provided for the server, and the Zookeeper also monitors the client registration microservice and the registration metadata.
Specifically, the monitor acquires the state change event of the Zookeeper, which may be the state change event that the monitor actively pulls the Zookeeper, or the state change event that the server actively reports.
And S102, processing the state change event to obtain corresponding service information, wherein the service information comprises a service name of a service end and instance information of a client.
After the state change event of the Zookeeper is acquired, analyzing the state change event to obtain corresponding service information, wherein the service information comprises a service name of a service end and registration metadata of a client, the registration metadata at least comprises instance information of the client, and the instance information can comprise IP information and/or port information of the client and the like.
In some embodiments, the Zookeeper can be implemented via a Curator framework that can reduce the complexity of Zookeeper usage from retry mechanisms, connection status monitoring, Zookeeper client instance management, and support for various usage scenarios.
Wherein the Curator provides a pluggable Retry mechanism, which configures a Retry strategy for capturing recoverable exceptions, and several standard Retry strategies are provided inside (e.g., explicit Back off Retry: Retry for a specified number of retries, and the Time for pause between each Retry gradually increases, Retry N Times: Retry strategy for specifying the maximum number of retries, Retry One Time: Retry only once, Retry UntilElapsed: Retry Until reaching the specified Time). After the Curator is initialized, the Zookeeper connection is monitored all the time, and once the connection state is found to change, corresponding processing is carried out. The curater manages the connection of the Zookeeper client to the server cluster, and rebuilds the Zookeeper example if necessary, so as to ensure the reliable connection with the Zookeeper cluster. Curater implements most of the Zookeeper support using scenario support (even including scenarios not supported by Zookeeper itself), and these implementations follow the best practices of Zookeeper and take into account various extremes. Thereby the complexity of the microservice of the client and the server can be reduced.
S103, obtaining configuration information of the configuration file of the monitoring program, wherein the configuration information at least comprises example information of the monitored client.
The monitored instance information of the client comprises IP information, port information and the like, and the instance information can also be recorded in an instance list for storage, namely, the service name of the server and the instance information when the client is registered are correspondingly recorded in the instance list, and the instance list is stored in a configuration file.
Since the configuration file of the listener and the configuration file of Prometheus are shared through NFS (network file system), the configuration file of Prometheus also stores the instance information of the monitored client, or stores the instance list.
Illustratively, by using the NFS, not only can the configuration files of the listener and Prometheus be shared, but also the space of the locally stored configuration files can be saved, and the commonly used configuration files are stored on one NFS server and can be accessed through the network, so that the local server or the terminal can reduce the use of the storage space of the local server or the terminal.
In some embodiments, information such as the instance list can be converted into information in the yaml and json formats for storage, because the configuration file of the Prometheus is written, read and updated according to the yaml and json formats, so that the Prometheus is read and used conveniently, and rapid monitoring is achieved.
S104, determining whether the configuration information in the configuration file needs to be updated according to the instance information in the service information and the instance information in the configuration information.
Specifically, the example information of the service information may be compared with the example information in the configuration information of the monitor to determine whether or not the Prometheus has monitored the client and the server corresponding to the client; when determining that the corresponding client exists, determining that the configuration information in the configuration file does not need to be updated; and when determining that no corresponding client exists, determining that the configuration information in the configuration file needs to be updated.
For example, it is determined whether instance information in the configuration information of the listener is in the same IP according to the IP information, and if it is determined that the instance information in the configuration information of the listener is in the same IP, it may be determined that the client and the server corresponding to the client have been monitored by Prometheus; and then determining whether the corresponding client exists in the instance list in the configuration file of the monitoring program according to the monitoring flag, and if determining that the corresponding client exists, determining that the client and the server corresponding to the client are monitored by Prometheus.
In some embodiments, in order to quickly determine whether the configuration information needs to be updated, as shown in fig. 4, that is, the step of determining whether the configuration information needs to be updated specifically includes the following steps:
s201, determining whether the configuration information has the same instance information as the instance information in the service information;
s202, determining that the configuration information in the configuration file needs to be updated;
s203, determining that the configuration information in the configuration file does not need to be updated.
Determining whether instance information which is the same as the instance information in the service information exists in the configuration information or not through IP information and/or port information, and if the instance information which is the same as the instance information in the service information does not exist in the configuration information, determining that the configuration information in the configuration file needs to be updated; and if the configuration information has the same instance information as the instance information in the service information, determining that the configuration information in the configuration file does not need to be updated.
It should be noted that the service information may include a case where a plurality of clients correspond to one server, and therefore when it is determined whether there is instance information that is the same as the instance information in the service information in the configuration information, if there is instance information that is the same as the instance information of all the clients in the service information in the configuration information, it is determined that it is not necessary to update the configuration information in the configuration file, and if there is at least one instance information that is different from the instance information of the client in the service information in the configuration information, it is determined that it is necessary to update the configuration information in the configuration file.
In some embodiments, whether the configuration information needs to be updated may be determined by an instance list in a listener configuration file, where the configuration information of the configuration file includes the instance list, and the instance list is used to record instance information of a client that has been monitored. Specifically, as shown in fig. 5, determining whether the configuration information in the configuration file needs to be updated according to the instance information in the service information and the instance information in the configuration information includes: namely, the step of determining whether to update the configuration information specifically includes the following steps:
s301, determining whether an instance list in the configuration information has instance information in the service information;
s302, determining that the configuration information in the configuration file needs to be updated;
s303, determining that the configuration information in the configuration file does not need to be updated.
Specifically, it is determined whether an instance list in the configuration information has instance information in the service information, and if the instance list in the configuration information does not have the instance information in the service information, it is determined that the configuration information in the configuration file needs to be updated; and if the instance list in the configuration information has the instance information in the service information, determining that the configuration information in the configuration file does not need to be updated.
And S105, if the updating is determined to be needed, updating the configuration information according to the service information, so that the Prometheus pulls the Metrics information from the service end according to the updated configuration information to complete monitoring.
Specifically, the configuration information is updated according to the service information, specifically, the client in the instance list may be updated according to the registration metadata of the client, and the server corresponding to the client is updated according to the service name of the server. Of course, the update of the pull interface (metric _ path) and the authentication information (basic _ auth) may be updated in addition to the update instance list (targets). So that Prometheus reads the updated configuration information from the configuration file of Prometheus and pulls the Metrics information from the server side according to the updated configuration information so as to complete monitoring.
Specifically, Prometheus is mainly divided into three parts, namely a pull module (Retrieval), a Storage module (Storage) and a language module (PromQL). The Retrieval is responsible for capturing Metrics information on the exposed target page at regular time, the Storage is responsible for writing the Metrics information into a disk for Storage, and the PromQL is a query language module provided by Prometheus, so that time sequence data can be conveniently searched and aggregated in real time.
Exemplarily, as shown in fig. 2, Prometheus pulls Metrics information from the server side in Pull. Prometheus locally stores all captured data, cleans and sorts the data by certain rules, and stores the obtained results in a new Time Series (TSDB) for subsequent analysis.
In some embodiments, to avoid wasting resources, the microservice monitoring system further comprises a preset event container configured to execute events in the event container by a scheduling thread at preset time intervals.
Correspondingly, as shown in fig. 6, namely, updating the configuration information specifically includes the following steps:
s401, updating the event corresponding to the configuration information according to the service information, and storing the event in the event container; and
s402, when the preset time is set, the scheduling thread executes the event in the event container to update the configuration information.
Events corresponding to updating the configuration information according to the service information, for example, a plurality of events corresponding to updating the configuration information, may be stored in the event container, and after the event container reaches a predetermined interval preset time, for example, an interval of 30s, the event container scheduling thread is started to execute the events in the event container, and a plurality of events corresponding to updating the configuration information are executed at the same time, so as to update the configuration information. Therefore, the configuration file can be prevented from being updated repeatedly, and resource waste is avoided.
In some embodiments, as shown in fig. 2, an Http interface (Http Server) of Prometheus may also be defined to connect an alarm component (Alerts Manager), a monitoring component (monitoring center), and a storage component (Grafana).
The alarm component is used for analyzing and processing the pulled Metrics information to determine whether the alarm information exists, the monitoring component is used for acquiring the alarm information from the alarm component to prompt a user, and the storage component is used for storing the pulled Metrics information for subsequent analysis and use.
For example, the manner of prompting the user may specifically be to send the warning information to a corresponding application program (APP) or to notify the user by Email, short message, or chat tool such as WeChat, qq, or the like.
In some embodiments, Prometheus periodically pulls Metrics information from a configured Service (Service) or retrieves Metrics information from the TSDB. The TSDB stores the collected Metrics information locally and runs well defined Alert rules, records new time sequences or pushes alerts to Alert managers. And the Alert manager processes the received alarm according to the configuration file and sends an alarm.
In some embodiments, Metrics information may also be presented in a list or by a trend graph for viewing by a user based on the Prometheus query language (PromQL). For example, as shown in fig. 7, the trend graph may show data on the same interface or show multiple types of data simultaneously, such as the number of requests and the average response time simultaneously. Illustratively, as shown in fig. 8, different data may be presented by dividing into a plurality of small interfaces.
Referring to fig. 9, fig. 9 is a schematic block diagram of a Zookeeper-based monitoring device according to an embodiment of the present application, where the Zookeeper-based monitoring device may be configured in a server for executing the foregoing monitoring method.
As shown in fig. 9, the Zookeeper-based monitoring apparatus 500 includes: an event monitoring module 501, an information processing module 502, an information obtaining module 503, an update determining module 504 and an update monitoring module 505.
An event monitoring module 501, configured to monitor the Zookeeper through the monitor to obtain a state change event of the Zookeeper;
an information processing module 502, configured to process the state change event to obtain corresponding service information, where the service information includes a service name of a service end and instance information of a client;
an information obtaining module 503, configured to obtain configuration information of a configuration file of the monitor, where the configuration information at least includes instance information of a monitored client;
an update determining module 504, configured to determine whether the configuration information in the configuration file needs to be updated according to instance information in the service information and instance information in the configuration information;
and an update monitoring module 505, configured to update the configuration information according to the service information if it is determined that the update is required, so that the Prometheus pulls Metrics information from the service end according to the updated configuration information to complete monitoring.
In some embodiments, the monitoring apparatus 500 may further include an information presentation module configured to present the Metrics information in a list manner or present the Metrics information through a trend graph based on the PromQL.
It should be noted that, as will be clear to those skilled in the art, for convenience and brevity of description, the specific working processes of the apparatus, the modules and the units described above may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
The methods, apparatus, and devices of the present application are operational with numerous general purpose or special purpose computing system environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet-type devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The above-described methods and apparatuses may be implemented, for example, in the form of a computer program that can be run on a computer device as shown in fig. 10.
Referring to fig. 10, fig. 10 is a schematic diagram of a computer device according to an embodiment of the present disclosure. The computer device may be a server or a terminal.
As shown in fig. 10, the computer device includes a processor, a memory, and a network interface connected by a system bus, wherein the memory may include a nonvolatile storage medium and an internal memory.
The non-volatile storage medium may store an operating system and a computer program. The computer program includes program instructions that, when executed, cause a processor to perform any of the Zookeeper-based monitoring methods.
The processor is used for providing calculation and control capability and supporting the operation of the whole computer equipment.
The internal memory provides an environment for the execution of a computer program on a non-volatile storage medium, which when executed by the processor, causes the processor to perform any of the Zookeeper-based monitoring methods.
The network interface is used for network communication, such as sending assigned tasks and the like. Those skilled in the art will appreciate that the configuration of the computer apparatus is merely a block diagram of a portion of the configuration associated with aspects of the present application and is not intended to limit the computer apparatus to which aspects of the present application may be applied, and that a particular computer apparatus may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.
It should be understood that the Processor may be a Central Processing Unit (CPU), and the Processor may be other general purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components, etc. Wherein a general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
Wherein, in some embodiments, the processor is configured to execute a computer program stored in the memory to implement the steps of:
monitoring the Zookeeper through the monitor to acquire a state change event of the Zookeeper; processing the state change event to obtain corresponding service information, wherein the service information comprises a service name of a service end and instance information of a client; acquiring configuration information of a configuration file of the monitor, wherein the configuration information at least comprises example information of a monitored client; determining whether the configuration information in the configuration file needs to be updated according to the instance information in the service information and the instance information in the configuration information; and if the fact that updating is needed is determined, updating the configuration information according to the service information, so that the Prometheus can pull the Metrics information from the service end according to the updated configuration information so as to complete monitoring.
In some embodiments, the state change event comprises: a new client registers an event corresponding to the microservice, and/or an event corresponding to the change of the registered metadata of the client, and/or an event corresponding to the up-line and down-line of the client or the server; and the client sends registration metadata to the Zookeeper when registering the microservice, wherein the registration metadata comprises instance information, pull interface information, monitoring mark information and authentication information, and the instance information comprises IP information and port information.
In some embodiments, when determining whether the configuration information in the configuration file needs to be updated according to the instance information in the service information and the instance information in the configuration information, the processor is specifically configured to:
determining whether the configuration information has the same instance information as the instance information in the service information; if the configuration information contains the instance information which is the same as the instance information in the service information, determining that the configuration information in the configuration file does not need to be updated; and if the configuration information does not contain the instance information which is the same as the instance information in the service information, determining that the configuration information in the configuration file needs to be updated.
In some embodiments, the configuration information includes an instance list for recording instance information of clients that have been monitored.
In some embodiments, when determining whether the configuration information in the configuration file needs to be updated according to the instance information in the service information and the instance information in the configuration information, the processor is specifically configured to:
determining whether an instance list in the configuration information has instance information in the service information; if the instance list in the configuration information has the instance information in the service information, determining that the configuration information in the configuration file does not need to be updated; and if the example list in the configuration information does not have the example information in the service information, determining that the configuration information in the configuration file needs to be updated.
In some embodiments, when the processor updates the configuration information according to the service information, specifically, the processor implements:
updating the instance list according to the instance information of the client; and updating the client in the example list according to the registration metadata of the client, and updating the server corresponding to the client according to the service name of the server.
In some embodiments, the microservice monitoring system further comprises a preset event container configured to execute events in the event container by a scheduling thread at preset time intervals.
In some embodiments, when the processor updates the configuration information according to the service information, specifically, the processor implements:
events corresponding to the configuration information updated according to the service information are stored in the event container; and when the preset time is set, scheduling the thread to execute the event in the event container to update the configuration information.
In some embodiments, the processor is further configured to:
and displaying the Metrics information in a list mode or displaying the Metrics information through a trend graph based on the PromQL.
The embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, where the computer program includes program instructions, and the program instructions, when executed, implement any Zookeeper-based monitoring method provided in the embodiment of the present application.
The computer-readable storage medium may be an internal storage unit of the computer device described in the foregoing embodiment, for example, a hard disk or a memory of the computer device. The computer readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), and the like provided on the computer device.
Further, the computer-readable storage medium may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function, and the like; the storage data area may store data created according to the use of the blockchain node, and the like.
The invention relates to a novel application mode of computer technologies such as storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like of a block chain language model. A block chain (Blockchain), which is essentially a decentralized database, is a series of data blocks associated by using a cryptographic method, and each data block contains information of a batch of network transactions, so as to verify the validity (anti-counterfeiting) of the information and generate a next block. The blockchain may include a blockchain underlying platform, a platform product service layer, an application service layer, and the like.
While the invention has been described with reference to specific embodiments, the scope of the invention is not limited thereto, and those skilled in the art can easily conceive various equivalent modifications or substitutions within the technical scope of the invention. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (10)

1. A monitoring method based on Zookeeper is characterized in that the monitoring method is applied to a micro-service monitoring system comprising the Zookeeper, Prometheus and a monitoring program, wherein the Prometheus and the monitoring program realize sharing of configuration files through a network file system; the method comprises the following steps:
monitoring the Zookeeper through the monitor to acquire a state change event of the Zookeeper;
processing the state change event to obtain corresponding service information, wherein the service information comprises a service name of a service end and instance information of a client;
acquiring configuration information of a configuration file of the monitor, wherein the configuration information at least comprises example information of a monitored client;
determining whether the configuration information in the configuration file needs to be updated according to the instance information in the service information and the instance information in the configuration information;
and if the fact that updating is needed is determined, updating the configuration information according to the service information, so that the Prometheus can pull the Metrics information from the service end according to the updated configuration information so as to complete monitoring.
2. The method of claim 1, wherein the state change event comprises:
a new client registers an event corresponding to the microservice, and/or an event corresponding to the change of the registered metadata of the client, and/or an event corresponding to the up-line and down-line of the client or the server;
and the client sends registration metadata to the Zookeeper when registering the microservice, wherein the registration metadata comprises instance information, pull interface information, monitoring mark information and authentication information, and the instance information comprises IP information and port information.
3. The method according to claim 1, wherein the determining whether the configuration information in the configuration file needs to be updated according to the instance information in the service information and the instance information in the configuration information comprises:
determining whether the configuration information has the same instance information as the instance information in the service information;
if the configuration information contains the instance information which is the same as the instance information in the service information, determining that the configuration information in the configuration file does not need to be updated;
and if the configuration information does not contain the instance information which is the same as the instance information in the service information, determining that the configuration information in the configuration file needs to be updated.
4. The method of claim 1, wherein the configuration information comprises an instance list for recording instance information of clients that have been monitored;
the determining whether the configuration information in the configuration file needs to be updated according to the instance information in the service information and the instance information in the configuration information includes:
determining whether an instance list in the configuration information has instance information in the service information;
if the instance list in the configuration information has the instance information in the service information, determining that the configuration information in the configuration file does not need to be updated;
and if the example list in the configuration information does not have the example information in the service information, determining that the configuration information in the configuration file needs to be updated.
5. The method of claim 4, wherein the updating the configuration information according to the service information comprises:
and updating the client in the example list according to the registration metadata of the client, and updating the server corresponding to the client according to the service name of the server.
6. The method of claim 1, wherein the microservice monitoring system further comprises a preset event container configured to execute events in the event container by a scheduling thread at preset time intervals;
the updating the configuration information according to the service information includes:
events corresponding to the configuration information updated according to the service information are stored in the event container; and
and when the preset time is set, the scheduling thread executes the event in the event container to update the configuration information.
7. The method according to claim 1, characterized in that it comprises:
and displaying the Metrics information in a list mode or displaying the Metrics information through a trend graph based on Prometheus query language.
8. A Zookeeper-based monitoring device, comprising:
the event monitoring module is used for monitoring the Zookeeper through the monitor program so as to obtain a state change event of the Zookeeper;
the information processing module is used for processing the state change event to obtain corresponding service information, and the service information comprises a service name of a service end and instance information of a client;
the information acquisition module is used for acquiring configuration information of a configuration file of the monitoring program, wherein the configuration information at least comprises example information of a monitored client;
an update determining module, configured to determine whether configuration information in the configuration file needs to be updated according to instance information in the service information and instance information in the configuration information;
and the updating monitoring module is used for updating the configuration information according to the service information if the updating is determined to be needed, so that the Prometheus can pull the Metrics information from the service end according to the updated configuration information to complete monitoring.
9. A computer device, wherein the computer device comprises a memory and a processor;
the memory for storing a computer program;
the processor is used for executing the computer program and realizing the following when the computer program is executed:
a method of monitoring as claimed in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program which, when executed by a processor, causes the processor to implement the monitoring method according to any one of claims 1 to 7.
CN202011193145.XA 2020-10-30 2020-10-30 Zookeeper-based monitoring method, monitoring device, equipment and storage medium Pending CN112328448A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011193145.XA CN112328448A (en) 2020-10-30 2020-10-30 Zookeeper-based monitoring method, monitoring device, equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011193145.XA CN112328448A (en) 2020-10-30 2020-10-30 Zookeeper-based monitoring method, monitoring device, equipment and storage medium

Publications (1)

Publication Number Publication Date
CN112328448A true CN112328448A (en) 2021-02-05

Family

ID=74297580

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011193145.XA Pending CN112328448A (en) 2020-10-30 2020-10-30 Zookeeper-based monitoring method, monitoring device, equipment and storage medium

Country Status (1)

Country Link
CN (1) CN112328448A (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112835650A (en) * 2021-03-18 2021-05-25 南威软件股份有限公司 Method and system for realizing system parameter unified configuration real-time effect
CN112862099A (en) * 2021-03-12 2021-05-28 云知声智能科技股份有限公司 Enterprise-level neural network model processing method and device, electronic equipment and storage medium
CN113051131A (en) * 2021-03-23 2021-06-29 北京沃东天骏信息技术有限公司 Acquisition terminal, management control platform, and Prometheus service adjusting method and system
CN114553740A (en) * 2022-03-11 2022-05-27 以萨技术股份有限公司 Method, system, readable storage medium and device for cross-network monitoring
CN115080337A (en) * 2021-03-16 2022-09-20 网联清算有限公司 Data monitoring method, device, system, server and readable storage medium

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102761432A (en) * 2011-04-29 2012-10-31 腾讯科技(深圳)有限公司 CGI (Common Gateway Interface) monitoring method, device and system thereof
CN107888444A (en) * 2017-09-29 2018-04-06 深圳市牛鼎丰科技有限公司 Service monitoring method, service monitoring device, computer equipment and storage medium
CN110688146A (en) * 2019-09-23 2020-01-14 凡普数字技术有限公司 Method, device and storage medium for dynamically configuring monitoring system
CN111147596A (en) * 2019-12-30 2020-05-12 中国移动通信集团江苏有限公司 Prometous cluster deployment method, device, equipment and medium
CN111475372A (en) * 2020-03-10 2020-07-31 中国平安人寿保险股份有限公司 Method, device, equipment and storage medium for monitoring service instance of microservice
CN111510351A (en) * 2020-04-10 2020-08-07 星辰天合(北京)数据科技有限公司 Anomaly detection method and device based on Promissuris monitoring system
CN111666189A (en) * 2020-06-12 2020-09-15 中信银行股份有限公司 Method and system for declaratively visually configuring Prometheus monitoring alarm

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102761432A (en) * 2011-04-29 2012-10-31 腾讯科技(深圳)有限公司 CGI (Common Gateway Interface) monitoring method, device and system thereof
CN107888444A (en) * 2017-09-29 2018-04-06 深圳市牛鼎丰科技有限公司 Service monitoring method, service monitoring device, computer equipment and storage medium
CN110688146A (en) * 2019-09-23 2020-01-14 凡普数字技术有限公司 Method, device and storage medium for dynamically configuring monitoring system
CN111147596A (en) * 2019-12-30 2020-05-12 中国移动通信集团江苏有限公司 Prometous cluster deployment method, device, equipment and medium
CN111475372A (en) * 2020-03-10 2020-07-31 中国平安人寿保险股份有限公司 Method, device, equipment and storage medium for monitoring service instance of microservice
CN111510351A (en) * 2020-04-10 2020-08-07 星辰天合(北京)数据科技有限公司 Anomaly detection method and device based on Promissuris monitoring system
CN111666189A (en) * 2020-06-12 2020-09-15 中信银行股份有限公司 Method and system for declaratively visually configuring Prometheus monitoring alarm

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112862099A (en) * 2021-03-12 2021-05-28 云知声智能科技股份有限公司 Enterprise-level neural network model processing method and device, electronic equipment and storage medium
CN112862099B (en) * 2021-03-12 2023-11-07 云知声智能科技股份有限公司 Enterprise-level neural network model processing method and device, electronic equipment and storage medium
CN115080337A (en) * 2021-03-16 2022-09-20 网联清算有限公司 Data monitoring method, device, system, server and readable storage medium
CN112835650A (en) * 2021-03-18 2021-05-25 南威软件股份有限公司 Method and system for realizing system parameter unified configuration real-time effect
CN113051131A (en) * 2021-03-23 2021-06-29 北京沃东天骏信息技术有限公司 Acquisition terminal, management control platform, and Prometheus service adjusting method and system
CN114553740A (en) * 2022-03-11 2022-05-27 以萨技术股份有限公司 Method, system, readable storage medium and device for cross-network monitoring
CN114553740B (en) * 2022-03-11 2023-11-10 以萨技术股份有限公司 Method, system, readable storage medium and device for cross-network monitoring

Similar Documents

Publication Publication Date Title
CN112328448A (en) Zookeeper-based monitoring method, monitoring device, equipment and storage medium
CN108566290B (en) Service configuration management method, system, storage medium and server
US9971823B2 (en) Dynamic replica failure detection and healing
US11132356B2 (en) Optimizing data entries in a log
WO2020258290A1 (en) Log data collection method, log data collection apparatus, storage medium and log data collection system
CN113010565B (en) Server real-time data processing method and system based on server cluster
US20140280912A1 (en) System and method for determination and visualization of cloud processes and network relationships
CN112905323B (en) Data processing method, device, electronic equipment and storage medium
CN110955578A (en) Log collection method and device based on host machine, computer equipment and storage medium
CN113377626B (en) Visual unified alarm method, device, equipment and medium based on service tree
CN111198859A (en) Data processing method and device, electronic equipment and computer readable storage medium
US10331484B2 (en) Distributed data platform resource allocator
WO2021167659A1 (en) Systems and methods of monitoring and controlling remote assets
CN112685499A (en) Method, device and equipment for synchronizing process data of work service flow
CN111338834B (en) Data storage method and device
US11334535B2 (en) Storage and analysis of data records associated with managed devices in a device management platform
US10122602B1 (en) Distributed system infrastructure testing
US20220044144A1 (en) Real time model cascades and derived feature hierarchy
CN113422808A (en) Internet of things platform HTTP information pushing method, system, device and medium
CN112506490A (en) Interface generation method and device, electronic equipment and storage medium
CN109324892B (en) Distributed management method, distributed management system and device
CN113965538B (en) Equipment state message processing method, device and storage medium
US10353792B2 (en) Data layering in a network management system
CN111274104A (en) Data processing method and device, electronic equipment and computer readable storage medium
CN110611576B (en) Data quality monitoring method, device, equipment and storage medium

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