Cloud platform alarm notification configuration method, device, equipment and medium

Abstract

The invention discloses a cloud platform alarm notification configuration method and device, equipment and a medium, and relates to the technical field of cloud computing. The method comprises the following steps: based on a custom resource definition defined in a Kubernetes cluster, creating a custom resource instance configured by an alarm notification according to a user demand; generating a global alarm notification configuration in a ConfigMap format by using a preset configuration management center component in the cloud platform; mounting the global alarm notification configuration to a first container of an alarm notification component, and monitoring the global alarm notification configuration by using a second container newly added in a Pod of the alarm notification component; and when the configuration is changed, calling a configuration hot loading interface of the alarm notification component to dynamically update the global alarm notification configuration, and reloading the updated global alarm notification configuration. According to the technical scheme of the invention, the isolation and safety of alarm notification configuration can be ensured, and the continuity and reliability of an alarm notification function can be ensured.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing technology, and in particular to a cloud platform alarm notification configuration method, device, equipment and medium. Background Art

[0002] With the rapid development of cloud-native technologies, Kubernetes-based cloud platforms have become core infrastructure for enterprise application deployment and management. In cloud platform operations and maintenance, monitoring and alerting are critical for ensuring system stability: by detecting application anomalies in real time and quickly notifying operations and maintenance personnel, fault response time can be significantly reduced. Traditional cloud platform monitoring and alerting solutions typically use Prometheus, a representative tool in the cloud-native monitoring field, combined with the AlertManager alarm management component to form a complete monitoring chain from metric collection to alarm triggering. For cloud platform administrators, the most important operation and maintenance requirement is receiving platform alerts, and the most flexible notification method for receiving alerts is webhooks. This method allows users to send alert information to a custom http endpoint, which can be used to integrate various third-party systems or custom services, such as an enterprise's internal alarm platform, automated operations and maintenance tools, or other notification systems.

[0003] However, as cloud platforms scale and user needs diversify, traditional solutions are gradually exposing the following issues: Traditional static configuration methods require manual modification of the AlertManager configuration file, which cannot meet users' personalized needs for webhook notifications. Furthermore, the modification process involves restarting the service, resulting in configuration fragmentation, cumbersome operations, and impacts on alert continuity. Therefore, how to address the rigid configuration, poor isolation, and unreliable dynamic updates of traditional solutions is a challenge currently faced by those skilled in the art. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a cloud platform alarm notification configuration method, device, equipment and medium, which can realize the centralized management of different alarm notification requirements of different personnel on the cloud platform, and ensure the continuity and reliability of the alarm notification function. The specific scheme is as follows:

[0005] In a first aspect, the present application discloses a cloud platform alarm notification configuration method, comprising:

[0006] Define a custom resource definition for the alarm notification configuration in the Kubernetes cluster, and based on the custom resource definition, create a custom resource instance for the alarm notification configuration according to user needs;

[0007] Using the configuration management center component preset in the cloud platform, the custom resource instance generates a global alarm notification configuration in the ConfigMap format in the Kubernetes cluster;

[0008] Mount the global alarm notification configuration to the first container of the alarm notification component provided by the Kubernetes cluster to load the global alarm notification configuration, and monitor the global alarm notification configuration using the second container newly added to the Pod of the alarm notification component;

[0009] When the global alarm notification configuration changes, the configuration hot reloading interface of the alarm notification component is called through the second container to dynamically update the global alarm notification configuration and reload the updated global alarm notification configuration.

[0010] Optionally, defining a custom resource definition for the alarm notification configuration in the Kubernetes cluster, and creating a custom resource instance for the alarm notification configuration based on the custom resource definition and user needs, includes:

[0011] Define custom resource definitions for alarm notification configuration in the Kubernetes cluster to create an alarm notification configuration resource model;

[0012] According to the user's needs, the basic configuration information in the alarm notification configuration resource model is filled with the default configuration or the custom configuration to create a custom resource instance of the alarm notification configuration; wherein the basic configuration information includes the alarm group, the alarm route, the target notification object and the webhook type address.

[0013] Optionally, after creating the custom resource instance of the alarm notification configuration according to user needs, the method further includes:

[0014] Performing a connectivity check on the webhook type address using the configuration management center component, and determining whether the connectivity check passes;

[0015] If the connectivity check passes, the status field corresponding to the resource status of the alarm notification resource is filled in as a valid state, and the step of generating the global alarm notification configuration is triggered;

[0016] If the connectivity check fails, the status field is filled with an invalid state, and the description field corresponding to the resource status of the alarm notification resource is filled to record the error reason why the connectivity check fails.

[0017] Optionally, the cloud platform alarm notification configuration method further includes:

[0018] Deploy the Kube-state-metrics component in the Kubernetes cluster to obtain the resource status of the alarm notification resource in real time;

