Distributed problem network management method and system

Abstract

The present application relates to a distributed problem network management method and system. According to the format arrangement rules of the warning message, an alarm notification is obtained. Each distributed device cluster has its own identity identification code. By associating the format arrangement rules of the warning message with the identity identification code, it is helpful to quickly determine the device cluster that may have problems. After determining the problem device cluster, each alarm notification is used to form an alarm history list, which can expand the data reserve of the noise reduction relationship model, thereby realizing convenient elimination of false alarm noise. Specifically, the problem network management method performs multi-dimensional analysis through the historical fields of the alarm message, the timeline of the warning message, and the original message ID of the warning message. The analysis results can be formed into management tasks in a timely manner, and the management tasks can be assigned to the engineer's task window. This greatly improves the maintenance convenience of the distributed problem network management method.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a distributed problem network management method and system. Background Art

[0002] In the process of intelligent device operation and maintenance of communication service providers, computer engineers and operation and maintenance engineers who manage intelligent device networks often encounter a single alarm notification method for problem networks when actually handling the equipment of problem networks. This leads to low convenience for computer engineers and operation and maintenance engineers to deal with problem networks and problem network equipment. In fact, most of the current intelligent devices and intelligent device networks are distributed architectures. Traditional distributed problem network management methods often result in irregular operation and maintenance management and low collaboration efficiency for relevant engineers who manage intelligent device networks due to the single alarm notification method for problem networks. To this end, it is necessary to propose a distributed problem network management method and system to address the defect of low maintenance convenience of traditional distributed problem network management methods. Summary of the invention

[0003] Based on this, it is necessary to propose a distributed problem network management method and system to address the defect of low maintenance convenience of traditional distributed problem network management methods.

[0004] The present application provides a distributed problem network management method, comprising:

[0005] Obtain warning notifications according to the format arrangement rules of warning messages;

[0006] Use each alarm notification to form an alarm history list;

[0007] In the alarm history list, obtain the drop-down list of historical fields of the alarm message;

[0008] Based on the history field drop-down list, obtain the original message ID of each history field; the original message ID is the identity identification number of the original message;

[0009] Using each original message ID, a timeline of the problem network event and a status table of the problem network event are formed;

[0010] Incorporate the timeline of problematic network events and the state table of problematic network events into the noise reduction relationship model;

[0011] Obtain analysis results of the noise reduction relationship model;

[0012] Transform analysis results into management tasks;

[0013] Assign management tasks to engineers' task windows.

[0014] The present application provides a distributed problem network management system, comprising:

[0015] A server, configured to execute the distributed problem network management method as claimed in any one of claims 1 to 8;

[0016] The memory is communicatively connected with the server.

[0017] The present application relates to a distributed problem network management method and system. According to the format arrangement rules of the warning message, an alarm notification is obtained. Each distributed device cluster has its own identity identification code. By associating the format arrangement rules of the warning message with the identity identification code, it is helpful to quickly determine the device cluster that may have problems. After determining the problem device cluster, each alarm notification is used to form an alarm history list, which can expand the data reserve of the noise reduction relationship model, thereby realizing convenient elimination of false alarm noise. Specifically, the problem network management method performs multi-dimensional analysis through the historical fields of the alarm message, the timeline of the warning message, and the original message ID of the warning message. The analysis results can be formed into management tasks in a timely manner, and the management tasks can be assigned to the engineer's task window. This greatly improves the maintenance convenience of the distributed problem network management method. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 A flow chart of a distributed problem network management method provided in one embodiment of the present application;

[0019] Figure 2 A structural connection diagram of a distributed problem network management system provided in one embodiment of the present application.

[0020] Reference numerals:

[0021] 100-server; 200-storage. DETAILED DESCRIPTION

[0022] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0023] The present application provides a distributed problem network management method.

[0024] like Figure 1 As shown, in one embodiment of the present application, a distributed problem network management method includes:

[0025] S100, obtaining an alarm notification according to a format arrangement rule of the alarm message.

[0026] Specifically, before obtaining the warning message, the request data type and the response data type are determined according to the interface address and the calling method when establishing communication with the device.

[0027] Simple, formatting rules for data types in alert notifications. This allows quick identification of the source of the alert message.

[0028] S200, using each alarm notification to form an alarm history list.

[0029] Specifically, determining the source of the warning message is actually determining the original message ID. The alarm notification is obtained according to the original message ID. Each alarm notification can be collected to form an alarm history list.

[0030] The alarm notification contains information such as user ID, alarm source ID, model name of the warning model, alarm source type, host, etc.

