System, method, and computer program for automatic parser creation

Abstract

The present disclosure describes a system, method, and computer program for automatically creating a parser for a log group. A parser-creation system groups logs that do not satisfy conditions for an existing parser, enables a user to select a log group for parser creation, and automatically creates a parser for the selected log group. In creating a parser, the system extracts values and keys value pairs from the log group and identifies the corresponding normalized output fields and regular expressions for the values and key-value pairs. To identify normalized fields corresponding to values and key-value pairs, the system compares the values and key-value pairs to one or more knowledgebases that include: (1) regular expressions from existing parsers, (2) regular expressions for value types associated with normalized fields, and (3) a list of keys in key-value pairs associated with normalized fields. As the system learns new token-to-normalized fields relationships, the system adds the relationships to its knowledgebase.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to computer parsers, and, more specifically, to automatically creating a parser for a group of raw event logs.

2. Description of the Background Art

Enterprise IT products generate a large variety and volume of event logs with data related to user activities in a network. For example, Microsoft's Active Directory (AD) records user-to-machine authentication events in AD domain controllers on a Windows environment; firewall security products generate alerts for user activities crossing the network perimeter; and endpoint products track file actions such as file deletion and creation, etc.

Various systems may use the event logs to manage an IT network. For instance, event logs are used by cybersecurity systems to detect potential cyberthreats to an IT network. A user-and-entity behavior analytics system (UEBA) uses event logs to create models of an entity's behavior in an IT network and determine when an enmity's behavior deviates from the norm. An example of a UEBA cybersecurity monitoring system is described in U.S. Pat. No. 9,798,883 issued on Oct. 24, 2017 and titled “System, Method, and Computer Program for Detecting and Assessing Security Risks in a Network,” the contents of which are incorporated by reference herein.

Log formats can vary significantly across different IT vendors. For example, the following tokens may all relate to a user ID:

• • “User_id=Luke”
  • “Account=Kylo”
  • “Login_id=Finn”
  • “UserName=Rey”
  • “Account Login=Han”

The log data must be normalized before it can be used by a cybersecurity system or other system that uses log data from multiple sources. As a result, systems that use a variety of event logs rely on parsers that extract values or key/value pairs from raw event logs and normalize the data (i.e., for each log, the parser generates a message with normalized fields and format for the log data). For example, parsers could normalize the above example tokens as follows:

• • “user=Luke”
  • “userKylo”
  • “user=Finn”
  • “user=Rey”
  • “user=Han”

Parsers are created manually, and this is a time-consuming process. Companies that process raw event logs from numerous sources often employ large teams that are dedicated to creating parsers. Therefore, there is a demand for a more automated method for creating parsers that normalize log data.

SUMMARY OF THE DISCLOSURE

The present disclosure describes a system, method, and computer program for identifying log groups in need of a parser and for automatically creating a parser for a log group. A parser-creation system loads a plurality of logs and analyzes each log to determine whether the log matches conditions for an existing parser. If the log matches the conditions for an existing parser, the system associates the log with the applicable parser.

The system tokenizes logs that do not satisfy conditions for an existing parser, and groups logs based on token patterns. The system displays the log groups in a user interface and enables a user to select a log group for parser creation. The system also enables a user to associate a vendor and event type with the log group.

In response to the system receiving a user selection of a log group and the associated vendor and event type, the system begins the automated parser creation process. The system creates conditions for the parser based on literals common to each log in the group. This will enable the system to identify future logs that should be associated with this parser.

The system obtains the tokens (i.e., values and key/value pairs) from the log group and identifies a plurality of normalized fields that correspond to tokens in the log group. The system then maps each of the identified normalized field to a regular expression and an example token from the log group. The system also identifies any required fields for the parser based on the event type.

The system provides a user interface that enables the user to view the mapping of identified normalized fields to regular expressions and example tokens. The system also displays an indication of which of the identified normalized fields in the mapping are required for the parser. Moreover, if there are any required fields for the parser that are not included in the mapping, these required fields are also displayed in the user interface.

The system enables a user to modify and add to the mapping of identified normalized fields to regular expressions and example tokens. In response to a user confirming the mapping, the system creates a parser for the log group based on the mappings. The system associates the parser with a vendor and event type, as well as the conditions created for the parser.

