Operation data processing method and device of network equipment, equipment and medium

Abstract

The invention relates to the technical field of data processing, can be applied to business scenes of financial science and technology, medical health and the like, and discloses an operation data processing method and device of network equipment, equipment and a medium. And storing the data as historical operation data entries based on the metadata mapping relationship, displaying the data through a graphical interface and generating a time sequence change curve, receiving a time range selection instruction, determining target data from the historical data, and performing visual display. According to the invention, by providing a unified data acquisition and storage framework, the standardization of historical data of wireless AP equipment of different brands is realized, and the problems of low data compatibility and low analysis efficiency are solved, so that the efficiency and accuracy of network management are remarkably improved, and unified monitoring and optimization analysis of equipment across manufacturers are supported.

Description

Technical Field

[0001] The present invention relates to the technical field of data processing, and particularly to a method, device, equipment and storage medium for processing operation data of network devices. Background Art

[0002] In the current management of wireless AP devices, there are mainly multiple technical deficiencies such as cross-brand device management, data standardization, and device configuration synchronization. Devices from different manufacturers usually adopt different network management systems, resulting in the inability to achieve unified monitoring and management. At the same time, due to the differences in device data formats and the lack of standardized interfaces, it is difficult to interoperate and integrate historical data between devices, increasing the difficulty of data cleaning and analysis. In addition, the "drift" phenomenon of device configurations often occurs, leading to problems with device performance and network coverage, and affecting the stability and reliability of the network.

[0003] In the field of fintech business, the problems of fragmented management of cross-brand wireless devices and lack of data standardization are particularly prominent. The network environment in the financial industry usually involves devices from multiple manufacturers. The lack of a unified network management platform leads to low efficiency of data analysis and monitoring, affecting the risk management, network security, and data compliance of financial institutions. In a multi-brand environment, it is impossible to efficiently integrate device data for comprehensive analysis, increasing the workload and cost of the operation and maintenance team.

[0004] In the field of medical and health business, hospitals and medical institutions often rely on wireless network devices for key operations such as device management and patient data transmission. However, the data fragmentation and incompatibility problems caused by multi-brand devices make it difficult for hospitals to collect, store, and analyze data. The untimely synchronization of medical device configurations will affect the network service quality of hospitals and even the diagnosis and treatment experience of patients. In addition, the lack of integration of device data makes network fault troubleshooting and performance optimization more complex, increasing the operation and maintenance costs of medical institutions and reducing the reliability of devices.

[0005] These problems not only affect the efficiency of network management but also severely restrict the capabilities of multiple industries in device management and data analysis. Therefore, how to achieve data standardization, effective cross-device management, and configuration synchronization in the management of multi-brand devices has become an urgent problem to be solved. Summary of the Invention

[0006] The main purpose of the present invention is to provide a method, device, equipment and storage medium for processing operation data of network devices, aiming to solve the technical problem that the prior art cannot achieve unified data standardization and effective historical data management of cross-brand wireless AP devices, resulting in the inability to compatibly analyze data of devices from different manufacturers, severely restricting the efficiency of network management and the ability of data integration.

[0007] To achieve the above object, the present invention provides a method for processing operation data of a network device, including:

[0008] Collecting operation parameter data of multiple network devices from different sources through a standardized data collection middleware, and converting the operation parameter data into a unified data format;

[0009] Based on a preset metadata mapping relationship, classifying and storing the converted operation parameter data as historical operation data entries;

[0010] Displaying the historical operation data entries through a graphical interface, and generating an operation time series change curve based on the historical operation data entries;

[0011] Receiving a time range selection instruction, and determining target operation parameter data corresponding to the time range from the historical operation data entries according to the time range selection instruction;

[0012] Visually associating and displaying the target operation parameter data and its corresponding historical operation data entries through the graphical interface.

[0013] Further, to achieve the above object, the present invention provides an operation data processing device for a network device, including:

[0014] A data collection and format conversion module, configured to collect operation parameter data of multiple network devices from different sources through a standardized data collection middleware, and convert the operation parameter data into a unified data format;

[0015] A data storage module, configured to classify and store the converted operation parameter data as historical operation data entries based on a preset metadata mapping relationship;

[0016] A data visualization display module, configured to display the historical operation data entries through a graphical interface, and generate an operation time series change curve based on the historical operation data entries;

[0017] A time range query module, configured to receive a time range selection instruction, and determine target operation parameter data corresponding to the time range from the historical operation data entries according to the time range selection instruction;

[0018] An interactive data association module, configured to visually associate and display the target operation parameter data and its corresponding historical operation data entries through the graphical interface.

[0019] Further, to achieve the above object, the present invention further provides a computer device, which includes a memory, a processor, and a running data processing program of a network device that is stored on the memory and can run on the processor. When the running data processing program of the network device is executed by the processor, it implements the steps of the running data processing method of the network device as described above.

[0020] Further, to achieve the above object, the present invention further provides a computer-readable storage medium, on which a running data processing program of a network device is stored. When the running data processing program of the network device is executed by a processor, it implements the steps of the running data processing method of the network device as described above.

[0021] Beneficial effects: The present invention relates to the technical field of data processing and can be applied to business scenarios such as fintech and healthcare. It discloses a running data processing method, device, equipment, and medium for a network device, including: collecting operation parameter data of multiple network devices from different sources through a standardized data collection middleware and converting it into a unified data format, classifying and storing the converted operation parameter data as historical operation data entries based on a preset metadata mapping relationship, displaying the historical operation data entries through a graphical interface and generating a running time series change curve based on these data, receiving a time range selection instruction and determining target operation parameter data from the historical operation data entries according to this instruction, and visually associating and displaying the target operation parameter data with its corresponding historical operation data entries through a graphical interface. By providing a unified data collection and storage framework, the present invention standardizes the historical data of different brand wireless AP devices, solves the problems of data compatibility and low analysis efficiency, thereby significantly improving the efficiency and accuracy of network management, and supporting unified monitoring and optimization analysis of cross-vendor devices. Description of the Drawings

[0022] The present invention will be further described below in conjunction with the drawings and embodiments. In the drawings:

[0023] Figure 1 It is a schematic diagram of an application environment of the running data processing method of a network device in an embodiment of the present invention;

[0024] Figure 2 It is a schematic flowchart of an embodiment of the running data processing method of a network device of the present invention;

[0025] Figure 3 It is a schematic diagram of the functional modules of a preferred embodiment of the running data processing device of a network device of the present invention;

[0026] Figure 4 It is a schematic diagram of the structure of a computer device in an embodiment of the present invention;

[0027] Figure 5 Another structural schematic diagram of the computer device in an embodiment of the present invention. Detailed implementation manners

[0028] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0029] The operation data processing method of the network device provided by the embodiment of the present invention can be applied in an application environment such as Figure 1 where the client communicates with the server through the network. The server can collect the operation parameter data of multiple network devices from different sources through the standardized data acquisition middleware used by the client and convert it into a unified data format, classify and store the converted operation parameter data as historical operation data entries based on the preset metadata mapping relationship, display the historical operation data entries through a graphical interface and generate an operation time series change curve based on these data, receive a time range selection instruction and determine the target operation parameter data from the historical operation data entries according to this instruction, and visually associate and display the target operation parameter data with its corresponding historical operation data entry through the graphical interface. The present invention provides a unified data acquisition and storage framework, realizes the standardization of historical data of different brand wireless AP devices, solves the problems of data compatibility and low analysis efficiency, thereby significantly improving the efficiency and accuracy of network management, and supports the unified monitoring and optimization analysis of cross-vendor devices. Among them, the client can be, but is not limited to, various personal computers, laptop computers, smart phones, tablet computers, and portable wearable devices. The server can be implemented by an independent server or a server cluster composed of multiple servers. The present invention will be described in detail below through specific embodiments.

[0030] Please refer to Figure 2 , Figure 2 which is a flowchart of an embodiment of the operation data processing method of the network device provided by the present invention. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described herein can be executed in a different order.

[0031] As Figure 2 shown, the operation data processing method of the network device proposed by the present invention includes the following steps:

[0032] S10, collecting the operation parameter data of multiple network devices from different sources through the standardized data acquisition middleware, and converting the operation parameter data into a unified data format;

[0033] In this embodiment, the historical information management of network devices involves multiple links such as device data collection, storage, processing, and display of multiple brands. The prior art faces many challenges in implementing these functions. Especially in the data collection and compatibility processing of cross-brand devices, there are significant technical deficiencies. For example, devices of different brands usually adopt different data formats and naming rules, resulting in poor cross-brand data compatibility, which further affects the efficiency and reliability of the device management system. Existing solutions mostly rely on private interfaces and standards provided by manufacturers, leading to system fragmentation and making it difficult to achieve unified cross-brand data management. Therefore, how to standardize, convert the format uniformly, and store efficiently the operation data of multiple network devices from different sources has become a key issue in realizing device historical information management.

