Alarm rule generation method and device, electronic equipment and storage medium

Abstract

The application provides an alarm rule generation method and device, electronic equipment and a storage medium. The alarm rule generation method comprises: determining an alarm strategy set by a user in an interface, the alarm strategy being represented by text; converting the alarm strategy into a code recognizable by Prometheus; and filling the code into a corresponding position in an alarm rule template to obtain an alarm rule, the alarm rule template being generated based on Prometheus, and the alarm rule enabling Prometheus to perform monitoring. In this way, the maintenance cost of an IT system can be reduced. Moreover, the efficiency and accuracy of alarm rule configuration can be improved, thereby improving the timeliness and accuracy of IT system maintenance.

Description

Technical Field

[0001] This application relates to the field of monitoring technology, and in particular to an alarm rule generation method, apparatus, electronic device and storage medium. Background Technology

[0002] To ensure the continuous and stable operation of an enterprise's Internet Technology (IT) systems, it is necessary to monitor and manage various resources within the IT system, such as clusters (e.g., Kubernetes), system components (e.g., Kafka, ZooKeeper, Loki, etcd, Flink), database components, and microservices. This allows for timely alerts when abnormal resources are detected, enabling rapid identification and resolution of various anomalies and ensuring the normal and stable operation of the IT system.

[0003] Currently, Prometheus is the primary tool used for monitoring IT systems. Prometheus is an open-source system monitoring and alerting system. By configuring alert rules on the Prometheus Server and sending these rules to Prometheus, Prometheus processes the collected data based on these rules. If an anomaly is detected, it sends an alert to Alert Manager. Alert Manager is a separate alerting sub-policy that receives alerts from Prometheus and sends the processed alerts to the appropriate receivers.

[0004] Although Prometheus Server has the function of configuring alarm rules, configuring alarm rules based on Prometheus Server requires the configuration personnel to write configuration instructions line by line according to the requirements of Prometheus. This places high demands on the professional skills of the configuration personnel, thereby increasing the maintenance cost of the IT system. Summary of the Invention

[0005] The purpose of this application is to provide an alarm rule generation method, apparatus, electronic device, and storage medium that can reduce the maintenance cost of IT systems.

[0006] To address the aforementioned technical problems, this application provides the following technical solutions:

[0007] The first aspect of this application provides a method for generating alarm rules, the method comprising: determining an alarm policy set by a user in an interface, the alarm policy being represented in text; converting the alarm policy into code recognizable by Prometheus; filling the code into the corresponding position in an alarm rule template to obtain an alarm rule, the alarm rule template being generated based on Prometheus rules, and the alarm rule enabling Prometheus to perform monitoring.

[0008] A second aspect of this application provides an alarm rule generation apparatus, the apparatus comprising: a configuration unit for determining an alarm policy set by a user in an interface, the alarm policy being represented in text; a conversion unit for converting the alarm policy into code recognizable by Prometheus; and an assembly unit for filling the code into corresponding positions in an alarm rule template to obtain alarm rules, the alarm rule template being generated based on Prometheus rules, and the alarm rules enabling Prometheus to perform monitoring.

[0009] A third aspect of this application provides an electronic device, comprising: a processor, a memory, and a bus; wherein the processor and the memory communicate with each other via the bus; and the processor is used to invoke program instructions in the memory to execute the method of the first aspect.

[0010] A fourth aspect of this application provides a computer-readable storage medium, comprising: a stored program; wherein, when the program is executed, it controls the device on which the storage medium is located to perform the method of the first aspect.

[0011] Compared to existing technologies, the alarm rule generation method provided in the first aspect of this application, after determining that the alarm policy is set by the user in the interface using text, first converts the text-represented alarm policy into code that Prometheus can recognize, and then fills the code into the corresponding position in the alarm rule template to obtain the alarm rule. Here, the alarm rule template is generated based on Prometheus rules, and the alarm rules enable Prometheus to monitor. In this way, no professional technicians are required; even ordinary personnel, after simple training, can configure alarm rules that can be used in Prometheus through the interface, reducing the maintenance cost of IT systems. Furthermore, it avoids the tedious editing of alarm rules and improves the efficiency and accuracy of alarm rule configuration, thereby enhancing the timeliness and accuracy of IT system maintenance.

[0012] The alarm rule generation apparatus provided in the second aspect of this application, the electronic device provided in the third aspect, and the computer-readable storage medium provided in the fourth aspect have the same or similar beneficial effects as the alarm rule generation method provided in the first aspect. Attached Figure Description

[0013] The above and other objects, features, and advantages of exemplary embodiments of this application will become readily understood by reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of this application are illustrated by way of example and not limitation, with the same or corresponding reference numerals denoteing the same or corresponding parts, wherein:

[0014] Figure 1 This is a flowchart illustrating the alarm rule generation method in the embodiments of this application. Figure 1 ;

[0015] Figure 2 This is a schematic diagram of the interface in an embodiment of this application;

[0016] Figure 3 This is a flowchart illustrating the alarm rule generation method in the embodiments of this application. Figure 2 ;

