Method and device for generating alarm

Abstract

The embodiment of the invention provides a method and device for generating an alarm, and the method comprises the steps: obtaining the event information of at least one Kubernetes cluster through an event collector, and writing the event information meeting a set screening condition into a message queue; monitoring alarm information of a monitoring alarm system is obtained through an alarm callback service, the monitoring alarm information is converted into a data structure of event information in a Kubernetes cluster, and the data structure is written into a message queue; and consuming each message in the message queue through an event consumer, generating a corresponding target alarm message according to a configured alarm rule, and sending the target alarm message according to a configured receiving client and a receiving mode. Unified alarm of event information and monitoring alarm information of different data formats is realized, used resources are reduced, the resource utilization rate is improved, and the efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the field of record notification, and in particular to a method and device for generating an alarm. Background Art

[0002] Each Kubernetes cluster generates events, which need to be notified to the corresponding users. Alarms generated by monitoring the Kubernetes cluster according to the Prometheus configuration also need to be notified to the corresponding users; for alarms configured using Prometheus that are based on monitoring data, you need to use the Prometheus alarm management page to configure alarms by writing YAML.

[0003] In the process of implementing the present invention, the applicant discovered that there are at least the following problems in the prior art:

[0004] The data formats of events and alarms are different. It is impossible to simply merge the two to form a notification in the same data format, which wastes resources and is inefficient. Therefore, a method is needed to merge events and alarms to form a notification in the same alarm format. Summary of the invention

[0005] The embodiments of the present invention provide a method and device for generating an alarm, which can solve the technical problem in the prior art that "the data formats of events and alarms are different, and it is impossible to simply merge the two to form notifications in the same data form, which wastes resources and is inefficient."

[0006] To achieve the above object, on the one hand, an embodiment of the present invention provides a method for generating an alarm, comprising:

[0007] Obtaining event information of at least one Kubernetes cluster through an event collector, and writing event information that meets set screening conditions into a message queue; wherein the event information is marked with an event source;

[0008] The monitoring alarm information of the monitoring alarm system is obtained through the alarm callback service, and the monitoring alarm information is converted into the data structure of event information in the Kubernetes cluster, and written into the message queue; wherein the monitoring alarm information is obtained by triggering the alarm callback service when the monitoring alarm system generates an alarm according to the configured alarm rule, and the event source marked by the monitoring alarm information after the data structure conversion is the monitoring alarm system;

[0009] Each message in the message queue is consumed by an event consumer, a corresponding target alarm message is generated according to the configured alarm rules, and the target alarm message is sent according to the configured receiving client and receiving method; the message queue includes messages corresponding to event information from at least one Kubernetes cluster and messages corresponding to monitoring alarm information from the monitoring alarm system.

[0010] On the other hand, an embodiment of the present invention provides a device for generating an alarm, including:

[0011] An event collector, used to obtain event information of at least one Kubernetes cluster and write event information that meets set screening conditions into a message queue; wherein the event information is marked with an event source;

[0012] An alarm callback service is used to obtain monitoring alarm information from the monitoring alarm system, convert the monitoring alarm information into a data structure of event information in the Kubernetes cluster, and write it into a message queue; wherein the monitoring alarm information is obtained by triggering the alarm callback service when the monitoring alarm system generates an alarm according to the configured alarm rules, and the event source marked by the monitoring alarm information after the data structure conversion is the monitoring alarm system;

[0013] An event consumer is used to consume each message in the message queue, generate a corresponding target alarm message according to the configured alarm rules, and send the target alarm message according to the configured receiving client and receiving method; the message queue includes messages corresponding to event information from the at least one Kubernetes cluster and messages corresponding to monitoring alarm information from the monitoring alarm system.

[0014] The above technical solution has the following beneficial effects: the monitoring alarm information is converted into the data structure of the event information in the Kubernetes cluster, a unified data format is prepared for the unified sending of alarms, both the event information and the monitoring alarm information are written into the message queue, each message in the message queue is consumed by the event consumer, a corresponding target alarm message is generated according to the configured alarm rules, and the target alarm message is sent according to the configured receiving client and receiving method, thereby realizing unified alarms for event information and monitoring alarm information in different data formats, reducing the resources used, improving resource utilization, and improving efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0016] Figure 1 is a flow chart of a method for generating an alarm according to an embodiment of the present invention;

[0017] Figure 2 is a structural diagram of an apparatus for generating an alarm according to an embodiment of the present invention;

