Device and method

Abstract

A device according to one aspect of the present disclosure comprises a generation unit that, when a prescribed event has occurred for the first time in a prescribed object, generates, on the basis of a log of a first operation for acquiring information pertaining to the event and a log of a second operation for resolving the event, information for identifying the event when the event occurs next time or thereafter.

Description

Apparatus and Method

[0001] The present disclosure relates to an apparatus and a method.

[0002] In general, while various techniques for detecting events such as failures, abnormalities, and malfunctions have been proposed, few techniques automatically perform responses and measures for events such as failures and abnormalities (hereinafter, operations and the like for resolving such events including responses and measures are collectively simply referred to as "measures"). As one of the conventional techniques for automatically executing measures for events such as failures and abnormalities, a technique capable of automatically executing measures for events occurring from the second occurrence onward has been proposed (Non-Patent Document 1).

[0003] Moriya Takaaki, Mukai Takashi, Nishi Manabu, Tsunoda Ai, Kanishima Ken, "Proposal of a Measure Generation Method Using Past Results in Future Managed Networks", IEICE Technical Report ICM2024-2.

[0004] However, the technique disclosed in Non-Patent Document 1 requires manual registration of information for identifying events from the second occurrence onward. For this reason, the knowledge and labor of a person (e.g., a network operator, etc.) who handles the first occurrence of an event are required.

[0005] The present disclosure has been made in view of the foregoing points, and an object thereof is to provide a technique capable of generating information for identifying an event.

[0006] An apparatus according to an aspect of the present disclosure includes a generation unit that, when a predetermined event occurs for the first time in a predetermined target, generates information for identifying the event from the next occurrence onward, based on a log of a first operation for obtaining information related to the event and a log of a second operation for resolving the event.

[0007] A technique capable of generating information for identifying an event is provided.

[0008] This figure shows an example of a method for generating identification conditions. This figure shows an example of the hardware configuration of a network operation support device according to one embodiment. This figure shows an example of the functional configuration of a network operation support device according to one embodiment. This figure shows a detailed example of the functional configuration of a recording processing unit according to one embodiment. This figure shows an example of an event database. This flowchart shows an example of the operation of a network operation support device according to one embodiment. This flowchart shows an example of recording processing according to one embodiment.

[0009] One embodiment of the present invention will be described in detail below with reference to the drawings.

[0010] <Background, Conventional Technology, and Challenges> In network operations, there is a demand to reduce manual labor while simultaneously operating a large number of networks and maintaining a certain level of quality. Therefore, if an event such as a failure, anomaly, or malfunction has occurred before (i.e., it is the second or subsequent occurrence), it is desirable to be able to automatically respond to the event by reproducing the actions taken by the operator when the event first occurred.

[0011] As a technology that can automatically execute the measures for subsequent occurrences of an event, the technology described in Non-Patent Document 1 is known. Non-Patent Document 1 discloses a technology in which, when an event occurs for the first time (i.e., the first time), the operator registers information for identifying the event and the measures to be taken for that event, so that when the event occurs for the second time or later, the measures to be taken for that event can be automatically executed.

[0012] However, the technology disclosed in Non-Patent Document 1 requires manual registration of information to identify subsequent events, thus demanding knowledge and operational skills from the operator handling the first event.

[0013] Therefore, the following proposes a method to solve the above problems and generate information for identifying subsequent events without requiring the knowledge or work of the operator who handled the first event. In the following, the information for identifying subsequent events will be referred to as "identification conditions."

[0014] <Proposed Method> <Focus> Generally, operation logs record the operation and its results as they are. For this reason, operation logs include operation logs of operations performed by the operator to confirm information about an event (hereinafter also referred to as "confirmation operations") and operation logs of operations performed to resolve the event (hereinafter also referred to as "corrective operations"). Hereafter, operation logs of confirmation operations will also be referred to as "confirmation operation logs," and operation logs of corrective operations will also be referred to as "corrective operation logs."

[0015] Therefore, it is considered possible to generate identification conditions by analyzing how the values ​​of the information items obtained through the verification operation (hereinafter also referred to as "verification information items") change before and after the corrective operation. Examples of verification information items include items related to metrics. Hereafter, if verification information items are output through a verification operation, those verification information items will be included in the operation log of that verification operation.