In certain embodiments, the system identifies the normalized fields for the parser by comparing the tokens to a number of knowledgebases. The system compares each of the tokens to a first knowledgebase of regular expressions associated with normalized fields based on existing parsers accessible to the system. In response to a token satisfying one of the regular expressions in the first knowledgebase, the system determines that the token corresponds to the normalized field associated with the satisfied regular expression.

For each token that does not satisfy one of the known regular expressions in the first knowledgebase, the system ascertains whether the token includes (1) a key in a second knowledgebase of key names known to be associated with normalized fields used by the system, or (2) a value that satisfy a regular expression for a value type in a third knowledgebase of regular expressions for value types known to be associated with normalized fields used by the system. In response to the token including a key or a value type associated with a normalized field used by the system, the system concludes that the token corresponds to said normalized field.

In certain embodiments, if a token corresponds to a regular expression in one of the knowledgebases, then the normalized fields associated with the token is mapped to the regular expression satisfied by the token. Otherwise, the system autogenerates a regular expression for the token and maps the normalized field associated with the token with the generated regular expression. In addition, the system increases it knowledge by adding new normalized field-to-regular expression mappings to the first knowledgebase.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A-1C are flowcharts that illustrate a method, according to one embodiment, for identifying log groups in need of a parser and for automatically creating a parser for a selected log group.

FIGS. 2A-2B are flowcharts that illustrate a method, according to one embodiment, for identifying the normalized fields that correspond to tokens in a log group.

FIGS. 3A-3B are flowcharts that illustrate a method, according to one embodiment, for mapping an identified normalized field to a regular expression.

FIG. 4 is a block diagram that illustrates an example software architecture for a parser-creation system according to one embodiment.

FIG. 5A is a screenshot that illustrates an example user interface, according to one embodiment, that displays a mapping of normalized fields to regular expressions and example tokens.

FIG. 5B is a screenshot that illustrates definitions for the symbols in the status field in FIG. 5A.

FIG. 6 is a screenshot that illustrates an example user interface, according to one embodiment, for enabling a user to add to the mapping of normalized fields to regular expressions and example tokens.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present disclosure describes a system, method, and computer program for identifying log groups in need of a parser and for automatically creating a parser for a log group. Specifically, the disclosure relates to a system that groups logs that do not satisfy conditions for an existing parser, enables a user to select a log group for parser creation, and automatically creates a parser for the selected log group. In creating a parser, the system extracts values and key/value pairs from the log group and identifies the corresponding normalized output fields and regular expressions for the values and key-value pairs. The method is performed by a computer system, referred to herein as “the system” or the “parser-creation system.” In one embodiment, the parsers created by the system are used by a cybersecurity system to parse logs and normalize the information in logs generated by various systems within an IT network.

A method for identifying log groups in need of a parser and for automatically creating a parser for a selected log group is described below with respect to FIG. 1.

1. Grouping Logs and Enabling a User to Select a Log Group for Parser Creation Referring to FIGS. 1A-1C, the parser-creation system loads a plurality of logs and analyzes each log to determine whether the log matches conditions for an existing parser (steps 110, 115). The conditions for a parser are literals (i.e., tokens and/or text) that must exist in a log. If the log matches the conditions for an existing parser, the system associates the log with the applicable parser (120).

The system then proceeds to group logs that do not satisfy the conditions of an existing parser. To do so, the system first tokenizes the logs (step 125). Tokens are key-value pairs or values in the logs, and tokenizing a log means identifying the key-value pairs and/or values in the log. In one embodiment, tokenizing a log comprises ascertaining whether the log has a known log format. If so, the system removes any header and tokenizes the log in accordance with the known log format. If not, the system tokenizes the log by identifying the delimiters and the key-value pairs format.

The system then groups the logs based on token patterns (step 130). In one embodiment, logs whose tokens overlap by 50% or more are grouped together. The result of the grouping is that logs from the same vendor and for the same event type are in the same group.

The system displays the log groups in a user interface and enables the user to select a log group for parser-creation (steps 135, 140). In response to receiving a user selection of a log group, the system also enables the user to select a vendor and event type for the log group (steps 145, 150). For example, the system may first display a list of vendors known to provide IT-related logs, and, in response to a user selecting a vendor, the system displays the type of events for which the vendor is known to generate logs and enables the user to choose one of the event types.

