An extensible intelligent operation and maintenance monitoring switch performance parameter method

Abstract

A scalable intelligent operation and maintenance method for monitoring switch performance parameters, belonging to the technical field of intelligent operation and maintenance, involves determining whether the switch plugin's configuration file is being used for the first time. If so, it reads the switch's basic information summary table, converts the detailed switch information into readable information, and stores it in a database. It then determines whether each performance parameter OID in the detailed switch information belongs to either quick query or normal query data. Two independent threads are used to query these two types of performance parameter data respectively, and the query results are written to the database and provided to the front-end software for querying and display. Through these three steps, the monitoring of switch performance parameters is achieved. This invention solves the dependence of traditional intelligent operation and maintenance monitoring of switch performance parameters on third-party paid tools, increasing scalability and flexibility.

Description

Technical Field

[0001] This invention relates to the technical field of intelligent operation and maintenance, and in particular to a scalable intelligent operation and maintenance method for monitoring switch performance parameters. Background Technology

[0002] Traditional methods for intelligent O&M monitoring of switch performance parameters involve purchasing third-party paid monitoring tools such as EISGHT, SolarWinds, PRTG, and ManageEngine OpManager, and developing an interface to interact with these tools. If the third-party tools change, the interface must be redeveloped, lacking flexibility. Other intelligent O&M methods for monitoring switch performance parameters focus on the algorithms used to monitor these parameters, and have limitations in supporting monitoring large numbers of switches and in terms of scalability.

[0003] Taking patent publication number CN106330555, "A Method for Measuring OpenFlow Switch Performance Parameters Based on KPLS Algorithm", as an example, it focuses on the algorithm for measuring switch performance parameters. The content is unrelated to intelligent operation and maintenance, and does not involve the monitoring method and scalability of performance parameters of a large number of switches. Summary of the Invention

[0004] In view of the problems of existing technologies that rely on third-party billing tools and lack flexibility in development based on billing tools, this invention provides a scalable intelligent operation and maintenance method for monitoring switch performance parameters, which solves the defects of relying on third-party billing tools and realizes the goal of intelligent operation and maintenance to independently develop flexible monitoring of switch performance parameters.

[0005] The technical solution adopted in this invention is: a scalable intelligent operation and maintenance monitoring method for switch performance parameters, using a server or PC as the carrier and Windows or Linux as the operating system, to read and save the performance parameters of multiple switches. The specific steps are as follows: First, determine whether the switch plugin configuration file is being run for the first time. If it is, the basic information summary table of the switches needs to be read. Based on the IP addresses of each switch in the basic information summary table, the system polls to query detailed information for each switch, converts the detailed information into readable information, and stores it in the database. If it is not, proceed directly to the second step.

[0006] The second step is to read the switch details stored in the database in the first step, write them into the plugin memory, determine whether each performance parameter OID in the switch details belongs to the two types of performance parameter data, fast query and normal query, query the data of these two types of performance parameters through two independent threads, write the query results into the database, and provide them to the front-end software for querying and display.

[0007] The third step involves the switch plugin receiving and processing the TRAP information sent by the switch in real time. TRAP is an active notification mechanism based on the SNMP protocol, used by the switch to actively send real-time messages when it detects a fault, status change, or anomaly. The switch plugin compares the TRAP information sent by the switch with the detailed switch information written into the plugin's memory in the second step, generates corresponding performance parameter data or alarm information, writes it to the database, and provides it to the front-end software for querying and display. When generating alarm information, it needs to be reported to the front-end software in real time.

[0008] By following the three steps above, the performance parameters of the switch can be monitored.

[0009] The first step involves a summary table of basic switch information, including the switch's IP address, model information, performance parameters to be monitored, performance monitoring OID, whether the performance parameters are those that can be quickly queried, and the unit of the performance parameters; and detailed switch information, including switch information, switch board information, and switch port information.

[0010] (1) Switch information includes the switch's IP address, model information, and switch performance monitoring OID;

[0011] (2) Switch board information includes the number of boards, board model, board name, board logical number, board physical number and board performance monitoring OID;

[0012] (3) Switch port information includes the number of ports, port type, port name, port logical number, port physical number, port performance monitoring OID and port TRAP information.