[0034] The operation parameter data of network devices usually comes from multiple device manufacturers, and devices of each manufacturer may use different interfaces, protocols, and data formats. To achieve unified cross-brand and cross-device data processing, it is first necessary to collect the operation parameter data from different devices through a standardized data collection middleware. This middleware supports obtaining data through multiple protocols (such as SNMP, Syslog, etc.) and converting this data into a unified data format. The data format conversion process includes standardizing the data fields of different manufacturers and mapping them to a unified naming rule and data structure. This standardized processing not only reduces the inconsistency in data formats but also improves the flexibility of data collection, enabling it to adapt to the characteristics of devices of different manufacturers. For example, an AP of a certain brand may represent the signal strength as "signal_strength", while an AP of another brand uses "received_signal_strength". Through the standardized data collection middleware, the data of these devices can be uniformly converted into the standard field of "signal_strength", thus avoiding information loss or processing errors caused by different data formats between devices. After data conversion, the data of all devices will be stored in a unified format, facilitating subsequent analysis, query, and display.

[0035] In the actual implementation process, the standardized data collection middleware usually includes support for multiple protocols such as SNMP, HTTP, Modbus, etc., and communicates with different devices through these protocols. During the collection process, all the original data first enters the data collection module and is then converted into a unified data format according to preset rules. For example, using a metadata mapping relationship table, the original parameter names of the devices are converted into standardized parameter names, and the parameter value units of different devices are ensured to be consistent, thus avoiding errors during data analysis.

[0036] To achieve standardized data collection, the following technical means can be adopted. First, the data collection module needs to support multiple communication protocols. For example, it can collect the operating status information of devices through the SNMP protocol or receive device log data through the Syslog protocol. Second, the data conversion module needs to map the device-specific data fields to standardized fields according to the characteristics and data formats of different devices through preset mapping rules. In this process, all data fields will be converted using a mapping table according to the protocol specifications of the device manufacturers. For example, the data collected by a device may contain fields with different names such as "received_signal_strength" and "rssi". After conversion, these fields are unified as "signal_strength". At the same time, all data units need to be unified according to the preset conversion rules to ensure that all data units are consistent.

[0037] In addition, the data storage module will receive the converted data and store it as standardized historical operation data entries. These data entries include device identification codes, timestamps, parameter names, and their corresponding values. During the storage process, it is possible to partition the data according to device types or device manufacturers for subsequent query and analysis.

[0038] Example illustration: In the field of medical and health services, there are various medical devices of different brands in a hospital, such as monitors, electrocardiogram devices, etc. The data provided by these devices usually has different formats and protocols. The hospital can uniformly standardize the historical health data collected by all devices to achieve seamless docking of data from different brand devices. In this way, doctors can view the historical health data of patients on a unified management platform and perform trend prediction and early diagnosis through data analysis tools, improving the efficiency and accuracy of medical services.

[0039] In the financial field, the network devices of banks and financial institutions often come from multiple manufacturers, and the formats of device logs and operation data are different, which brings great difficulties to the monitoring and analysis of financial operations. Through the standardized data collection middleware, banks can achieve unified collection and conversion of data from various network devices, thus establishing a unified device monitoring platform. This platform can not only monitor the operating status of various devices in real time but also provide support for risk management and business optimization, enhancing the operating efficiency and data processing capacity of the bank network.

[0040] In this embodiment, by using a standardized data acquisition middleware, the problem of inconsistent data formats among cross-brand devices is solved, and data compatibility among multiple devices is achieved. It not only improves the data consistency of the device management system, but also simplifies the interconnection and interoperability among devices, enhancing the data queryability and analysis efficiency. In addition, the unified data format and structure enable the device management system to easily perform data mining and analysis, thus providing important support for network optimization and fault diagnosis.

[0041] S20, based on a preset metadata mapping relationship, classify and store the converted operation parameter data as historical operation data entries;

[0042] In this embodiment, the collected operation parameter data needs to be classified and stored according to the standardized rules of different devices. To ensure the efficient management and subsequent processing of this data, it is first necessary to further process the data based on a preset metadata mapping relationship. The core goal of this step is to convert the standardized data into historical operation data entries that conform to predefined standards, and ensure that each piece of data can be effectively stored and retrieved according to keyword fields such as device identification and timestamp.

[0043] Specifically, first, according to the preset metadata mapping relationship table, bind information such as device identification code and timestamp in the converted operation parameter data to generate basic data units. This data unit not only contains the standardized parameter data, but also contains relevant metadata, such as device identification code, acquisition timestamp, etc. The key to this process is to ensure that the data fields of different devices can be correctly mapped to standardized fields through the mapping relationship table. For example, in AP devices of different brands, there may be different parameter names, such as "channel interference rate" and "band conflict index" for describing the same parameter. Through the preset metadata mapping relationship, the system can automatically map these device-specific parameter names to a unified standard field name (such as "channel_interference"), thus avoiding data processing errors caused by differences in parameter naming among different devices.

[0044] Subsequently, classify and store these standardized data units. The storage method is usually to partition according to the device identification code, and the data of each device is assigned to a corresponding device-specific storage area. This classification storage approach ensures the efficiency of data query and processing in the subsequent process. Especially when the system needs to retrieve the historical data of a certain device according to the device identification code, it can quickly locate the corresponding data set.

[0045] In the specific implementation process, the metadata mapping relationship table and the device identification code are usually managed by the database system. The mapping relationship table defines the parameter field names of each device and their corresponding standard fields, and this table can be updated manually by the administrator or automatically by the system. The device identification code serves as an important index for data storage, ensuring the precise positioning and classification of data. The system stores each historical operation data entry in the database, and each data entry includes the device identification code, timestamp, standardized parameter value, and other relevant metadata.

[0046] For the storage of operation parameter data, a distributed database system is usually adopted. This system can distribute the data load among multiple servers to ensure the high efficiency of data storage and retrieval. In addition, the timestamp and device identification code of the data serve as key fields, which also facilitate subsequent filtering and retrieval according to the time range or device type.

[0047] In one specific implementation, first, the raw data provided by the device manufacturer will be converted through the standardized data acquisition module. This module supports multiple protocols (such as SNMP, Syslog, etc.) and maps the parameter field names specific to each manufacturer to the unified standard fields through mapping rules. For example, for the "channel interference rate" parameter of an AP device, it can be converted to "channel_interference" through the mapping table. The converted data will carry standardized field names and unified measurement units to ensure seamless integration of cross-device data. The standardized data units will be classified and stored in the database. Through the preset storage strategy, the device data will be partitioned according to the device identification code to ensure that the operation parameter data of each device can be stored separately and accessed independently. For each device data entry, the stored content includes the device identification code, timestamp, standardized parameter value, and other metadata (such as device type, location, etc.). This ensures that data can be precisely retrieved according to the device and time. To improve the efficiency of data storage and retrieval, especially when dealing with a large amount of device data, a distributed database system is adopted. This system can store data in different shards according to the device identification code, and each shard contains data of specific devices, reducing the retrieval time during query. The system uses a distributed query mechanism to obtain data of different devices, ensuring efficient retrieval of historical data even in the case of a large amount of data. During the data storage process, the device identification code and timestamp play a crucial role. The device identification code is the field that uniquely identifies the device, ensuring that the data of each device can be accurately distinguished during storage. The timestamp is used to record the time of data acquisition, ensuring the preservation of the time sequence of data and providing an accurate basis for subsequent time series analysis. The system will classify and index data according to the device identification code and timestamp to quickly locate data within a specific device and time range.

[0048] In this embodiment, by using a standardized data acquisition middleware and a metadata mapping relationship, the problem of inconsistent data formats among multi-brand devices is effectively solved. The system ensures the compatibility and consistency of device data by converting the operation data of devices from different manufacturers into a unified format. Through classification storage based on device identification codes and timestamps, the query and management of data become more efficient and accurate. Especially in a large-scale network environment, the application of a distributed database makes data storage and retrieval more flexible and efficient, meeting the requirements of enterprise-level network device management.

[0049] S30, display the historical operation data entries through a graphical interface, and generate an operation time-series change curve based on the historical operation data entries;

[0050] In this embodiment, the generation and display of the operation time-series change curve is an important analysis step. This step involves extracting the stored historical operation data entries from the database and presenting these data in a graphical form for data analysis and visualization. The core objective of this process is to help users quickly understand the historical operation status, performance changes, and their trends of the device through the graphical interface.

[0051] First, the data extracted from the stored historical operation data entries includes the device identification code, timestamp, and standardized parameter values. These data are uniformly formatted by the standardized data acquisition module to ensure the consistency of data from different devices. Through the graphical interface, users can extract a set of historical operation data entries for a specific device and time range from the distributed time-series database according to the selected time range and device identification code.

[0052] After extracting the data, it is necessary to sort these data according to the timestamp and classify them according to the device identification code. The sorted data will be arranged along the time axis, and a curve graph data sequence with a time coordinate axis and a parameter value coordinate axis will be generated based on the standardized parameter values at each time point. This curve graph data sequence is a visual expression of time-series data and can clearly show the changes in the operation parameters of the device within the specified time range.

[0053] The generated curve graph data sequence is then mapped in the main view area of the graphical interface, presenting as a dynamically changing difference curve. This curve reflects the change in the device operation state over time and can effectively reflect the performance fluctuations of the device at different time periods. Users can view the detailed data of the device operation in a specific time period by adjusting the time axis range.