[0016] <<Outline of the Proposed Method>> The proposed method consists of the following steps 1 to 3. Steps 1 to 3 are executed after the operator has taken action to address the first occurrence of an event.

[0017] Step 1: Review the operation logs after the incident occurred. Classify them into operation logs and corrective action logs.

[0018] Step 2: If there are any verification operations performed before the corrective action that have not been performed after the corrective action, perform those verification operations. Hereafter, verification operations performed before the corrective action will also be referred to as "pre-corrective operations," and verification operations performed after the corrective action will be referred to as "post-corrective operations."

[0019] Step 3: Generate identification conditions from the difference between the value of the confirmation information item for the confirmation operation log prior to the action operation log and the value of the confirmation information item for the confirmation operation log after the action operation log.

[0020] For example, as shown in Figure 1, the above steps 1 and 2 yield the following: operation log 1010 for the pre-check operation, operation log 1020 for the pre-check operation, confirmation information item 1021 for operation log 1020, operation log 1030 for the corrective action operation, operation log 1040 for the post-check operation, confirmation information item 1041 for operation log 1040, operation log 1050 for the post-check operation, and confirmation information item 1051 for operation log 1050. In this case, step 3 above generates the identification condition "no output as a result of 'ps -ef | grep ' / usr / sbin / httpd -k start ' | grep -v grep'" from the difference between confirmation information item 1021 and confirmation information items 1041 and 1051. This is because there is no difference between confirmation information item 1021 and confirmation information item 1051, but there is a difference in confirmation information item 1041.

[0021] As a result, the operator only needs to take action for the first occurrence of an event, eliminating the need for knowledge or work to generate identification conditions. Therefore, it is possible to automate the response to events at a lower cost than, for example, the technology disclosed in Non-Patent Document 1. In the following, we assume the case of generating identification conditions to identify events such as abnormalities, failures, and malfunctions that occur in network equipment, etc., but this is just an example, and it can be similarly applied to generating identification conditions to identify events that occur in any device, equipment, or system (e.g., ICT system, etc.).

[0022] The following describes a network operation support device 10 that can automatically execute measures for subsequent occurrences of abnormalities, failures, malfunctions, and other events in network equipment, etc., after generating event identification conditions using the proposed method described above.

[0023] <Example of Hardware Configuration of Network Operation Support Device 10> Figure 2 is a diagram showing an example of the hardware configuration of a network operation support device 10 according to one embodiment. As shown in Figure 2, the network operation support device 10 according to one embodiment includes an input device 101, a display device 102, an external I / F 103, a communication I / F 104, a RAM (Random Access Memory) 105, a ROM (Read Only Memory) 106, an auxiliary storage device 107, and a processor 108. Each of these hardware components is connected to communicate via a bus 109.

[0024] The input device 101 is, for example, a keyboard, mouse, touch panel, or physical button. The display device 102 is, for example, a display or display panel. Note that the network operation support device 10 does not necessarily have to have at least one of the input device 101 and the display device 102.

[0025] The external I / F 103 is an interface with external devices such as the recording medium 103a. Examples of recording media 103a include CDs (Compact Discs), DVDs (Digital Versatile Disks), SD memory cards (Secure Digital memory cards), and USB (Universal Serial Bus) memory cards.

[0026] The communication interface 104 is an interface for connecting to a communication network. The RAM 105 is a volatile semiconductor memory (storage device) that temporarily holds programs and data. The ROM 106 is a non-volatile semiconductor memory (storage device) that can retain programs and data even when the power is turned off. The auxiliary storage device 107 is a non-volatile storage device such as an HDD (Hard Disk Drive), SSD (Solid State Drive), or flash memory. The processor 108 is an arithmetic unit such as a CPU (Central Processing Unit).

[0027] Note that the hardware configuration shown in Figure 1 is just one example, and the hardware configuration of the network operation support device 10 is not limited to this. For example, the network operation support device 10 may have multiple auxiliary storage devices 107 and multiple processors 108, it may not have some of the hardware shown, or it may have various other hardware besides the hardware shown.

