Alarm message notification template processing method and computing device

Abstract

The embodiment of the invention provides an alarm message notification template processing method and computing equipment. The method is applied to a computer cluster, a monitoring component runs in the computer cluster, the monitoring component is used for managing a target alarm message notification template, and the method comprises the following steps: monitoring a configuration change event, and when it is monitored that the configuration change event indicates that an instance generated based on CRD is changed, generating a target alarm message notification template based on the configuration change event; executing a target operation on a target configuration file corresponding to the target alarm message notification template; and processing the target alarm message notification template based on the target operation, so that the target alarm message notification template becomes effective. By adopting the method, the CRD definition is introduced, and the alarm notification template is modeled into the native resource object, so that management and full-life-cycle automatic operation and maintenance of the target alarm message notification template are realized, dynamic updating can be realized without manual intervention, and the configuration efficiency of the alarm service is remarkably improved.

Description

Technical Field

[0001] This application relates to the field of operation and maintenance management technology, and in particular to a method for processing alarm message notification templates and a computing device. Background Technology

[0002] To ensure the stability of Kubernetes (K8s) clusters and the services running on them, monitoring systems need to generate alerts. The triggering of these alerts relies on pre-configured alert templates. In actual operation and maintenance, changes in business scenarios or adjustments to notification policies often require a series of operations on the alert templates. However, current technologies typically require manual management of template configurations: operations personnel must log into the system, manually write or copy template content line by line, and manually perform a series of operations such as file writing, mounting configuration volumes, and restarting container groups. This process is cumbersome, relies on manual intervention, and severely impacts the efficiency of alert service processing. Summary of the Invention

[0003] This application provides an alarm message notification template processing method and computing device. By introducing CRD definition, the alarm notification template is modeled as a native resource object, thereby realizing the management and full life cycle automation of the target alarm message notification template. The alarm template can be dynamically updated without manual intervention, which significantly improves the configuration efficiency of alarm services.

[0004] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: In a first aspect, embodiments of this application provide a method for processing alarm message notification templates, used in a computer cluster. The computer cluster runs a monitoring component that manages target alarm message notification templates. The method includes: listening for configuration change events triggered by a user-submitted declarative configuration file; the declarative configuration file is an instance generated for a defined custom resource CRD, used to define the target alarm message notification template; the CRD is a pre-set structured alarm template used to constrain the format and content of the target alarm message notification template; when a configuration change event is detected indicating a change in the instance generated based on the CRD, a target operation is performed on the target configuration file corresponding to the target alarm message notification template based on the configuration change event; the target operation reflects lifecycle changes to the target alarm message notification template; the target configuration file is runtime configuration data upon which the alarm message generation logic depends; and processing the target alarm message notification template based on the target operation to make the target alarm message notification template effective.

[0005] Based on this solution, in a computer cluster environment, a new custom resource definition is defined to carry alarm message notification templates. The template content is abstracted into declarative resource objects that conform to the platform's native semantics, and the monitoring component listens for configuration change events to achieve automated management of the template's entire lifecycle. In this way, by introducing a CRD mechanism, alarm message notification templates are modeled as native resource objects, thereby achieving automated management and full lifecycle operation and maintenance of target alarm message notification templates. Dynamic updates are possible without manual intervention, significantly improving the configuration efficiency of the alarm service.

[0006] In one possible implementation, based on a configuration change event, a target operation is performed on the target configuration file corresponding to the target alarm message notification template, including: determining the target operation based on the configuration change event; if the target operation is a creation operation, extracting the format content of the target alarm message notification template from the target alarm message notification template; and generating the target configuration file corresponding to the target alarm message notification template based on the format content of the target alarm message notification template.

[0007] Based on this solution, by listening for configuration change events, the system identifies instances created based on CRDs and responds accordingly, automatically generating the runtime configuration file corresponding to the target alarm template, i.e., the target configuration file. This allows for automatic identification of template creation requests and triggering of the configuration file generation process, enabling alarm policy deployment without manual intervention. This effectively reduces operational complexity, shortens the effective cycle of target alarm message notification templates, and significantly improves the configuration efficiency of the alarm service.

[0008] In another possible implementation, based on the configuration change event, a target operation is performed on the target configuration file corresponding to the target alarm message notification template, including: determining the target operation based on the configuration change event; if the target operation is a modification operation, extracting the format content of the target alarm message notification template from the target alarm message notification template; and modifying the target configuration file corresponding to the target alarm message notification template based on the format content of the target alarm message notification template.

[0009] Based on this solution, by listening for configuration change events, it identifies instances modified based on CRDs, determines the corresponding modification operations, and responds to the modification events by automatically modifying the runtime configuration file corresponding to the target alarm template, i.e., the target configuration file. This allows for automatic identification of template modification requests and triggering of the configuration file modification process, enabling alarm policy deployment without manual intervention. This effectively reduces operational complexity, shortens the effective cycle of target alarm message notification templates, and significantly improves the configuration efficiency of the alarm service.

[0010] In another possible implementation, based on the configuration change event, a target operation is performed on the target configuration file corresponding to the target alarm message notification template, including: determining the target operation based on the configuration change event; and deleting the target configuration file corresponding to the target alarm message notification template if the target operation is a deletion operation.

[0011] Based on this solution, by listening for configuration change events, it identifies instances generated based on CRDs that have undergone deletion operations. Based on this, it determines the corresponding deletion operation, responds to the deletion event, and automatically deletes the runtime configuration file corresponding to the target alarm template, i.e., the target configuration file. This allows for automatic identification of template deletion requests and triggering of the configuration file deletion process, completing the deployment of alarm policies without manual intervention. This effectively reduces operational complexity, shortens the effective cycle of target alarm message notification templates, and significantly improves the configuration efficiency of the alarm service.

[0012] In another possible implementation, the target alarm message notification template is processed based on the target operation, including: mounting the target configuration file to the target path of the alarm management container; and calling the configuration reload component for hot update, so that the alarm management container reloads the target alarm message notification template from the mounted target configuration file.

[0013] Based on this solution, by injecting the updated target configuration file into the alarm management container via mounting, and by triggering the template loading without restart through the configuration reload mechanism, the alarm policy can be smoothly updated and take effect in real time, avoiding service interruption and the rebuilding of configuration reload components, thus significantly improving the configuration efficiency of the alarm service.

[0014] In another possible implementation, based on target operations, the target alarm message notification template is processed, including: deleting the target configuration file mounted on the target path of the alarm management container; and calling the configuration reload component for hot update.

[0015] Based on this solution, by deleting the runtime configuration file and triggering configuration reload, the alarm message notification template can be dynamically taken offline. This enables smooth updates and real-time effects of alarm policies, avoids service interruptions and the rebuilding of configuration reload components, and significantly improves the configuration efficiency of the alarm service.

