A multi-dimensional health monitoring and state management system for field agent devices

Abstract

This invention belongs to the field of enterprise communication technology and discloses a multi-dimensional health monitoring and status management system for field agent devices. It includes a tunnel health perception module for periodically receiving heartbeat data from agent devices and generating trigger events; a device-level concurrency control module for acquiring mutex locks for agent devices; a heartbeat timeout detection module for detecting agent devices with timed heartbeats and triggering heartbeat timeout events via scheduled tasks, and performing secondary verification on the heartbeat timeout events; a multi-dimensional resource anomaly detector for performing anomaly judgment based on a dual-threshold time window algorithm on each detector instance of each agent device; a state machine module for driving the agent devices to transition between connected, disconnected, and abnormal states; and a three-atom synchronization module for distinguishing synchronization conditions. This invention solves practical operational and maintenance problems in existing monitoring schemes, such as lack of tunnel status perception, monitoring alarm jitter, and data loss due to concurrent race conditions.

Description

Technical Field

[0001] This invention relates to the field of enterprise communication technology, and in particular to a multi-dimensional health monitoring and status management system for field agent devices. Background Technology

[0002] In a hybrid deployment architecture of an enterprise communication system, the cloud-based PBX (Private Branch Exchange) platform is responsible for unified management and control. Field agent devices are deployed on the customer's local network. These field agent devices handle SIP (Session Initiation Protocol) phone registration, RTP (Real-time Transport Protocol) media stream forwarding, and local voice processing before forwarding data to the cloud-based PBX platform. Existing cloud-based PBX platforms typically use a heartbeat detection mechanism to determine if the field agent devices are functioning correctly. The cloud records the timestamp of the last heartbeat arrival for each device and runs a timed detection task. If the difference between the current time and the last heartbeat arrival time exceeds a preset timeout threshold, it is considered offline and an alarm is triggered. However, this mechanism cannot distinguish whether the offline status is due to network jitter caused by packet delays or loss, or device failure caused by process crashes.

[0003] Existing technologies use threshold-triggered methods to monitor the resource utilization of field agent devices. Resource utilization includes CPU (Central Processing Unit), memory, and disk utilization. Since CPU utilization is a continuously fluctuating time-series signal, when the overall system load approaches the alarm threshold, CPU utilization will frequently fluctuate around the threshold, generating significant alarm jitter. In high-concurrency scenarios, multiple heartbeat requests from the same device may simultaneously arrive at the cloud and trigger status updates for the same device. Due to the lack of fine-grained concurrency control mechanisms and the ambiguous thread execution sequence, the final updated state depends on the specific execution operation, leading to unpredictable errors. Furthermore, the storage of field agent device status data includes two levels of storage: local status storage for the cloud PBX heartbeat processing service and a database on the cloud management platform. The synchronization method involves first reading the current device status from the local status storage and generating a snapshot, then pushing this snapshot to the cloud management platform via a network interface. However, there is a time window between reading the snapshot and completing the push. Changes to the device status received within this time window cannot be captured, resulting in the permanent loss of intermediate device status data after the synchronization push is completed. This leads to a desynchronization of the device status data stored on the cloud management platform and in the local status storage. Furthermore, the heartbeat timeout detection suffers from a concurrent defect due to the TOCTOU (Time-of-Check-Time-of-Use) race condition. Summary of the Invention

[0004] The purpose of this invention is to provide a multi-dimensional monitoring and status management system for field agent equipment. Through the joint collaboration of multiple modules such as tunnel health perception, multi-dimensional resource anomaly detection, priority state machine, concurrency control, TOCTOU security verification, and three-state atomic synchronization, it solves the technical problems existing in the current monitoring scheme, such as the lack of tunnel status perception, resource monitoring alarm jitter, data inconsistency caused by concurrency race conditions, and data loss.

[0005] In a first aspect, embodiments of the present invention provide a multi-dimensional health monitoring and status management system for field agent devices, characterized in that it includes: The tunnel health awareness module is used to periodically receive heartbeat data from the proxy device and generate trigger events. The heartbeat data includes the current proxy device's unique identifier, CPU usage, memory usage, disk usage, and tunnel health status. The tunnel health status is used to indicate whether the secure tunnel carrying the current session initiation protocol signaling and real-time transmission protocol media stream is in an available state. The device-level concurrency control module is used to acquire the mutex lock of the proxy device, so that the state transition instructions of the same proxy device are executed serially; The heartbeat timeout detection module is used to detect agent devices with timed heartbeats and trigger heartbeat timeout events through a timed task. After acquiring the mutex lock and before executing the state transition, the heartbeat timeout event is verified a second time. If the agent device has resumed heartbeat, the current state transition is abandoned. A multi-dimensional resource anomaly detector is used to configure detector instances for CPU utilization, memory utilization, and disk utilization, respectively. It performs anomaly judgment based on a dual-threshold time window algorithm on each detector instance of each agent device and generates anomaly flag bits. The state machine module is used to maintain a state machine instance for each agent device with the device's unique identifier as the granularity. Based on the received trigger event, according to the exception flag bit and the preset state priority rules, it drives the agent device to switch between connected state, disconnected state and abnormal state, and writes the changed device state data into the memory cache. The three-atom synchronization module is used to combine preset synchronization timed tasks to distinguish the synchronization status between the agent device and the cloud management platform into synchronized, pending, and in-synchronization states, and ensures that data changes generated during the synchronization process are not lost through atomic state transitions.

[0006] Optionally, anomaly detection based on a dual-threshold time window algorithm is performed on each detector instance of each agent device, wherein, The detector instance includes a detection status field, a current usage rate field, an anomaly start time field, and a recovery start time field; The detection status field is used to record whether the current detector instance is in a normal or abnormal state; the current utilization rate field is used to record the parameter value of the utilization rate corresponding to the detector instance; the abnormal start time field is used to record the timestamp of the first time the utilization rate exceeds the preset load threshold; the recovery start time field is used to record the timestamp of the first time the utilization rate drops below the preset recovery threshold. The steps for anomaly detection include: When the detector instance is originally in a normal state, if the current utilization rate is greater than or equal to the preset load threshold, the first difference between the current time and the abnormal start time field is recorded, and when the first difference reaches the preset abnormal duration threshold, the detection status field is switched to the abnormal state, and the recovery start time field is cleared to zero; if the current utilization rate is less than the preset load threshold, the abnormal start time field is cleared to zero, and the detection status field remains in the current normal state. When the detector instance is originally in an abnormal state, if the current utilization rate is less than the preset load threshold, the second difference between the current time and the recovery start time field is recorded. When the second difference reaches the preset recovery duration threshold, the detection status field is switched to the normal state, and the abnormal start time field is cleared to zero. If the current utilization rate is greater than or equal to the preset load threshold, the recovery start time field is cleared to zero, and the detection status field remains in the current abnormal state.