[0028] <Example of Functional Configuration of Network Operation Support Device 10> Figure 3 is a diagram showing an example of the functional configuration of a network operation support device 10 according to one embodiment. As shown in Figure 3, the network operation support device 10 according to one embodiment includes a fault definition unit 201, an automatic execution determination unit 202, a recording processing unit 203, and an automatic execution processing unit 204. Each of these units is realized, for example, by a process in which one or more programs installed in the network operation support device 10 are executed by a processor 108 or the like. The network operation support device 10 according to one embodiment also has an event DB 205. The event DB 205 is realized, for example, by a storage area such as an auxiliary storage device 107. The event DB 205 may also be realized, for example, by a storage area of ​​a storage device (e.g., a storage device of a database server) that is communicably connected to the network operation support device 10.

[0029] When the fault definition unit 201 receives an alarm or the like from a network device, it identifies the event identification information (hereinafter also referred to as the "event key") that represents the alarm or the like. The fault definition unit 201 may, for example, identify the event key from information that associates alarms with event keys, identify the event key from a model created using machine learning, or identify the event key by other methods.

[0030] The automatic execution determination unit 202 determines, based on the event key and the event database 205, whether the event represented by the event key is the first occurrence or a second or subsequent occurrence. Specifically, the automatic execution determination unit 202 determines, based on the event key, the abstracted event key (described later) and identification conditions included in the event data stored in the event database 205, that if a certain event data can be obtained, it is the second or subsequent occurrence; otherwise, it is the first occurrence.

[0031] If the recording processing unit 203 determines that the event represented by the event key has occurred for the first time, it creates event data that includes an abstracted event key (a key obtained by grouping or abstracting the event key), the identification conditions for the event, and the corrective action taken for the event, and saves it in the event DB 205. A detailed example of the functional configuration of the recording processing unit 203 will be described later.

[0032] If the automatic execution processing unit 204 determines that the event represented by the event key is the second or subsequent occurrence, it executes the action taken as included in the event data acquired by the automatic execution determination unit 202.

[0033] ≪Detailed Functional Configuration Example of Record Processing Unit 203≫ Figure 4 is a diagram showing a detailed functional configuration example of a record processing unit 203 according to one embodiment. As shown in Figure 4, the record processing unit 203 according to one embodiment includes an interface unit 211, a log acquisition unit 212, a log classification unit 213, a confirmation operation unit 214, an identification condition generation unit 215, and a data creation unit 216.

[0034] The interface unit 211 is an interface with the operator, and notifies the operator when an event occurs, accepts operations from the operator, and outputs those operations to network devices, etc.

[0035] The log acquisition unit 212 acquires operation logs for a predetermined period (or a predetermined number of logs) before and after any action taken in response to the event. The log acquisition unit 212 may acquire operation logs from, for example, a log management system that manages operation logs for network devices, etc.

[0036] The log classification unit 213 classifies the operation logs acquired by the log acquisition unit 212 into confirmation operation logs and corrective operation logs. The log classification unit 213 may classify the operation logs into confirmation operation logs and corrective operation logs by any method. For example, the log classification unit 213 may classify the operation logs using information that associates the operation log with a category indicating whether the operation log is a confirmation operation log or a corrective operation log. Alternatively, the log classification unit 213 may classify the operation logs using a large-scale language model (LLM), or it may classify the operation logs based on values ​​associated with the operation buttons used by the operator.

[0037] The confirmation operation unit 214 uses the operation logs classified by the log classification unit 213 to execute any confirmation operations that were performed before the corrective action but not after the corrective action. This allows the confirmation information items for those confirmation operations to be obtained.

[0038] The identification condition generation unit 215 generates identification conditions from the difference in the values ​​of the confirmation information items before and after the corrective action operation. The identification conditions include a confirmation operation for outputting confirmation information items that differ before and after the corrective action operation, and conditions on the values ​​of the confirmation information items output by that confirmation operation.

[0039] The data creation unit 216 creates an abstract event key from the event key, and then creates event data that includes the abstract event key, the identification conditions generated by the identification condition generation unit 215, and the action operations represented by the action operation logs classified by the log classification unit 213, and saves it in the event DB 205. An abstract event key is, for example, identification information that represents a group when event keys representing events that can reuse the same action are grouped into the same group. Note that the group is defined in advance, for example, by a human.

