JP2009043029A - Related database creating device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a means for efficiently utilizing a database where failure information is accumulated since a person in charge of failure reception acquires failure information on the basis of information from an inquirer and obtains the information by listening when there is missing information in order to accumulate the failure information as achievements or acquires configuration information from the inquirer when a phenomenon that has occurred depends on the environment when a failure occurs in a conventional management system. <P>SOLUTION: Provided is a means for efficiently utilizing failure information by creating a related DB to be an intermediate DB which is used when retrieving similar cases and performing retrieval operation to the related DB. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention is a means for extracting known information of a system for registering an event that has occurred in an IT system.

  In the conventional management system, when a failure occurs, the failure reception staff acquires failure information based on the information from the inquirer in order to accumulate failure information as a record. Get information. In addition, regarding the phenomenon that occurs, if it is a problem that depends on the environment, configuration information is obtained from the inquirer.

  Regarding the stored fault information, the countermeasure that is a countermeasure for the phenomenon will be investigated, but similar fault cases may be stored in the fault management DB. Search for similar fault information. Search processing is performed by keyword matching search. For similar failure cases obtained from the search results, configuration information and the like are manually checked to narrow down candidates and determine validity. In the prior art, when a plurality of databases are managed, a method relating to a management recommendation has been provided.

JP 2006-277579 A

  Information obtained from the inquirer is vague and information is often insufficient. When the failure information is accumulated as a record, the shortage information is supplemented by the failure reception person, so that the information depends on the know-how of the reception person. In addition, investigation of failure cases requires a wide variety of information, and it is necessary to supplement the information.

  In the search when investigating the countermeasure as a countermeasure against the phenomenon that has occurred, the search and the registration are performed independently. As a search condition at that time, since a complete match search is performed using a keyword input by the user, there are many problems of display fluctuations, and there are many cases where an accurate similar failure case is not reached. In the prior art, the system name and the like are standardized, required items are provided, and the hit rate is increased by searching for sentences.

  When a keyword match search is performed for the failure management DB, there are similarities in the problem and phenomenon of acquiring multiple failure information that can be determined to be the same case, but the occurrence factors differ and can be regarded as noise It includes the problem that cases are also acquired. Since the same case is acquired as a plurality of search results, it is necessary to determine whether it is the same case each time. In addition, since cases where the generation factors are clearly different are acquired, it is necessary to verify the validity of the search results each time. As a result, the intended similar case is buried and it takes time to reach the countermeasure. In the prior art, the configuration information is confirmed and the validity of the search result is verified manually. However, this can be narrowed down to some extent using the configuration information.

  In many cases, the failure handling is performed by referring to the handling method of the past failure information when the failure information is sufficiently accumulated. However, when the system is changed, the failure handling is not always correct. For this reason, it is necessary to confirm whether or not the correct coping method is based on the difference in system configuration between the past fault information and the fault information that has occurred. In the past, these were performed manually.

  In order to search for similar failure cases, it is desirable that the accumulated information has little shortage information. Therefore, the missing information is complemented. Instead of confirming and entering the configuration information with the user who has failed, the confirmation items are limited to the host name. Then, the configuration information of the failure source is supplemented from the configuration management DB. Complementary means that a related item, that is, an application name, version information, a network configuration, and the like is acquired from the configuration management DB and registered as additional information from the host name.

  When searching for similar failure cases, the related words are expanded as search condition keywords, and the search is performed to deal with the problem of notation fluctuation, synonyms, and similar words. The phenomenon of failure information is a sentence that is stylized to some extent, but the word used may differ depending on the person in charge of the reception. Reduce search omissions. In the field of failure information, there are cases where a target is expressed by a host name, an IP address, a URL, or the like, and such information is also searched for as a similar word, thereby reducing acquisition omissions.

  In addition, a related DB, which is an intermediate DB used for searches and investigations, is created, and information on fault phenomena, countermeasures, factors and their relevance is stored in this DB. This eliminates the redundancy of the search results and manages a plurality of phenomena that may occur for the same configuration. Further, by holding only the configuration information related to the factor from the configuration information, it is possible to cope with a comparison such as a difference when the system is updated.

  When similar cases are found from past cases, similar failure cases are narrowed down using configuration information. The configuration information used for narrowing down is the factor configuration information that causes the phenomenon stored in the related DB and the configuration information of the failure case supplemented by the configuration management DB. For known cases, it has been found that there is a single piece of configuration information that can cause the phenomenon, or a combination as a competitive condition. In the related DB, this is stored as factor configuration information. By comparing the configuration information of the target in which the failure has occurred with the factor configuration information that is a configuration that may cause a past phenomenon obtained by keyword expansion search using a related word dictionary, the past phenomenon can be determined. It is possible to determine whether or not there is a relationship with the phenomenon in which the failure occurs.

  If past similar cases are not found in the search, it is judged as a new phenomenon, and it is necessary to investigate the countermeasure separately, so the failure information is registered in the investigation state. When it is determined that a countermeasure for a failure case registered in the investigation state is found, a similar countermeasure search is performed using keyword expansion using a related word dictionary to determine whether the countermeasure is known. If a similar measure cannot be acquired, the measure is registered in the related DB as a new measure, and the related DB is updated. If a similar countermeasure can be acquired, the relation of the countermeasure is updated. The related DB is expanded by performing the same operation on the updated related DB.

  The relation DB expanded in this way stores information on the phenomenon, countermeasures, and relations related to the failure information, and can be used for search, failure investigation, and the like.

  By applying the present invention, it is possible to efficiently extract cases when IT system occurrences are stored in the DB.

  Embodiments of the invention will be described with reference to the drawings.

  FIG. 1 shows the configuration of the present invention. A display device (101) having a registration display unit (103) for registering and displaying failure information read on the memory (102) and a countermeasure list display unit (104) is connected to a management device (101) via the network (107). 108). The memory (111) of the management device (108) includes a handling candidate search processing unit (112) that presents handling candidates from failure information, and a handling registration processing unit (113) that performs registration processing when the handling is confirmed. . The management device (108) is a failure management DB (115) in which individual failure information is stored, a configuration management DB (117) in which configuration information (118) to be managed is stored, and an intermediate DB used for searching and the like. A related DB (119) is connected. The related DB (119) stores a related word dictionary (120) and a related phenomenon (121).

  FIG. 2 shows a registration processing flow when a failure occurs in the configuration. This processing is processed by the handling candidate search processing unit (112). First, information received from the user is input by the person in charge of reception and registered as failure information. The failure information is managed in the form of a failure information table (FIG. 8). Interviews with configuration information or complements based on automatically acquired host name information. Specifically, the configuration information of the target in which the failure has occurred is searched using the host name as key information, and the information obtained from the user is complemented using the obtained configuration information (202). The configuration of the configuration information table stored in the configuration management DB (118) is shown in FIG. Using the information obtained by complementing the information obtained from the user from the configuration management DB (118), a countermeasure candidate is searched from the failure management DB (118) (203). The detailed search flow will be described later. If there is a similar phenomenon as a result of the search, a countermeasure list is presented to the user as a candidate for countermeasure (206). If there is no search result, a similar phenomenon does not exist in the failure management DB, so that it can be determined as an unknown phenomenon. In that case, the failure information that has occurred is stored in the failure management DB while being investigated (205).

  FIG. 3 shows a detailed flow of processing called from the target search (203) from the phenomenon. First, keywords are extracted on a word basis from information input as phenomena, and the keywords are expanded using the related word dictionary (121) of the related DB (302). The keyword to be expanded is acquired from information stored in the similar word table (FIGS. 10 and 11). The expanded keyword is set as an OR condition (303), and a keyword match search is performed on the phenomenon table of the related DB (120) (304). For example, when the inspection keyword “host name + doesn't work” is acquired, the search condition is (“host (host name)” or “192.168.0. **” using the post-similar table (FIGS. 10 and 11). "Or" http: // **** "or ...) and (" doesn't work "or" stops "or" no response "or ...). By performing a search under such a search condition, cases such as “host is stopped”, “no response of 192.168.0. **”, and the like can be acquired as search results. It is determined whether or not this search result can be obtained (305). If a similar phenomenon can be acquired, a countermeasure ID list is acquired using the phenomenon / occurrence condition mapping table (FIG. 16) and the occurrence condition / response mapping table (FIG. 17) (306). The countermeasure list acquired at this point is a candidate for countermeasure from the viewpoint of the phenomenon. This is narrowed down from the viewpoint of composition by comparing the factor composition that causes the phenomenon and the offense in which the phenomenon occurred (307). This detailed flow will be described with reference to FIG. As a result of the narrowing down, it is determined whether there is a handling candidate (308). If there is a handling candidate, the handling is presented to the user in the form of a handling list in FIG. 13 (310). If there is no coping candidate, it is determined that there is no similar case, and the case is registered in the state under investigation whose coping is unknown in the format of FIG. 8 (309).

  FIG. 4 shows a detailed flow of processing called from the countermeasure candidate narrowing (307). Since there is a possibility that a plurality of handling candidates can be acquired, the first handling candidate is acquired (402). From the acquired countermeasure candidates, using the occurrence condition / countermeasure mapping table (FIG. 17) and the occurrence condition / factor configuration mapping table (FIG. 18), the factor configuration (FIG. 14) associated with the countermeasure is acquired (403). ). In the factor configuration (FIG. 14), there may be a case where there is a factor that causes a failure in a single component or a case where a plurality of factor configurations compete. It is determined whether the factor configuration is single or multiple conflicts (404), and the component that occurs independently can be determined by matching with a specific type of configuration information in which the phenomenon occurs (405). If there are a plurality of factor configurations, matching is performed for all the factor configurations (406). As for matching, matching is performed in the order of network information, server information, OS information, driver information, middleware information, and AP information with a high degree of failure impact classified in FIG. The matching condition for each element is that the version information is equal to or less than the factor configuration information when the component name matches and the version information exists. Then, whether or not matching is possible is determined (407). If matching is established, it can be determined that the handling candidate is appropriate in terms of configuration, and the presented handling candidate is acquired in the form of the list of FIG. 13 (409). When matching is not established, it can be determined that the countermeasure is inappropriate from the viewpoint of configuration, and is not acquired as a candidate for countermeasure. Then, it is determined whether there is another factor configuration related to the countermeasure (408). If there is, the same matching operation is performed on another factor configuration related to the countermeasure. When matching operation is performed for all factor configurations, the same operation is performed for the next coping candidate. In this way, it is possible to narrow down all the handling candidates from the viewpoint of configuration. For example, assume that the configuration information in which the phenomenon has occurred is OS1 (OS information), AP1 (UP information), and AP2 (AP information). If the search result handling candidate is related only to the factor configuration “AP3 (UP information)” or only the factor configuration “OS1 + AP3”, it is determined that the handling candidate is not appropriate. . In addition, since the handling candidate related to the factor configuration “OS1” and the handling candidate related to the factor configuration “AP1 + AP2” may be appropriate handling, it is determined that the handling candidate is appropriate as the handling candidate.

  FIG. 5 shows a flow when the countermeasure information is found in the failure information DB registered in the investigation. This processing is processed by the handling registration processing unit (113). First, in order to determine whether the phenomenon is a known phenomenon, a similar phenomenon is searched (502). Details of the processing will be described later with reference to FIG. If there is no similar phenomenon, the phenomenon is unknown and new registration is performed in the related DB (504). If a similar phenomenon exists, the new phenomenon is not registered because the phenomenon is already known. A search for similar measures is performed regarding measures (505). Details of the processing will be described later with reference to FIG. A known or unknown decision is made, and if it is unknown, a new registration is made in the form of FIG. 13 (507). Then, the occurrence condition of the phenomenon such as the reproduction procedure is registered in the format of FIG. 15 (508). Further, the factor configuration (FIG. 14) is registered (509), and the mapping table is updated (510). The factor configuration is stored in the format of a factor configuration table (FIG. 14). The factor information table (FIG. 14) includes a factor configuration ID (1401), a target name (1402), and configuration information (1403). In the configuration information (1403), only the configuration information directly causing the phenomenon is stored, and the configuration information unrelated to the cause of the phenomenon is not stored.

  A search flow for similar phenomena is shown in FIG. The processing starts from the similar phenomenon search (502) of FIG. 5 (601). First, the inputted phenomenon keyword is acquired (602). Then, a match search is performed to determine whether the acquired keyword exists in the related word dictionary (603). A match search is performed for each keyword to determine whether it exists in the related word dictionary (604). If it exists, it is acquired as an extended keyword for searching (605). If not present, the keyword is not expanded. The keyword thus obtained is designated as an OR condition (606). Based on the generated search condition, a match search of the phenomenon table is performed to obtain the result (608).

  FIG. 7 is a search flow for similar measures. The processing is started from the similarity countermeasure search (505) in FIG. 5 (701). First, the inputted phenomenon keyword is acquired (702). Then, a matching search is performed to determine whether the acquired keyword exists in the related word dictionary (703). A match search is performed for each keyword to determine whether it exists in the related word dictionary (704). If it exists, it is acquired as an extended keyword for searching (705). If not present, the keyword is not expanded. The keyword thus obtained is designated as an OR condition (706). Based on the generated search condition, a matching table is searched for a match and a result is obtained (708).

  A series of operations is performed using the related DB (120) thus expanded.

  A failure management table for managing failure information is shown in FIG. The failure information table manages information such as the phenomenon and countermeasure, the host name and configuration information of the target, the importance of the failure, and the like. Host name information serving as a search key and configuration information when a failure occurs are also stored in this failure information table.

  A configuration management table for managing configuration management information is shown in FIG. The configuration information table (FIG. 7) stores installed software, version, patch information, manufacturer, and the like for each type when the management target is a specific machine. The configuration information is stored in a state representing the correlation of each configuration, and by referring to this configuration information table (FIG. 7), it is possible to estimate the influence range when a failure occurs. This configuration management DB is searched with the input host name, and all configuration information is acquired from the configuration information (119) and stored as failure information.

  The similar word table stored in the configuration management DB (118) is shown in FIGS. The post-similar table is composed of pairs of representative words (1001, 1102) and similar words (1002, 1102). The types of stored words are classified into those that can be judged as similar words in terms of meaning (FIG. 10) and those that can be judged as similar words in the field of fault information (FIG. 11). Since information such as the host name may be expressed by IP or URL, similar word information acquired from the configuration management DB (118) is also stored in the related word dictionary (121).

  The phenomenon is stored in the form of a phenomenon table (FIG. 12). The phenomenon table includes a phenomenon ID (1201) used for the phenomenon mapping table used for the mapping table and a phenomenon (1202) of specific phenomenon contents.

  The countermeasure is stored in the form of a countermeasure table (FIG. 13). The countermeasure table includes a countermeasure ID used in the mapping table, a countermeasure (1302) which is a specific countermeasure, and a factor (1303) which the countermeasure solves. The factor (1303) is the target of the extended keyword search.

  FIG. 14 shows a factor configuration table. This factor configuration table stores configuration information that causes a failure. The table configuration is the factor configuration ID (1401) used in the mapping table. When a failure occurs, the configuration information (1403) is classified and stored in the same manner as the configuration information table (FIG. 7). Is done. The difference from the configuration information table (FIG. 7) is that the configuration information table (FIG. 7) stores all the configuration information constituting the object, whereas the cause configuration table (FIG. 14) relates to the occurrence of a failure. Only possible configuration information is stored.

  A series of operations are repeated based on the related DB thus expanded.