[0018] Figure 3 Detailed description of the invention is given in detail. DETAILED DESCRIPTION

[0019] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0020] like Figure 1 As shown, in combination with an embodiment of the present invention, a method for generating an alarm is provided, comprising:

[0021] S101: Acquire event information of at least one Kubernetes cluster through an event collector, and write event information that meets set screening conditions into a message queue; wherein the event information is marked with an event source;

[0022] S102: Obtain monitoring alarm information of the monitoring alarm system through the alarm callback service, convert the monitoring alarm information into a data structure of event information in the Kubernetes cluster, and write it into a message queue; wherein the monitoring alarm information is obtained by triggering the alarm callback service when the monitoring alarm system generates an alarm according to the configured alarm rule, and the event source marked by the monitoring alarm information after the data structure conversion is the monitoring alarm system;

[0023] S103: Consume each message in the message queue through an event consumer, generate a corresponding target alarm message according to the configured alarm rule, and send the target alarm message according to the configured receiving client and receiving method; the message queue includes messages corresponding to the event information from the at least one Kubernetes cluster, and messages corresponding to the monitoring alarm information from the monitoring alarm system.

[0024] The monitoring alarm information is converted into the data structure of the event information in the Kubernetes cluster, and a unified data format is prepared for the unified sending of the alarm information. The event information and the monitoring alarm information are written into the message queue, and each message in the message queue is consumed by the event consumer. The corresponding target alarm message is generated according to the configured alarm rule, and the target alarm message is sent according to the configured receiving client and receiving method, thereby realizing unified alarm for event information and monitoring alarm information in different data formats, reducing the resources used, improving resource utilization, and improving efficiency.

[0025] Preferably, the method for generating an alarm further includes:

[0026] S104: Generate a first rule for the monitoring alarm information through the application program interface of the monitoring alarm system, and write the first rule into a database, wherein the first rule includes an alarm rule, an alarm level, a receiving client corresponding to the monitoring alarm information, and a receiving method; the alarm rule is the basis for generating the monitoring alarm information, and when sending the monitoring alarm information, it is necessary to obtain the alarm level, the receiving client corresponding to the monitoring alarm information, and the receiving method.

[0027] S105: Generate a second rule for the event information through the application program interface of the Kubernetes cluster, and write the second rule into the database, wherein the second rule includes: a receiving client and a receiving method corresponding to the event information, and when sending the event information, it is necessary to obtain the receiving client and the receiving method corresponding to the event information.

[0028] Preferably, in S101, obtaining event information of at least one Kubernetes cluster through an event collector includes:

[0029] S101-1: Start the same number of coroutines as the Kubernetes clusters through the event collector, call the event output interface on the corresponding Kubernetes cluster through each coroutine, monitor and collect the event information output by the event output interface. The coroutine is a lightweight concurrent execution unit that can be switched in user mode (i.e., application level) without the intervention of the operating system kernel. Set a label for the event information, and the label includes at least: the cluster name and the source of the event representing the Kubernetes cluster.

[0030] Preferably, in S102, obtaining monitoring alarm information of the monitoring alarm system through the alarm callback service includes:

[0031] S102-1: receiving an HTTP request from a monitoring alarm system through an alarm callback service, where the monitoring alarm system is used to monitor the at least one Kubernetes cluster, and the HTTP request carries the monitoring alarm information as HTTPBody;

[0032] S102-2: Parse the HTTP Body in the HTTP request to obtain the monitoring alarm information, and set a tag for the monitoring alarm information. The tag at least includes: a cluster name and an event source representing an event from the monitoring alarm system, which is required when the alarm sender sends the alarm information.

[0033] Preferably, in S101, writing event information that meets the set screening conditions into the message queue includes:

[0034] S101-2: for each event information to be filtered, query whether there is an identical event ID in the periodic cache, wherein the periodic cache stores event information in a dictionary format, and the event information in the dictionary format is a key-value pair consisting of an event ID as a key and a resource acquisition process information set of the event information as a value;

[0035] S101-3: If the same event ID is not found in the periodic cache, write the event information into a message queue, and form a new key-value pair with the event ID corresponding to the event information as the key and the resource acquisition process information set of the event information as the value, and save the new key-value pair in the periodic cache; the key-value pairs in the periodic cache are marked with a storage period, and the storage period is used to constrain the maximum storage duration of the key-value pairs;