[0007] Optionally, generate exception flags, including: The judgment results of each detector instance of CPU usage, memory usage, and disk usage are combined into an anomaly flag field through bitwise operations. The exception flag field is an integer value; wherein, the zeroth bit is used to indicate whether the CPU utilization is in an abnormal state, and is set to one if yes, otherwise it is set to zero; the first bit is used to indicate whether the memory utilization is in an abnormal state, and is set to one if yes, otherwise it is set to zero; the second bit is used to indicate whether the disk utilization is in an abnormal state, and is set to one if yes, otherwise it is set to zero.

[0008] Optionally, based on the received trigger event, and according to the exception flag and preset state priority rules, the agent device is driven to switch between connected state, disconnected state and exception state; The state priority rule is determined by the triggering event, wherein the triggering event includes a heartbeat reporting event, a heartbeat timeout event, and a key reset event; The state priority rules include: First priority: when the triggering event is a heartbeat timeout event, a key reset event, or a heartbeat reporting event and the tunnel health status is unavailable, switch the state machine instance to the disconnected state. The second priority is that when the agent device was originally in a disconnected state, the triggering event is a heartbeat reporting event, and the tunnel health status is available, if the value of the abnormal flag field is zero, the state machine instance is switched to the connected state; if the value of the abnormal flag field is not zero, the state machine instance is switched to the abnormal state. The third priority is that when the proxy device is originally in a connected state, the triggering event is a heartbeat reporting event, and the tunnel health status is available, if the value of the abnormal flag field is zero, the state machine instance remains in the connected state; if the value of the abnormal flag field is not zero, the state machine instance is switched to the abnormal state. Fourth priority: When the agent device was originally in an abnormal state, the triggering event was a heartbeat reporting event, and the tunnel health status was available, if the value of the abnormal flag field is zero, the state machine instance is switched to the connected state; if the value of the abnormal flag field is non-zero, the state machine instance remains in the abnormal state.

[0009] Optionally, the synchronization status between the agent device and the cloud management platform can be categorized into synchronized, pending, and in-process states, including: In the memory cache, configure a synchronization state field for each agent device to perform update operations via an atomic interface; When one or more of the state machine instance, configuration, and number of associated phones of the agent device change, the synchronization status field is set to the state to be synchronized. When the scheduled synchronization task starts, all agent devices in the pending synchronization state are converted to the synchronization state at once, and a list of device unique identifiers of the corresponding agent devices is returned. When the scheduled synchronization task is executed successfully, for the agent devices that were marked as pending synchronization due to data changes during the synchronization process, the pending synchronization state is maintained, and they wait to execute the next round of synchronization tasks; while the remaining agent devices that have successfully executed the task are marked as synchronized. When the scheduled synchronization task fails, all agent devices in the synchronization state will be rolled back to the waiting synchronization state.

[0010] Optionally, after acquiring the mutex lock but before executing the state transition, a secondary verification of the heartbeat timeout event is performed. The verification steps include: After acquiring the mutex lock and before performing the state transition, the timestamp of the last heartbeat data reported by the agent device is reread from the memory cache, and the difference between the current time and the timestamp is calculated. If the difference is less than or equal to the preset timeout threshold, it is determined that the agent device that was originally detected to have timed out has resumed heartbeat reporting, the heartbeat timeout event is invalidated, the mutex lock is released, and no state transition operation is performed. If the difference is greater than the preset timeout threshold, it is determined that the agent device is indeed in a heartbeat timeout state, and the state machine instance continues to perform state transition operations.

[0011] Optionally, the system further includes a platform adaptive synchronization adapter, used to select the corresponding tunnel service synchronization implementation method based on the platform type currently deployed in the system, including: When the deployment platform is a cloud-based PBX platform, a synchronization request is sent through the cloud application programming interface to push the configuration information of the agent device to the cloud tunnel service; When the deployment platform is a local PBX platform, it communicates with the tunnel service process running on the same device through the Hypertext Transfer Protocol on the local inter-process communication socket to synchronize the configuration information of the proxy device to the local tunnel service. Optionally, the system further includes an idempotent online phone count module, which reads the actual number of online phones under the current agent device from the database cache layer used to store the phone registration status when a phone goes online or offline event occurs, and directly overwrites the number of online phones in the memory cache.

[0012] Secondly, embodiments of the present invention also provide a method for multi-dimensional health monitoring and status management of field agent equipment, including: The system periodically receives heartbeat data from proxy devices and generates trigger events. The heartbeat data includes the current proxy device's unique identifier, CPU usage, memory usage, disk usage, and tunnel health status. The tunnel health status is used to indicate whether the secure tunnel for the current session initiation protocol signaling and real-time transport protocol media stream is available. Acquire the mutex lock of the proxy device to enable the state transition instructions of the same proxy device to be executed serially; The system detects agent devices that have timed out heartbeats and triggers a heartbeat timeout event via a scheduled task. After acquiring the mutex lock and before executing the state transition, the heartbeat timeout event is verified a second time. If the agent device has resumed heartbeat, the current state transition is abandoned. Configure detector instances for CPU usage, memory usage, and disk usage respectively, and perform anomaly detection based on a dual-threshold time window algorithm for each detector instance of each agent device to generate anomaly flag bits; Maintain a state machine instance with a unique device identifier for each agent device. Based on the received trigger event, drive the agent device to switch between connected, disconnected and abnormal states according to the exception flag and the preset state priority rules, and write the changed device state data into the memory cache. By combining preset synchronization timed tasks, the synchronization status between the agent device and the cloud management platform is divided into synchronized, pending, and synchronizing states, and atomic state transitions are used to ensure that data changes generated during the synchronization process are not lost.

[0013] This system, through the collaborative efforts of its various modules, constructs a highly reliable and high-performance field agent equipment monitoring and management system. At the data acquisition and anomaly detection level, it solves the alarm jitter problem caused by the traditional single-threshold detection method by introducing a dual-threshold time window algorithm with hysteresis effect. Furthermore, it incorporates tunnel health status as the highest priority judgment condition into the state machine decision-making process and designs a four-level priority mechanism to ensure that state transitions are performed according to business importance when multiple triggering events occur simultaneously, enabling the agent equipment to provide timely and accurate business services to the outside world.