[0019] The Prometheus component provided by the Kubernetes cluster is used to collect the resource status and generate corresponding monitoring data so that the user can view the resource status based on the monitoring data or using the command line tool of the Kubernetes cluster.

[0020] Optionally, when the global alarm notification configuration changes, calling the configuration hot reload interface of the alarm notification component through the second container to dynamically update the global alarm notification configuration and reload the updated global alarm notification configuration, including:

[0021] When there is a configuration deletion and / or configuration modification event related to the basic configuration information in the global alarm notification configuration, the configuration hot reloading interface of the alarm notification component is called through the second container to re-trigger the step of generating the global alarm notification configuration, dynamically update the global alarm notification configuration, and reload the updated global alarm notification configuration.

[0022] Optionally, the cloud platform alarm notification configuration method further includes:

[0023] Based on a preset time interval, starting a scheduled refresh task through the configuration management center component;

[0024] Determine, based on the scheduled refresh task, a target resource configuration in the Kubernetes cluster that has passed the current connectivity check, and generate a simulated alarm notification configuration based on the target resource configuration and the basic configuration information;

[0025] The simulated alarm notification configuration is compared with the global alarm notification configuration, and when it is detected that the simulated alarm notification configuration is inconsistent with the global alarm notification configuration, the global alarm notification configuration is replaced with the simulated alarm notification configuration.

[0026] Optionally, mounting the global alarm notification configuration onto a first container of the alarm notification component provided by the Kubernetes cluster to load the global alarm notification configuration, and using a second container added to the Pod of the alarm notification component to monitor the global alarm notification configuration includes:

[0027] Mount the global alert notification configuration to the first container of the AlertManager component to load the global alert notification configuration, and monitor the global alert notification configuration using the configmap-reload container newly added to the Pod of the alert notification component;

[0028] Accordingly, when the global alarm notification configuration changes, calling the configuration hot reload interface of the alarm notification component through the second container includes:

[0029] When the global alarm notification configuration changes, the reload interface of the AlertManager component is called through the configmap-reload container.

[0030] In a second aspect, the present application discloses a cloud platform alarm notification configuration device, comprising:

[0031] A custom resource management module is used to define custom resource definitions for alarm notification configurations in the Kubernetes cluster and, based on the custom resource definitions, create custom resource instances for the alarm notification configurations according to user needs;

[0032] A global configuration generation module is used to generate a global alarm notification configuration in the ConfigMap format in the Kubernetes cluster from the custom resource instance using a configuration management center component preset in the cloud platform;

[0033] A first configuration loading module, configured to mount the global alarm notification configuration onto a first container of the alarm notification component provided by the Kubernetes cluster to load the global alarm notification configuration;

[0034] A monitoring module, configured to monitor the global alarm notification configuration using a second container added to the Pod of the alarm notification component;

[0035] The second configuration loading module is used to call the configuration hot loading interface of the alarm notification component through the second container when the global alarm notification configuration changes, so as to dynamically update the global alarm notification configuration and reload the updated global alarm notification configuration.

[0036] In a third aspect, the present application discloses an electronic device comprising a processor and a memory; wherein the memory is used to store a computer program, and the computer program is loaded and executed by the processor to implement the cloud platform alarm notification configuration method as described above.

[0037] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein the computer program, when executed by a processor, implements the cloud platform alarm notification configuration method as described above.

[0038] The present application provides a cloud platform alarm notification configuration method, including: defining a custom resource definition of the alarm notification configuration in a Kubernetes cluster, and creating a custom resource instance of the alarm notification configuration according to user needs based on the custom resource definition; using a configuration management center component preset in the cloud platform to generate a global alarm notification configuration in the ConfigMap format in the Kubernetes cluster from the custom resource instance; mounting the global alarm notification configuration on a first container of the alarm notification component provided by the Kubernetes cluster to load the global alarm notification configuration, and using a second container newly added in the Pod of the alarm notification component to monitor the global alarm notification configuration; when the global alarm notification configuration changes, calling the configuration hot loading interface of the alarm notification component through the second container to dynamically update the global alarm notification configuration, and reloading the updated global alarm notification configuration.

[0039] The beneficial effects of this application are as follows: Utilizing the custom resource definition feature of Kubernetes, users can define configuration resources in different formats based on their own alarm notification needs and obtain corresponding custom resource instances. The cloud platform provides a unified configuration management center component that generates a global alarm notification configuration in ConfigMap format from the custom resource instance and mounts it to the first container of the alarm notification component. Simultaneously, the alarm notification component Pod adds a second container based on the first container to monitor the global alarm notification configuration in ConfigMap format. When the global alarm notification configuration changes, the alarm notification component's configuration hot reload interface is called to trigger the reloading of the configuration. As can be seen, users can freely choose their alarm notification configuration, truly achieving centralized management of the different alarm notification needs of different personnel on the cloud platform. Multi-user configurations are isolated through custom resource instances, making them unaware of other users' use, ensuring the isolation and security of the alarm notification configuration. The configuration management center component automatically completes dynamic loading of the alarm notification configuration, ensuring the continuity and reliability of the alarm notification function, thereby achieving the stability of the cloud platform's monitoring and alarm management.