[0036] S101 - 4 : When the same event ID is found in the periodic cache, the event information is abandoned to achieve convergence of event information with the same time ID.

[0037] Since the event information with the same Kubernetes event ID only differs in time and frequency, a periodic cache mechanism is used to converge Kubernetes event information. First, apply for a fixed-size memory space to store the event ID. The event ID is stored in the data format of a dictionary. The dictionary data format has a characteristic that the key value of the dictionary cannot be repeated. When the event ID is stored, the storage period of this event ID is written, such as 2 minutes. After 2 minutes, this event ID will be deleted from the memory. When there is new event information, it is necessary to query whether there is the same event ID in the periodic cache. When the same event ID is found in the periodic cache, the event information is abandoned to achieve convergence of event information with the same event ID.

[0038] Preferably, the method for generating an alarm further includes:

[0039] S101-5: After receiving the event information output by the event output interface on each Kubernetes cluster, filter the collected event information according to the preset filtering rules, filter out the event information that meets the filtering rules, and retain the event information that does not meet the filtering rules as the event information to be filtered, so as to filter out the event information that does not need to be sent; the filtering rules include at least one or any combination of the following: filtering out events in a specified namespace, filtering out events of a set type, and filtering out events containing set information. This step is performed before S101-2.

[0040] like Figure 2 As shown, in combination with an embodiment of the present invention, a device for generating an alarm is provided, comprising:

[0041] An event collector 21 is used to obtain event information of at least one Kubernetes cluster and write event information that meets set screening conditions into a message queue; wherein the event information is marked with an event source;

[0042] The alarm callback service 22 is used to obtain the monitoring alarm information of the monitoring alarm system, convert the monitoring alarm information into the data structure of event information in the Kubernetes cluster, and write it into the message queue; wherein the monitoring alarm information is obtained by triggering the alarm callback service when the monitoring alarm system generates an alarm according to the configured alarm rule, and the event source marked by the monitoring alarm information after the data structure conversion is the monitoring alarm system;

[0043] The event consumer 23 is used to consume each message in the message queue, generate a corresponding target alarm message according to the configured alarm rules, and send the target alarm message according to the configured receiving client and receiving method; the message queue includes messages corresponding to event information from at least one Kubernetes cluster and messages corresponding to monitoring alarm information from the monitoring alarm system.

[0044] The monitoring alarm information is converted into the data structure of the event information in the Kubernetes cluster, and a unified data format is prepared for the unified sending of the alarm information. The event information and the monitoring alarm information are written into the message queue, and each message in the message queue is consumed by the event consumer. The corresponding target alarm message is generated according to the configured alarm rule, and the target alarm message is sent according to the configured receiving client and receiving method, thereby realizing unified alarm for event information and monitoring alarm information in different data formats, reducing the resources used, improving resource utilization, and improving efficiency.

[0045] Preferably, the device for generating an alarm further comprises:

[0046] The application program interface of the monitoring alarm system is used to generate a first rule for monitoring alarm information and write the first rule into a database. The first rule includes an alarm rule, an alarm level, a receiving client corresponding to the monitoring alarm information, and a receiving method. The alarm rule is the basis for generating monitoring alarm information. When sending monitoring alarm information, it is necessary to obtain the alarm level, the receiving client corresponding to the monitoring alarm information, and the receiving method.

[0047] The application program interface of the Kubernetes cluster is used to generate a second rule for event information and write the second rule into a database. The second rule includes: a receiving client and a receiving method corresponding to the event information. When sending event information, it is necessary to obtain the receiving client and the receiving method corresponding to the event information.

[0048] Preferably, the event collector 21 is specifically used for:

[0049] Start the same number of coroutines as the Kubernetes clusters, call the event output interface on the corresponding Kubernetes cluster through each coroutine, listen to and collect the event information output by the event output interface, the coroutine is a lightweight concurrent execution unit, which can be switched in user mode (i.e., application level) without the intervention of the operating system kernel, set a label for the event information, and the label includes at least: the cluster name and the source of the event from the Kubernetes cluster.

[0050] Preferably, the alarm callback service 22 is specifically used for:

[0051] Receiving an HTTP request from a monitoring and alarm system, where the monitoring and alarm system is used to monitor the at least one Kubernetes cluster, and the HTTP request carries the monitoring and alarm information as an HTTP Body;