[0014] This system also assigns an independent mutex lock to each device, enabling concurrent execution of state transition operations across different devices while serializing operations only on the same device. Furthermore, addressing the TOCTOU race condition in heartbeat timeout detection scenarios, the system performs secondary verification under the protection of the mutex lock, fundamentally eliminating the risk of incorrectly marking recovered devices as offline. Moreover, the system introduces a synchronization-in-progress state as an intermediate state in the three-atom synchronization module, ensuring that the synchronization completion operation only clears the synchronization-in-progress state, not the pending synchronization state, guaranteeing zero data loss during synchronization and achieving high concurrency processing capabilities and excellent scalability. This system significantly reduces the false alarm rate of field agent devices, improves the accuracy of state judgment and concurrency security, and guarantees eventual consistency of cloud data synchronization. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of a multi-dimensional health monitoring and status management system for field agent equipment provided in an embodiment of the present invention.

[0016] Figure 2 This is a state transition diagram of a three-atom synchronization module provided in an embodiment of the present invention.

[0017] Figure 3 A schematic diagram of another field agent device multi-dimensional health monitoring and status management system provided in an embodiment of the present invention. Figure 4This is a flowchart of a method for multi-dimensional health monitoring and status management of field agent equipment according to an embodiment of the present invention. Detailed Implementation

[0018] The present invention will be described in detail below through embodiments. These embodiments are based on the technical solution of the present invention and provide detailed implementation methods and specific operating procedures. However, the scope of protection of the present invention is not limited to the following embodiments.

[0019] In this invention, the terms "in one possible embodiment," "exemplary," or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "in one possible embodiment," "exemplary," or "for example" in this invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "in one possible embodiment," "exemplary," or "for example" is intended to present the relevant concepts in a specific manner.

[0020] In high-concurrency scenarios, multiple heartbeat requests from the same device arrive at the cloud simultaneously and trigger state updates for the same device. How to perform fine-grained security concurrency control efficiently and accurately is a key technical issue in reducing the false alarm rate of on-site agent devices.

[0021] Existing device management systems rely on a single threshold trigger mechanism to determine the load status of field agent devices. However, this mechanism cannot distinguish whether the triggering of the threshold is due to network jitter caused by packet delays or loss, or to device failure caused by process crashes. When the overall system load approaches the alarm threshold, resource utilization frequently fluctuates around the threshold, generating significant alarm jitter. Furthermore, the process reads the current device status from local state storage and generates a snapshot, then pushes this snapshot to the cloud management platform via a network interface. Since the local state storage is not frozen during the time window between reading the snapshot and completing the push, any changes to the device status received during this period cannot be captured, resulting in the permanent loss of intermediate device status after the synchronization push is completed.

[0022] Therefore, there is an urgent need in this field for a field agent device management solution that can perform fine-grained concurrent control, ensure data security, and simultaneously improve accuracy.

[0023] To address this, the present invention designs a highly reliable system with multi-module collaboration, which executes corresponding functional modules at each stage of data packet flow to achieve collaboration among modules such as tunnel health perception, multi-dimensional resource anomaly detection, priority state machine, concurrency control, TOCTOU security verification, and three-state atomic synchronization. This aims to solve existing technical problems such as resource monitoring jitter, concurrency race conditions, and data loss.

[0024] Firstly, a detailed description will be given of a multi-dimensional health monitoring and status management system for field agent devices provided in an embodiment of the present invention. For example... Figure 1 As shown, the multi-dimensional health monitoring and status management system 10 for field agent equipment provided in this embodiment of the invention may include a tunnel health perception module 110, an equipment granular concurrent control module 120, a heartbeat timeout detection module 130, a multi-dimensional resource anomaly detector 140, a state machine module 150, and a three-atom synchronization module 160.

[0025] The tunnel health sensing module 110 is used to periodically receive heartbeat data from the agent device and generate trigger events.

[0026] The device-level concurrency control module 120 is used to acquire the mutex lock of the proxy device, so that the state transition instructions of the same proxy device are executed serially.

[0027] The heartbeat timeout detection module 130 is used to detect agent devices with heartbeat timeouts through a timed task and trigger a heartbeat timeout event. After acquiring the mutex lock and before executing the state transition, the heartbeat timeout event is verified a second time. If the agent device has resumed heartbeat, the current state transition is abandoned.

[0028] The multi-dimensional resource anomaly detector 140 is used to configure detector instances for CPU utilization, memory utilization, and disk utilization, respectively. It performs anomaly determination based on a dual-threshold time window algorithm on each detector instance of each agent device and generates anomaly flag bits.

[0029] The state machine module 150 is used to maintain a state machine instance for each agent device with the device's unique identifier as the granularity. Based on the received trigger event, according to the exception flag bit and the preset state priority rules, it drives the agent device to switch between connected state, disconnected state and abnormal state, and writes the changed device state data into the memory cache.

[0030] The three-atom synchronization module 160 is used to combine preset synchronization timed tasks to distinguish the synchronization status between the agent device and the cloud management platform into synchronized, pending, and in-synchronization states, and ensures that data changes generated during the synchronization process are not lost through atomic state transitions.

[0031] Specifically, the tunnel health sensing module adopts an architecture combining timed polling and event-driven processing. It is responsible for receiving heartbeat data, extracting key indicators, and generating trigger events. For example, the monitoring agent program running on the field agent device sends heartbeat data packets to the heartbeat receiving port of the cloud PBX platform via a secure version of the Hypertext Transfer Protocol (HTTP) every preset heartbeat cycle, such as 30 seconds. This heartbeat data packet is encoded using JavaScript object notation and includes, but is not limited to, multiple key fields such as the device's unique identifier, CPU usage, memory usage, disk usage, and tunnel health status. The device's unique identifier field can use the Universal Unique Identifier 4 (UUID 4) algorithm to randomly generate a 128-bit identifier based on a fixed version number and variant bits, represented as a 36-character string in the standard 8-4-4-12 format, for example, "7c3526e1-7p07-41el-8c58-kfa74dc4f98c".

[0032] After the on-site agent device software is installed, the administrator configures the device's unique identifier and key into the software. Upon the first startup of the device software, a verification request containing the device's unique identifier and key is sent to the cloud-based PBX platform. Once the key is activated, the device reports its heartbeat normally.

[0033] CPU utilization, memory utilization, and disk utilization reflect the real-time load of the device at the time of sampling.