[0013] The method for querying detailed information of each switch in the first step is as follows: use the WALK or GETBULK operation of the SNMP protocol to query the switch. The query fields include interface index, interface description, and interface type. After the switch returns the query results, the switch plugin converts the switch details into readable information. According to the type of detailed information returned by the switch, the port information is converted into port information containing the number of ports, port type, port name, port logical number, and port physical number. The board information is converted into board information containing the number of boards, board model, board name, board logical number, and board physical number.

[0014] The second step describes a method for querying these two types of performance parameters using two independent threads: using the SNMP protocol to send a GET request to the switch to query the performance parameters of multiple boards and ports at once, with the number of performance parameters queried at one time ranging from 50 to 70.

[0015] The second step involves determining whether each performance parameter OID in the switch's detailed information belongs to either the quick query or normal query performance parameter data. This is achieved using two independent threads to query these two types of performance parameters. The switch's performance parameters are categorized into normal performance parameters and quick query performance parameters based on user needs. Normal performance parameters are those that do not affect the normal operation of the switch and are for user viewing. The process for determining the normal performance parameters of the switch thread is as follows: Periodically check if the initialization flag is SUCCESS. If yes, it indicates that the software initialization process has ended normally. If not, return to the idle state and wait for the next cycle to continue checking if the initialization process has ended normally. Read the current switch number index to obtain the current switch's IP address and its normal performance parameters. Send an SNMP GET query operation and obtain the SNMP GET return result, i.e., the performance parameter value. Increment the switch number index by 1 to point to the next switch. Check if the switch number index is greater than or equal to the total number of switches. If yes, set the switch number index to 0, indicating that the query for the normal performance parameters of all switches will restart. After a 3-second sleep period, return to the idle state and wait for the next cycle to query the switch corresponding to the new switch number index.

[0016] For fast performance parameter lookup, each query should be performed using the maximum number of OIDs, denoted as MAX_OID_COUNT. A larger number indicates more performance parameters queried in a single query, resulting in faster query speeds. MAX_OID_COUNT is a configurable parameter, configured according to actual conditions. The process for determining the switch's fast performance parameter lookup thread is as follows: Periodically check if the initialization flag is SUCCESS. If yes, it indicates the software initialization process has completed normally; otherwise, return to idle state and wait for the next cycle to check if the initialization process has completed normally. Read the current switch ID index to obtain the current switch's IP address and the switch's fast performance parameter lookup information. Determine if the total number of fast performance parameter lookup results exceeds MAX_OID_COUNT. If yes, send an SNMP GET query to obtain SNMP data. The GET request returns the result, i.e., the performance parameter value; if not, it continues to retrieve the OID of the quick query performance parameter that needs to be queried locally; the switch number index is incremented by 1 to point to the next switch; it is checked whether the switch number index is greater than or equal to the total number of switches; if so, the switch number index is set to 0, indicating that the query of the general performance parameters of all switches will start again; after a 3-second sleep time, it returns to the idle state and waits for the next cycle to query the switch corresponding to the new switch number index.

[0017] The method described in step three for the switch plugin to compare the TRAP information sent by the switch with the switch details written into the plugin's memory in step two is as follows: When an SNMP message is received, the PDU type is identified as 7, indicating that this is a TRAP message. The variable binding list in the TRAP message is parsed. It is a sequence containing multiple "variable name-value" pairs. Each "variable name-value" pair is also a sequence containing an OID and a Value. The OID serves as a unique identifier for the object, indicating what the variable is, and the Value is the value of the object at the current moment. The OID in the TRAP information is compared with the OID in the switch details read into the plugin's memory in step two. After finding the corresponding OID, the Value corresponding to the OID in the TRAP information is updated to the database. If the OID corresponds to a user-requested alarm, the corresponding alarm is generated, sent to the front-end software via HTTP POST for alarm display, and the alarm information is written to the database.

[0018] The method for providing query and display services to the front-end software in the third step is as follows: The front-end software interacts with the switch plugin via HTTP requests GET and POST. The switch plugin processes the request, performs database operations, and then returns the data to the front-end in JSON format. The front-end software sends an HTTP request to the switch plugin. Upon receiving the request, the switch plugin executes the corresponding business logic based on the request URL and parameters, connects to the database, executes an SQL query, converts the query results into JSON format, and returns them to the front-end software via an HTTP response. Upon receiving the response, the front-end software parses the data and updates the page, allowing users to view the switch's performance parameters and query switch alarm information.