[0052] The monitoring alarm information is obtained by parsing the HTTP Body in the HTTP request, and a label is set for the monitoring alarm information, wherein the label at least includes: a cluster name and an event source representing an event source from the monitoring alarm system, which is required when the alarm sender sends the alarm information.

[0053] Preferably, the event collector 21 is further used for:

[0054] For each event information to be filtered, query whether there is an identical event ID in the periodic cache, wherein the periodic cache stores event information in a dictionary format, and the event information in the dictionary format is a key-value pair consisting of an event ID as a key and a resource acquisition process information set of the event information as a value;

[0055] If the same event ID is not found in the periodic cache, the event information is written into the message queue, and a new key-value pair is formed with the event ID corresponding to the event information as the key and the resource acquisition process information set of the event information as the value, and the new key-value pair is stored in the periodic cache; the key-value pairs in the periodic cache are marked with a storage period, and the storage period is used to constrain the maximum storage duration of the key-value pairs;

[0056] When the same event ID is found in the periodic cache, the event information is abandoned to achieve convergence of event information with the same time ID.

[0057] Since the event information with the same Kubernetes event ID only differs in time and frequency, a periodic cache mechanism is used to converge Kubernetes event information. First, apply for a fixed-size memory space to store the event ID. The event ID is stored in the data format of a dictionary. The dictionary data format has a characteristic that the key value of the dictionary cannot be repeated. When the event ID is stored, the storage period of this event ID is written, such as 2 minutes. After 2 minutes, this event ID will be deleted from the memory. When there is new event information, it is necessary to query whether there is the same event ID in the periodic cache. When the same event ID is found in the periodic cache, the event information is abandoned to achieve convergence of event information with the same event ID.

[0058] Preferably, the event collector 21 is also used for:

[0059] After receiving the event information output by the event output interface on each Kubernetes cluster, the collected event information is filtered according to the preset filtering rules, the event information that meets the filtering rules is filtered out, and the event information that does not meet the filtering rules is retained as the event information to be filtered, so as to filter out the event information that does not need to be sent; the filtering rules include at least one of the following or any combination: filtering out events in a specified namespace, filtering out events of a set type, and filtering out events containing set information.

[0060] The above technical solution of the embodiment of the present invention is described in detail below in conjunction with specific application examples. For technical details not introduced during the implementation process, please refer to the relevant description in the previous text.

[0061] The present invention is implemented as a method for generating an alarm, and a device corresponding to the method, wherein the alarm includes: Kubernetes multi-cluster event information and Prometheus monitoring alarm information, such as Figure 3 The sequential flow chart of the alarm generation method shown in FIG. Figure 3 002), Prometheus( Figure 3 003), alarm callback service ( Figure 3 004), message queue ( Figure 3 005), Kubernetes multi-cluster ( Figure 3 006), event collector ( Figure 3 007), event consumer ( Figure 3 012), alarm transmitter ( Figure 3 013) and database ( Figure 3 015) collaborated to realize the solution of integrating the event information of Kubernetes multiple clusters with the monitoring alarm information of Prometheus.

[0062] Obtaining event information of at least one Kubernetes cluster through an event collector, and writing event information that meets set screening conditions into a message queue; wherein the event information is marked with an event source;

[0063] The monitoring alarm information of the monitoring alarm system is obtained through the alarm callback service, and the monitoring alarm information is converted into the data structure of event information in the Kubernetes cluster, and written into the message queue; wherein the monitoring alarm information is obtained by triggering the alarm callback service when the monitoring alarm system generates an alarm according to the configured alarm rule, and the event source marked by the monitoring alarm information after the data structure conversion is the monitoring alarm system;

[0064] Each message in the message queue is consumed by an event consumer, a corresponding target alarm message is generated according to the configured alarm rules, and the target alarm message is sent according to the configured receiving client and receiving method; the message queue includes messages corresponding to event information from at least one Kubernetes cluster and messages corresponding to monitoring alarm information from the monitoring alarm system.

[0065] 1. Web Services Figure 3 002)

[0066] By connecting to the Prometheus API, you can write to Prometheus ( Figure 3003) Alarm rules, only alarm rules (Prometheus is only responsible for alarms, not sending them), alarm rules are used to make Prometheus generate alarms. The first rule for monitoring alarm information includes: alarm rules, alarm levels, receiving clients and receiving methods corresponding to monitoring alarm information; and write the first rule to the database ( Figure 3 015). Prometheus API is the application program interface provided by the monitoring and alarm system Prometheus.