[0034] The tunnel health status field is one of the key innovations of this invention. It indicates whether the secure tunnel carrying Session Initiation Protocol (SIP) signaling and Real-Time Transport Protocol (RTP) media streams is in an available state. The SIP handles signaling interactions such as phone registration, call setup, and call transfer, while the RTP transmits real-time data such as audio and video over the Internet. Since field agent devices are typically deployed in an enterprise intranet environment, while the cloud-based PBX platform is deployed in a public network environment, a secure communication channel is established between the two using dedicated tunneling technology.

[0035] Specifically, after receiving the heartbeat data packet, the tunnel health sensing module 110 first performs format verification and integrity checks on the data packet to ensure that all fields exist and their values ​​are within the legal range. After the verification passes, the heartbeat data is written to the memory cache, the last reported timestamp of the corresponding agent device is updated, and a data structure containing the device's unique identifier, heartbeat data, and trigger event is generated and passed to the state machine module 150 through an internal message queue.

[0036] When the state machine module 150 receives a trigger event for a device's unique identifier, the device-level concurrency control module 120 first queries the mutex concurrency mapping table (sync.Map) for the mutex instance corresponding to that unique identifier. If no instance is found, a mutex instance corresponding to that unique identifier is created. The mutex concurrency mapping table uses the device's unique identifier (UUID) as the key and the mutex instance (sync.Mutex) as the value, employing a read-write lock mechanism. This allows multiple read operations to be executed concurrently, while write operations are mutually exclusive with other operations. After determining the state priority according to the rules, if the state has not changed, the mutex is released and a unchanged result is returned. If the state has changed, the memory cache is updated and the state is marked as pending synchronization in subsequent steps. Next, the operating thread calls the mutex's locking method, which blocks the current thread until ownership of the mutex is successfully acquired. After successful locking, the operating thread enters the critical section code, strictly executing the state reading, determination, and update operations of a single agent device sequentially.

[0037] The heartbeat timeout detection module 130 performs secondary verification for proxy devices whose trigger event within the critical section is a heartbeat timeout event, under the protection of a mutex lock, to determine whether the current state transition has been executed. This can eliminate the time window race problem between the timed task detection timeout and the actual execution of the state transition by the state machine.

[0038] The multi-dimensional resource anomaly detector 140 maintains three independent detector instances for each agent device, respectively determining whether CPU utilization, memory utilization, and disk utilization are in a normal or abnormal state. The detector performs bitwise operations on the results of each instance and merges them into an anomaly flag. This allows for precise identification of the specific cause of resource overload during subsequent state rule determinations by performing a bitwise AND operation on the anomaly flag field.

[0039] The state machine module 150 maintains an independent state machine instance for each agent device. The state machine instance supports three trigger events: heartbeat reporting, heartbeat timeout, and key reset. The heartbeat reporting event is triggered when the on-site agent device successfully reports heartbeat data, carrying key information such as the agent device's latest resource utilization, tunnel health status, and number of online phones. The heartbeat timeout event is triggered when a scheduled task detects that a device has exceeded a preset timeout threshold without reporting a heartbeat, indicating a possible network connection interruption. The key reset event is triggered when an administrator resets the device's authentication key through the cloud management platform. The state machine instance will force the device's state to transition to the disconnected state and notify the tunnel service to update its configuration. First, tunnel health status is incorporated as the first priority condition into the state transition decision. Based on the principle of business importance, the device is driven to transition between connected, disconnected, and abnormal states in descending order of priority.

[0040] The three-atom synchronization module 160 maintains a synchronization status field in the memory cache for each agent device. When the device's status, configuration, or number of online phones changes, the system uses atomic operations to uniformly set the synchronization status to "pending synchronization." When the synchronization scheduled task sends a synchronization request to the cloud management platform according to the preset synchronization cycle, the synchronization status field is switched to the "synchronizing" status, and a response indicating success or failure is returned. If the synchronization request is successful, the "synchronizing" status in the synchronization status field is cleared, and it is marked as synchronized.

[0041] This system, through the collaborative efforts of its various modules, constructs a highly reliable and high-performance field agent equipment monitoring and management system. At the data acquisition and anomaly detection level, it solves the alarm jitter problem caused by the traditional single-threshold detection method by introducing a dual-threshold time window algorithm with hysteresis effect. Furthermore, it incorporates tunnel health status as the highest priority judgment condition into the state machine decision-making process and designs a four-level priority mechanism to ensure that state transitions are performed according to business importance when multiple triggering events occur simultaneously, enabling the agent equipment to provide timely and accurate business services to the outside world.

[0042] This system also assigns an independent mutex lock to each device, enabling concurrent execution of state transition operations across different devices while serializing operations only on the same device. Furthermore, addressing the TOCTOU race condition in heartbeat timeout detection scenarios, the system performs secondary verification under the protection of the mutex lock, fundamentally eliminating the risk of incorrectly marking recovered devices as offline. Moreover, the system introduces a synchronization-in-progress state as an intermediate state in the three-atom synchronization module, ensuring that the synchronization completion operation only clears the synchronization-in-progress state, not the pending synchronization state, guaranteeing zero data loss during synchronization and achieving high concurrency processing capabilities and excellent scalability. This system significantly reduces the false alarm rate of field agent devices, improves the accuracy of state judgment and concurrency security, and guarantees eventual consistency of cloud data synchronization.

[0043] exist Figure 1 Based on the illustrated embodiment, as one implementation of the present invention, anomaly determination based on a dual-threshold time window algorithm is performed on each detector instance of each proxy device.

[0044] The detector instance includes fields for detection status, current usage rate, anomaly start time, and recovery start time. The meaning of each field is as follows: 1. The detection status field can be an enumeration type, used to record whether the current detector instance is in a normal or abnormal state; 2. The current usage rate field can be a floating-point number to record the corresponding usage rate parameter value carried in the last heartbeat data; 3. The exception start field can use Unix timestamp format to record the timestamp when the usage rate first exceeds the preset load threshold, which is used to calculate the duration of the exception; 4. The recovery start time field can use the Unix timestamp format to record the timestamp when the usage rate first drops below the preset recovery threshold, which is used to calculate the recovery duration.

[0045] The detector instance performs the following steps for anomaly detection based on the current state of the state machine instance: Step a1: First, perform the initialization operation. The device enters the normal state and continuously receives heartbeat data. When the usage rate of at least one of them exceeds the threshold for a period of time, the following anomaly detection process will begin.

