Equipment management method and device, equipment and readable storage medium

Abstract

The invention provides a device management method and device, a device and a readable storage medium, and the method comprises the steps: actively obtaining the latest synchronization progress information about a device event between each managed device and an NMS, and constructing a synchronization request message carrying a synchronization window triggering mark based on the latest synchronization progress information; according to the method and the device, an accurate and controllable device event synchronization mechanism is initiated to the managed device, the managed device can define a device event range needing to be synchronized based on the synchronization request message, repeated transmission of the synchronized device event is avoided, the transmission efficiency is improved, and efficient backtracking and complementing of the device event missed in the NMS service interruption period are realized. The method is suitable for various IP network environments and various network topology structures, can be used for traditional copper cable access and wireless access scenes, and can also be used for optical fiber access scenes including an FTTR (Fiber To The Room) all-optical access network.

Description

Equipment management methods, devices, equipment and readable storage media Technical Field

[0001] This application relates to the field of communication technology, and in particular to a device management method, apparatus, device, and readable storage medium. Background Technology

[0002] With the development of cloud computing, the Internet of Things, FTTR, and large-scale campus networks, network scale and equipment types are growing rapidly, forming a multi-vendor, heterogeneous hybrid network environment. Network management systems (NMS) need to centrally monitor various managed devices and obtain key information such as operating status, alarms, logs, configuration changes, and performance indicators.

[0003] Traditionally, NMS relies on proactive polling to obtain snapshots of the current device status of managed devices, or on device events proactively reported by managed devices. However, both of these methods suffer from the inability to synchronize device events to NMS in scenarios where NMS is experiencing management service anomalies such as restarts, software upgrades, management link interruptions or unstable link quality, large-scale failures, or network instability. This results in critical device events generated by managed devices during NMS service anomalies not being compensated by NMS. Summary of the Invention

[0004] In view of this, in order to solve the above-mentioned technical problems, this application provides a device management method, apparatus, device and readable storage medium, which can compensate the NMS end for key device events such as alarms, logs and configuration changes generated by the managed device during NMS service anomalies.

[0005] Specifically, this application is implemented through the following technical solution: According to a first aspect of the embodiments of this application, a device management method is provided, applied to a network management system (NMS). The method includes: for any managed device, determining the latest synchronization progress information between the managed device and the NMS; the latest synchronization progress information is used to characterize the event range of device events that the managed device has successfully synchronized to the NMS; constructing a synchronization request message based on the latest synchronization progress information; the synchronization request message carrying a synchronization window trigger flag; the synchronization window trigger flag being configured with a valid value, the valid value being used to instruct the managed device to determine the device event to be synchronized from the device events cached by the managed device; sending the synchronization request message to the managed device to instruct the managed device to determine the device event to be synchronized from the device events cached by the managed device based on the latest synchronization progress information carried in the synchronization request message, and sending the determined device event to the NMS.

[0006] Optionally, the device event includes an event identifier and an event occurrence timestamp; the latest synchronization progress information includes an event identifier and / or an event occurrence timestamp of the target event; the target event includes: the device event located at the last position when all device events of the managed device that have been synchronized to the NMS are sorted according to a preset global event identifier sequence.

[0007] Optionally, after sending the synchronization request message to the managed device, the method further includes: receiving a response message returned by the managed device in response to the synchronization request message; the response message includes synchronization window data; the synchronization window data includes device events determined by the managed device from the device events cached by the managed device based on the latest synchronization progress information; updating the event database maintained for the managed device according to the synchronization window data included in the response message, and updating the latest synchronization progress information that the device events of the managed device have been synchronized to the NMS.

[0008] Optionally, updating the event database maintained for the managed device based on the synchronization window data included in the response message includes: performing an idempotency check on each device event included in the synchronization window data based on the event identifier of the device event; the idempotency check is used to detect whether the device event already exists in the event database maintained for the managed device; if the idempotency check passes, the device event is written to the event database matching the event type based on the event type of the device event.

[0009] Optionally, the synchronization request message may further include an event synchronization policy configured for the managed device; the event synchronization policy includes the conditions that the managed device must meet to synchronize device events to the NMS.

[0010] Optionally, after sending the synchronization request message to the managed device, the method further includes: if no response message is received from the managed device for the synchronization request message within a preset time period, then if the number of retries to send the synchronization request message to the managed device has not reached a set threshold, resending the synchronization request message to the managed device; and triggering an operation and maintenance alarm if the number of retries to send the synchronization request message to the managed device reaches the set threshold.

[0011] According to a second aspect of the embodiments of this application, a device management method is provided, applied to any managed device managed by a network management system (NMS). The method includes: receiving a synchronization request message from the NMS; the synchronization request message carrying the latest synchronization progress information that the device events of the managed device have been synchronized to the NMS; if the synchronization window trigger flag parsed from the synchronization request message is a valid value, determining the device events to be synchronized from locally cached device events based on the latest synchronization progress information carried in the synchronization request message; constructing a response message based on the device events to be synchronized, and sending the response message to the NMS.

[0012] Optionally, the device event includes an event identifier and an event occurrence timestamp; the latest synchronization progress information includes an event identifier and / or an event occurrence timestamp of the target event; the target event includes: the device event located at the end when all device events synchronized to the NMS by the managed device are sorted according to a preset global event identifier sequence; the step of determining the device event to be synchronized from the locally cached device events based on the latest synchronization progress information carried in the synchronization request message includes: filtering device events that meet the reporting conditions from the locally cached device events, and determining the device event to be synchronized based on the device events that meet the reporting conditions; wherein, the reporting conditions include: the event occurrence timestamp of the device event is later than the event occurrence timestamp of the target event; or, the event identifier of the device event is located after the event identifier of the target event in the preset global event identifier sequence.

[0013] Optionally, the synchronization request message also carries an event synchronization strategy; the event synchronization strategy includes the conditions that the managed device needs to meet to synchronize device events to the NMS; the step of determining the device events to be synchronized from the locally cached device events based on the latest synchronization progress information carried in the synchronization request message includes: parsing the event synchronization strategy from the synchronization request message; and selecting the device events that meet the event synchronization strategy from the device events that meet the reporting conditions in the locally cached device events as the device events to be synchronized.

[0014] According to a third aspect of the embodiments of this application, a device management apparatus is provided, applied to a network management system (NMS). The apparatus includes: a synchronization progress information acquisition module configured to determine, for any managed device, the latest synchronization progress information between the managed device and the NMS; the latest synchronization progress information is used to characterize the event range of device events that the managed device has successfully synchronized to the NMS; a synchronization request message construction module configured to construct a synchronization request message based on the latest synchronization progress information; the synchronization request message carries a synchronization window trigger flag; the synchronization window trigger flag is configured to a valid value, the valid value being used to instruct the managed device to determine the device event to be synchronized from the device events cached by the managed device; and a message sending module configured to send the synchronization request message to the managed device to instruct the managed device to determine the device event to be synchronized from the device events cached by the managed device based on the latest synchronization progress information carried in the synchronization request message, and to send the determined device event to the NMS.

[0015] Optionally, the device event includes an event identifier and an event occurrence timestamp; the latest synchronization progress information includes an event identifier and / or an event occurrence timestamp of the target event; the target event includes: the device event located at the last position when all device events of the managed device that have been synchronized to the NMS are sorted according to a preset global event identifier sequence.

[0016] Optionally, after sending the synchronization request message to the managed device, the apparatus further includes: a response message receiving module, configured to receive a response message returned by the managed device in response to the synchronization request message; the response message includes synchronization window data; the synchronization window data includes device events determined by the managed device from the device events cached by the managed device based on the latest synchronization progress information; and an event database and progress information updating module, configured to update the event database maintained for the managed device and update the latest synchronization progress information of the managed device's device events synchronized to the NMS based on the synchronization window data included in the response message.