[0067] 2. Alarm callback service ( Figure 3 004)

[0068] The alarm callback service is a Webhook. When Prometheus( Figure 3 003) When a monitoring alarm occurs according to the alarm rule configured by the user, the monitoring alarm information is sent to the alarm callback service in the form of an HTTP request, and the HTTP request carries the monitoring alarm information as the HTTP Body; the alarm callback service parses the HTTP Body, obtains the monitoring alarm information, and needs to convert the data format of the monitoring alarm information, convert the format of the monitoring alarm information into the structure of Kubernetes event information, and set a label for the monitoring alarm information: the cluster name and the representation of the event source from the monitoring alarm system, and then send the monitoring alarm information to the message queue ( Figure 3 005).

[0069] 3. Generate a second rule for the event information through the application program interface of the Kubernetes cluster, and write the second rule into the database, wherein the second rule includes: a receiving client and a receiving method corresponding to the event information.

[0070] 4. Event Collector ( Figure 3 007)

[0071] Event information is the data generated by kubernetes when coordinating resources. It is a record of behavior. Event information includes: what time, what happened, what operation was performed, and what the final status was. Event information is stored in etcd. Each cluster has a corresponding etcd, which is decentralized. Event information is generated by multiple behaviors. Both kubernetes administrators and ordinary users need to see it. Among them, coordination of resources is a broad concept. In order to obtain the expected situation of users, kubernetes coordinates multiple configurations or resources through controllers. Various event information will be generated during the entire coordination process.

[0072] a) Kubernetes event collection:

[0073] Because the event information of multiple Kubernetes clusters needs to be collected, each cluster should have an independent and unique name. The event collector will start the same number of coroutines according to the number of Kubernetes clusters. The coroutines listen to the event information of each cluster by calling the application program interface API of the Kubernetes cluster. The coroutine is a lightweight concurrent execution unit that can be switched in user mode (i.e., at the application level) without the intervention of the operating system kernel.

[0074] b) Event Marking ( Figure 3 008):

[0075] In order to know the source of event information, you need to label the event. The main labels include the cluster name and the event source representing the Kubernetes cluster, which needs to be reflected in the subsequent alarm information.

[0076] c) Event Filtering Figure 3 009):

[0077] After receiving the event information output by the event output interface on each Kubernetes cluster, the collected event information is filtered according to the preset filtering rules, the event information that meets the filtering rules is filtered out, and the event information that does not meet the filtering rules is retained as the event information to be filtered; the filtering rules can be defined according to the needs, such as the filtering rules include at least one or any combination of: filtering out events in a specified namespace, filtering out events of a certain type, filtering out events containing certain information, etc.

[0078] d) Event Convergence ( Figure 3 010): The underlying principle of Kubernetes event information generation is the event information generated by various coordinators in Kubernetes when coordinating resources. Therefore, the generation of event information is not completely sent according to a certain period. Event information with the same event ID is the same, but the time of occurrence of the event information is updated and the number of occurrences is increased. Due to this mechanism of Kubernetes event information generation, if the event information is not converged, the event information will be repeated and frequent.

[0079] e) Periodic caching:

[0080] Since the event information with the same Kubernetes event ID differs only in time and frequency, a periodic cache mechanism is used to converge Kubernetes event information. First, a fixed-size memory space is applied to store the event ID. The event ID is stored in a dictionary data format. The dictionary data format has a characteristic that the key value of the dictionary cannot be repeated. When the event ID is stored, the storage period of the event ID is written, such as 2 minutes. After 2 minutes, the event ID will be deleted from the memory.

[0081] For each event information to be filtered, query whether there is an identical event ID in the periodic cache, wherein the periodic cache stores event information in a dictionary format, and the event information in the dictionary format is a key-value pair consisting of an event ID as a key and a resource acquisition process information set of the event information as a value;

[0082] If the same event ID is not found in the periodic cache, the event information is written into the message queue, and a new key-value pair is formed with the event ID corresponding to the event information as the key and the resource acquisition process information set of the event information as the value, and the new key-value pair is saved in the periodic cache; the key-value pairs in the periodic cache are marked with a storage period, and the storage period is used to constrain the maximum storage duration of the key-value pairs; the event information generated by the Kubernetes cluster is stored in ETCD (a key-value database) in the prior art, and the storage time defaults to one hour. Because the number of events is too large, etcd can no longer continue to implement the storage function.