[0031] The diversity of information in alarm notifications can greatly improve the screening speed of distributed networks and the location of problem networks.

[0032] A large number of alarm notifications can be used as samples for data training and noise reduction to improve the accuracy of relationship models, which can also help engineers improve the management convenience of distributed network devices.

[0033] S300: Obtain a drop-down list of historical fields of an alarm message in the alarm history list.

[0034] Specifically, the alarm message may be "sourme": "The person in charge of the test user group cmdb has an intersection". Sourme is the alarm source type of the alarm message. The person in charge of the test user group cmdb has an intersection is the specific content of the warning. Through the rule of merging fields, it can be determined that "The person in charge of the test user group cmdb has an intersection" is the merged field of the alarm message. The message is generated in the host "demo15". And the danger level of this message is "WARNING.level.max".

[0035] S400, based on the history field drop-down list, obtain the original message ID of each history field.

[0036] Specifically, the original message id is the identity identification number of the original message.

[0037] Through the original message ID, each historical field, that is, a non-real-time, merged field that has appeared, can be associated with the host information.

[0038] In fact, the formation of a timeline helps engineers quickly analyze the sources and causes of distributed problem networks, thereby improving the speed of handling distributed network problems and improving the fluency of collaboration between engineers.

[0039] S500, using each original message ID, a timeline of the problem network event and a state table of the problem network event are formed.

[0040] Specifically, the status table of the problem network event includes whether the alarm source ID is managed, the alarm level, and the engineer's takeover status. True means it is managed, and false means it is not managed. The alarm levels are OK, DISASTER, HIGH, AVERAGE, and WARNING. The takeover status includes PENDING, PROCESSING, and CLOSED.

[0041] The factors included in the problem network event timeline include tag value, status, level, alarm source name, field, event name, merge rule name, creation time, update event, last update time, and last creation time.

[0042] S600: Incorporate the timeline of the problem network event and the state table of the problem network event into the noise reduction relationship model.

[0043] Specifically, the noise reduction relationship model includes modules such as model training id, offline task, alarm source id, merging rule id, start time, end time, model type, algorithm type, and algorithm parameters.

[0044] S700: Obtain analysis results of the noise reduction relationship model.

[0045] S800, forming a management task with the analysis result.

[0046] S900, assign management tasks to the engineer's task window.

[0047] Specifically, the analysis result of the noise reduction relationship model is the maintenance strategy of the problem network. Based on the maintenance strategy, the maintenance plan of the problem network is formed into at least one task, and the task is distributed to engineers.

[0048] First, you can query the engineers in the user group based on the completion conditions such as the skill requirements of the task. Provide relevant task information to engineers in batches through configuration item IDs. Create a post-callback interface for the task ticket so that the system can update the maintenance status of the problem network in a timely manner.

[0049] This embodiment relates to a distributed problem network management method. According to the format arrangement rules of the warning message, an alarm notification is obtained. Each distributed device cluster has its own identity identification code. By associating the format arrangement rules of the warning message with the identity identification code, it is helpful to quickly determine the device cluster that may have problems. After determining the problem device cluster, each alarm notification is used to form an alarm history list, which can expand the data reserve of the noise reduction relationship model, thereby realizing convenient elimination of false alarm noise. Specifically, the problem network management method performs multi-dimensional analysis through the historical fields of the alarm message, the timeline of the warning message, and the original message ID of the warning message. The analysis results can be formed into management tasks in a timely manner, and the management tasks can be assigned to the engineer's task window. This greatly improves the maintenance convenience of the distributed problem network management method.

[0050] In one embodiment of the present application, S100 includes:

[0051] S110, determining a calling method of the warning message.

[0052] S120, determining the data type of the requesting network device and the data type of the responding network device according to the format arrangement rule of the warning message.

[0053] S130: Obtain a warning message based on the interface address.

[0054] S140, extracting the id of the warning source according to the obtained warning message.

[0055] Specifically, the warning message may be called by a GET function, or by calling data through the address 111.10.19.132:18080.

[0056] Generally speaking, the data type of the request network device and the data type of the response network device can be determined according to the application type of json or the application type of python. Different application types have different format arrangement rules for warning messages, and the format arrangement rules for warning messages contain the id of the warning source.

[0057] The interface address is the access address of the database. In distributed network devices, the network device can be found based on the interface address.

[0058] According to the format arrangement rules of the warning message, the alarm notification is obtained. Each distributed device cluster has its own identity identification code. By associating the format arrangement rules of the warning message with the identity identification code, it is helpful to quickly determine the device cluster that may have problems.