[0019] The technical advantages of this invention are: it solves the dependence of traditional intelligent operation and maintenance (O&M) monitoring of switch performance parameters on third-party paid tools, increasing scalability and flexibility. Traditional methods for monitoring switch performance parameters in intelligent O&M involve purchasing third-party paid monitoring tools such as EISGHT, SolarWinds, PRTG, and ManageEngine OpManager, and developing interfaces to interact with these tools. If the third-party tools change, the interaction interface must be redeveloped, lacking flexibility. Other methods for monitoring switch performance parameters in intelligent O&M focus on the algorithms for monitoring switch performance parameters, and have shortcomings in supporting monitoring methods for large numbers of switches and in supporting scalability.

[0020] In contrast, this invention enables flexible and automated monitoring of performance parameters for a large number of switches. It not only collects key metrics such as CPU, memory, and port traffic in real time, but also allows users to easily add, modify, or delete performance metrics to be monitored through an interface or configuration file. Furthermore, it allows users to easily add extended switches or switch cards through a basic switch information summary table or interface. Attached Figure Description

[0021] Figure 1 To implement the intelligent operation and maintenance monitoring switch performance parameter initialization process of this invention;

[0022] Figure 2 To realize the design of local data structures related to the intelligent operation and maintenance switch monitoring of this invention;

[0023] Figure 3 To implement the operation flow of the thread for intelligent operation and maintenance monitoring of ordinary performance parameters of switches in this invention;

[0024] Figure 4 To realize the operation flow of the thread for quickly querying performance parameters of the intelligent operation and maintenance monitoring switch in this invention;

[0025] Figure 5 The diagram illustrates the business components of the software used in the intelligent operation and maintenance system. Detailed Implementation

[0026] like Figure 1 The diagram illustrates the initialization process for intelligent operation and maintenance monitoring of switch performance parameters. After startup, the software reads switch information and performance parameter codes from the database, constructs a local data structure, and then enters an idle state. In this idle state, it periodically checks whether it has permission to query switch performance parameters, such as whether it is currently in the primary server environment or whether login authentication is required. If it has permission, it performs SNMP initialization, including configuring the SNMP version and reading / writing community words. If it does not have permission, it returns to the idle state and waits for the next cycle to re-evaluate. It then checks if the SNMP configuration was successful. If successful, it sets the initialization configuration flag to SUCCESS and ends the initialization process. If the SNMP configuration fails, it returns to the idle state and restarts the process of checking for permission to read switch performance parameters.

[0027] like Figure 2 The diagram shows the local switch information data structure design for the intelligent operation and maintenance switch. It includes the name, device code, model, manufacturer, subsystem code, IP address, portIndex, device-level OID list, board-level OID list, and port-level OID list. The portIndex records which port information is currently being queried for this switch.

[0028] The device-level OID list includes all performance names and performance OIDs; the board-level OID list includes the slot number, internal number, and board performance list, with the board performance list including performance names and performance OIDs; the port-level OID list includes the physical number, logical number, display number, slot number, internal number, and port performance list, with the port performance list including performance names and performance OIDs.

[0029] like Figure 3The diagram illustrates the workflow of the intelligent operation and maintenance monitoring thread for common switch performance parameters. Switch performance parameters are categorized into common performance parameters and quick-query performance parameters based on user needs. Quick-query performance parameters are those that users require timely monitoring, such as memory usage and temperature; these are parameters whose abnormal values ​​would affect the normal operation of the switch. Common performance parameters, on the other hand, do not affect the normal operation of the switch and are for user viewing. The workflow for the common switch performance parameter monitoring thread is as follows: Periodically check if the initialization flag is SUCCESS. If it is, it indicates that the initialization process of the software has ended normally; otherwise, return to the idle state and wait for the next period to check if the initialization process has ended normally. Read the current switch number index to obtain the current switch's IP address and common performance parameters. Send an SNMP GET query operation and obtain the SNMP GET return result, i.e., the performance parameter value. Increment the switch number index by 1 to point to the next switch. Check if the switch number index is greater than or equal to the total number of switches. If it is, set the switch number index to 0, indicating that the query for common performance parameters of all switches will restart. After a 3-second sleep period, it returns to idle state and waits for the next cycle to query the switch corresponding to the new switch number index.

