Alarm management method, device and equipment

Abstract

The embodiment of the invention discloses an alarm management method, device and equipment, and the method comprises the steps: collecting the state data of a target node in a current monitoring period through a data collection assembly, mapping the state data into target state data which accords with a preset transmission format based on a preset mapping rule, and transmitting the target state data to a server; and in the long connection established between the data acquisition component and the data pulling component, transmitting the target state data to the data pulling component in parallel by utilizing a multiplexing mechanism, judging whether the target node is abnormal or not based on the target state data in the data pulling component, and if yes, sending the abnormal target node to the data acquisition component. And when it is determined that the target node is abnormal, sending preset alarm information to the target node.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an alarm management method, apparatus, and device. Background Technology

[0002] With economic development and technological advancements, emerging container resources in recent years often require additional monitoring platforms for monitoring. For example, the Prometheus system, which can collect the real-time operating status of monitored devices, can be used to monitor whether there are any abnormalities in the operating status of the monitored devices and send alarm information when abnormalities are detected.

[0003] However, because the Prometheus system adopts a single-connection serial pull mode, each metric collection requires a TCP three-way handshake and serial request-response, which significantly increases the collection latency in high-concurrency scenarios, resulting in low data retrieval efficiency and delayed anomaly alarms. Therefore, a technical solution is needed to improve data retrieval efficiency and avoid delays in anomaly alarms. Summary of the Invention

[0004] The purpose of this invention is to provide a technical solution that can improve data retrieval efficiency and avoid delays in abnormal alarms.

[0005] To solve the above-mentioned technical problems, the embodiments of the present invention are implemented as follows: In a first aspect, an alarm management method is provided by an embodiment of the present invention, the method comprising: Use data acquisition components to collect status data of target nodes within the current monitoring period; Based on preset mapping rules, the state data is mapped to target state data that conforms to a preset transmission format; In the long connection established between the data acquisition component and the data retrieval component, the target state data is transmitted to the data retrieval component in parallel using a multiplexing mechanism; Based on the target state data in the data retrieval component, it is determined whether the target node is abnormal; If an anomaly is detected in the target node, a preset alarm message is sent to the target node.

[0006] Secondly, embodiments of the present invention provide an alarm management device, the device comprising: The data acquisition module is used to collect the status data of the target node within the current monitoring period using the data acquisition components. The data mapping module is used to map the state data into target state data that conforms to a preset transmission format based on preset mapping rules. The data transmission module is used to transmit the target state data to the data extraction component in parallel using a multiplexing mechanism in the long connection established between the data acquisition component and the data extraction component. The anomaly detection module is used to determine whether the target node has any anomalies based on the target state data retrieved from the data pull component. The anomaly alarm module is used to send preset alarm information to the target node when it is determined that there is an anomaly in the target node.

[0007] Thirdly, embodiments of the present invention provide an alarm management device, including a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps of the alarm management method provided in the above embodiments.

[0008] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the alarm management method provided in the above embodiments.

[0009] Fifthly, embodiments of the present invention provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the alarm management method provided in the above embodiments. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of the present invention 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 recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating an alarm management method according to the present invention; Figure 2 This is a schematic diagram of a data transmission process according to the present invention; Figure 3 This is a flowchart illustrating an incremental data filtering process according to the present invention. Figure 4 This is a flowchart illustrating the transmission process of target state data according to the present invention. Figure 5 This is a flowchart illustrating the alarm information sending process according to the present invention. Figure 6 This is a schematic diagram of an alarm system according to the present invention; Figure 7This is a schematic diagram of the structure of an alarm management device according to the present invention; Figure 8 This is a schematic diagram of the structure of an alarm management device according to the present invention. Detailed Implementation

[0012] This invention provides an alarm management method, apparatus, and device.

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

[0014] like Figure 1 As shown, this embodiment of the invention provides an alarm management method. The executing entity of this method can be a terminal device or a server. The terminal device can be a mobile terminal device such as a mobile phone, tablet computer, or smartwatch, or a terminal device such as a computer. The server can be an independent server or a server cluster composed of multiple servers. Specifically, the method may include the following steps: In step S102, the status data of the target node within the current monitoring period is collected using the data acquisition component.

[0015] The data acquisition component can be the Exporter component in an anomaly monitoring and alarm system such as Prometheus, and the target node can be any network device. The Prometheus system can periodically capture the status data of the monitored component (i.e., the target node, which can be a server, database, application, etc.) via HTTP. The status data can be used to characterize the running status of the target node. For example, the status data can include the CPU utilization and memory utilization of the target node.

[0016] In implementation, taking a Prometheus system server as an example, the server can define the target nodes to be crawled in the prometheus.yml file and integrate Grafana. For example, Prometheus can be added as a Grafana data source by entering the Prometheus address (e.g., prometheus:9090) to complete the integration and achieve data visualization. Alerts can then be set, such as through Prometheus's Alertmanager or Grafana's built-in alerting function, and email notifications can be configured.

[0017] After completing the above configuration, the server can use the data acquisition component Exporter to collect the status data of the target node within the current monitoring period (such as the last ten minutes, the last half hour, etc.).

[0018] In step S104, based on preset mapping rules, the state data is mapped to target state data that conforms to a preset transmission format.

[0019] In implementation, taking binary format as the preset transmission format as an example, the server can map state data into target state data in binary format based on preset mapping rules. For instance, the server can perform dictionary mapping between the indicator names and tag keys in the state data collected by the Exporter component to obtain the target state data in binary format.

[0020] In step S106, in the long connection established between the data acquisition component and the data retrieval component, the target state data is transmitted to the data retrieval component in parallel using a multiplexing mechanism.

[0021] The data retrieval component can be a Server component in an anomaly monitoring and alarm system such as Prometheus. In Prometheus, the Exporter and Server components are the two pillars of its core architecture, working together to achieve data collection and storage. Figure 2 As shown, since the monitoring system may involve a large amount of time-series data, its data sources mainly include various Exporter components (such as Node Exporter, MySQL Exporter, etc.). These Exporter components are responsible for collecting indicator data (i.e., status data) from the monitored devices or services (i.e., target nodes) and converting it into a format that Prometheus can parse. The Server component is used to periodically (e.g., every 15 seconds) pull the target status data exposed by the Exporter components via HTTP.