[0040] In addition, the cloud platform alarm notification configuration device, equipment and storage medium provided in this application correspond to the above-mentioned cloud platform alarm notification configuration method and have the same effect as above. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0042] Figure 1 This is a flow chart of a cloud platform alarm notification configuration method disclosed in this application;

[0043] Figure 2 This is an example diagram of the basic configuration of AlertManager disclosed in this application;

[0044] Figure 3 This is an example diagram of a default type of alarm notification configuration disclosed in this application;

[0045] Figure 4 This is an example diagram of a custom alarm notification configuration disclosed in this application;

[0046] Figure 5 A schematic diagram of a dynamic loading process for an alarm notification configuration disclosed in this application;

[0047] Figure 6 This is a schematic diagram of the structure of a cloud platform alarm notification configuration device disclosed in this application;

[0048] Figure 7 This is a structural diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION

[0049] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. 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 making creative efforts are within the scope of protection of the present invention.

[0050] Kubernetes technology provides a powerful and highly automated platform for cloud computing, which can be used to deploy, manage, and scale applications in cloud-native environments. Traditional cloud platform monitoring and alerting solutions are usually based on the Prometheus and AlertManager architecture: Prometheus is an open source monitoring and alerting tool that combines automatic discovery technology with the ability to monitor applications running on Kubernetes clusters. It is responsible for collecting metrics data for applications, nodes, and components in Kubernetes clusters; AlertManager is responsible for processing alerts triggered by Prometheus and managing the entire lifecycle of these alerts, including grouping, suppression, silencing, and sending notifications. However, as cloud platforms expand in scale and user needs diversify, traditional solutions have gradually exposed the following problems:

[0051] 1. Static Alert Notification Configuration: Traditional AlertManager's alert notification configuration (such as webhook addresses and notification templates) is typically managed through static configuration files. To modify notification targets (such as adding an internal alert platform) or adjust notification policies, users must manually edit the configuration file and restart AlertManager, which is complex and can easily lead to alert interruption.

[0052] 2. Insufficient isolation of user-defined configurations: Cloud platforms typically need to support multi-user sharing, but traditional solutions cannot achieve user-level configuration isolation. If multiple users require customized webhook notifications, manual coordination and configuration are required, which can easily lead to configuration conflicts or sensitive information leakage.

[0053] 3. Low reliability and efficiency of dynamic loading: Traditional solutions often rely on unified templates or fixed notification rules, making it difficult to dynamically load and securely isolate user configurations. Even some solutions attempt to dynamically update AlertManager configurations through APIs, but they still face challenges such as complex configuration verification and confusing version management. Configuration errors can cause AlertManager to crash, impacting the continuity of global alerting functionality.

[0054] To this end, this application provides a cloud platform alarm notification configuration solution that can support flexible access of user-defined webhook terminals while ensuring the stability of the alarm service, truly realizing centralized management of different alarm notification needs of different personnel on the cloud platform, and ensuring the continuity and reliability of the alarm notification function.

[0055] The embodiment of the present invention discloses a cloud platform alarm notification configuration method, see Figure 1 As shown, taking the webhook type alarm notification resource as an example, the method includes:

[0056] Step S11: defining a custom resource definition for the alarm notification configuration in the Kubernetes cluster, and creating a custom resource instance for the alarm notification configuration based on the custom resource definition and user needs.

[0057] In the embodiment of the present application, the cloud platform is managed by Kubernetes clusters, and all components are deployed using Pods. Among them, the Kubernetes cluster provides an AlertManager component (alarm notification component) and is paired with a Prometheus component to implement the alarm notification capabilities of the environment.

[0058] In this embodiment, considering the cloud platform administrator's need to receive webhook-type alarm notifications, the Kubernetes Custom Resource Definition (CR) feature is leveraged to support user-defined alarm notification configurations, meeting their individual needs for alarm notification configuration. Specifically, by leveraging the Kubernetes CRD feature, a unified alarm notification configuration resource model, named MonitorAlertNotification (abbreviated as "man," is defined). Users can then use custom resource instances (CRs) to manage and implement alarm notification configurations for target notification objects as needed.

[0059] It should be noted that after the alarm notification configuration resource model is defined, the resource definition initialization is completed. The scope is at the namespace level. The conf part of the spec defines the configuration content. The description field (description) and the state field (state) of the resource status are waiting to be filled in by the subsequent configuration center. The webhook type address is empty and waits for subsequent filling in by the configuration center.