[0030] like Figure 4 As shown, this describes the operation of the intelligent operation and maintenance monitoring switch's fast performance parameter query thread. For performance parameters requiring fast querying, each query needs to be performed using the maximum number of OIDs, denoted as MAX_OID_COUNT. The larger the number, the more performance parameters are queried in a single query, resulting in faster query speeds. It is recommended to set MAX_OID_COUNT as a configurable parameter, configured according to actual conditions. The process of determining the fast performance parameter query thread is as follows: Periodically check if the initialization flag is SUCCESS. If it is, it indicates that the initialization process of the software has ended normally; otherwise, return to the idle state and wait for the next period to continue checking if the initialization process has ended normally. Read the current switch number index to obtain the current switch's IP address and the fast performance parameter query data for that switch. Determine if the total number of fast performance parameter queries exceeds MAX_OID_COUNT. If it is, send an SNMP GET query operation and obtain the SNMP GET return result, i.e., obtain the performance parameter value; otherwise, continue to obtain the local fast performance parameter OIDs that need to be queried. Increment the switch number index by 1 to point to the next switch. Check if the switch number index is greater than or equal to the total number of switches. If it is, set the switch number index to 0, indicating that the query for the general performance parameters of all switches will start again. After a 3-second sleep period, return to the idle state and wait for the next cycle to query the switch corresponding to the new switch number index.

[0031] like Figure 5 The diagram shows the business composition of the software of this invention applied in an intelligent operation and maintenance system. The intelligent operation and maintenance system monitors switch performance parameters and stores the acquired data in a database. The expert rule module, alarm management module, and performance data management module in the intelligent operation and maintenance backend process this data. The expert rule module determines whether the performance data does not meet the performance indicator requirements of the expert rules. If not, it notifies the alarm management module to automatically generate an alarm and proactively send it to the intelligent operation and maintenance frontend. The alarm management module also manages alarms corresponding to performance parameters, including confirmation and manual clearing. The performance data management module supports responding to performance data display requests sent from the intelligent operation and maintenance frontend. When performance data that did not meet the expert rules becomes compliant, the expert rule module notifies the alarm management module to automatically restore the corresponding alarm. In the entire intelligent operation and maintenance architecture, the switch performance data monitoring plugin realizes periodic monitoring and real-time updates of switch data, monitors network stability and reliability, and ensures smooth service.

[0032] Example 1 illustrates the practical application of this method in a real-world project, using the intelligent operation and maintenance (O&M) monitoring of switch performance parameters on a subway line in a certain city as an example. This line provides IP and model information for all switches, requiring intelligent O&M monitoring of nearly 200 switches, including monitoring important information such as temperature, memory usage, hard disk usage, port status, and port packet loss. To meet user requirements, the method described in this invention was used to implement intelligent O&M monitoring of switch performance parameters. The specific steps are as follows: First, determine if the switch plugin's configuration file indicates that it is the first time running the switch plugin. If it is the first time running, the switch's basic information summary table needs to be read. This basic information summary table is provided by the subway switch supplier and includes the switch's IP address, model information, performance parameters to be monitored, whether the performance parameters are quick-query parameters, and the unit of the performance parameters. From a practical application perspective, the switch supplier cannot provide information that is completely consistent with the on-site switch installation information because modern switches support multiple plug-and-play slots. The actual installed slot locations cannot be 100% consistent with the information provided by the supplier, requiring software to obtain detailed switch information. The switch is queried using the SNMP protocol's WALK or GETBULK operation. After the switch returns detailed query results, the switch plugin converts the switch details into readable information. Based on the type of detailed information returned by the switch, port information is converted to include the number of ports, port type, port name, port logical number, and port physical number. Board information is converted to include the number of boards, board model, board name, board logical number, and board physical number. The detailed switch information can be obtained by querying the OID corresponding to the detailed switch information, as shown in Table 1 below.

[0033] Table 1. Switch Details and Corresponding OIDs

[0034]

[0035] As shown in Table 1, the OID value of the physical entity index is "1.3.6.1.2.1.47.1.1.1.1.1", and the switch plugin can use this OID to query the detailed information of the switch physical entity index; the OID value of the physical entity alias is "1.3.6.1.2.1.47.1.1.1.1.14", and the switch plugin can use this OID to query the switch physical entity alias; the OID value of the interface description is "1.3.6.1.2.1.2.2.1.2", and the switch plugin can use this OID to query the switch interface description.

