Network device monitoring system and apparatus suitable for multiple protocols

Abstract

The present invention relates to the technical field of network security. Disclosed are a network device monitoring system and apparatus suitable for multiple protocols. The system comprises: a data processing layer, a collection driving layer and a data collection layer, wherein the data processing layer is used for periodically generating collection task information and sending same to the collection driving layer, and processing data returned by the collection driving layer; and the collection driving layer is used for generating a driving object on the basis of the collection task information, driving, on the basis of the driving object, the data collection layer to collect specified data, and converting the collected data into data in a unified format and returning same to the data processing layer. By means of a structured design of the system and a rational design of a configuration data structure, the present invention achieves good scalability of codes, and effectively reduces the costs of later upgrades, modifications and maintenance.

Description

A network equipment monitoring system and device suitable for multiple protocols Technical Field

[0001] The present invention relates to the technical field of network security, and in particular to a network equipment monitoring system and device applicable to multiple protocols. Background Art

[0002] A typical operations and maintenance management system primarily implements unified device management and centralized monitoring, collecting device resource and indicator information and using data analysis to implement functions such as device status monitoring, topology display, alarm management, and performance management. An operations and maintenance management system must provide unified platform management and monitoring for a wide range of hardware and software devices, from different manufacturers and models. In real-world environments, devices supporting diverse protocols vary depending on the time of construction and the organization involved. During system implementation, multiple business modules, such as alarm modules, performance modules, and configuration management modules, require access to device resource and indicator information or control devices. Each business module, in order to obtain and process the required information, requires specialized processing procedures tailored to specific device models. This inevitably leads to duplication and fragmentation of processing logic, making code maintenance difficult, and other issues. The diverse range of managed device types and models also increases the difficulty of collecting device information.

[0003] Summary of the Invention

[0004] The present invention aims to solve at least one of the technical problems in the above-mentioned technologies to a certain extent. To this end, the first aspect of the present invention provides a network device monitoring system applicable to multiple protocols, comprising:

[0005] Data processing layer, acquisition driver layer, data acquisition layer; among them,

[0006] The data processing layer is used to: regularly generate acquisition task information and send it to the acquisition driver layer; process the data returned by the acquisition driver layer;

[0007] The acquisition driver layer is used to: generate a drive object according to the acquisition task information, and drive the data acquisition layer to acquire specified data according to the drive object; convert the acquired data into data in a unified format and return it to the data processing layer.

[0008] Preferably, the data processing layer is composed of several submodules, and each submodule is used to initiate collection task information of its corresponding data according to its corresponding polling cycle.

[0009] Preferably, the system further comprises: a data storage layer; the data storage layer is configured to: receive data sent by the data processing layer; and store the received data.

[0010] Preferably, the system further includes: a data display layer; the data display layer is used to: receive data sent by the data processing layer; and display the received data.

[0011] Preferably, the collection task information includes: a list of data to be collected, a code of the data to be collected, an expression of the data to be collected, and device information of a device corresponding to the data to be collected; the device information includes a device type and a device signal.

[0012] Preferably, the acquisition driver layer is used to: match the acquisition task information with a preset protocol configuration parameter table to determine the protocol configuration parameters corresponding to the acquisition task information; generate a drive object according to the drive object parameters; wherein,

[0013] The protocol configuration parameters include: device type, device model, device operating system type, encoding of the data to be collected, and protocol type.

[0014] Preferably, the protocol configuration parameters further include:

[0015] The type of processing algorithm and the processing algorithm corresponding to the data to be collected;

[0016] The acquisition driver layer is used to process the data collected by the data acquisition layer according to the processing algorithm type and processing algorithm of the data to be collected, convert the collected data into data in a unified format and return it to the data processing layer.

[0017] Preferably, the acquisition driver layer is also used to: when it is determined that there is no protocol configuration parameter in the protocol configuration parameter table that completely matches the acquisition task information, replace at least one sub-information in the acquisition task information with a wildcard, and re-match the acquisition task information with the preset protocol configuration parameter table.

[0018] The second aspect of the present invention proposes an electronic device, including a memory and a processor, wherein the memory at least stores computer programs / instructions corresponding to the network device monitoring system applicable to multiple protocols; the processor is at least used to execute the computer programs / instructions stored in the memory.

[0019] A third aspect of the present invention provides a computer-readable storage medium, in which at least a computer program / instruction corresponding to the multi-protocol network device monitoring system is stored.

[0020] Compared with the prior art, the present invention has the following beneficial effects:

[0021] The multi-protocol network device monitoring system proposed in the present invention separates the specialized processing of return values ​​for different device types and models from the data acquisition layer, constructing a collection driver layer for the specialized behaviors and data of different device types and models, such as processing the private MIB of the SNMP protocol. The collection driver layer determines which performance indicator sets are collected by the device via which protocol, while the universal data acquisition layer performs the collection according to different protocols. This advantageously allows the data processing layer to focus solely on the indicators collected by the device, rather than the varying collection methods resulting from different protocols. The data acquisition layer only cares about which indicators are collected via which protocol. The collection driver layer is responsible for converting the specialized data formats generated by different device types and models into a unified, standard data format and returning it to the data processing layer. The monitoring system proposed in the present invention can acquire newly added indicators through configuration without requiring code modifications, resulting in high versatility. Adding new protocol types requires only adding a general protocol processing method to the data acquisition layer and modifying the underlying configuration data. In summary, the present invention achieves excellent code scalability through a structured system design coupled with a rational configuration data structure, effectively reducing the cost of subsequent upgrades, modifications, and maintenance.

[0022] Other features and advantages of the present invention will be described in the following description, and in part will become apparent from the description, or will be understood by practicing the present invention. The purpose and other advantages of the present invention can be realized and obtained by the structures particularly pointed out in the written description and the accompanying drawings.

[0023] The technical solution of the present invention is further described in detail below through the accompanying drawings and embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The accompanying drawings are used to provide a further understanding of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the present invention and do not constitute a limitation of the present invention. In the accompanying drawings:

[0025] FIG1 is a schematic diagram of a network device monitoring system applicable to multiple protocols provided by the present invention;

[0026] FIG2 is a schematic diagram of a network device monitoring system applicable to multiple protocols according to an embodiment;

[0027] FIG3 is a schematic diagram of the inheritance relationship of the acquisition driver layer provided in an embodiment;

[0028] FIG4 is a schematic diagram of an alarm data collection process 1 according to an embodiment;

[0029] FIG5 is a schematic diagram of a second alarm data collection process according to an embodiment;

[0030] FIG6 is a schematic diagram of the third alarm data collection process according to an embodiment;

[0031] FIG7 is a schematic diagram of an electronic device according to an embodiment;

[0032] FIG8 is a schematic diagram of a computer-readable storage medium according to an embodiment. DETAILED DESCRIPTION

[0033] The preferred embodiments of the present invention are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present invention, and are not used to limit the present invention.

[0034] Figure 1 is a schematic diagram of a multi-protocol network device monitoring system according to the present invention. The network device monitoring system includes a data processing layer 101, an acquisition driver layer 102, and a data acquisition layer 103. The data processing layer 101 is configured to periodically generate acquisition task information and send it to the acquisition driver layer 102; process the data returned by the acquisition driver layer 102; and the acquisition driver layer 102 is configured to generate a drive object based on the acquisition task information and drive the data acquisition layer 103 to acquire specified data based on the drive object; and convert the acquired data into data in a unified format and return it to the data processing layer 101.

[0035] According to some embodiments of the present invention, the monitoring system further includes a data storage layer, a data storage layer, and a data presentation layer. The data storage layer is configured to receive and store data sent by the data processing layer. The data presentation layer is configured to receive and display data sent by the data processing layer.

[0036] Figure 2 is a schematic diagram of a network device monitoring system according to an embodiment. In this embodiment, the data acquisition layer of the network device monitoring system shown in Figure 2 is connected to the external interface of a switch deployed between a firewall and a server. Furthermore, in this network device monitoring system, the data display layer, data processing layer, acquisition driver layer, and data acquisition layer are sequentially connected. The data storage layer is connected to the data processing layer, and data flows bidirectionally between these connected layers. The data storage layer also has an external interface that is connected to a database.

[0037] According to some embodiments of the present invention, the data processing layer is composed of several sub-modules, each sub-module is used to initiate the collection task information of its corresponding data according to its corresponding polling cycle, the polling cycles of the sub-modules can be the same or different, each sub-module can independently process a certain type of data, or can jointly process a certain type of data. In some embodiments, the data processing layer is divided into alarm, performance, resource, etc. according to horizontal modules, and each module collects designated resources or indicators according to its own polling cycle. The data processing layer is responsible for initiating the collection task, calling the collection driver layer to drive the data collection layer to collect, and after the driver layer returns the result in a unified format, the processing layer converts the result calculation into the information of the alarm, performance, and resource modules, calls the database storage layer to persist the data, and finally updates the collected data to the data display layer. Each module in this layer only cares about what to get, not how to get it or how to store it.