[0022] In implementation, data acquisition can adopt a pull mode, where the Server component can periodically send HTTP requests to the Exporter component to obtain current monitoring metric data. To improve the data acquisition efficiency of the Server component, the communication protocol between the Server and Exporter components is upgraded from HTTP / 1.1 to HTTP / 2. Utilizing the multiplexing mechanism of HTTP / 2, multiple metric data streams are transmitted in parallel over a single TCP long connection. These metric data streams are used to transmit target status data, thus avoiding the performance bottleneck caused by serial requests in HTTP / 1.1.

[0023] In this way, obtaining target status data through binary encoding reduces transmission volume. The transmission volume of a single indicator data point can be reduced by 60%-70% compared to traditional text format, and the parsing speed of binary format is more than 50% faster than text format, thus improving parsing efficiency. Simultaneously, the HTTP / 2 multiplexing mechanism can improve data collection parallelism, shorten overall data collection latency, and increase collection efficiency.

[0024] In step S108, based on the target state data in the data retrieval component, it is determined whether there is an anomaly in the target node.

[0025] In implementation, the server can parse the target state data in the data retrieval component and use a pre-trained anomaly detection model to perform anomaly detection on the parsed state data in order to determine whether there is anomaly in the target node based on the anomaly detection results.

[0026] In step S110, if it is determined that there is an anomaly in the target node, a preset alarm message is sent to the target node.

[0027] In practice, if an anomaly is detected in the target node, a preset alarm message can be sent to the target node through Alertmanager.

[0028] This invention provides an alarm management method. It utilizes a data acquisition component to collect status data of target nodes within the current monitoring period. Based on preset mapping rules, the status data is mapped to target status data conforming to a preset transmission format. In a long-lived connection established between the data acquisition component and the data retrieval component, a multiplexing mechanism is used to transmit the target status data to the data retrieval component in parallel. Based on the target status data in the data retrieval component, it is determined whether the target node is abnormal. If an abnormality is determined, a preset alarm message is sent to the target node. Thus, by converting the format of the collected target node status data through preset mapping rules, the transmission volume can be reduced, and data transmission efficiency can be improved. Simultaneously, the HTTP / 2 multiplexing mechanism can improve the parallelism of acquisition, shorten the overall acquisition latency, improve data retrieval efficiency, and avoid delays in abnormal alarms.

[0029] In practical applications, the specific processing method for mapping state data to target state data conforming to a preset transmission format based on preset mapping rules in step S104 above can be varied. The following provides one optional processing method, such as... Figure 3 As shown, the specific process may include the following steps S1042 to S1044.

[0030] In step S1042, based on the status data of the target nodes that have been transmitted in the historical monitoring period, incremental data in the status data of the target nodes in the current monitoring period is filtered out.

[0031] In implementation, raw data collected by data acquisition components (such as the Exporter component) can be transmitted in text format (such as JSON or Prometheus text format). However, to reduce transmission volume and parsing overhead, Protocol Buffers (Protobuf) can be introduced as a binary encoding protocol. Specifically: Dictionary mapping between metric names and tag keys: Each Exporter component can maintain a `metric_dict.json` file locally, using key-value pairs for storage, with the following structure: json { "metric_names": { / / Metric name mapping (1-byte ID, range 0x01-0x7F) "cpu_usage": 0x01, "memory_usage": 0x02, "disk_used_percent": 0x03, "node_name": 0x04, "service_port": 0x05 }, "label_keys": { / / Label key mapping (1-byte ID, range 0x80-0xFF) "instance": 0x81, "namespace": 0x82, "pod_name": 0x83, "service_name": 0x84 }, "version": "v1.0.2", / / Dictionary version, bound to the Exporter version. "update_time": 1715884800 / / Last update timestamp (seconds) } When the Exporter component starts, it can load the dictionary table via `ioutil.ReadFile(". / metric_dict.json")`. If the file does not exist, a default table (containing mappings for 20 commonly used metrics / tags) can be generated. When adding a metric or tag that is not yet included, the Exporter component can automatically assign an unused ID (in ascending order) and update the current table after backing up the old table in `. / metric_dict.json.bak`. If the dictionary version carried by the Prometheus system's Server component in the request is inconsistent with the locally stored dictionary table in the Exporter component, the Exporter component can first push the latest dictionary table (compressed to no more than 512 bytes) via HTTP / 2 HEADERS frames.

[0032] The Exporter component can define message structures based on Protocol Buffers 3.0 and select different storage lengths according to the numerical range. The implementation code is as follows: / / Dynamically select the number of bytes to store based on the numerical range Func encodeValue(value float64) ([]byte, error) { var buf []byte / / 1. Convert to integer (Prometheus metrics retain 2 decimal places, so multiply by 100 first) intVal := int64(value 100) / / 2. Select the encoding length based on the numerical range switch { case intVal>= 0&&intVal<= 255: / / 0.00 ~ 2.55 (1 byte of storage) buf = []byte{byte(intVal)} case intVal>255&&intVal<= 65535: / / 2.56 ~ 655.35 (2 bytes of storage) buf = make([]byte, 2) binary.LittleEndian.PutUint16(buf, uint16(intVal)) case intVal>65535: / / >655.35 (4 bytes of storage) buf = make([]byte, 4) binary.LittleEndian.PutUint32(buf, uint32(intVal)) default: / / Negative numbers (the highest bit is marked as 1) buf = make([]byte, 4) binary.LittleEndian.PutUint32(buf, uint32(math.Abs(float64(intVal)))) buf[3] |= 0x80 / / Mark the highest bit as negative } return buf, nil } / / Decoding function (corresponding encoding logic) func decodeValue(buf []byte, valueType ValueType) (float64, error) { switch len(buf) { case 1: return float64(uint8(buf[0])) / 100, nil case 2: return float64(binary.LittleEndian.Uint16(buf)) / 100, nil case 4: isNegative := (buf[3]&0x80) != 0 if isNegative { buf[3]&^= 0x80} val := float64(binary.LittleEndian.Uint32(buf)) / 100 if isNegative { val = -val} return val, nil default: return 0, errors.New("invalid value buffer length (1 / 2 / 4 bytesrequired)") } } Meanwhile, the Protobuf message definition (in the .proto file) is as follows: protobuf syntax = "proto3"; package prometheus_metric; / / Binary structure of a single indicator message MetricPoint { uint32 metric_id = 1; / / Metric name ID (1 byte) repeatedLabelPair labels = 2; / / List of label key-value pairs ValueType value_type = 3; / / Numeric type (GAUGE / COUNTER / HISTOGRAM) bytes value = 4; / / The dynamically encoded numerical value int64 timestamp = 5; / / Data collection timestamp (milliseconds) } / / Tag key-value pairs message LabelPair { uint32 label_key_id = 1; / / Label key ID (1 byte) bytes label_value = 2; / / Label value (UTF-8 encoded) } / / Numeric type enumeration enum ValueType { GAUGE = 0; COUNTER = 1; HISTOGRAM = 2; } / / Incremental indicator set message MetricBatch { uint32 exporter_id = 1; / / Unique identifier for the exporter (4 bytes) uint64 version = 2; / / CRC32 version number (8 bytes) repeated MetricPoint metrics = 3; / / List of incremental metrics uint32 total_count = 4; / / Total number of indicators in this batch (for verification) } In step S1044, based on preset mapping rules, the selected incremental data is mapped to target state data that conforms to a preset transmission format.

