An alarm method and device, electronic equipment and storage medium
By configuring clients in NFV architecture communication networks and utilizing machine learning algorithms to construct resource topology trees for horizontal and vertical analysis, the problem of difficult fault location in NFV architecture communication networks is solved, achieving rapid and accurate fault location and effective alarm filtering.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SANGFOR TECH INC
- Filing Date
- 2021-06-28
- Publication Date
- 2026-05-19
AI Technical Summary
In NFV architecture communication networks, a single-layer fault may trigger multiple layers of alarms, making fault location difficult. Existing technologies struggle to effectively identify and filter useful alarm information, especially when virtual networks change, making it difficult to obtain real resource information in a timely manner.
By configuring clients at the hardware, virtual, and application layers, alarms are collected centrally and automatically identified and stored using machine learning algorithms. A resource topology tree is constructed, and the source of the fault is determined by combining horizontal and vertical analysis.
It enables rapid and accurate fault location in NFV architecture communication networks, improves the efficiency of filtering valid alarms, timely obtains real resource information of virtual networks, and improves the accuracy of fault location.
Smart Images
Figure CN115604073B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and more specifically, to an alarm method, apparatus, electronic device, and computer-readable storage medium. Background Technology
[0002] Traditional communication networks use physical hardware, loading operating systems, middleware, and application software to implement various functional entities of the communication network. After network function virtualization is deployed, all functional entities in the application layer share hardware resources in the cloud computing resource pool. Therefore, in addition to paying attention to the various indicators and operating status of the traditional application layer, attention should also be paid to the virtualization layer and the physical layer.
[0003] NFV (Network Function Virtualization) architecture uses three-layer decoupling to break down a single physical device into a hardware layer, a virtualization layer, and an application layer. While this three-layer decoupling enables resource sharing and hierarchical management, allowing hardware and software to evolve independently, a single-layer failure can trigger multiple layers of alarms. Therefore, how to achieve effective fault location is a technical problem that needs to be solved by those skilled in the art. Summary of the Invention
[0004] The purpose of this application is to provide an alarm method, device, electronic device, and computer-readable storage medium that enable effective fault location in NFV architecture communication networks.
[0005] To achieve the above objectives, this application provides an alarm method, comprising:
[0006] Receive a target alarm and determine the resource identifier corresponding to the target alarm; determine alarms belonging to the same architecture layer as the target alarm and alarms belonging to different architecture layers based on the resource identifier of the target alarm, wherein the architecture layer includes a hardware layer, a virtual layer and an application layer;
[0007] Perform horizontal analysis on alarms belonging to the same architecture layer as the target alarm, and perform vertical analysis on alarms belonging to different architecture layers than the target alarm;
[0008] The source of the fault was determined based on the results of the horizontal and vertical analysis.
[0009] Wherein, determining the resource identifier corresponding to the target alarm includes:
[0010] Resource information of the hardware layer, the virtual layer, and the application layer is collected at preset time intervals, and a resource topology tree is constructed based on the resource information;
[0011] If a target alarm is detected, the resource information of the hardware layer, the virtual layer, and the application layer is collected again, and the resource topology tree is updated according to the collected information;
[0012] The resource identifier corresponding to the target alarm is determined based on the updated resource topology tree.
[0013] This also includes:
[0014] Obtain the original alarms from devices in the hardware layer, the virtual layer, and the application layer;
[0015] The target alarm is extracted from the original alarm using a machine learning algorithm.
[0016] The step of extracting the target alarm from the original alarm using a machine learning algorithm includes:
[0017] Determine the attribute information of the original alarms and calculate the correlation between different original alarms;
[0018] The target alarm is extracted using machine learning algorithms based on the attribute information of the original alarm and the correlation between different original alarms.
[0019] The step of extracting the target alarm using a machine learning algorithm based on the attribute information of the original alarm and the correlation between different original alarms includes:
[0020] Based on the attribute information of the original alarms, multiple identical original alarms are aggregated into a single target alarm;
[0021] And / or, merge multiple original alarms with a correlation greater than a preset value into a target alarm;
[0022] And / or, based on the attribute information of the original alarm and the correlation between different original alarms, determine the primary alarm, secondary alarm and derived alarm, and determine the primary alarm as the target alarm.
[0023] The step of obtaining the original alarms from devices in the hardware layer, the virtual layer, and the application layer includes:
[0024] A client is deployed on the device in the hardware layer, the virtual layer, and the application layer. The client is used to collect the original alarms in the corresponding host.
[0025] The server retrieves the raw alarms collected by each client and publishes the raw alarms to the Kafka cluster.
[0026] Subscribe to raw alerts in the Kafka cluster using the ELK model.
[0027] The step of collecting resource information from the hardware layer, virtual layer, and application layer at preset intervals includes:
[0028] By establishing a cron job, resource information from the hardware layer, virtual layer, and application layer is collected at preset intervals.
[0029] The resource identifiers corresponding to the target alarms at the hardware layer include the host identifier and the identifier of the virtualization infrastructure manager to which they belong; the resource identifiers corresponding to the target alarms at the virtual layer include the virtual machine identifier, the identifier of the virtual network function to which they belong, the identifier of the virtualization infrastructure manager to which they belong, and the host identifier to which they reside; and the resource identifiers corresponding to the target alarms at the application layer include the virtual network function identifier, the identifier of the virtual network function manager to which they belong, the identifier of the virtualization infrastructure manager to which they reside, and the virtual machine identifier.
[0030] To achieve the above objectives, this application provides an alarm device, comprising:
[0031] The first determining module is used to receive a target alarm, determine the resource identifier corresponding to the target alarm, and determine alarms belonging to the same architecture layer as the target alarm and alarms belonging to different architecture layers according to the resource identifier of the target alarm. The architecture layer includes a hardware layer, a virtual layer and an application layer.
[0032] The analysis module is used to perform horizontal analysis based on alarms belonging to the same architecture layer as the target alarm, and vertical analysis based on alarms belonging to different architecture layers as the target alarm.
[0033] The second determination module is used to determine the source of the fault based on the results of horizontal and vertical analysis.
[0034] To achieve the above objectives, this application provides an electronic device, comprising:
[0035] Memory, used to store computer programs;
[0036] A processor for implementing the alarm method described above when executing the computer program.
[0037] To achieve the above objectives, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the alarm method described above.
[0038] As can be seen from the above scheme, the alarm method provided in this application includes: receiving a target alarm and determining the resource identifier corresponding to the target alarm; determining alarms belonging to the same architecture layer as the target alarm and alarms belonging to different architecture layers according to the resource identifier of the target alarm, wherein the architecture layer includes a hardware layer, a virtual layer, and an application layer; performing horizontal analysis based on the alarms belonging to the same architecture layer as the target alarm and performing vertical analysis based on the alarms belonging to different architecture layers as the target alarm; and determining the source of the fault based on the results of the horizontal and vertical analysis.
[0039] The alarm method provided in this application performs horizontal analysis based on alarms belonging to the same architectural layer as the target alarm, and vertical analysis based on alarms belonging to different architectural layers. Based on the results of both horizontal and vertical analysis, it effectively locates the source of the fault. This application also discloses an alarm device, an electronic device, and a computer-readable storage medium, which can achieve the same technical effects.
[0040] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this application. Attached Figure Description
[0041] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. The drawings are used to provide a further understanding of this disclosure and constitute a part of the specification. They are used together with the following detailed description to explain this disclosure, but do not constitute a limitation of this disclosure. In the drawings:
[0042] Figure 1 This is a flowchart illustrating an alarm method according to an exemplary embodiment;
[0043] Figure 2 A flowchart illustrating another alarm method according to an exemplary embodiment;
[0044] Figure 3 This is a structural diagram of an alarm device according to an exemplary embodiment;
[0045] Figure 4 This is a structural diagram of an electronic device according to an exemplary embodiment. Detailed Implementation
[0046] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Furthermore, in the embodiments of this application, "first," "second," etc., are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.
[0047] Those skilled in the art have discovered the following technical challenges in implementing alarms for NFV architecture communication networks: First, traditional networks consist of only physical machines, allowing all alarms to be converted into a standardized format for processing. However, NFV architecture communication networks involve multiple hosts across the hardware, virtualization, and application layers, resulting in numerous alarm sources. Furthermore, each layer has different alarm formats and types, and each layer has its own collection methods and databases, necessitating rapid and accurate filtering to identify truly useful alarm information. Second, alarms at the three layers of an NFV architecture communication network are correlated, requiring the determination of these correlations for effective fault location. Finally, when changes occur in the virtual network, such as scaling up or down, or virtual machine migration, the correspondence between applications, virtual machines, and hosts dynamically changes. Therefore, timely and accurate acquisition of real resource information within the virtual network is crucial for alarm analysis.
[0048] Therefore, firstly, in this application, clients are configured for each host in the hardware layer, virtual layer, and application layer. These clients are used to collect alarms from the corresponding hosts. A server is set up to collect the alarms collected by each client. Compared to multiple independent collection methods, the centralized collection method provided in this application can save a significant amount of time. Secondly, this application automatically identifies and stores alarms based on machine learning principles, and derives correlation results based on predefined rules or statistical analysis of historical data. Machine learning introduces many mathematical and statistical techniques to enhance the accuracy of the analysis. These techniques can comprehensively analyze and extract effective target alarms based on statistics, depth, density, or clustering, improving the efficiency of filtering effective alarms compared to manual alarm data selection. Furthermore, this application collects resource information primarily through periodic collection and secondarily through on-demand collection, and constructs the network topology. Periodic collection ensures that the topology information of the cloud resource pool is saved at fixed intervals, while on-demand collection ensures that the latest data of the resource pool is collected immediately when a valid target alarm is detected. Through these two aspects of resource information collection, the real resource information in the virtual network can be obtained in a timely and accurate manner. Finally, based on the horizontal analysis of the resource identifiers corresponding to the target alarms at the same level, this application performs a vertical analysis of the resource identifiers corresponding to the target alarms at different levels, and achieves effective location of the fault source based on the results of the horizontal and vertical analysis.
[0049] This application discloses an alarm method that enables effective fault location in NFV architecture communication networks.
[0050] See Figure 1 A flowchart illustrating an alarm method according to an exemplary embodiment is shown below. Figure 1 As shown, it includes:
[0051] S101: Receive a target alarm and determine the resource identifier corresponding to the target alarm; determine alarms belonging to the same architecture layer as the target alarm and alarms belonging to different architecture layers according to the resource identifier of the target alarm, wherein the architecture layer includes a hardware layer, a virtual layer and an application layer;
[0052] It is understandable that the NFV architecture communication network includes a hardware layer, a virtualization layer, and an application layer. The hardware layer includes multiple hosts, the virtualization layer includes multiple virtual machines (VMs), and the application layer includes multiple virtual network functions (VNFs). The hosts in the application layer, the virtual machines in the virtualization layer, and the virtual network functions in the application layer can be collectively referred to as devices.
[0053] The target alarms in this step are the valid alarms and require special attention. Therefore, based on the resource identifier of the target alarm, we determine the alarms that belong to the same architecture layer and the alarms that belong to different architecture layers, so that we can perform horizontal and vertical correlation analysis in subsequent steps.
[0054] In a preferred embodiment, determining the resource identifier corresponding to the target alarm includes: collecting resource information of the hardware layer, the virtual layer, and the application layer at preset time intervals, and constructing a resource topology tree based on the resource information; if a target alarm is detected, re-collecting the resource information of the hardware layer, the virtual layer, and the application layer, and updating the resource topology tree according to the collected information; and determining the resource identifier corresponding to the target alarm based on the updated resource topology tree.
[0055] In practical implementation, a script is used to collect all resource information within the cloud resource pool at preset intervals. This involves extracting resource information from the hardware, virtualization, and application layers. One feasible implementation is to establish a cron job to collect this information at these intervals. A resource topology tree is then constructed based on this information, with each node representing one of the aforementioned devices. For example, starting with a virtual card in a VNF, the topology information includes the VNF name, the virtual card name, the associated VM, the hypervisor of the VM, the virtual network associated with the VM, the subnet and corresponding port of the virtual network, and the physical server where the hypervisor resides. Each of these objects corresponds to its own resource identifier.
[0056] It should be noted that target alarms cause changes in resource topology, such as virtual machine migration or VNF scaling. Therefore, upon detecting a target alarm, resource information from the hardware, virtualization, and application layers is collected in real time to update the resource topology tree, thereby ensuring the accuracy of resource information within the topology tree. The resource identifier corresponding to the target alarm is then determined within the updated resource topology tree. Specifically, the resource identifiers corresponding to target alarms at the hardware layer may include host identifier (Host_ID), host name (Host_Name), and the identifier of the virtualization infrastructure manager (VIM_ID). The resource identifiers corresponding to target alarms at the virtualization layer may include virtual machine identifier (VM_ID), virtual machine name (VM_Name), the identifier of the virtual network function (VNF_ID), the identifier of the virtualization infrastructure manager (VIM_ID), the host identifier (Host_ID), and the host name (Host_Name). The resource identifiers corresponding to target alarms at the application layer may include virtual network function identifier (VNF_ID), virtual network function name (VNF_Name), the identifier of the virtual network function manager (VIM_ID), the identifier of the virtualization infrastructure manager (VNFM_ID), and the virtual machine identifier (VM_ID).
[0057] S102: Perform horizontal analysis on alarms belonging to the same architecture layer as the target alarm, and perform vertical analysis on alarms belonging to different architecture layers than the target alarm;
[0058] In this step, horizontal analysis is performed on alarms belonging to the same architectural layer as the target alarm. For example, if multiple VM alarms appear in the virtualization layer, it's necessary to analyze whether these alarms share consistent characteristics, such as whether they originate from the same VNF, the same physical server, or the same resource pool. Simultaneously, vertical analysis is performed on alarms belonging to different architectural layers than the target alarm. For example, within a short timeframe, the application layer experiences node restarts, the virtualization layer experiences VM unavailability, and the hardware layer experiences server failures. In this case, it's necessary to analyze which layer the root cause of these alarms originates from.
[0059] S103: Determine the source of the fault based on the results of horizontal and vertical analysis.
[0060] In practice, if the results of horizontal and vertical correlations are consistent, the source of the fault can be directly predicted. If they are inconsistent, then there is a certain degree of correlation. By combining semi-supervised machine learning with the experience and judgment of operations and maintenance personnel, the results can become increasingly accurate.
[0061] The alarm method provided in this application performs horizontal analysis based on alarms belonging to the same architecture layer as the target alarm, and vertical analysis based on alarms belonging to different architecture layers as the target alarm. Based on the results of the horizontal and vertical analysis, the source of the fault is effectively located.
[0062] Based on the above embodiments, as a preferred implementation, the method further includes: acquiring the original alarms of the devices in the hardware layer, the virtual layer, and the application layer; and extracting the target alarm from the original alarms using a machine learning algorithm.
[0063] In practice, the system acquires the original alarms from devices in the hardware, virtual, and application layers, automatically identifies and stores the original alarms based on machine learning principles, and extracts valid target alarms from the original alarms based on predefined rules or statistical analysis of historical data.
[0064] As a feasible implementation, obtaining the original alarms of devices in the hardware layer, the virtual layer, and the application layer includes: deploying clients on devices in the hardware layer, the virtual layer, and the application layer, wherein the clients are used to collect the original alarms in the corresponding hosts; using a server to obtain the original alarms collected by each client and publishing the original alarms to the Kafka cluster; and using the ELK model to subscribe to the original alarms in the Kafka cluster.
[0065] In practice, the first step is to configure clients on devices at the hardware, virtualization, and application layers. These clients can be Rsyslog clients, used to collect alarms from the corresponding hosts. Next, a server is set up, which can be an Rsyslog server, used to collect the alarms collected by the clients.
[0066] Kafka is an open-source stream processing platform characterized by high throughput and low latency, and it can persistently store data, often used for log forwarding. The Rsyslog server sends alerts to the Kafka cluster, which stores the alerts and provides them to Logstash for subscription. Logstash processes and transforms the alert data before saving it to the Elasticsearch cluster. Simultaneously, Kibana can be used to view and interact with the data stored in the Elasticsearch index. During the semi-supervised learning process, operations personnel can review and update the data.
[0067] This embodiment will detail the target alarm extraction process. Compared to the above embodiment, this embodiment further explains and optimizes the technical solution. Specifically:
[0068] See Figure 2 A flowchart illustrating another alarm method according to an exemplary embodiment, such as Figure 2 As shown, it includes:
[0069] S201: Obtain the original alarms from the host in the hardware layer, the virtual layer, and the application layer;
[0070] S202: Determine the attribute information of the original alarms and calculate the correlation between different original alarms;
[0071] In practice, raw alarms from the hardware, virtualization, and application layers are preprocessed and standardized before being converted into feature values, which are then identifiable alarm attributes. Each alarm at each layer has its own characteristics, such as alarm identifier, alarm level, alarm name, keywords, length, time, resource information, and probability of occurrence. The correlation between the feature values of different raw alarms can be calculated based on predefined rules or historical data statistics.
[0072] S203: Extract the target alarm based on the attribute information of the original alarm and the correlation between different original alarms using a machine learning algorithm.
[0073] In this step, the attribute information of each original alarm, namely the feature values mentioned above and the correlation between different original alarms, is provided to the machine learning algorithm to calculate the correlation model between alarms at different levels.
[0074] As one possible implementation, this step may include: aggregating multiple identical original alarms into a single target alarm based on the attribute information of the original alarms. In practice, if there are many identical alarms, multiple identical alarms can be aggregated multiple times to eventually become a single alarm.
[0075] As another feasible implementation, this step may include merging multiple original alarms with a correlation greater than a preset value into a target alarm. In specific implementations, multiple original alarms with high correlation can be directly treated as a single association rule.
[0076] As another feasible implementation, this step may include: determining primary alarms, secondary alarms, and derived alarms based on the attribute information of the original alarms and the correlation between different original alarms, and identifying the primary alarm as the target alarm. In specific implementations, the primary alarm can be emphasized while the secondary and derived alarms are downplayed, that is, the host alarm can be used as the target alarm.
[0077] Meanwhile, machine learning and feature value training can be used to summarize the frequency of each alarm, define the time window between alarms with correlation in different layers, and then combine the resource information of the three layers to finally output alarm association rules.
[0078] Therefore, this embodiment, based on machine learning principles, automatically identifies and stores alarms, and derives correlation results based on predefined rules or statistical analysis of historical data. Machine learning incorporates numerous mathematical and statistical techniques to enhance the accuracy of the analysis. These techniques can comprehensively analyze and extract effective target alarms based on statistics, depth, density, or clustering, improving the efficiency of selecting effective alarms compared to manual alarm data screening.
[0079] The following describes an alarm device provided in an embodiment of this application. The alarm device described below and the alarm method described above can be referred to each other.
[0080] See Figure 3 A structural diagram of an alarm device according to an exemplary embodiment is shown, such as... Figure 3 As shown, it includes:
[0081] The first determining module 301 is used to receive a target alarm, determine the resource identifier corresponding to the target alarm, and determine alarms belonging to the same architecture layer as the target alarm and alarms belonging to different architecture layers according to the resource identifier of the target alarm. The architecture layer includes a hardware layer, a virtual layer and an application layer.
[0082] Analysis module 302 is used to perform horizontal analysis based on alarms belonging to the same architecture layer as the target alarm, and vertical analysis based on alarms belonging to different architecture layers as the target alarm;
[0083] The second determination module 303 is used to determine the source of the fault based on the results of the horizontal analysis and the vertical analysis.
[0084] The alarm device provided in this application embodiment performs horizontal analysis based on alarms belonging to the same architecture layer as the target alarm, and vertical analysis based on alarms belonging to different architecture layers as the target alarm. Based on the horizontal and vertical analysis results, the source of the fault is effectively located.
[0085] Based on the above embodiments, as a preferred implementation, the first determining module 301 includes:
[0086] The receiving unit is used to receive target alarms;
[0087] The construction unit is used to collect resource information of the hardware layer, the virtual layer and the application layer at preset time intervals, and construct a resource topology tree based on the resource information;
[0088] According to the unit, if a target alarm is detected, the resource information of the hardware layer, the virtual layer and the application layer is re-collected, and the resource topology tree is updated according to the collected information;
[0089] The first determining unit is used to determine the resource identifier corresponding to the target alarm based on the updated resource topology tree;
[0090] The second determining unit is used to determine, based on the resource identifier of the target alarm, alarms belonging to the same architecture layer as the target alarm and alarms belonging to different architecture layers than the target alarm.
[0091] Based on the above embodiments, as a preferred embodiment, it further includes:
[0092] The acquisition module is used to acquire the original alarms of devices in the hardware layer, the virtual layer and the application layer;
[0093] The extraction module is used to extract the target alarm from the original alarm using machine learning algorithms.
[0094] Based on the above embodiments, as a preferred embodiment, the extraction module includes:
[0095] A calculation unit is used to determine the attribute information of the original alarms and calculate the correlation between different original alarms;
[0096] The extraction unit is used to extract the target alarm based on the attribute information of the original alarm and the correlation between different original alarms using a machine learning algorithm.
[0097] Based on the above embodiments, as a preferred implementation, the extraction unit includes a convergence subunit, a merging subunit, and a combination of any one or several of the determining subunits;
[0098] The aggregation subunit is used to aggregate multiple identical original alarms into a single target alarm based on the attribute information of the original alarms.
[0099] The merging sub-unit is used to merge multiple original alarms with a correlation greater than a preset value into a target alarm.
[0100] The determination subunit is used to determine primary alarms, secondary alarms, and derived alarms based on the attribute information of the original alarms and the correlation between different original alarms, and to determine the primary alarms as the target alarms.
[0101] Based on the above embodiments, as a preferred embodiment, the acquisition module includes:
[0102] A deployment unit is used to deploy a client on devices in the hardware layer, the virtual layer, and the application layer, wherein the client is used to collect raw alarms from the corresponding host.
[0103] The publishing unit is used to obtain the original alarms collected by each client using the server and publish the original alarms to the Kafka cluster;
[0104] The subscription unit is used to subscribe to raw alerts in the Kafka cluster using the ELK model.
[0105] Based on the above embodiments, as a preferred implementation, the construction module 301 is specifically a module that collects resource information of the hardware layer, virtual layer and application layer by establishing a cron job at preset intervals, and constructs a resource topology tree based on the resource information.
[0106] Based on the above embodiments, as a preferred implementation, the resource identifier corresponding to the target alarm in the hardware layer includes the host identifier and the identifier of the virtualization infrastructure manager to which it belongs; the resource identifier corresponding to the target alarm in the virtual layer includes the virtual machine identifier, the identifier of the virtual network function to which it belongs, the identifier of the virtualization infrastructure manager to which it belongs, and the host identifier where it is located; and the resource identifier corresponding to the target alarm in the application layer includes the virtual network function identifier, the identifier of the virtual network function manager to which it belongs, the identifier of the virtualization infrastructure manager where it is located, and the virtual machine identifier.
[0107] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.
[0108] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiments of this application, the embodiments of this application also provide an electronic device. Figure 4 This is a structural diagram of an electronic device according to an exemplary embodiment, such as... Figure 4 As shown, the electronic device includes:
[0109] Communication interface 1 enables information exchange with other devices, such as network devices;
[0110] Processor 2 is connected to communication interface 1 to enable information exchange with other devices and, when running a computer program, executes the alarm methods provided by one or more of the above-mentioned technical solutions. The computer program is stored in memory 3.
[0111] Of course, in practical applications, the various components in an electronic device are coupled together through bus system 4. It can be understood that bus system 4 is used to achieve communication and connection between these components. In addition to the data bus, bus system 4 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 4 The general will label all buses as Bus System 4.
[0112] The memory 3 in this embodiment is used to store various types of data to support the operation of the electronic device. Examples of such data include any computer program used to operate on the electronic device.
[0113] It is understood that memory 3 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memory 2 described in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.
[0114] The methods disclosed in the embodiments of this application can be applied to processor 2, or implemented by processor 2. Processor 2 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 2 or by instructions in the form of software. The processor 2 may be a general-purpose processor, DSP, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 2 can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in memory 3. Processor 2 reads the program in memory 3 and completes the steps of the aforementioned method in combination with its hardware.
[0115] When processor 2 executes the program, it implements the corresponding processes in the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.
[0116] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a memory 3 that stores a computer program, which can be executed by a processor 2 to complete the steps described in the aforementioned method. The computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM.
[0117] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.
[0118] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.
[0119] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. An alarm method, characterized in that, include: Receive the target alarm and determine the resource identifier corresponding to the target alarm; Based on the resource identifier of the target alarm, alarms belonging to the same architecture layer as the target alarm and alarms belonging to different architecture layers are identified. The architecture layers include the hardware layer, the virtual layer, and the application layer. A horizontal analysis is performed on alarms belonging to the same architecture layer as the target alarm to analyze whether alarms in the same architecture layer have unified characteristics. A vertical analysis is performed on alarms belonging to different architecture layers as the target alarm to analyze the architecture layer where the root cause of the fault in alarms in different architecture layers is located. The source of the fault was determined based on the results of the horizontal and vertical analysis.
2. The alarm method according to claim 1, characterized in that, Determining the resource identifier corresponding to the target alarm includes: Resource information of the hardware layer, the virtual layer, and the application layer is collected at preset time intervals, and a resource topology tree is constructed based on the resource information; If a target alarm is detected, the resource information of the hardware layer, the virtual layer, and the application layer is collected again, and the resource topology tree is updated according to the collected information. The resource identifier corresponding to the target alarm is determined based on the updated resource topology tree.
3. The alarm method according to claim 1, characterized in that, Also includes: Obtain the original alarms from devices in the hardware layer, the virtual layer, and the application layer; The target alarm is extracted from the original alarm using a machine learning algorithm.
4. The alarm method according to claim 3, characterized in that, The step of extracting the target alarm from the original alarm using a machine learning algorithm includes: Determine the attribute information of the original alarms and calculate the correlation between different original alarms; The target alarm is extracted using machine learning algorithms based on the attribute information of the original alarm and the correlation between different original alarms.
5. The alarm method according to claim 4, characterized in that, The step of extracting the target alarm using a machine learning algorithm based on the attribute information of the original alarm and the correlation between different original alarms includes: Based on the attribute information of the original alarms, multiple identical original alarms are aggregated into a single target alarm; And / or, merge multiple original alarms with a correlation greater than a preset value into a target alarm; And / or, based on the attribute information of the original alarm and the correlation between different original alarms, determine the primary alarm, secondary alarm and derived alarm, and determine the primary alarm as the target alarm.
6. The alarm method according to claim 3, characterized in that, The process of acquiring the original alarms from devices in the hardware layer, the virtual layer, and the application layer includes: A client is deployed on the device in the hardware layer, the virtual layer, and the application layer. The client is used to collect the original alarms in the corresponding host. The server retrieves the raw alarms collected by each client and publishes the raw alarms to the Kafka cluster. Subscribe to raw alerts in the Kafka cluster using the ELK model.
7. The alarm method according to claim 2, characterized in that, The collection of resource information from the hardware layer, virtual layer, and application layer at preset time intervals includes: By establishing a cron job, resource information from the hardware layer, virtual layer, and application layer is collected at preset intervals.
8. The alarm method according to claim 1, characterized in that, The resource identifier corresponding to the target alarm at the hardware layer includes the host identifier and the identifier of the virtualization infrastructure manager to which it belongs. The resource identifier corresponding to the target alarm at the virtual layer includes the virtual machine identifier, the identifier of the virtual network function to which it belongs, the identifier of the virtualization infrastructure manager to which it belongs, and the host identifier to which it is located. The resource identifier corresponding to the target alarm at the application layer includes the virtual network function identifier, the identifier of the virtual network function manager to which it belongs, the identifier of the virtualization infrastructure manager to which it is located, and the virtual machine identifier.
9. An alarm device, characterized in that, include: The first determining module is used to receive the target alarm and determine the resource identifier corresponding to the target alarm; Based on the resource identifier of the target alarm, alarms belonging to the same architecture layer as the target alarm and alarms belonging to different architecture layers are identified. The architecture layers include the hardware layer, the virtual layer, and the application layer. The analysis module is used to perform horizontal analysis on alarms belonging to the same architecture layer as the target alarm to analyze whether alarms in the same architecture layer have unified characteristics, and to perform vertical analysis on alarms belonging to different architecture layers as the target alarm to analyze the architecture layer where the root cause of the fault in the alarms in different architecture layers is located. The second determination module is used to determine the source of the fault based on the results of horizontal and vertical analysis.
10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the alarm method as described in any one of claims 1 to 8 when executing the computer program.
11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the alarm method as described in any one of claims 1 to 8.