2. Creating Conditions for a Parser for a Selected Log Group

In response to the system receiving a user selection of a log group and the associated vendor and event type, the system begins the automated parser creation process. The system creates conditions for the parser based on literals common to each log in the group (step 155). This will enable the system to identify future logs that should be associated with this parser.

3. Identifying Required Normalized Fields for the Parser

For logs meeting the conditions for the parser, the parser must be able to parse the logs for any output fields required for the associated event by the cybersecurity or other system that will be using the log data. Consequently, the parser-creation system identifies any required normalized fields for the parser based on the event type associated with the parser (step 160). Normalized fields are the keys in the output messages that will be generated by the parser being created. In other words, they are the output fields in the messages generated by the parser.

In one embodiment, the system identifies the required fields by creating a superset of normalized fields extracted in all pre-existing parsers accessible to the system for the same event type and then identifying the normalized fields in the superset that are common to all the preexisting parsers for the same event type. In an alternate embodiment, each event type is associated with a list of required normalized fields for the event type.

4. Identifying the Normalized Fields that Correspond to Tokens in the Log Group

The system identifies the tokens in the log group (step 165). As discussed above, each log in the group was previously tokenized, and identifying the tokens for the log group comprises aggregating the tokens of the individual logs in the log group.

The system then identifies a plurality of normalized fields that correspond to tokens in the log group (step 170). The identified normalized fields may include both required fields and optional fields for the event type. Identifying the normalized fields that correspond to the tokens comprises comparing the tokens to: (1) regular expressions in existing parsers accessible to the system, (2) regular expressions for value types associated with normalized fields in the system, and (3) a list of keys in key-value pairs associated with normalized fields in the system. FIGS. 2A-2B illustrate a more detailed example of this process. As shown in the figure, the system selects a token from the log group and compares the token to a first knowledgebase of regular expressions from existing parsers accessible to the system (step 220). The first knowledgebase comprises a mapping of regular expressions for tokens to normalized fields. The first knowledgebase is automatically derived by the system by extracting mappings of regular expression to normalized fields from existing parsers. In other words, the first knowledgebase reflects the system's knowledge based on previous parsers created by the system or otherwise loaded into the system. The first knowledgebase may be seeded initially with a set of “starter parsers” that are loaded into the system. As described below, the first knowledgebase grows as the system creates new parsers and learns new token-to-normalized field correlations.

The system determines whether the token satisfies a regular expression in the first knowledgebase (i.e., a regular expression used in an existing parser) (step 230). In response to the token satisfying a regular expression in the first knowledgebase, the system determines that the token corresponds to the normalized field to which the satisfied regular expression is mapped in the first knowledgebase (step 240).

If the token does not satisfy a regular expression in the first knowledgebase, the system determines whether the token includes a key known to be associated with a normalized field. Specifically, the system compares the token to a second knowledgebase of token keys mapped to normalized fields (step 245). In certain embodiments, the second knowledgebase is based on industry/expert knowledge of keys known to correspond to normalized fields. In response to determining that a key in the token matches a key in the second knowledgebase, the system concludes that the token corresponds to the normalized field associated with the matching key in the second knowledgebase (steps 250, 260).

If the token neither satisfies a regular expression in the first knowledgebase, nor matches a key in the second knowledgebase, the system determines whether the token satisfies a regular expression for a value type associated with normalized fields in the system. Specifically, the system compares the token to a third knowledgebase of regular expressions for value types associated with normalized fields (step 265). In certain embodiments, the third knowledgebase is based on industry/expert knowledge of value types known to correspond to normalized fields. In response to determining that the token satisfies a regular expression in the third knowledgebase for a value type, the system concludes that the token corresponds to the normalized field associated with the value type (steps 270, 275).

If the token neither satisfies a regular expression in the first or third knowledgebases, nor includes a key in the second knowledgebase, the system does not match the token to a normalized field at this time (step 280). The method repeats until all the tokens in the log group have been processed (steps 285, 215). If a normalized field is identified from a token, then the system may map the identified normalized field to a regular expression, as discussed below, before proceeding to process the next token in step 215.