[0033] In implementation, each Exporter component can maintain a MetricCache structure (used to cache the version number and metric set of the last sent data), with the following logic: / / Metrics cache maintained by the Exporter component type MetricCache struct { lastVersionuint64 / / The version number of the last sent version lastMetricsmap[string]MetricPoint / / The last set of metrics sent (key: metric_id + label combination) mutexsync.RWMutex } / / Filter incremental data (only send metrics that show version changes) func (c MetricCache) getDeltaMetrics(currentMetrics []MetricPoint)([]MetricPoint, uint64) { c.mutex.RLock() defer c.mutex.RUnlock() var deltaMetrics[]MetricPoint currentMetricMap := make(map[string]MetricPoint) / / 1. Construct a hash map for the current metric (key: metric_id + tag key combination) for _, mp := range currentMetrics { key := getMetricKey(mp) / / Such as "0x01_0x81:192.168.1.1_0x82:default" currentMetricMap[key] = mp } / / 2. Compare with the previous indicator set and filter for newly added / changed indicators. for key, currentMP := range currentMetricMap { if lastMP, exists := c.lastMetrics[key]; !exists { deltaMetrics = append(deltaMetrics, currentMP) / / Add new metrics } else { / / Determination of numerical change (error > 0.01) currentVal, _ := decodeValue(currentMP.Value, currentMP.ValueType) lastVal, _ := decodeValue(lastMP.Value, lastMP.ValueType) if math.Abs(currentVal-lastVal)>0.01 { deltaMetrics = append(deltaMetrics, currentMP) } } } / / 3. Calculate the current version number (CRC32 algorithm) currentVersion := calculateVersion(currentMetrics) / / 4. Update the cache (only when there is an increment) if len(deltaMetrics)>0 { c.lastVersion = currentVersion c.lastMetrics = currentMetricMap } return deltaMetrics, currentVersion } / / Calculate the CRC32 version number (timestamp + indicator set hash) func calculateVersion(metrics []MetricPoint) uint64 { timestamp := uint64(time.Now().UnixMilli()) / / Metric set hash (first 4 bytes of SHA-1) metricSetStr := getMetricSetString(metrics) hash := sha1.Sum([]byte(metricSetStr)) hashBytes := hash[:4] / / Concatenate the timestamp and hash, then calculate the CRC32. rawData := append(uint64ToBytes(timestamp), hashBytes...) crc32Val := crc32.ChecksumIEEE(rawData) / / Version number = timestamp (8 bytes) + CRC32 (4 bytes, padded with zeros to expand to 8 bytes) return (timestamp<<32) | uint64(crc32Val) } In this way, the Exporter component can map the filtered incremental data to the target state data through incremental synchronization, and send the incremental data to the data retrieval component (i.e., the Server component), avoiding repeated transmission of the same data and reducing network traffic.

[0034] The dictionary mapping algorithm for the above binary encoding and incremental synchronization algorithm is as follows: Each Exporter component can load a local dictionary table at startup via (". / metric_dict.json"), mapping the metric name and tag key to a 1-byte ID (metric ID 0x01-0x7F, tag ID 0x80-0xFF); when adding a new metric / tag, it automatically assigns an unused ID and backs up the old table.

[0035] The numerical dynamic coding algorithm is as follows: The storage length is selected based on the numerical range. The specific rules and code implementation are as follows: 1. If the value is within the range of [0, 2.55] (corresponding to index value 0.00~2.55), use 1 byte for storage (encoding: directly convert to uint8, decoding: uint8 → float64 / 100). 2. If the value is within the range of (2.55, 655.35], use 2 bytes to store it (encoding: convert to uint16, decoding: uint16 → float64 / 100). 3. If the value range exceeds 655.35, use 4 bytes for storage (encoding: convert to uint32, decoding: uint32 → float64 / 100); 4. Negative numbers are uniformly stored using 4 bytes, marked by the highest bit (bit31) (encoding: take the absolute value → uint32, set bit31 to 1; decoding: clear bit31 → uint32 → float64 / 100, add a negative sign).

[0036] Version number generation and verification algorithm: The version number can be calculated from the timestamp and the hash value of the indicator set using CRC32, as follows:

[0037] Where Version is the version number, Timestamp is the current timestamp, Hash(Metric_Set) is the hash value of the current metric set, and CRC32 is a 32-bit cyclic redundancy check algorithm.

[0038] In addition, it can support user-defined tag key mappings (such as mapping service_name to ID=101), reducing dynamic negotiation overhead.

[0039] In practical applications, the specific processing method for parallel transmission of target state data to the data retrieval component in step S106 above can vary. The following provides one optional processing method, such as... Figure 4 As shown, the specific process may include the following steps S1062 to S1064.

[0040] In step S1062, the data stream transmission priority corresponding to each target state data is determined according to the transmission priority of the indicator data contained in the target state data.

[0041] In implementation, the server can determine the transmission priority of indicator data contained in the target state data based on a preset correspondence between indicators and priorities. This preset correspondence can be determined based on historical state data. For example, indicator data such as CPU and memory can have a higher transmission priority, while indicator data such as disk and nodes can have a lower transmission priority.

[0042] The server can allocate higher data stream transmission priority to high-priority indicator data to ensure that high-priority indicator data is retrieved within a preset time range, thereby reducing the overall data collection latency.

[0043] In step S1064, target state data is transmitted to the data retrieval component in parallel based on the data stream transmission priority corresponding to each target state data.