[0017] Figure 4 This is a flowchart illustrating the alarm rule generation method in the embodiments of this application. Figure 3 ;

[0018] Figure 5 This is a schematic diagram of the alarm rule generation device in the embodiments of this application. Figure 1 ;

[0019] Figure 6 This is a schematic diagram of the alarm rule generation device in the embodiments of this application. Figure 2 ;

[0020] Figure 7 This is a schematic diagram of the structure of the electronic device in the embodiments of this application. Detailed Implementation

[0021] Exemplary embodiments of this application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of this application and to fully convey the scope of this application to those skilled in the art.

[0022] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application shall have the ordinary meaning as understood by one of ordinary skill in the art to which this application pertains.

[0023] Currently, monitoring IT systems primarily involves configuring alerting rules in Prometheus. However, configuring alerting rules in Prometheus requires specialized technical personnel, which undoubtedly increases the monitoring and maintenance costs of IT systems. Furthermore, configuring alerting rules in Prometheus by technical personnel involves writing code line by line based on the actual monitoring and alerting needs and the rules required by Prometheus. This not only consumes a significant amount of time for technical personnel but also carries the risk of errors due to oversight, thereby reducing the efficiency and accuracy of alerting rule generation.

[0024] Through in-depth research, the inventors discovered that the high monitoring and maintenance costs of current IT systems are primarily due not to the IT systems themselves, but to the configuration of alert rules in Prometheus. Furthermore, the low efficiency and accuracy of alert rule configuration in Prometheus are not primarily due to Prometheus itself, but rather to the fact that it requires manual configuration by specialized technical personnel.

[0025] In view of this, this application provides an alarm rule generation method. An interface is provided where alarm policies can be expressed in text, allowing users to set alarm policies via the interface. After determining the text alarm policy set by the user in the interface, the alarm policy is automatically converted into code that Prometheus can recognize. This code is then filled into the corresponding position in the alarm rule template. This alarm rule template is a framework for alarm rules generated based on Prometheus rules. At this point, alarm rules applicable to Prometheus and capable of being monitored by Prometheus are obtained. Thus, users only need to set alarm policies expressed in text in the interface to automatically generate alarm rules usable in Prometheus. This eliminates the need for professional technical personnel to configure alarm rules in Prometheus, reducing the monitoring and maintenance costs of IT systems. Furthermore, it avoids technical personnel writing alarm rule code line by line, improving the efficiency and accuracy of alarm rule configuration in Prometheus.

[0026] Next, the alarm rule generation method provided in the embodiments of this application will be described in detail.

[0027] Figure 1 This is a flowchart illustrating the alarm rule generation method in the embodiments of this application. Figure 1 See Figure 1 As shown, the method may include:

[0028] S101: Determine the alarm policy set by the user in the interface.

[0029] The alarm strategy is expressed in text.

[0030] The alarm policy can be set via text in the interface, eliminating the need for code. In other words, administrators can configure alarm policies directly through the interface using text. This text can be Chinese, English, numbers, symbols, or a combination of one or more of these.

[0031] Figure 2 This is a schematic diagram of the interface in an embodiment of this application. See also: Figure 2 As shown, a complete alarm strategy is formed in the interface by using Chinese phrases, English phrases, numbers, and symbols.

[0032] For example, when it is necessary to monitor the utilization of the Central Processing Unit (CPU) in a system, you can set "Service Alarm Policy" in the policy type of the interface, set "CPU Utilization", ">", "10", and "Immediate Alarm" in the alarm trigger conditions, set "Immediate Alarm if CPU Utilization is greater than 10%" in the policy name, set "Medium Risk" in the alarm level, and set "6" in the number of repeated alarms.

[0033] Of course, in addition to setting individual policies as described above, a complete policy can also be set directly. For example, the service alarm policy could be set to immediately alarm when CPU utilization exceeds 10%, with an alarm level of medium risk and a repeat alarm count of 6. Then, each policy can be obtained through statement recognition and decomposition. The specific format of the alarm policy in the interface is not limited here.

[0034] It should be noted that the above interface can be displayed through a browser. That is, users can log in to this interface by entering the specified address in their browser. Of course, the above interface can also be displayed in other ways, such as through applications or email. The specific method of viewing the interface is not limited here.

[0035] The systems that need to be monitored can be internal systems used by enterprises, institutions, governments, or other organizations, or they can be systems that are open to the public. The specific type of system to be monitored is not limited here.

[0036] In this way, when the system needs to be monitored, the user can set alarm policies using text in the interface. Then, the embodiment of this application can obtain the alarm policies represented by the text set by the user in the interface, and continue to generate subsequent alarm rules.

[0037] S102: Convert alarm policies into code that Prometheus can recognize.

[0038] Since the alerting policy is represented in text, and Prometheus cannot recognize text content, it can only recognize code language. Therefore, it is necessary to convert the text-represented alerting policy into code language that Prometheus can recognize.

[0039] In practice, the text-to-code correspondence can be used to convert alarm strategies represented by text into code that Prometheus can recognize.