[0054] The specific implementation method includes, first, obtaining the device identification code and time range instruction input by the user through the front-end graphical interface. The system will extract relevant historical operation data entries from the database according to these inputs. Then, sort the extracted historical data by timestamp, calculate the parameter values at each time point, and generate a curve graph data sequence based on this. When displaying, the curve graph will be rendered through the front-end framework to ensure that users can view the data change trend in real time.

[0055] Example illustration: In the field of medical and health services, medical devices of different brands (such as blood pressure monitors, thermometers, etc.) provide device operation data, such as battery power, working status, parameter readings, etc. Through this technology, the historical operation data of these devices can be displayed as time-series change curves through a graphical interface. Doctors can intuitively understand the working status of the devices based on these curves, promptly detect possible device failures or performance degradation, and improve device management efficiency.

[0056] In the financial field, the data centers of banks may contain network devices of multiple brands (such as switches, firewalls, etc.). Through the historical data of the operation of these devices, it can help the operation and maintenance team monitor the performance fluctuations of the devices at different time periods. Generating time-series change curves for these data through a graphical interface can help the IT personnel of the bank promptly detect possible device failures or performance bottlenecks, ensuring the stable operation of the bank's network and data security.

[0057] This embodiment displays historical operation data entries through a graphical interface and generates an operation time-series change curve, which can effectively help users conduct visual analysis of device performance and monitor the operation status of the device in real time. This way of data visualization can quickly feedback the working trend of the device, help users identify abnormal fluctuations in device operation, make early warnings or scheduling in advance, and improve the efficiency and accuracy of device operation and maintenance.

[0058] S40, receiving a time range selection instruction, and determining target operation parameter data corresponding to the time range from the historical operation data entries according to the time range selection instruction;

[0059] In this embodiment, receiving a time range selection instruction and determining target operation parameter data from the historical operation data entries according to this instruction. This step allows users to filter out data within a specific time range from the historical data for further analysis or display.

[0060] First, the time range selection instruction is an instruction input by the user through the graphical interface, usually including a start timestamp and an end timestamp. These timestamps usually adopt the standard date and time format, such as the ISO 8601 format (e.g., 2023-07-01T14:30:00Z), to ensure the accuracy and consistency of the time range. After receiving the user's time range selection instruction, the system needs to parse the start timestamp and the end timestamp in the instruction to generate a standardized absolute time interval expression, which will be used in subsequent database queries.

[0061] By parsing the start and end timestamps in the time range selection instruction, the system can generate a complete time interval expression. For example, if the user selects to query the data from July 1st to July 31st, 2023, the system will parse this time period, generate a standardized time interval expression, and pass it as a query condition to the subsequent distributed time series database query module.

[0062] Next, the system constructs the query conditions for querying the distributed time series database according to the generated time interval expression. The query conditions usually include the device identification code (to ensure querying the historical data of specific devices) and the time interval (to ensure querying the data within the specified time period). The process of constructing the query conditions is based on the distributed storage structure. The system needs to obtain data from multiple storage shards according to the matching of timestamps and device identification codes. This process requires the distributed time series database to be able to efficiently shard and index timestamps to ensure quickly locating the target data in the massive data.

[0063] In the specific implementation method, the system will generate a corresponding query condition according to the start and end timestamps in the time range selection instruction, and query the historical operation data entries in the database according to this condition. The query result is the target operation parameter data that meets the time range condition, and these data usually include the device identification code, the acquisition timestamp, and the device operation parameter value.

[0064] Example: In the field of medical and health, the equipment managers in the hospital can easily query the operation data of different devices (such as blood glucose meters, electrocardiogram monitors, etc.) within a specific time period. For example, hospital staff can select to query the operation conditions of all devices within a certain time period, and accurately extract relevant data through the device identification code and the timestamp range, which is convenient for health monitoring, performance evaluation, and equipment maintenance.

[0065] In the financial field, the network administrators of financial institutions can search for the operation data of network devices (such as firewalls, switches, etc.) within a specific time period. The administrators can conduct performance analysis on the devices based on the historical data, and timely discover abnormal fluctuations or fault points to ensure the security and stability of the financial system.

[0066] In this embodiment, by accurately parsing the time range selection instruction and efficiently querying the distributed time series database, the target operation parameter data required by the user can be accurately obtained, improving the flexibility and response speed of data query. In addition, the system can support concurrent queries of a large number of devices, ensuring the processing efficiency of device operation data in a high-concurrency environment, and greatly improving the access and analysis capabilities of operation and maintenance personnel to device historical data.

[0067] S50, visually associate and display the target operation parameter data with its corresponding historical operation data entries through the graphical interface.

[0068] In this embodiment, visually associating and displaying the target operation parameter data with its corresponding historical operation data entries through the graphical interface aims to improve the interactivity and understandability of the data. This step is based on the comparison of the aforementioned target operation parameter data and historical operation data entries, and uses the graphical interface to intuitively display the association between the two, helping operation and maintenance personnel better understand the device operation status.

[0069] In the specific implementation process, the design of the graphical interface needs to support real-time display of data from different sources and present the operation parameter data in a visual way. First, the system extracts historical data related to the target device from the historical operation data entries, and this data includes information such as device identification codes, timestamps, parameter values, etc. Subsequently, the system compares the target operation parameter data with the parameter data in the historical operation data entries to generate a device-level time series comparison data sequence. The core of the time series comparison data sequence is to align the target operation parameter data and historical data through timestamps, ensuring that there are consistent parameter values for display and comparison at each time point.

[0070] In the display session, the system will graphically present the difference values, target parameter values, and historical parameter values in the device-level time series comparison data sequence. The graphical interface will map these data to a chart according to the time axis and parameter value coordinate axis, usually using line charts, scatter plots, or bar charts, etc. to display the change trend of the data. At the same time, the graphical interface should also have interactive functions, and users can adjust the display range of the chart by zooming, dragging, etc., so as to facilitate viewing the data changes in a specific time period.

[0071] This graphical interface can dynamically display the change differences between the target operation parameters and historical operation data entries, and provide rich interactive functions. Users can easily view the comparison between historical data and target data, and further analyze the device operation status and trends. This can not only help operation and maintenance personnel quickly discover device anomalies, but also provide accurate data support for subsequent device optimization and fault prevention.

[0072] In one specific implementation, the operating parameter data and relevant historical operating data entries of the target device are extracted from the distributed time-series database, ensuring that the timestamps of the data are aligned, and a device-level time-series comparison data sequence is generated. According to the requirements of the time axis and the parameter value axis, the device-level time-series comparison data sequence is mapped into a dynamic curve or other suitable graphical representation. The graphical interface should support dynamic updates to respond to user interactions, such as adjusting the display range or zooming the chart. The graphical interface provides user interaction functions, such as zooming, panning, and clicking to view detailed information, enabling users to conveniently select the time period of interest and analyze the data fluctuation trend. Ensure that the difference values between the target operating parameter data and the historical operating data entries are clearly displayed in the graphical interface, and the color, size, or other attributes of the difference values can be used to intuitively represent the amplitude of data fluctuations. Different display methods (such as color, line thickness, etc.) can help users quickly identify abnormal fluctuation areas. The system can be optimized based on different display requirements. For example, in the case of a large amount of data, batch loading and partial refresh technologies are adopted to improve the efficiency of chart rendering. In a high-concurrency environment, background data preprocessing and caching technologies are adopted to reduce the loading pressure on the graphical interface and ensure smooth interaction.

[0073] In this embodiment, the target operating parameter data and the historical operating data entries are visually associated and displayed through the graphical interface, which can effectively improve the work efficiency of the operation and maintenance personnel. By displaying and comparing the device operating data in real time, users can intuitively understand the operating status of the device and discover potential faults or abnormal fluctuations. In addition, the interactive interface provides extremely high flexibility, and the operation and maintenance personnel can accurately filter the data according to their needs, thereby more efficiently performing fault troubleshooting and performance tuning. This data visualization method greatly improves the convenience and intelligence of device management, helping the operation team to keep track of the status of network devices in real time.

[0074] The present invention relates to the technical field of data processing and can be applied to business scenarios such as fintech and healthcare. It discloses a method, device, equipment and medium for processing operation data of network devices, including: collecting operation parameter data of network devices from multiple different sources through a standardized data collection middleware and converting it into a unified data format, classifying and storing the converted operation parameter data as historical operation data entries based on a preset metadata mapping relationship, displaying the historical operation data entries through a graphical interface and generating an operation time series change curve based on these data, receiving a time range selection instruction and determining target operation parameter data from the historical operation data entries according to this instruction, and visually associating and displaying the target operation parameter data with its corresponding historical operation data entries through a graphical interface. By providing a unified data collection and storage framework, the present invention standardizes the historical data of wireless AP devices of different brands, solves the problems of data compatibility and low analysis efficiency, thereby significantly improving the efficiency and accuracy of network management and supporting unified monitoring and optimization analysis of cross-vendor devices.

[0075] In one embodiment, the above step S10 includes:

[0076] S101, obtaining the original operation parameter data of network devices from different sources through an open network management protocol, where the original operation parameter data includes a device identification code and a corresponding device private parameter identifier;