[0044] In implementation, to improve the efficiency of collecting key metrics, the Exporter component can allocate dedicated data streams to high-priority metrics (such as CPU utilization and memory utilization) and set high transmission weights (e.g., greater than 80) to ensure that they are retrieved within a preset time range (e.g., 10ms). Lower-priority metrics can share the remaining bandwidth, thereby effectively reducing overall collection latency.

[0045] In practical applications, the specific processing method for transmitting target state data to the data retrieval component in parallel based on the data stream transmission priority corresponding to each target state data in step S1064 can be varied. The following provides an optional processing method, which may specifically include the processing of steps A1 to A3.

[0046] In step A1, the data stream transmission weight corresponding to each target state data is determined based on the data stream transmission priority.

[0047] In implementation, HTTP / 2 flow control can use a window mechanism, where each stream can have an independent flow control window to limit the sender's sending rate. Weights can be transmitted through the data stream to influence the window allocation ratio.

[0048] In step A2, based on the traffic window size and the data stream transmission weight corresponding to each target state data, a sub-traffic window corresponding to each target state data is determined.

[0049] In implementation, the sub-flow window corresponding to each target state data can be determined by the following formula:

[0050] Where Window_Sizei can be the sub-flow window corresponding to the i-th target state data, Weighti can be the data flow transmission weight corresponding to the i-th target state data, ∑j=1nWeightj is the sum of all data flow transmission weights, and Total_Window can be the flow window size.

[0051] In step A3, based on the sub-traffic window, the transmission rate corresponding to each target state data is determined, and the target state data is transmitted to the data fetching component in parallel at the transmission rate corresponding to each target state data.

[0052] In implementation, the data acquisition component can also transmit target state data to the data retrieval component in parallel based on the following priority scheduling strategy: 1. The data stream transmission weight for indicator data with higher data stream transmission priority can be set to 90, and the data stream transmission weight for indicator data with lower data stream transmission priority can be set to 10. 2. A weighted round-robin algorithm is used to allocate transmission opportunities. High-priority data streams can be transmitted once every 2 scheduling cycles, while low-priority data streams can be transmitted once every 10 cycles. 3. Dynamic adjustment of flow control window: Every 2 DATA frames (16384 bytes / frame) received can trigger a window update, with an increment of 8192 bytes, to ensure that high-priority data in the data stream takes priority in occupying bandwidth.

[0053] In practical applications, the specific processing method for sending preset alarm information to the target node in step S110 above can vary. The following provides one optional processing method, such as... Figure 5 As shown, the process may specifically include the following steps, S1102.

[0054] In step S1102, a preset alarm message is sent to the target node via a long connection established based on the WebSocket protocol, using the first channel.

[0055] The first channel can be a Slack channel, an email channel, etc.

[0056] In implementation, asynchronous alarm pushes between Alertmanager and the receiving end (i.e., the target node with the anomaly) can be achieved based on the WebSocket protocol (RFC 6455 standard). Core functionalities include: Establishing a long-lived connection based on WebSocket: Alertmanager can conduct a TLS encrypted handshake with the receiving end, negotiating the sub-prom-alert-v1 protocol and the compression extension (permessage-deflate). The core code is as follows: func dialWebSocket(addr string) ( websocket.Conn, error) { header := http.Header{} header.Set("Sec-WebSocket-Protocol", "prom-alert-v1") header.Set("Sec-WebSocket-Extensions", "permessage-deflate; client_max_window_bits=15") dialer := websocket.Dialer{ HandshakeTimeout: 1 time.Second, ReadBufferSize: 4096, WriteBufferSize: 4096, EnableCompression: true, / / Enable compression } conn, resp, err := dialer.Dial(addr, header) if err != nil { return nil, fmt.Errorf("handshake failed: %v", err) } / / Verify the sub-protocol negotiation result if resp.Header.Get("Sec-WebSocket-Protocol") != "prom-alert-v1" { conn.Close() return nil, errors.New("subprotocol negotiation failed") } return conn, nil } After establishing a long connection based on WebSocket, preset alarm information can be sent to the target node based on this long connection and the first channel.

[0057] In practical applications, the specific processing method for sending preset alarm information to the target node based on the first channel in step S1102 above can be varied. The following provides an optional processing method, which may specifically include the processing of steps B1 to B4.

[0058] In step B1, using a long connection established based on the WebSocket protocol, detection data is sent to the first channel based on a preset detection period, and feedback data from the target node in response to the detection data is collected.

[0059] In step B2, the first channel is assessed for faults based on the feedback data, and the first channel is determined to be in a fault state based on the assessment results.

[0060] In implementation, for example, a long connection can be established based on the WebSocket protocol, and a binary heartbeat frame can be sent to the first channel every 10 seconds as a detection (the frame structure may include 1 byte type, 8 bytes timestamp, 4 bytes average latency, 2 bytes failure count and 2 bytes CRC16 check).

[0061] If there is no response after three consecutive heartbeats, or if the average delay is greater than the preset delay threshold (e.g., 500ms), the first channel can be marked as faulty.

[0062] In step B3, if the first channel is not in a faulty state, a preset alarm message is sent to the target node based on the first channel.

[0063] In step B4, if the first channel is in a faulty state, a preset alarm message is sent to the target node based on the second channel.

[0064] In implementation, a primary channel (i.e., the first channel) and a backup channel (i.e., the second channel) can be configured to switch to the backup channel for information transmission in the event of a failure of the primary channel. For example, the first channel can be a Slack channel and the second channel can be an email channel. If the first channel is in a failure state, the system can switch to the backup channel within 100ms. The core logic can be to shut down the primary channel, verify the availability of the backup channel, and update the current channel reference to ensure that the alarm delivery rate is greater than 99.9%.

[0065] Based on the alarm management methods described above, a system can be built as follows: Figure 6The alarm system shown can achieve efficient and reliable data acquisition and alarm processing through the collaborative work of the protocol adaptation layer, asynchronous notification module and priority scheduler.

[0066] In terms of data acquisition, the system upgrades the communication protocol between the Prometheus Server component and the Exporter component from HTTP / 1.1 to HTTP / 2, utilizing its multiplexing mechanism to transmit multiple indicator data streams in parallel within a single TCP long connection.