[0017] Optionally, the event database and progress information update module is configured to update the event database maintained for the managed device based on the synchronization window data included in the response message, comprising: a verification module configured to perform idempotency verification for each device event included in the synchronization window data based on the event identifier of the device event; the idempotency verification is used to detect whether the device event already exists in the event database maintained for the managed device; and a writing module configured to, if the idempotency verification passes, write the device event to the event database matching the event type based on the event type of the device event.

[0018] Optionally, the synchronization request message may further include an event synchronization policy configured for the managed device; the event synchronization policy includes the conditions that the managed device must meet to synchronize device events to the NMS.

[0019] Optionally, after sending the synchronization request message to the managed device, the device further includes: a retry module, configured to resend the synchronization request message to the managed device if no response message is received from the managed device for the synchronization request message within a preset time period, provided that the number of retries to send the synchronization request message to the managed device has not reached a set threshold; and an alarm module, configured to trigger an operation and maintenance alarm if the number of retries to send the synchronization request message to the managed device reaches a set threshold.

[0020] According to a fourth aspect of the embodiments of this application, a device management apparatus is provided for any managed device managed by a network management system (NMS). The apparatus includes: a message receiving module configured to receive a synchronization request message from the NMS; the synchronization request message carries the latest synchronization progress information indicating that the device events of the managed device have been synchronized to the NMS; an incremental synchronization module configured to, when the synchronization window trigger flag parsed from the synchronization request message is valid, determine a device event to be synchronized from locally cached device events based on the latest synchronization progress information carried in the synchronization request message; and a response module configured to construct a response message based on the device event to be synchronized and send the response message to the NMS.

[0021] Optionally, the device event includes an event identifier and an event occurrence timestamp; the latest synchronization progress information includes an event identifier and / or an event occurrence timestamp of the target event; the target event includes: the device event located at the last position when all device events synchronized to the NMS by the managed device are sorted according to a preset global event identifier sequence; when the incremental synchronization module is configured to determine the device event to be synchronized from the locally cached device events, it includes: filtering device events that meet the reporting conditions from the locally cached device events, and determining the device event to be synchronized based on the device events that meet the reporting conditions; wherein, the reporting conditions include: the event occurrence timestamp of the device event is later than the event occurrence timestamp of the target event; or, the event identifier of the device event is located after the event identifier of the target event in the preset global event identifier sequence.

[0022] Optionally, the synchronization request message also carries an event synchronization strategy; the event synchronization strategy includes the conditions that the managed device must meet to synchronize device events to the NMS; when the incremental synchronization module is configured to determine the device events to be synchronized from the locally cached device events, it includes: parsing the event synchronization strategy from the synchronization request message; and selecting the device events that meet the event synchronization strategy from the device events that meet the reporting conditions in the locally cached device events as the device events to be synchronized.

[0023] According to a fifth aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: a memory and a processor; the memory being used to store a computer program; the processor being used to execute the above-described device management method by invoking the computer program.

[0024] According to a sixth aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the above-described device management method.

[0025] In the technical solution provided in this application, the latest synchronization progress information of device events between each managed device and the NMS is actively obtained, and a synchronization request message carrying a synchronization window trigger flag is constructed based on the latest synchronization progress information. The managed device is instructed to accurately identify the device events that need to be synchronized from the device events cached locally by the managed device based on the latest synchronization progress information and send them back to the NMS. The NMS receives and processes the device event data uploaded by the managed device accordingly. Thus, in abnormal scenarios such as management link interruption, NMS restart, or network instability, the key events such as alarms, logs, and configuration changes generated by the managed device during the service abnormality can still be completely restored. This effectively avoids the event loss problem caused by service interruption in the traditional polling or passive reporting mode, and improves the integrity, synchronization reliability, and fault recovery capability of network management data.

[0026] Furthermore, this method is applicable to various network environments. For all-optical indoor networks deployed using FTTR, a large number of optical access terminals are distributed as managed devices in various rooms of homes or enterprises. The configuration changes, link alarms, QoS events, etc. generated by these terminals are crucial to network operation and maintenance. This application proactively initiates synchronization requests to the managed devices based on the latest synchronization progress information, enabling each FTTR terminal to accurately transmit device events cached during NMS service anomalies. This effectively compensates for monitoring blind spots caused by momentary unavailability of the management plane, thereby improving the operational reliability and user experience of the FTTR network. Attached Figure Description

[0027] Figure 1 is an exemplary schematic diagram of the architecture of a network management system (NMS) and managed devices in the prior art; Figure 2A is a schematic flowchart of a device management method according to an exemplary embodiment of this application; Figure 2B is an exemplary embodiment of this application showing the interaction between an NMS and any managed device; Figure 3 is an exemplary embodiment of this application showing another device management method; Figure 4 is an exemplary embodiment of this application showing the structure of a device management apparatus; Figure 5 is an exemplary embodiment of this application showing another device management apparatus; Figure 6 is an exemplary embodiment of this application showing the hardware of an electronic device. Detailed Implementation

[0028] Exemplary embodiments will now be described in detail. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0029] NMS (Network Management System): A system responsible for the centralized management and monitoring of various managed devices in the network. It is used to collect information such as device status, alarms, logs, and configuration changes of managed devices, and to perform unified operation and maintenance management of the network.

[0030] Managed Device: Network nodes managed by NMS, including but not limited to switches, routers, wireless controllers, optical network units, etc.

[0031] With the rapid development of scenarios such as cloud computing, the Internet of Things, FTTR, and large enterprise campus networks, network scale and the number of devices continue to grow, and the vendors and types of network devices are becoming increasingly diverse. In real-world networks, switches, routers, wireless devices, optical access FTTR devices, etc. from multiple vendors are often deployed simultaneously, forming a heterogeneous, multi-vendor mixed network environment.

[0032] In such networks, the Network Management System (NMS) plays a crucial role in centralized monitoring, unified operation and maintenance, and policy control. For example, referring to Figure 1, which illustrates an example of an NMS and managed devices, the NMS centrally monitors managed devices 1 through n. It needs to periodically or in real-time acquire various types of information from each managed device, including but not limited to: operational status (e.g., interface up / down status, link connectivity, CPU / memory utilization, etc.) for monitoring device health; alarm information (e.g., link interruption, port error, board failure, overheating, etc.) for fault detection and location; log information (e.g., system logs, security logs, service logs) for fault tracing, security auditing, and behavior analysis; configuration change information (recording configuration additions, modifications, and deletions) for change management, compliance auditing, and issue tracing; and performance metrics (e.g., traffic, latency, packet loss rate, error rate) for capacity planning and service quality assurance.

[0033] In traditional network management architectures, NMS and managed devices mainly interact through the following two mechanisms: 1) NMS proactive polling: NMS proactively queries the current status and some performance information of the device at fixed intervals using SNMP, NetConf, REST API or vendor-specific protocols, such as: interface up / down status, link status; current uncleared alarm list or recent alarms; current CPU / memory usage and other resource utilization information.

[0034] This method is mainly used to obtain a snapshot of the current device status of the managed device. For short-lived events that have already occurred and ended, most cannot be obtained by actively polling, resulting in limited knowledge of the device event sequence of the managed device over a period of time.

[0035] 2) Managed devices proactively report: When internal events are triggered (such as alarm generation / recovery, critical log events), or after periodic aggregation, managed devices proactively report to the NMS via Syslog, SNMP Trap, or a custom protocol. For example, when an alarm is generated or recovered, an SNMP Trap or Syslog message is reported; system logs, security logs, or performance statistics are reported in batches periodically; and some devices report relevant logs when important operations or configuration changes occur.