[0038] According to some embodiments of the present invention, the driver layer: generates a corresponding driver object based on the target device specified by the data processing layer, reads the configuration information based on the collected indicator set, obtains the protocol through which each indicator of the device is obtained, calls the data collection layer to obtain the indicator data, and after returning, calls the relevant processing method to perform special processing on the indicator value, and returns the sorted value to the data processing layer.

[0039] In some embodiments of the present invention, the acquisition driver layer includes: a device driver layer; the device driver layer includes: a switch driver layer, a server driver layer, and a memory driver layer; the switch driver layer is provided with several switch drivers, and the switch driver is used to drive the acquisition layer to collect the port status of the switch, including power information and connection status information; the server driver layer is provided with several server drivers, which are used to collect the operation information of the server, including CPU status, memory status, hard disk status, heat dissipation status, etc.; the memory driver layer is provided with several memory drivers, which are used to collect the power information and hard disk status of the memory, etc. The inheritance relationship of the acquisition driver layer software level in this embodiment is shown in Figure 3, where Driver represents the driver, Switch represents the switch, storage represents the storage device, PortStatus represents the port status, Power represents the power information, LinkStatus represents the connection status, Cpu represents the processor, Memory represents the memory, Disk represents the memory, Fan represents the radiator, getPortStatus() represents the method of obtaining the port status, and the same applies to the others.

[0040] According to some embodiments of the present invention, the collection task information includes: a list of data to be collected, the encoding of the data to be collected, the expression of the data to be collected, and the device information of the device corresponding to the data to be collected; the device information includes the device type and the device signal.

[0041] According to some embodiments of the present invention, the acquisition driver layer generates a driver object in a process including: matching the acquisition task information with a preset protocol configuration parameter table to determine the protocol configuration parameters corresponding to the acquisition task information; generating the driver object based on the driver object parameters; wherein the protocol configuration parameters include: device type, device model, device operating system type, encoding of the data to be collected, and protocol type. In some embodiments of the present invention, when the acquisition driver layer determines that there are no protocol configuration parameters in the protocol configuration parameter table that completely match the acquisition task information, it replaces at least one sub-information in the acquisition task information with a wildcard, which is equivalent to relaxing the matching conditions and re-matching the acquisition task information with the preset protocol configuration parameter table. In some embodiments, the protocol configuration parameters also include: the processing algorithm type and processing algorithm corresponding to the data to be collected; the acquisition driver layer is used to: process the data collected by the data acquisition layer according to the processing algorithm type and processing algorithm of the data to be collected, and convert the collected data into data in a unified format and return it to the data processing layer.

[0042] The embodiment of the present invention provides a process for collecting alarm data in a multi-protocol network device monitoring system, including:

[0043] Step 1: Initialize the configuration data and read the resource collection configuration information and performance index collection information of all types and models of devices into the cache;

[0044] Step 2: In the data processing layer, create polling tasks based on the functional modules. Taking the alarm module as an example, obtain the device list, loop to obtain the alarms of each device, and obtain the required collection alarm indicators from the alarm configuration table based on the device type and model of each device. In the following table, * is a wildcard item, indicating a common type and model. The example structure of the alarm configuration table is shown in Table 1 below:

[0045] Table 1

[0046] Step 3: Call the driver layer interface, input device information, and collect the alarm indicator list.

[0047] Step 4: Obtain the device type and model information from the incoming device information, create the corresponding driver object, and obtain the collection alarm indicator list information. Based on the above information, obtain the corresponding collection protocol type (0: SNMPGET, 1: SNMPWALK, 2: RPC, 3: RESTful...), return value type (integer, 0: OID list, 1: OID expression or single OID value, 3: Map), calculation formula (string type, can be OID, OID expression, RPC path, RESTful path and parameters, etc.) from the protocol configuration data. In the following table, * indicates a wildcard item, indicating a common type and model. The protocol configuration is shown in Table 2 below:

[0048] Table 2

[0049] Step 5: Determine whether the joint primary key Key = device type + device model + collection alarm indicator + operating system (can be an empty string), and search the table for a match. If so, return to obtain the corresponding protocol type, formula type, and calculation formula. If not, determine whether the joint primary key Key = device type + * + collection indicator + operating system (can be an empty string), change the device model to *, and find out whether a general acquisition method for this type of device exists. If so, return to obtain the corresponding protocol type, formula type, and calculation formula. If still not, determine whether the joint primary key Key = * + * + collection indicator + operating system (can be an empty string), change the device type and device model to *, and find out whether a general acquisition method for all devices exists. If so, return to obtain the corresponding protocol type, formula type, and calculation formula. If it does not exist, return empty.

[0050] Step 6: After the protocol layer obtains the protocol type, formula type, and calculation formula required for the collection indicator, it calls the data collection layer protocol general collection method according to the protocol type and organizes the return value into a unified data format and returns it.