[0016] In another possible implementation, listening for configuration change events includes: creating a corresponding target alarm message notification template based on the user-submitted declarative configuration file; generating a configuration change event when the corresponding target alarm message notification template is created; and listening for configuration change events.

[0017] Based on this solution, by automatically converting user-submitted declarative configurations into platform native resource instances, and having the system automatically generate and listen for configuration change events, the system achieves automated perception and response to target alarm message notification templates, significantly improving the configuration efficiency of alarm services.

[0018] In another possible implementation, before listening for configuration change events, the method further includes: defining a CRD for an alarm template and deploying the CRD to a computer cluster; defining a resource monitor in the monitoring component for listening to the target alarm message notification template and an event handler for processing the target alarm message notification template; the event handler includes a new resource handler, a modified resource handler, and a deleted resource handler; and deploying the resource monitor and the new, modified, and deleted resource handlers to the computer cluster.

[0019] Based on this solution, by pre-defining and registering the alarm template resource model and its event handling mechanism based on CRD, an infrastructure for declarative configuration and automated operation and maintenance is built. This enables the system to dynamically detect template changes and perform operations such as creation, update, and deletion without manual intervention, significantly improving the configuration efficiency of alarm services.

[0020] In another possible implementation, when the configuration change event indicates a change in the instance generated based on the CRD, the monitoring module, upon detecting the configuration change event, performs a target operation on the target configuration file corresponding to the target alarm message notification template. This includes: the monitoring module writing the target alarm message notification template into an incremental first-in-first-out queue; the processing module retrieving the target alarm message notification template from the incremental first-in-first-out queue; the processing module determining the target operation corresponding to the target alarm message notification template based on the target alarm message notification template; the processing module sending the target operation to the target processor; and the target processor performing the target operation on the target configuration file corresponding to the target alarm message notification template.

[0021] Based on this solution, a layered asynchronous architecture is constructed using a monitoring module, a processing module, and a target processor to achieve efficient processing of alarm template change events. Specifically, the monitoring module listens for configuration changes and writes them to an event queue; the processing module retrieves instances from the queue, parses the event type, and determines the target operation; the target processor executes the corresponding configuration file generation, update, or deletion operation. This enables asynchronous and queued processing of alarm message notifications for template change events, avoiding event loss or processing blockage in high-concurrency scenarios and significantly improving the configuration efficiency of the alarm service.

[0022] Secondly, this application also provides an alarm message notification template processing system. This system includes a listening component and an alarm management container. The listening component includes a monitoring module and a processing module. The monitoring module listens for configuration change events, which are triggered by user-submitted declarative configuration files. The declarative configuration file is an instance generated from a defined custom resource definition (CRD) and is used to define the target alarm message notification template. The CRD is a pre-set structured alarm template used to constrain the format and content of the target alarm message notification template. The processing module, upon detecting a configuration change event indicating a change in the instance generated based on the CRD, performs a target operation on the target configuration file corresponding to the target alarm message notification template based on the configuration change event. The target operation reflects the lifecycle changes of the target alarm message notification template. The target configuration file is the runtime configuration data upon which the alarm message generation logic depends. The alarm management container processes the target alarm message notification template based on the target operation, making the target alarm message notification template effective.

[0023] In one possible implementation, the listening component further includes a new resource processor and a processing module, specifically used to determine the target operation based on the configuration change event; the new resource processor is used to extract the format content of the target alarm message notification template from the target alarm message notification template when the target operation is a creation operation; the new resource processor is also used to create the target configuration file corresponding to the target alarm message notification template based on the format content of the target alarm message notification template.

[0024] In one possible implementation, the listening component further includes a modification resource processor and a processing module, specifically used to determine the target operation based on the configuration change event; the modification resource processor is used to extract the format content of the target alarm message notification template from the target alarm message notification template when the target operation is a modification operation; and to modify the target configuration file corresponding to the target alarm message notification template based on the format content of the target alarm message notification template.

[0025] In one possible implementation, the listening component further includes a delete resource handler and a processing module, specifically used to determine the target operation based on the configuration change event; the delete resource handler is used to delete the target configuration file corresponding to the target alarm message notification template when the target operation is a delete operation.

[0026] In one possible implementation, the listening module is specifically used to create a corresponding target alarm message notification template based on the declarative configuration file submitted by the user; when the corresponding target alarm message notification template is created, a configuration change event is generated; and the configuration change event is listened to.

[0027] In one possible implementation, a component is defined for defining the CRD of an alarm template, and the CRD is deployed to a computer cluster; a resource monitor for listening to target alarm message notification templates and an event handler for processing the target alarm message notification templates are defined in the monitoring component; the event handlers include a new resource handler, a modified resource handler, and a deleted resource handler; the resource monitor and the new, modified, and deleted resource handlers are deployed to the computer cluster.

[0028] Thirdly, embodiments of this application also provide a computing device, including: a processor and a memory; the processor and the memory are coupled; the memory is used to store program instructions; the processor is used to execute the program instructions to perform the method as described in any of the first aspects above.

[0029] Fourthly, embodiments of this application provide a chip for performing the methods described in any of the first aspects above.

[0030] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, implement the method as described in any of the first aspects.

[0031] In a sixth aspect, embodiments of this application provide a program product including a computer program that, when executed by a processor, implements the method as described in any of the first aspects. Attached Figure Description

[0032] Figure 1 This is a schematic diagram of a computer cluster scenario provided by an embodiment of this application; Figure 2 This is the first structural schematic diagram of an alarm message notification template processing method provided in this application embodiment; Figure 3 This is a first flowchart illustrating an alarm message notification template processing method provided in this application embodiment; Figure 4 This is a second flowchart illustrating an alarm message notification template processing method provided in an embodiment of this application; Figure 5 This is the first interactive schematic diagram of an alarm message notification template processing method provided in this application embodiment; Figure 6 This is a third flowchart illustrating an alarm message notification template processing method provided in an embodiment of this application; Figure 7 This is the second interactive schematic diagram of an alarm message notification template processing method provided in an embodiment of this application; Figure 8This is a fourth flowchart illustrating an alarm message notification template processing method provided in this application embodiment; Figure 9 This is the third interactive schematic diagram of an alarm message notification template processing method provided in this application embodiment; Figure 10 This is the fifth flowchart of an alarm message notification template processing method provided in this application embodiment; Figure 11 This is the sixth flowchart of an alarm message notification template processing method provided in this application embodiment; Figure 12 This is a schematic diagram of an alarm message notification template processing system provided in an embodiment of this application; Figure 13 This is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0033] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. To facilitate a clear description of the technical solutions of the embodiments of this application, the use of terms such as "first," "second," etc., in the embodiments of this application is for illustrative purposes and to distinguish the objects being described. There is no particular order between them, nor does it indicate a specific limitation on the number of devices in the embodiments of this application, and they do not constitute any limitation on the embodiments of this application.

[0034] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of this application.