[0046] Step a2: When the detector instance is originally in a normal state, if the abnormal detection unit (AbnormalSince) confirms that the current utilization rate is greater than or equal to the preset load threshold and continues for a period of time, then the abnormal state processing (Checking_Abnormal) is entered to perform the judgment, and the first difference between the current time and the abnormal start time field is recorded; for example, taking the detector instance of the central processing unit utilization rate as an example, the preset load threshold can be set to 80%, and the preset abnormal duration threshold can be set to 300 seconds.

[0047] If the first difference reaches the preset abnormal duration threshold of 300 seconds, the agent device is judged to be in an abnormal state, and the recovery start time field is cleared to zero.

[0048] If the first difference does not reach the preset abnormal duration threshold of 300 seconds, it enters the hysteresis interval, indicating that the overload may be caused by instantaneous network jitter. At this time, the detection status field remains in the current normal state.

[0049] If the abnormality detection (AbnormalSince) confirms that the current utilization rate is less than the preset load threshold, the abnormality start time field will be cleared to zero, and the detection status field will remain in the current normal state.

[0050] Step a3: When the detector instance was originally in an abnormal state, if the abnormal detection unit (AbnormalSince) confirms that the current utilization rate is less than the preset load threshold and continues for a period of time, it enters the recovery detection phase (Checking_Normal) to perform the judgment and records the second difference between the current time and the recovery start time field; for example, taking the detector instance of the central processing unit utilization rate as an example, the preset recovery duration threshold can be set to 120 seconds.

[0051] If the second difference reaches the preset recovery time threshold of 120 seconds, the agent device is determined to be in normal condition, and the abnormal start time field is cleared to zero.

[0052] If the second difference does not reach the preset recovery time threshold of 120 seconds, it indicates that the agent device has not stably entered the normal state, and the detection status field remains in the current abnormal state.

[0053] If the abnormal detection unit (AbnormalSince) confirms that the current utilization rate is greater than or equal to the preset load threshold, the recovery start time field will be cleared to zero, and the detection status field will remain in the current abnormal state.

[0054] The multi-dimensional resource anomaly detector of this invention implements a dual-threshold time window algorithm with hysteresis, introducing a time continuity requirement. This effectively filters out instantaneous spikes in resource utilization, avoiding false alarms caused by brief spikes due to business fluctuations such as scheduled task execution, log rotation, database queries, and configuration file reloading. It eliminates alarm jitter near the threshold, significantly improving alarm stability and reliability. Furthermore, this invention employs an asymmetric time window, ensuring both alarm accuracy and response speed.

[0055] exist Figure 1 Based on the illustrated embodiment, as one implementation of the present invention, a specific scheme for generating the exception flag bit includes: The judgment results of the detector instances of CPU usage, memory usage, and disk usage are combined by bitwise operations into an exception flag field, which is an integer value.

[0056] The zeroth bit is used to indicate whether the CPU utilization is in an abnormal state; it is 1 if it is, and 0 otherwise. The first bit is used to indicate whether the memory usage is in an abnormal state; it is 1 if it is, and 0 otherwise. The second bit is used to indicate whether the disk usage is in an abnormal state; it is 1 if it is, and 0 otherwise.

[0057] For example, performing a bitwise AND operation between the exception flag field and the decimal value 1, if the result is non-zero, it means that the zeroth bit is 1, and the central processing unit is in an overload exception state.

[0058] In this implementation, independent detector instances are maintained for the central processing unit, memory, and disk respectively, enabling multi-dimensional fine-grained monitoring. When the state machine module determines the state transition rules, it can identify the specific abnormal type by performing bit operations on the abnormal flag field, providing accurate fault location information, reducing memory usage and computational overhead, thereby improving execution performance and the fault handling efficiency of maintenance personnel.

[0059] exist Figure 1 Based on the illustrated embodiment, as one implementation of the present invention, based on the received trigger event, the agent device is driven to switch between connected state, disconnected state and abnormal state according to the abnormal flag bit and the preset state priority rules.

[0060] The status priority rules are determined by the triggering events, including heartbeat reporting events, heartbeat timeout events, and key reset events.

[0061] The determination process for the state priority rules is arranged into four levels according to priority from high to low, as follows: 1. First priority: When the triggering event is a heartbeat timeout event, a key reset event, or a heartbeat reporting event and the tunnel health status is unavailable, it is a forced disconnection condition. Regardless of the agent device's current state, the state machine instance will be forcibly switched to the disconnected state.

[0062] 2. Second priority: When the agent device was originally in a disconnected state, the triggering event is a heartbeat reporting event, and the tunnel health status is available, it is a disconnection recovery condition, and the state is switched according to the value of the abnormal flag field.

[0063] If the value of the exception flag field is zero, it means that there are no exceptions in the three resources. Switching the state machine instance to the connected state indicates that the device has fully recovered to normal.

[0064] If the value of the exception flag field is non-zero, it indicates that at least one resource is abnormal. The state machine instance will then be switched to the abnormal state, which reflects the fact that the device has restored the connection and prompts the operation and maintenance personnel to pay attention to the resource usage.

[0065] 3. Third priority: When the agent device is originally in a connected state, the trigger event is a heartbeat reporting event, and the tunnel health status is available, it is an online anomaly detection condition, and the state is switched according to the value of the anomaly flag field.

[0066] If the value of the exception flag field is zero, the state machine instance remains in the connected state and only updates metadata such as the last reported time.

[0067] If the value of the exception flag field is non-zero, the state machine instance will be switched to an exception state, triggering an alarm to notify the operation and maintenance personnel to intervene and handle it in a timely manner.

[0068] 4. Fourth priority: When the agent device was originally in an abnormal state, the triggering event is a heartbeat reporting event, and the tunnel health status is available, it is an abnormal recovery condition, and the state is switched according to the value of the abnormal flag field.

[0069] If the value of the exception flag field is zero, it means that the previously abnormal resource has been restored to normal, and the state machine instance is switched to the connected state.

[0070] If the value of the exception flag field is non-zero, it indicates that the resource exception has not been fully recovered. The state machine instance remains in the exception state and continues to report alarm notifications.

[0071] In this implementation, the tunnel health status is incorporated as the first priority condition into the transition decision, and a four-level priority mechanism is established to encompass state transitions under all circumstances. This makes the state transition results predictable, provides comprehensive monitoring information, and enables maintenance personnel to promptly identify resource usage issues for preventative maintenance.

[0072] exist Figure 1 Based on the illustrated embodiment, as one implementation of the present invention, the synchronization status between the agent device and the cloud management platform is divided into synchronized state, pending synchronization state, and in-synchronization state. In the memory cache, a synchronization status field is configured for each agent device to perform update operations through an atomic interface.