[0051] Step 7: The protocol layer processes the returned data according to the derived class of each device, combining the formula type and calculation formula, and organizes the data into a unified and orderly result object ReturnObj, which is returned to the data processing layer.

[0052] Step 8: After the data processing layer receives the returned data, it determines whether to generate an alarm or restore the alarm based on the alarm expression and alarm recovery expression defined in the alarm configuration table. It then calls the data storage layer to store the updated alarm information in the database and updates the cache. Finally, it sends the alarm message to the data presentation layer for display to the user.

[0053] Figures 4-6 are flow charts for collecting alarm data in a multi-protocol network device monitoring system according to another embodiment of the present invention. It should be noted that lines corresponding to the same letters in Figures 4-6 are connected to each other, for example, the line corresponding to A in Figure 4 is connected to the line corresponding to A in Figure 5, and the same applies hereinafter. Figure 4 illustrates process 1, which includes: system initialization configuration data; the module corresponding to alarm indicator data in the data processing module creates an alarm collection timed polling task; when the alarm collection timed polling task is triggered, the system obtains a list of devices in the monitored network system; the monitoring system cyclically reads device information from the device list; if no device information is read, monitoring ends; when device information is read, a new collection thread is generated and placed in the collection thread pool; the data processing layer obtains a collection alarm indicator list from the device type and model alarm configuration table, generates an alarm data collection task, and the system calls the collection driver layer to create a corresponding driver object based on the device type and model information in the collection task to obtain the alarm indicator list.

[0054] Figure 5 illustrates the second step of this process. This process involves the data driver layer looping through the alarm indicator list, checking for a match based on the combined primary key Key = device type + device model + alarm indicator collection + operating system (which can be an empty string). The data driver layer then searches the table for a match. If so, it returns the corresponding protocol type, formula type, and calculation formula. If not, the indicators are sequentially converted to * based on their importance. For example, the device model is converted to *. The data driver layer then checks for a combined primary key Key = device type + * + alarm indicator collection + operating system (which can be an empty string). A check is performed to determine if a universal acquisition method exists for this type of device. If so, it returns the corresponding protocol type, formula type, and calculation formula. If not, it checks for a universal acquisition method for all devices based on the combined primary key Key = * + * + alarm indicator collection + operating system (which can be an empty string). The device type and model are then converted to *. A check is performed to determine if a universal acquisition method exists for all devices. If so, it returns the corresponding protocol type, formula type, and calculation formula. If not, it returns nothing. Upon obtaining the protocol type, formula type, and calculation formula required for the acquisition indicator, the acquisition driver layer generates a map.

[0055] Figure 6 shows the Map obtained from Figure 5, looping through all relevant indicator data. For example, this involves obtaining collection results using the collection algorithms corresponding to the SNMPGET protocol, the SNMPWALK protocol, the RPC protocol, and the RESTful protocol. If the Map obtained from Figure 5 fails to obtain relevant indicators, this step is repeated until the relevant indicators are obtained. The collection driver layer, based on a preset algorithm and the derived classes of each device, processes the returned data in a targeted manner, combining the formula type and calculation formula. This data is organized into a unified, ordered result object, ReturnObj, and returned to the data core processing layer. After receiving the returned data, the data processing layer determines whether to generate or restore an alarm based on the alarm expression and alarm recovery expression defined in the alarm configuration table. The data storage layer then calls the data storage layer to store the updated alarm information in the database and update the cache. Finally, the alarm message is sent to the data presentation layer for display to the user.

[0056] It should be noted that ICMP stands for Internet Control Message Protocol. It is a subprotocol of the TCP / IP protocol suite and is used to transmit control messages between IP hosts and routers. Control messages refer to network-specific messages such as whether the network is connected, whether the host is reachable, and whether the route is available. SNMP stands for Simple Network Management Protocol, a standard protocol specifically designed for managing network nodes (servers, workstations, routers, switches, and hubs) on IP networks. It is an application layer protocol. MIB refers to a collection of management objects that can be accessed through SNMP. OID refers to the fact that the MIB in SNMP is a tree-like database. The objects managed by the MIB are the end nodes of the tree, and each node has a unique location and name. The IETF stipulates that the Management Information Base Object Identifier (OID) is uniquely assigned, and the naming convention is to use the parent node's name as a prefix for the child node's name. Furthermore, the above examples are merely illustrative of this solution. The system supports protocols including, but not limited to, ICMP, SNMP, RPC, and RESTful. Adding a protocol can be implemented through data configuration and minor extensions to the driver layer code. Adding collection indicators to existing protocols can be accomplished entirely through data configuration.