[0035] It should be noted that many specific details are set forth in the following description in order to provide a full understanding of this application. However, this application may also be implemented in other ways different from those described herein. Therefore, the scope of protection of this application is not limited to the specific embodiments disclosed below.

[0036] The following explanations of the technical terms mentioned in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0037] A computer cluster, also known as a Kubernetes cluster, refers to a distributed computing environment in which the Kubernetes system has been deployed and is running. Kubernetes does not directly manage individual containers, but uses Pods as its smallest unit of scheduling and management. Each Pod can contain one or more closely related containers that share network and storage resources.

[0038] A Pod is the smallest deployable and manageable unit in Kubernetes, representing a running process or a group of containers working together in a cluster. Each Pod encapsulates one or more containers that share network, storage, and resources, and is scheduled and managed as a whole throughout its lifecycle.

[0039] Custom resource definitions (CDRs) are a core mechanism in Kubernetes used to extend APIs. Based on this, users can define new resource types to support resource management for specific application scenarios or business needs. In this embodiment, a CDR is defined to declare the resource model of the alarm message notification template, abstracting the template content into a declarative resource object that conforms to Kubernetes' native semantics, thus achieving standardized template definition, versioned management, and automated control.

[0040] A custom resource definition instance (CR) is a specific resource object created based on a custom resource definition (CRD). In this embodiment, the custom resource instance represents the specific configuration content of a user-submitted alarm message notification template, corresponding to lifecycle operations such as template creation, updating, or deletion, and serves as the runtime carrier of declarative configuration.

[0041] A container is an isolated runtime environment based on operating system-level virtualization. It provides applications with independent file systems, networks, process spaces, and resource views through technologies such as namespaces, cgroups, and file system isolation.

[0042] The Prometheus Operator is a controller extension component on the Kubernetes platform used to simplify the deployment and management of Prometheus monitoring systems. This component introduces declarative resource types through a custom resource definition mechanism, enabling automated management of monitoring instances, data collection configurations, alarm rules, and notification policies. In this embodiment, the Prometheus Operator, as the monitoring component, is responsible for listening for changes to alarm message notification templates and driving dynamic updates to related configurations.

[0043] The embodiments of this application will now be described with reference to the accompanying drawings.

[0044] Figure 1 This is a schematic diagram of a computer cluster scenario provided by an embodiment of this application.

[0045] like Figure 1 As shown, a computer cluster can include multiple nodes, including at least one master node (01) and multiple worker nodes (02). Master node 01 runs the cluster control plane components, including the API server, scheduler, and controller manager, and is responsible for the overall management and resource scheduling of the cluster. Worker nodes 02 host the actual workloads, deploying container runtime environments, Kubelet agents, and network plugins, and are used to create and manage Pod instances. Through the collaborative work of master node 01 and worker nodes 02, the entire cluster can flexibly and efficiently respond to various business needs and service deployment requirements.

[0046] To ensure the stability and reliability of the computer cluster and its supported services, a monitoring system is essential for real-time monitoring of the cluster's status and for generating corresponding alarm messages when anomalies are detected. However, in actual business operations, the types and quantities of alarm messages generated by the system are numerous and varied. If each alarm requires manual writing of notification content, response efficiency will be severely hampered. Therefore, it is typically necessary to generate standardized alarm message notification templates based on high-frequency alarm scenarios to accelerate the automated generation and distribution of alarm information.

[0047] Based on this, this application provides a method for processing alarm message notification templates. This method is applied to a computer cluster, where a monitoring component runs. The monitoring component manages target alarm message notification templates. Specifically, it listens for configuration change events triggered by user-submitted declarative configuration files. The declarative configuration file is an instance generated from a predefined custom resource definition (CRD) used to define the target alarm message notification template. The CRD is a pre-set structured alarm template used to constrain the format and content of the target alarm message notification template. When a configuration change event indicates a change in the instance generated based on the CRD, a target operation is performed on the target configuration file corresponding to the target alarm message notification template based on the configuration change event. The target operation reflects the lifecycle changes of the target alarm message notification template. The target configuration file is the runtime configuration data upon which the alarm message generation logic depends. Based on the target operation, the target alarm message notification template is processed to make it effective.

[0048] In summary, by introducing CRD definitions, alarm notification templates are modeled as native resource objects, thereby enabling the management and full lifecycle automation of target alarm message notification templates. They can be dynamically updated without manual intervention, significantly improving the configuration efficiency of alarm services.

[0049] The following section, with reference to the accompanying diagram, explains the specific implementation process of the alarm message notification template processing method.

[0050] Figure 2 This is the first structural diagram of an alarm message notification template processing method provided in this application embodiment.

[0051] like Figure 2 As shown, this method is applied to a Kubernetes cluster. The Kubernetes cluster runs a definition component, a monitoring component, and an alarm management container. The monitoring component manages target alarm message notification templates and includes a monitoring module (Reflector), a processing module (Informer), an incremental first-in-first-out queue (delta FIFO), and multiple target processors, such as add resource processors, modify resource processors, and delete resource processors. Specifically, the monitoring module uses the Kubernetes API Server's Watch mechanism to listen for change events of the custom resource (CR) corresponding to the alarm message notification template and writes incremental records (Delta) containing the operation type (e.g., create, update, delete) and resource status to the incremental FIFO queue. The processing module reads these incremental records from the incremental FIFO queue and processes them sequentially to prevent event loss or out-of-order execution. The target processors include add resource processors, modify resource processors, and delete resource processors, which are used to respond to template creation, update, and deletion operations, respectively, and execute the corresponding configuration generation and distribution logic. In other words, through the collaborative work of the monitoring module, processing module, incremental first-in-first-out queue and target processor, asynchronous, orderly and reliable processing of alarm template change events is achieved, significantly improving the configuration efficiency of alarm services.

[0052] Based on the above architecture, combined with Figure 3 As shown, the method for processing alarm message notification templates is explained in detail.

[0053] Figure 3 This is the first flowchart of an alarm message notification template processing method provided in this application embodiment.

[0054] Based on the aforementioned system architecture consisting of definition components, monitoring components, and alarm management containers, this method achieves automated response to alarm template change events through a modular collaboration mechanism.

[0055] like Figure 3 As shown, the alarm message notification template processing method includes the following steps: S1: Define a custom resource model and build a monitoring component, and register the custom resource model and the monitoring component to the Kubernetes cluster.

[0056] Figure 4 This is a second flowchart illustrating an alarm message notification template processing method provided in an embodiment of this application.

[0057] like Figure 4 As shown, step S1 includes steps S11-S13.

[0058] S11: Define the CRD for the alarm template and deploy the CRD to the computer cluster.

[0059] CDR (Custom Resource Description) is a mechanism in Kubernetes used to define new custom resource types. It registers new resource types with the cluster, enabling the cluster to recognize and manage user-defined objects without modifying the core Kubernetes code. This mechanism allows for the expansion of the types of resources supported by the cluster without changing the existing system architecture. The CDR is a pre-defined structured alert template used to constrain the format and content of target alert message notification templates. A CDR can include fields such as metadata, kind, and spec, used to describe the metadata and version of the custom resource.