[0073] The cloud management platform is an independent device management system operating separately from the cloud PBX platform. It provides device status updates, generates statistical reports, and triggers maintenance work orders. Its database can be deployed in different data centers and interacts with the cloud PBX platform via a web application programming interface (API). Furthermore, it maintains a synchronization status field to mark synchronized, pending, and in-sync states. A value of 0 indicates that the agent device's status data is consistent with the cloud management platform; a value of 1 indicates that the agent device's status data has changed and is awaiting synchronization to the cloud; and a value of 2 indicates that synchronization is currently underway.

[0074] An atomic interface is an interface whose execution process cannot be interrupted. This means that during concurrent access by multiple threads, the interface's execution will not have any intermediate states that can be observed by other threads, thus preventing data loss. The data flow process of synchronized state transitions is as follows: Figure 2 As shown, the specific steps are as follows: Step b1: After the state machine module performs the state transition, it first performs an initialization operation on the agent device, and the synchronization state field is the synchronized state (Synced) that has not changed.

[0075] Step b2: When one or more of the state machine instance, configuration parameters, and number of associated phones of the agent device change, call the markForCMSync(.) method to transfer the initial state (Synced) to the pending state (Pending).

[0076] Step b3: The incremental synchronization timer task iterates through the synchronization status fields of all devices in the pending state in the memory cache according to the preset synchronization period, executes the atomic conversion StartCMSync(.), and then switches the synchronization status field to the Syncing state to perform state synchronization.

[0077] The state synchronization process is as follows: a synchronization request data packet is constructed and sent to the application interface of the cloud management platform via the Hypertext Transfer Protocol; after receiving the synchronization request, the cloud management platform updates the device data in the database and returns a response indicating whether the synchronization was successful or failed.

[0078] Step b4: During the synchronization process, if one or more of the following changes again: the state machine instance of the proxy device, the configuration parameters, and the number of associated phones, the system calls the markForCMSync() method again to reset the synchronization status (Syncing) to the pending synchronization status (Pending).

[0079] In step b5, if a synchronization failure response is returned, the system calls the ResetCMSyncStatus() method to roll back the Syncing status to the Pending status. The agent device remains in the synchronization queue, waiting for the next round of incremental synchronization timed tasks.

[0080] Step b6: If a synchronization success response is returned, the system calls the atomic mark synchronization completed interface, and clears the Syncing status from the synchronization field to the synchronized status through the MarkCMSyncCompleted() method.

[0081] In this implementation, by introducing a state in synchronization as an intermediate transitional state between synchronized and pending synchronization, zero data loss is achieved during the synchronization process. This ensures that all changes to device data are synchronized to the cloud management platform, and the data in the cloud management platform always converges to a state consistent with the actual device data. Furthermore, the three-state atomic synchronization mechanism is implemented based on atomic operations, eliminating the need for additional global lock mechanisms, thus maintaining high-performance synchronization efficiency while ensuring data reliability.

[0082] exist Figure 1Based on the illustrated embodiment, as one implementation of the present invention, after acquiring the mutex lock and before executing the state transition, the heartbeat timeout event is verified a second time.

[0083] Specifically, in the heartbeat timeout detection scenario, the scheduled task checks the last reported event of the device at a certain moment. If it finds that the event exceeds the preset timeout threshold, it determines that the device has timed out and then triggers the heartbeat timeout event. However, there is a time delay between the scheduled task's check and the state machine's actual processing of the event. During this delay, the device may have re-reported the heartbeat, but it may have been mistakenly marked as offline.

[0084] For example, a scheduled task executed every 30 seconds scans the memory cache for the last reporting time of all agent devices, adding devices that have not reported for more than 60 seconds to a timeout list. For each device in the timeout list, the scheduled task triggers a heartbeat timeout event.

[0085] After acquiring the mutex lock but before executing the state transition, perform secondary verification on the aforementioned heartbeat timeout event, including the following steps: Step c1: After acquiring the mutex lock and before performing the state transition, reread the timestamp of the last reported heartbeat data from the agent device that triggered the heartbeat timeout event from the memory cache, and calculate the difference between the current time and that timestamp.

[0086] The re-read operation is performed under the protection of a holding lock, during which no other concurrent operations modify the last reported event of the agent device. Therefore, the read timestamp can accurately reflect the latest heartbeat status of the device.

[0087] In step c2, if the difference is less than or equal to the preset timeout threshold, it is determined that the agent device that was originally detected to have timed out has resumed heartbeat, the heartbeat timeout event is invalidated, the mutex lock is released, and no state transition operation is performed.

[0088] Step c3: If the difference is greater than the preset timeout threshold, it is determined that the agent device is indeed in a heartbeat timeout state, the tunnel health status is unavailable, the state machine instance continues to execute the state transition operation, and sets it to the disconnected state according to the first priority forced disconnection condition in the above embodiment.

[0089] In this implementation, the two-step verification process fundamentally eliminates the time-out and usage race conditions (TOCTOU race conditions) between the timed task detection timeout and the actual state transition of the state machine. This avoids the problem in the prior art where recovered devices are mistakenly marked as offline due to factors such as network jitter and timed task scheduling delays.

[0090] exist Figure 1 Based on the illustrated embodiments, as one implementation of the present invention, such as... Figure 3 As shown, the system also includes a platform adaptive synchronization adapter 170, which is used to select the corresponding tunnel service synchronization implementation method based on the platform type deployed in the current system.

[0091] Among them, the platform adaptive adapter uses the factory method pattern to automatically select PCE (P-Series Cloud Edition) or PSE (P-Series Appliance Edition) / PAE (P-Series Software Edition) based on the platform type during system initialization.

[0092] Specifically, when the deployment platform is a cloud-based PBX platform, the platform adaptive synchronization adapter 170 sends synchronization request data to the cloud tunnel service through the cloud application programming interface (CloudPBX API) of the PCE (P-Series Cloud Edition) platform. The request data includes the device SN (serial number), UUID (unique device identifier), SecretKey (key), and agent device instance ID. After receiving the notification, the cloud tunnel service updates the corresponding tunnel configuration, allowing or denying the tunnel connection request for the device corresponding to the unique device identifier. If the connection is allowed, the device with the changed status is synchronized to the cloud management platform through the API interface of the CM platform (Central Management).

[0093] When the deployment platform is a local PBX platform, the platform adaptive synchronization adapter 170 sends synchronization request data to the local tunnel service via the Hypertext Transfer Protocol (HTTP) on the local inter-process communication socket (Unix Domain Socket) of the PSE (P-Series Appliance Edition) / PAE (P-Series Software Edition) platform local tunnel service.