[0060] The AlertManager component first initializes an empty ConfigMap configuration file named alertmanager-config to store the global configuration generated by the Configuration Management Center component. This configuration is then mounted into the AlertManager component container for final configuration loading.

[0061] In this embodiment, the AlertManager component extracts basic configuration information based on user needs. This information is used to configure webhook-type alert notification resources. This basic configuration information includes alert groups, alert routes, target notification objects, and webhook type addresses. This configuration is stored by initializing a ConfigMap format, named alertmanager-base.

[0062] Among them, alarm grouping is to merge alarms that are triggered in the same time period and have similar characteristics into one notification group, which can avoid repeatedly sending a large number of similar alarms; for example: if 10 Pods in a Kubernetes cluster trigger an alarm due to insufficient resources at the same time, Alertmanager will merge them into one notification: "10 Pods in cluster A have insufficient resources." Alarm routing usually determines to which notification object the alarm should be sent based on the alarm's label matching rules. The target notification object is the receiver (Receiver) that receives the alarm notification resource. The webhook type address can send the alarm notification resource to the specified URL endpoint through the HTTP protocol. Figure 2 The figure shows an example diagram of basic configuration information of an AlertManager component provided in this embodiment.

[0063] Since users are allowed to customize the alarm notification configuration individually, the embodiment of the present application supports two scenarios: users using the default configuration or personalized configuration. Ordinary users use the default configuration, and special users use customized configuration. The basic configuration information in the alarm notification configuration resource model is filled in to create a customized resource instance of the alarm notification configuration. Figure 3 The following is a schematic diagram of a custom resource instance generated using the default configuration. The spec field contains user-defined configuration information, which is used to describe how the user wants the resource to be presented. When using the default configuration, the spec conf only needs to configure the receiver default (default) and the webhook type address to add the URL of the target notification object; Figure 4 The following shows an example of a custom resource generated using a custom configuration. The conf file in the spec also requires configuring the alert routing section and adding a custom receiver. The name must not be "default." For the webhook type address, add the URL of the target notification object. Additionally, each configuration supports defining one or more webhook URLs for a single resource.

[0064] It can be seen that, on the one hand, ordinary users only need to configure the webhook type URL address of the target notification object based on the basic configuration information to achieve the default requirements; on the other hand, special users can refer to the basic configuration information and configure alarm grouping, alarm routing, and customized target notification objects to achieve customized requirements.

[0065] Step S12: Using the configuration management center component preset in the cloud platform, the custom resource instance is generated into a global alarm notification configuration in the ConfigMap format in the Kubernetes cluster.

[0066] In an embodiment of the present application, the cloud platform provides a unified configuration management center component, which integrates multiple functional modules, including a resource monitoring module, a resource inspection module, a configuration generation module, a timed refresh module, etc.

[0067] The resource monitoring module acquires declared alarm notification resources on the cloud platform in real time. The resource checking module performs connectivity checks on the resource's alarm notification configuration to confirm that the Alertmanager component is correctly connected to the target alarm notification object webhook address. The configuration generation module assembles the basic configuration information and the verified correct resource configuration into a global alarm notification configuration in ConfigMap format. The timed refresh module periodically checks the consistency of the global alarm notification configuration and the configured resources. The specific details will be detailed in the following invention embodiments and will not be repeated here.

[0068] Step S13: Mount the global alarm notification configuration to the first container of the alarm notification component provided by the Kubernetes cluster to load the global alarm notification configuration, and use the second container newly added in the Pod of the alarm notification component to monitor the global alarm notification configuration.

[0069] As can be seen from the preceding steps, the AlertManager component pre-initializes an empty configuration in ConfigMap format and mounts it to the AlertManager container. Therefore, the current global alert notification configuration is generated based on this and mounted to the AlertManager container for final configuration loading.

[0070] To enable dynamic loading, this embodiment adds a configmap-reload container to the AlertManager container in the AlertManager component Pod. This container monitors changes to the ConfigMap in real time and then notifies the AlertManager component to load. In one feasible implementation, the webhook-url address configured in the startup parameters of this container is the reload address supported by the local AlertManager component container, with a value of http: / / localhost:9093 / - / reload.

[0071] Step S14: When the global alarm notification configuration changes, the configuration hot reloading interface of the alarm notification component is called through the second container to dynamically update the global alarm notification configuration and reload the updated global alarm notification configuration.

[0072] In this embodiment, once a global configuration change is detected in real time via the configmap-reload container, the / reload API of the Alertmanager component is immediately called to trigger a configuration reload. This entire process does not require a Pod restart, ultimately enabling Alertmanager to dynamically load the global alert notification configuration. Each user can flexibly choose between the default configuration and a custom configuration based on their needs, and the configuration center automatically completes configuration checking and dynamic loading.