[0036] This method enables relatively real-time alarm and log collection when NMS is continuously online and the network is stable.

[0037] However, in scenarios where NMS is experiencing management service anomalies such as restarting, software upgrades, management link interruptions or unstable link quality, large-scale failures, or network instability, both proactive polling and proactive reporting methods have the problem of device events not being synchronized to NMS. This results in critical device events such as alarms, logs, and configuration changes generated by managed devices during NMS service anomalies not being compensated at the NMS end, leading to a series of problems, such as the inability to reconstruct the complete event chain from the occurrence to recovery of the fault, affecting root cause analysis, and the inability to track the specific details of configuration changes due to broken audit chains.

[0038] In view of this, this application provides a device management method applicable to scenarios where an NMS manages one or more managed devices. The managed devices can be products from different manufacturers and support multiple protocol interfaces (such as SNMP, NetConf, REST API, Syslog, etc.). This method solves the problem of device event loss in abnormal scenarios such as NMS process restart, system crash recovery, and prolonged management link interruption. The method actively obtains the latest synchronization progress information of device events between each managed device and the NMS, and constructs a synchronization request message carrying a synchronization window trigger flag based on this latest synchronization progress information. This initiates a precise and controllable device event synchronization mechanism to the managed devices. Based on this synchronization request message, the managed devices can define the scope of device events that need to be synchronized, avoiding duplicate transmission of already synchronized device events, improving transmission efficiency, and achieving efficient backtracking and completion of device events missed during NMS service interruptions.

[0039] This method is applicable to wireless networking environments with various networking modes, including traditional access networks and all-optical access networks with FTTR (Fiber To The Room) architecture, to improve the reliability of wireless data transmission in various networking scenarios. Taking an FTTR network as an example, the wireless access terminal device can be an FTTR slave gateway (optical AP) deployed in each room, and the NMS can be a centralized network management system deployed at the central office or cloud side to uniformly monitor and manage the optical access devices throughout the home or enterprise campus; the managed devices can be FTTR terminal devices that support local event caching capabilities, such as optical network units (ONUs), Wi-Fi 6 / 7 optical APs, and smart edge gateways distributed in each room.

[0040] In this embodiment, the NMS and any managed device pre-agree on a unified message structure for device event synchronization (such as the message structure of a synchronization request message and a response message to the synchronization request message). This structure covers information such as the field structure, field semantics, parsing method, and synchronization interaction protocol specifications of the message. Furthermore, a unified event description format for various device events is pre-defined, enabling devices from different vendors to use unified access and state synchronization under the same NMS, thereby reducing the adaptation complexity and maintenance costs caused by differences in vendor proprietary formats.

[0041] Device events generated during the operation of any managed device under the NMS management, including but not limited to alarm generation / clearing, configuration changes, security logs, performance limit violations, system restarts, etc., are all structured and organized according to a unified event description format and cached in the managed device, such as in the synchronization window maintained by the managed device.

[0042] The unified event description format includes a predefined set of fields and field semantic specifications, used to provide a unified and structured description of device events from various heterogeneous sources, ensuring consistency in semantics and expression for device events generated by different manufacturers and types of devices. The synchronization window is a local buffer on the managed device used to temporarily store device events generated within a recent period. The types of device events stored in this synchronization window, the synchronization window capacity, and the synchronization window retention period can be determined according to the caching policy configured by the NMS for the network device.

[0043] The unified event description format may include at least the following fields: an event identifier for the device event and an event timestamp. The event identifier uniquely identifies the device event within the global scope of the managed device / across all managed devices managed by the NMS, ensuring accurate identification, comparison, and deduplication of device events during cross-time-segment synchronization, and preventing the NMS from repeatedly storing and processing the same device event. The event timestamp accurately records the actual trigger time (UTC or nanosecond level) of the device event on the managed device, serving as a crucial basis for device event timing, synchronization window calculation, and fault link restoration.

[0044] Based on this, this embodiment describes the device management method proposed in this application from the perspective of the Network Management System (NMS). The following method is at least applicable to the situation where the NMS is recovering from a management service interruption, that is, the situation after the NMS is unable to receive the reported messages from the managed devices or initiate a synchronization request, such as the NMS process restart, NMS upgrade, system crash recovery, or reactivation after the management service has been unavailable for a long time. It is also at least applicable to the situation of device event synchronization during the normal service management process of the NMS.

[0045] Referring to Figure 2A, which exemplarily illustrates a flowchart of a device management method, the method may include at least the following steps: S201, for any managed device, determining the latest synchronization progress information between the managed device and the NMS; the latest synchronization progress information is used to characterize the event range of device events that the managed device has successfully synchronized to the NMS; the latest synchronization progress information is used to identify the latest synchronization progress of device event synchronization that has been performed between the managed device and the NMS, indicating the synchronization anchor point of the latest device event from the managed device that the NMS has successfully received and persisted, and the anchor point is used to define the starting position of the next device event synchronization within the managed device, ensuring that after the NMS single incremental synchronization ends / after the NMS service recovers abnormally, it can continue to pull unsynchronized device events from the breakpoint, avoiding the omission or duplicate synchronization of device events.

[0046] The latest synchronization progress information between the managed device and the NMS can be stored in the NMS's local database, configuration file, memory cache, or distributed state storage system. The storage location and persistence strategy can be flexibly configured according to actual deployment needs, and this application does not limit them.

[0047] When the unified event description format includes an event identifier and an event occurrence timestamp for each device event, and any device event includes both an event identifier and an event occurrence timestamp, then the various device events generated locally by the same managed device can be arranged in an ordered manner according to a preset global event identifier sequence. The global event identifier sequence is a unique and globally ordered sorting rule for event identifiers within the managed device scope, and it maintains the same order as the event occurrence timestamps of the device events. That is, the later the event occurrence timestamp of a device event, the later its event identifier appears in the preset global event identifier sequence. In other words, the arrangement order of the global event identifier sequence is consistent with the actual chronological order of the device events, ensuring that the event identifiers not only possess uniqueness and global order but also accurately reflect the chronological relationship of events.

[0048] Based on this, the latest synchronization progress information between the managed device and the NMS may include at least: the event identifier of the target event and / or the event occurrence timestamp; the target event includes: the device event located at the last position when the device events of the managed device that have been synchronized to the NMS are sorted according to the preset global event identifier sequence.

[0049] For example, suppose that during a synchronization process, NMS pulls three device events from managed device A, as shown in Table 1 below: Table 1 shows the target event as the device event identified by EVT-1005. The latest synchronization progress information can be represented as {Event Identifier: "EVT-1005", Event Occurrence Timestamp: "2026-02-06T10:07:41Z"}.

[0050] If a successful synchronization recently involved one or more device events, and there are device events that need to be stored in the event database maintained by the NMS for the managed device, then when storing each device event in the event database, the event occurrence timestamp and event identifier of the device event can be compared with the corresponding fields in the latest recorded synchronization progress information: if the event occurrence timestamp of the device event is later than the timestamp in the latest recorded synchronization progress information (or the timestamps are the same but the event identifier has a larger lexicographical order to handle the deterministic ordering of multiple events at the same time), then the latest recorded synchronization progress information in the NMS is updated with the timestamp and event identifier of the device event currently being stored; otherwise, the corresponding fields in the latest recorded synchronization progress information remain unchanged.