[0083] When the same event ID is found in the periodic cache, the event information is abandoned to achieve convergence of event information with the same time ID. The purpose of converging events can be achieved by adjusting the size of the storage period.

[0084] f) Send the event information that does not have the same event ID to the message queue ( Figure 3 005)

[0085] 5. Message Queue ( Figure 3 005)

[0086] From the alarm callback service ( Figure 3 004) and the monitoring alarm information sent from the event collector ( Figure 3 007) event information sent is written to the message queue ( Figure 3 005) for event consumers ( Figure 3 012) to consume the alarm information.

[0087] 6. Event Consumer ( Figure 3 012)

[0088] a) Event Consumer ( Figure 3 012), from the message queue ( Figure 3 005) for consumption. This message queue has integrated monitoring alarm messages from Prometheus and event information from multiple Kubernetes integrations.

[0089] b) Another job of the event consumer is to store the messages obtained from the message queue in the database ( Figure 3 In 015), the alarm information is persisted.

[0090] c) At the same time, go to the database according to the label of the alarm information ( Figure 3 015) to retrieve the rules corresponding to the alarm message and obtain the corresponding receiving client (or recipient) and receiving method. The tag will pass the application information, cluster name, event source, namespace, application name

[0091] d) Send the alarm information, receiving client (or recipient) and receiving method to the alarm sender ( Figure 3 013) to send alarm information.

[0092] 7. Alarm transmitter ( Figure 3 013)

[0093] The alarm sender implements multiple alarm sending methods, and obtains alarm rules, clients (or recipients) and receiving methods according to the alarm information. Alarm methods (014) include: email, DingTalk; format the alarm information to render it into the data format of email or DingTalk, and then call the email or DingTalk interface to send the alarm information according to the receiving client (or recipient) and receiving method. At the same time, modify the alarm information in the database to add information such as the client (or recipient) and receiving method.

[0094] 8. Database Figure 3 015)

[0095] The first rule, the second rule, and the alarm information are stored in a database for persistence of the alarm information, the first rule, and the second rule.

[0096] Beneficial technical effects achieved by the embodiments of the present invention are:

[0097] 1. Unify and integrate the data formats of event information of multiple Kubernetes clusters and monitoring alarm information of Prometheus to achieve unified storage and processing.

[0098] 2. The unified collection, filtering, convergence and persistence of event information from multiple Kubernetes clusters solves the technical problem in the prior art that event information generated by Kubernetes clusters cannot be converged and the same event ID may be generated multiple times.

[0099] 3. For the event information of multiple Kubernetes clusters and the monitoring alarm information of Prometheus, the notification configuration rules are unified, and the alarm information (event information and monitoring alarm information) is sent to the alarm recipient in a unified format.

[0100] It should be understood that the specific order or hierarchy of steps in the disclosed process is an example of an exemplary method. Based on design preferences, it should be understood that the specific order or hierarchy of steps in the process can be rearranged without departing from the scope of protection of the present disclosure. The attached method claims present the elements of the various steps in an exemplary order and are not intended to be limited to the specific order or hierarchy described.

[0101] In the above detailed description, various features are grouped together in a single embodiment to simplify the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the embodiments of the claimed subject matter require more features than are clearly stated in each claim. On the contrary, as reflected in the appended claims, the invention is in a state of having less than all the features of the disclosed individual embodiments. Therefore, the appended claims are hereby expressly incorporated into the detailed description, with each claim standing on its own as a separate preferred embodiment of the invention.

[0102] The disclosed embodiments are described above to enable any person skilled in the art to implement or use the present invention. Various modifications of these embodiments are obvious to those skilled in the art, and the general principles defined herein may also be applied to other embodiments without departing from the spirit and scope of the present disclosure. Therefore, the present disclosure is not limited to the embodiments given herein, but is consistent with the broadest scope of the principles and novel features disclosed in this application.

[0103] The above description includes examples of one or more embodiments. Of course, it is impossible to describe all possible combinations of components or methods for the purpose of describing the above embodiments, but it should be recognized by those skilled in the art that the various embodiments may be further combined and arranged. Therefore, the embodiments described herein are intended to cover all such changes, modifications and variations that fall within the scope of protection of the appended claims. In addition, with respect to the term "comprising" used in the specification or claims, the word is covered in a manner similar to the term "including", just as "including," is explained as a transitional word in the claims. In addition, any term "or" used in the specification of the claims is intended to mean "non-exclusive or".