[0073] It should be noted that global alarm notification configuration change events include configuration deletion and / or configuration modification events related to the basic configuration information. For example, when a configuration resource is deleted, the resource monitoring module receives the deletion event, parses the configuration information, determines whether it is the default configuration or a custom configuration based on the content of the configuration information, skips the resource inspection module, and notifies the configuration generation module. When the basic configuration information is modified, the resource monitoring module receives the modification event, parses the configuration information, determines whether it is the default configuration or a custom configuration based on the content of the configuration information, skips the resource inspection module, and notifies the configuration generation module.

[0074] The present application provides a cloud platform alarm notification configuration method, including: defining a custom resource definition of the alarm notification configuration in a Kubernetes cluster, and creating a custom resource instance of the alarm notification configuration according to user needs based on the custom resource definition; using a configuration management center component preset in the cloud platform to generate a global alarm notification configuration in the ConfigMap format in the Kubernetes cluster from the custom resource instance; mounting the global alarm notification configuration on a first container of the alarm notification component provided by the Kubernetes cluster to load the global alarm notification configuration, and using a second container newly added in the Pod of the alarm notification component to monitor the global alarm notification configuration; when the global alarm notification configuration changes, calling the configuration hot loading interface of the alarm notification component through the second container to dynamically update the global alarm notification configuration, and reloading the updated global alarm notification configuration.

[0075] The beneficial effects of this application are as follows: Utilizing the custom resource definition feature of Kubernetes, users can define configuration resources in different formats based on their own alarm notification needs and obtain corresponding custom resource instances. The cloud platform provides a unified configuration management center component that generates a global alarm notification configuration in ConfigMap format from the custom resource instance and mounts it to the first container of the alarm notification component. Simultaneously, the alarm notification component Pod adds a second container based on the first container to monitor the global alarm notification configuration in ConfigMap format. When the global alarm notification configuration changes, the alarm notification component's configuration hot reload interface is called to trigger the reloading of the configuration. As can be seen, users can freely choose their alarm notification configuration, truly achieving centralized management of the different alarm notification needs of different personnel on the cloud platform. Multi-user configurations are isolated through custom resource instances, making them unaware of other users' use, ensuring the isolation and security of the alarm notification configuration. The configuration management center component automatically completes dynamic loading of the alarm notification configuration, ensuring the continuity and reliability of the alarm notification function, thereby achieving the stability of the cloud platform's monitoring and alarm management.

[0076] Based on the above embodiment, in a feasible implementation, in order to confirm the reachability of the target URL and ensure that the alarm notification resource can actually be delivered to the target notification object specified by the user, in the technical solution of dynamic loading configuration, it is a key link to ensure the reliability of the alarm function. After creating the custom resource instance of the alarm notification configuration according to user needs, the embodiment of this application can also include the following steps:

[0077] Performing a connectivity check on the webhook type address using the configuration management center component, and determining whether the connectivity check passes;

[0078] If the connectivity check passes, the status field corresponding to the resource status of the alarm notification resource is filled in as a valid state, and the step of generating the global alarm notification configuration is triggered;

[0079] If the connectivity check fails, the status field is filled with an invalid state, and the description field corresponding to the resource status of the alarm notification resource is filled to record the error reason why the connectivity check fails.

[0080] It should be pointed out that when there is an alarm notification of resource creation or modification, the resource monitoring module in the configuration management center component receives the creation or modification event, parses the configuration information, determines the default configuration or custom configuration based on the content in the configuration information, and notifies the resource inspection module of the URL of the configured webhook type address.

[0081] In this embodiment of the application, the resource check module in the configuration management center component is used to check the connectivity of the webhook type URL of the alarm notification resource. If the check passes, the state field of the resource status is filled with Valid (valid state), refer to Figure 4 For each resource configuration that passes the check, the default configuration adds the URL address to the receiver default, and the custom configuration adds the route and receiver simultaneously. Finally, the notification configuration generation module completes the loading, and loads all alarm notification resources to generate a global alarm notification configuration; if the check fails, the state field of the resource status is filled with InValid (invalid state), and the description field is filled with the reason for the failure. Figure 3 , used to report user failures in URL connectivity through content troubleshooting.

[0082] Furthermore, in a feasible implementation, other components can be supported to obtain monitoring of the resource or users can use the kubectl command to view the configuration validity of the configured resource and the reason for the loading failure. Specifically, the Kube-state-metrics component is deployed in the Kubernetes cluster to obtain the resource status of the alarm notification resource in real time; the Prometheus component provided by the Kubernetes cluster is used to collect the resource status and generate corresponding monitoring data, so that users can view the resource status based on the monitoring data or using the command line tool of the Kubernetes cluster.