[0051] S202, a synchronization request message is constructed based on the latest synchronization progress information; the synchronization request message carries a synchronization window trigger flag; the synchronization window trigger flag is configured with a valid value, which is used to instruct the managed device to determine the device events to be synchronized from the device events cached by the managed device; the synchronization request message is used to actively initiate the event synchronization process after the NMS service recovers abnormally or after the last incremental synchronization ends, and is sent by the NMS to the managed device, with fields filled and encapsulated according to the unified message structure agreed upon by both parties in advance. The synchronization request message carries at least a field indicating the latest synchronization progress information and at least a field indicating the synchronization window trigger flag.

[0052] The synchronization window trigger flag is an explicit control field (such as a Boolean flag or a specific enumeration value) used to instruct the managed device receiving the synchronization request message to search for the device events to be synchronized in its locally maintained synchronization window buffer. For the managed device, when it parses a valid value (such as true, 1, or a predefined "trigger synchronization" code) from the received synchronization request message, it clearly knows that this request is not a normal status query or heartbeat probe, but rather a request to backtrack to cached device events within its local window based on the synchronization anchor point provided by NMS (i.e., the latest synchronization progress information). It then actively filters and returns device events from the cache that have not been reported since the last successful synchronization.

[0053] Based on this synchronization window trigger flag, it is ensured that even critical device events generated during long-term NMS offline periods can be accurately and reliably retransmitted after the NMS service is restored, thereby guaranteeing the integrity and timing consistency of the event sequence.

[0054] To achieve refined, on-demand event synchronization control for managed devices, improve synchronization efficiency, and avoid redundant transmission of irrelevant events, the synchronization request message may further include an event synchronization strategy configured for the managed device. This event synchronization strategy includes the conditions that the managed device must meet to synchronize device events to the NMS, enabling the controlled device to filter device events upon receiving the synchronization request message.

[0055] The event synchronization strategy can be predefined by the synchronization strategy configuration module or function on the NMS side, and can be flexibly configured for a single managed device or a group of managed devices. It can be set according to the various fields describing the device event included in the unified event description format.

[0056] Refer to Table 2 below for an example of a unified event description format. In addition to the event identifier and the event occurrence timestamp, the unified event description format may include at least fields such as the event type, event priority, event details, and extended fields of the device event.

[0057] The event type represents the business category or triggering scenario of the device event, used for event classification and management, such as alarms (ALARM), logs (LOG), configuration changes (CONFIG_CHANGE), etc., facilitating subsequent filtering, statistics, and analysis by type. The event priority represents the severity and urgency level of the event, used to guide operation and maintenance response strategies and event handling priority ranking, typically divided into CRITICAL, MAJOR, MINOR, INFO, etc., supporting differentiated synchronization and alarm notifications. The event details represent the specific description information and contextual data of the event, including but not limited to the event cause, affected objects (such as interfaces, IP addresses, module names), related parameters (such as old / new values), error codes, operating users, etc., providing a complete basis for fault diagnosis and auditing. The extended fields are used to carry vendor-specific or custom additional information, encapsulated in the form of Map (key-value pairs), ensuring that while maintaining the standardization of core fields, it can be compatible with the private attributes or special requirements of different vendor devices, improving the universality and scalability of the protocol.

[0058] Table 2 shows that the event synchronization strategy can include at least the following filtering conditions: event type, event priority, and maximum number of events returned in a single synchronization. For example, the event synchronization strategy can include at least the following: allowed event types (e.g., only synchronizing "alarms" and "configuration changes", ignoring ordinary logs); minimum event priority threshold (e.g., only synchronizing events with "high" priority or higher); time range restrictions (e.g., only synchronizing events that occurred within the last 2 hours, even if earlier events exist in the cache); and the maximum number of events in a single synchronization (e.g., returning a maximum of 100 events to prevent a sudden surge of events from causing network or processing congestion).

[0059] The event synchronization strategy is explicitly passed to the managed devices by carrying and sending it through a dedicated field in the synchronization request message. Upon receiving a request with a valid synchronization window trigger flag, the managed device combines the latest synchronization progress information with the event synchronization strategy to filter device events from its local synchronization window that simultaneously meet the filtering conditions in both the latest synchronization progress information and the event synchronization strategy. These selected events are then returned to the NMS as device events to be synchronized.

[0060] Based on this event synchronization strategy, NMS can dynamically adjust the synchronization granularity for each managed device according to different operation and maintenance scenarios (such as fault emergency response requiring full backtracking of high-priority alarms, and daily inspections only focusing on key configuration changes). This ensures event integrity while optimizing system resource consumption, achieving differentiated event synchronization, and optimizing event transmission efficiency.

[0061] If there is no latest synchronization progress information between the managed device and the NMS, or if the latest synchronization progress information is empty, the latest synchronization progress information carried in the synchronization request message can be configured to a set value to instruct the managed device that receives the synchronization request message to synchronize all device events cached by the managed device to the NMS.

[0062] S203, the synchronization request message is sent to the managed device to instruct the managed device to determine the device events to be synchronized from the device events cached by the managed device based on the latest synchronization progress information carried in the synchronization request message, and send the determined device events to the NMS.

[0063] The NMS can send the synchronization request message to the managed device through the management link between the NMS and the managed device.

[0064] Accordingly, upon receiving the synchronization request message, the managed device parses it and, based on the latest synchronization progress information extracted from it, filters out device events that have not yet been synchronized to the NMS from the locally cached device events. Subsequently, the managed device encapsulates the identified device events to be synchronized into a response message according to a pre-agreed message format and returns the response message to the NMS through the management link.

[0065] The device management method provided in this embodiment effectively solves the problem of device event loss in abnormal scenarios such as NMS process restart, system crash recovery, and long-term interruption of management links. It actively obtains the latest synchronization progress information of device events between each managed device and NMS, and constructs a synchronization request message carrying a synchronization window trigger flag based on the latest synchronization progress information. It initiates a precise and controllable device event synchronization mechanism to the managed devices. Based on the synchronization request message, the managed devices can define the scope of device events that need to be synchronized, avoid duplicate transmission of synchronized device events, improve transmission efficiency, and realize efficient backtracking and completion of device events missed during NMS service interruption.

[0066] Furthermore, this method is applicable to various network environments. For all-optical indoor networks deployed using FTTR, a large number of optical access terminals are distributed as managed devices in various rooms of homes or enterprises. The configuration changes, link alarms, QoS events, etc. generated by these terminals are crucial to network operation and maintenance. This application proactively initiates synchronization requests to the managed devices based on the latest synchronization progress information, enabling each FTTR terminal to accurately transmit device events cached during NMS service anomalies. This effectively compensates for monitoring blind spots caused by momentary unavailability of the management plane, thereby improving the operational reliability and user experience of the FTTR network.

[0067] Based on the above interaction, after sending the synchronization request message to the managed device, the method further includes a step of receiving and processing a response message. Referring to Figure 2B, which exemplarily illustrates the interaction between the NMS and any managed device, the step of receiving and processing the response message includes: S204, receiving a response message returned by the managed device in response to the synchronization request message; wherein, the response message includes at least synchronization window data; the synchronization window data includes device events determined by the managed device from the device events cached by the managed device based on the latest synchronization progress information; the response message may include a dedicated field (e.g., SyncWindowData) for carrying the synchronization window data, the field value of which is the set of device events determined by the managed device from the device events cached locally by the managed device based on the latest synchronization progress information.

[0068] In addition, the response message may also carry a snapshot of the current device status, which reflects the overall operating status of the managed device at the time the response message is generated. This status snapshot can be encapsulated through another dedicated field (e.g., CurrentStatus) to facilitate NMS operations such as status comparison, anomaly detection, or configuration consistency verification.

[0069] S205, based on the synchronization window data included in the response message, update the event database maintained for the managed device, and update the latest synchronization progress information of the managed device's device events to the NMS.