[0077] S102, establishing a mapping relationship table between the device private parameter identifier and the standard parameter identifier;

[0078] S103, performing data cleaning processing on the original operation parameter data to remove abnormal values and format errors that exceed a preset threshold;

[0079] S104, converting the original operation parameter data after cleaning processing into a standard operation parameter data set with a unified naming strategy and data structure based on the mapping relationship table.

[0080] In this embodiment, collecting operation parameter data of network devices from multiple different sources through a standardized data collection middleware and converting the operation parameter data into a unified data format is the core step to solve the problem of data fragmentation of network devices. Devices of multiple brands and models usually use different private protocols and standards to transmit and store data, which results in inconsistent data formats, naming rules and interfaces, making it difficult to conduct unified monitoring and management.

[0081] The device identification code and the device private parameter identifier are the unique identifiers of each device and the key parts of its specific data. The device identification code can help accurately identify the device, while the private parameter identifier refers to the specific operating parameters defined by each device manufacturer. For example, the "channel interference rate" of a device may have different identifiers in different devices. Adopting a unified device identification code can track and manage these parameters across devices. Communicate with the device by supporting open network management protocols (such as SNMP, NetConf, RESTful API, etc.) to extract the raw data of different devices. The device identification code and the device private parameter identifier are obtained through protocol fields. These raw data include, but are not limited to, performance parameters such as the temperature, flow rate, power, and load of the device.

[0082] Devices from different manufacturers will use different private parameter identifiers in the network management protocol, which leads to compatibility issues between different devices. Therefore, by establishing a mapping table between the device private parameter identifier and the standard parameter identifier, the parameter identifiers of these devices can be unified, enabling the use of a unified naming convention when processing and analyzing data. Preset a mapping table in the system to map the private identifier of each device manufacturer to the parameter name of the unified standard. For example, the "band conflict index" of Huawei devices and the "Channel Utilization" of Cisco devices are mapped to "channel_utilization" through the standard parameter identifier. The establishment of this mapping table can be done through manual configuration or through interaction with the device using an automated tool.

[0083] Data cleaning is a necessary step to ensure data quality and accuracy, especially when there are problems such as data anomalies, inconsistent formats, and missing values among cross-brand devices. Data cleaning includes removing abnormal values that exceed the preset threshold, and values with incorrect formats will be excluded to ensure the validity of the final data. The system will check the device parameters according to the preset reasonable range and remove the data that does not meet the preset threshold. For example, if the value of the temperature parameter exceeds the operating temperature range of the device (such as 50°C to 100°C), it will be marked as abnormal and deleted from the data set. Values with incorrect formats (such as text fields containing illegal characters) will also be excluded.

[0084] Based on the mapping relation table, the original operation parameter data after cleaning is converted into a standard operation parameter data set with a unified naming strategy and data structure. This process ensures that the operation data of all devices can be standardized, transformed into a unified data format, enabling devices from different manufacturers to be represented in the same data structure and supporting further analysis and comparison. The system, according to the previously established mapping relation table, converts the private parameter identifiers of the cleaned devices into unified standard parameter identifiers and stores them according to the unified data structure. The data structure can be in the form of JSON, XML, or a database table, etc., containing fields such as device identification code, timestamp, and standard parameter values.

[0085] In this embodiment, the standardized data acquisition middleware is used to collect the operation parameter data of multiple network devices from different sources and convert it into a unified data format, effectively solving the problems of fragmented device data and incompatible heterogeneous data formats, and greatly improving the compatibility of cross-brand network devices and the data analysis efficiency. By establishing a unified parameter naming specification, data can be seamlessly transferred between devices of different manufacturers and support further data cleaning, analysis, and report generation.

[0086] In one embodiment, the above step S20 includes:

[0087] S201, bind the converted operation parameter data with the device identification code and the acquisition timestamp to generate a basic data unit;

[0088] S202, supplement and expand parameters for the basic data unit according to the preset metadata mapping relation to generate an enhanced data unit;

[0089] S203, encapsulate the enhanced data unit to generate a historical operation data entry containing the device identification code, acquisition timestamp, and extended parameters;

[0090] S204, attach network topology level labels and physical location coordinate metadata to each historical operation data entry;

[0091] S205, allocate the historical operation data entries to the corresponding device-specific storage partitions according to the device identification code;

[0092] S206, perform time range sharding on the historical operation data entries in the storage partition using a distributed time series database to generate multiple shard units.

[0093] In this embodiment, in the cross-vendor management of multi-brand devices, due to the differences in the naming rules and data storage formats of devices from different manufacturers, it is difficult for traditional technologies to conduct unified management and analysis. By classifying and storing the converted operation parameter data according to the preset metadata mapping relation, it is possible to effectively unify the device data format and ensure the manageability and analyzability of the data.

[0094] When classifying and storing the converted operating parameter data, it is first necessary to bind this data to the device identification code and the acquisition timestamp. The device identification code, as the unique identifier of the device, is used to distinguish different devices, and each device will have a unique device identification code. The acquisition timestamp records the exact time when each data point is acquired, usually in a standard time format to ensure the timing of the data. In this process, the generated basic data unit is a complete data unit that includes the device identification code, timestamp, and operating parameter data, which lays the foundation for subsequent data storage and processing.

[0095] After generating the basic data unit, the next operation is to expand it according to the preset metadata mapping relationship. The mapping relationship table defines the standard naming rules and data structures for each device and operating parameter. Therefore, the expansion process is to match the private parameter identifiers of each device with the standardized parameter identifiers, so as to ensure that the parameter data of all devices can be stored in a unified standard. This process generates an enhanced data unit, which contains the expanded data, and such data can be better compared and analyzed with the data of other devices.

[0096] Then, these enhanced data units are encapsulated to generate historical operating data entries that include the device identification code, acquisition timestamp, and standardized extended parameters. The encapsulation operation organizes the data into a structured format and adds more metadata to each data entry. These metadata include network topology level tags and physical location coordinate metadata, which can help better understand the working environment of the device and its position in the network.

[0097] The network topology level tag of the device assigns a specific level or role identifier to each device, indicating the position and function of the device in the entire network. The physical location coordinate metadata provides the position of the device in physical space, usually including information such as the rack number, area, and floor of the device. In this way, the data not only includes the operating status of the device, but also the physical location of the device and its relationship in the network, further enhancing the visualization and analysis value of the data.

[0098] Next, according to the device identification code, these historical operating data entries are assigned to the corresponding device-specific storage partition. This can avoid the mixing of data from different devices and improve the efficiency of data storage and query. Each storage partition corresponds to all the operating data of a specific device, ensuring that the data can be quickly located when accessed.

[0099] Finally, a distributed time-series database is used to store these data in a time-range sharding manner. The sharding operation divides the data into multiple sharding units, each of which contains data within a certain time range, and preserves the continuity of the device identification code and timestamp. Distributed storage can improve the data access efficiency. Especially in the case of large amounts of data that need to be accessed in chronological order, it can effectively reduce the access time and query latency. In this way, while ensuring efficient storage, the integrity and consistency of the data can be ensured.

[0100] In this embodiment, by standardizing and classifying the operation parameter data for storage, the differences between devices of different manufacturers can be effectively eliminated, and a consistent management and analysis framework can be provided. The classified storage of historical operation data entries makes the data management more efficient and reduces the difficulty of manual management. At the same time, through the sharding storage method of the distributed time-series database, the efficient storage and fast query of large-scale device data can be ensured. During the whole process, the operations of data standardization, expansion, encapsulation, and storage enable the device data to be managed not only in the time dimension but also to be analyzed and optimized based on the network topology and physical location, greatly improving the data availability and analysis efficiency.

[0101] In one embodiment, the above step S30 includes:

[0102] S301, according to the device identification code input by the user, extract a set of historical operation data entries containing the acquisition timestamp and the standardized parameter values from the distributed time-series database;

[0103] S302, sort the acquisition timestamps and standardized parameter values in the set of historical operation data entries in the time dimension to generate a curve graph data sequence with a time coordinate axis and a parameter value coordinate axis;

[0104] S303, map the curve graph data sequence to an interactive time-series change curve in the graphical interface to generate a running time-series change curve graph;

[0105] S304, based on the physical location coordinate metadata stored in the historical operation data entries, overlay a device location heat map on the running time-series change curve graph.

[0106] In this embodiment, the management system needs to uniformly monitor and analyze the devices of multiple brands. However, the differences in the operation data formats of devices from different manufacturers and the large number of devices make data query, management, and analysis extremely complex. To overcome these challenges, device data from multiple different sources can be integrated into a unified display format and the device status can be presented in the form of a time-series change curve to help network administrators monitor and optimize the devices in real time.

[0107] First, according to the device identification code input by the user, a set of historical operation data entries containing the acquisition timestamp and standardized parameter values is extracted from the distributed time-series database. The device identification code is used to uniquely identify each device, and the acquisition timestamp is the timestamp of each data acquisition, ensuring that the data is arranged in chronological order. These historical operation data entries are stored in the database in a standardized data format, ensuring the unity of data across different brands of devices. In actual implementation, the device identification code can be obtained through the device management system or the device API interface, and the set of historical operation data entries is obtained through the query function of the distributed time-series database. This process retrieves the historical data of the device based on the device identification code.