[0036] The query results for detailed switch information, including switch information, switch board information, and switch port information, are shown in Tables 2, 3, and 4 below:

[0037] Table 2 shows the switch information queried.

[0038]

[0039] As shown in Table 2, the queried switch information indicates that it is a CloudEngine S5735-L-V2 series switch, model "S5735-S48T4XE-V2".

[0040] Table 3 shows the switch board information queried.

[0041]

[0042] As shown in Table 3, the query information of the switch boards shows that the boards in each slot of the switch are MPU boards, fan boards, power supply boards and their numbers.

[0043] Table 4 shows the switch port information queried.

[0044]

[0045] As shown in Table 4, the queried switch port information displays the name and speed of each port. For example, "GE1 / 0 / 8" indicates "Gigabit Ethernet port, stacked, slot 0, port 8", and "10GE1 / 0 / 6" indicates "10 Gigabit Ethernet port, stacked, slot 0, port 6".

[0046] After converting the switch details into more readable information, they are stored in the database. Then, the flag indicating whether the switch plugin is running for the first time is set to "not the first time," so that the switch plugin does not need to repeatedly read the switch details upon restart.

[0047] The second step involves reading detailed switch information from the database and writing it into the plugin's memory for further refinement. Based on the actual needs of subway users, it's determined whether each switch performance parameter requires rapid querying. Memory usage, temperature, CPU usage, optical module transmit power, and optical module receive power are all parameters requiring rapid querying, and the switch plugin uses a separate thread to query these parameters. Other performance parameters that don't require rapid querying are polled by another separate thread. The value of a performance parameter can be retrieved by querying its corresponding OID. The OIDs for each performance parameter are shown in Table 5 below.

[0048] Table 5 Performance parameters and corresponding OIDs

[0049]

[0050] This line uses a MySQL database. The method to read the switch details from the database is: select distinct * from 'table_name' where 'restriction_condition' group by 'grouping_basis' having 'filter_condition' order by limit 'number_of_representations'.

[0051] The third step is to receive and process TRAP information sent by the switch in real time. Read the received TRAP information, identify the PDU type as 7, indicating it's a TRAP message. Parse the variable binding list in the TRAP message; it's a sequence containing multiple "variable name-value" pairs. Each "variable name-value" pair is also a sequence containing an OID and a Value. The OID serves as a unique identifier for the object, specifying what the variable is, and the Value is the object's value at the current moment. For example, if the TRAP information contains the OID "1.3.6.1.2.1.2.2.1.8.", it indicates that the TRAP information is a real-time report of the "port working status." Based on the corresponding value of the OID in the TRAP information, determine whether the port working status is UP or DOWN, and generate a corresponding alarm for port disconnection or port reconnection. When an alarm or alarm recovery information is generated, POST the alarm or alarm recovery information to the front end via HTTP. The method for retrieving detailed switch information stored in the database is as follows: The reading method uses different syntax depending on the database type, where:

[0052] MySQL:

[0053] SELECT DISTINCT * FROM 'table_name' WHERE 'restrictions' GROUP BY 'grouping criteria' HAVING 'filter conditions' ORDER BY LIMIT 'number of rows to display'

[0054] SQL Server:

[0055] SELECT * FROM table_name WHERE column_name='value'

[0056] MongoDB:

[0057] db.collection_name.find({condition_document}).

[0058] Write the switch performance parameters into the database. Specific information is shown in Table 6 below.

[0059] Table 6. Switch Performance Parameter Storage

[0060]

[0061] The method for writing to the database is as follows:

[0062] The syntax varies depending on the database type, including:

[0063] MySQL:

[0064] INSERT INTO table_name(field1, field2, ..., fieldn) VALUES (value1, value2, ..., valuen);

[0065] SQL Server:

[0066] INSERT INTO table_name[(column_name1, column_name2, ...)]

[0067] VALUES (value1, value2, ...);

[0068] MongoDB:

[0069] db.collection_name.insertOne({key_name:value}).

[0070] This line uses a MySQL database, and the method for writing to the database is:

[0071] INSERT INTO table_name(field1,field2,...fieldn) VALUES (value1,value2,...valuen) The front-end software interacts with the switch plugin via HTTP requests (GET and POST). The switch plugin processes the requests, performs database operations, and then returns the data to the front-end in JSON format. The front-end software sends HTTP requests to the switch plugin. Upon receiving the request, the switch plugin executes the corresponding business logic based on the request URL and parameters, connects to the database, executes an SQL query, converts the query results into JSON format, and returns them to the front-end software via an HTTP response. The data in the JSON format of the query results in Table 6 is as follows: [

[0073] {

[0074] "id": 1,

[0075] Time: 2025 / 11 / 7 14:17:18.253

[0076] Device Name: Dedicated Telephone Parking Exchange 104

[0077] "Performance Data": "Port Working Status",

[0078] "Subframe": 0,

[0079] "Slot": 1,

[0080] "Port": 0,

[0081] "Value": "UP"

[0082] },

[0083] {

[0084] "id": 2,

[0085] Time: 2025 / 11 / 7 14:17:23.252

[0086] Device Name: Dedicated Telephone Parking Exchange 104

[0087] Performance data: CPU utilization

[0088] "Subframe": 0,

[0089] "Slot": 1,

[0090] "port": null,

[0091] Value: 3%

[0092] } ]

[0094] The front-end software receives the JSON data, parses it, and updates the page. Users can then view the switch's performance parameters and query its alarm information.

[0095] Through the above steps, the performance parameters of the switch are monitored. The basic connectivity is ensured by monitoring the status of the switch ports, congestion and bottlenecks are identified by monitoring the amount of data entering and leaving the switch ports, physical layer and data link layer problems are diagnosed by monitoring the error packet count and packet loss rate of the switch ports, and device health is assessed and downtime is prevented by monitoring CPU utilization, memory utilization and temperature. This provides an efficient and solid guarantee for the stability of the entire network.

Claims

1. A scalable intelligent operation and maintenance monitoring method for switch performance parameters, characterized in that: Using a server or PC as the platform, and operating systems such as Windows or Linux, this system reads and saves performance parameters of multiple switches. The specific steps are as follows: First, determine whether the switch plugin configuration file is being run for the first time. If it is, the system needs to read the basic information summary table of the switches, poll the IP addresses of each switch in the summary table, query detailed information for each switch, convert the detailed information into readable information, and store it in the database. If it is not the first time running the switch plugin, proceed directly to the second step. The second step is to read the switch details stored in the database in the first step, write them into the plugin memory, determine whether each performance parameter OID in the switch details belongs to the two types of performance parameter data, fast query and normal query, query the data of these two types of performance parameters through two independent threads, write the query results into the database, and provide them to the front-end software for querying and display. The third step is for the switch plug-in to receive and process the TRAP information sent by the switch in real time. TRAP is an active notification mechanism based on the SNMP protocol. When a switch detects a fault, status change, or an anomaly, it actively sends a real-time message. The switch plugin compares the TRAP information sent by the switch with the detailed switch information written into the plugin's memory in the second step, generates corresponding performance parameter data or alarm information, writes it into the database, and provides it to the front-end software for querying and display. When generating alarm information, it needs to be reported to the front-end software in real time. By following the above three steps, the performance parameters of the switch can be monitored. The first step involves a summary table of basic switch information, including the switch's IP address, model information, performance parameters to be monitored, performance monitoring OID, whether the performance parameters are those that can be quickly queried, and the unit of the performance parameters; and detailed switch information, including switch information, switch board information, and switch port information. The switch information includes the switch's IP address, model information, and switch performance monitoring OID; The switch board information includes the number of boards, board model, board name, board logical number, board physical number, and board performance monitoring OID; Switch port information includes the number of ports, port type, port name, port logical number, port physical number, port performance monitoring OID, and port TRAP information; The method for querying detailed information of each switch in the first step is as follows: use the WALK or GETBULK operation of the SNMP protocol to query the switch. The query fields include interface index, interface description, and interface type. After the switch returns the query results, the switch plugin converts the detailed switch information into readable information. According to the type of detailed information returned by the switch, the port information is converted into port information containing the number of ports, port type, port name, port logical number, and port physical number. The board information is converted into board information containing the number of boards, board model, board name, board logical number, and board physical number. The second step, quick performance parameter query, involves monitoring performance parameters that users require in a timely manner. These are parameters whose abnormal values ​​will affect the normal operation of the switch. Each query should be performed using the maximum number of OIDs, denoted as MAX_OID_COUNT. The larger the number, the more performance parameters are queried in a single query, and the faster the query will be. MAX_OID_COUNT can be set as a configurable parameter, configured according to actual conditions. Ordinary performance parameters are those that do not affect the normal operation of the switch and are for user viewing. The second step involves determining whether each performance parameter OID in the switch's detailed information belongs to either the quick query or normal query performance parameter data. This is achieved using two independent threads to query these two types of performance parameters. The switch's performance parameters are categorized into normal performance parameters and quick query performance parameters based on user needs. The process for determining the normal performance parameters is as follows: Periodically check if the initialization flag is SUCCESS. If yes, it indicates that the software initialization process has completed normally. If not, return to the idle state and wait for the next cycle to continue checking if the initialization process has completed normally. Read the current switch number index to obtain the current switch's IP address and its normal performance parameters. Send an SNMP GET query operation and obtain the SNMP GET return result, i.e., the performance parameter value. Increment the switch number index by 1 to point to the next switch. Check if the switch number index is greater than or equal to the total number of switches. If yes, set the switch number index to 0, indicating that the query for all switches' normal performance parameters will restart. After a 3-second sleep period, return to the idle state and wait for the next cycle to query the switch corresponding to the new switch number index. The process of determining the fast query performance parameter thread for a switch is as follows: Periodically check if the initialization flag is SUCCESS. If yes, it indicates that the software initialization process has ended normally; otherwise, return to the idle state and wait for the next cycle to continue checking if the initialization process has ended normally. Read the current switch number index to obtain the IP address of the current switch and the fast query performance parameters for that switch. Determine if the total number of fast query performance parameters obtained exceeds MAX_OID_COUNT. If yes, send an SNMP GET query operation and obtain the SNMP GET return result, i.e., obtain the performance parameter value; otherwise, continue to obtain the OID of the fast query performance parameters to be queried locally. Increment the switch number index by 1 to point to the next switch. Check if the switch number index is greater than or equal to the total number of switches. If yes, set the switch number index to 0, indicating that the fast query performance parameters of all switches will be queried again. After a 3-second sleep period, return to the idle state and wait for the next cycle to query the switch corresponding to the new switch number index.