[0070] To ensure the consistency of event data and avoid duplicate writing, when updating the event database maintained for the managed device, it is necessary to first check whether the currently processed device event already exists in the event database.

[0071] Based on this, when updating the event library maintained for the managed device, for each device event included in the synchronization window data, an idempotency check is performed based on the event identifier of the device event; the idempotency check is used to detect whether the device event already exists in the event library maintained for the managed device; if the idempotency check fails (i.e., the device event already exists in the event library), the device event is skipped and no duplicate write operation is performed; if the idempotency check passes (i.e., the device event is not in the event library), the device event is written to the event library matching the event type based on the event type of the device event.

[0072] For example, the synchronization window data reported by a managed device B contains the following three device events: Event A: Event identifier: evt-20260206-001 Event type: LinkDown (link interruption) Occurrence timestamp: 2026-02-06T10:05:23Z Event B: Event identifier: evt-20260206-002 Event type: CPUHighUtilization (CPU high load) Occurrence timestamp: 2026-02-06T10:07:45Z Event C: Event identifier: evt-20260206-001 (same as Event A) Event type: LinkDown Occurrence timestamp: 2026-02-06T10:05:23Z (repeated reporting) When processing these events, NMS performs idempotency checks on each event in sequence: Processing Event A: Check if there is a record with identifier evt-20260206-001 in the event database. If it does not exist (idempotency check passed), then because its event type is LinkDown, it is written into the link status event library corresponding to the managed device B.

[0073] Event B was not found in the event database. The verification passed. Since its type is CPUHighUtilization, it was written to the performance alarm event database corresponding to managed device B.

[0074] Event C: The identifier evt-20260206-001 already exists in the event library (written by event A). The idempotency check failed, so this duplicate event is discarded and not written.

[0075] In this embodiment, the managed device returns a response message based on a preset response message format, enabling the NMS to uniformly process device events reported by products from different manufacturers. Furthermore, each device event carries a globally unique event identifier. Before the device event is entered into the database, the NMS performs an existence check based on the event identifier to avoid duplicate writing of device events. After the device event is successfully entered into the database, the latest synchronization progress information of the managed device is updated to ensure that the synchronization status is consistent with the data persistence and to prevent synchronization boundary disorder caused by processing interruption.

[0076] In addition, after sending a synchronization request message to the managed device, in order to ensure the reliability of event synchronization and the robustness of the system, a timeout retry and fault alarm mechanism can be introduced based on the possibility of abnormal situations such as packet loss, delay or temporary unavailability of the managed device in network communication.

[0077] That is, if no response message is received from the managed device for the synchronization request message within a preset time period, the synchronization request message will be resent to the managed device and the retry count will be incremented if the number of retries to send the synchronization request message to the managed device has not reached the set threshold.

[0078] The retry process continues until a response message is successfully received, or the number of retries reaches the set threshold. If the number of retries to send a synchronization request message to the managed device reaches the set threshold, an operation and maintenance alarm is triggered to notify the administrator to intervene and investigate, so as to avoid continuous loss of event data or long-term inconsistency in synchronization status.

[0079] In cases where the number of retries to send a synchronization request message to the managed device does not reach a set threshold, when the synchronization request message carries a time synchronization strategy, the event synchronization strategy in the synchronization request message can be dynamically adjusted based on the reason for the failure of the previous interaction or the current load status of the managed device to improve the synchronization success rate and reduce system pressure. For example, the maximum number of events allowed to be returned in this synchronization request can be reduced (e.g., the value of the MaxEvents field in the synchronization request message, which indicates the maximum number of events allowed to be returned in the event synchronization strategy), or the synchronization time window range can be narrowed, or only high-priority device events or only events of key interest can be requested to achieve rate limiting or degradation processing.

[0080] Subsequently, the adjusted synchronization request message is sent to the managed device to adapt to its current processing capacity, avoiding response timeouts or drops due to excessive request load, thereby improving the robustness and success rate of the synchronization process.

[0081] Next, this embodiment will explain and illustrate the device management method provided in this application from the perspective of any managed device managed by the NMS. Referring to Figure 3, which illustrates an exemplary flowchart of another device management method, the method may include at least the following steps: S301, receiving a synchronization request message from the NMS; the synchronization request message carries the latest synchronization progress information that the device events of the managed device have been synchronized to the NMS; S302, if the synchronization window trigger flag parsed from the synchronization request message is a valid value, determining the device event to be synchronized from the locally cached device events based on the latest synchronization progress information carried in the synchronization request message; as can be seen from the foregoing embodiment, the latest synchronization progress information between the managed device and the NMS includes: the event identifier of the target event and / or the event occurrence timestamp. Based on this, when determining the device event to be synchronized from the locally cached device events based on the latest synchronization progress information carried in the synchronization request message, device events that meet the reporting conditions can be filtered from the locally cached device events, and the device event to be synchronized can be determined based on the device events that meet the reporting conditions; wherein, the reporting conditions include: the event occurrence timestamp of the device event is later than the event occurrence timestamp of the target event; or, the event identifier of the device event is located after the event identifier of the target event in a preset global event identifier sequence.

[0082] For example, the device events cached locally on the managed device are shown in Table 3 below: Table 3 shows that after the managed device receives the synchronization request message, the latest synchronization progress information carried in it is: {Event Identifier: "EVT-20260206-003"; Event Occurrence Timestamp: "2026-02-06T10:05:00Z"}. The managed device then needs to filter events that meet any of the following reporting conditions: Condition 1: The event occurrence timestamp is later than the target event's timestamp (i.e., >10:05:00Z); → Matching event: EVT-20260206- 004, EVT-20260206-005; Condition 2: The event ID is located after EVT-20260206-003 in the global event identifier sequence; → Assuming the global sequence is strictly ascending in lexicographical / generation order of IDs, then the I of EVT-20260206-004 and EVT-20260206-005 is located after it, thus matching events EVT-20260206-004 and EVT-20260206-005.

[0083] The managed device integrates the device events that meet each of the above conditions into a device event to be synchronized, and encapsulates the device event to be synchronized into a response message: EVT-20260206-004 (LinkDown, 10:07:00Z) and EVT-20260206-005 (MemoryLow, 10:09:00Z). The encapsulated response message is sent to NMS to complete incremental synchronization.

[0084] Furthermore, when the synchronization request message carries an event synchronization strategy, when determining the device event to be synchronized from the locally cached device events based on the latest synchronization progress information carried in the synchronization request message, the event synchronization strategy can be parsed from the synchronization request message first; furthermore, for the device events that meet the reporting conditions from the locally cached device events, the device events that meet the event synchronization strategy are selected as the device events to be synchronized.

[0085] S303, construct a response message based on the device event to be synchronized, and send the response message to the NMS.

[0086] The device event to be synchronized is used as the valid data payload of the response message. A complete response message is constructed according to the response message format pre-agreed with the NMS, and the response message is sent to the NMS through the established management link between the managed device and the NMS.

[0087] To enable those skilled in the art to better understand the device management method provided in this application, this embodiment uses the normal operation of NMS and the recovery of NMS service after abnormal interruption as examples to illustrate the above-mentioned device management method.

[0088] 1. Exemplary description of some fields in the message structure (1) The partial fields of the synchronization request message are shown in Table 4.

[0089] Table 4(2) shows the example field definitions of the CustomWindowConfig field as shown in Table 5: Table 5(3) Examples of some fields in the response message are shown in Table 6: Table 6(4) shows an example of a structured organization description of equipment events (uniform event description format) as shown in Table 7: Table 7 is based on the above message structure and event structured description definition. The following is an exemplary description of NMS and managed devices: (1) NMS-side synchronization policy configuration: used to configure the event synchronization policy for a single device or a group of devices. The event synchronization policy content may include at least: synchronization event type (alarm, configuration change, log, performance event, etc.), minimum priority, time range (e.g., the last 2 hours), maximum number of events in a single event, etc.