[0108] Next, the system sorts the acquisition timestamps and standardized parameter values in the set of historical operation data entries by time dimension to generate a curve graph data sequence with a time axis and a parameter value axis. The sorting operation ensures that the device data is arranged in chronological order, and the generated curve graph data sequence can reflect the operating status of the device at different time points. The time axis represents the acquisition time, and the parameter value axis corresponds to the performance or operating status data of the device (such as signal strength, load, etc.). The data sorting and graph generation are mapped according to the timestamp and parameter value, and the generated sequence is convenient for visualization operations and subsequent chart generation.

[0109] In the display of the graphical interface, these sorted curve graph data sequences are mapped into an interactive time-series change curve graph. Users can perform interactive operations on the data through the graphical interface, such as zooming in, zooming out, and viewing the operating status of the device in a specific time period. This interactive time-series curve graph helps users not only view the changes in the device status during operation but also perform flexible data analysis, facilitating real-time monitoring of the change trend of device operation and quickly discovering anomalies or potential problems.

[0110] Based on the generated time-series change curve graph, the system also overlays a device location heat map on the running time-series change curve graph based on the physical location coordinate metadata stored in the historical operation data entries. This function is achieved by overlaying the physical location coordinate metadata of the device (such as information about the rack, floor, area where the device is located, etc.) on the time-series change curve. In this way, the administrator can intuitively see the relationship between the location information of the device and its operating status, helping to analyze whether the performance and faults of the device are related to its physical location. For example, devices in a certain area may frequently experience performance fluctuations due to network interference. Through the display of the heat map, the administrator can clearly identify potential problems in that area.

[0111] Through the above steps in this embodiment, device data is no longer difficult to manage due to brand differences. The unified standardized data format and the generation of real-time time-series change diagrams enable the device status to be intuitively reflected, and flexible querying and analysis can be performed according to the time dimension. By overlaying the device location heat map on the time-series diagram, users can discover the potential correlation between device performance problems and physical locations, improving the efficiency of fault troubleshooting and network optimization. This visual correlation display makes device management more efficient, providing strong data support and decision-making basis for network operation personnel.

[0112] In one embodiment, step S40 above includes:

[0113] S401, parsing the start timestamp and end timestamp in the time range selection instruction to generate an absolute time interval expression;

[0114] S402, constructing a distributed time-series database query condition based on the device identification code and the absolute time interval expression;

[0115] S403, extracting the original operation parameter data set from the corresponding shard unit of the distributed time-series database based on the distributed time-series database query condition;

[0116] S404, performing time alignment processing on the original operation parameter data set to generate a target operation parameter data sequence.

[0117] In this embodiment, in the current device management system, querying and processing historical data are often faced when managing a large number of devices. Especially when there are many types of devices, different manufacturers, and a large amount of data, the system needs to efficiently and accurately screen out the target device parameter data within a specified time period from the massive data. To solve this problem, the target operation parameter data can be extracted from the historical operation data entries according to the time range specified by the user, and the whole process is efficiently executed in the distributed time-series database.

[0118] First, after receiving the time range selection instruction, the system will parse the start timestamp and end timestamp in the instruction. These timestamps define the time range that the user hopes to view, usually in the ISO 8601 format (such as from "2023-07-01T00:00:00Z" to "2023-07-01T23:59:59Z"). The purpose of parsing these timestamps is to convert the time range input by the user into a standard time interval expression that can be processed by the machine, ensuring the accuracy of the query condition. Specifically, this parsing process will extract two key data - the start timestamp and the end timestamp - from the instruction and form a valid time interval. This can ensure that subsequent query operations only cover the time range required by the user.

[0119] Next, the system constructs a distributed time-series database query condition based on the device identification code and the generated time interval expression. The device identification code is the unique identifier of each device. Through the device identification code, the system can accurately locate the relevant information of the target device in the large-scale device data. At the same time, the generated time interval expression determines the time range of data query, which can limit the query condition and only retrieve data from the specified time range. These query conditions will include the hash value of the device identification code and the corresponding time-series shard interval identifier, so as to achieve efficient shard query. Since time-series data is usually stored in shards according to time, using the time-series shard interval identifier can help the system accurately and quickly locate the relevant shards and improve the query efficiency.

[0120] Then, the system extracts the original operating parameter data set from the corresponding shard unit of the distributed time-series database based on these query conditions. Due to the large amount of data, the method of storing in a distributed time-series database can ensure that the system can effectively store and query data at different devices and different time periods. In a distributed time-series database, data is usually stored in shards, and each shard stores the device data for a certain time period. The system can locate the corresponding shard unit according to the previously constructed query conditions and extract all the original operating parameter data of the target device within the specified time range from it. The data set includes various operating parameters of the device (such as load, bandwidth, signal strength, etc.) and timestamp information.

[0121] Finally, the system performs time alignment processing on the extracted original operating parameter data set to ensure the continuity and time-series consistency of the data. Since the device may be offline, missing, or out of sync during data collection, time alignment processing is necessary. It can ensure that the device data is arranged in time series and fill in the missing data points (such as through interpolation or filling methods). After time alignment processing, the system finally generates the target operating parameter data sequence, which includes the timestamp and the associated data of various device parameters, and finally returns to the user in a standardized format.

[0122] In this embodiment, through standardized query conditions and time alignment processing, the target operating parameter data is effectively extracted from the massive device historical data. By using the device identification code and the time interval expression, the system can accurately and efficiently locate and extract the required data from the distributed time-series database, ensuring the accuracy of data query. Time alignment processing further improves the accuracy and integrity of the data. Especially when dealing with problems such as device offline and data missing, it ensures the data continuity, thus providing reliable data support for device management and fault troubleshooting.

[0123] In one embodiment, the above step S50 includes:

[0124] S501. Extract a set of associated historical operation data entries from the distributed time-series database according to the device identification code and time-stamp range in the target operation parameter data.

[0125] S502. Align the time-stamp and parameter values of the target operation parameter data with the historical parameter values of the same device identification code in the set of associated historical operation data entries to generate a device-level time-series comparison data sequence.

[0126] S503. In the main view area of the graphical interface, map the difference value between the target parameter value and the historical parameter value in the device-level time-series comparison data sequence to a dynamic difference curve.

[0127] S504. In the topology view area of the graphical interface, convert the average difference value of the device-level time-series comparison data sequence into a heat color scale value according to the physical location coordinate metadata associated with the device identification code to generate a difference heat distribution map.

[0128] S505. In response to the user's intercept operation on the time-axis controller, update the time window range of the dynamic difference curve in the main view area and adjust the heat color scale mapping strategy in the topology view area.

[0129] In this embodiment, in a modern device management system, with the increase in the types of devices and the complexity of the operating environment, cross-device data comparison and monitoring become increasingly difficult. Especially when the amount and types of device operation data are huge, how to efficiently and intuitively display the historical operation status and differences of devices becomes a key technical requirement. Displaying the comparison between the target operation parameter data and the historical operation data entries in a visual way not only improves the management efficiency but also helps engineers timely discover potential device failures or operation deviations. Displaying device operation data through a graphical interface and generating a dynamic difference curve and a heat distribution map in combination with historical data can provide a clear and intuitive view of the device health status.

[0130] First, the system extracts a set of associated historical operation data entries from the distributed time-series database according to the device identification code and time-stamp range input by the user. The user inputs the device identification code (uniquely identifying each device) and the query time range (such as "from July 1, 2023, to July 31, 2023") on the graphical interface. The device identification code helps the system accurately locate the target device, and the time-stamp range limits the time period for data query. These information are used as query conditions, and the system filters out the historical operation data that meet the conditions in the distributed time-series database to ensure the relevance and accuracy of the data. For a large-scale device management system, the distributed time-series database can ensure the efficiency of data storage and query. The historical operation data entries returned by the query contain various operation parameters of the device and their corresponding time-stamps, forming a historical data set.

[0131] Next, the system aligns the target operating parameter data and the set of historical operating data entries along the time axis. The target operating parameter data usually contains device operating parameters at multiple moments (such as signal strength, working status, bandwidth, etc.), and the timestamps of these data must be precisely aligned with the timestamps of the historical operating data entries. Through time alignment processing, the system ensures that the target parameter values and the historical parameter values can be compared on the same time axis. Specifically, the system will look for corresponding timestamps in the target data and the historical data. If there are cases where the timestamps do not exactly match, the system will perform alignment processing through methods such as interpolation as needed. The key to this step is to generate a time-series comparison data sequence at the device level, which shows the differences between the target parameter values and the historical parameter values, facilitating further difference analysis and visual display.

[0132] In the main view area of the graphical interface, the system maps the difference values in the device-level time-series comparison data sequence to a dynamic difference curve. The difference curve shows the fluctuations in time of the target parameter values and the historical parameter values, intuitively presenting the abnormal fluctuations of the device within the specified time range. For example, if the working status of a certain device changes drastically within a certain period of time, the difference curve can clearly reflect this change. To enhance the visualization effect, the color depth of the curve can be proportional to the magnitude of the difference value. The greater the difference, the darker the curve color, thus helping users quickly identify abnormal fluctuations.