In certain embodiments, the first, second, and third knowledgebases are a suite of libraries. They may be separate libraries or subsections of the same library.

5. Mapping the Identified Normalized Fields to Regular Expressions and Example Tokens

The system maps each of the identified normalized fields to a regular expression (step 175). More specifically, each normalized field identified in step 160 is mapped to a regular expression for the token corresponding to the field. The system also maps each of the identified normalized fields to an example token (from the log group) corresponding to the normalized field. The example token may be selected in a number of ways. For example, the system may randomly select the token from a group of tokens corresponding to the normalized field, or it may select the first token on a list of tokens (from the log group) corresponding to the normalized field.

FIGS. 3A-3B illustrate a method for mapping an identified normalized field to a regular expression. If the normalized field corresponds to a token that satisfies a regular expression in the first knowledgebase, then, for purposes of the mapping of step 165, the normalized field is mapped to the regular expression satisfied by the token (steps 320, 330). If the normalized field corresponds to a token that matches a key in the second database, the system creates a regular expression for the token and maps the normalized field to the new regular expression (steps 340, 350). The system also add the new normalized field-to-regular expression mapping to the first knowledgebase (step 360). If the normalized field corresponds to a token that satisfies a regular expression for a value type in the third knowledgebase, then the normalized field is mapped to the regular expression satisfied by the token (step 370). This new mapping is added to the first knowledgebase (step 375). As shown with steps 360 and 375, the system learns over time and increases it knowledge of how tokens correspond to normalized fields. The method is repeated for each normalized field identified for the log group (steps 360, 315).

6. Enabling User to Edit Normalized Fields and Regular Expressions Identified for the Log Group

The system provides a user interface that enables the user to view the mapping of identified normalized fields to regular expressions and example tokens (step 180). The system also displays an indication of which of the identified normalized fields are required for the parser. For example, required fields may be denoted with a symbol or other graphic feature. Moreover, if there are any required fields for the parser that are not included in the mapping, these required fields are also displayed in the user interface.

FIG. 5A illustrates an example of the user interface generated in step 180. The field column 510 lists the normalized fields identified or required for the parser. The key and value columns 520, 530 list example key-value tokens corresponding to the normalized fields in column 510. For fields with value-only tokens, then the key column 520 is blank. The pattern column 540 lists the regular expressions mapped to the normalized fields in column 510. The status column 505 lists the status associated with each of the normalized fields displayed in the user interface. FIG. 5B illustrate a window that appears when a user hovers over a status symbol. The window illustrates the meaning of each symbol (e.g., whether the corresponding normalized field is required or optional and whether an example token and regular expression was mapped to the field).

In certain embodiments, the system also provides a user interface in which a user can view a list of all the tokens for the log group and the normalized fields matched to each token. Such views allow a user to confirm that matchings are correct, as well as to see any tokens from the log group not matched to a normalized field. The system may also enable a user to review and edit conditions for the log group.

The system enables the user to edit the mapping of identified normalized fields to regular expressions and example tokens (step 185). This includes being able to modify the mappings for identified normalized fields, being able to add regular expressions and example tokens for unmatched required fields, and being able to add normalized fields and regular expressions to unmatched tokens. FIG. 6 illustrates an example of a way a user can add to the mapping. In this embodiment, the user can view one or more logs from the log group and highlight any token with the log group. As shown in FIG. 6, the user can assign a normalized a field and a field type (e.g., value or key/value) to a highlighted token. For example, in FIG. 6, the user has assigned the highlighted token “Computer Name=10.10.0.9” (630) to the field “host” (610) and the field type “key/value” (620). When the user selects the “create” button, the system auto-generates a regular expression for the highlighted token and adds the assigned normalized field and regular expression to the mapping. The highlighted token is used as the example token for the normalized field. This regular expression-to-normalized field match is also added to the first knowledgebase base, thereby enabling the system to learn from the user's edits.

7. Creating a Parser

The user interface includes a call-to-action that enables a user to indicate that the displayed normalized fields and corresponding regular expressions are acceptable and to initiate the final parser creation step. For example, the user interface may include a “create parser” button or the like. In response to a user selecting the call-to-action, the system creates a parser for the log group based on the mapping of the normalized fields to regular expressions (as modified by the user if applicable) (step 190). The system associates the created parser with the vendor and event type selected for the log group. Also, the system associates the parser with the conditions for the log group.