FIG. Processing flow when a phenomenon occurs. Processing candidate search processing flow. Narrowing candidate flow. Processing flow at the time of finding out what to do. Similarity phenomenon search flow. Similarity search flow. Fault information table. Configuration management table. Related word dictionary table 1. Related word dictionary table 2. Symptom table. Action table. Factor configuration table. Occurrence condition table. Phenomenon / occurrence condition mapping table. Occurrence condition / action mapping table. Occurrence condition / factor configuration mapping table.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 101 ... Display apparatus, 102 ... Memory, 103 ... Registration display part, 104 ... Action list display part, 105 ... Processor, 106 ... Communication interface, 107 ... Network, 108 ... Management apparatus, 109 ... Communication interface, 110 ... Processor, 111 ... Memory, 112 ... Coping candidate search processing unit, 113 ... Coping registration processing unit, 114 ... Disk interface, 115 ... Fault management DB, 116 ... Fault information, 117 ... Configuration management DB, 118 ... Configuration information, 119 ... Related DB, 120 ... Related word dictionary, 121 ... Related phenomenon.

Claims (3)

  A data structure generation method for associating configuration management data for managing a machine configuration of a management system and fault information data for managing fault information generated in the management system.   A method of associating a failure newly generated in the management system with failure information data recorded as a record in the management system.   A search condition that determines that new failure information newly generated in the management system and failure information data recorded as a record in the management system are the same information using similar language data that stores a set of similar languages Extension method.

Images