[0090] Request Generation: Based on the event synchronization policy and the current LastSyncTimestamp and LastSyncEventID between the managed device and the NMS, a corresponding synchronization request message is generated. This synchronization request message can also carry the following message type: RequestType: FULL: Synchronize the current device state snapshot; INCREMENTAL: Incremental synchronization based on the last synchronization position under normal NMS operation; BREAKPOINT_COMPENSATION: Breakpoint compensation synchronization after NMS service failure recovery.

[0091] The synchronization request message can also carry SyncWindowFlag and CustomWindowConfig.

[0092] Message parsing and event handling: Parse the response messages returned by the device, extract CurrentStatus and SyncWindowData from them, and convert the events into an internal unified format.

[0093] Idempotency verification and storage: Idempotency verification is performed on the EventID of each device event: if the event already exists in the local event library, it is ignored; if it does not exist, it is written to the event library / alarm library / configuration change library, and the LastSyncTimestamp and LastSyncEventID of the device are updated.

[0094] Exception and retry handling: When a synchronization request times out, transmission fails, or the response is abnormal, strategies such as retry, rate limiting (e.g., reducing MaxEvents), and degradation (e.g., synchronizing only high-priority events) are implemented, and an operation and maintenance alarm is triggered when the preset failure threshold is reached.

[0095] Device Management: Maintain the NodeID, device type, manufacturer information, and synchronization status information such as LastSyncTimestamp and LastSyncEventID for each device, which are used to drive incremental synchronization and breakpoint compensation.

[0096] (2) Managed device-side synchronization window management: Maintain one or more synchronization windows in local storage to cache device events generated in the recent period. Different windows can be divided according to event type and priority, or a unified window can be used and the type and priority can be identified by fields to provide basic data storage for breakpoint compensation and incremental difference synchronization.

[0097] The synchronization window can be implemented using a queue or circular buffer structure. When the capacity limit is reached, the oldest events are evicted in chronological order. The capacity, retention period, and quotas based on event type or priority of the synchronization window can be adjusted by the device's default configuration or by the NMS through CustomWindowConfig. Collected alarms, logs, configuration changes, and other events are written to the synchronization window. Each record includes fields such as EventID, EventType, Timestamp, Priority, and Details. Event collection: Alarms, logs, and configuration change events are collected from the device's operation module, log module, and configuration module, and written to the synchronization window in a unified event description format. Each event includes the event description fields defined above, such as EventID, EventType, Timestamp, Priority, and Details.

[0098] Request parsing: Receives and parses NMS synchronization request messages, and identifies fields such as NodeID, RequestType, SyncWindowFlag, LastSyncTimestamp, LastSyncEventID, and CustomWindowConfig.

[0099] Incremental data identification: Based on LastSyncTimestamp and / or LastSyncEventID, determine which events belong to incremental events since the last synchronization, which is used in breakpoint compensation or incremental synchronization scenarios.

[0100] Response generation and message encapsulation: Based on the RequestType and incremental data identification results, construct a standardized response message, fill in CurrentStatus, SyncWindowData and ResponseTime, and send it to NMS.

[0101] Based on the above, this embodiment provides the following synchronization process example: (1) Normal synchronization process When NMS is running normally, the following normal state synchronization process is executed.

[0102] NMS generates a synchronization request message based on the synchronization strategy. RequestType can be FULL or INCREMENTAL, and SyncWindowFlag should be TRUE when the request type is RequestType.

[0103] NMS sends synchronization request messages to managed devices through the management channel.

[0104] The managed device receives and parses the synchronization request message, identifying fields such as NodeID, RequestType, and LastSyncTimestamp.

[0105] The managed device selects the processing logic based on RequestType: ①FULL scenario: Generate a snapshot of the current device status CurrentStatus; ②INCREMENTAL scenario: Identify the set of incremental events from the synchronization window based on LastSyncTimestamp / LastSyncEventID.

[0106] The managed device encapsulates the response message and fills in CurrentStatus, SyncWindowData, and ResponseTime.

[0107] The managed device sends a response message to the NMS.

[0108] NMS parses the response, performs idempotency checks on events in SyncWindowData, writes unprocessed events to storage, and updates LastSyncTimestamp and LastSyncEventID.

[0109] (2) Breakpoint compensation process When NMS restarts due to a restart or abnormal recovery, the breakpoint compensation process is executed to compensate for historical events during the breakpoint period: NMS starts and enters the initialization process.

[0110] NMS determines whether the current startup is an abnormal recovery startup (e.g., detecting the existence of the previous running state information in persistent storage).

[0111] If the startup is due to an abnormal recovery, NMS reads the last synchronization information LastSyncTimestamp and LastSyncEventID from persistent storage for each device.

[0112] NMS generates a breakpoint compensation request for each managed device: RequestType=BREAKPOINT_COMPENSATION, SyncWindowFlag=TRUE, and carries LastSyncTimestamp / LastSyncEventID and CustomWindowConfig.

[0113] The managed device receives and parses the breakpoint compensation request, parses out SyncWindowFlag=TRUE, and triggers the synchronization window backtracking logic.

[0114] The managed device searches for events after the breakpoint in the synchronization window, i.e., events whose Timestamp is greater than LastSyncTimestamp or whose EventID is greater than LastSyncEventID, and filters and sorts them according to the event type, priority, and time range specified in CustomWindowConfig.

[0115] The managed device encapsulates a response message and sends the current status snapshot (CurrentStatus) and the filtered historical events (SyncWindowData) to the NMS.

[0116] The NMS parses the response, performs idempotency checks on each event in SyncWindowData, writes unprocessed events, and updates the LastSyncTimestamp and LastSyncEventID of the device. The breakpoint compensation process ends when all devices have completed the above compensation.

[0117] (3) Abnormal handling and priority synchronization process: If the NMS does not receive a response from the device within the predetermined timeout period during the synchronization process, it needs to retry and handle the abnormality. When the number of returned events is large, high priority events need to be handled first, including: NMS initiating a synchronization request (which can be a regular synchronization or a breakpoint compensation request).

[0118] NMS waits for a device response; the waiting time is configured.

[0119] Determine if a device response was received before the timeout: If yes, proceed with event parsing and priority handling when a response is received within the subsequent timeout period; if no response is received on time, record the synchronization failure, increment the retry count RetryCount by 1, and determine if RetryCount is greater than the maximum retry count MaxRetryTimes: If not, return to S501 and resend the request; if greater, trigger an operation and maintenance alarm and policy adjustment.

[0120] After reaching the maximum number of retries, an operation and maintenance alarm is triggered, prompting you to check network connectivity, device status, and synchronization window capacity. Synchronization parameters can be adjusted according to the strategy (such as reducing MaxEvents, shortening the time window, or synchronizing only high-priority events).

[0121] When a response is received within the timeout period, the SyncWindowData in the response is parsed to obtain the event list; the events are divided into high-priority queues and low-priority queues according to Priority; high-priority queue events are processed first, and idempotency checks and data entry are performed on them; and low-priority queue events are processed (which can be delayed or batched), and LastSyncTimestamp and LastSyncEventID are updated to end the current synchronization process.

[0122] Taking a corporate campus network as an example, the NMS manages hundreds of managed devices. During a planned upgrade, the NMS restart took about 15 minutes, during which multiple link interruptions and configuration change events occurred in the network.