[0060] For example, a CRD is defined and deployed to represent an alarm message notification template, for example, named AlertNotificationTemplate. The definition of this CRD includes resource metadata, resource name, naming convention, namespace scope (such as namespace level), supported versions, and resource structure verification rules.

[0061] S12: Define a resource monitor in the monitoring component for listening to target alarm message notification templates and a target processor for processing target alarm message notification templates.

[0062] The monitoring component, known as Prometheus Operator, is an open-source tool for simplifying and automating the deployment and management of Prometheus monitoring systems in Kubernetes environments. By introducing CRDs such as Prometheus, ServiceMonitor, PodMonitor, Alertmanager, and PrometheusRule, it enables declarative management of the monitoring system. It can automatically create Prometheus instances, dynamically generate crawl configurations, manage alert rules, and support scaling and rolling updates, thereby greatly simplifying the operation and maintenance of Prometheus and its related components (such as Alertmanager) in complex cloud-native environments.

[0063] The way to define the resource monitor for listening to target alarm message notification templates and the target processor for processing target alarm message notification templates in the monitoring component can be by extending the source code of the existing Prometheus Operator or by refactoring the source code of the original Prometheus Operator.

[0064] In one implementation, the existing Prometheus Operator source code can be extended to add a resource monitor for the CRD used to represent alarm message notification templates, along with corresponding target processing logic. This target processor includes a new resource processor for responding to resource creation, a modified resource processor for responding to resource updates, and a deleted resource processor for responding to resource deletion, thereby enabling monitoring and processing of the entire lifecycle of alarm message notification templates.

[0065] In another implementation, the Prometheus Operator source code is rebuilt, integrating the resource monitor and target processor for target alert message notification templates as built-in modules into the core logic of the Prometheus Operator, and recompiling to generate a new Operator image. By deploying this rebuilt instance, it automatically loads and runs the ability to listen for and process custom template resources upon startup.

[0066] S13: Deploy the resource monitor and add, modify, and delete resource processors to the computer cluster.

[0067] Specifically, a resource monitor that integrates the ability to listen for target alarm message notification templates, as well as the ability to add, modify, and delete resource processors, will be deployed to the Kubernetes cluster.

[0068] It should be noted that the deployment of the aforementioned custom resource definitions, resource monitors, and related target processors can be achieved by registering and deploying each component independently to the computer cluster, configuring and starting them as needed, or by integrating the CRD definitions, monitoring logic, and target processing modules into the Helm Chart package of the Prometheus Operator application and deploying them as a whole. No specific limitations are made here.

[0069] S2: Listen for configuration change events.

[0070] In one implementation, the combination continues. Figure 4 As shown, step S2 includes steps S21-S23.

[0071] S21: Based on the user-submitted declarative configuration file, create the corresponding target alarm message notification template.

[0072] Figure 5 This is the first interactive schematic diagram of an alarm message notification template processing method provided in this application embodiment.

[0073] like Figure 5 As shown, step S21 includes step S1001.

[0074] S1001: In response to a user-submitted declarative configuration file, create a corresponding target alarm message notification template.

[0075] The declarative configuration file is an instance (CR instance) generated from a predefined custom resource definition CRD, used to define target alarm message notification templates. The declarative configuration file can be written in YAML format, JSON format, or other structured data formats conforming to the Kubernetes resource object definition specification; no specific limitation is made here. Regardless of the specific format used, the file must conform to the API pattern specified by the predefined CRD to ensure correct parsing and instantiation.

[0076] For example, when a user submits a declarative configuration file A in YAML format, this configuration file A contains configuration information for creating a target alarm message notification template A1, such as the template name, its namespace, the template text for the notification content, and variable definitions. After the Prometheus Operator receives this configuration file through the Kubernetes API Server, it parses the field content and performs a validity check based on the predefined CRD structure. If the configuration is confirmed to conform to the resource data structure specification, a corresponding resource CR instance is generated, i.e., a custom resource object named "Target Alarm Message Notification Template A1" is created.

[0077] S22: If a corresponding target alarm message notification template is created, a configuration change event is generated.

[0078] like Figure 5 As shown, step S22 includes S1002.

[0079] S1002: When a corresponding target alarm message notification template is created, a resource configuration change event is automatically generated.

[0080] The configuration change event is of type "Add Event" and is used to mark the start of the lifecycle of this custom resource. This configuration change event carries the event type and the format of the target alarm message notification template. The format of the target alarm message notification template includes the resource object's metadata (such as name, namespace, resource version, etc.) and contextual information such as the operation timestamp.

[0081] Following the example above, if the corresponding target alarm message notification template A1 is created, a resource configuration change event A3 will be automatically generated.

[0082] S23: Listen for configuration change events.

[0083] like Figure 5 As shown, step S23 includes S1003.

[0084] S1003: Reflector continuously listens for configuration change events.

[0085] The Prometheus Operator's built-in resource monitor (Reflector) continuously listens to the event stream of AlertNotificationTemplate type resources.

[0086] For example, Reflector listens for configuration change event A3 (“Add” event).

[0087] S3: When a configuration change event is detected indicating that the instance generated based on the CRD has changed, the target operation is performed on the target configuration file corresponding to the target alarm message notification template based on the configuration change event.

[0088] Among them, the target operation is used to reflect the lifecycle changes of the target alarm message notification template. The target operation can include any one of the creation operation, modification operation and deletion operation.

[0089] The following example from this application demonstrates the creation process.

[0090] In one embodiment, the combination continues. Figure 4As shown, step S3 includes steps S31a-S31c.

[0091] S31a: Determine the target operation based on the configuration change event.

[0092] Continue to combine Figure 5 As shown, step S31a includes steps S1004-S1006.

[0093] S1004: When Reflector detects a configuration change event indicating that the instance generated based on the CRD has changed, it writes the configuration change event to the incremental first-in-first-out queue.

[0094] Continuing with the example above, when Reflector detects a configuration change event indicating that the instance generated based on the CRD has changed, it writes the configuration change event A3 into the incremental first-in-first-out queue.

[0095] S1005: Informer retrieves configuration change events from the incremental first-in-first-out queue.

[0096] Continuing with the example above, Informer retrieves configuration change event A3 from the incremental first-in-first-out queue.

[0097] S1006: Informer determines the target operation based on configuration change events.

[0098] Continuing with the example above, Informer determines the target operation as a creation operation based on the target alarm message notification template A1 in the configuration change event A3.

[0099] S31b: When the target operation is a creation operation, extract the format content of the target alarm message notification template from the target alarm message notification template.

[0100] Continue to combine Figure 5 As shown, step S31b includes steps S1007-S1008.