[0094] In this implementation, by implementing a platform-adaptive synchronization adapter, unified business logic code is used across different deployment platforms. Platform-related implementation details are encapsulated within the adapter class, and the business code only depends on the abstract interface, improving readability and maintainability. When support for a new deployment platform is required, only a new adapter class needs to be implemented; the business code does not need to be modified, achieving excellent scalability.

[0095] exist Figure 1Based on the illustrated embodiment, as one implementation of the present invention, the system further includes an idempotent online phone count module, which is used to read the actual number of online phones under the current agent device from the database cache layer used to store the phone registration status when a phone goes online or offline event occurs, and directly overwrite the number of online phones in the memory cache.

[0096] Specifically, when a phone comes online, the system first updates the status of that phone in the database cache layer to online, then calls the phone online method of the idempotent online phone count statistics module, calls and queries all phone records under the device name to which that phone belongs in the database cache layer, counts the number of phones with the status of online, and returns accurate real-time statistics.

[0097] If the real-time statistical value differs from the current value, the real-time statistical value is directly overwritten into the memory cache, and a status change for the agent device is triggered in the timed heartbeat data. After executing the operations described in the above embodiment, the updated device data is synchronized to the cloud management platform. The handling process for the phone offline event is exactly the same as the above steps, only the type of event triggered is different, and will not be described in detail here.

[0098] In this implementation, by using idempotent direct overwrite semantics to replace traditional incremental addition and subtraction operations, the race condition problem between the full loading of the memory cache and the phone status change event during system restart is fundamentally eliminated. This avoids the accumulation of statistical deviations caused by the uncertainty of the loading order, avoids unnecessary write operations and synchronization operations, and reduces system overhead. Furthermore, since the database cache layer itself is an in-memory data structure, the time taken for a single query is at the microsecond level, which greatly improves the system's execution performance.

[0099] This invention also provides a method for multi-dimensional health monitoring and status management of field agent equipment, such as... Figure 4 As shown, the method may include the following steps: S410 periodically receives heartbeat data from the agent device and generates trigger events.

[0100] S420: Acquire the mutex lock of the agent device, so that the state transition instructions of the same agent device are executed serially.

[0101] S430 detects agent devices with timed heartbeats and triggers heartbeat timeout events through a timed task. After acquiring the mutex lock and before executing the state transition, the heartbeat timeout event is verified a second time. If the agent device has resumed heartbeat, the current state transition is abandoned.

[0102] S440 configures detector instances for CPU utilization, memory utilization, and disk utilization, respectively, and performs anomaly detection based on a dual-threshold time window algorithm on each detector instance of each agent device to generate anomaly flag bits.

[0103] S450 maintains a state machine instance for each agent device with a unique device identifier as the granularity. Based on the received trigger event, according to the exception flag bit and the preset state priority rules, it drives the agent device to switch between connected, disconnected and abnormal states, and writes the changed device state data into the memory cache.

[0104] The S460, combined with preset synchronization timed tasks, distinguishes the synchronization status between the agent device and the cloud management platform into synchronized, pending, and synchronizing states, and ensures that data changes generated during the synchronization process are not lost through atomic state transitions.

[0105] This invention, through the collaborative efforts of various modules, constructs a highly reliable and high-performance field agent equipment monitoring and management system. At the data acquisition and anomaly detection level, it solves the alarm jitter problem caused by the traditional single-threshold detection method by introducing a dual-threshold time window algorithm with hysteresis effect. Furthermore, it incorporates tunnel health status as the highest priority judgment condition into the state machine decision-making and designs a four-level priority mechanism to ensure that state transitions can be performed according to business importance when multiple triggering events occur simultaneously, enabling the agent equipment to provide timely and accurate business services to the outside world.

[0106] The multi-dimensional health monitoring and status management method and the multi-dimensional health monitoring and status management system provided in this embodiment of the invention correspond to each other. Here, other contents of the multi-dimensional health monitoring and status management method will not be described in detail. Please refer to the contents of the multi-dimensional health monitoring and status management system.

[0107] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention without departing from the principles and spirit of the present invention.

Claims

1. A multi-dimensional health monitoring and status management system for field-based agent equipment, characterized in that, include: The tunnel health sensing module is used to periodically receive heartbeat data from the agent device and generate trigger events. The heartbeat data includes the current agent device's unique identifier, CPU usage, memory usage, disk usage, and tunnel health status. The tunnel health status is used to indicate whether the secure tunnel carrying the current session initiation protocol signaling and real-time transport protocol media stream is in an available state. The device-level concurrency control module is used to acquire the mutex lock of the proxy device, so that the state transition instructions of the same proxy device are executed serially; The heartbeat timeout detection module is used to detect agent devices with timed heartbeats and trigger heartbeat timeout events through a timed task. After acquiring the mutex lock and before executing the state transition, the heartbeat timeout event is verified a second time. If the agent device has resumed heartbeat, the current state transition is abandoned. A multi-dimensional resource anomaly detector is used to configure detector instances for CPU utilization, memory utilization, and disk utilization, respectively. It performs anomaly judgment based on a dual-threshold time window algorithm on each detector instance of each agent device and generates anomaly flag bits. The state machine module is used to maintain a state machine instance for each agent device with the device's unique identifier as the granularity. Based on the received trigger event, according to the exception flag bit and the preset state priority rules, it drives the agent device to switch between connected state, disconnected state and abnormal state, and writes the changed device state data into the memory cache. The three-atom synchronization module is used to combine preset synchronization timed tasks to distinguish the synchronization status between the agent device and the cloud management platform into synchronized, pending, and in-synchronization states, and ensures that data changes generated during the synchronization process are not lost through atomic state transitions.