[0123] The last successful synchronization time before NMS restart is T0; the restart period is [T1, T2], where T1 ≥ T0; NMS completes recovery and enters the abnormal recovery process at T2.

[0124] After recovery, NMS performs the following operations: reads the LastSyncTimestamp and LastSyncEventID of each device; initiates a breakpoint compensation request with RequestType=BREAKPOINT_COMPENSATION and SyncWindowFlag=TRUE for each device, carrying LastSyncTimestamp=T0, and specifies through CustomWindowConfig that only high-priority alarms and configuration change events need to be compensated; each device searches for high-priority alarms and configuration change events with Timestamp>T0 in its synchronization window, encapsulates them in SyncWindowData in chronological order, and sends them to NMS; NMS performs idempotency verification on the returned events and stores them in the database, updating LastSyncTimestamp and LastSyncEventID.

[0125] Through this process, NMS fills in all critical alarms and configuration change events during the restart, thereby accurately reconstructing the fault and change history and supporting subsequent root cause analysis and auditing.

[0126] The present invention has the following beneficial effects: 1) Accurate compensation of historical data during breakpoints: By combining the device-side synchronization window and the breakpoint compensation request led by NMS with LastSyncTimestamp / LastSyncEventID, the present invention achieves retrospective compensation of key events during NMS restart or abnormal recovery. Compared with existing solutions that rely solely on device buffering and simple batch reporting, the present invention can more accurately recover the event sequence during breakpoints, significantly reducing the risk of historical event loss.

[0127] 2) Standardized and unified access for multi-vendor devices: By uniformly defining the synchronization request and response message structure and event data structure, this invention provides a unified access framework for multi-vendor devices. NMS only needs to implement standardized parsing logic once to support multiple vendor devices. This significantly reduces integration costs and is beneficial for promotion and maintenance in large-scale, multi-vendor network environments.

[0128] 3) Customizable synchronization window policies: Through CustomWindowConfig, NMS can flexibly configure synchronization window policies by device or device group. For example, during a fault, high-priority alarms and configuration changes can be synchronized first, while performance indicators and some logs can be synchronized during routine inspections. This flexibility enables the system to implement differentiated synchronization policies for different operation and maintenance scenarios, improving operation and maintenance efficiency.

[0129] 4) Incremental Differential Synchronization Improves Synchronization Efficiency: This invention implements incremental differential synchronization based on LastSyncTimestamp and / or LastSyncEventID, enabling the device to only return newly added or changed events after the breakpoint, avoiding repeated transmission of historical data. Especially in large-scale networks and high-frequency synchronization scenarios, it can effectively reduce bandwidth consumption and NMS-side storage / processing pressure, thereby improving overall synchronization efficiency.

[0130] 5) Idempotent verification ensures data consistency. By assigning a unique EventID to each event and performing idempotent verification on the NMS side, this invention can ensure that the same event will only be processed once in complex scenarios such as breakpoint compensation, multiple retries, and device-initiated reporting, avoiding duplicate alarms, duplicate logs, and chaotic configuration records, and significantly improving the reliability of operation and maintenance data.

[0131] 6) Anomaly self-healing and priority queues enhance system robustness. Through retry mechanisms, anomaly alarms, and event priority-based queue processing strategies, this invention can automatically adjust synchronization behavior when network quality fluctuates or device load is high, prioritize the synchronization of critical events, and trigger manual intervention when anomalies persist, thereby improving the overall robustness and availability of the system.

[0132] Corresponding to the aforementioned device management method embodiments, as shown in Figure 4, this application also provides an embodiment of a device management apparatus applied to a network management system (NMS). The apparatus includes: a synchronization progress information acquisition module 401, configured to determine, for any managed device, the latest synchronization progress information between the managed device and the NMS; the latest synchronization progress information is used to characterize the event range of device events that the managed device has successfully synchronized to the NMS; a synchronization request message construction module 402, configured to construct a synchronization request message based on the latest synchronization progress information; the synchronization request message carries a synchronization window trigger flag; the synchronization window trigger flag is configured to a valid value, the valid value being used to instruct the managed device to determine the device event to be synchronized from the device events cached by the managed device; and a message sending module 403, configured to send the synchronization request message to the managed device to instruct the managed device to determine the device event to be synchronized from the device events cached by the managed device based on the latest synchronization progress information carried in the synchronization request message, and to send the determined device event to the NMS.

[0133] In some embodiments, the device event includes an event identifier and an event occurrence timestamp; the latest synchronization progress information includes an event identifier and / or an event occurrence timestamp of a target event; the target event includes: the device event located at the last position when all device events of the managed device that have been synchronized to the NMS are sorted according to a preset global event identifier sequence.

[0134] In some embodiments, after sending the synchronization request message to the managed device, the apparatus further includes: a response message receiving module configured to receive a response message returned by the managed device in response to the synchronization request message; the response message includes synchronization window data; the synchronization window data includes device events determined by the managed device from the device events cached by the managed device based on the latest synchronization progress information; and an event database and progress information updating module configured to update the event database maintained for the managed device and update the latest synchronization progress information of the managed device's device events synchronized to the NMS based on the synchronization window data included in the response message.

[0135] In some embodiments, when the event library and progress information update module is configured to update the event library maintained for the managed device based on the synchronization window data included in the response message, it includes: a verification module, configured to perform idempotency verification for each device event included in the synchronization window data based on the event identifier of the device event; the idempotency verification is used to detect whether the device event already exists in the event library maintained for the managed device; and a writing module, configured to write the device event to an event library matching the event type based on the event type of the device event if the idempotency verification passes.

[0136] In some embodiments, the synchronization request message further includes an event synchronization policy configured for the managed device; the event synchronization policy includes the conditions that the managed device must meet to synchronize device events to the NMS.

[0137] In some embodiments, after sending the synchronization request message to the managed device, the device further includes: a retry module, configured to resend the synchronization request message to the managed device if no response message is received from the managed device for the synchronization request message within a preset time period, provided that the number of retries to send the synchronization request message to the managed device has not reached a set threshold; and an alarm module, configured to trigger an operation and maintenance alarm if the number of retries to send the synchronization request message to the managed device reaches a set threshold.

[0138] This application also provides another embodiment of a device management device, as shown in Figure 5, applied to any managed device managed by a Network Management System (NMS). The device includes: a message receiving module 501, configured to receive a synchronization request message from the NMS; the synchronization request message carries the latest synchronization progress information that the device events of the managed device have been synchronized to the NMS; an incremental synchronization module 502, configured to, when the synchronization window trigger flag parsed from the synchronization request message is valid, determine the device events to be synchronized from locally cached device events based on the latest synchronization progress information carried in the synchronization request message; and a response module 503, configured to construct a response message based on the device events to be synchronized and send the response message to the NMS.

[0139] In some embodiments, the device event includes an event identifier and an event occurrence timestamp; the latest synchronization progress information includes an event identifier and / or an event occurrence timestamp of the target event; the target event includes: the device event located at the last position when all device events synchronized to the NMS by the managed device are sorted according to a preset global event identifier sequence; when the incremental synchronization module is configured to determine the device event to be synchronized from the locally cached device events, it includes: filtering device events that meet the reporting conditions from the locally cached device events, and determining the device event to be synchronized based on the device events that meet the reporting conditions; wherein, the reporting conditions include: the event occurrence timestamp of the device event is later than the event occurrence timestamp of the target event; or, the event identifier of the device event is located after the event identifier of the target event in the preset global event identifier sequence.