[0083] As can be seen, deploying the Kube-state-metrics component in the Kubernetes cluster enables real-time monitoring of alarm notification resources. The Prometheus component can enhance the monitoring capabilities of the Kube-state-metrics component. Users can view the monitoring data of the resource or use the kubectl command to view the resource status, and promptly discover and troubleshoot resources that fail to be checked.

[0084] Based on the above embodiment, in a feasible implementation, the configuration management center component further includes a timed refresh module. Specifically, the following steps may be included:

[0085] Based on a preset time interval, starting a scheduled refresh task through the configuration management center component;

[0086] Determine, based on the scheduled refresh task, a target resource configuration in the Kubernetes cluster that has passed the current connectivity check, and generate a simulated alarm notification configuration based on the target resource configuration and the basic configuration information;

[0087] The simulated alarm notification configuration is compared with the global alarm notification configuration, and when it is detected that the simulated alarm notification configuration is inconsistent with the global alarm notification configuration, the global alarm notification configuration is replaced with the simulated alarm notification configuration.

[0088] Since the final global alarm notification configuration is managed in ConfigMap mode, it may be accidentally modified or deleted in the environment. In the embodiment of the present application, the consistency of the global configuration and the configuration resources is regularly checked by the timed refresh module in the configuration management center component.

[0089] The scheduled refresh module loads the target resource configuration that has passed the connectivity check based on the basic configuration information, generating the final simulated alarm notification configuration. Furthermore, it compares the simulated alarm notification configuration with the existing complete configuration, that is, the global alarm notification configuration. If there is any inconsistency, it is modified and the Alertmanager configuration is reloaded.

[0090] Further, such as Figure 5 The figure shows a schematic diagram of the process of dynamically loading alarm notification configuration provided in this embodiment. First, define the "template" (CRD) of the "alarm notification configuration". The CRD of Kubernetes allows users to customize a "resource type", and users submit configurations through "custom resources" (CR). The configuration management center component "listens" and verifies all CRs. It will "listen" to changes in the basic configuration information (creation or modification) of all CRs in the cluster. Whenever a user submits a CR, the configuration management center component will verify the legitimacy of the configuration, including connectivity checks, isolation of multi-user configurations, and filling in the fields corresponding to the basic configuration information. Furthermore, the configuration management center component assembles the basic configuration information and the resource configuration that has passed the check into a complete global alarm notification configuration, and stores it as Kubernetes' ConfigMap (a resource for storing configurations). At this time, the Alertmanager Pod will load the global alarm notification configuration by mounting the ConfigMap. To implement dynamic loading, a configmap-reload container is deployed in the Alertmanager Pod. It monitors changes in the ConfigMap in real time. Once the ConfigMap is updated (that is, the user modifies the alert configuration), configmap-reload immediately calls the / reload interface of Alertmanage to trigger it to reload the configuration.

[0091] Based on the above modifications, it helps platform personnel to choose the default configuration or customized configuration according to their own needs, which can not only meet the general needs of ordinary users, but also realize the customized needs of special users, and truly realize the centralized management of different alarm notification needs of different personnel on the cloud platform. Complete the configuration according to the alarm notification configuration resource format requirements, realize the connection between the configuration management center component and the alarm notification component, realize the separation of the alarm notification configuration and the component, and dynamically load the alarm notification configuration without affecting the operation of the alarm notification component. The configuration management center component detects any configuration changes in real time and realizes the automatic generation and dynamic loading of the global alarm notification configuration. At the same time, it regularly checks the consistency of the configuration resources and the global configuration to ensure that the configuration will not be tampered with, and ultimately realizes and guarantees the correct alarm notification needs of all users. This invention can reduce the cost of users learning the alarm notification component and reduce the risk of incorrect modification of the alarm notification configuration, thereby ensuring the continuity and reliability of the alarm notification function.

[0092] Correspondingly, the embodiment of the present application also discloses a cloud platform alarm notification configuration device, see Figure 6 As shown, the device includes:

[0093] A custom resource management module 11 is used to define custom resource definitions for alarm notification configurations in the Kubernetes cluster, and based on the custom resource definitions, create custom resource instances for the alarm notification configurations according to user needs;

[0094] A global configuration generation module 12 is configured to generate a global alarm notification configuration in the ConfigMap format in the Kubernetes cluster from the custom resource instance using a configuration management center component preset in the cloud platform;

[0095] A first configuration loading module 13 is used to mount the global alarm notification configuration to the first container of the alarm notification component provided by the Kubernetes cluster to load the global alarm notification configuration;

[0096] A monitoring module 14 is configured to monitor the global alarm notification configuration using a second container newly added to the Pod of the alarm notification component;

[0097] The second configuration loading module 15 is used to call the configuration hot loading interface of the alarm notification component through the second container when the global alarm notification configuration changes, so as to dynamically update the global alarm notification configuration and reload the updated global alarm notification configuration.