[0040] <<Event DB 205>> FIG. 5 is a diagram showing an example of the event DB 205. As shown in FIG. 5, event data is stored in the event DB 205, and each piece of event data includes, for example, an ID, an event key, an abstracted event key, pre-confirmation, measure operation, post-confirmation, and the like. Here, the pre-confirmation corresponds to the identification condition. However, this is only an example, and for example, the event key and post-confirmation do not need to be included in the event data. Note that the post-confirmation is information for confirming whether or not the event has been resolved as intended when a measure is executed by the automatic execution processing unit 204.

[0041] In the example shown in FIG. 5, a case where event data with ID "1" and event data with ID "2" are stored in the event DB 205 is shown.

[0042] <Operation Example of Network Operation Support Device 10> FIG. 6 is a flowchart showing an example of the operation of the network operation support device 10 according to an embodiment. Hereinafter, it is assumed that the network operation support device 10 has received an alarm transmitted from a network device or the like.

[0043] A failure defining unit 201 identifies an event key of the alarm (step S101).

[0044] Next, an automatic execution determining unit 202 determines, based on the event key identified in step S101 described above and the event DB 205, whether the occurrence of the event represented by the event key is the first occurrence or the second or subsequent occurrence (step S102). The automatic execution determining unit 202 may determine whether the occurrence of the event is the first occurrence or the second or subsequent occurrence by, for example, the following procedures 11 to 15.

[0045] Procedure 11: The automatic execution determining unit 202 searches for event data from the event DB 205 by using the target event key and an abstracted event key included in event data stored in the event DB 205. That is, the automatic execution determining unit 202 searches the event DB 205 for event data of the abstracted event key of a group including the target event key.

[0046] Step 12: The automatic execution determination unit 202 determines that it is the first occurrence when no event data is retrieved in step 11 described above, and executes step 13 and subsequent steps when event data is retrieved in step 11 described above.

[0047] Step 13: The automatic execution determination unit 202 uses the prior confirmation (identification condition) included in the event data retrieved in step 11 described above to execute the confirmation operation included in the prior confirmation (identification condition).

[0048] Step 14: The automatic execution determination unit 202 determines whether or not the value of the confirmation information item output for the confirmation operation executed in step 13 described above satisfies the condition included in the identification condition.

[0049] Step 15: The automatic execution determination unit 202 determines that the occurrence is the second or subsequent time when it determines that the value of the confirmation information item satisfies the condition included in the identification condition, and acquires the event data from the event DB 205. On the other hand, the automatic execution determination unit 202 determines that it is the first occurrence when it does not determine that the value of the confirmation information item satisfies the condition included in the identification condition for all event data retrieved in step 11 described above.

[0050] When it is determined in step S102 described above that the event occurs for the first time, the recording processing unit 203 creates case data by executing recording processing and stores the case data in the event DB 205 (step S103). An example of the recording processing will be described later.

[0051] On the other hand, when it is determined in step S102 described above that the event occurs for the second or subsequent time, the automatic execution processing unit 204 executes the measure operation included in the event data acquired in step 15 described above (step S104). This enables automatic implementation of measures for an event occurring in a network device or the like, thereby achieving elimination of the event.

[0052] <<Example of Recording Processing>> Figure 7 is a flowchart showing an example of recording processing according to an embodiment.

[0053] The interface unit 211 notifies the operator that an event has occurred (step S201). This allows the operator to perform confirmation and corrective actions.

[0054] The interface unit 211 outputs confirmation operations, corrective actions, and other operations performed by the operator to network equipment, etc. (step S202). This resolves the issue that occurred in the network equipment, etc. After the issue is resolved, the operator may perform confirmation operations, etc.

[0055] The log acquisition unit 212 acquires operation logs for a predetermined period (or a predetermined number of logs) before and after the measure (step S203).

[0056] The log classification unit 213 classifies the operation logs acquired in step S203 into confirmation operation logs and corrective operation logs (step S204).

[0057] The verification operation unit 214 uses the operation log classified in step S204 to determine whether additional verification operations are required (step S205). The verification operation unit 214 determines that additional verification operations are required if there are verification operations performed before the corrective action that were not performed after the corrective action; otherwise, it determines that additional verification operations are not required. For example, if verification operations A and B were performed before the corrective action, but only verification operation A was performed after the corrective action, the verification operation unit 214 determines that an additional verification operation (i.e., verification operation B) is required.