[0140] In some embodiments, the synchronization request message also carries an event synchronization strategy; the event synchronization strategy includes the conditions that the managed device needs to satisfy to synchronize device events to the NMS; when the incremental synchronization module is configured to determine the device events to be synchronized from the locally cached device events, it includes: parsing the event synchronization strategy from the synchronization request message; and selecting the device events that satisfy the event synchronization strategy from the device events that meet the reporting conditions in the locally cached device events as the device events to be synchronized.

[0141] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0142] This application also provides an electronic device, the structural schematic of which is shown in FIG6. The electronic device 600 includes at least one processor 601, a memory 602, and a bus 603. At least one processor 601 is electrically connected to the memory 602. The memory 602 is configured to store at least one computer-executable instruction, and the processor 601 is configured to execute the at least one computer-executable instruction, thereby performing the steps of any device management method provided by any embodiment or any optional implementation of this application.

[0143] Furthermore, the processor 601 can be an FPGA (Field-Programmable Gate Array) or other devices with logic processing capabilities, such as an MCU (Microcontroller Unit) or a CPU (Central Processing Unit).

[0144] This application also provides another readable storage medium storing a computer program that, when executed by a processor, implements the steps of any device management method provided in any embodiment or optional implementation of this application.

[0145] The readable storage media provided in this application include, but are not limited to, any type of disk (including floppy disk, hard disk, optical disk, CD-ROM, and magneto-optical disk), ROM (Read-Only Memory), RAM (Random Access Memory), EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory, magnetic cards, or optical cards. In other words, readable storage media include any medium by which a device (e.g., a computer) stores or transmits information in a readable form.

[0146] The device management method, apparatus, device, and readable storage medium of this application embodiment can be used in a network management system (NMS). In abnormal scenarios such as management link interruption, NMS restart, or network instability, it can still completely restore key events such as alarms, logs, and configuration changes generated by the managed device during the NMS service abnormality. It can be applied to various networking methods such as traditional access networks and all-optical access networks, including but not limited to FTTR fiber-to-the-room networking scenarios.

[0147] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for managing equipment, characterized in that, The method, applied to a network management system (NMS), includes: for any managed device, determining the latest synchronization progress information between the managed device and the NMS; the latest synchronization progress information is used to characterize the event range of device events that the managed device has successfully synchronized to the NMS; constructing a synchronization request message based on the latest synchronization progress information; the synchronization request message carrying a synchronization window trigger flag; the synchronization window trigger flag being configured with a valid value, the valid value being used to instruct the managed device to determine the device events to be synchronized from the device events already cached by the managed device; sending the synchronization request message to the managed device to instruct the managed device to determine the device events to be synchronized from the device events already cached by the managed device based on the latest synchronization progress information carried in the synchronization request message, and sending the determined device events to the NMS.

2. The method according to claim 1, characterized in that, The device event includes an event identifier and an event timestamp. The latest synchronization progress information includes the event identifier of the target event and / or the event occurrence timestamp; The target event includes: the device event located at the last position when the device events of the managed device that have been synchronized to the NMS are sorted according to the preset global event identifier sequence.

3. The method according to claim 1, characterized in that, After sending the synchronization request message to the managed device, the method further includes: receiving a response message returned by the managed device in response to the synchronization request message; the response message includes synchronization window data; the synchronization window data includes device events determined by the managed device from the device events cached by the managed device based on the latest synchronization progress information; updating the event database maintained for the managed device according to the synchronization window data included in the response message, and updating the latest synchronization progress information that the device events of the managed device have been synchronized to the NMS.

4. The method according to claim 3, characterized in that, The step of updating the event database maintained for the managed device based on the synchronization window data included in the response message includes: performing an idempotency check on each device event included in the synchronization window data based on the event identifier of the device event; the idempotency check is used to detect whether the device event already exists in the event database maintained for the managed device; if the idempotency check passes, the device event is written to the event database matching the event type based on the event type of the device event.

5. The method according to claim 1, characterized in that, The synchronization request message also includes an event synchronization policy configured for the managed device; the event synchronization policy includes the conditions that the managed device must meet to synchronize device events to the NMS.

6. The method according to claim 1, characterized in that, After sending the synchronization request message to the managed device, the method further includes: if no response message is received from the managed device for the synchronization request message within a preset time period, then if the number of retries to send the synchronization request message to the managed device has not reached a set threshold, the synchronization request message is resent to the managed device; if the number of retries to send the synchronization request message to the managed device reaches the set threshold, an operation and maintenance alarm is triggered.

7. A method for managing equipment, characterized in that, The method, applicable to any managed device managed by a Network Management System (NMS), includes: receiving a synchronization request message from the NMS; the synchronization request message carrying the latest synchronization progress information indicating that device events of the managed device have been synchronized to the NMS; if the synchronization window trigger flag parsed from the synchronization request message is valid, determining the device events to be synchronized from locally cached device events based on the latest synchronization progress information carried in the synchronization request message; constructing a response message based on the device events to be synchronized, and sending the response message to the NMS.

8. The method according to claim 7, characterized in that, The device event includes an event identifier and an event timestamp. The latest synchronization progress information includes the event identifier of the target event and / or the event occurrence timestamp; The target event includes: the device event located at the end when all device events synchronized to the NMS by the managed device are sorted according to a preset global event identifier sequence; the step of determining the device event to be synchronized from the locally cached device events based on the latest synchronization progress information carried in the synchronization request message includes: filtering device events that meet the reporting conditions from the locally cached device events, and determining the device event to be synchronized based on the device events that meet the reporting conditions; wherein, the reporting conditions include: the event occurrence timestamp of the device event is later than the event occurrence timestamp of the target event; or, the event identifier of the device event is located after the event identifier of the target event in the preset global event identifier sequence.

9. The method according to claim 7 or 8, characterized in that, The synchronization request message also carries an event synchronization policy; the event synchronization policy includes the conditions that the managed device must meet to synchronize device events to the NMS; The step of determining the device events to be synchronized from the locally cached device events based on the latest synchronization progress information carried in the synchronization request message includes: parsing the event synchronization strategy from the synchronization request message; From the device events that meet the reporting conditions selected from the locally cached device events, the device events that satisfy the event synchronization strategy are selected as the device events to be synchronized.

10. An equipment management device, characterized in that, An apparatus applied to a network management system (NMS) includes: a synchronization progress information acquisition module configured to determine, for any managed device, the latest synchronization progress information between the managed device and the NMS; the latest synchronization progress information is used to characterize the event range of device events that the managed device has successfully synchronized to the NMS; a synchronization request message construction module configured to construct a synchronization request message based on the latest synchronization progress information; the synchronization request message carries a synchronization window trigger flag; the synchronization window trigger flag is configured to a valid value, the valid value being used to instruct the managed device to determine the device events to be synchronized from the device events cached by the managed device; and a message sending module configured to send the synchronization request message to the managed device to instruct the managed device to determine the device events to be synchronized from the device events cached by the managed device based on the latest synchronization progress information carried in the synchronization request message, and to send the determined device events to the NMS.

11. An equipment management device, characterized in that, The apparatus, applicable to any managed device managed by a Network Management System (NMS), comprises: a message receiving module configured to receive a synchronization request message from the NMS; the synchronization request message carrying the latest synchronization progress information indicating that the device events of the managed device have been synchronized to the NMS; an incremental synchronization module configured to, when the synchronization window trigger flag parsed from the synchronization request message is valid, determine the device events to be synchronized from locally cached device events based on the latest synchronization progress information carried in the synchronization request message; and a response module configured to construct a response message based on the device events to be synchronized and send the response message to the NMS.

12. An electronic device, characterized in that, include: Memory, processor; The memory is used to store a computer program; the processor is used to invoke the computer program to implement the method as described in any one of claims 1-6 or 7-9.

13. A readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-6 or 7-9.

Images