[0040] Specifically, the mapping relationship contains various commonly used resource monitoring text phrases and their corresponding English phrases in Prometheus. After obtaining the text-represented alarm policy, the mapping relationship can be used to find text phrases that are consistent with or similar to the alarm policy. Then, the corresponding English phrases are used as the Prometheus-recognizable codes for the text-represented alarm policies set by the user in the interface.

[0041] Of course, other methods can be used to convert text-based alert policies into a code language that Prometheus can recognize. For example, language conversion tools can be used. The specific method for converting alert policies in the interface into Prometheus-recognizable code is not limited here.

[0042] S103: Fill the code into the corresponding position in the alarm rule template to obtain the alarm rule.

[0043] The alert rule templates are generated based on Prometheus rules. These alert rules enable Prometheus to perform monitoring.

[0044] In fact, the architecture of alerting rules configured in Prometheus is largely the same; the differences lie only in the specific monitoring content, i.e., the alerting policies. Therefore, alerting rule templates can be extracted based on Prometheus rules or by referring to previously configured alerting rules. Then, during subsequent configuration of Prometheus alerting rules, only the specific monitoring content, i.e., the alerting policies, needs to be filled in within the alerting rule template. There is no need to regenerate the alerting rule template afterward.

[0045] After converting the text-based alert policies in the interface into code that Prometheus can recognize, you can then populate the corresponding code into the designated locations in the alert rule template. Once all the fields are filled in, you will have the final alert rules that Prometheus can monitor.

[0046] In the specific implementation process, the alarm strategy can be filled into the specific location of the alarm rule template according to the specific content or type of the alarm strategy and the pre-set mapping relationship.

[0047] For example, suppose the content filled in interface A corresponds to the content reserved in alarm rule template a, the content filled in interface B corresponds to the content reserved in alarm rule template b, and the content filled in interface C corresponds to the content reserved in alarm rule template c. When a user sets alarm policy 1 in interface A, alarm policy 2 in interface B, and alarm policy 3 in interface C, policy 1 is converted into code 1, policy 2 into code 2, and policy 3 into code 3. Then, according to the preset mapping relationship, code 1 needs to be filled in alarm rule template a, code 2 needs to be filled in alarm rule template b, and code 3 needs to be filled in alarm rule template c.

[0048] Of course, other methods can also be used to populate the code in the corresponding position in the alarm rule template. For example, after identifying the specific content of the code, the code can be populated in the corresponding position in the alarm rule template based on the identified content. The specific content on which the code is based for populating the code in the corresponding position in the alarm rule template is not limited here.

[0049] After filling in the code in the alarm rule template, you will obtain the alarm rule, which is now generated. This alarm rule can then be sent to Prometheus, enabling Prometheus to monitor the system and send alarm messages to Alert Manager, thus allowing Alert Manager to issue alerts.

[0050] As described above, the alarm rule generation method provided in this application, after determining that the user has set an alarm policy using text in the interface, first converts the text-represented alarm policy into code that Prometheus can recognize, and then fills the code into the corresponding position in the alarm rule template to obtain the alarm rule. Here, the alarm rule template is generated based on Prometheus rules, and the alarm rules enable Prometheus to monitor. In this way, no professional technicians are required; ordinary personnel, after simple training, can configure alarm rules that can be used in Prometheus through the interface, reducing the maintenance cost of the IT system. Furthermore, it avoids the tedious editing of alarm rules and improves the efficiency and accuracy of alarm rule configuration, thereby enhancing the timeliness and accuracy of IT system maintenance.

[0051] Furthermore, as a response to Figure 1 To refine and extend the method shown, and improve the efficiency of text-to-code conversion, thereby enhancing the configuration efficiency of alerting rules, various commonly used alerting strategies can be collected in advance. Then, a correspondence can be established between the collected strategies and Prometheus-recognizable codes. In this way, after obtaining the textual representation of the alerting strategy from the interface, the corresponding code can be quickly determined through the correspondence, and then filled into the appropriate position in the alerting rule template, thus improving the configuration efficiency of alerting rules.

[0052] Specifically, before step S102, the method may also include: constructing a correspondence between the text representing each sub-strategy and the corresponding Prometheus-recognizable code.

[0053] Here, the alarm policy in the interface can be composed of at least one of multiple sub-policies. Each sub-policy represents different configuration content.

[0054] For example, before configuring alerting rules based on Prometheus, the first step is to collect information on the targets that need to be monitored for each system. Generally, the monitored targets mainly include eight categories: physical resources, storage, clusters, services, system components, data flow, data backlog, and collectors. Then, each major category is further subdivided into multiple subcategories. For example, physical resources can be divided into seven subcategories: CPU utilization, host status, network inflow, network outflow, memory utilization, network latency, and network utilization. This way, multiple sub-policies are collected. Finally, the correspondence between each sub-policy and its corresponding Prometheus-recognizable code is established.