[0098] Among them, for more specific working processes of the above modules, please refer to the corresponding contents disclosed in the aforementioned embodiments, which will not be repeated here.

[0099] It can be seen that the above-mentioned scheme of this embodiment includes: defining a custom resource definition of the alarm notification configuration in the Kubernetes cluster, and creating a custom resource instance of the alarm notification configuration according to user needs based on the custom resource definition; using the configuration management center component preset in the cloud platform to generate a global alarm notification configuration in the ConfigMap format in the Kubernetes cluster from the custom resource instance; mounting the global alarm notification configuration on the first container of the alarm notification component provided by the Kubernetes cluster to load the global alarm notification configuration, and using the second container newly added in the Pod of the alarm notification component to monitor the global alarm notification configuration; when the global alarm notification configuration changes, calling the configuration hot loading interface of the alarm notification component through the second container to dynamically update the global alarm notification configuration, and reload the updated global alarm notification configuration.

[0100] The beneficial effects of this application are as follows: Utilizing the custom resource definition feature of Kubernetes, users can define configuration resources in different formats based on their own alarm notification needs and obtain corresponding custom resource instances. The cloud platform provides a unified configuration management center component that generates a global alarm notification configuration in ConfigMap format from the custom resource instance and mounts it to the first container of the alarm notification component. Simultaneously, the alarm notification component Pod adds a second container based on the first container to monitor the global alarm notification configuration in ConfigMap format. When the global alarm notification configuration changes, the alarm notification component's configuration hot reload interface is called to trigger the reloading of the configuration. As can be seen, users can freely choose their alarm notification configuration, truly achieving centralized management of the different alarm notification needs of different personnel on the cloud platform. Multi-user configurations are isolated through custom resource instances, making them unaware of other users' use, ensuring the isolation and security of the alarm notification configuration. The configuration management center component automatically completes dynamic loading of the alarm notification configuration, ensuring the continuity and reliability of the alarm notification function, thereby achieving the stability of the cloud platform's monitoring and alarm management.

[0101] Furthermore, the embodiment of the present application also discloses an electronic device, Figure 7 This is a structural diagram of an electronic device 20 according to an exemplary embodiment, and the content in the diagram cannot be considered as any limitation to the scope of use of the present application.

[0102] Figure 7This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the cloud platform alarm notification configuration method disclosed in any of the aforementioned embodiments. In addition, the electronic device 20 in this embodiment may specifically be a computer.

[0103] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device. The communication protocol it follows is any communication protocol that can be applied to the technical solution of this application and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world. Its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0104] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, a magnetic disk, or an optical disk. The resources stored thereon may include an operating system 221, a computer program 222, and data 223. The data 223 may include various data. The storage method can be temporary storage or permanent storage.

[0105] The operating system 221 is used to manage and control the hardware devices on the electronic device 20 and the computer program 222, which can be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program that can be used to implement the cloud platform alarm notification configuration method executed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 222 can further include a computer program that can be used to perform other specific tasks.

[0106] Furthermore, the embodiments of the present application also disclose a computer-readable storage medium, where the computer-readable storage medium includes a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a magnetic disk or an optical disk, or any other form of storage medium known in the technical field. Wherein, when the computer program is executed by the processor, the aforementioned cloud platform alarm notification configuration method is implemented. For the specific steps of the method, reference can be made to the corresponding content disclosed in the aforementioned embodiments, which will not be repeated here.

[0107] Furthermore, an embodiment of the present application also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements any one of the above-mentioned cloud platform alarm notification configuration methods.

[0108] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from the other embodiments. Reference can be made to the descriptions of the identical or similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions of the methods.

[0109] The steps of the cloud platform alarm notification configuration method or algorithm described in conjunction with the embodiments disclosed herein can be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module can be stored in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0110] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0111] The above is a detailed introduction to the cloud platform alarm notification configuration method, device, equipment and medium provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core ideas. At the same time, for general technical personnel in this field, according to the ideas of the present invention, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.

Claims

1. A cloud platform alarm notification configuration method, characterized in that: include: Define a custom resource definition for the alarm notification configuration in the Kubernetes cluster, and based on the custom resource definition, create a custom resource instance for the alarm notification configuration according to user needs; Using the configuration management center component preset in the cloud platform, the custom resource instance generates a global alarm notification configuration in the ConfigMap format in the Kubernetes cluster; Mount the global alarm notification configuration to the first container of the alarm notification component provided by the Kubernetes cluster to load the global alarm notification configuration, and monitor the global alarm notification configuration using the second container newly added to the Pod of the alarm notification component; When the global alarm notification configuration changes, the configuration hot reloading interface of the alarm notification component is called through the second container to dynamically update the global alarm notification configuration and reload the updated global alarm notification configuration.