[0101] S1007: Informer sends a target alarm message notification template to newly added resource processors.

[0102] Continuing with the example above, Informer sends the target alarm message notification template A1 to the newly added resource handler.

[0103] S1008: Added resource processor to extract the format content of the target alarm message notification template from the target alarm message notification template.

[0104] Continuing with the example above, Informer extracts the formatted content of the target alarm message notification template A1, such as the template name, namespace, notification content template text, and variable definitions.

[0105] S31c: Based on the format and content of the target alarm message notification template, create the target configuration file corresponding to the target alarm message notification template.

[0106] Continue to combine Figure 5 As shown, step S31c includes step S1009.

[0107] S1009: Added resource processor to create target configuration files corresponding to the target alarm message notification template based on the format content of the target alarm message notification template.

[0108] The target configuration file contains the runtime configuration data upon which the alarm message generation logic depends.

[0109] Following the example above, the new resource processor will convert the extracted content into a template format that conforms to the Alertmanager recognition specifications and generate the corresponding runtime configuration file (such as notification-template-A1.tmpl).

[0110] S4: Based on the target operation, process the target alarm message notification template to make the target alarm message notification template effective.

[0111] Continue to combine Figure 4 As shown, step S4 includes steps S41-S42.

[0112] S41: Mount the target configuration file to the target path of the alarm management container.

[0113] Continue to combine Figure 5 As shown, step S41 includes step S1010.

[0114] S1010: The new resource processor mounts the target configuration file to the target path of the alarm management container.

[0115] Continuing with the example above, the new resource processor writes the formatted content to the path specified in the shared storage volume or configuration map (ConfigMap), which is the target path of the management container.

[0116] S42: Call the configuration reloader to perform hot updates, reloading the target alarm message notification template from the mounted target configuration file.

[0117] Continue to combine Figure 5 As shown, step S42 includes step S1011.

[0118] S1011: Call the configuration reloader to perform hot updates, reloading the target alarm message notification template from the mounted target configuration file.

[0119] The configuration reload component can be a tool like config-reloader, which has dynamic configuration awareness and reload capabilities. This component listens for changes in the directory containing the configuration file or receives external trigger signals to reread and load the mounted target configuration file without restarting the Pod or interrupting the alarm service. This enables uninterrupted, hot updates of alarm message notification templates. After the extracted template content is written to a shared storage volume or configuration map and persisted to a specified path, the system automatically triggers the alarm component's configuration reload mechanism.

[0120] Continuing with the example above, a reload request can be sent by calling the Reload API provided by the Prometheus Operator. After receiving the instruction, config-reloader will notify Alertmanager to re-parse its target configuration file and include the newly created or updated "Target Alarm Message Notification Template A1" in the runtime scope.

[0121] In summary, by introducing CRD definitions and modeling alarm notification templates as native resource objects, the addition of target alarm message notification templates and automated operation and maintenance throughout their entire lifecycle can be achieved. Alarm templates can be dynamically updated without manual intervention, significantly improving the configuration efficiency of alarm services.

[0122] Corresponding to the aforementioned embodiment of the alarm message notification template processing method, this application also provides another embodiment of the alarm message notification template processing method, which will be described below in conjunction with... Figure 6 An example of the method for processing the second alarm message notification template will be described.

[0123] Figure 6 This is a third flowchart illustrating an alarm message notification template processing method provided in this application embodiment.

[0124] like Figure 6 As shown, the alarm message notification template processing method includes the following steps: S01: Define a custom resource model and build a monitoring component, and register the custom resource model and the monitoring component to the Kubernetes cluster.

[0125] The details of step S01 can be found in step S1, and will not be repeated here.

[0126] S02: Listen for configuration change events.

[0127] Continue to combine Figure 6 As shown, step S02 includes steps S021-S023.

[0128] S021: Based on the user-submitted declarative configuration file, create the corresponding target alarm message notification template.

[0129] Figure 7 This is the second interactive schematic diagram of an alarm message notification template processing method provided in this application embodiment.

[0130] like Figure 7 As shown, step S021 includes S2001.

[0131] S2001: In response to a user-submitted declarative configuration file, create a corresponding target alarm message notification template.

[0132] The specific details of step S2001 can be found in step S1001, and will not be repeated here.

[0133] S022: If a corresponding target alarm message notification template is created, a configuration change event is generated.

[0134] like Figure 7 As shown, step S022 includes S2002.

[0135] S2002: When a corresponding target alarm message notification template is created, a resource configuration change event is automatically generated.

[0136] The configuration change event, classified as an "Update Event," marks the beginning of the lifecycle of this custom resource. This event carries the event type and the format of the target alarm message notification template. The target alarm message notification template includes metadata about the resource object (such as name, namespace, resource version, etc.) and contextual information such as the operation timestamp.

[0137] Following the example above, if a corresponding target alarm message notification template is created, a resource configuration change event A3' will be automatically generated.

[0138] S023: Listen for configuration change events.

[0139] like Figure 7 As shown, step S023 includes S2003.

[0140] S2003: Reflector continuously listens for configuration change events.

[0141] The specific details of step S2003 can be found in step S1003, and will not be repeated here.

[0142] Continuing with the example above, Reflector listens for configuration change event A3' ("Modify" event).

[0143] S03: When a configuration change event is detected indicating that the instance generated based on the CRD has changed, the target operation is performed on the target configuration file corresponding to the target alarm message notification template based on the configuration change event.

[0144] Continue to combine Figure 6 As shown, step S03 includes steps S32a-S32c.

[0145] S32a: Determine the target operation based on the configuration change event.

[0146] Continue to combine Figure 7 As shown, step S32a includes steps S2004-S2006.

[0147] S2004: When Reflector detects a configuration change event indicating that the instance generated based on the CRD has changed, it writes the configuration change event to the incremental first-in-first-out queue.

[0148] Continuing with the example above, when Reflector detects a configuration change event indicating that the instance generated based on the CRD has changed, it writes the configuration change event A3' into the incremental first-in-first-out queue.

[0149] S2005: Informer retrieves configuration change events from the incremental first-in-first-out queue.

[0150] Continuing with the example above, Informer retrieves the configuration change event A3' from the incremental first-in-first-out queue.

[0151] S2006: Informer determines the target operation based on configuration change events.

[0152] Continuing with the example above, Informer determines that the target operation is a modification operation based on the target alarm message notification template A1' in the configuration change event A3'.

[0153] S32b: When the target operation is a modification operation, extract the format content of the target alarm message notification template from the target alarm message notification template.

[0154] Continue to combine Figure 7 As shown, step S32b includes steps S2007-S2008.

[0155] S2007: Informer sends target alarm message notification templates to modified resource handlers.

[0156] Continuing with the example above, Informer sends the target alarm message notification template A1' to the modified resource handler.

[0157] S2008: Modify the format content of the target alarm message notification template extracted from the target alarm message notification template by the resource processor.