2. The system according to claim 1, characterized in that, For each detector instance of each agent device, anomaly detection based on a dual-threshold time window algorithm is performed, where... The detector instance includes a detection status field, a current usage rate field, an anomaly start time field, and a recovery start time field; The detection status field is used to record whether the current detector instance is in a normal or abnormal state; the current utilization rate field is used to record the parameter value of the utilization rate corresponding to the detector instance; the abnormal start time field is used to record the timestamp of the first time the utilization rate exceeds the preset load threshold; the recovery start time field is used to record the timestamp of the first time the utilization rate drops below the preset recovery threshold. The steps for anomaly detection include: When the detector instance is originally in a normal state, if the current utilization rate is greater than or equal to the preset load threshold, the first difference between the current time and the abnormal start time field is recorded, and when the first difference reaches the preset abnormal duration threshold, the detection status field is switched to the abnormal state, and the recovery start time field is cleared to zero; if the current utilization rate is less than the preset load threshold, the abnormal start time field is cleared to zero, and the detection status field remains in the current normal state. When the detector instance is originally in an abnormal state, if the current utilization rate is less than the preset load threshold, the second difference between the current time and the recovery start time field is recorded. When the second difference reaches the preset recovery duration threshold, the detection status field is switched to the normal state, and the abnormal start time field is cleared to zero. If the current utilization rate is greater than or equal to the preset load threshold, the recovery start time field is cleared to zero, and the detection status field remains in the current abnormal state.

3. The system according to claim 1, characterized in that, Generate exception flags, including: The judgment results of each detector instance of CPU usage, memory usage, and disk usage are combined into an anomaly flag field through bitwise operations. The exception flag field is an integer value; wherein, the zeroth bit is used to indicate whether the CPU utilization is in an abnormal state, and is set to one if yes, otherwise it is set to zero; the first bit is used to indicate whether the memory utilization is in an abnormal state, and is set to one if yes, otherwise it is set to zero; the second bit is used to indicate whether the disk utilization is in an abnormal state, and is set to one if yes, otherwise it is set to zero.

4. The system according to claim 1, characterized in that, Based on the received trigger event, and according to the exception flag and the preset state priority rules, the agent device is driven to switch between connected state, disconnected state and exception state. The state priority rule is determined by the triggering event, wherein the triggering event includes a heartbeat reporting event, a heartbeat timeout event, and a key reset event; The state priority rules include: First priority: when the triggering event is a heartbeat timeout event, a key reset event, or a heartbeat reporting event and the tunnel health status is unavailable, switch the state machine instance to the disconnected state. The second priority is that when the agent device was originally in a disconnected state, the triggering event is a heartbeat reporting event, and the tunnel health status is available, if the value of the abnormal flag field is zero, the state machine instance is switched to the connected state; if the value of the abnormal flag field is not zero, the state machine instance is switched to the abnormal state. The third priority is that when the proxy device is originally in a connected state, the triggering event is a heartbeat reporting event, and the tunnel health status is available, if the value of the abnormal flag field is zero, the state machine instance remains in the connected state; if the value of the abnormal flag field is not zero, the state machine instance is switched to the abnormal state. Fourth priority: When the agent device was originally in an abnormal state, the triggering event was a heartbeat reporting event, and the tunnel health status was available, if the value of the abnormal flag field is zero, the state machine instance is switched to the connected state; if the value of the abnormal flag field is non-zero, the state machine instance remains in the abnormal state.

5. The system according to claim 1, characterized in that, The synchronization status between the agent device and the cloud management platform is categorized into three states: synchronized, pending synchronization, and in progress. In the memory cache, configure a synchronization state field for each agent device to perform update operations via an atomic interface; When one or more of the state machine instance, configuration, and number of associated phones of the agent device change, the synchronization status field is set to the state to be synchronized. When the scheduled synchronization task starts, all agent devices in the pending synchronization state are converted to the synchronization state at once, and a list of device unique identifiers of the corresponding agent devices is returned. When the scheduled synchronization task is executed successfully, for the agent devices that were marked as pending synchronization due to data changes during the synchronization process, the pending synchronization state is maintained, and they wait to execute the next round of synchronization tasks; while the remaining agent devices that have successfully executed the task are marked as synchronized. When the scheduled synchronization task fails, all agent devices in the synchronization state will be rolled back to the waiting synchronization state.

6. The system according to claim 1, characterized in that, After acquiring the mutex lock but before executing the state transition, a secondary verification is performed on the heartbeat timeout event. The verification steps include: After acquiring the mutex lock and before performing the state transition, the timestamp of the last heartbeat data reported by the agent device is reread from the memory cache, and the difference between the current time and the timestamp is calculated. If the difference is less than or equal to the preset timeout threshold, it is determined that the agent device that was originally detected to have timed out has resumed heartbeat reporting, the heartbeat timeout event is invalidated, the mutex lock is released, and no state transition operation is performed. If the difference is greater than the preset timeout threshold, it is determined that the agent device is indeed in a heartbeat timeout state, and the state machine instance continues to perform state transition operations.

7. The system according to claim 1, characterized in that, The system also includes a platform adaptive synchronization adapter, used to select the corresponding tunnel service synchronization implementation method based on the platform type currently deployed in the system, including: When the deployment platform is a cloud-based PBX platform, a synchronization request is sent through the cloud application programming interface to push the configuration information of the agent device to the cloud tunnel service; When the deployment platform is a local PBX platform, it communicates with the tunnel service process running on the same device through the Hypertext Transfer Protocol on the local inter-process communication socket to synchronize the configuration information of the proxy device to the local tunnel service.

8. The system according to claim 1, characterized in that, The system also includes an idempotent online phone count module, which reads the actual number of online phones under the current agent device from the database cache layer used to store phone registration status when a phone goes online or offline event occurs, and directly overwrites the number of online phones in the memory cache.

9. A method for multi-dimensional health monitoring and status management of field-based agency equipment, characterized in that, include: Periodically receive heartbeat data from the proxy device and generate trigger events. The heartbeat data includes the current proxy device's unique identifier, CPU usage, memory usage, disk usage, and tunnel health status. The tunnel health status is used to indicate whether the secure tunnel carrying the current session initiation protocol signaling and real-time transport protocol media stream is in an available state. Acquire the mutex lock of the proxy device to enable the state transition instructions of the same proxy device to be executed serially; The system detects agent devices that have timed out heartbeats and triggers a heartbeat timeout event via a scheduled task. After acquiring the mutex lock and before executing the state transition, the heartbeat timeout event is verified a second time. If the agent device has resumed heartbeat, the current state transition is abandoned. Configure detector instances for CPU usage, memory usage, and disk usage respectively, and perform anomaly detection based on a dual-threshold time window algorithm for each detector instance of each agent device to generate anomaly flag bits; Maintain a state machine instance with a unique device identifier for each agent device. Based on the received trigger event, drive the agent device to switch between connected, disconnected and abnormal states according to the exception flag and the preset state priority rules, and write the changed device state data into the memory cache. By combining preset synchronization timed tasks, the synchronization status between the agent device and the cloud management platform is divided into synchronized, pending, and synchronizing states, and atomic state transitions are used to ensure that data changes generated during the synchronization process are not lost.

Images