2. The cloud platform alarm notification configuration method according to claim 1, characterized in that: Defining a custom resource definition for the alarm notification configuration in the Kubernetes cluster, and creating a custom resource instance for the alarm notification configuration based on the custom resource definition and user needs, includes: Define custom resource definitions for alarm notification configuration in the Kubernetes cluster to create an alarm notification configuration resource model; According to the user's needs, the basic configuration information in the alarm notification configuration resource model is filled with the default configuration or the custom configuration to create a custom resource instance of the alarm notification configuration; wherein the basic configuration information includes the alarm group, the alarm route, the target notification object and the webhook type address.

3. The cloud platform alarm notification configuration method according to claim 1, characterized in that: After creating the custom resource instance of the alarm notification configuration according to user needs, the method further includes: Performing a connectivity check on the webhook type address using the configuration management center component, and determining whether the connectivity check passes; If the connectivity check passes, the status field corresponding to the resource status of the alarm notification resource is filled in as a valid state, and the step of generating the global alarm notification configuration is triggered; If the connectivity check fails, the status field is filled with an invalid status, and the description field corresponding to the resource status of the alarm notification resource is filled to record the error reason why the connectivity check fails.

4. The cloud platform alarm notification configuration method according to claim 3, characterized in that: Also includes: Deploy the Kube-state-metrics component in the Kubernetes cluster to obtain the resource status of the alarm notification resource in real time; The Prometheus component provided by the Kubernetes cluster is used to collect the resource status and generate corresponding monitoring data so that the user can view the resource status based on the monitoring data or using the command line tool of the Kubernetes cluster.

5. The cloud platform alarm notification configuration method according to claim 2, characterized in that: When the global alarm notification configuration changes, calling the configuration hot reload interface of the alarm notification component through the second container to dynamically update the global alarm notification configuration and reload the updated global alarm notification configuration, including: When there is a configuration deletion and / or configuration modification event related to the basic configuration information in the global alarm notification configuration, the configuration hot reloading interface of the alarm notification component is called through the second container to re-trigger the step of generating the global alarm notification configuration, dynamically update the global alarm notification configuration, and reload the updated global alarm notification configuration.

6. The cloud platform alarm notification configuration method according to claim 2, characterized in that: Also includes: Based on a preset time interval, starting a scheduled refresh task through the configuration management center component; Determine, based on the scheduled refresh task, a target resource configuration in the Kubernetes cluster that has passed the current connectivity check, and generate a simulated alarm notification configuration based on the target resource configuration and the basic configuration information; The simulated alarm notification configuration is compared with the global alarm notification configuration, and when it is detected that the simulated alarm notification configuration is inconsistent with the global alarm notification configuration, the global alarm notification configuration is replaced with the simulated alarm notification configuration.

7. The cloud platform alarm notification configuration method according to any one of claims 1 to 6, characterized in that: Mounting the global alarm notification configuration on the first container of the alarm notification component provided by the Kubernetes cluster to load the global alarm notification configuration, and monitoring the global alarm notification configuration using a second container added to the Pod of the alarm notification component, includes: Mount the global alert notification configuration to the first container of the AlertManager component to load the global alert notification configuration, and monitor the global alert notification configuration using the configmap-reload container newly added to the Pod of the alert notification component; Accordingly, when the global alarm notification configuration changes, calling the configuration hot reload interface of the alarm notification component through the second container includes: When the global alarm notification configuration changes, the reload interface of the AlertManager component is called through the configmap-reload container.

8. A cloud platform alarm notification configuration device, characterized in that: include: A custom resource management module is used to define custom resource definitions for alarm notification configurations in the Kubernetes cluster and, based on the custom resource definitions, create custom resource instances for the alarm notification configurations according to user needs; A global configuration generation module is used to generate a global alarm notification configuration in the ConfigMap format in the Kubernetes cluster from the custom resource instance using a configuration management center component preset in the cloud platform; A first configuration loading module, configured to mount the global alarm notification configuration onto a first container of the alarm notification component provided by the Kubernetes cluster to load the global alarm notification configuration; A monitoring module, configured to monitor the global alarm notification configuration using a second container added to the Pod of the alarm notification component; The second configuration loading module is used to call the configuration hot loading interface of the alarm notification component through the second container when the global alarm notification configuration changes, so as to dynamically update the global alarm notification configuration and reload the updated global alarm notification configuration.

9. An electronic device, characterized in that: The electronic device includes a processor and a memory; wherein the memory is used to store a computer program, and the computer program is loaded and executed by the processor to implement the cloud platform alarm notification configuration method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that Used to store computer programs; wherein when the computer program is executed by the processor, the cloud platform alarm notification configuration method according to any one of claims 1 to 7 is implemented.

Images