[0055] During the process of establishing the correspondence, each sub-strategy can be named using an English word with an underscore, entered into the data dictionary, and indexed. This way, after obtaining the textual representation of the sub-strategy, the corresponding English word can be retrieved from the data dictionary using the index. These English words are essentially the code that Prometheus can recognize. Alternatively, a direct text-to-code correspondence can be established, where the data dictionary contains not only the English word but also the corresponding Chinese word and sub-strategy. In this way, after obtaining the textual representation of the sub-strategy, the corresponding Prometheus-recognizable code can be obtained by searching within the correspondence. The specific method for establishing the correspondence is not limited here.

[0056] Similarly, in addition to pre-entering English words related to monitoring alarms into the data dictionary, alarm rule templates can also be pre-created. For details on how to construct alarm rule templates, please refer to the description of step S103 above.

[0057] The following is an example of an alarm rule template.

[0058]

[0059] Of course, the format of the alarm rule template is not limited to FTL format; any format that is compatible with Prometheus and Alert Manager is acceptable. The specific format of the alarm rule template is not limited here.

[0060] Accordingly, step S102 can be: determining the Prometheus-recognizable code corresponding to the text representing at least one sub-strategy from the correspondence.

[0061] Because the data dictionary stores various English words used for monitoring and alerting—that is, English words corresponding to multiple sub-policies—and the content set by the user in the interface at one time will not be all the contents of the data dictionary, after determining at least one sub-policy set by the user in the interface, the corresponding English words for that at least one sub-policy can be found in the data dictionary. These English words can then be filled into the alert rule template, thereby automatically generating alert rules.

[0062] See also Figure 2 As shown, the sub-policies that users can set in the interface include: Service Alarm Policy, CPU Utilization, >, 10, Immediate Alarm, Immediate Alarm for CPU Utilization Greater Than 10%, Medium Risk, and 6. The corresponding English words for these sub-policies can be found in the data dictionary.

[0063] It's important to note that the sub-policies mentioned above, such as >, 10, and 6, may already be recognized by Prometheus without further conversion. Therefore, when converting sub-policies into code, content containing numerical values ​​or complex operations that Prometheus can recognize can be pre-excluded, reducing the amount of conversion and thus improving conversion efficiency, which in turn improves the configuration efficiency of alerting rules.

[0064] As can be seen from the above, by pre-constructing the correspondence between the text representing each sub-strategy and the corresponding Prometheus-recognizable code, that is, by entering the corresponding content into the data dictionary, after determining at least one sub-strategy set by the user in the interface, the corresponding English words for that at least one sub-strategy can be quickly found from the data dictionary, and then these English words can be filled into the alarm rule template to automatically generate alarm rules, thereby improving the configuration efficiency of alarm rules.

[0065] Furthermore, as a response to Figure 1 The method shown can be further refined and extended to ensure the completeness and accuracy of the alarm policies set by the user in the interface. After the user sets the alarm policies in the interface, the completeness and accuracy of the alarm policies can be checked.

[0066] Specifically, step S101 may include:

[0067] Step A1: Obtain the sub-policies set by the user in the policy box of the interface.

[0068] The interface contains multiple strategy boxes. See also... Figure 2 As shown, in this interface, there is one policy box corresponding to the policy type, four policy boxes corresponding to the alarm trigger condition, one policy box corresponding to the policy name, one policy box corresponding to the alarm level, and one policy box corresponding to the repeated alarm count. There are a total of eight policy boxes on this interface. Of course, this does not mean that there should only be eight policy boxes on the interface; the number of policy boxes can be set according to actual monitoring and alarm needs. The above is just an example.

[0069] In practical applications, users can set sub-policies in the policy box of the interface in the following two ways, but not limited to:

[0070] Method b1: The user selects a sub-strategy in the strategy box on the interface.

[0071] Accordingly, step A1 is to obtain the sub-strategy selected by the user in the drop-down menu of the strategy box on the interface.

[0072] That is, various sub-strategies are pre-set at corresponding positions on the interface and stored in the form of a drop-down menu. When a user needs to set an alarm strategy in the interface, the user can select the required sub-strategy from the drop-down menu of each strategy box. This can make it more convenient for the user to set the alarm strategy in the interface and reduce the probability of setting errors.

[0073] Mode b2: The user inputs a sub-strategy in the strategy box on the interface.

[0074] Correspondingly, step A1 is: acquiring the sub-strategy input by the user in the strategy box on the interface.

[0075] That is, each strategy box in the interface is blank, requiring the user to manually fill in the sub-strategy. When the user needs to set the alarm strategy in the interface, the alarm strategy setting is completed through manual filling. This allows the user to set the alarm strategy in the interface more flexibly, improving the flexibility of alarm strategy setting.

[0076] Since there may be input errors when the user manually inputs the sub-strategy in the strategy box on the interface, it is necessary to check the sub-strategy manually input by the user after the user manually inputs the sub-strategy.

[0077] Specifically, when the user sets the sub-strategy in the interface using the above mode b2, after the corresponding step A1, the following may further be included:

[0078] Step c1: Determine whether the input sub-strategy meets the preset format requirement; if yes, execute step c2; if no, execute step c3.