[0158] Continuing with the example above, Informer extracts the formatted content of the target alarm message notification template A1', such as the template name, namespace, notification content template text, and variable definitions.

[0159] S32c: Modify the target configuration file corresponding to the target alarm message notification template based on the format and content of the target alarm message notification template.

[0160] Continue to combine Figure 7 As shown, step S32b includes step S2009.

[0161] S2009: Modify the resource processor to modify the target configuration file corresponding to the target alarm message notification template based on the format content of the target alarm message notification template.

[0162] Following the example above, the new resource processor will convert the extracted content into a template format that conforms to the Alertmanager recognition specifications and modify the corresponding runtime configuration file (such as notification-template-A1.tmpl).

[0163] S04: Based on the target operation, process the target alarm message notification template to make the target alarm message notification template effective.

[0164] Continue to combine Figure 4 As shown, step S04 includes steps S041-S042.

[0165] S041: Mount the target configuration file to the target path of the alarm management container.

[0166] Continue to combine Figure 5 As shown, step S041 includes step S2010.

[0167] S2010: Modify the resource handler to mount the target configuration file to the target path of the alarm management container.

[0168] Continuing with the example above, modify the resource processor to write formatted content to the path specified in the shared storage volume or configuration map (ConfigMap), which is the target path of the management container.

[0169] S042: Call the configuration reloader to perform a hot update, reloading the target alarm message notification template from the mounted target configuration file.

[0170] Continue to combine Figure 7 As shown, step S042 includes step S2011.

[0171] S2011: Call the configuration reloader to perform hot updates, and reload the target alarm message notification template from the mounted target configuration file.

[0172] The specific content of step S2011 can be referred to the content of step S1011 above, and will not be repeated here.

[0173] In summary, by introducing CRD definitions, alarm notification templates are modeled as native resource objects, thereby enabling the modification of target alarm message notification templates and automated operation and maintenance throughout their entire lifecycle. Alarm templates can be dynamically updated without manual intervention, significantly improving the configuration efficiency of alarm services.

[0174] Corresponding to the aforementioned embodiment of the alarm message notification template processing method, this application also provides another embodiment of the alarm message notification template processing method, which will be described below in conjunction with... Figure 8 An example of the method for processing the third alarm message notification template will be described.

[0175] Figure 8 This is the fourth flowchart of an alarm message notification template processing method provided in this application embodiment.

[0176] like Figure 8 As shown, the alarm message notification template processing method includes the following steps: S001: Define a custom resource model and build a monitoring component, and register the custom resource model and build the monitoring component to the Kubernetes cluster.

[0177] The details of step S001 can be found in step S1, and will not be repeated here.

[0178] S002: Listen for configuration change events.

[0179] Continue to combine Figure 6 As shown, step S002 includes steps S0021-S0023.

[0180] S0021: Based on the user-submitted declarative configuration file, create the corresponding target alarm message notification template.

[0181] Figure 9 This is the third interactive schematic diagram of an alarm message notification template processing method provided in this application embodiment.

[0182] like Figure 9 As shown, step S0021 includes S3001.

[0183] S3001: In response to a user-submitted declarative configuration file, create a corresponding target alarm message notification template.

[0184] The specific details of step S3001 can be found in step S1001, and will not be repeated here.

[0185] S0022: When a corresponding target alarm message notification template is created, a configuration change event is generated.

[0186] like Figure 9 As shown, step S0022 includes step S3002.

[0187] S3002: When a corresponding target alarm message notification template is created, a resource configuration change event is automatically generated.

[0188] The configuration change event, classified as an "Update Event," marks the beginning of the custom resource's lifecycle. This event carries the event type and the format of the target alarm message notification template. The template includes metadata about the resource object (such as name, namespace, resource version, etc.) and contextual information such as the operation timestamp.

[0189] Following the example above, if a corresponding target alarm message notification template is created, a resource configuration change event A3' will be automatically generated.

[0190] S003: When a configuration change event is detected indicating that the instance generated based on the CRD has changed, the target operation is performed on the target configuration file corresponding to the target alarm message notification template based on the configuration change event.

[0191] Continue to combine Figure 8 As shown, step S003 includes steps S33a-S33b.

[0192] S33a: Determine the target operation based on the configuration change event.

[0193] Continue to combine Figure 9 As shown, step S33a includes steps S3004-S3006.

[0194] S3004: When Reflector detects a configuration change event indicating that the instance generated based on the CRD has changed, it writes the configuration change event to the incremental first-in-first-out queue.

[0195] Continuing with the example above, when Reflector detects a configuration change event indicating that the instance generated based on the CRD has changed, it writes the configuration change event A3'' to the incremental first-in-first-out queue.

[0196] S3005: Informer retrieves configuration change events from the incremental first-in-first-out queue.

[0197] Continuing with the example above, Informer retrieves the configuration change event A3' from the incremental first-in-first-out queue.

[0198] S3006: Informer determines the target operation based on configuration change events.

[0199] Continuing with the example above, Informer determines that the target operation is a deletion operation based on the target alarm message notification template A1 in the configuration change event A3' '.

[0200] S33b: When the target operation is a delete operation, delete the target configuration file corresponding to the target alarm message notification template.

[0201] Continue to combine Figure 9 As shown, step S32b includes steps S3007-S3008.

[0202] S3007: Informer sends a deletion target alert message to the deletion resource handler, notifying the target configuration file corresponding to the template.

[0203] S3008: Delete the resource processor and delete the target configuration file corresponding to the target alarm message notification template.

[0204] Continuing with the example above, the resource processor deletes the target configuration file, i.e., the runtime configuration file (such as notification-template-A1.tmpl).

[0205] S004: Based on the target operation, process the target alarm message notification template to make the target alarm message notification template effective.

[0206] Continue to combine Figure 8 As shown, step S004 includes steps S0041-S0042.

[0207] S0041: Delete the target configuration file mounted to the target path of the alarm management container.

[0208] Continue to combine Figure 9 As shown, step S0041 includes step S3009.

[0209] S3009: Remove resource handlers. Removes target configuration files mounted to the target path of the alarm management container.

[0210] Continuing with the example above, when the target operation is deletion, deleting the resource processor requires clearing the runtime configuration file corresponding to the template on the alerting component side. Specifically, locate the storage path (e.g., / etc / alertmanager / config / templates / ) where the target configuration file generated by the template is mounted in the alert management container group (e.g., Alertmanager Pod), and remove the configuration file (e.g., notification-template-A1.tmpl) corresponding to the template being deleted under that path.

[0211] S0042: Call the configuration overload component for hot update.

[0212] Continue to combine Figure 9 As shown, step S0042 includes step S3010.

[0213] S3010: Remove resource processors and call configuration reload components for hot updates.

[0214] Continuing with the example above, after the resource handler completes the file deletion operation, it further triggers the reload logic through the config-reloader in the container. Based on this triggering reload logic, it re-parses its configuration file and template directory, finds that the original template file no longer exists, and thus removes it from the runtime context.