[0133] In the topology view area of the graphical interface, based on the physical location coordinate metadata associated with the device identification code, the system converts the average difference value of the device-level time-series comparison data sequence into a heat color scale value and generates a difference heat distribution map. By superimposing the heat map in the topology view, users can intuitively see the performance differences of devices in physical space. For example, if multiple devices experience failures or performance anomalies within the same time period, the heat map can highlight the locations of these devices on the map, helping operation and maintenance personnel quickly locate the problem devices. The intensity of the heat color scale is related to the magnitude of the difference value. The greater the difference value, the darker the color of the heat map, further improving the efficiency of fault detection.

[0134] Finally, when the user selects a new time range through the time axis controller's intercept operation, the system will update the dynamic difference curve in the main view area and adjust the heat color scale mapping strategy in the topology view area. This operation realizes the dynamic update of the data. Without reloading the entire dataset, users can flexibly select different time periods for comparison and analysis. The system will automatically adjust the display content of the difference curve according to the new time range selected by the user, and at the same time update the color scale mapping rule of the heat map to ensure that the color mapping is consistent with the parameter differences within the current time window.

[0135] Through the above steps, this embodiment can effectively solve the problem of difficult comparison of device operation data in different time periods. Especially in the large-scale device management environment, it helps users quickly discover anomalies in the device operation status. By aligning the target operation parameters with historical data in terms of time and calculating the differences, users can intuitively view the time-series change curves of the devices and timely discover the performance problems of the devices. At the same time, with the help of the difference heat map in the topology view, users can accurately locate the devices with anomalies and their locations, improving the efficiency of device management and the speed of fault handling.

[0136] In one embodiment, after the above step S30, the following steps are further included:

[0137] S305, detecting the parameter change rate between adjacent time points in the operation time-series change curve, and when the change rate exceeds the preset fluctuation threshold range, determining it as an abnormal fluctuation event;

[0138] S306, on the time-series change curve of the graphical interface, covering the time interval corresponding to the abnormal fluctuation event with a highlighted color block, and embedding a dynamically flashing warning identifier within the highlighted color block;

[0139] S307, encapsulating the time stamp, device identification code, parameter type, and the fluctuation value exceeding the threshold of the abnormal fluctuation event into a structured warning log file;

[0140] S308, retrieving the device configuration snapshot library according to the device identification code, and associating and storing the warning log with the complete device configuration information at the moment of the anomaly in the audit database;

[0141] S309, when multiple network devices at the same network topology level trigger abnormal fluctuations in the same time period, marking the abnormal time intervals of the associated network devices with highlighted color blocks in the graphical interface, and generating a topology-level warning event.

[0142] In this embodiment, in the management system of network devices, the stability and health status of device operation are key issues that need to be continuously monitored. During the operation of the device, it may experience some performance fluctuations. Especially in a multi-device environment, how to efficiently detect and quickly respond to abnormal fluctuations has become the core requirement for improving network management efficiency and reducing fault downtime. By performing operations such as time-series change detection, abnormal fluctuation event marking, and warning log generation on the device operation parameter data through the graphical interface, the real-time monitoring and timely warning of the device health status are ensured.

[0143] First, the system detects the operation timing change curve of the device. After the system displays the operation timing change curve of the device, the next step is to analyze the parameter change rate between adjacent time points. Specifically, the system calculates the difference in parameter values between each time point of the target device and the previous time point, and then obtains the change rate. If the change rate exceeds the preset fluctuation threshold range, the system determines it as an abnormal fluctuation event. This fluctuation threshold range is set according to the working state of the device. For example, for the change in signal strength, if its change rate exceeds 10%, it can be considered an abnormal fluctuation. By setting a predefined threshold range, the system can effectively screen out abnormal fluctuations.

[0144] After detecting abnormal fluctuation events, the system covers these abnormal events on the timing change curve of the graphical interface with highlighted color blocks. To make the abnormal fluctuation events easier to identify, the color of the color block is adjusted according to the size of the fluctuation. The larger the fluctuation, the darker the color of the color block. In addition, a dynamically flashing warning identifier is embedded in the color block to help users quickly identify the faulty or abnormal area among a large amount of data. The dynamically flashing identifier further improves the visibility of the system in the face of a large amount of data by adding a visual dynamic effect.

[0145] Next, the system encapsulates the relevant information of the abnormal fluctuation events into a structured alarm log file. This log file includes information such as the timestamp of the event, the device identification code, the type of abnormal parameter, and the fluctuation value exceeding the threshold. This information is stored in a structured manner for subsequent query and analysis to ensure the complete traceability of the event. The structured log can support accurate fault location and abnormal analysis, reducing the time and error probability of manual analysis.

[0146] To solve problems such as device configuration drift, the system retrieves the device configuration snapshot library according to the device identification code. The configuration snapshot library stores the configuration information of the device, including the configuration status of the device when the abnormality occurs. The alarm log is associated with the device configuration snapshot and stored in the audit database for future auditing and analysis. By associating the configuration snapshot with the alarm log, it can help the operation and maintenance personnel trace the configuration status of the device when the problem occurs and find the root cause of the fault.

[0147] Finally, when multiple devices have abnormal fluctuations within the same time period, the system will mark the abnormal time intervals of these devices in the form of highlighted color blocks in the graphical interface and generate topology-level alarm events. This function is especially applicable in a multi-device environment. From the perspective of the network topology, the operation and maintenance personnel can see the correlation and abnormal conditions between different devices. This helps to identify potential fault patterns in the system, especially in the device interactions between network topology levels.

[0148] In actual deployment, the system first receives the device identification code and the monitored time range input by the user through the graphical interface. The system queries the distributed time-series database, retrieves the historical operation data entries of the device from the database, and generates a time-series change curve. The time-series change of the device calculates the change rate based on the actual parameter values and compares it with the preset fluctuation threshold. When an abnormal fluctuation occurs, the system highlights the corresponding period on the graphical interface and converts it into a dynamically flashing alarm identifier. The backend part of the system generates an alarm log, records the detailed information of all abnormal fluctuation events, and associates it with the device configuration snapshot. Finally, all abnormal events are recorded in the audit database for post-event analysis and auditing. When the system discovers that multiple devices have anomalies within the same time period, it not only updates the graphical interfaces of the relevant devices but also, through the topology-level alarm mechanism, associates and displays the abnormal events of multiple devices. The topology-level alarm mechanism helps the operation and maintenance personnel quickly identify potential fault points in the network topology hierarchy and respond in a timely manner.

[0149] Example illustration: In the financial field, bank self-service equipment (such as ATMs) may face various faults or performance fluctuations during daily operation, resulting in service interruptions or poor user experiences. Financial institutions need to monitor the operating status of the equipment in real time, quickly locate and solve problems to ensure the stability and security of the equipment. The bank's ATMs collect the operating parameters of each device (such as device status, transaction volume, number of faults, etc.) through a standardized data acquisition middleware and convert the data into a unified standard format. These data are transmitted to the central monitoring system through open network management protocols (such as SNMP, HTTP interfaces) to ensure that the data of ATMs from different manufacturers can be uniformly managed. Through the device identification code and private parameter identifier, the system integrates all device data to solve the data compatibility problem between multi-brand ATMs. The converted device operating data is bound with the device identification code and the acquisition timestamp to form a basic data unit. Then, based on the preset metadata mapping relationship, relevant parameters (such as device location information, device model, etc.) are supplemented and extended to the device operating data and stored as standardized historical operating data entries. Each entry is attached with a network topology level label and physical location coordinates (such as the specific location or area of the ATM) and stored and managed through a distributed time series database. In this way, even under large-scale device deployments, the efficiency of data management and retrieval can be ensured. The bank displays the historical operating data of all ATMs through a graphical interface and generates the operating time series change curve of each ATM to help operation and maintenance personnel view the performance changes of the device at different time periods. The operation and maintenance personnel can easily extract the set of historical operating data entries of the device from the distributed time series database according to the device identification code input by the user, arrange the timestamp and parameter values in chronological order, and generate a curve data sequence with a time axis and a parameter value axis. In the main view area of the graphical interface, the difference value between the time series curve of the ATM and the historical parameter value is mapped as a dynamic difference curve to help operation and maintenance personnel intuitively understand the operating fluctuations of the device. When the operating parameters of the ATM change beyond the preset fluctuation threshold, the system will automatically detect and mark the abnormal fluctuation event. For example, when the transaction volume or the number of faults of a certain ATM fluctuates abnormally, the system will cover and display these abnormal fluctuations on the time series change curve by highlighting color blocks, and embed a dynamic flashing alarm identifier in the color block. The alarm identifier provides clear visual feedback to help operation and maintenance personnel quickly identify and locate the problem device. After detecting an abnormal fluctuation event, the system encapsulates the detailed information of the abnormal fluctuation event (such as timestamp, device identification code, abnormal parameter value, etc.) into a structured alarm log file and records it in the audit database. The alarm log is associated and stored with the complete device configuration information at the moment of the abnormality. By querying the device configuration snapshot library, operation and maintenance personnel can view the device configuration information and historical configuration status of the ATM to help analyze whether there is configuration drift or device failure.If multiple ATMs at the same network topology level trigger abnormal fluctuations within the same time period, the system will mark the abnormal time intervals of multiple devices with highlighted color blocks in the graphical interface, forming a topology-level alarm event. This helps the operation and maintenance personnel quickly identify potential associated faults among multiple devices and take prompt actions to repair the devices in the entire network.