[0057] Figure 7 illustrates an electronic device 20 according to an embodiment of the present invention, comprising a memory 201 and a processor 202. Memory 201 stores at least a computer program / instructions corresponding to the aforementioned multi-protocol network device monitoring system; processor 202 is configured to execute at least the computer program / instructions stored in the memory. Figure 8 illustrates a computer-readable storage medium 30 according to an embodiment of the present invention, storing at least a computer program / instructions corresponding to the aforementioned multi-protocol network device monitoring system.

[0058] Traditional operation and maintenance management systems manage a wide variety of hardware devices with non-standard models, primarily supporting common SNMP and ICMP protocols. The system provided by the present invention not only supports the management of hardware devices but also multiple software platforms, achieving unified management and centralized monitoring of both hardware and software devices. Furthermore, the system provided by the present invention not only supports protocols such as ICMP, SNMP, RPC, and RESTful, but also supports additional supported protocol types by modifying configuration files. Traditional management systems utilize customized protocol development based on device models, resulting in numerous special processing requirements, poor reusability, and difficulty in maintenance, which increases the cost of subsequent code maintenance. The system provided by the present invention allows new acquisition indicators to be acquired through configuration without requiring code modifications, resulting in strong versatility. Adding new protocol types requires only adding a general protocol processing method to the data acquisition layer and modifying the underlying configuration data. Adding new device types and models requires only adding driver code for the corresponding device type and model to the driver layer and modifying the underlying configuration data. In summary, the present invention achieves excellent code scalability through the structured design of a network device monitoring system and the rational design of configuration data structures, effectively reducing the cost of subsequent upgrades, modifications, and maintenance.

[0059] Obviously, those skilled in the art may make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if such changes and modifications fall within the scope of the claims and their equivalents, the present invention is intended to include such changes and modifications.

Claims

1. A network equipment monitoring system applicable to multiple protocols, characterized in that: include: Data processing layer, acquisition driver layer, data acquisition layer; among them, The data processing layer is used to: regularly generate acquisition task information and send it to the acquisition driver layer; process the data returned by the acquisition driver layer; The acquisition driver layer is used to: generate a drive object according to the acquisition task information, and drive the data acquisition layer to acquire specified data according to the drive object; convert the acquired data into data in a unified format and return it to the data processing layer.

2. The multi-protocol network device monitoring system according to claim 1, wherein: The data processing layer is composed of several submodules, and each submodule is used to initiate collection task information of its corresponding data according to its corresponding polling cycle.

3. The multi-protocol network device monitoring system according to claim 1, wherein: Also includes: Data storage layer; the data storage layer is used to: receive data sent by the data processing layer; The received data is stored.

4. The multi-protocol network device monitoring system according to claim 1, wherein: Also includes: Data presentation layer; the data presentation layer is used to: receive data sent by the data processing layer; Display the received data.

5. The multi-protocol network device monitoring system according to claim 1, wherein: The collection task information includes: a list of data to be collected, a code of the data to be collected, an expression of the data to be collected, and device information of the device corresponding to the data to be collected; the device information includes a device type and a device signal.

6. The multi-protocol network device monitoring system according to claim 5, wherein: The acquisition driver layer is used to match the acquisition task information with a preset protocol configuration parameter table to determine the protocol configuration parameters corresponding to the acquisition task information; Generate a driving object according to the driving object parameters; wherein, The protocol configuration parameters include: device type, device model, device operating system type, encoding of the data to be collected, and protocol type.

7. The multi-protocol network device monitoring system according to claim 6, wherein: The protocol configuration parameters also include: The type of processing algorithm and the processing algorithm corresponding to the data to be collected; The acquisition driver layer is used to process the data collected by the data acquisition layer according to the processing algorithm type and processing algorithm of the data to be collected, convert the collected data into data in a unified format and return it to the data processing layer.

8. The multi-protocol network device monitoring system according to claim 6, wherein: The acquisition driver layer is further used to: when it is determined that there is no protocol configuration parameter in the protocol configuration parameter table that completely matches the acquisition task information, replace at least one sub-information in the acquisition task information with a wildcard, and re-match the acquisition task information with the preset protocol configuration parameter table.

9. An electronic device, characterized in that: It includes a memory and a processor, wherein the memory stores at least a computer program / instruction corresponding to the multi-protocol network device monitoring system as described in any one of claims 1-8; the processor is at least used to execute the computer program / instruction stored in the memory.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium at least stores a computer program / instruction corresponding to the multi-protocol network device monitoring system according to any one of claims 1 to 8.

Images