[0059] In one embodiment of the present application, S200 includes:

[0060] S210: Select an alarm notification.

[0061] S220: Determine the ID of the warning source of the selected warning notification.

[0062] S230, based on the ID of the warning source, determine the host corresponding to the warning source.

[0063] S240: Determine the warning parameter type in the warning source type by using the warning source ID.

[0064] S250: Determine the merged fields in the alarm notification based on the alarm parameter type.

[0065] S260, adding the merged field into the alarm history list.

[0066] S270, returning to the step of selecting an alarm notification until all alarm notifications are selected.

[0067] Specifically, in the process of establishing a timeline of problematic network events, a large number of alarm notifications are required as joint objects.

[0068] A large number of alarm notifications have two functions. One is to establish a timeline of problem network events. The other is to correct the response accuracy of establishing the timeline of problem network events based on the trained noise reduction relationship model, thereby improving the response accuracy of the distributed problem network management method.

[0069] In fact, the sample data used for modeling, training, and correcting parameters of the denoising relationship model are a large number of alarm notifications.

[0070] In one embodiment of the present application, S300 includes:

[0071] S310, select a host.

[0072] S320, calling all merge fields of the selected host.

[0073] S330, counting all merged fields.

[0074] S340, forming a historical field drop-down list about the frequency of occurrence of the merged field.

[0075] S350, returning to the process of selecting a host until all hosts are selected.

[0076] Specifically, the alarm notification includes the ID of the warning source, the alarm source type, the host information, and the merge field.

[0077] The drop-down list of historical fields of alarm messages contains the ID of the alarm source, the alarm source type, the host information, and the merged fields.

[0078] In fact, a host can have multiple alarm notifications, and the main body of the information in the alarm notification is the content of the merged field.

[0079] By counting all the merged fields, you can determine the number of identical alarm notifications for a host.

[0080] Based on the number of identical alarm notifications, it is possible to determine the host fault, whether the fault was resolved in a timely manner, and the danger level of the fault.

[0081] In one embodiment of the present application, S400 includes:

[0082] S410, calling an id of a warning source.

[0083] S420, determining each access time of the warning source ID.

[0084] S430: Generate a timeline of the warning source ID based on each access time of the warning source ID.

[0085] S440: Select an access time.

[0086] S450, based on the intervention time and the host corresponding to the ID of the warning source, determine the merge field corresponding to the selected access time.

[0087] S460, returning to the step of selecting an access time until all access times are selected.

[0088] S470, returning the ID of calling a warning source until the IDs of all warning sources are called.

[0089] S480, obtaining a timeline of the id of the warning source of the original message id of the history field.

[0090] Specifically, the original message id of the history field is a combined field, an id of a warning source, and a joint identity identification number of a host corresponding to the id of the warning source.

[0091] The access time of the warning source ID can be determined based on the event log.

[0092] The event log contains the host ID, the time when events and warnings were generated, and the update of events.

[0093] Arrange each access time of the same warning source ID in chronological order to generate a timeline of the warning source ID.

[0094] The timeline of the warning source ID is one of the components of the problem network event timeline. The timeline of the warning source ID is supplemented with a corresponding merge field.

[0095] The timeline can be used to manage distributed networks and distributed network devices more clearly. The timeline can improve the management convenience of distributed networks and distributed network devices.

[0096] In one embodiment of the present application, S500 includes:

[0097] S511, select a timeline of the id of the warning source of the original message id of the history field.

[0098] S512, select a merge field.

[0099] S513, determining whether adjacent access times appear in the same merged field.

[0100] S514: If no adjacent access time appears in the same merged field, it is determined that the merged field is a resolved network event.

[0101] S515: If adjacent access times appear in the same merged field, determine whether the time difference between the latest access time and the system time is within the alarm time period.

[0102] S516: If the time difference between the latest access time and the system time is not within the alarm time period, the problematic network event corresponding to the merged field is determined to be a level 2 risk event.

[0103] S517: If the time difference between the latest access time and the system time is within the alarm time period, the problematic network event corresponding to the merged field is determined to be a first-level risk event.

[0104] S518, returning to the step of selecting a merge field until all merge fields are selected.

[0105] S519, returning to the step of selecting a timeline of an id of a warning source for an original message id of a history field, until all timelines of an id of a warning source for an original message id of a history field are selected.

[0106] Specifically, the merged field, as the main content of the warning notification, can provide feedback on event sequence number, event level, processing status, tag name, tag value and other information.