[0058] If it is determined in step S205 that additional verification operations are required, the verification operation unit 214 performs additional verification operations (step S206). As a result, verification information items for this verification operation are output.

[0059] The identification condition generation unit 215 generates identification conditions from the difference in the values ​​of the confirmation information items before and after the action operation (step S207). That is, the identification condition generation unit 215 generates identification conditions according to the following procedures 21 to 24.

[0060] Procedure 21: The identification condition generation unit 215 uses the operation logs classified in step S204 above to obtain confirmation information items for the pre-confirmation operation.

[0061] Procedure 22: The identification condition generation unit 215 uses the operation logs classified in step S204 above to obtain confirmation information items for the post-confirmation operation.

[0062] Step 23: If an additional verification operation was performed in step S206 above, the identification condition generation unit 215 obtains verification information items for this verification operation.

[0063] Step 24: The identification condition generation unit 215 identifies the difference between the value of the confirmation information item obtained in Step 21 and the value of the confirmation information item obtained in Step 22 or Step 23 between the same confirmation operations, and generates the confirmation operation and the conditions for identifying the difference as identification conditions.

[0064] For example, in the example shown in Figure 1, the difference between the value of the confirmation information item for operation log 1010 and the value of confirmation information item 1041 for operation log 1040 is identified. Similarly, the difference between the value of confirmation information item 1021 for operation log 1020 and the value of confirmation information item 1051 for operation log 1050 is identified. In this case, there is no difference between the value of confirmation information item 1021 and the value of confirmation information item 1051, and no confirmation information item is output for operation log 1010, so ultimately the value of confirmation information item 1041 is identified as the difference. Therefore, in the example shown in Figure 1, the confirmation operations represented by operation logs 1010 and 1040, and the condition indicating that there is no output for those confirmation operations are generated as identification conditions. Specifically, the identification condition is "the result of performing ps -ef | grep ' / usr / sbin / httpd -k start ' | grep -v grep' is that there is no output."

[0065] The data creation unit 216 creates an abstract event key from the event key of the event in question, and then creates event data using the abstract event key, the identification conditions generated in step S207, and the action operation represented by the action operation log included in the action log classified in step S204, and saves it to the event DB 205 (step S208). At this time, an ID for the event data is also generated.

[0066] <Summary> As described above, the network operation support device 10 according to one embodiment can generate information (identification conditions) for identifying an event when an event occurs in the target of action, using the operation log of the user, such as the operator, who took action against that event. Therefore, according to the network operation support device 10 according to one embodiment, the cost required to generate identification conditions is reduced, and it becomes possible to realize the automatic execution of action against events at a low cost.

[0067] The present invention is not limited to the embodiments specifically disclosed above, and various modifications, changes, and combinations with known technologies are possible without departing from the spirit of the claims.

[0068] 10 Network operation support device 101 Input device 102 Display device 103 External I / F 103a Recording medium 104 Communication I / F 105 RAM 106 ROM 107 Auxiliary storage device 108 Processor 109 Bus 201 Fault definition unit 202 Automatic execution determination unit 203 Recording processing unit 204 Automatic execution processing unit 211 Interface unit 212 Log acquisition unit 213 Log classification unit 214 Confirmation operation unit 215 Identification condition generation unit 216 Data creation unit

Claims

1. A device having a generation unit that, when a predetermined event occurs for the first time in a predetermined object, generates information for identifying the event in subsequent instances based on a log of a first operation for obtaining information about the event and a log of a second operation for resolving the event.

2. The apparatus according to claim 1, wherein the generation unit generates information for identifying the event based on the difference between the information obtained in the first operation before and after the second operation is performed.

3. The apparatus according to claim 2, wherein the generating unit identifies a first operation among the first operations performed before the second operation is performed that has not been performed after the second operation is performed, and after performing the identified first operation, generates information for identifying the event based on the difference.

4. A method by which a computer executes a generation procedure to generate information for identifying a predetermined event in the future, based on a log of a first operation to obtain information about the event and a log of a second operation to resolve the event, when a predetermined event occurs for the first time in a predetermined object.

Images