8. Example Software Architecture

FIG. 4 illustrates an example system architecture for performing the methods described herein. The methods described herein may be implemented in a system configured differently and are not limited to the system architecture illustrated in FIG. 4.

A log loader module 420 loads raw event logs 410 into the system 400. The log grouper module 420 groups logs as described above, and a parser-creation module 430 creates a parser for a selected group of raw logs in accordance with the methods of FIGS. 1-3. To identify the normalized fields corresponding to tokens in a log group, the parser-creation module accesses the first, second, and third knowledgebases 470, 480, and 490, which collectively include (1) regular expressions in existing parsers accessible to the system (470), (2) regular expressions for value types associated with normalized fields in the system (490), and (3) a list of keys in key-value pairs associated with normalized fields in the system (480). The user interface generation module 440 generates the user interfaces discussed above. Created parsers are added to parser database 415.

8. General

The methods described herein are embodied in software and performed by one or more computer systems (each comprising one or more computing devices) executing the software. A person skilled in the art would understand that a computer system has one or more memory units, disks, or other physical, computer-readable storage media for storing software instructions, as well as one or more processors for executing the software instructions. All illustrated screen shots and user interfaces are examples and not limiting of the invention.

As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Accordingly, the above disclosure is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

Claims

1. A method, performed by a computer system, for creating a parser for a log group that parses and normalizes log data, the method comprising: loading a plurality of logs into the system;for each log in the plurality of logs, determining whether the log satisfies conditions for an existing parser;in response to a log satisfying conditions for an existing parser, associating the log with said existing parser;tokenizing logs that do not satisfy conditions for an existing parser;grouping the logs that do not satisfy conditions for an existing parser to create one or more log groups, wherein the logs are grouped based on token patterns;displaying the log groups in a first user interface and enabling a user to select a log group for parser creation;receiving a user selection of a log group for parser creation;enabling the user to select a vendor and an event type for the selected log group;receiving the user selection of a vendor and event type for the selected log group;creating a parser for the selected log group, wherein creating the parser comprises: creating conditions for the parser based on literals common to each log in the log group;identifying any required normalized fields for the parser based on the event type;identifying tokens for the selected log group;identifying a plurality of normalized fields that correspond to the tokens in the selected log group, wherein identifying a plurality of normalized fields comprises: comparing each of the tokens to a first knowledgebase of regular expressions associated with normalized fields based on existing parsers accessible to the system,in response to a token satisfying one of the regular expressions in the first knowledgebase, determining that the token corresponds to the normalized field associated with the satisfied regular expression,in response to the token not satisfying one of the regular expressions in the first knowledgebase, determining whether the token includes a key in a second knowledgebase of known key names associated with normalized fields used by the system, and, wherein for at least one token that does not satisfy one of the regular expressions in the first knowledgebase, determining whether the token includes a value that satisfies a regular expression for a value type in a third knowledgebase of regular expressions for value types associated with normalized fields used by the system, wherein the first knowledgebase, second knowledgebase, and third knowledgebase are separate libraries, andin response to the token including a key or a value type associated with a normalized field used by the system, determining that the token corresponds to said normalized field;mapping each of the identified normalized fields to a regular expression and an example token from the log group;providing a second user interface that enables a user to view the mapping of identified normalized fields to regular expressions and example tokens, wherein the user interface includes an indication of which of the identified normalized fields are required fields for the parser and wherein the user interface also displays any required normalized field not mapped to a regular expression and an example token;enabling a user to modify and add to the mapping of identified normalized fields to regular expressions and example tokens; andcreating a parser for the log group based on the mapping, wherein the parser is associated with the vendor and event type selected by the user, as well as the conditions for the log group.