[0107] Relying on the alarm source ID, alarm source name, alarm source creation time, alarm source update time, alarm source first access time, and alarm source resolution timestamp, a variety of information can be given to problem network events.

[0108] The aggregation of diverse information in problematic network events can improve the accuracy of risk assessment of problematic network events and conveniently increase the speed of handling problematic network events.

[0109] More specifically, DISASTER and HIGH in the hazard level are secondary risk events.

[0110] AVERAGE and WARNING in the hazard level are level one risk events.

[0111] Since a level 1 risk event will trigger multiple high-frequency alarms in the firewall system, the time difference between the latest access time and the system time can be used to simply distinguish the risk event danger level of the problem network.

[0112] In one embodiment of the present application, S500 further includes:

[0113] S521, based on all the first-level risk events and all the second-level risk events, a status table of problem network events is formed.

[0114] S522, each warning parameter type is formed into a type tag to form a type tag library.

[0115] S523, assigning the type label in the type label library that matches the merged field to the first-level risk event corresponding to the merged field.

[0116] S524, assigning the type label in the type label library that matches the merged field to the secondary risk event corresponding to the merged field.

[0117] S525, all first-level risk events with type tags and all second-level risk events with type tags are combined into a timeline of problematic network events based on the timeline of the warning source id of the original message id in the history field.

[0118] Specifically, the status table of problem network events is used to monitor risk events of problem networks. In fact, there are two possible causes of problem network events: one is the communication connection of the network itself and the network attack event. The other is the hardware failure of the network equipment. The status table of problem network events can mark these two situations with type tags. It can also monitor the handling process nodes of risk events.

[0119] In one embodiment of the present application, S600 includes:

[0120] S610, calling the trained denoising relationship model.

[0121] Specifically, the noise reduction relationship model includes an alarm source ID module, a merging rule ID module, a problem network event start and end time judgment module, a model training module and a parameter adjustment module.

[0122] More specifically, the alarm source id module is used to determine the alarm group id, alarm group id, model id, and sending engineer object id rules.

[0123] The merge rule id module is used to determine the keyword merge rule id, event id, and dispatch rule id.

[0124] The module for determining the start and end time of a problematic network event is used to determine the event log timestamp, the event generation or reopen time, the processing time, the event record creation time, and the update time.

[0125] The model training module can use a large number of alarm notifications as samples for data training and noise reduction to improve the accuracy of the relationship model, which can also help engineers improve the management convenience of distributed network devices.

[0126] The parameter adjustment module can adjust the maximum threshold weight and average threshold weight of the merged field in the risk event information group of this host timeline.

[0127] S620, selecting a timeline of a problematic network event.

[0128] S630, incorporating the timeline of the selected problematic network event into the trained noise reduction relationship model.

[0129] S640: Obtain problematic network events that meet the danger threshold.

[0130] Specifically, problematic network events that are greater than or equal to the danger threshold are problematic network events to be handled by engineers in the management task.

[0131] When a problem network event becomes a risk event, the safety threshold of the problem network event is greater than or equal to the danger threshold, the event may be a problem network event to be handled by engineers in a management task.

[0132] The present application provides a distributed problem network management system.

[0133] like Figure 2 As shown, in one embodiment of the present application, a distributed problem network management system includes a server 100 and a storage 200 .

[0134] The server 100 is used to execute the distributed problem network management method.

[0135] The storage 200 is communicatively connected with the server 100 .

[0136] The present application relates to a distributed problem network management system. The server 100 obtains an alarm notification according to the format arrangement rules of the warning message. Each distributed device cluster has its own identity identification code. By associating the format arrangement rules of the warning message with the identity identification code, it is helpful to quickly determine the device cluster that may have problems. After determining the problem device cluster, each alarm notification is used to form an alarm history list, which can expand the data reserve of the noise reduction relationship model in the memory 200, thereby realizing convenient elimination of false alarm noise. Specifically, the problem network management method performs multi-dimensional analysis through the historical fields of the alarm message, the timeline of the warning message, and the original message ID of the warning message. The analysis results can be formed into management tasks in a timely manner, and the management tasks can be assigned to the engineer's task window. This greatly improves the maintenance convenience of the distributed problem network management method.

[0137] The technical features of the above-described embodiments may be arbitrarily combined, and the execution order of the method steps is not limited. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0138] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A distributed problem network management method, characterized in that: include: Obtain warning notifications according to the format arrangement rules of warning messages; Use each alarm notification to form an alarm history list; In the alarm history list, obtain the drop-down list of historical fields of the alarm message; Based on the history field drop-down list, obtain the original message ID of each history field; the original message ID is the identity identification number of the original message; Using each original message ID, a timeline of the problem network event and a status table of the problem network event are formed; Incorporate the timeline of problematic network events and the state table of problematic network events into the noise reduction relationship model; Obtain analysis results of the noise reduction relationship model; Transform analysis results into management tasks; Assign management tasks to engineers' task windows.