[0079] Step c2: Take the input sub-strategy as the sub-strategy set by the user in the strategy box on the interface.

[0080] Step c3: Perform format conversion on the input sub-strategy, and take the format-converted sub-strategy as the sub-strategy set by the user in the strategy box on the interface.

[0081] For example, still referring to Figure 2 as shown, for example: for the third strategy box in the alarm trigger condition, the preset format requirement should be any value between 0 and 100. If the input value is 200 at this time, it is determined that the input sub-strategy does not meet the preset format requirement, and it can be considered that the user has input an extra 0 when inputting 20, so 200 can be automatically modified to 20 for confirmation with the user. For another example: for the strategy box in the alarm level, the preset format requirement should be correct spelling. If the input content is "中未" at this time, it is determined that the input sub-strategy does not meet the preset format requirement, and it can be directly and automatically modified to the correct term "Medium Risk".

[0082] Step A2: Determine if the number of sub-policies set is consistent with the number of policy boxes in the interface; if yes, proceed to step A3; if no, proceed to step A4.

[0083] Generally, users may overlook some sub-policies when setting them in the interface. If some policy boxes in the interface lack sub-policies, the alert rule template will not be fully populated, resulting in incomplete alert rules that cannot run in Prometheus. Therefore, after the user completes the settings and clicks save, it is necessary to check whether the number of sub-policies set by the user matches the number of policy boxes in the interface.

[0084] See also Figure 2 As shown, suppose a user sets the following sub-policies in the interface: "Service Alarm Policy", "CPU Utilization", "10", "Immediate Alarm", "Immediate Alarm if CPU Utilization is greater than 10%", "Medium Risk", and "6", but omits the ">" setting. In this case, the number of sub-policies set by the user in the interface is 7, while the number of policy boxes in the interface is 8, resulting in a discrepancy.

[0085] Step A3: Use the sub-policy set as the alarm policy set by the user in the interface.

[0086] When the number of sub-policies set by the user in the interface is the same as the number of policy boxes in the interface, it means that the user's settings in the interface are complete. The user's sub-policies can be used as the alarm policies set by the user in the interface. Then, after finding the corresponding English words, they are filled into the alarm rule template to generate alarm rules.

[0087] Step A4: Display a prompt message on the interface.

[0088] The prompt message is used to remind the user that the number of sub-policies set is inconsistent with the number of policy boxes in the interface.

[0089] When the number of sub-policies set by the user in the interface is inconsistent with the number of policy boxes in the interface, it means that the content set by the user in the interface is incomplete and some required fields have not been set by the user. At this time, it is necessary to output prompt information in the interface to remind the user that there are omissions in the process of setting sub-policies.

[0090] After the prompts are displayed on the interface, users can either supplement any missing sub-policies based on the prompts, or the interface backend can automatically supplement any missing sub-policies. Regardless of the method used to supplement missing sub-policies, the sub-policy settings on the interface are complete, ensuring the completeness and accuracy of the generated alarm rules.

[0091] In the process of automatically supplementing sub-policies, after step A4, the following may also be included:

[0092] Step A5: When user feedback is received, identify the target strategy box that the user has not set in the interface.

[0093] The feedback information is used to instruct users not to add sub-policies.

[0094] After the prompt message is displayed on the interface, the user may not want to add any missing sub-strategies, or the user may not know what to set for the missing sub-strategies. Therefore, the user may provide feedback on the prompt message or click "save" multiple times. The user's feedback or multiple clicks can be considered as specific feedback information.

[0095] In order to automatically add any sub-policies missed by the user later, it is necessary to determine which policy boxes the user missed in the interface, i.e., the settings of the target policy boxes.

[0096] Step A6: Identify the sub-policy in the target policy box from the historical policies of the same type as the sub-policy set.

[0097] Before making this setting in the interface, the user has made multiple historical settings, which constitute historical policies. Therefore, the sub-policy in the target policy box can be determined from historical policies that are similar to the sub-policy being set.

[0098] In determining sub-policies within the target policy frame from historical policies, one can select the most recently set sub-policy from all corresponding sub-policies within the historical policy's target policy frame, or select the sub-policy set most frequently, or sum and average the sub-policies of all corresponding sub-policies within the historical policy's target policy frame. The specific method for retrieving sub-policies from the target policy frame from historical policies is not limited here.

[0099] See also Figure 2 As shown, suppose the user forgot to set the number of repeated alarms when configuring the interface. Since the user has already set "Service Alarm Policy" and "CPU Utilization" in the interface, the specific value of the number of repeated alarms can be determined from the user's previous settings related to service alarm policy and CPU utilization (e.g., the first time set to 5, the second time set to 4, the third time set to 6, etc.).

[0100] Of course, if the user is setting it up for the first time in the interface, then it is impossible to determine the sub-policy that the user missed from the historical policies. We can only continue to output prompts to remind the user to add them.

[0101] Step A7: Use the sub-policies in the determined target policy box and the set sub-policies as the alarm policies set by the user in the interface.