2. The method of claim 1, wherein mapping an identified normalized field to a regular expression comprises the following: in response to the identified normalized field corresponding to a token that satisfies one of the regular expressions in the first knowledgebase, mapping the identified normalized field to the regular expression satisfied by the token;in response to the identified normalized field corresponding to a token that satisfies one of the regular expressions in the third knowledgebase, mapping the identified normalized field to the regular expression satisfied by the token and adding the mapping of the identified normalized field to said regular expression to the first knowledgebase;in response to the identified normalized field corresponding to a token that is not satisfied by a regular expression in the first or third knowledgebase, but includes a key associated with a normalized field used by the system, creating a regular expression for the corresponding token, mapping the identified normalized field to the created regular expression, and adding the mapping of the identified normalized field to the created regular expression to the first knowledge base of known regular expressions.

3. The method of claim 1, wherein identifying required normalized fields for the parser comprises the following: identifying pre-existing parsers accessible to the system for the same event type as the event type selected by the user for the log group;obtaining a superset of normalized fields extracted in all the pre-existing parsers for the same event type; andidentifying the normalized fields within the superset that are common to all the preexisting parsers for the same event type as the required normalized fields for the parser.

4. A non-transitory computer-readable medium comprising a computer program that, when executed by a computer system, enables the computer system to perform the following method for creating a parser for a log group that parses and normalizes log data, the method comprising: loading a plurality of logs into the system;for each log in the plurality of logs, determining whether the log satisfies conditions for an existing parser;in response to a log satisfying conditions for an existing parser, associating the log with said existing parser;tokenizing logs that do not satisfy conditions for an existing parser;grouping the logs that do not satisfy conditions for an existing parser to create one or more log groups, wherein the logs are grouped based on token patterns;displaying the log groups in a first user interface and enabling a user to select a log group for parser creation;receiving a user selection of a log group for parser creation;enabling the user to select a vendor and an event type for the selected log group;receiving the user selection of a vendor and event type for the selected log group;creating a parser for the selected log group, wherein creating the parser comprises: creating conditions for the parser based on literals common to each log in the log group;identifying any required normalized fields for the parser based on the event type;identifying tokens for the selected log group;identifying a plurality of normalized fields that correspond to the tokens in the selected log group, wherein identifying a plurality of normalized fields comprises: comparing each of the tokens to a first knowledgebase of regular expressions associated with normalized fields based on existing parsers accessible to the system,in response to a token satisfying one of the regular expressions in the first knowledgebase, determining that the token corresponds to the normalized field associated with the satisfied regular expression,in response to the token not satisfying one of the regular expressions in the first knowledgebase, determining whether the token includes a key in a second knowledgebase of known key names associated with normalized fields used by the system, and, wherein for at least one token that does not satisfy one of the regular expressions in the first knowledgebase, determining whether the token includes a value that satisfies a regular expression for a value type in a third knowledgebase of regular expressions for value types associated with normalized fields used by the system, wherein the first knowledgebase, second knowledgebase, and third knowledgebase are separate libraries, andin response to the token including a key or a value type associated with a normalized field used by the system, determining that the token corresponds to said normalized field;mapping each of the identified normalized fields to a regular expression and an example token from the log group;providing a second user interface that enables a user to view the mapping of identified normalized fields to regular expressions and example tokens, wherein the user interface includes an indication of which of the identified normalized fields are required fields for the parser and wherein the user interface also displays any required normalized field not mapped to a regular expression and an example token;enabling a user to modify and add to the mapping of identified normalized fields to regular expressions and example tokens; andcreating a parser for the log group based on the mapping, wherein the parser is associated with the vendor and event type selected by the user, as well as the conditions for the log group.

5. The non-transitory computer-readable medium of claim 4, wherein mapping an identified normalized field to a regular expression comprises the following: in response to the identified normalized field corresponding to a token that satisfies one of the regular expressions in the first knowledgebase, mapping the identified normalized field to the regular expression satisfied by the token;in response to the identified normalized field corresponding to a token that satisfies one of the regular expressions in the third knowledgebase, mapping the identified normalized field to the regular expression satisfied by the token and adding the mapping of the identified normalized field to said regular expression to the first knowledgebase;in response to the identified normalized field corresponding to a token that is not satisfied by a regular expression in the first or third knowledgebase, but includes a key associated with a normalized field used by the system, creating a regular expression for the corresponding token, mapping the identified normalized field to the created regular expression, and adding the mapping of the identified normalized field to the created regular expression to the first knowledge base of known regular expressions.