2. The method for scalable intelligent operation and maintenance monitoring of switch performance parameters according to claim 1, characterized in that: The second step describes a method for querying these two types of performance parameters using two independent threads: using the SNMP protocol to send a GET request to the switch to query the performance parameters of multiple boards and ports at once, with the number of performance parameters queried at one time ranging from 50 to 70.

3. The method for scalable intelligent operation and maintenance monitoring of switch performance parameters according to claim 1, characterized in that: The method described in step three for the switch plugin to compare the TRAP information sent by the switch with the switch details written into the plugin's memory in step two is as follows: When an SNMP message is received, the PDU type is identified as 7, indicating that it is a TRAP message. The variable binding list in the TRAP message is parsed. It is a sequence containing multiple "variable name-value" pairs. Each "variable name-value" pair is also a sequence containing an OID and a Value. The OID serves as a unique identifier for the object, indicating what the variable is, and the Value is the value of the object at the current moment. The OID in the TRAP information is compared with the OID in the switch details read into the plugin's memory in step two. After finding the corresponding OID, the Value corresponding to the OID in the TRAP information is updated to the database. If the OID corresponds to a user-requested alarm, the corresponding alarm is generated, sent to the front-end software via HTTP POST for alarm display, and the alarm information is written to the database.

4. The scalable intelligent operation and maintenance monitoring method for switch performance parameters according to claim 1, characterized in that: The method for providing query and display to the front-end software in the third step is as follows: The front-end software interacts with the switch plugin through HTTP requests GET and POST. The switch plugin processes the request, performs database operations, and then returns the data to the front-end in JSON format. The front-end software sends an HTTP request to the switch plugin. The switch plugin receives the request, executes the corresponding business logic according to the URL and parameters of the request, connects to the database, executes SQL queries, converts the query results into JSON format, and returns them to the front-end software through an HTTP response. The front-end software receives the response, parses the data, and updates the page, allowing users to view the switch's performance parameters and query switch alarm information.

Images