[0102] After automatically identifying the sub-policies missed by the user from the historical policies, the automatically identified sub-policies and the sub-policies set by the user in the interface can form a complete alarm policy. Then, by converting and filling in the alarm policy, a complete and correct alarm rule can be obtained.

[0103] In addition to setting new alarm policies in the interface, users can also modify, delete, enable, and disable saved alarm rules through the interface.

[0104] After the user sets the alarm policy in the interface, the backend retrieves the corresponding English word for the alarm policy from the data dictionary and fills the English word into the corresponding position in the alarm rule template to configure the alarm rule.

[0105] continue Figure 2 The example above shows an alarm rule template where the alarm policy is selected in the alarm population interface, the alarm triggering condition is selected in the expr population interface, the duration is selected in the duration population interface, the alarm level is selected in the level population interface, and so on.

[0106] As described above, after the user sets each sub-policy in the interface, the system checks whether the number of sub-policies set by the user matches the number of policy boxes in the interface. If a discrepancy is found, a prompt message is generated to remind the user to supplement the policy. Alternatively, it identifies a target policy box in the interface that the user has not set and automatically supplements the sub-policies in the target policy box based on historical policies. This ensures that the alarm policies set by the user in the interface are complete, thereby improving the completeness and accuracy of alarm rule generation. Furthermore, when the user manually enters a sub-policy in the interface, it checks whether the entered sub-policy conforms to the preset format requirements. If not, it is automatically modified, improving the convenience and accuracy of setting alarm policies in the interface. Finally, by allowing the user to select the desired sub-policy from the drop-down menu of each policy box in the interface and use it as the alarm policy set in the interface, the system makes setting alarm policies in the interface more convenient and reduces the probability of setting errors.

[0107] Furthermore, as a response to Figure 1The method described is a refinement and extension. After generating alarm rules, the configured alarm rules can be uploaded to Prometheus via the k8s-client client to make the configuration effective. Prometheus monitors the system and generates alarms based on the configured alarm rules, and pushes the generated alarm messages to Alert Manager.

[0108] Alert Manager manages these alert messages. The management includes silencing, suppressing, and aggregating alerts. The alert messages are then sent to the appropriate receivers via email, SMS, or other means, or to the alert message service, i.e., the backend interface in this application's embodiment.

[0109] To enable users to view alarm messages more clearly, alarm messages can be received from Alert Manager and further processed to allow users to view them more clearly.

[0110] Specifically, after step S103, the following may also be included:

[0111] Step B1: Receive alarm messages sent by Alert Manager.

[0112] Alert messages in Alert Manager are generated based on alert messages sent from Prometheus to Alert Manager, while alert messages in Prometheus are generated based on alert rules.

[0113] Step B2: Parse the alarm information and generate an alarm list.

[0114] Each row in the alarm list corresponds to information for a different alarm attribute.

[0115] Step B3: Display the alarm list.

[0116] Since Alert Manager sends alert messages in a JSON format, the specific alert content cannot be viewed by non-technical personnel. Therefore, the alert messages need to be formatted, i.e., parsed, to extract fields such as Internet Protocol (IP), alert trigger time, alert end time, and alert content. Each alert message is parsed into a single record and stored in the database as an alert list. Simultaneously, users can be notified via in-site messages, allowing them to view easily understandable alert messages through the front-end interface.

[0117] As can be seen from the above, by processing the alarm messages pushed by Alert Manager into an alarm list that ordinary users can understand and displaying it on the interface, users can more easily and clearly view the alarm messages, thus improving the user experience in platform monitoring.

[0118] Finally, a complete embodiment will be used to fully describe the alarm rule generation method provided in this application.

[0119] Figure 3 This is a flowchart illustrating the alarm rule generation method in the embodiments of this application. Figure 2 See Figure 3 As shown, the method may include:

[0120] S301: The survey platform needs to monitor and classify the targets, and name each target using English words with underscores, and enter them into the data dictionary.

[0121] S302: Organize alarm rule templates in FTL format according to the rules defined by Alert Manager.

[0122] S303: Add alarm policies to the front-end interface according to business needs.

[0123] S304: After the alarm policy is saved, it is assembled into alarm rules according to the alarm rule template in FTL format, and uploaded to Prometheus through the k8s-client to make the configuration effective.

[0124] S305: After Prometheus makes a judgment, it generates an alarm message and pushes it to Alert Manager. Alert Manager manages the alarm messages and sends them to the alarm message service via Email, SMS and other means.

[0125] S306: After receiving the alarm message pushed by Alert Manager, the alarm service formats the alarm message, parses each alarm message into a record, stores it in the database, and notifies the user via in-site message or other means.

[0126] It should be noted that steps S301 and S302 can be executed only once, while steps S303 to S306 can be configured multiple times according to the configuration requirements of the alarm rules. Of course, when a new monitoring target appears, or the template needs to be changed, steps S301 and S302 can be executed repeatedly.

[0127] Figure 4 This is a flowchart illustrating the alarm rule generation method in the embodiments of this application. Figure 3 See Figure 4As shown, Figure 4 and Figure 3 The process is essentially the same; this is only to provide a clearer explanation of the overall process of the alarm rule generation method in the embodiments of this application.