[0150] In the field of healthcare, devices in hospitals (such as electrocardiographs, blood glucose meters, X-ray machines, etc.) need to operate stably for a long time to provide reliable health monitoring and diagnostic services for patients. The maintenance and management of medical devices are crucial, as any abnormal fluctuations may affect the diagnostic results or treatment effects of patients. Various medical devices in hospitals collect the operating parameters of the devices (such as device status, maintenance records, operating hours, etc.) through a standardized data acquisition middleware and convert these data into a unified data format. Through open network management protocols (such as SNMP, HTTP interfaces, etc.), the operating data of the devices are transmitted to the hospital's central management system. These data involve devices from different manufacturers, and there are significant differences in parameter naming (for example, X-ray machines of different brands may use different terms to record image quality). The system uniformly converts these data formats through device identification codes and private parameter identifiers, eliminating compatibility issues between devices. Bind the operating data of the device with the device identification code and the acquisition timestamp, and generate basic data units. The system expands the basic data units according to the preset metadata mapping relationships (such as the model of the device, the location of use, etc.) and stores them as historical operating data entries. Each data entry contains key information such as device identification code, acquisition timestamp, and device parameters, and is appended with device location information and network topology level labels. Through a distributed time series database, the hospital can efficiently store and manage data of a large number of devices, ensuring real-time access and efficient query of the data. The hospital displays the historical operating data of the devices through a graphical interface and generates a time series change curve of the device operation. The operation and maintenance personnel can easily extract the set of historical operating data entries of the device from the distributed time series database according to the device identification code and sort them in chronological order to generate a curve graph. Compare the operating status of the device with the historical operating data entries to generate a device-level time series comparison data sequence with time coordinates and parameter value coordinates. In the main view area of the graphical interface, the operation and maintenance personnel can intuitively see the changes in the device operation time series, helping to detect performance fluctuations of the device in a timely manner. When the operating parameters of the device change beyond the preset fluctuation threshold, the system will automatically detect the abnormal fluctuations and highlight the abnormal fluctuation events in the graphical interface by covering them with colored blocks. The color depth of the colored blocks is proportional to the fluctuation amplitude, helping the operation and maintenance personnel quickly locate the abnormal area. A dynamically flashing alarm identifier will be embedded in the colored block to prompt the operation and maintenance personnel that the device has a fault or an abnormal situation. The system will record the relevant information of the device in the detected abnormal fluctuation events, such as device identification code, abnormal parameter value, timestamp, etc., and encapsulate these information into a structured alarm log file. By retrieving the device configuration snapshot library, the operation and maintenance personnel can view the configuration status of the device at the time of the anomaly and associate the alarm log with the device configuration snapshot and store it in the audit database. In this way, the operation and maintenance personnel can trace back to the configuration history of the device and analyze the root cause of the device failure.When multiple devices experience abnormal fluctuations within the same network topology level during the same time period, the system will mark the abnormal time intervals of these devices with highlighted color blocks to generate topology-level alarm events. Through this information, operation and maintenance personnel can quickly identify associated faults between devices, take effective measures to repair the devices, ensure the stable operation of hospital devices, and avoid the occurrence of cascading failures.

[0151] In this embodiment, through the visualization methods of dynamic difference curves, heat maps, and alarm identifiers, operation and maintenance personnel can quickly locate the problem, and through structured alarm logs and device configuration snapshots, conduct effective fault tracing and resolution. Especially for the detection of abnormal events of multiple devices and across levels, it improves the efficiency and reliability of overall network management.

[0152] In one embodiment, there is provided an operating data processing device for network devices, which corresponds one-to-one with the operating data processing method of network devices in the above embodiment. Refer to Figure 3 , Figure 3 which is a schematic diagram of the functional modules of a preferred embodiment of the operating data processing device for network devices of the present invention. The data acquisition and format conversion module 10, the data storage module 20, the data visualization display module 30, the time range query module 40, and the interactive data association module 50. The detailed description of each functional module is as follows:

[0153] The data acquisition and format conversion module 10 is used to collect the operating parameter data of multiple network devices from different sources through a standardized data acquisition middleware, and convert the operating parameter data into a unified data format;

[0154] The data storage module 20 is used to classify and store the converted operating parameter data as historical operating data entries based on a preset metadata mapping relationship;

[0155] The data visualization display module 30 is used to display the historical operating data entries through a graphical interface and generate an operating time series change curve based on the historical operating data entries;

[0156] The time range query module 40 is used to receive a time range selection instruction, and determine the target operating parameter data within the corresponding time range from the historical operating data entries according to the time range selection instruction;

[0157] The interactive data association module 50 is used to visually associate and display the target operating parameter data with its corresponding historical operating data entry through the graphical interface.

[0158] In one embodiment, the data acquisition and format conversion module 10 is specifically used for:

[0159] Obtain the original operation parameter data of network devices from different sources through the Open Network Management Protocol, where the original operation parameter data includes device identification codes and corresponding device private parameter identifiers;

[0160] Establish a mapping relationship table between the device private parameter identifiers and standard parameter identifiers;

[0161] Perform data cleaning on the original operation parameter data to remove abnormal values and format errors that exceed the preset threshold;

[0162] Based on the mapping relationship table, convert the cleaned original operation parameter data into a standard operation parameter data set with a unified naming strategy and data structure.

[0163] In one embodiment, the data storage module 20 is specifically configured to:

[0164] Bind the converted operation parameter data with the device identification code and the acquisition timestamp to generate a basic data unit;

[0165] Supplement and expand parameters for the basic data unit according to the preset metadata mapping relationship to generate an enhanced data unit;

[0166] Encapsulate the enhanced data unit to generate a historical operation data entry containing the device identification code, acquisition timestamp, and extended parameters;

[0167] Attach network topology level labels and physical location coordinate metadata to each historical operation data entry;

[0168] Allocate historical operation data entries to the corresponding device exclusive storage partition according to the device identification code;

[0169] Use a distributed time series database to perform time range sharding on the historical operation data entries in the storage partition to generate multiple shard units.

[0170] In one embodiment, the data visualization display module 30 is specifically configured to:

[0171] Extract a set of historical operation data entries containing the acquisition timestamp and standardized parameter values from the distributed time series database according to the device identification code input by the user;

[0172] Sort the acquisition timestamps and standardized parameter values in the set of historical operation data entries in the time dimension to generate a curve graph data sequence with a time axis and a parameter value axis;

[0173] Map the curve graph data sequence to an interactive time series change curve in the graphical interface to generate a running time series change curve graph;

[0174] Overlay a device location heat map on the running time series change curve graph based on the physical location coordinate metadata stored in the historical running data entries.

[0175] In one embodiment, the time range query module 40 is specifically configured to:

[0176] Parse the start timestamp and end timestamp in the time range selection instruction to generate an absolute time interval expression;

[0177] Construct a distributed time series database query condition based on the device identification code and the absolute time interval expression;

[0178] Extract the original running parameter data set from the corresponding shard unit of the distributed time series database based on the distributed time series database query condition;

[0179] Perform time alignment processing on the original running parameter data set to generate a target running parameter data sequence.

[0180] In one embodiment, the interactive data association module 50 is specifically configured to:

[0181] Extract a set of associated historical running data entries from the distributed time series database according to the device identification code and time stamp range in the target running parameter data;

[0182] Align the time stamps and parameter values of the target running parameter data with the historical parameter values of the same device identification code in the set of associated historical running data entries on the time axis to generate a device-level time series comparison data sequence;

[0183] In the main view area of the graphical interface, map the difference value between the target parameter value and the historical parameter value in the device-level time series comparison data sequence to a dynamic difference curve;

[0184] In the topology view area of the graphical interface, convert the average difference value of the device-level time series comparison data sequence into a heat color scale value according to the physical location coordinate metadata associated with the device identification code to generate a difference heat distribution map;

[0185] In response to the user's interception operation on the time axis controller, update the time window range of the dynamic difference curve in the main view area and adjust the heat color scale mapping strategy in the topology view area.

[0186] In one embodiment, the data visualization display module 30 is specifically configured to:

[0187] Detect the parameter change rate between adjacent time points in the running time series change curve, and when the change rate exceeds the preset fluctuation threshold range, determine it as an abnormal fluctuation event;

[0188] On the timing change curve of the graphical interface, highlight a color block to cover and display the time interval corresponding to the abnormal fluctuation event, and embed a dynamically flashing warning identifier within the highlighted color block;

[0189] Package the timestamp, device identification code, parameter type, and fluctuation value exceeding the threshold of the abnormal fluctuation event into a structured warning log file;

[0190] Retrieve the device configuration snapshot library according to the device identification code, and associate and store the warning log with the complete device configuration information at the moment of the abnormality in the audit database;

