An adaptive multi-mode snmp network device monitoring method and system
Patent Information
- Application Number
- CN202610928984.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-25
- Publication Date
- 2026-08-18
AI Technical Summary
[0003]然而,异构网络设备通常包含大量厂商私有OID,不同品牌、型号和固件版本的OID树结构差异明显
[0020] Those skilled in the art will understand that the objectives and advantages achievable with the present invention are not limited to those specifically described above, and that the above and other objectives achievable with the present invention will become clearer from the following detailed description.
Smart Images

Figure CN122601433A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of network management system technology, and in particular to an adaptive multi-mode SNMP network device monitoring method and system. Background Technology
[0002] SNMP is a widely used protocol in the field of network device monitoring. Maintenance platforms typically use SNMP polling to obtain the status, resource load, port information, and communication status of devices such as switches, routers, and dedicated optical switches. In existing common solutions, maintenance personnel need to pre-list the OIDs to be collected for each type of device in the collector configuration file. Then, the collector periodically sends SNMP requests to the target devices, and Prometheus or a compatible time-series database retrieves or receives the corresponding metrics.
[0003] However, heterogeneous network devices typically contain a large number of vendor-specific OIDs, and the OID tree structure varies significantly across different brands, models, and firmware versions. In scenarios where device documentation is incomplete or device types change rapidly, maintenance personnel may find it difficult to obtain all the necessary OIDs in advance. This often necessitates manual compilation of OIDs, individual modification of collection configurations, and restarting or reloading of collection components when a new device is connected to the SNMP monitoring system. For devices that only publicly disclose basic management OIDs without fully disclosing their proprietary OIDs, the metric coverage during the initial connection phase may be insufficient. Summary of the Invention
[0004] In view of this, embodiments of the present invention provide an adaptive multi-mode SNMP network device monitoring method and system to eliminate or improve one or more defects existing in the prior art.
[0005] One aspect of the present invention provides an adaptive multi-mode SNMP network device monitoring method, the method comprising the following steps: The NMS asset database is periodically queried to obtain network device records within the current collection period, and target fields are read from the network device records, including a list of pre-configured target OIDs. The acquisition mode is determined based on the pre-configured target OID list, and the acquisition mode includes the pre-configured OID acquisition mode and the OID automatic discovery acquisition mode. If the OID auto-discovery collection mode is used, a list of valid OIDs is constructed based on the OID tree of the corresponding network device point, and the OID values corresponding to the list of valid OIDs are used as the raw SNMP collection data. If the pre-configured OID collection mode is used, an SNMP active collection request is sent to the corresponding network device based on the pre-configured target OID list to obtain the raw SNMP collection data corresponding to the pre-configured target OID list. The original SNMP data is converted into a new format and saved to a database; the list of valid OIDs is then updated to the pre-configured target OID list for the corresponding network device.
[0006] Using the above solution, the NMS asset database is no longer just a passive asset ledger that records the status of devices, but is used as a control plane to drive the SNMP collection strategy. The SNMP monitoring agent reads the target_oids field in each collection cycle and maps the presence or absence of this field directly to the pre-configured OID collection mode or the OID auto-discovery collection mode, so that the device OID knowledge status is coupled with the collection behavior in real time. When the OID auto-discovery collection mode is used, data collection can be completed without exposing private OIDs.
[0007] In some embodiments of the present invention, in the step of constructing a valid OID list based on the OID tree of the corresponding network device point, and using the OID values corresponding to the valid OID list as SNMP raw data, an SNMP Walk request is sent to the corresponding network device to traverse the OID tree, and target numeric OIDs are filtered from the traversal results to construct a valid OID list. The OID values corresponding to the valid OID list are used as SNMP raw data. The format of the SNMP raw data is converted and saved to the database. The valid OID list is then updated to the pre-configured target OID list of the corresponding network device.
[0008] In some embodiments of the present invention, in the step of sending an SNMP active collection request to the corresponding network device based on the pre-configured target OID list to obtain the raw SNMP collection data corresponding to the pre-configured target OID list, an SNMP GET or GETBULK request is sent to the corresponding network device based on the pre-configured target OID list, and the OID value is extracted after receiving the response as the raw SNMP collection data.
[0009] In some embodiments of the present invention, the method further includes the following steps: The system parses the SNMP Trap messages reported by the monitoring network device to obtain the Trap object identifier and variable binding information. Based on the sender address of the SNMP Trap message, it looks up the corresponding unique asset identifier in the NMS asset database, constructs alarm information containing the corresponding unique asset identifier, and pushes it to the alarm management component.
[0010] In some embodiments of the present invention, in the steps of parsing the SNMP Trap messages reported by the monitoring network device to obtain the Trap object identifier and variable binding information, retrieving the corresponding asset unique identifier from the NMS asset database based on the sender address of the SNMP Trap message, constructing alarm information containing the corresponding asset unique identifier, and pushing it to the alarm management component, an independent coroutine is used to listen on UDP port 162. The Trap object identifier, variable binding information, and timestamp are extracted from the PDU field of the SNMP Trap message, and the corresponding asset unique identifier, Trap object identifier, variable binding information, device IP, and alarm level are written together into the alarm.
[0011] In some embodiments of the present invention, in the step of determining the acquisition mode based on the pre-configured target OID list, if the pre-configured target OID list is not empty, the pre-configured OID acquisition mode is adopted; if the pre-configured target OID list is empty, the OID automatic discovery acquisition mode is adopted.
[0012] In some embodiments of the present invention, the target field further includes a unique asset identifier. In the step of converting the format of the raw SNMP data and saving it to the database, the raw SNMP data is converted into Prometheus Exposition Format, and the corresponding unique asset identifier is saved to the database as a tag.
[0013] In some embodiments of the present invention, in the steps of sending an SNMP Walk request to the corresponding network device to traverse the OID tree, filtering target numeric OIDs from the traversal results, constructing a list of valid OIDs, and using the OID values corresponding to the list of valid OIDs as the raw SNMP data, the SNMP Walk request traverses from the starting point of the standard OID tree or from the device manufacturer's enterprise ID subtree; the target numeric OIDs include OIDs with return value types of INTEGER, Counter32, Counter64, Gauge32, or TimeTicks.
[0014] In practice, OIDs that return string descriptions, OID type values, or MAC addresses are filtered to be non-numeric OIDs.
[0015] In some embodiments of the present invention, in the step of updating the list of valid OIDs to the pre-configured target OID list of the corresponding network device, the list of valid OIDs is written into the discovered_oids field of the NMS asset database in a discovered and pending audit status; after receiving the audit confirmation result for the OIDs in the discovered_oids field, the list of valid OIDs is updated to the pre-configured target OID list of the corresponding network device.
[0016] In the specific implementation process, in the step of updating the list of valid OIDs to the pre-configured target OID list of the corresponding network device, the verified OIDs are written into the target_oids field of the NMS asset database, so that the target_oids field becomes the collection mode switching signal for subsequent collection cycles.
[0017] A second aspect of the present invention also provides an adaptive multi-mode SNMP network device monitoring system, the system comprising a computer device including a processor and a memory, the memory storing computer instructions, the processor executing the computer instructions stored in the memory, and the system implementing the steps of the method described above when the computer instructions are executed by the processor.
[0018] A third aspect of the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the aforementioned adaptive multi-mode SNMP network device monitoring method.
[0019] Additional advantages, objects, and features of the invention will be set forth in part in the description which follows, and will also become apparent in part to those skilled in the art upon studying the text, or may be learned by practice of the invention. The objects and other advantages of the invention will become apparent from the description and the accompanying drawings.
[0020] Those skilled in the art will understand that the objectives and advantages achievable with the present invention are not limited to those specifically described above, and that the above and other objectives achievable with the present invention will become clearer from the following detailed description. Attached Figure Description
[0021] The accompanying drawings, which are provided to further illustrate the invention and form part of this application, are not intended to limit the scope of the invention.
[0022] Figure 1 This is a flowchart illustrating the first implementation method of the adaptive multi-mode SNMP network device monitoring method in this solution. Figure 2This is a flowchart illustrating the second implementation method of the adaptive multi-mode SNMP network device monitoring method in this solution. Detailed Implementation
[0023] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and descriptions of this invention are used to explain the invention, but are not intended to limit the invention.
[0024] It should also be noted that, in order to avoid obscuring the invention with unnecessary details, only the structures and / or processing steps closely related to the solution according to the invention are shown in the accompanying drawings, while other details that are not closely related to the invention are omitted.
[0025] like Figure 1 As shown, this invention proposes an adaptive multi-mode SNMP network device monitoring method, the steps of which include: In one implementation, the method can be executed by an adaptive multi-mode SNMP (Simple Network Management Protocol) monitoring agent. The agent can be deployed on an NMS (Network Management System) server, a standalone acquisition node, or a containerized operating environment, and can access the NMS asset database, target network devices, databases, and alarm management components. The network devices can be switches, routers, dedicated optical switches, or other infrastructure devices that support the SNMP protocol.
[0026] Step S100: Periodically query the NMS asset database to obtain network device records within the current collection period, and read target fields from the network device records. The target fields include a list of pre-configured target OIDs. In practice, the Agent queries the NMS asset database according to a preset collection cycle to obtain records of network devices in online, monitored, or discovered states. Each network device record includes at least the device IP, SNMP community word, SNMP version, pre-configured target OID list (target_oids), discovered OID list, and asset unique identifier (asset_id).
[0027] Step S200: Determine the collection mode based on the pre-configured target OID list. The collection mode includes the pre-configured OID collection mode and the OID automatic discovery collection mode. Step S310: If the OID auto-discovery collection mode is adopted, a list of valid OIDs is constructed based on the OID tree of the corresponding network device point, and the OID value corresponding to the list of valid OIDs is used as the raw SNMP collection data. Step S320: If the pre-configured OID collection mode is adopted, an SNMP active collection request is sent to the corresponding network device based on the pre-configured target OID list to obtain the SNMP raw collection data corresponding to the pre-configured target OID list. Step S400: Based on the raw SNMP data, perform format conversion and save it to the database; and update the list of valid OIDs to the pre-configured target OID list of the corresponding network device.
[0028] In practical implementation, the SNMP monitoring agent in this solution uses the pre-configured target OID list in the NMS asset database, specifically the `target_oids` field, as the basis for switching collection strategies. At the start of each collection cycle, the agent reads the device IP, SNMP community word, SNMP version, `target_oids` field, `discovered_oids` field, and `asset_id` field from each network device record. Based on whether the `target_oids` field is empty, it determines whether the current device enters the pre-configured OID collection mode or the automatic OID discovery collection mode. This process transforms the asset database from merely a ledger storing device information into a control plane driving the SNMP collection strategy. In the automatic OID discovery collection mode, the agent traverses the device OID tree using SNMP Walk, filtering the return value types of the traversal results to form a valid OID list suitable for writing to the time-series database. This valid OID list serves as the source of the original SNMP collection data for the current cycle and is also written to the `discovered_oids` field and marked as discovered and awaiting review. After review and confirmation, the valid OID list is updated and written to the `target_oids` field, causing subsequent collection cycles to automatically switch to the pre-configured OID collection mode.
[0029] Using the above solution, the NMS asset database is no longer just a passive asset ledger that records the status of devices, but is used as a control plane to drive the SNMP collection strategy. The SNMP monitoring agent reads the target_oids field in each collection cycle and maps the presence or absence of this field directly to the pre-configured OID collection mode or the OID auto-discovery collection mode, so that the device OID knowledge status is coupled with the collection behavior in real time. When the OID auto-discovery collection mode is used, data collection can be completed without exposing private OIDs.
[0030] In some embodiments of the present invention, in the step of constructing a valid OID list based on the OID tree of the corresponding network device point, and using the OID values corresponding to the valid OID list as SNMP raw data, an SNMP Walk request is sent to the corresponding network device to traverse the OID tree, and target numeric OIDs are filtered from the traversal results to construct a valid OID list. The OID values corresponding to the valid OID list are used as SNMP raw data. The format of the SNMP raw data is converted and saved to the database. The valid OID list is then updated to the pre-configured target OID list of the corresponding network device.
[0031] Specifically, an SNMP Walk request is an operation that traverses the complete OID tree of a device using the SNMP GetNext / GetBulk command, which can automatically discover all OIDs (Object Identifiers) supported by the device.
[0032] In some embodiments of the present invention, in the step of sending an SNMP active collection request to the corresponding network device based on the pre-configured target OID list to obtain the raw SNMP collection data corresponding to the pre-configured target OID list, an SNMP GET or GETBULK request is sent to the corresponding network device based on the pre-configured target OID list, and the OID value is extracted after receiving the response as the raw SNMP collection data.
[0033] Specifically, when the target_oids field is not empty, the Agent constructs an SNMP GET request or an SNMP GETBULK request based on the device IP, SNMP community word, and SNMP version in the device record to collect multiple target OIDs in the target_oids list in batches.
[0034] like Figure 2 As shown, in some embodiments of the present invention, the method further includes the following steps: Step S500: parse the SNMP Trap message reported by the monitoring network device to obtain the Trap object identifier and variable binding information. Based on the sender address of the SNMP Trap message, look up the corresponding unique asset identifier in the NMS asset database, construct alarm information containing the corresponding unique asset identifier, and push it to the alarm management component.
[0035] Specifically, SNMP Trap is an SNMP passive alarm mechanism, which is an asynchronous notification message that the device actively sends to the management station when a fault occurs or the status changes.
[0036] In some embodiments of the present invention, in the steps of parsing the SNMP Trap messages reported by the monitoring network device to obtain the Trap object identifier and variable binding information, retrieving the corresponding asset unique identifier from the NMS asset database based on the sender address of the SNMP Trap message, constructing alarm information containing the corresponding asset unique identifier, and pushing it to the alarm management component, an independent coroutine is used to listen on UDP port 162. The Trap object identifier, variable binding information, and timestamp are extracted from the PDU field of the SNMP Trap message, and the corresponding asset unique identifier, Trap object identifier, variable binding information, device IP, and alarm level are written together into the alarm.
[0037] Specifically, the Agent listens on the SNMP Trap port via an independent coroutine. For SNMP Trap messages proactively reported by network devices, the Agent uses the sender's IP address to look up the asset_id in the same NMS asset database and writes the asset_id into the alarm information; proactively polled metrics also use the asset_id as the tag when converted to Prometheus format. Therefore, although proactively polled metrics and passive Trap alarms come from different sources, they are both aggregated under the same business asset identifier.
[0038] In some embodiments of the present invention, the alarm information constructed by the Agent may include asset_id, device IP, Trap object identifier, variable binding information, alarm level, alarm time, collection mode context, and original message digest. This alarm information is pushed to the AlertManager API, where downstream components perform deduplication, grouping, routing, and notification; alternatively, it can be written to a Kafka message queue or an NMS alarm database.
[0039] AlertManager is an alarm management component in the Prometheus ecosystem, responsible for alarm deduplication, grouping, routing, and notification distribution.
[0040] The above solution unifies Trap monitoring and proactive polling data collection within the same Agent processing chain, reusing the same asset database connection and asset_id mapping logic. Since both Trap alerts and polling metrics carry asset_ids, subsequent fault analysis can focus on a unified view of historical metrics, real-time alerts, and asset ledger information related to business assets, reducing cross-system maintenance costs.
[0041] In some embodiments of the present invention, in the step of determining the acquisition mode based on the pre-configured target OID list, if the pre-configured target OID list is not empty, the pre-configured OID acquisition mode is adopted; if the pre-configured target OID list is empty, the OID automatic discovery acquisition mode is adopted.
[0042] In some embodiments of the present invention, the target field further includes a unique asset identifier. In the step of converting the format of the raw SNMP data and saving it to the database, the raw SNMP data is converted into Prometheus Exposition Format, and the corresponding unique asset identifier is saved to the database as a tag.
[0043] The above approach converts the collected raw SNMP data into Prometheus ExpositionFormat, using asset_id as the primary tag. This directly links monitoring metrics to the NMS asset model, overcoming the problem of historical metric gaps caused by IP changes. The OID numeric string is automatically converted into a readable name using the MIB library; auxiliary tags such as device_ip and asset_type are also appended. After batch construction, the data is pushed to VictoriaMetrics via the Remote Write protocol. This design allows actively polled metrics and passively triggered trap alarms from the same business asset to share the same asset_id tag, supporting unified cross-mode association queries.
[0044] Specifically, VictoriaMetrics is a high-performance time-series database that is compatible with Prometheus and supports the Remote Write protocol for receiving metric data.
[0045] In some embodiments of the present invention, in the steps of sending an SNMP Walk request to the corresponding network device to traverse the OID tree, filtering target numeric OIDs from the traversal results, constructing a list of valid OIDs, and using the OID values corresponding to the list of valid OIDs as the raw SNMP data, the SNMP Walk request traverses from the starting point of the standard OID tree or from the device manufacturer's enterprise ID subtree; the target numeric OIDs include OIDs with return value types of INTEGER, Counter32, Counter64, Gauge32, or TimeTicks.
[0046] In practice, OIDs that return string descriptions, OID type values, or MAC addresses are filtered to be non-numeric OIDs.
[0047] In practice, when the `target_oids` field is empty, the Agent sends an SNMP Walk request to the target network device based on the device IP, SNMP community word, and SNMP version. The traversal starting point can be the standard OID tree starting point 1.3.6.1, or a specific enterprise ID under the device vendor's enterprise ID subtree 1.3.6.1.4.1. When the device record contains `vendor_id` or `device_model`, the Agent can determine the local Walk starting point based on the vendor identifier or device model to reduce traversal of irrelevant OID subtrees.
[0048] Specifically, the OID return results obtained by the Agent from SNMP Walk include the OID numeric string, return value, return value type, and collection time. The Agent performs type determination on each OID return result, retaining only OIDs whose return value type belongs to the numeric set, thus constructing a list of valid OIDs. The numeric set can include INTEGER, Counter32, Counter64, Gauge32, and TimeTicks; for OIDs whose return values are string descriptions, OID type values, or MAC addresses directly written to the time-series database, the Agent filters them as non-numeric OIDs.
[0049] In some embodiments of the present invention, in the step of updating the list of valid OIDs to the pre-configured target OID list of the corresponding network device, the list of valid OIDs is written into the discovered_oids field of the NMS asset database in a discovered and pending audit status; after receiving the audit confirmation result for the OIDs in the discovered_oids field, the list of valid OIDs is updated to the pre-configured target OID list of the corresponding network device.
[0050] In the specific implementation process, in the step of updating the list of valid OIDs to the pre-configured target OID list of the corresponding network device, the verified OIDs are written into the target_oids field of the NMS asset database, so that the target_oids field becomes the collection mode switching signal for subsequent collection cycles.
[0051] Specifically, in this step, operations and maintenance personnel or an automated review process review the list of valid OIDs in the `discovered_oids` field. Review criteria may include MIB name readability, OID return value type, OID stability evaluation value, device model compatibility, business significance of metrics, and alarm rule requirements. For OIDs that pass the review, they are written to the `target_oids` field; for OIDs that fail the review, they can be retained in the `discovered_oids` field and marked as ignored, pending retesting, or of no monitoring value.
[0052] The beneficial effects of this plan include: 1. Reduced configuration threshold: This solution does not require prior knowledge of the complete OID tree of the device; for devices with abundant proprietary OIDs from manufacturers but lacking documentation (such as dedicated optical switches), the SNMP Walk automatic discovery mode can complete the initial metric collection with zero initial configuration.
[0053] 2. Automatic configuration synchronization: This solution uses the asset database as the single configuration source. Asset changes (equipment offline / offline, IP change, OID configuration update) are automatically reflected in the behavior of the next collection cycle. There is no need to manually maintain independent configuration files, which completely eliminates the problem of information separation between configuration files and asset ledgers in the existing solution.
[0054] 3. Simplified architecture: This solution unifies the two monitoring mechanisms of active data collection (Pull mode) and passive Trap reception (Push mode) into a single Agent process, reuses asset database connection and asset_id mapping logic, and reduces the number of operation and maintenance components and system complexity.
[0055] 4. Traceable metrics: This solution uses the asset_id tag to bind proactively polled metrics and passively triggered trap alarms to the same business asset record, supporting asset association queries across time-series databases and alarm systems, which facilitates fault location and asset association analysis.
[0056] 5. OID Knowledge Closed Loop: After the automatically discovered results are filtered numerically, they are written back to the discovered_oids field, forming a complete closed loop of "zero configuration → automatic discovery → write-back and accumulation → manual review → target_oids upgrade → targeted collection". This allows OID knowledge to accumulate over time and continuously improve the coverage of the entire network collection.
[0057] 6. Dynamic and seamless switching: The collection mode is automatically switched at runtime based on changes in the target_oids field in the asset database. Zero-downtime configuration updates can be achieved without restarting the Agent, smoothly upgrading from the high-cost SNMP Walk discovery mode to the high-efficiency collection mode with pre-configured OIDs.
[0058] This invention also provides an adaptive multi-mode SNMP network device monitoring system. The system includes a computer device, which includes a processor and a memory. The memory stores computer instructions, and the processor executes the computer instructions stored in the memory. When the computer instructions are executed by the processor, the system implements the steps of the method described above.
[0059] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the aforementioned adaptive multi-mode SNMP network device monitoring method. The computer-readable storage medium can be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, floppy disks, hard disks, removable storage disks, CD-ROMs, or any other form of storage medium known in the art.
[0060] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the desired tasks. The programs or code segments can be stored in a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave.
[0061] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.
[0062] In this invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.
[0063] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations of the embodiments of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. An adaptive multi-mode SNMP network device monitoring method, characterized in that, The steps of the method include: The NMS asset database is periodically queried to obtain network device records within the current collection period, and target fields are read from the network device records, including a list of pre-configured target OIDs. The acquisition mode is determined based on the pre-configured target OID list, and the acquisition mode includes the pre-configured OID acquisition mode and the OID automatic discovery acquisition mode. If the OID auto-discovery collection mode is used, a list of valid OIDs is constructed based on the OID tree of the corresponding network device point, and the OID values corresponding to the list of valid OIDs are used as the raw SNMP collection data. If the pre-configured OID collection mode is used, an SNMP active collection request is sent to the corresponding network device based on the pre-configured target OID list to obtain the raw SNMP collection data corresponding to the pre-configured target OID list. The original SNMP data is converted into a new format and saved to a database; the list of valid OIDs is then updated to the pre-configured target OID list for the corresponding network device.
2. The adaptive multi-mode SNMP network device monitoring method according to claim 1, characterized in that, In the step of constructing a list of valid OIDs based on the OID tree of the corresponding network device point and using the OID values corresponding to the list of valid OIDs as the raw SNMP data, an SNMP Walk request is sent to the corresponding network device to traverse the OID tree, and the target numeric OIDs are filtered from the traversal results to construct a list of valid OIDs. The OID values corresponding to the list of valid OIDs are used as the raw SNMP data. The original SNMP data is converted into a new format and saved to a database. The list of valid OIDs will be updated to the pre-configured target OID list for the corresponding network device.
3. The adaptive multi-mode SNMP network device monitoring method according to claim 1, characterized in that, In the step of sending an SNMP active collection request to the corresponding network device based on the pre-configured target OID list to obtain the raw SNMP collection data corresponding to the pre-configured target OID list, an SNMP GET or GETBULK request is sent to the corresponding network device based on the pre-configured target OID list, and the OID value is extracted after receiving the response as the raw SNMP collection data.
4. The adaptive multi-mode SNMP network device monitoring method according to claim 1, characterized in that, The method further includes the following steps: parsing the SNMP Trap message reported by the monitoring network device to obtain the Trap object identifier and variable binding information; looking up the corresponding unique asset identifier in the NMS asset database based on the sender address of the SNMP Trap message; constructing alarm information containing the corresponding unique asset identifier; and pushing it to the alarm management component.
5. The adaptive multi-mode SNMP network device monitoring method according to claim 4, characterized in that, In the steps of parsing the SNMP Trap messages reported by the monitoring network device to obtain the Trap object identifier and variable binding information, retrieving the corresponding asset unique identifier from the NMS asset database based on the sender address of the SNMP Trap message, constructing alarm information containing the corresponding asset unique identifier, and pushing it to the alarm management component, an independent coroutine listens on UDP port 162. Based on the PDU field of the SNMP Trap message, the Trap object identifier, variable binding information, and timestamp are extracted, and the corresponding asset unique identifier, Trap object identifier, variable binding information, device IP, and alarm level are written together into the alarm.
6. The adaptive multi-mode SNMP network device monitoring method according to claim 1, characterized in that, In the step of determining the acquisition mode based on the pre-configured target OID list, if the pre-configured target OID list is not empty, the pre-configured OID acquisition mode is adopted; if the pre-configured target OID list is empty, the OID automatic discovery acquisition mode is adopted.
7. The adaptive multi-mode SNMP network device monitoring method according to claim 1, characterized in that, The target field also includes a unique asset identifier. In the step of converting the format of the raw SNMP data and saving it to the database, the raw SNMP data is converted into Prometheus Exposition Format, and the corresponding unique asset identifier is used as a tag and saved to the database.
8. The adaptive multi-mode SNMP network device monitoring method according to claim 2, characterized in that, In the steps of sending an SNMP Walk request to the corresponding network device to traverse the OID tree, filtering target numeric OIDs from the traversal results to construct a list of valid OIDs, and using the OID values corresponding to the list of valid OIDs as the raw SNMP data, the SNMP Walk request traverses from the starting point of the standard OID tree or from the device manufacturer's enterprise ID subtree; the target numeric OIDs include OIDs with return value types of INTEGER, Counter32, Counter64, Gauge32, or TimeTicks.
9. The adaptive multi-mode SNMP network device monitoring method according to claim 1, characterized in that, In the step of updating the list of valid OIDs to the pre-configured target OID list of the corresponding network device, the list of valid OIDs is written into the discovered_oids field of the NMS asset database in a discovered and pending audit status; after receiving the audit confirmation result for the OIDs in the discovered_oids field, the list of valid OIDs is updated to the pre-configured target OID list of the corresponding network device.
10. An adaptive multi-mode SNMP network device monitoring system, characterized in that, The system includes a computer device, which includes a processor and a memory. The memory stores computer instructions, and the processor executes the computer instructions stored in the memory. When the computer instructions are executed by the processor, the system implements the steps of the method as described in any one of claims 1 to 9.