[0067] In terms of data transmission, this alarm system can use Protocol Buffers to define a lightweight binary format, mapping indicator names and tag keys using a dictionary, replacing strings with 1-byte IDs to reduce transmission volume. Simultaneously, it can dynamically select the storage length based on the numerical range, further compressing the data volume. Each Exporter component can maintain a version number based on CRC32 checksum, transmitting only incremental data reflecting version changes, reducing duplicate transmissions by more than 80%, thus improving network transmission efficiency and the parsing speed of the Server component.

[0068] Regarding alarm notifications, the alarm system utilizes a WebSocket long-connection mechanism to enable asynchronous push notifications between Alertmanager and the receiving end. The receiving end can provide feedback on the processing status via ACK frames. The alarm system can configure primary and backup channels (e.g., a Slack channel as the primary channel and an email channel as the backup channel) and monitor channel status in real time (10-second heartbeat detection). When the primary channel latency exceeds 500ms or the failure rate exceeds 10%, the alarm system can automatically switch to the backup channel with a switching time of less than 100ms, thus ensuring the real-time performance and reliability of alarm notifications, with a delivery rate exceeding 99.9%.

[0069] The protocol adaptation layer is responsible for upgrading the traditional HTTP / 1.1 protocol to HTTP / 2 and managing communication for the Exporter components. Its core functions include: HTTP / 2 long connection multiplexing: enabling parallel transmission of multiple streams through a single TCP long connection; Stream priority scheduling: to improve the efficiency of key indicator collection, the alarm system allocates dedicated streams to high-priority indicators (such as CPU utilization and memory utilization) and sets high transmission weights (e.g., no less than 80) to ensure they are retrieved within 10ms. Low-priority indicators can share the remaining bandwidth, and the transmission rate is dynamically adjusted through a flow control window, effectively reducing overall collection latency by more than 80% compared to traditional methods. Protocol Buffers are used to encode indicator data in binary form, enabling lightweight transmission and maintaining the version number of each Exporter component, transmitting only incremental data reflecting version changes.

[0070] The priority scheduler coordinates the transmission priorities of multiple streams, ensuring that critical metrics are transmitted first. Its scheduling algorithm is as follows: Stream weight allocation rule: The stream weight for high-priority metrics is no less than 80, and the stream weight for low-priority metrics is no greater than 20. Dynamic adjustment of flow control window: The flow control window size for each stream is dynamically adjusted according to network conditions to ensure that high-priority metrics are transmitted first. Transmission latency control: Through priority scheduling, high-priority metrics are ensured to be retrieved within 10ms, reducing overall collection latency by more than 80%.

[0071] In summary, the alarm system, through the collaborative design of the protocol adaptation layer, asynchronous notification module, and priority scheduler, can achieve comprehensive optimization of monitoring data collection and alarm push, and has high technical innovation value and practical application significance.

[0072] Let's take the standard deployment mode as an example: 1. Exporter component initialization: (1) Loading dictionary table: When the Exporter component starts, it reads ` / etc / prometheus / exporter / metric_dict.json`. If it does not exist, it generates a default table (containing 30 commonly used metrics / label mappings). (2) Initialize cache: Create a MetricCache instance, initially lastVersion=0, lastMetrics=empty map; (3) Start the HTTP / 2 service: listen on port 9200, load the TLS certificate (path ` / etc / prometheus / cert / `), configure the maximum number of concurrent streams = 100, and IdleConnTimeout = 30s.

[0073] 2. The Prometheus Server component establishes an HTTP / 2 connection: (1) Initialize the HTTP / 2 client: Configure the transport pool using newHTTP2Transport() (MaxIdleConns=100, TLSHandshakeTimeout=100ms). (2) Configure the pull target: Modify prometheus.yml and point the pull address to the PAG gateway (HTTP / 2 port 8443), as follows: scrape_configs: - job_name: 'high-priority-metrics' static_configs: - targets: ['pag-ip:8443'] params: priority: ['90'] # High priority metrics (CPU / Memory) scrape_interval: 5s - job_name: 'low-priority-metrics' static_configs: - targets: ['pag-ip:8443'] params: priority: ['10'] # Low priority metrics (disk / node) scrape_interval: 30s 3. Stream allocation and priority setting: After receiving the request from the Server component, PAG assigns StreamID=1 (CPU), 3 (memory), and weight=90 to high-priority metrics; Assign StreamID=2 (disk), 4 (node ​​information), and weight=10 to low-priority metrics; Start a StreamScheduler instance and perform scheduling every 10ms to ensure that high-priority streams are transmitted first.

[0074] 4. Data Acquisition and Encoding: The Exporter component collects metrics every 5 seconds and generates a list of currentMetrics. Call getDeltaMetrics() to filter incremental data and calculate currentVersion; If there is an increment, it is encoded into a MetricBatch structure using Protocol Buffers and transmitted via HTTP / 2DATA frames (frame size = 16384 bytes).

[0075] 5. Incremental data transmission: After receiving the MetricBatch, PAG verifies the version against the local cache. If it is a new version, it translates it into text format and sends it back to the Server component via HTTP / 1.1. PAG transmits the X-Metric-Priority and X-Metric-Version header fields, which are then parsed by the Server component and updated in local storage.

[0076] 6. Alarm push preparation: Alertmanager initializes the WebSocket client: it calls dialWebSocket() to connect to the main channel (wss: / / slack-notify.example.com:8080 / alert-ws). Pre-establish a backup channel: Connect to the backup channel (wss: / / mail-notify.example.com:8080 / alert-ws) and keep it idle to reduce switchover time; Start the heartbeat goroutine: Send a heartbeat frame every 10 seconds to monitor the channel status.

[0077] 7. Alarm push notifications and channel switching: When an alarm is triggered, Alertmanager encodes the alarm in Protobuf format (AlertBatch structure) and pushes it asynchronously via WebSocket; After processing, the receiving end replies with an ACK frame (containing the batch ID), and Alertmanager records the transmission delay; If the main channel latency is >500ms, a switchover is triggered: close the main channel → update the current channel to the backup channel → continue pushing. The switchover takes 85ms.