[0128] First, the policy management module allows users to configure alarm policies through the interface. The controller and PostgreSQL modules then transmit the alarm policies from the front-end interface to the back-end and retrieve the corresponding English terms for each policy. Finally, the alarm rule template module generates alarm rule templates.

[0129] Then, by assembling the alarm configuration module, English words are filled into the alarm rule template. Alarm rules are generated using the alarm message generation module. The alarm rules are then sent to the Prometheus module via the k8s-client-api, enabling Prometheus to monitor them. The Alert Manager module manages the alarm messages sent by Prometheus.

[0130] Next, the alarm receiving module receives alarm messages. The formatting module formats the alarm messages. The PostgreSQL module converts the processed alarm messages into text and generates an alarm list. The controller module sends the alarm list to the front-end interface.

[0131] Finally, the alarm list is displayed through the alarm information module.

[0132] Based on the same inventive concept, as an implementation of the above method, this application also provides an alarm rule generation device. Figure 5 This is a schematic diagram of the alarm rule generation device in the embodiments of this application. Figure 1 See Figure 5 As shown, the device may include:

[0133] Configuration unit 501 is used to determine the alarm policy set by the user in the interface, wherein the alarm policy is expressed in text.

[0134] The conversion unit 502 is used to convert the alarm policy into code that Prometheus can recognize;

[0135] Assembly unit 503 is used to fill the code into the corresponding position in the alarm rule template to obtain alarm rules. The alarm rule template is generated based on Prometheus rules, and the alarm rules enable Prometheus to monitor.

[0136] Furthermore, as a response to Figure 5In a refinement and extension of the illustrated device, this application embodiment also provides an alarm rule generation device. Figure 6 This is a schematic diagram of the alarm rule generation device in the embodiments of this application. Figure 2 See Figure 6 As shown, the device may include:

[0137] Here, the alarm policy consists of at least one of multiple sub-policies, each representing different configuration content.

[0138] Construction unit 601 is used to construct the correspondence between the text representing each sub-strategy and the corresponding Prometheus-recognizable code.

[0139] Configuration unit 602 includes:

[0140] Get sub-unit 6021, used to retrieve the sub-policy set by the user in the policy box of the interface.

[0141] The acquisition subunit 6021 is specifically used to acquire the sub-strategy entered by the user in the strategy box of the interface; when the entered sub-strategy meets the preset format requirements, the entered sub-strategy is used as the sub-strategy set by the user in the strategy box of the interface; when the entered sub-strategy does not meet the preset format requirements, the format of the entered sub-strategy is converted, and the converted sub-strategy is used as the sub-strategy set by the user in the strategy box of the interface.

[0142] The acquisition subunit 6021 is specifically used to acquire the sub-strategy selected by the user in the drop-down menu of the strategy box on the interface.

[0143] The first determining subunit 6022 is used to use the set sub-strategies as alarm strategies set by the user in the interface when the number of set sub-strategies is consistent with the number of strategy boxes in the interface.

[0144] The prompt subunit 6023 is used to display a prompt message on the interface when the number of set sub-strategies is inconsistent with the number of strategy boxes in the interface. The prompt message is used to remind the user that the number of set sub-strategies is inconsistent with the number of strategy boxes in the interface.

[0145] The second determining subunit 6024 is used to determine, when receiving feedback information from the user, a target policy box that the user has not set in the interface, the feedback information being used to instruct the user not to add a sub-policy; determine the sub-policy in the target policy box from historical policies of the same type as the set sub-policy; and use the determined sub-policy in the target policy box and the set sub-policy as the alarm policy set by the user in the interface.

[0146] The conversion unit 603 is used to determine, from the correspondence, the Prometheus-recognizable code corresponding to the text representing the at least one sub-strategy.

[0147] Assembly unit 604 is used to fill the code into the corresponding position in the alarm rule template to obtain alarm rules. The alarm rule template is generated based on Prometheus rules, and the alarm rules enable Prometheus to monitor.

[0148] The receiving unit 605 is used to receive alarm messages sent by the Alert Manager, wherein the alarm messages in the Alert Manager are generated based on the alarm messages sent by Prometheus to the Alert Manager, and the alarm messages in Prometheus are generated based on the alarm rules.

[0149] The parsing unit 606 is used to parse the alarm information and generate an alarm list, wherein each row of the alarm list corresponds to information corresponding to different alarm attributes.

[0150] Display unit 607 is used to display the alarm list.

[0151] It should be noted that the description of the above device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0152] Based on the same inventive concept, embodiments of this application also provide an electronic device. Figure 7 This is a schematic diagram of the electronic device in an embodiment of this application. See also... Figure 7 As shown, the electronic device may include: a processor 701, a memory 702, and a bus 703; wherein the processor 701 and the memory 702 communicate with each other through the bus 703; the processor 701 is used to call program instructions in the memory 702 to execute the methods in one or more of the above embodiments.