[0215] In summary, by introducing CRD definitions, alarm notification templates are modeled as native resource objects, thereby enabling the deletion of target alarm message notification templates and automated operation and maintenance throughout their entire lifecycle. Alarm templates can be dynamically updated without manual intervention, significantly improving the configuration efficiency of alarm services.

[0216] Corresponding to the aforementioned embodiments of the alarm message notification template processing method, this application also provides a complete embodiment of alarm message notification template processing.

[0217] Figure 10 This is the fifth flowchart of an alarm message notification template processing method provided in this application embodiment.

[0218] like Figure 10 As shown, the alarm message notification template processing method includes the following steps: S101: Define a custom resource model and build monitoring components, and register the custom resource model and build monitoring components to the Kubernetes cluster.

[0219] Step S101 can refer to the specific content of step S1 above, and will not be repeated here.

[0220] S102: Listen for configuration change events.

[0221] S103: Determine whether a configuration change event has occurred.

[0222] S104: When a configuration change event is detected indicating that the instance generated based on the CRD has changed, the target operation is executed on the target configuration file corresponding to the target alarm message notification template based on the configuration change event.

[0223] S105: When the target operation is a creation operation, extract the format content of the target alarm message notification template from the target alarm message notification template.

[0224] S106: Modify the target configuration file corresponding to the target alarm message notification template based on the format content.

[0225] The specific details of steps S102-S106 can be found in steps S1001-S1010 above, and will not be repeated here.

[0226] S107: When the target operation is a modification operation, extract the format content of the target alarm message notification template from the target alarm message notification template.

[0227] S108: Based on the format content, modify the target configuration file corresponding to the target alarm message notification template.

[0228] The specific details of steps S107-S108 can be found in steps S2001-S2010 above, and will not be repeated here.

[0229] S109: If the target operation is a delete operation, delete the target configuration file corresponding to the target alarm message notification template.

[0230] The specific details of step S109 can be found in steps S3001-S3010 above, and will not be repeated here.

[0231] S110: Based on the target operation, process the target alarm message notification template to make the target alarm message notification template effective.

[0232] The specific content of step S110 can be referred to steps S4, S04, and S004 above, and will not be repeated here. In summary, by introducing CRD definitions, alarm notification templates are modeled as native resource objects, thereby realizing the management and full lifecycle automated operation and maintenance of target alarm message notification templates. Dynamic updates are possible without manual intervention, significantly improving the configuration efficiency of alarm services.

[0233] Corresponding to the aforementioned embodiments of alarm message notification template processing methods, this application also provides an embodiment of alarm message notification template processing.

[0234] Figure 11 This is the sixth flowchart of an alarm message notification template processing method provided in this application embodiment.

[0235] like Figure 11 As shown, the alarm message notification template processing method includes the following steps: S111: Listen for configuration change events.

[0236] Among them, the configuration change event is triggered by the declarative configuration file submitted by the user; the declarative configuration file is an instance generated for the defined custom resource definition CRD, which is used to define the target alarm message notification template; the CRD is a pre-set structured alarm template, which is used to constrain the format and content of the target alarm message notification template.

[0237] S112: When a configuration change event is detected indicating that the instance generated based on the CRD has changed, the target operation is performed on the target configuration file corresponding to the target alarm message notification template based on the configuration change event.

[0238] Among them, the target operation is used to reflect the lifecycle changes of the target alarm message notification template; the target configuration file is the runtime configuration data on which the alarm message generation logic depends.

[0239] S113: Based on the target operation, process the target alarm message notification template to make the target alarm message notification template effective.

[0240] The above methods also include: Before listening for configuration change events, define the CRD of the alarm template and deploy the CRD to the computer cluster; register resource monitors and event handlers in the monitoring component to listen for target alarm message notification templates; the event handlers include adding resource handlers, modifying resource handlers, and deleting resource handlers; deploy the resource monitors and the adding, modifying, and deleting resource handlers to the computer cluster.

[0241] In summary, by introducing the CRD mechanism, alarm message notification templates are modeled as native resource objects, thereby enabling the management and full lifecycle automation of target alarm message notification templates. Alarm policies can be dynamically updated without manual intervention, significantly improving the configuration efficiency of alarm services.

[0242] Corresponding to the aforementioned embodiments of the alarm message notification template processing method, this application also provides embodiments of the alarm message notification template processing system.

[0243] Figure 12 This is a schematic diagram of an alarm message notification template processing system provided in an embodiment of this application.

[0244] like Figure 12 As shown, the alarm message notification template processing system 1200 includes a definition component 1201, a listening component 1202, and an alarm management container 1203. The listening component 1202 includes a monitoring module 1202a and a processing module 1202b. The monitoring module 1202a is used to listen for configuration change events, which are triggered by user-submitted declarative configuration files. The declarative configuration file is an instance generated for a defined custom resource definition CRD, used to define the target alarm message notification template. The CRD is a pre-set structured alarm template used to constrain the format and content of the target alarm message notification template. The processing module is used to perform target operations on the target configuration file corresponding to the target alarm message notification template based on the configuration change event when a configuration change event is detected indicating that the instance generated based on the CRD has changed. The target operation is used to reflect the lifecycle changes of the target alarm message notification template. The target configuration file is the runtime configuration data on which the alarm message generation logic depends. The alarm management container is used to process the target alarm message notification template based on the target operation, so that the target alarm message notification template takes effect.

[0245] In one possible implementation, the listening component further includes a new resource processor 1202c and a processing module 1202b, specifically used to determine the target operation based on the configuration change event; the new resource processor 1202c is used to extract the format content of the target alarm message notification template from the target alarm message notification template when the target operation is a creation operation; the new resource processor is also used to create the target configuration file corresponding to the target alarm message notification template based on the format content.

[0246] In one possible implementation, the listening component further includes a modification resource processor 1202d and a processing module 1202a, specifically used to determine the target operation based on the configuration change event; the modification resource processor 1202d is used to extract the format content of the target alarm message notification template from the target alarm message notification template when the target operation is a modification operation; and modify the target configuration file corresponding to the target alarm message notification template based on the format content.

[0247] In one possible implementation, the listening component further includes a deletion resource processor 1202e and a processing module 1202b, specifically used to determine the target operation based on the configuration change event; the deletion resource processor 1202e is used to delete the target configuration file corresponding to the target alarm message notification template when the target operation is a deletion operation.

[0248] In one possible implementation, the listening module 1202a is specifically used to create a corresponding target alarm message notification template based on the declarative configuration file submitted by the user; generate a configuration change event when the corresponding target alarm message notification template is created; and listen for the configuration change event.