[0078] The following explanation uses a multi-Exporter component deployment mode as an example: In large-scale monitoring scenarios (such as a 1000-node cluster), the alarm system can support the parallel deployment of multiple Exporter components, with each Exporter component independently running the following logic: 1. Each Exporter component is assigned a unique ID (based on IP + port hash, 4 bytes) to avoid version number conflicts; 2. Each Exporter component independently maintains its own dictionary table and MetricCache, and only transmits its own incremental data; 3. The PrometheusServer component coordinates the pull tasks of multiple Exporter components through the "load balancing module" (based on the Round-Robin algorithm) of the PAG gateway, ensuring that a single PAG node can support 200 concurrent connections of Exporter components; 4. The priority scheduler allocates bandwidth based on a dual priority of "Exporter component type + indicator type": the high priority indicator weight of core business Exporter components is 95, and the high priority indicator weight of non-core business Exporter components is 70, ensuring that core business takes priority.

[0079] To illustrate using a hybrid channel deployment mode: In practical applications, alarm notification channels can be configured in various ways (Slack, email, SMS), and the alarm system can support three-level channel switching: primary-backup-emergency. 1. Main channel (Slack channel): Used for real-time alarms (response latency requirement <300ms), heartbeat detection interval 10s; Backup channel (email channel): Used for alarm backup in case of primary channel failure (response latency requirement <1s), and maintains connection with the primary channel at the same time; Emergency Channel (SMS Channel): Used for emergency alarms when both primary and backup channels fail (only critical level alarms are sent), and calls the SMS gateway via HTTP API; 2. Switching logic: If the main channel fails, switch to the backup channel; if the backup channel fails, switch to the emergency channel; once either channel is restored, automatically switch back to the higher priority channel.

[0080] In certain scenarios, the alarm system can dynamically adjust the stream weights based on network conditions. For example, when network bandwidth is sufficient, the weights of high-priority streams can be appropriately reduced to balance overall transmission efficiency; when network bandwidth is limited, the weights of high-priority streams can be increased to ensure that critical indicators are transmitted first.

[0081] Thus, engineering challenges are addressed by adding an HTTP / 2 Protocol Adaptation Gateway (PAG): PAG supports dual-protocol listening (port 8080 for HTTP / 1.1 and port 8443 for HTTP / 2), dynamically selecting the communication method based on the ALPN protocol, and is compatible with existing HTTP / 1.1 Exporters; PAG translates HTTP / 2 binary data into a text format compatible with the Prometheus Server component, and transmits metadata through the X-Metric-Priority and X-Metric-Version header fields, ensuring collaboration with the Alertmanager and Grafana ecosystem; PAG configures TCP long connection parameters (KeepAlive=30s, IdleConnTimeout=90s) to reduce connection rebuilding overhead. Communication between the Server and Exporter components is upgraded to HTTP / 2, leveraging multiplexing capabilities to transmit multiple sets of metric data in parallel within a single TCP long connection. By assigning dedicated streams to high-priority metrics (such as CPU utilization and memory utilization) and setting transmission weights (weight range 1-100), key metrics are ensured to be retrieved within 10ms; low-priority metrics share the remaining bandwidth, and the transmission rate is dynamically adjusted through a flow control window. This solves the efficiency bottleneck of HTTP / 1.1 single-connection serial transmission, eliminates redundant TCP handshake overhead, and reduces data acquisition latency by more than 80%. By upgrading the communication protocol between the Server component and the Exporter component from HTTP / 1.1 to HTTP / 2, and utilizing its multiplexing and stream priority scheduling mechanisms, multiple metric data streams are transmitted in parallel within a single TCP long connection. This avoids the serial requests and redundant handshake overhead of HTTP / 1.1, reducing the acquisition latency of key metrics to less than 10ms and the overall acquisition latency by more than 80%, effectively solving the high latency problem caused by low protocol efficiency in existing technologies.

[0082] A lightweight binary format is defined using Protocol Buffers, employing dictionary mapping for metric names and tag keys (e.g., using 1-byte IDs instead of strings). Numerical types dynamically select their storage length based on their range (e.g., 1 byte for 0-100, 4 bytes for 100+). A metric version number is maintained for each Exporter component (based on CRC32 checksum), transmitting only incremental data where the version number changes, reducing redundant transmissions by over 80%. Compared to traditional text formats, the transmission volume of a single metric is reduced by 60%-70%, and parsing time is reduced by 50%, significantly improving network transmission efficiency and server-side processing speed, and resolving the redundancy and low transmission efficiency issues of existing text formats.

[0083] Alertmanager establishes a WebSocket long-lived connection with the receiving end, sending alarms asynchronously via push. The receiving end provides feedback on the processing status via ACK frames. A primary and backup channel (e.g., a Slack primary channel and an email backup channel) are configured, and channel status is monitored in real time (with a 10-second heartbeat check). When the primary channel latency exceeds 500ms or the failure rate exceeds 10%, the system automatically switches to the backup channel, with a switchover time of <100ms. This eliminates the blocking problem of synchronous HTTP requests, reducing alarm notification latency from seconds to sub-seconds, and improves notification reliability (delivery rate >99.9%) through dynamic channel switching. The introduction of the WebSocket long-lived connection mechanism enables asynchronous push between Alertmanager and the receiving end, eliminating the blocking problem of synchronous HTTP requests and reducing alarm notification latency from seconds to sub-seconds. Simultaneously, configuring primary and backup channels and monitoring channel status in real time allows for automatic switchover to the backup channel when the primary channel fails, with a switchover time of <100ms and a delivery rate exceeding 99.9%, resolving the problems of high alarm notification latency and poor reliability in existing technologies.

[0084] By maintaining the version number of each Exporter component (based on CRC32 checksum), only incremental data with version changes is transmitted, so that static metrics do not need to be transmitted in a stable state, thereby reducing the amount of duplicate transmission by more than 80% and effectively alleviating the network load and processing latency problems caused by the traditional full data retrieval mode.

[0085] The system has been systematically optimized from the protocol layer and data transmission layer to the alarm notification layer, forming a complete optimized system that includes a protocol adaptation layer, an asynchronous notification module, and a priority scheduler. The modules work together to achieve an overall performance improvement in monitoring data collection and alarm push, meeting the needs of scenarios with extremely high requirements for fault response time, such as finance and real-time computing.

[0086] This alarm system has the following value: 1. Broad target market: Industries such as finance, e-commerce, and smart manufacturing are sensitive to alarm latency (e.g., high-frequency trading requires fault response time of <1 second). Existing solutions cannot meet these needs. This alarm system can provide a low-cost, highly compatible protocol-level optimization solution that is compatible with existing Prometheus clusters, and has huge potential for market penetration.