[0191] When multiple network devices at the same network topology level trigger abnormal fluctuations in the same time period, mark the abnormal time intervals of the associated network devices with highlighted color blocks in the graphical interface, and generate topology-level warning events.

[0192] In one embodiment, a computer device is provided. The computer device can be a server, and its internal structure diagram can be as Figure 4 shown. The computer device includes a processor, a memory, a network interface, and a database connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes non-volatile and / or volatile storage media, and internal memory. The non-volatile storage media stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage media. The network interface of the computer device is used to communicate with an external client through a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the server side of a method for processing operation data of network devices.

[0193] In one embodiment, a computer device is provided. The computer device can be a client, and its internal structure diagram can be as Figure 5 shown. The computer device includes a processor, a memory, a network interface, a display screen, and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes non-volatile storage media and internal memory. The non-volatile storage media stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage media. The network interface of the computer device is used to communicate with an external server through a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the client side of a method for processing operation data of network devices

[0194] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are implemented:

[0195] Collect the operation parameter data of multiple network devices from different sources through a standardized data collection middleware, and convert the operation parameter data into a unified data format;

[0196] Based on a preset metadata mapping relationship, classify and store the converted operation parameter data as historical operation data entries;

[0197] Display the historical operation data entries through a graphical interface, and generate an operation time series change curve based on the historical operation data entries;

[0198] Receive a time range selection instruction, and determine the target operation parameter data corresponding to the time range from the historical operation data entries according to the time range selection instruction;

[0199] Visually and associatively display the target operation parameter data and its corresponding historical operation data entries through the graphical interface.

[0200] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0201] Collect the operation parameter data of multiple network devices from different sources through a standardized data collection middleware, and convert the operation parameter data into a unified data format;

[0202] Based on a preset metadata mapping relationship, classify and store the converted operation parameter data as historical operation data entries;

[0203] Display the historical operation data entries through a graphical interface, and generate an operation time series change curve based on the historical operation data entries;

[0204] Receive a time range selection instruction, and determine the target operation parameter data corresponding to the time range from the historical operation data entries according to the time range selection instruction;

[0205] Visually and associatively display the target operation parameter data and its corresponding historical operation data entries through the graphical interface.

[0206] It should be noted that for the functions or steps that can be realized by the above computer-readable storage medium or computer device, reference can be made to the relevant descriptions on the server side and the user side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0207] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above-mentioned embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned various methods. Among them, any reference to a memory, storage, database, or other medium used in the various embodiments provided in this application can include non-volatile and / or volatile memories. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM), etc.

[0208] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the above-mentioned division of each functional unit and module is used as an example. In actual applications, the above-mentioned functions can be allocated to different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above.

[0209] It should be noted that if there are software tools or components of other companies in the embodiments of this application, they are only used for illustrative introduction and do not represent actual use. The above-mentioned embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the various embodiments of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. A method for processing operation data of a network device, characterized in that Including the following steps: Collect the operation parameter data of network devices from multiple different sources through a standardized data collection middleware, and convert the operation parameter data into a unified data format; Based on a preset metadata mapping relationship, classify and store the converted operation parameter data as historical operation data entries; Display the historical operation data entries through a graphical interface, and generate an operation time series change curve based on the historical operation data entries; Receive a time range selection instruction, and determine the target operation parameter data within the corresponding time range from the historical operation data entries according to the time range selection instruction; Visually associate and display the target operation parameter data and its corresponding historical operation data entries through the graphical interface.

2. The method for processing operation data of a network device according to claim 1, wherein Collect the operation parameter data of network devices from multiple different sources through a standardized data collection middleware, and convert the operation parameter data into a unified data format, including: Obtain the original operation parameter data of network devices from different sources through the Open Network Management Protocol, and the original operation parameter data includes a device identification code and a corresponding device private parameter identifier; Establish a mapping relationship table between the device private parameter identifier and the standard parameter identifier; Perform data cleaning processing on the original operation parameter data, and remove abnormal numerical values and format errors that exceed a preset threshold; Based on the mapping relationship table, convert the cleaned original operation parameter data into a standard operation parameter data set with a unified naming strategy and data structure.

3. The method for processing operation data of a network device according to claim 1, wherein Based on a preset metadata mapping relationship, classify and store the converted operation parameter data as historical operation data entries, including: Bind the converted operation parameter data with the device identification code and the collection timestamp to generate a basic data unit; Supplement and expand parameters for the basic data unit according to the preset metadata mapping relationship to generate an enhanced data unit; Encapsulate the enhanced data unit to generate a historical operation data entry including the device identification code, the collection timestamp, and the extended parameters; Attach a network topology level label and physical location coordinate metadata to each historical operation data entry; Allocate the historical operation data entries to the corresponding device exclusive storage partitions according to the device identification code; Use a distributed time series database to perform time range sharding on the historical operation data entries in the storage partition to generate multiple shard units.

4. The method for processing operation data of a network device according to claim 1, wherein Display the historical operation data entries through a graphical interface, and generate an operation time series change curve based on the historical operation data entries, including: Extract a set of historical operation data entries including the collection timestamp and the standardized parameter values from the distributed time series database according to the device identification code input by the user; Sort the collection timestamps and the standardized parameter values in the set of historical operation data entries in the time dimension to generate a curve graph data sequence with a time axis and a parameter value axis; Map the curve graph data sequence into an interactive time series change curve in the graphical interface to generate an operation time series change curve graph; Overlay a device location heat map on the operation time series change curve graph based on the physical location coordinate metadata stored in the historical operation data entries.

5. The method for processing operation data of a network device according to claim 1, wherein Receive a time range selection instruction, and determine the target operation parameter data corresponding to the time range from the historical operation data entries according to the time range selection instruction, including: Parse the start timestamp and end timestamp in the time range selection instruction to generate an absolute time interval expression; Construct a distributed time series database query condition based on the device identification code and the absolute time interval expression; Extract the original operation parameter data set from the corresponding shard unit of the distributed time series database based on the distributed time series database query condition; Perform time alignment processing on the original operation parameter data set to generate a target operation parameter data sequence.

6. The method for processing operation data of a network device according to claim 1, characterized in that Visually associate and display the target operation parameter data with its corresponding historical operation data entry through the graphical interface, including: Extract the associated historical operation data entry set from the distributed time series database according to the device identification code and timestamp range in the target operation parameter data; Align the timestamps and parameter values of the target operation parameter data with the historical parameter values of the same device identification code in the associated historical operation data entry set along the time axis to generate a device-level time series comparison data sequence; In the main view area of the graphical interface, map the difference value between the target parameter value and the historical parameter value in the device-level time series comparison data sequence to a dynamic difference curve; In the topology view area of the graphical interface, convert the average difference value of the device-level time series comparison data sequence into a heat color scale value according to the physical location coordinate metadata associated with the device identification code to generate a difference heat distribution map; In response to the user's intercept operation on the time axis controller, update the time window range of the dynamic difference curve in the main view area and adjust the heat color scale mapping strategy in the topology view area.

7. The method for processing operation data of a network device according to claim 1, characterized in that After displaying the historical operation data entry through the graphical interface and generating an operation time series change curve based on the historical operation data entry, it further includes: Detect the parameter change rate between adjacent time points in the operation time series change curve, and when the change rate exceeds the preset fluctuation threshold range, determine it as an abnormal fluctuation event; On the time series change curve of the graphical interface, cover the time interval corresponding to the abnormal fluctuation event with a highlighted color block and embed a dynamically flashing alarm identifier in the highlighted color block; Package the timestamp, device identification code, parameter type, and fluctuation value exceeding the threshold of the abnormal fluctuation event into a structured alarm log file; Retrieve the device configuration snapshot library according to the device identification code, and associate and store the alarm log with the complete device configuration information at the moment of the anomaly in the audit database; When multiple network devices at the same network topology level trigger abnormal fluctuations in the same time period, mark the abnormal time intervals of the associated network devices with highlighted color blocks in the graphical interface and generate a topology-level alarm event.

8. An operating data processing device for a network device, characterized in that, The operation data processing device of the network device includes: A data collection and format conversion module, which is used to collect the operation parameter data of multiple network devices from different sources through a standardized data collection middleware and convert the operation parameter data into a unified data format; A data storage module, configured to classify and store the converted operation parameter data as historical operation data entries based on a preset metadata mapping relationship; A data visualization display module, configured to display the historical operation data entries through a graphical interface and generate an operation time series change curve based on the historical operation data entries; A time range query module, configured to receive a time range selection instruction and determine target operation parameter data corresponding to a corresponding time range from the historical operation data entries according to the time range selection instruction; An interactive data association module, configured to visually associate and display the target operation parameter data with its corresponding historical operation data entry through the graphical interface.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and an operation data processing program of a network device that is stored on the memory and can run on the processor. When the operation data processing program of the network device is executed by the processor, the steps of the operation data processing method of the network device according to any one of claims 1-7 are implemented.

10. A computer-readable storage medium, characterized in that, An operation data processing program of a network device is stored on the storage medium. When the operation data processing program of the network device is executed by a processor, the steps of the operation data processing method of the network device according to any one of claims 1-7 are implemented.

Images