[0104] Those skilled in the art may also understand that the various illustrative logical blocks, units, and steps listed in the embodiments of the present invention may be implemented by electronic hardware, computer software, or a combination of the two. In order to clearly demonstrate the interchangeability of hardware and software, the various illustrative components, units, and steps described above have generally described their functions. Whether such functions are implemented by hardware or software depends on the specific application and the design requirements of the entire system. Those skilled in the art may use various methods to implement the described functions for each specific application, but such implementation should not be understood as exceeding the scope of protection of the embodiments of the present invention.

[0105] The various illustrative logic blocks or units described in the embodiments of the present invention can be implemented or operated by a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field programmable gate array or other programmable logic device, a discrete gate or transistor logic, a discrete hardware component, or any combination of the above. The general-purpose processor can be a microprocessor, and optionally, the general-purpose processor can also be any conventional processor, controller, microcontroller or state machine. The processor can also be implemented by a combination of computing devices, such as a digital signal processor and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a digital signal processor core, or any other similar configuration.

[0106] The steps of the method or algorithm described in the embodiments of the present invention can be directly embedded in hardware, a software module executed by a processor, or a combination of the two. The software module can be stored in a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, a CD-ROM, or other storage media of any form in the art. Exemplarily, the storage medium can be connected to the processor so that the processor can read information from the storage medium and can write information to the storage medium. Optionally, the storage medium can also be integrated into the processor. The processor and the storage medium can be arranged in an ASIC, and the ASIC can be arranged in a user terminal. Optionally, the processor and the storage medium can also be arranged in different components in the user terminal.

[0107] In one or more exemplary designs, the above functions described in the embodiments of the present invention can be implemented in hardware, software, firmware or any combination of the three. If implemented in software, these functions can be stored on a computer-readable medium, or transmitted in the form of one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media that facilitate the transfer of computer programs from one place to another. The storage medium can be any available medium that can be accessed by any general or special computer. For example, such computer-readable media can include but are not limited to RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage or other magnetic storage devices, or any other medium that can be used to carry or store program codes in the form of instructions or data structures and other forms that can be read by general or special computers, or general or special processors. In addition, any connection can be appropriately defined as a computer-readable medium, for example, if the software is transmitted from a website site, server or other remote resource through a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL) or wirelessly, such as infrared, wireless and microwave, it is also included in the defined computer-readable medium. The disk and disc include compact disk, laser disk, optical disk, DVD, floppy disk and blue-ray disk. Disks usually copy data magnetically, while discs usually copy data optically with lasers. The above combination can also be included in computer readable media.

[0108] The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for generating an alarm, characterized in that: include: Obtaining event information of at least one Kubernetes cluster through an event collector, and writing event information that meets set screening conditions into a message queue; wherein the event information is marked with an event source; The monitoring alarm information of the monitoring alarm system is obtained through the alarm callback service, and the monitoring alarm information is converted into the data structure of event information in the Kubernetes cluster, and written into the message queue; wherein the monitoring alarm information is obtained by triggering the alarm callback service when the monitoring alarm system generates an alarm according to the configured alarm rule, and the event source marked by the monitoring alarm information after the data structure conversion is the monitoring alarm system; Each message in the message queue is consumed by an event consumer, a corresponding target alarm message is generated according to the configured alarm rules, and the target alarm message is sent according to the configured receiving client and receiving method; the message queue includes messages corresponding to event information from at least one Kubernetes cluster and messages corresponding to monitoring alarm information from the monitoring alarm system.

2. The method for generating an alarm according to claim 1, characterized in that: Also includes: Generate a first rule for the monitoring alarm information through an application program interface of the monitoring alarm system, and write the first rule into a database, wherein the first rule includes an alarm rule, an alarm level, a receiving client corresponding to the monitoring alarm information, and a receiving method; A second rule is generated for the event information through the application program interface of the Kubernetes cluster, and the second rule is written into a database, wherein the second rule includes: a receiving client and a receiving method corresponding to the event information.

3. The method for generating an alarm according to claim 1, characterized in that: The obtaining event information of at least one Kubernetes cluster through an event collector includes: Start the same number of coroutines as the Kubernetes clusters through the event collector, call the event output interface on the corresponding Kubernetes cluster through each coroutine, listen to and collect the event information output by the event output interface, set a label for the event information, and the label includes at least: the cluster name and the event source representing the Kubernetes cluster.