[0087] Technical barriers and differentiation: Unlike existing storage layer or rule engine optimizations, it focuses on the underlying transformation of communication protocols, forming a unique technical path. The combination of HTTP / 2 multiplexing, binary incremental transmission, and WebSocket asynchronous notification can achieve a breakthrough in latency from 30 seconds to sub-seconds without changing the core architecture of Prometheus, demonstrating significant technical advantages.

[0088] 2. Strong match with customer pain points: Enterprise users generally face the problem of "delayed monitoring and alarms leading to slow fault recovery". A test by a major Internet company showed that this solution can reduce fault recovery time by 70% and indirectly reduce operation and maintenance costs by more than 30%.

[0089] This specification provides an alarm management method. It utilizes a data acquisition component to collect status data of target nodes within the current monitoring period. Based on preset mapping rules, the status data is mapped to target status data conforming to a preset transmission format. In a long-lived connection established between the data acquisition component and the data retrieval component, a multiplexing mechanism is used to transmit the target status data to the data retrieval component in parallel. Based on the target status data in the data retrieval component, it is determined whether the target node is abnormal. If an abnormality is determined, a preset alarm message is sent to the target node. Thus, by converting the format of the collected target node status data through preset mapping rules, the transmission volume can be reduced, and data transmission efficiency can be improved. Simultaneously, the HTTP / 2 multiplexing mechanism can improve the parallelism of acquisition, shorten the overall acquisition latency, improve data retrieval efficiency, and avoid delays in abnormal alarms.

[0090] The above describes the alarm management method provided in the embodiments of this specification. Based on the same idea, the embodiments of this specification also provide an alarm management device, such as... Figure 7 As shown.

[0091] The alarm management device includes: a data acquisition module 701, a data mapping module 702, a data transmission module 703, an anomaly judgment module 704, and an anomaly alarm module 705, wherein: Data acquisition module 701 is used to acquire status data of target nodes within the current monitoring period using data acquisition components; The data mapping module 702 is used to map the state data into target state data that conforms to a preset transmission format based on preset mapping rules. The data transmission module 703 is used to transmit the target state data to the data extraction component in parallel using a multiplexing mechanism in the long connection established between the data acquisition component and the data extraction component. The anomaly detection module 704 is used to determine whether the target node has an anomaly based on the target state data retrieved from the data pull component. The anomaly alarm module 705 is used to send preset alarm information to the target node when it is determined that there is an anomaly in the target node.

[0092] The various embodiments in this specification are described in a progressive 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 alarm management device 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.

[0093] This specification provides an alarm management device that utilizes a data acquisition component to collect status data of target nodes within the current monitoring period. Based on preset mapping rules, the status data is mapped to target status data conforming to a preset transmission format. In a long-lived connection established between the data acquisition component and the data retrieval component, a multiplexing mechanism is used to transmit the target status data to the data retrieval component in parallel. Based on the target status data in the data retrieval component, it is determined whether the target node is abnormal. If an abnormality is determined, a preset alarm message is sent to the target node. Thus, by converting the format of the collected target node status data through preset mapping rules, the transmission volume can be reduced and the data transmission efficiency improved. Simultaneously, the HTTP / 2 multiplexing mechanism can improve the parallelism of acquisition, shorten the overall acquisition latency, improve data retrieval efficiency, and avoid delays in abnormal alarms.

[0094] The above are the alarm management devices provided in the embodiments of this specification. Based on the same idea, the embodiments of this specification also provide an alarm management device, such as... Figure 8 As shown.

[0095] The alarm management device can provide terminal devices or servers, etc., for the above embodiments.

[0096] Alarm management devices can vary significantly due to differences in configuration and performance. They may include one or more processors 801 and memory 802, with memory 802 storing one or more application programs or data. Memory 802 may be temporary or persistent storage. The application programs stored in memory 802 may include one or more modules (not shown in the figures), each module including a series of computer-executable instructions for the alarm management device. Furthermore, processor 801 may be configured to communicate with memory 802, executing the series of computer-executable instructions in memory 802 on the alarm management device. The alarm management device may also include one or more power supplies 803, one or more wired or wireless network interfaces 804, one or more input / output interfaces 805, and one or more keyboards 806.

[0097] Specifically, in this embodiment, the alarm management device includes a memory and one or more programs, wherein one or more programs are stored in the memory, and one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the alarm management device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following: Use data acquisition components to collect status data of target nodes within the current monitoring period; Based on preset mapping rules, the state data is mapped to target state data that conforms to a preset transmission format; In the long connection established between the data acquisition component and the data retrieval component, the target state data is transmitted to the data retrieval component in parallel using a multiplexing mechanism; Based on the target state data in the data retrieval component, it is determined whether the target node is abnormal; If an anomaly is detected in the target node, a preset alarm message is sent to the target node.

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

[0099] This specification provides an alarm management device that utilizes a data acquisition component to collect status data of target nodes within the current monitoring period. Based on preset mapping rules, the status data is mapped to target status data conforming to a preset transmission format. In a long-lived connection established between the data acquisition component and the data retrieval component, a multiplexing mechanism is used to transmit the target status data to the data retrieval component in parallel. Based on the target status data in the data retrieval component, it is determined whether the target node is abnormal. If an abnormality is determined, a preset alarm message is sent to the target node. Thus, by converting the format of the collected target node status data through preset mapping rules, the transmission volume can be reduced and the data transmission efficiency improved. Simultaneously, the HTTP / 2 multiplexing mechanism can improve the parallelism of acquisition, shorten the overall acquisition latency, improve data retrieval efficiency, and avoid delays in abnormal alarms.

[0100] Furthermore, based on the above Figures 1 to 6The method shown in this specification, along with one or more embodiments, also provides a storage medium for storing computer-executable instruction information. In one specific embodiment, the storage medium can be a USB flash drive, optical disc, hard disk, etc. When the computer-executable instruction information stored in the storage medium is executed by a processor, it can achieve the following process: Use data acquisition components to collect status data of target nodes within the current monitoring period; Based on preset mapping rules, the state data is mapped to target state data that conforms to a preset transmission format; In the long connection established between the data acquisition component and the data retrieval component, the target state data is transmitted to the data retrieval component in parallel using a multiplexing mechanism; Based on the target state data in the data retrieval component, it is determined whether the target node is abnormal; If an anomaly is detected in the target node, a preset alarm message is sent to the target node.

[0101] The various embodiments in this specification are described in a progressive 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 above-described storage medium embodiment is basically similar to the method embodiment, so the description is relatively simple; relevant parts can be referred to the description of the method embodiment.