2. The distributed problem network management method according to claim 1, characterized in that: The step of obtaining the warning notification according to the format arrangement rule of the warning message includes: Determine how warning messages are invoked; Determine the data type of the requesting network device and the data type of the responding network device according to the format arrangement rule of the warning message; Get warning messages based on interface addresses; Extract the warning source ID based on the obtained warning message.

3. The distributed problem network management method according to claim 2, characterized in that: The alarm history list is formed by using each alarm notification, including: Select an alert notification; Determine the id of the warning source of the selected warning notification; Based on the id of the warning source, determine the host corresponding to the warning source; Using the id of the warning source, determine the warning parameter type in the alarm source type; Based on the alert parameter type, determine the merge fields in the alert notification; Include merged fields in the alarm history list; Return to selecting an alarm notification until all alarm notifications are selected.

4. The distributed problem network management method according to claim 3, characterized in that: In the alarm history list, a drop-down list of historical fields of the alarm message is obtained, including: Choose a host; Call all merge fields of the selected host; Count all merge fields; Form a drop-down list of historical fields about the frequency of occurrence of the merged fields; Return to the step of selecting a host until all hosts are selected.

5. The distributed problem network management method according to claim 4, characterized in that: The original message ID of each historical field is obtained based on the historical field drop-down list, including: Call the id of a warning source; Determine each access time of the warning source id; Based on each access time of the warning source ID, a timeline about the warning source ID is generated; Select a time to access; Based on the intervention time and the host corresponding to the id of the warning source, determine the merge field corresponding to the selected access time; Return to selecting an access time until all access times are selected; Return the id of the warning source called, until all the ids of the warning sources are called; A timeline of the id of the warning source about the original message id of the history field is obtained; the original message id of the history field is a combined field, the id of the warning source, and the joint identification number of the host corresponding to the id of the warning source.

6. The distributed problem network management method according to claim 5, characterized in that: The method of using each original message ID to form a timeline of a problem network event and a state table of the problem network event includes: Select a timeline with the id of the warning source on the original message id of the history field; Select a merge field; Determine whether adjacent access times appear in the same merge field; If no adjacent access times appear in the same merged field, the merged field is determined to be a resolved network event; If adjacent access times appear in the same merge field, determine whether the time difference between the latest access time and the system time is within the alarm time period; If the time difference between the latest access time and the system time is not within the alarm time period, the problematic network event corresponding to the merged field is determined to be a level 2 risk event; If the time difference between the latest access time and the system time is within the alarm time period, the problem network event corresponding to the merged field is determined to be a level one risk event; Return to Select a Merge Field until all merge fields are selected; Return to the timeline of selecting the id of the warning source of the original message id of the history field until all the timelines of the id of the warning source of the original message id of the history field are selected.

7. The distributed problem network management method according to claim 6, characterized in that: The method of using each original message ID to form a timeline of a problem network event and a state table of the problem network event also includes: Based on all the first-level risk events and all the second-level risk events, a status table of problem network events is formed; Each warning parameter type is formed into a type tag to form a type tag library; Assign the type label in the type label library that matches the merged field to the first-level risk event of the corresponding merged field; Assign the type label in the type label library that matches the merged field to the secondary risk event of the corresponding merged field; All first-level risk events with type tags and all second-level risk events with type tags are combined to form a timeline of problematic network events based on the timeline of the warning source id of the original message id in the history field.

8. The distributed problem network management method according to claim 7, characterized in that: Incorporating the timeline of the problematic network events and the status of the problematic network events into the noise reduction relationship model includes: Calling the trained noise reduction relationship model; the noise reduction relationship model includes an alarm source ID module, a merging rule ID module, a problem network event start and end time judgment module, a model training module and a parameter adjustment module; Choose a timeline of problematic network events; Incorporate the timeline of the selected problematic network events into the trained noise reduction relationship model; Obtain problematic network events that meet the danger threshold; problematic network events that are greater than or equal to the danger threshold are problematic network events to be handled by engineers in the management task.

9. A distributed problem network management system, characterized in that: include: A server, configured to execute the distributed problem network management method as claimed in any one of claims 1 to 8; The memory is communicatively connected with the server.

Images