4. The method for generating an alarm according to claim 1, characterized in that: The obtaining of monitoring alarm information of the monitoring alarm system through the alarm callback service includes: Receiving an HTTP request from a monitoring alarm system through an alarm callback service, wherein the monitoring alarm system is used to monitor the at least one Kubernetes cluster, and the HTTP request carries the monitoring alarm information as an HTTP Body; The monitoring alarm information is obtained by parsing the HTTP Body in the HTTP request, and a label is set for the monitoring alarm information, wherein the label at least includes: a cluster name and an event source representing an event from a monitoring alarm system.

5. The method for generating an alarm according to claim 3, characterized in that: The step of writing the event information that meets the set screening conditions into the message queue includes: For each event information to be filtered, query whether there is an identical event ID in the periodic cache, wherein the periodic cache stores event information in a dictionary format, and the event information in the dictionary format is a key-value pair consisting of an event ID as a key and a resource acquisition process information set of the event information as a value; If the same event ID is not found in the periodic cache, the event information is written into the message queue, and a new key-value pair is formed with the event ID corresponding to the event information as the key and the resource acquisition process information set of the event information as the value, and the new key-value pair is stored in the periodic cache; the key-value pairs in the periodic cache are marked with a storage period, and the storage period is used to constrain the maximum storage duration of the key-value pairs; When the same event ID is found in the periodic cache, the event information is abandoned to achieve convergence of event information with the same event ID.

6. The method for generating an alarm according to claim 5, characterized in that: The method further comprises: After receiving the event information output by the event output interface on each Kubernetes cluster, the collected event information is filtered according to the preset filtering rules, the event information that meets the filtering rules is filtered out, and the event information that does not meet the filtering rules is retained as the event information to be filtered; the filtering rules include at least one or any combination of the following: filtering out events in a specified namespace, filtering out events of a set type, and filtering out events containing set information.

7. A device for generating an alarm, characterized in that: include: An event collector, used to obtain event information of at least one Kubernetes cluster and write event information that meets set screening conditions into a message queue; wherein the event information is marked with an event source; An alarm callback service is used to obtain monitoring alarm information from the monitoring alarm system, convert the monitoring alarm information into a data structure of event information in the Kubernetes cluster, and write it into a message queue; wherein the monitoring alarm information is obtained by triggering the alarm callback service when the monitoring alarm system generates an alarm according to the configured alarm rules, and the event source marked by the monitoring alarm information after the data structure conversion is the monitoring alarm system; An event consumer is used to consume each message in the message queue, generate a corresponding target alarm message according to the configured alarm rules, and send the target alarm message according to the configured receiving client and receiving method; the message queue includes messages corresponding to event information from the at least one Kubernetes cluster and messages corresponding to monitoring alarm information from the monitoring alarm system.

8. The device for generating an alarm according to claim 7, characterized in that: The event collector is specifically used for: Start the same number of coroutines as the number of Kubernetes clusters, call the event output interface on the corresponding Kubernetes cluster through each coroutine, listen to and collect the event information output by the event output interface, and set a label for the event information, where the label at least includes: the cluster name and the event source representing the Kubernetes cluster.

9. The device for generating an alarm according to claim 7, characterized in that: The alarm callback service is specifically used for: Receiving an HTTP request from a monitoring and alarm system, where the monitoring and alarm system is used to monitor the at least one Kubernetes cluster, and the HTTP request carries the monitoring and alarm information as an HTTP Body; The monitoring alarm information is obtained by parsing the HTTP Body in the HTTP request, and a label is set for the monitoring alarm information, wherein the label at least includes: a cluster name and an event source representing an event from a monitoring alarm system.

10. The device for generating an alarm according to claim 8, characterized in that: The event collector is also used to: For each event information to be filtered, query whether there is an identical event ID in the periodic cache, wherein the periodic cache stores event information in a dictionary format, and the event information in the dictionary format is a key-value pair consisting of an event ID as a key and a resource acquisition process information set of the event information as a value; If the same event ID is not found in the periodic cache, the event information is written into the message queue, and a new key-value pair is formed with the event ID corresponding to the event information as the key and the resource acquisition process information set of the event information as the value, and the new key-value pair is stored in the periodic cache; the key-value pairs in the periodic cache are marked with a storage period, and the storage period is used to constrain the maximum storage duration of the key-value pairs; When the same event ID is found in the periodic cache, the event information is abandoned to achieve convergence of event information with the same event ID.

Images