6. The non-transitory computer-readable medium of claim 4, wherein identifying required normalized fields for the parser comprises the following: identifying pre-existing parsers accessible to the system for the same event type as the event type selected by the user for the log group;obtaining a superset of normalized fields extracted in all the pre-existing parsers for the same event type; andidentifying the normalized fields within the superset that are common to all the preexisting parsers for the same event type as the required normalized fields for the parser.

7. A computer system for creating a parser for a log group that parses and normalizes log data, the system comprising: one or more processors;one or more physical memory units coupled to the one or more processors, wherein the one or more memory units store instructions that, when executed by the one or more processors, cause the system to perform the operations of: loading a plurality of logs into the system;for each log in the plurality of logs, determining whether the log satisfies conditions for an existing parser;in response to a log satisfying conditions for an existing parser, associating the log with said existing parser;tokenizing logs that do not satisfy conditions for an existing parser;grouping the logs that do not satisfy conditions for an existing parser to create one or more log groups, wherein the logs are grouped based on token patterns;displaying the log groups in a first user interface and enabling a user to select a log group for parser creation;receiving a user selection of a log group for parser creation;enabling the user to select a vendor and an event type for the selected log group;receiving the user selection of a vendor and event type for the selected log group;creating a parser for the selected log group, wherein creating the parser comprises: creating conditions for the parser based on literals common to each log in the log group;identifying any required normalized fields for the parser based on the event type;identifying tokens for the selected log group;identifying a plurality of normalized fields that correspond to the tokens in the selected log group, wherein identifying a plurality of normalized fields comprises: comparing each of the tokens to a first knowledgebase of regular expressions associated with normalized fields based on existing parsers accessible to the system,in response to a token satisfying one of the regular expressions in the first knowledgebase, determining that the token corresponds to the normalized field associated with the satisfied regular expression,in response to the token not satisfying one of the regular expressions in the first knowledgebase, determining whether the token includes a key in a second knowledgebase of known key names associated with normalized fields used by the system, and, wherein for at least one token that does not satisfy one of the regular expressions in the first knowledgebase, determining whether the token includes a value that satisfies a regular expression for a value type in a third knowledgebase of regular expressions for value types associated with normalized fields used by the system, wherein the first knowledgebase, second knowledgebase, and third knowledgebase are separate libraries, andin response to the token including a key or a value type associated with a normalized field used by the system, determining that the token corresponds to said normalized field;mapping each of the identified normalized fields to a regular expression and an example token from the log group;identifying any required normalized fields for the parser based on the event type;providing a second user interface that enables a user to view the mapping of identified normalized fields to regular expressions and example tokens, wherein the user interface includes an indication of which of the identified normalized fields are required fields for the parser and wherein the user interface also displays any required normalized field not mapped to a regular expression and an example token;enabling a user to modify and add to the mapping of identified normalized fields to regular expressions and example tokens; andcreating a parser for the log group based on the mapping, wherein the parser is associated with the vendor and event type selected by the user, as well as the conditions for the log group.

8. The system of claim 7, wherein mapping an identified normalized field to a regular expression comprises the following: in response to the identified normalized field corresponding to a token that satisfies one of the regular expressions in the first knowledgebase, mapping the identified normalized field to the regular expression satisfied by the token;in response to the identified normalized field corresponding to a token that satisfies one of the regular expressions in the third knowledgebase, mapping the identified normalized field to the regular expression satisfied by the token and adding the mapping of the identified normalized field to said regular expression to the first knowledgebase;in response to the identified normalized field corresponding to a token that is not satisfied by a regular expression in the first or third knowledgebase, but includes a key associated with a normalized field used by the system, creating a regular expression for the corresponding token, mapping the identified normalized field to the created regular expression, and adding the mapping of the identified normalized field to the created regular expression to the first knowledge base of known regular expressions.

9. The system of claim 7, wherein identifying required normalized fields for the parser comprises the following: identifying pre-existing parsers accessible to the system for the same event type as the event type selected by the user for the log group;obtaining a superset of normalized fields extracted in all the pre-existing parsers for the same event type; andidentifying the normalized fields within the superset that are common to all the preexisting parsers for the same event type as the required normalized fields for the parser.