[0102] This specification provides a storage medium that utilizes a data acquisition component to collect status data of a target node within the current monitoring period. Based on a preset mapping rule, the status data is mapped to target status data conforming to a preset transmission format. In a long-lived connection established between the data acquisition component and the data retrieval component, a multiplexing mechanism is used to transmit the target status data to the data retrieval component in parallel. Based on the target status data in the data retrieval component, it is determined whether the target node exhibits an anomaly. If an anomaly is determined, a preset alarm message is sent to the target node. Thus, by converting the format of the collected target node status data through the preset mapping rule, the transmission volume can be reduced, and data transmission efficiency can be improved. Simultaneously, the HTTP / 2 multiplexing mechanism can enhance the parallelism of acquisition, shorten the overall acquisition latency, improve data retrieval efficiency, and avoid delays in anomaly alarms.

[0103] Furthermore, based on the above Figures 1 to 6 The method shown in this specification, along with one or more embodiments, also provides a computer program product including a computer program that, when executed by a processor, performs the following process: Use data acquisition components to collect status data of target nodes within the current monitoring period; Based on preset mapping rules, the state data is mapped to target state data that conforms to a preset transmission format; In the long connection established between the data acquisition component and the data retrieval component, the target state data is transmitted to the data retrieval component in parallel using a multiplexing mechanism; Based on the target state data in the data retrieval component, it is determined whether the target node is abnormal; If an anomaly is detected in the target node, a preset alarm message is sent to the target node.

[0104] The various embodiments in this specification are described in a progressive 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 above-described embodiment of a computer program product is relatively simple in description because it is fundamentally similar to the method embodiment; relevant parts can be referred to the description of the method embodiment.

[0105] This specification provides a computer program product that utilizes a data acquisition component to collect status data of a target node within the current monitoring period. Based on preset mapping rules, the status data is mapped to target status data conforming to a preset transmission format. In a long-lived connection established between the data acquisition component and the data retrieval component, a multiplexing mechanism is used to transmit the target status data to the data retrieval component in parallel. Based on the target status data in the data retrieval component, it is determined whether the target node exhibits any anomalies. If an anomaly is determined, a preset alarm message is sent to the target node. Thus, by converting the format of the collected target node status data through preset mapping rules, the transmission volume can be reduced, and data transmission efficiency can be improved. Simultaneously, the HTTP / 2 multiplexing mechanism can enhance the parallelism of data acquisition, shorten the overall acquisition latency, improve data retrieval efficiency, and avoid delays in anomaly alarms.

[0106] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0107] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0108] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) that can be executed by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers.

[0109] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, when implementing one or more embodiments of this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0110] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0111] Embodiments in this specification are described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable parallel device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable parallel device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0112] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable fraud device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0113] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0114] Computer-readable media includes both permanent and non-permanent, removable and non-removable media, and information storage can be achieved by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. As defined herein, computer-readable media does not include transient media, such as modulated data signals and carrier waves.

[0115] It should also be noted that 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 limitation, 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 said element.

[0116] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0117] The various embodiments in this specification are described in a progressive 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 system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0118] The above description is merely an embodiment of this specification and is not intended to limit this document. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. An alarm management method, characterized in that, The method includes: Use data acquisition components to collect status data of target nodes within the current monitoring period; Based on preset mapping rules, the state data is mapped to target state data that conforms to a preset transmission format; In the long connection established between the data acquisition component and the data retrieval component, the target state data is transmitted to the data retrieval component in parallel using a multiplexing mechanism; Based on the target state data in the data retrieval component, it is determined whether the target node is abnormal; If an anomaly is detected in the target node, a preset alarm message is sent to the target node.

2. The method according to claim 1, characterized in that, The step of mapping the state data into target state data conforming to a preset transmission format based on preset mapping rules includes: Based on the status data of the target node that has been transmitted in the historical monitoring period, incremental data in the status data of the target node in the current monitoring period is filtered out. Based on the preset mapping rules, the selected incremental data is mapped to target state data that conforms to the preset transmission format.

3. The method according to claim 1, characterized in that, The parallel transmission of the target state data to the data fetching component includes: Based on the transmission priority of the indicator data contained in the target state data, the data stream transmission priority corresponding to each target state data is determined; Based on the data stream transmission priority corresponding to each target state data, the target state data is transmitted to the data retrieval component in parallel.

4. The method according to claim 3, characterized in that, The method of transmitting the target state data to the data fetching component in parallel based on the data stream transmission priority corresponding to each target state data includes: Based on the data stream transmission priority, determine the data stream transmission weight corresponding to each target state data; Based on the traffic window size and the data stream transmission weight corresponding to each target state data, a sub-traffic window corresponding to each target state data is determined; Based on the sub-traffic window, the transmission rate corresponding to each target state data is determined, and the target state data is transmitted to the data retrieval component in parallel at the transmission rate corresponding to each target state data.

5. The method according to claim 1, characterized in that, Sending preset alarm information to the target node includes: Using a long connection established based on the WebSocket protocol, a preset alarm message is sent to the target node via the first channel.

6. The method according to claim 5, characterized in that, The step of sending preset alarm information to the target node based on the first channel includes: Using a long connection established based on the WebSocket protocol, detection data is sent to the first channel based on a preset detection period, and feedback data from the target node in response to the detection data is collected. Based on the feedback data, a fault assessment is performed on the first channel, and based on the fault assessment result, it is determined whether the first channel is in a fault state. If the first channel is not in a faulty state, a preset alarm message is sent to the target node based on the first channel; If the first channel is in a faulty state, a preset alarm message is sent to the target node based on the second channel.

7. An alarm management device, characterized in that, The device includes: The data acquisition module is used to collect the status data of the target node within the current monitoring period using the data acquisition components. The data mapping module is used to map the state data into target state data that conforms to a preset transmission format based on preset mapping rules. The data transmission module is used to transmit the target state data to the data extraction component in parallel using a multiplexing mechanism in the long connection established between the data acquisition component and the data extraction component. The anomaly detection module is used to determine whether the target node has an anomaly based on the target state data retrieved from the data pull component. The anomaly alarm module is used to send preset alarm information to the target node when it is determined that there is an anomaly in the target node.

8. An alarm management device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the alarm management method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the steps of the alarm management method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the steps of the alarm management method according to any one of claims 1 to 6.

Images