[0249] In one possible implementation, component 1201 is defined to define the CRD of the alarm template and deploy the CRD to the computer cluster; a resource monitor and event handler are registered in the monitoring component to listen for target alarm message notification templates; the event handlers include adding resource handlers, modifying resource handlers and deleting resource handlers; the resource monitor and the adding, modifying and deleting resource handlers are deployed to the computer cluster.

[0250] Figure 13 This is a schematic diagram of a computing device provided in an embodiment of this application.

[0251] like Figure 13 As shown, the computing device 1300 includes a processor 1301 and a memory 1602. Exemplarily, the computing device 1300 may also include a communications interface 1303 and a communications bus 1304.

[0252] The processor 1301, memory 1302, and communication interface 1303 communicate with each other via communication bus 1304. The communication interface 1303 may include a transmitter and receiver for communicating with other devices or communication networks. It can be a wired interface (port), such as a fiber distributed data interface (FDDI) or a gigabit Ethernet interface (GE).

[0253] In some embodiments, the processor 1301 is used to execute program 1305, specifically performing the relevant steps in the above-described alarm message notification template processing method embodiments. Specifically, program 1305 may include program code, which includes computer-executable instructions.

[0254] For example, processor 1301 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement some embodiments of this application. Computing device 1100 may include one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs. The CPU may be a single-core CPU or a multi-core CPU.

[0255] In some embodiments, memory 1302 is used to store program 1305. Memory 1302 may include high-speed random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device.

[0256] Specifically, program 1305 can be called by processor 1301 to cause computing device 1300 to perform alarm message notification template processing operations.

[0257] Some embodiments of this application provide a computer-readable storage medium storing at least one executable instruction that, when executed on a computing device 1300, causes the computing device 1300 to perform the alarm message notification template processing method described in the above embodiments.

[0258] For example, the computer-readable storage medium can be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device.

[0259] This application provides a chip system in some embodiments, which is applied to a server. The chip system includes one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via lines. The interface circuits are used to receive signals from the server's memory and send signals to the processors, the signals including computer instructions stored in the memory. When the server processor executes the computer instructions, the server performs the various steps of the alarm message notification template processing method shown in the above method embodiments.

[0260] The beneficial effects that the readable storage medium provided in some embodiments of this application can achieve can be referred to the beneficial effects in the corresponding inference task execution method provided above, and will not be repeated here.

[0261] It should be noted that, in this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0262] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0263] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0264] For the purposes of this specification, "computer-readable medium" can mean any means that can contain, store, communicate, propagate, or transmit programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0265] More specific examples of computer-readable media (a non-exhaustive list) include the following: electrical connections having one or more wires (electronic devices), portable computer disks (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM).

[0266] Furthermore, the computer-readable medium can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory. It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof.

[0267] In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc. The above embodiments are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solutions of this application should be included within the scope of protection of this application.

Claims

1. A method for processing alarm message notification templates, applied to a computer cluster, wherein a monitoring component runs in the computer cluster, and the monitoring component is used to manage target alarm message notification templates, characterized in that, The method includes: Listen for configuration change events, which are triggered by a declarative configuration file submitted by the user. The declarative configuration file is an instance generated from a defined custom resource definition CRD, used to define the target alarm message notification template. The CRD is a pre-set structured alarm template used to constrain the format and content of the target alarm message notification template. If the configuration change event indicates that the instance generated based on the CRD has changed, a target operation is performed on the target configuration file corresponding to the target alarm message notification template based on the configuration change event; the target operation is used to reflect the lifecycle change of the target alarm message notification template; the target configuration file is the runtime configuration data on which the alarm message generation logic depends. Based on the target operation, process the target alarm message notification template to make the target alarm message notification template effective.

2. The alarm message notification template processing method according to claim 1, characterized in that, The step of performing target operations on the target configuration file corresponding to the target alarm message notification template based on the configuration change event includes: Based on the configuration change event, determine the target operation; When the target operation is a creation operation, extract the format content of the target alarm message notification template from the target alarm message notification template; Based on the format and content of the target alarm message notification template, create the target configuration file corresponding to the target alarm message notification template.

3. The alarm message notification template processing method according to claim 1, characterized in that, The step of performing target operations on the target configuration file corresponding to the target alarm message notification template based on the configuration change event includes: Based on the configuration change event, determine the target operation; When the target operation is a modification operation, extract the format content of the target alarm message notification template from the target alarm message notification template; Based on the format and content of the target alarm message notification template, modify the target configuration file corresponding to the target alarm message notification template.

4. The alarm message notification template processing method according to claim 1, characterized in that, The step of performing target operations on the target configuration file corresponding to the target alarm message notification template based on the configuration change event includes: Based on the configuration change event, determine the target operation; If the target operation is a deletion operation, delete the target configuration file corresponding to the target alarm message notification template.

5. The alarm message notification template processing method according to claim 2 or 3, characterized in that, The process of processing the target alarm message notification template based on the target operation includes: Mount the target configuration file to the target path of the alarm management container; The configuration reload component is invoked for hot update, and the target alarm message notification template is reloaded from the mounted target configuration file.

6. The alarm message notification template processing method according to claim 4, characterized in that, The process of processing the target alarm message notification template based on the target operation includes: Delete the target configuration file mounted to the target path of the alarm management container; Invoke the configuration overload component for hot updates.

7. The alarm message notification template processing method according to any one of claims 1-6, characterized in that, The monitoring of configuration change events includes: Based on the declarative configuration file submitted by the user, create the corresponding target alarm message notification template; When the corresponding target alarm message notification template is created, the configuration change event is generated; Listen for the configuration change event.

8. The alarm message notification template processing method according to any one of claims 1-7, characterized in that, Before listening for configuration change events, it also includes: Define the CRD for the alarm template and deploy the CRD to the computer cluster; The monitoring component defines a resource monitor for listening to the target alarm message notification template and an event handler for processing the target alarm message notification template; the event handler includes adding a resource handler, modifying a resource handler, and deleting a resource handler; The resource monitor, the newly added resource processor, the modified resource processor, and the deleted resource processor are deployed to the computer cluster.

9. The alarm message notification template processing method according to claim 1, characterized in that, When the configuration change event indicates a change in the instance generated based on the CRD, the step of performing a target operation on the target configuration file corresponding to the target alarm message notification template based on the configuration change event includes: When the monitoring module detects that the configuration change event indicates a change in the instance generated based on the CRD, it writes the target alarm message notification template into the incremental first-in-first-out queue. The processing module obtains the target alarm message notification template from the incremental first-in-first-out queue; The processing module determines the target operation corresponding to the target alarm message notification template based on the target alarm message notification template; The processing module sends the target operation to the target processor; The target processor executes the target operation on the target configuration file corresponding to the target alarm message notification template.

10. A computing device, characterized in that, The computing device includes a memory and a processor; the memory and the processor are coupled; the memory is used to store computer program code, the computer program code including computer instructions, which, when executed by the processor, cause the computing device to perform the alarm message notification template processing method as described in any one of claims 1 to 9.

Images