[0153] It should be noted that the descriptions of the above electronic device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the electronic device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0154] Based on the same inventive concept, embodiments of this application also provide a computer-readable storage medium, which may include: a stored program; wherein, when the program is running, it controls the device where the storage medium is located to execute the methods in one or more of the above embodiments.

[0155] It should be noted that the descriptions of the storage medium embodiments above are similar to those of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0156] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for generating alarm rules, characterized in that, The method includes: Determine the complete alarm policy set by the user in the interface. The alarm policy is represented by text. The individual sub-policies in the complete alarm policy are obtained through sentence recognition and decomposition. Construct a correspondence between the text representing each sub-policy and the corresponding Prometheus-recognizable code; each sub-policy is named using English words with underscores, and content containing numbers or operators is excluded beforehand; From the correspondence, determine the Prometheus-recognizable code corresponding to the text representing at least one sub-strategy; Fill the code into the corresponding position in the alarm rule template to obtain the alarm rule. The alarm rule template is generated based on Prometheus rules, and the alarm rule enables Prometheus to monitor. The alarm policy is composed of at least one of multiple sub-policies, each representing different configuration content; determining the alarm policy set by the user in the interface includes: Retrieve the sub-policies set by the user in the policy box of the interface; When the number of sub-policies set is inconsistent with the number of policy boxes in the interface, a prompt message is displayed in the interface. The prompt message is used to remind the user that the number of sub-policies set is inconsistent with the number of policy boxes in the interface. When the number of sub-strategies set is inconsistent with the number of strategy boxes in the interface, the method further includes: When user feedback is received, the system determines the target policy box that the user has not set in the interface, and the feedback is used to instruct the user not to add sub-policies. Determine the sub-strategy in the target strategy box from historical strategies of the same type as the set sub-strategy; The sub-policies in the determined target policy box and the set sub-policies are used as the alarm policies set by the user in the interface.

2. The method according to claim 1, characterized in that, The determination of the alarm policy set by the user in the interface includes: When the number of sub-policies set is the same as the number of policy boxes in the interface, the set sub-policies will be used as the alarm policies set by the user in the interface.

3. The method according to claim 2, characterized in that, The process of obtaining the sub-policies set by the user in the policy box of the interface includes: Get the sub-policy that the user enters in the policy box on the interface; When the input sub-policy meets the preset format requirements, the input sub-policy will be used as the sub-policy set by the user in the policy box of the interface. When the input sub-policy does not meet the preset format requirements, the input sub-policy is converted, and the converted sub-policy is used as the sub-policy set by the user in the policy box of the interface.

4. The method according to claim 2, characterized in that, The process of obtaining the sub-policies set by the user in the policy box of the interface includes: Get the sub-policy selected by the user in the drop-down menu of the policy box on the interface.

5. The method according to any one of claims 1 to 4, characterized in that, After obtaining the alarm rules, the method further includes: Receive alarm messages sent by Alert Manager, wherein the alarm messages in Alert Manager are generated based on the alarm messages sent by Prometheus to Alert Manager, and the alarm messages in Prometheus are generated based on the alarm rules; The alarm message is parsed to generate an alarm list, and each row of the alarm list corresponds to information corresponding to different alarm attributes; Display the alarm list.

6. An alarm rule generation device, characterized in that, The device includes: The configuration unit is used to determine the complete alarm policy set by the user in the interface. The alarm policy is represented by text, and the various sub-policies in the complete alarm policy are obtained by sentence recognition and decomposition. The building unit is used to construct the correspondence between the text representing each sub-policy and the corresponding Prometheus-recognizable code; each sub-policy is named using English words with underscores, and content containing numbers and operators is excluded in advance; A conversion unit is used to determine, from the correspondence, the Prometheus-recognizable code corresponding to at least one sub-strategy characterization text; An assembly unit is used to fill the code into the corresponding position in the alarm rule template to obtain alarm rules. The alarm rule template is generated based on Prometheus rules, and the alarm rules enable Prometheus to monitor. The alarm policy is composed of at least one of multiple sub-policies, each representing different configuration content; the configuration unit includes: Get sub-units, used to retrieve the sub-policies set by the user in the policy box of the interface; The prompt subunit is used to display a prompt message on the interface when the number of set sub-strategies is inconsistent with the number of strategy boxes in the interface. The prompt message is used to remind the user that the number of set sub-strategies is inconsistent with the number of strategy boxes in the interface. The second determining subunit is used to determine, when receiving feedback information from the user, a target policy box that the user has not set in the interface, the feedback information being used to instruct the user not to add any more sub-policies; determine the sub-policies in the target policy box from historical policies of the same type as the set sub-policies; and use the determined sub-policies in the target policy box and the set sub-policies as the alarm policies set by the user in the interface.

7. An electronic device, characterized in that, include: Processor, memory, bus; The processor and the memory communicate with each other via the bus. The processor is used to invoke program instructions in the memory to execute the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, include: A stored program; wherein, when the program is executed, the device containing the storage medium is controlled to perform the method as described in any one of claims 1 to 5.

Images