Event limited field picker

An event limited field picker for a search user interface is described. In one or more implementations, a service may operate to collect and store data as events each of which includes a portion of the data correlated with a point in time. Clients may use a search user interface perform searches by input of search criteria. Responsive to receiving search criteria, the service may operate to apply a late binding schema to extract events that match the search criteria and provide search results for display via the search user interface. The search user interface exposes an event limited field picker operable to make selections of fields with respect to individual events in a view of the search results. In response to receiving an indication of a fields selected via the picker, visibility of selected fields may be updated to control which field and values are included in different views.

BACKGROUND

Modern data centers may have thousands of host computer systems that operate collectively to service requests from even larger numbers of remote clients in relation to performance data and diagnostic information (e.g., “logs”) that can be analyzed to quickly diagnose performance problems. In order to reduce the size of this performance data, the data is typically pre-processed prior to being stored based on anticipated data-analysis needs. For example, pre-specified data items can be extracted from the performance data and stored in a database during a data ingestion phase to facilitate efficient retrieval and analysis later at search time. Conventionally, the performance data is not saved in raw form and is essentially discarded during pre-processing. As such, it may be impossible to do analysis later on for items that are not anticipated up front and therefore are not added as pre-specified data items since the discarded raw data is no longer available after data ingestion.

SUMMARY

An event limited field picker for a search user interface is described. In one or more implementations, a service may operate to collect and store data as events each of which includes a portion of the data correlated with a point in time. Clients may use a search user interface to access the event data and perform searches by input of search criteria via the search user interface. At least some search criteria may be in the form of extraction rules that are applied a search time to extract corresponding field values from the event data. Responsive to receiving search criteria input via a search user interface, the service may operate to apply a late binding schema to extract events that match the search criteria and provide search results for display via the search user interface. The search user interface exposes an event limited field picker operable to display fields that are filtered with respect to individual events in a view of the search results. In response to receiving an indication of fields selected via the event limited field picker, the visibility of selected fields may be set to control which fields are included in different views of the data.

DETAILED DESCRIPTION

Overview

Data for large scale systems is typically pre-processed prior to being stored based on anticipated data-analysis needs. For example, pre-specified data items can be extracted from the performance data and stored in a database during a data ingestion phase to facilitate efficient retrieval and analysis later at search time. Conventionally, the performance data is not saved in raw form and therefore, it may be impossible to do analysis later on for items that are not anticipated up front since the discarded raw data may no longer be available after data ingestion.

An event view selector for a search user interface is described. In one or more implementations, a service may operate to collect and store data as events each of which includes a portion of the data correlated with a point in time. Client may use a search user interface to access the event data and perform searches by input of search criteria via the search user interface. At least some search criteria may be in the form of extraction rules that are applied at search time to extract corresponding field values from the event data. Responsive to receiving search criteria input via a search user interface, the service may operate to apply a late binding schema to extract events that match the search criteria and provide search results for display via the search user interface. The search user interface exposes an event view selector operable to enable transitions between multiple different views of the events associated with different levels of detail. The views may include at least a raw view, a list view, and a table view. Responsive to receiving an indication of a view selected via the event view selector, the search user interface may be reconfigured to display the events using the selected view with the corresponding level of detail. In addition or alternatively, the service may facilitate a transition to expose the selected view via the search user interface, such as by reapplying the late binding schema to update search results based on the selected view and/or configuring the selected view for output via the search user interface.

In the following discussion, an example environment is first described that may employ the techniques described herein. Example user interfaces and procedures are then described which may be implemented in the example environment as well as other environments. Consequently, the user interfaces and example procedures are not limited to the example environment and the example environment is not limited to the example user interface and procedures enumerated herein.

Example Environment

Modern data centers often comprise thousands of host computer systems that operate collectively to service requests from even larger numbers of remote clients. During operation, these data centers generate significant volumes of performance data and diagnostic information that can be analyzed to quickly diagnose performance problems. In order to reduce the size of this performance data, the data is typically pre-processed prior to being stored based on anticipated data-analysis needs. For example, pre-specified data items can be extracted from the performance data and stored in a database to facilitate efficient retrieval and analysis at search time. However, the rest of the performance data is not saved and is essentially discarded during pre-processing. As storage capacity becomes progressively cheaper and more plentiful, there are fewer incentives to discard this performance data and many reasons to keep it.

This plentiful storage capacity is presently making it feasible to store massive quantities of minimally processed performance data at “ingestion time” for later retrieval and analysis at “search time.” Note that performing the analysis operations at search time provides greater flexibility because it enables an analyst to search all of the performance data, instead of searching pre-specified data items that were stored at ingestion time. This enables the analyst to investigate different aspects of the performance data instead of being confined to the pre-specified set of data items that were selected at ingestion time.

However, analyzing massive quantities of heterogeneous performance data at search time can be a challenging task. A data center may generate heterogeneous performance data from thousands of different components, which can collectively generate tremendous volumes of performance data that can be time-consuming to analyze. For example, this performance data can include data from system logs, network packet data, sensor data, and data generated by various applications. Also, the unstructured nature of much of this performance data can pose additional challenges because of the difficulty of applying semantic meaning to unstructured data, and the difficulty of indexing and querying unstructured data using traditional database systems.

These challenges can be addressed by using an event-based system, such as the SPLUNK® ENTERPRISE system produced by Splunk Inc. of San Francisco, Calif., to store and process performance data. The SPLUNK® ENTERPRISE system is the leading platform for providing real-time operational intelligence that enables organizations to collect, index, and harness machine-generated data from various websites, applications, servers, networks, and mobile devices that power their businesses. The SPLUNK® ENTERPRISE system is particularly useful for analyzing unstructured performance data, which is commonly found in system log files. Although many of the techniques described herein are explained with reference to the SPLUNK® ENTERPRISE system, the techniques are also applicable to other types of data server systems.

In the SPLUNK® ENTERPRISE system, performance data is stored as “events,” in which each event comprises a collection of performance data and/or diagnostic information that is generated by a computer system and is correlated with a specific point in time. Events can be derived from “time series data,” in which time series data includes a sequence of data points (e.g., performance measurements from a computer system) that are associated with successive points in time and are typically spaced at uniform time intervals. Events can also be derived from “structured” or “unstructured” data. Structured data has a predefined format, in which specific data items with specific data formats reside at predefined locations in the data. For example, structured data can include data items stored in fields in a database table. In contrast, unstructured data does not have a predefined format. This means that unstructured data can include various data items having different data types that can reside at different locations. For example, when the data source is an operating system log, an event can include one or more lines from the operating system log containing raw data that includes different types of performance and diagnostic information associated with a specific point in time. Examples of data sources from which an event may be derived include, but are not limited to: web servers; application servers; databases; firewalls; routers; operating systems; and software applications that execute on computer systems, mobile devices, and sensors. The data generated by such data sources can be produced in various forms including, for example and without limitation, server log files, activity log files, configuration files, messages, network packet data, performance measurements and sensor measurements. An event typically includes a timestamp that may be derived from the raw data in the event, or may be determined through interpolation between temporally proximate events having known timestamps.

The SPLUNK® ENTERPRISE system also facilitates using a flexible schema to specify how to extract information from the event data, in which the flexible schema may be developed and redefined as needed. Note that a flexible schema may be applied to event data “on the fly” as desired (e.g., at search time), rather than at ingestion time of the data as in traditional database systems. Because the schema is not applied to event data until it is desired (e.g., at search time), it is referred to as a “late-binding schema.”

During operation, the SPLUNK® ENTERPRISE system starts with raw data, which can include unstructured data, machine data, performance measurements or other time-series data, such as data obtained from weblogs, syslogs, or sensor readings. It divides this raw data into “portions,” and optionally transforms the data to produce timestamped events. The system stores the timestamped events in a data store, and enables a user to run queries against the data store to retrieve events that meet specified criteria, such as containing certain keywords or having specific values in defined fields. Note that the term “field” refers to a location in the event data containing a value for a specific data item.

As noted above, the SPLUNK® ENTERPRISE system facilitates using a late-binding schema while performing queries on events. A late-binding schema specifies “extraction rules” that are applied to data in the events to extract values for specific fields. More specifically, the extraction rules for a field can include one or more instructions that specify how to extract a value for the field from the event data. An extraction rule can generally include any type of instruction for extracting values from data in events. In some cases, an extraction rule includes a regular expression, in which case the rule is referred to as a “regex rule.”

In contrast to a conventional schema for a database system, a late-binding schema is not defined at data ingestion time. Instead, the late-binding schema can be developed on an ongoing basis until the time a query is actually executed. This means that extraction rules for the fields in a query may be provided in the query itself, or may be located during execution of the query. Hence, as an analyst learns more about the data in the events, the analyst can continue to refine the late-binding schema by adding new fields, deleting fields, or changing the field extraction rules until the next time the schema is used by a query. Because the SPLUNK® ENTERPRISE system maintains the underlying raw data and provides a late-binding schema for searching the raw data, it enables an analyst to investigate questions that arise as the analyst learns more about the events.

In the SPLUNK® ENTERPRISE system, a field extractor may be configured to automatically generate extraction rules for certain fields in the events when the events are being created, indexed, or stored, or possibly at a later time. Alternatively, a user may manually define extraction rules for fields using a variety of techniques.

Also, a number of “default fields” that specify metadata about the events rather than data in the events themselves can be created automatically. For example, such default fields can specify: a timestamp for the event data; a host from which the event data originated; a source of the event data; and a source type for the event data. These default fields may be determined automatically when the events are created, indexed or stored.

In some embodiments, a common field name may be used to reference two or more fields containing equivalent data items, even though the fields may be associated with different types of events that possibly have different data formats and different extraction rules. By enabling a common field name to be used to identify equivalent fields from different types of events generated by different data sources, the system facilitates use of a “common information model” (CIM) across the different data sources.

1.2 Data Server System

FIG. 1presents a block diagram of an example event-processing system100, similar to the SPLUNK® ENTERPRISE system. System100includes one or more forwarders101that represent functionality to collect data and one or more indexers102that represent functionality to store, process, and/or perform operations on this data, in which each indexer may operate on data contained in a specific data store103. A search head104may also be provided that represents functionality to obtain and process search requests from clients and provide results of the search back to the clients, additional details of which are discussed in relation toFIGS. 3 and 4. The forwarders101, indexers102, and/or search head104may be configured as separate computer systems in a data center, or alternatively may be configured as separate processes implemented via one or more individual computer systems. Data that is collected via the forwarders may be obtained from a variety of different data sources105. As further illustrated, the search head104may operate as a service that interacts with a client application module106associated with a client device, such as to obtain search queries and supply search results or other suitable data back to the client application module106that is effective to enable the client application module106to form search user interfaces108through which different views of the data may be exposed. Various examples and details regarding search user interfaces108, client application modules106, search queries, and operation of the various components illustrated inFIG. 1are discussed throughout this document.

For example, during operation, the forwarders101identify which indexers102will receive the collected data and then forward the data to the identified indexers. Forwarders101can also perform operations to strip out extraneous data and detect timestamps in the data. The forwarders next determine which indexers102will receive each data item and then forward the data items to the determined indexers102.

Note that distributing data across different indexers facilitates parallel processing. This parallel processing can take place at data ingestion time, because multiple indexers can process the incoming data in parallel. The parallel processing can also take place at search time, because multiple indexers can search through the data in parallel.

System100and the processes described below with respect toFIGS. 1-5are further described in “Exploring Splunk Search Processing Language (SPL) Primer and Cookbook” by David Carasso, CITO Research, 2012, and in “Optimizing Data Analysis With a Semi-Structured Time Series Database” by Ledion Bitincka, Archana Ganapathi, Stephen Sorkin, and Steve Zhang, SLAML, 2010, each of which is hereby incorporated herein by reference in its entirety for all purposes.

1.3 Data Ingestion

FIG. 2presents a flowchart200illustrating how an indexer processes, indexes, and stores data received from forwarders in accordance with the disclosed embodiments. At block201, the indexer receives the data from the forwarder. Next, at block202, the indexer apportions the data into events. Note that the data can include lines of text that are separated by carriage returns or line breaks and an event may include one or more of these lines. During the apportioning process, the indexer can use heuristic rules to automatically determine the boundaries of the events, which for example coincide with line boundaries. These heuristic rules may be determined based on the source of the data, in which the indexer can be explicitly informed about the source of the data or can infer the source of the data by examining the data. These heuristic rules can include regular expression-based rules or delimiter-based rules for determining event boundaries, in which the event boundaries may be indicated by predefined characters or character strings. These predefined characters may include punctuation marks or other special characters including, for example, carriage returns, tabs, spaces or line breaks. In some cases, a user can fine-tune or configure the rules that the indexers use to determine event boundaries in order to adapt the rules to the user's specific requirements.

Next, the indexer determines a timestamp for each event at block203. As mentioned above, these timestamps can be determined by extracting the time directly from data in the event, or by interpolating the time based on timestamps from temporally proximate events. In some cases, a timestamp can be determined based on the time the data was received or generated. The indexer subsequently associates the determined timestamp with each event at block204, for example by storing the timestamp as metadata for each event.

Then, the system can apply transformations to data to be included in events at block205. For log data, such transformations can include removing a portion of an event (e.g., a portion used to define event boundaries, extraneous text, characters, etc.) or removing redundant portions of an event. Note that a user can specify portions to be removed using a regular expression or any other possible technique.

Next, a keyword index can optionally be generated to facilitate fast keyword searching for events. To build a keyword index, the indexer first identifies a set of keywords in block206. Then, at block207the indexer includes the identified keywords in an index, which associates each stored keyword with references to events containing that keyword (or to locations within events where that keyword is located). When an indexer subsequently receives a keyword-based query, the indexer can access the keyword index to quickly identify events containing the keyword.

In some embodiments, the keyword index may include entries for name-value pairs found in events, wherein a name-value pair can include a pair of keywords connected by a symbol, such as an equals sign or colon. In this way, events containing these name-value pairs can be quickly located. In some embodiments, fields can automatically be generated for some or all of the name-value pairs at the time of indexing. For example, if the string “dest=10.0.1.2” is found in an event, a field named “dest” may be created for the event, and assigned a value of “10.0.1.2.”

Finally, the indexer stores the events in a data store at block208, wherein a timestamp can be stored with each event to facilitate searching for events based on a time range. In some cases, the stored events are organized into a plurality of buckets, wherein each bucket stores events associated with a specific time range. This not only improves time-based searches, but it also allows events with recent timestamps that may have a higher likelihood of being accessed to be stored in faster memory to facilitate faster retrieval. For example, a bucket containing the most recent events can be stored as flash memory instead of on hard disk.

Each indexer102is responsible for storing and searching a subset of the events contained in a corresponding data store103. By distributing events among the indexers and data stores, the indexers can analyze events for a query in parallel, for example using map-reduce techniques, in which each indexer returns partial responses for a subset of events to a search head that combines the results to produce an answer for the query. By storing events in buckets for specific time ranges, an indexer may further optimize searching by looking only in buckets for time ranges that are relevant to a query.

Moreover, events and buckets can also be replicated across different indexers and data stores to facilitate high availability and disaster recovery as is described in U.S. patent application Ser. No. 14/266,812 filed on 30 Apr. 2014, and in U.S. application patent Ser. No. 14/266,817 also filed on 30 Apr. 2014.

1.4 Query Processing

FIG. 3presents a flowchart300illustrating how a search head104and102indexers perform a search query in accordance with the disclosed embodiments. At the start of this process, a search head receives a search query from a client (e.g., client application module106) at block301. Next, at block302, the search head analyzes the search query to determine what portions can be delegated to indexers and what portions need to be executed locally by the search head. At block303, the search head distributes the determined portions of the query to the indexers. Note that commands that operate on single events can be trivially delegated to the indexers, while commands that involve events from multiple indexers are harder to delegate.

Then, at block304, the indexers to which the query was distributed search their data stores for events that are responsive to the query. To determine which events are responsive to the query, the indexer searches for events that match the criteria specified in the query. This criteria can include matching keywords or specific values for certain fields. In a query that uses a late-binding schema, the searching operations in block304may involve using the late-binding schema to extract values for specified fields from events at the time the query is processed. Next, the indexers can either send the relevant events back to the search head, or use the events to calculate a partial result, and send the partial result back to the search head.

Finally, at block305, the search head combines the partial results and/or events received from the indexers to produce a final result for the query. This final result can comprise different types of data depending upon what the query is asking for. For example, the final results can include a listing of matching events returned by the query, or some type of visualization of data from the returned events. In another example, the final result can include one or more calculated values derived from the matching events.

Moreover, the results generated by system100can be returned to a client using different techniques. For example, one technique streams results back to a client in real-time as they are identified. Another technique waits to report results to the client until a complete set of results is ready to return to the client. Yet another technique streams interim results back to the client in real-time until a complete set of results is ready, and then returns the complete set of results to the client. In another technique, certain results are stored as “search jobs,” and the client may subsequently retrieve the results by referencing the search jobs.

The search head can also perform various operations to make the search more efficient. For example, before the search head starts executing a query, the search head can determine a time range for the query and a set of common keywords that all matching events must include. Next, the search head can use these parameters to query the indexers to obtain a superset of the eventual results. Then, during a filtering stage, the search head can perform field-extraction operations on the superset to produce a reduced set of search results.

1.5 Field Extraction

FIG. 4presents a block diagram400illustrating how fields can be extracted during query processing in accordance with the disclosed embodiments. At the start of this process, a search query402is received at a query processor404. Query processor404includes various mechanisms for processing a query, wherein these mechanisms can reside in a search head104and/or an indexer102. Note that the example search query402illustrated inFIG. 4is expressed in Search Processing Language (SPL), which is used in conjunction with the SPLUNK® ENTERPRISE system. SPL is a pipelined search language in which a set of inputs is operated on by a first command in a command line, and then a subsequent command following the pipe symbol “|” operates on the results produced by the first command, and so on for additional commands. Search query402can also be expressed in other query languages, such as the Structured Query Language (“SQL”) or any suitable query language.

Upon receiving search query402, query processor404sees that search query402includes two fields “IP” and “target.” Query processor404also determines that the values for the “IP” and “target” fields have not already been extracted from events in data store414, and consequently determines that query processor404needs to use extraction rules to extract values for the fields. Hence, query processor404performs a lookup for the extraction rules in a rule base406, in which rule base406maps field names to corresponding extraction rules and obtains extraction rules408-409, extraction rule408specifies how to extract a value for the “IP” field from an event, and extraction rule409specifies how to extract a value for the “target” field from an event. As is illustrated inFIG. 4, extraction rules408-409can include regular expressions that specify how to extract values for the relevant fields. Such regular-expression-based extraction rules are also referred to as “regex rules.” In addition to specifying how to extract field values, the extraction rules may also include instructions for deriving a field value by performing a function on a character string or value retrieved by the extraction rule. For example, a transformation rule may truncate a character string, or convert the character string into a different data format. In some cases, the query itself can specify one or more extraction rules.

Next, query processor404sends extraction rules408-409to a field extractor412, which applies extraction rules408-409to events416-418in a data store414. Note that data store414can include one or more data stores, and extraction rules408-409can be applied to large numbers of events in data store414, and are not meant to be limited to the three events416-418illustrated inFIG. 4. Moreover, the query processor404can instruct field extractor412to apply the extraction rules to all the events in a data store414, or to a subset of the events that have been filtered based on some criteria.

Next, field extractor412applies extraction rule408for the first command “Search IP=“10*” to events in data store414including events416-418. Extraction rule408is used to extract values for the IP address field from events in data store414by looking for a pattern of one or more digits, followed by a period, followed again by one or more digits, followed by another period, followed again by one or more digits, followed by another period, and followed again by one or more digits. Next, field extractor412returns field values420to query processor404, which uses the criterion IP=“10*” to look for IP addresses that start with “10”. Note that events416and417match this criterion, but event418does not, so the result set for the first command is events416-417.

Query processor404then sends events416-417to the next command “stats count target.” To process this command, query processor404causes field extractor412to apply extraction rule409to events416-417. Extraction rule409is used to extract values for the target field for events416-417by skipping the first four commas in events416-417, and then extracting all of the following characters until a comma or period is reached. Next, field extractor412returns field values421to query processor404, which executes the command “stats count target” to count the number of unique values contained in the target fields, which in this example produces the value “2” that is returned as a final result422for the query.

Note that query results can be returned to a client, a search head, or any other system component for further processing. In general, query results may include: a set of one or more events; a set of one or more values obtained from the events; a subset of the values; statistics calculated based on the values; a report containing the values; or a visualization, such as a graph or chart, generated from the values.

1.6 Example Search Screen

FIG. 6Adepicts an example search screen600that represent an illustrative example of a search user interface108in accordance with one or more implementations. Search screen600includes a search bar602that accepts user input in the form of a search string. It also includes a time range picker603that enables the user to specify a time range for the search. For “historical searches” the user can select a specific time range, or alternatively a relative time range, such as “today,” “yesterday” or “last week.” For “real-time searches,” the user can select the size of a preceding time window to search for real-time events. Search screen600also initially displays a “data summary” dialog as is illustrated inFIG. 6Bthat enables the user to select different sources for the event data, for example by selecting specific hosts and log files.

After the search is executed, the search screen600can display the results through search results tabs604, wherein search results tabs604includes: an “events tab” that displays various information about events returned by the search; a “statistics tab” that displays statistics about the search results; and a “visualization tab” that displays various visualizations of the search results. The events tab illustrated inFIG. 6Adisplays a timeline graph605that graphically illustrates the number of events that occurred in one-hour intervals over the selected time range. It also displays an events pane606that enables a user to view the event data in each of the returned events and may support a plurality of different views of the event data as discussed herein. It additionally displays a fields sidebar608that includes statistics about occurrences of specific fields in the returned events, including “selected fields” that are pre-selected by the user, and “interesting fields” that are automatically selected by the system based on pre-specified criteria. In one or more implementations, the fields sidebar608may also be configured to facilitate selections of fields in various ways.

The above-described system provides significant flexibility by enabling a user to analyze massive quantities of minimally processed performance data “on the fly” at search time instead of storing pre-specified portions of the performance data in a database at ingestion time. This flexibility enables a user to see correlations in the performance data and perform subsequent queries to examine interesting aspects of the performance data that may not have been apparent at ingestion time.

However, performing extraction and analysis operations at search time can involve a large amount of data and require a large number of computational operations, which can cause considerable delays while processing the queries. Fortunately, a number of acceleration techniques have been developed to speed up analysis operations performed at search time. These techniques include: (1) performing search operations in parallel by formulating a search as a map-reduce computation; (2) using a keyword index; (3) using a high performance analytics store; and (4) accelerating the process of generating reports. These techniques are described in more detail below.

To facilitate faster query processing, a query can be structured as a map-reduce computation, wherein the “map” operations are delegated to the indexers, while the corresponding “reduce” operations are performed locally at the search head. For example,FIG. 5illustrates an example500of how a search query501received from a client at search head104can split into two phases, including: (1) a “map phase” comprising subtasks502(e.g., data retrieval or simple filtering) that may be performed in parallel and are “mapped” to indexers102for execution, and (2) a “reduce phase” comprising a merging operation503to be executed by the search head when the results are ultimately collected from the indexers.

During operation, upon receiving search query501, search head104modifies search query501by substituting “stats” with “prestats” to produce search query502, and then distributes search query502to one or more distributed indexers, which are also referred to as “search peers.” Note that search queries may generally specify search criteria or operations to be performed on events that meet the search criteria. Search queries may also specify field names, as well as search criteria for the values in the fields or operations to be performed on the values in the fields. Moreover, the search head may distribute the full search query to the search peers as is illustrated inFIG. 3, or may alternatively distribute a modified version (e.g., a more restricted version) of the search query to the search peers. In this example, the indexers are responsible for producing the results and sending them to the search head. After the indexers return the results to the search head, the search head performs the merging operations503on the results. Note that by executing the computation in this way, the system effectively distributes the computational operations while minimizing data transfers.

1.7.2 Keyword Index

As described above with reference to the flow charts200,300inFIGS. 2 and 3, event-processing system100can construct and maintain one or more keyword indices to facilitate rapidly identifying events containing specific keywords. This can greatly speed up the processing of queries involving specific keywords. As mentioned above, to build a keyword index, an indexer first identifies a set of keywords. Then, the indexer includes the identified keywords in an index, which associates each stored keyword with references to events containing that keyword, or to locations within events where that keyword is located. When an indexer subsequently receives a keyword-based query, the indexer can access the keyword index to quickly identify events containing the keyword.

1.7.3 High Performance Analytics Store

To speed up certain types of queries, some embodiments of system100make use of a high performance analytics store, which is referred to as a “summarization table,” that contains entries for specific field-value pairs. Each of these entries keeps track of instances of a specific value in a specific field in the event data and includes references to events containing the specific value in the specific field. For example, an example entry in a summarization table can keep track of occurrences of the value “94107” in a “ZIP code” field of a set of events, wherein the entry includes references to all of the events that contain the value “94107” in the ZIP code field. This enables the system to quickly process queries that seek to determine how many events have a particular value for a particular field, because the system can examine the entry in the summarization table to count instances of the specific value in the field without having to go through the individual events or do extractions at search time. Also, if the system needs to process each of the events that have a specific field-value combination, the system can use the references in the summarization table entry to directly access the events to extract further information without having to search each of the events to find the specific field-value combination at search time.

In some embodiments, the system maintains a separate summarization table for each of the above-described time-specific buckets that stores events for a specific time range, wherein a bucket-specific summarization table includes entries for specific field-value combinations that occur in events in the specific bucket. Alternatively, the system can maintain a separate summarization table for each indexer, in which the indexer-specific summarization table only includes entries for the events in a data store that is managed by the specific indexer.

The summarization table can be populated by running a “collection query” that scans a set of events to find instances of a specific field-value combination, or alternatively instances of all field-value combinations for a specific field. A collection query can be initiated by a user, or can be scheduled to occur automatically at specific time intervals. A collection query can also be automatically launched in response to a query that asks for a specific field-value combination.

In some cases, the summarization tables may not cover each of the events that are relevant to a query. In this case, the system can use the summarization tables to obtain partial results for the events that are covered by summarization tables, but may also have to search through other events that are not covered by the summarization tables to produce additional results. These additional results can then be combined with the partial results to produce a final set of results for the query. This summarization table and associated techniques are described in more detail in U.S. Pat. No. 8,682,925, issued on Mar. 25, 2014.

1.7.4 Accelerating Report Generation

In some embodiments, a data server system such as the SPLUNK® ENTERPRISE system can accelerate the process of periodically generating updated reports based on query results. To accelerate this process, a summarization engine automatically examines the query to determine whether generation of updated reports can be accelerated by creating intermediate summaries. (This is possible if results from preceding time periods can be computed separately and combined to generate an updated report. In some cases, it is not possible to combine such incremental results, for example where a value in the report depends on relationships between events from different time periods.) If reports can be accelerated, the summarization engine periodically generates a summary covering data obtained during a latest non-overlapping time period. For example, where the query seeks events meeting a specified criteria, a summary for the time period includes only events within the time period that meet the specified criteria. Similarly, if the query seeks statistics calculated from the events, such as the number of events that match the specified criteria, then the summary for the time period includes the number of events in the period that match the specified criteria.

In parallel with the creation of the summaries, the summarization engine schedules the periodic updating of the report associated with the query. During each scheduled report update, the query engine determines whether intermediate summaries have been generated covering portions of the time period covered by the report update. If so, then the report is generated based on the information contained in the summaries. Also, if additional event data has been received and has not yet been summarized, and is required to generate the complete report, the query can be run on this additional event data. Then, the results returned by this query on the additional event data, along with the partial results obtained from the intermediate summaries, can be combined to generate the updated report. This process is repeated each time the report is updated. Alternatively, if the system stores events in buckets covering specific time ranges, then the summaries can be generated on a bucket-by-bucket basis. Note that producing intermediate summaries can save the work involved in re-running the query for previous time periods, so only the newer event data needs to be processed while generating an updated report. These report acceleration techniques are described in more detail in U.S. Pat. No. 8,589,403, issued on Nov. 19, 2013, and U.S. Pat. No. 8,412,696, issued on Apr. 2, 2011.

1.8 Security Features

The SPLUNK® ENTERPRISE platform provides various schemas, dashboards and visualizations that make it easy for developers to create applications to provide additional capabilities. One such application is the SPLUNK® APP FOR ENTERPRISE SECURITY, which performs monitoring and alerting operations and includes analytics to facilitate identifying both known and unknown security threats based on large volumes of data stored by the SPLUNK® ENTERPRISE system. This differs significantly from conventional Security Information and Event Management (SIEM) systems that lack the infrastructure to effectively store and analyze large volumes of security-related event data. Traditional SIEM systems typically use fixed schemas to extract data from pre-defined security-related fields at data ingestion time, wherein the extracted data is typically stored in a relational database. This data extraction process (and associated reduction in data size) that occurs at data ingestion time inevitably hampers future incident investigations, when all of the original data may be needed to determine the root cause of a security issue, or to detect the tiny fingerprints of an impending security threat.

In contrast, the SPLUNK® APP FOR ENTERPRISE SECURITY system stores large volumes of minimally processed security-related data at ingestion time for later retrieval and analysis at search time when a live security threat is being investigated. To facilitate this data retrieval process, the SPLUNK® APP FOR ENTERPRISE SECURITY provides pre-specified schemas for extracting relevant values from the different types of security-related event data, and also enables a user to define such schemas.

The SPLUNK® APP FOR ENTERPRISE SECURITY can process many types of security-related information. In general, this security-related information can include any information that can be used to identify security threats. For example, the security-related information can include network-related information, such as IP addresses, domain names, asset identifiers, network traffic volume, uniform resource locator strings, and source addresses. (The process of detecting security threats for network-related information is further described in U.S. patent application Ser. Nos. 13/956,252, and 13/956,262.) Security-related information can also include endpoint information, such as malware infection data and system configuration information, as well as access control information, such as login/logout information and access failure notifications. The security-related information can originate from various sources within a data center, such as hosts, virtual machines, storage devices and sensors. The security-related information can also originate from various sources in a network, such as routers, switches, email servers, proxy servers, gateways, firewalls and intrusion-detection systems.

During operation, the SPLUNK® APP FOR ENTERPRISE SECURITY facilitates detecting so-called “notable events” that are likely to indicate a security threat. These notable events can be detected in a number of ways: (1) an analyst can notice a correlation in the data and can manually identify a corresponding group of one or more events as “notable;” or (2) an analyst can define a “correlation search” specifying criteria for a notable event, and every time one or more events satisfy the criteria, the application can indicate that the one or more events are notable. An analyst can alternatively select a pre-defined correlation search provided by the application. Note that correlation searches can be run continuously or at regular intervals (e.g., every hour) to search for notable events. Upon detection, notable events can be stored in a dedicated “notable events index,” which can be subsequently accessed to generate various visualizations containing security-related information. Also, alerts can be generated to notify system operators when important notable events are discovered.

The SPLUNK® APP FOR ENTERPRISE SECURITY provides various visualizations to aid in discovering security threats, such as a “key indicators view” that enables a user to view security metrics of interest, such as counts of different types of notable events. For example,FIG. 7Aillustrates an example key indicators view700that comprises a dashboard, which can display a value701, for various security-related metrics, such as malware infections702. It can also display a change in a metric value703, which indicates that the number of malware infections increased by 63 during the preceding interval. Key indicators view700additionally displays a histogram panel704that displays a histogram of notable events organized by urgency values, and a histogram of notable events705organized by time intervals. This key indicators view is described in further detail in pending U.S. patent application Ser. No. 13/956,338 filed Jul. 31, 2013.

These visualizations can also include an “incident review dashboard” that enables a user to view and act on “notable events.” These notable events can include: (1) a single event of high importance, such as any activity from a known web attacker; or (2) multiple events that collectively warrant review, such as a large number of authentication failures on a host followed by a successful authentication. For example,FIG. 7Billustrates an example incident review dashboard710that includes a set of incident attribute fields711that, for example, enables a user to specify a time range field712for the displayed events. It also includes a timeline713that graphically illustrates the number of incidents that occurred in one-hour time intervals over the selected time range. It additionally displays an events list714that enables a user to view a list of each of the notable events that match the criteria in the incident attributes fields711. To facilitate identifying patterns among the notable events, each notable event can be associated with an urgency value (e.g., low, medium, high, critical), which is indicated in the incident review dashboard. The urgency value for a detected event can be determined based on the severity of the event and the priority of the system component associated with the event. The incident review dashboard is described further in “http://docs.splunk.com/Documentation/PCI/2.1.1/User/IncidentReviewdashboard.”

1.9 Data Center Monitoring

As mentioned above, the SPLUNK® ENTERPRISE platform provides various features that make it easy for developers to create various applications. One such application is the SPLUNK® APP FOR VMWARE®, which performs monitoring operations and includes analytics to facilitate diagnosing the root cause of performance problems in a data center based on large volumes of data stored by the SPLUNK® ENTERPRISE system.

This differs from conventional data-center-monitoring systems that lack the infrastructure to effectively store and analyze large volumes of performance information and log data obtained from the data center. In conventional data-center-monitoring systems, this performance data is typically pre-processed prior to being stored, for example by extracting pre-specified data items from the performance data and storing them in a database to facilitate subsequent retrieval and analysis at search time. However, the rest of the performance data is not saved and is essentially discarded during pre-processing. In contrast, the SPLUNK® APP FOR VMWARE® stores large volumes of minimally processed performance information and log data at ingestion time for later retrieval and analysis at search time when a live performance issue is being investigated.

The SPLUNK® APP FOR VMWARE® can process many types of performance-related information. In general, this performance-related information can include any type of performance-related data and log data produced by virtual machines and host computer systems in a data center. In addition to data obtained from various log files, this performance-related information can include values for performance metrics obtained through an application programming interface (API) provided as part of the vSphere Hypervisor™ system distributed by VMware, Inc. of Palo Alto, Calif. For example, these performance metrics can include: (1) CPU-related performance metrics; (2) disk-related performance metrics; (3) memory-related performance metrics; (4) network-related performance metrics; (5) energy-usage statistics; (6) data-traffic-related performance metrics; (7) overall system availability performance metrics; (8) cluster-related performance metrics; and (9) virtual machine performance statistics. For more details about such performance metrics, please see U.S. patent Ser. No. 14/167,316 filed 29 Jan. 2014, which is hereby incorporated herein by reference. Also, see “vSphere Monitoring and Performance,” Update 1, vSphere 5.5, EN-001357-00, http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-551-monitoring-performance-guide.pdf.

To facilitate retrieving information of interest from performance data and log files, the SPLUNK® APP FOR VMWARE® provides pre-specified schemas for extracting relevant values from different types of performance-related event data, and also enables a user to define such schemas.

The SPLUNK® APP FOR VMWARE® additionally provides various visualizations to facilitate detecting and diagnosing the root cause of performance problems. For example, one such visualization is a “proactive monitoring tree” that enables a user to easily view and understand relationships among various factors that affect the performance of a hierarchically structured computing system. This proactive monitoring tree enables a user to easily navigate the hierarchy by selectively expanding nodes representing various entities (e.g., virtual centers or computing clusters) to view performance information for lower-level nodes associated with lower-level entities (e.g., virtual machines or host systems). Example node-expansion operations are illustrated inFIG. 7C, wherein nodes733and734are selectively expanded. Note that nodes731-739can be displayed using different patterns or colors to represent different performance states, such as a critical state, a warning state, a normal state or an unknown/offline state. The ease of navigation provided by selective expansion in combination with the associated performance-state information enables a user to quickly diagnose the root cause of a performance problem. The proactive monitoring tree is described in further detail in U.S. patent application Ser. No. 14/235,490 filed on 15 Apr. 2014, which is hereby incorporated herein by reference for all possible purposes.

The SPLUNK® APP FOR VMWARE® also provides a user interface that enables a user to select a specific time range and then view heterogeneous data, comprising events, log data and associated performance metrics, for the selected time range. For example, the screen illustrated inFIG. 7Ddisplays a listing of recent “tasks and events” and a listing of recent “log entries” for a selected time range above a performance-metric graph for “average CPU core utilization” for the selected time range. Note that a user is able to operate pull-down menus742to selectively display different performance metric graphs for the selected time range. This enables the user to correlate trends in the performance-metric graph with corresponding event and log data to quickly determine the root cause of a performance problem. This user interface is described in more detail in U.S. patent application Ser. No. 14/167,316 filed on 29 Jan. 2014, which is hereby incorporated herein by reference for all possible purposes.

Example User Interfaces and Procedures

The following discussion describes user interface and techniques that may be implemented utilizing the previously described systems and devices. For example, search user interfaces108may be configured in various ways to facilitate searches of and other interaction with data stored as events in one or more data stores as noted previously. In one or more implementations, user interfaces may be formed by a client application module106based upon data that is supplied by a search service, such as via components of the example system100above. The service may communicate data in response to search queries from clients that is effective to enable a client application module106to form search user interfaces108through which different views of the data may be exposed. In addition or alternatively, the service may operate to configure search user interfaces, views, or pages on the server-side based on results of searches for communication to and display by clients via a client application module106executed on the client-side.

Event View Selector

In one or more implementations, a search user interface108, such as the example search screen600described above, may be configured to expose an event view selector that is operable to cause transitions between multiple different views of events or “display formats” presented within the search user interface. The multiple different views may be configured to provide different representations of events, fields, and metadata included in search results generated for search queries. This may include organizing the data in different ways, providing different levels of detail, exposing or omitting values and headers for fields and/or other metadata derived from the events, grouping events in categories, collapsing or expanding portions, and so forth.

By way of example and not limitation, the multiple different views may include one or more of a list view, a table view and a raw view. Other different types of views are also contemplated that may be supported by a search user interface. Generally, different views may be configured to provide different levels of detail with respect to how much of the data for events is shown and/or whether fields and corresponding values are or are not presented in conjunction with the event data. The event view selector may be configured as any suitable user interface instrumentality that enables selection of a selected view from among multiple different views that are supported by the system. By way of example and not limitation, the event view selector may be configured to incorporate one or more of a list box element, a radio control, a slider control, a menu, icons representing the multiple different views, links, check boxes, tabs, or buttons configured to enable selections between the multiple different views.

As noted above, data may be stored as events with each event including a portion of the data associated with a timestamp or other indication of a point in time. The data may represent various raw data, which may include but is not limited to one or more of unstructured data, log data, network data, packet data, wire data, machine data, performance measurements, or time-series data. Moreover, field values for fields may be retrieved by applying a late binding schema that implements one or more extraction rules configured to define the fields and indicate how to derive the field values from event data at search time.

In this context, the list view is configured to represent portions of the data for events in a list in conjunction with field values that are extracted based on application of the late binding schema. For example, in list view events may be represented as a list of rows where each row corresponds to an individual event. One or more selected fields/field values may also be shown in the rows along with the event data for each field. Individual rows in the list view may be configured to show event data with the field values and/or labels for a corresponding event. A variety of techniques may be used to select the fields to show in list view and/or other views some example of which are discussed above and below.

The table view is configured to represent field values extracted based on application of a late binding schema for one or more selected fields in a table form without showing corresponding event data. In other words, selection of table view transitions the user interface to present a view in which selected fields/field values are represented in a compact or summarized form without showing the underlying data for the events. In table view, field headers having labels (e.g., field names) may also be shown, such as in a row at the top of the table to produce columns that correspond to the selected fields. The field headers may be configured to enable various manipulations of the table data, such as changing column widths, removal of fields using a defined action such as a drag and drop action or selection of a delete control, rearranging the columns one to another, sorting/filtering of the data based on values in one or more columns and so forth. Individual rows in the table view may be configured to show just the field values for a corresponding event.

The raw view is configured to represent the portions of the data for events in a raw format. In raw view, underlying event data for events is represented without showing the fields/field values as in list view or table view. Here, individual rows may be configured to show just the underlying event data. Further details and examples regarding aspects of the event view selector and different views are discussed in relation to example search user interfaces represented inFIGS. 8 to 11.

FIG. 8illustrates generally at800an example search user interface108having an event view selector in a list view in accordance with one or more implementations. In the depicted example, search user interface108includes a search bar602, time range picker603, search results tab604, events pane606, and field sidebar608as discussed previously. The example search user interface108also includes an event view selector802that may be configured and operate as described above and below. Here, the event view selector802is implemented as a list box element configured to provide a list of the multiple different views as selectable items. The event view selector802may be further configured to initiate communication of an indication regarding the selected view responsive to a selection from the list. The indication may cause operations by the client and/or service to update the search user interface according to the selected view. The supported views as shown inFIG. 8include a raw view, list view, and table view. Further, the event view selector802may visually represent the selected view such as using a checkmark, highlighting, different colored text, and/or other indicators. Other configurations of an event view selector802are also contemplated examples of which were previously discussed.

In the example shown, a list view804is illustrated as being the selected view and accordingly is depicted as being rendered within the events pane606. In particular, each row in the in the example list view804corresponds to an event and includes underlying event data806corresponding to the event and field data808(e.g., including field headers810and field values812) that may be extracted for the event. Field data may be shown for one or more selected fields. Fields to include in queries may be selected in various ways such as via a field picker exposed via controls associated with individual events in the events pane606, interaction (e.g., selection, hovering, clicking, etc.) with fields enumerated in the fields sidebar606, an all fields control805operable to launch a picker showing all available fields, or otherwise. Various selected fields may be identified via the fields sidebar606as further represented inFIG. 8.

As mentioned, selections made via the event view selector802may cause transitions between different views of the event data. For example, selection of list view804may cause a transition from the table view or raw view discussed below in relation toFIG. 9andFIG. 10, respectively, or another view of the event data. Generally speaking, a client may obtain input indicative of a selected view via the event view selector802. In response, the client may cause a transition to a selected view by reconfiguring the search user interface to display events in accordance with a selected view. This may involve operations setting the visibility of items (e.g., fields, events, raw data, etc.) to correspond to the selected view, reformatting of the events pane606at the client, rendering the selected view, and so forth. In this approach, the client processes search results that have been returned based on the current search to form the different view in response to the input indicative of a selected view.

In another approach, the client may communicate indications of the selected view to a service to cause operations by the service to update the view. The service may then perform various operations to facilitate transitions to expose a selected view responsive to receiving an indication of a selected view. For example, the service may operate to determine updated search criteria that include modified extraction rules corresponding to a selected view and reapply a late binding schema to extract events that match the updated search criteria using the one or more extraction rules as modified. In addition or alternatively, the service may operate to configure the selected view and communicate data effective to enable the client computing device to expose the view to the client computing device. In another example, the view may be configured at the client based on communication of data by the service effective to enable the client to form the view.

FIG. 9illustrates generally at900a search user interface108having an event view selector in a table view in accordance with one or more implementations. The table view902shown in this example may be output in the events pane606responsive to selection of table view via the event view selector802in the manner previously described. Selection of table view902may cause a transition from the list view804ofFIG. 8, raw view discussed below in relation toFIG. 10, or another view of the event data. In the table view902, a compact and/or summarized view is shown in which each row displays field data808for the event without including underlying event data806. Rows may be configured to show both field values812and field headers810as in the example ofFIG. 8. In addition or alternatively, a header portion904may be exposed to provide field headers810as represented inFIG. 9. In this example, the table includes rows corresponding to individual events and columns corresponding to individual fields. As mentioned above, the header portion904and field headers may enable various functionality to further refine the view such as changing column widths, removal of fields using a defined action such as a drag and drop action or selection of a delete control, rearranging the columns one to another, sorting/filtering of the data based on values in one or more columns and so forth. When the header portion904is employed, the rows may show just field values812for the events in the rows as represented inFIG. 9.

FIG. 9additionally depicts association of an event limited field picker toggle906with each of the events (e.g., each row). The event limited field picker toggle906is representative of any suitable user interface instrumentality that is operable to expose an event limited field picker for a corresponding event. By way of example, the event limited field picker toggle906is configured as a selectable arrow control that may be selectively toggled to show or hide a corresponding event limited field picker. Other types of user interface instrumentalities are also contemplated such as a button, selectable text, an icon, and so forth. The event limited field picker toggle906is discussed with respect to the table view, but corresponding toggles may be employed with other views as represented in relation to the list view and raw view ofFIGS. 8 and 10, respectively

Details and examples regarding event limited field pickers are discussed in relation toFIGS. 12 to 16below. By way of introduction, though, the event limited field picker is configured to expose details regarding a corresponding event and include various functionality to perform operations with respect to fields associated with the corresponding event. These operations may include but are not limited to making selections to specify fields that are visible and hidden for a view, selecting or deselecting fields for a search query, refining a time period specified for the query, specifying tags for field values pairs, setting query constraints with respect to fields, and initiating custom actions, to name a few examples.

FIG. 10illustrates generally at1000a search user interface having an event view selector in a raw view in accordance with one or more implementations. The raw view1002shown in this example may be output in the events pane606responsive to selection of raw view via the event view selector802in the manner previously described. Selection of raw view1002may cause a transition from the list view804ofFIG. 8, table view902ofFIG. 9, or another view of the event data. In the raw view1002, underlying event data is shown in a raw or “unaltered” format. The raw view1002may provide a view of the event data806as stored in the data store and without including additional field data808, metadata, statistics, or parameters that may be derived from the event data806and exposed in other views. In addition or alternatively, the raw view1002may provide a view with limited detail and/or metadata, such as by presenting the raw data for events along with an associated timestamps for organization, sorting, and identification of the event data.

FIG. 11illustrates generally at1100a docking header for a table view mode that may be employed in accordance with one or more implementations. In this example, the table view902as discussed in relation toFIG. 9is shown in which the field headers904are included as part of a docking header1102. The docking header1102is configured to enable a docked view1101in which the headers remain visible as different groups of events are accessed via the events pane606. For example, input1104such as touch input, mouse clicks, scrolling, keystrokes or other types of input may be used to navigate1106to different pages or portions of the table. A page selector1108may also be provided to facilitate navigations to different pages of search results included in the view. The docking header1102may be visually fixed at the top of the table. Rows of events may be rendered to scroll underneath the docking header1102in implementations in which scrolling is available. In addition or alternatively, operation of the page selector1108may cause different portions of the table to appear below the docking header1102while the docking header1102stays in place.

Moreover, in an implementation, some portions of the search user interface108may be collapsed when the docking header1102is activated. For instance, comparison of the docked view1101with the table view902ofFIG. 9reveals that in the example docked view1101the field sidebar608and event pane606are expanded and other portions shown above these elements inFIG. 9(e.g., search bar602, search results tab604, time range picker603, timeline605, etc.) are collapsed. Collapsing of some portions enables presentation of additional rows, fields and/or data within the field sidebar608and event pane606.

The docking header1102may be activated in various ways. In one approach, the docking header1102may dock automatically in response to input to access different rows or pages of results. In addition or alternatively, a control associated with the headers, such as a dock button or icon, may be provided to enable an explicit selection by a user to transition to the docked view1101. Still further, the docked view1101may be provided as another supported view option that may be selectable via an event view selector802in accordance with the techniques discussed herein.

Event Limited Field Picker

In one or more implementations, a search user interface108such as the example search screen600described above may be configured to expose an event limited field picker. As introduced above, the event limited field picker is configured to expose details regarding a corresponding event and include various functionality to perform operations with respect to fields associated with the corresponding event. The operations may include at least selection and deselection of fields as selected fields that are made visible in views of search results. Additional operations may include but are not limited to selecting or deselecting fields for a search query, refining a time period specified for the query, specifying tags for field values pairs, setting query constraints with respect to fields, and initiating custom actions, to name a few examples . . . . As noted, any suitable user interface instrumentality may be employed to provide access to and launch an event limited field picker for a corresponding event, examples of which include but are not limited to a toggle control, a button, selectable text, an icon, and so forth.

Generally, the event limited field picker may be configured to provide a filtered view of fields that corresponds to fields available for a selected event. The event limited field picker may be employed with any of the various example views of events discussed herein, such as raw view, list view, or table view. In one approach, an event limited field picker toggle906(or other user interface instrumentality) may be exposed in association with each individual event in views presented within an events pane606. When the event limited field picker is launched for a selected event, detail information for the selected event may be exposed.

In an implementation, the event limited field picker provides at least a list of fields associated with a selected event along with suitable user interface instrumentalities operable to select and deselect fields to incorporate into search criteria for a search query. For example, the event limited field picker may be configured to expose a toggle control in association with each event in the view of the events. Each of the toggle controls may be operable to launch the event limited field picker using field data filtered for a corresponding event.

In other words, the event limited field picker is configured to show fields associated with the selected event and enable selections to designate which or the fields are displayed in a view of the events. Selection or deselection of the fields via the event limited field picker may cause setting of the visibility of fields in various views of event data that may be accessible via the search user interface. Visibility of fields may be set with respect to a search results obtained via the search user interface. In an implementation, visibility parameters for fields are set based on selections may via the event limited field picker and views are updated accordingly. This may occur without having the requery the server to obtain updated a search results. In addition or alternatively, selections/deselections of one or more fields via the picker may result in a modification of the search criteria in which case indications of the settings for the one or more fields may be communicated to the server to cause updating of search results by the service accordingly.

In addition to listing of fields corresponding to the selected event, other detail information for the fields may be exposed via the event limited field picker. For example, the event limited field picker may be configured to display a representation of the event data806(e.g., as shown in list view804or raw view1002) for a selected event. Moreover, the event limited field picker may be configured to display a representation of field data808(e.g., as shown in list view804or table view902) including field values for one or more fields associated with a selected event.

The event limited field picker may be accessible from within an events pane of the search user interface to show the filtered view of fields associated with a selected event. The event limited field picker—may also be accessible from a menu item, sidebar, or other representation of individual events provided by the search user interface. The filtered view may be configured to indicate fields that are already selected and other fields associated with the selected event that are available for selection (e.g., fields returned by the query that are not currently selected). For example, the events may be visually divided into a list of selected events and a list of other events using text headers, lines, boxes or other elements.

Further, the event limited field picker may be configured to provide various functionality to perform operations with respect to fields associated with a corresponding event. The operations made available via the event limited field picker may include but are not limited to one or more of making selections to select or deselect fields for a search query, refining a time period specified for a search query, specifying tags for field-values pairs, and/or setting query constraints with respect to fields.

In one particular example, controls associated with each individual field may be configured to launch a drilldown menu with options to refine the search criteria for an active query. Example options include but are not limited to selections to include the individual field in the query, exclude the individual field in the query, or launch a new search using the individual field. The query, search results, and corresponding views may be automatically updated based on selections made via the drilldown menu. In another example, the event limited field picker includes controls associated with each selected field selectable to define a tag for a field-value pair. The tags may then be used to refer to the field-value pair in search queries, label instances of the field-value pair recognized in search results and events, or otherwise make use of a field and particular value in combination. Further details and examples regarding aspects of event limited field picker and techniques to select fields are discussed in relation to example search user interfaces represented inFIGS. 12 to 16.

FIG. 12illustrates generally at1200a search user interface108having an event limited field picker1202in a table view902in accordance with one or more implementations. In this example, an event limited field picker toggle906as discussed in relation toFIG. 9is shown that is operable to selectively expose or collapse the event limited field picker1202for a corresponding event. For instance, selection of the toggle for a particular event to launch the picker may cause an expansion of the row for the event and concealment of rows for other events. The event limited field picker1202is then revealed within the expanded portion in the event pane606. The selection may also cause “modalization” of the events pane606and “locking-out” of other portions of the search user interface as discussed in greater detail below. Subsequent selection of the toggle to close the picker may cause a switch back to the former view. Operation of the event limited field picker toggle906to selectively launch and close to picker is illustrated by comparison of the different example views shown inFIGS. 9 and 12.

Generally speaking, a client may obtain input indicative of selected fields via the event limited field picker1202. In response, the client may reconfigure and render the view of events to include selected fields and/or communicate indications of the selected fields to a service to cause operations by the service to requery the data, update search results, and/or configure the search user interface to output the updated search results. In one or more implementations, the client may operate to process search results obtained from the server to set visibility of fields in accordance with selection made via the event limited field picker1202. Selected fields may then be shown in location where field data808is exposed and deselected fields may be hidden.

In one or more implementations, the service may perform various operations to facilitate transitions to expose updated views responsive to receiving indications of selected fields. As noted, searches performed by the service may involve applying a late binding schema, which uses one or more extraction rules reflected by the search criteria. In this context, selection of the fields via the event limited field picker and/or other functionality accessible via the field picker may cause modification of the search criteria to specify new and/or updated extraction rules. In response to indications provided by the client regarding the modification of search criteria, the service may be configured to ascertain the extraction rules corresponding to the one or more fields that are selected. In one approach, the extraction rules may be included with and obtained from the indications communicated by the client. In addition or alternatively, the service may include or otherwise make use of a library of extraction rules (e.g., rule base406) that correspond to fields indicated in the search criteria by the client. In this case, the service may operate to look-up extraction rules for at least some selected fields from the library. Then, the service may reapply the late binding schema to extract events that match the modified search criteria using the ascertained extraction rules. A response that incorporates updated search results based on application of the late binding schema may then be communicated back to the client to facilitate generation of an updated view. This may be accomplished by the service sending search results to the client effective to enable the client computing device to form the updated view (e.g., a view that includes fields/field data in accordance with selection made via the event limited field picker). In addition or alternatively, the service may configure at least a portion of the view on the server side and communicate data effective to enable the client to expose the view on the client side.

In the example ofFIG. 12, the event limited field picker1202is configured to represent both selected fields1204and available fields1206as mentioned previously. Field data808including one or both of field headers810and field values812may be included in the representation, such as in a list having fields and value columns as shown. Additionally, user interface instrumentalities1208in the form of check boxes (or other controls) may be provided in connection with each individual field. The check boxes or other suitable controls may be used to enable selection and deselection of individual fields in accordance with techniques discussed herein. The fields represented in the event limited field picker1202are filtered or “limited” such that the event limited field picker1202displays a list of fields that are relevant to the selected event. Accordingly, the fields shown by the event limited field picker1202in connection with different events may be different.

FIG. 13illustrates generally at1300a search user interface108having an event limited field picker1202in a list view804in accordance with one or more implementations. The example ofFIG. 13is similar to the example ofFIG. 12just discussed, except that the event limited field picker1202is launched from a list view as inFIG. 8rather than the table view ifFIG. 9. More generally, an event limited field picker1202as described herein may be made accessible in any suitable way in connection with a list of individual events and/or representations of individual events exposed within a search user interface108.

The examples depicted inFIGS. 12 and 13additionally illustrate the features of modalization that may be employed in one or more implementations of a search user interface108. Although aspects of modalization are discussed in relation to the event limited field picker1202, modalization as described herein is generally applicable to various different views of event data, user interface portions, and functionality that are accessible via a search user interface108of which the event limited field picker1202is but one illustrative example.

In general, modalization in the context of the example search user interfaces108and techniques discussed herein involves entering a mode in which at least one portion of the user interface (e.g., a pane, pop-up window, frame, tool bar, menu, etc.) operates as a modal element and other portions of the user interface are “locked-out”. In this mode, extended interaction with data presented via the modal element may occur. At the same time, the locked-out portions may be deactivated such that these portion may not be usable while another portion is modalized and/or processing for the locked-out portions may be stopped or paused.

For example, a rendered page, picker, pop-up box other element associated with view of events via a search user interface108may be modalized, in which case other portions of the search user interface108may become locked-out until interaction with the modal element concludes (e.g., the search bar602, fields sidebar608, time range picker603, search results tabs604, etc.). In the case of an on-going active, real-time search, modalizing may cause a pause in the rendering of search results. The search may continue to, but the results are not updated via the events pane so that the user is able to interact with data via the modal element, without worrying about intervening changes that may occur due to the on-going search. For instance, a user may interact to sort or rearrange events in a table view902in which case the events pane606may be modalized. Here, modalization prevents newly obtained results from coming in the table during the user activity, which could interfere with what the user is trying to accomplish.

Additionally, modalization of an element may enable various kinds of interaction that may not be possible while the search results continue to updating. For example, modalization may provide a static view of events, fields, and/or other data that may be review for an extended period of time without the data changing. Moreover, copy, paste, sort, and rearrange operation for a table or list of data may be made available in connection with a modal element. In addition or alternatively, various different action with respect to event data may be made available in connection with a modal element. For instance, options for event-based actions may be exposed via the modal element examples of which include but are not limited to options to build an new event type, define and/or extract new fields, show and/or access a source of an event, generate reports, view statistical information, expose visualization of the data, select or deselect fields, add tags for field-value pairs, review fields and field values, compare field values summary stats for a query, perform custom defined actions, and/or other actions.

An example of modalization with respect to the event limited field picker1202is represented inFIG. 13. Here, operation of the event limited field picker toggle906launches the event limited field picker1202as a modal element. A search user interface108may be configured to visually represent the modalization. By way of example, the event pane606inFIG. 13is shown as a modal1302portion that has different shading/coloration than locked-out1304portions. In this example, the locked-out1304portions are shaded to deemphasize these portions whereas the modal1302portion may remain the same shade/color. Other techniques to distinguish between the active modal element and other portions are also contemplated, such as by visually emphasizing the modal portion1302with highlighting, a color change, a border, or other visual clues.

The event pane606inFIG. 13may remain in the modal mode as long as interaction with the event limited field picker1202continues and/or until a selection is made to leave the modal mode. For example, selecting the event limited field picker toggle906again may cause the event limited field picker1202to close and the row to collapse to return to a former view (e.g., list view804in the example ofFIG. 13). Additionally, this selection switch out of the modal mode, which may reactivate the locked-out1304portions and restart rendering of search results for an on-going search. In one or more implementation, a selection within one of the locked-out1304portions (e.g., shaded portions inFIG. 13) may be interpreted as an attempt to leave the modal mode in which case the selection may also cause switch out of the modal and back to the former view.

In this context, a selection may be detected to launch an event limited field picker1202or other element associated with a search user interface108as a modal element. Responsive to the selection, one or more other elements of the search user interface108may be locked-out and rendering off search results within the user interface may be paused.

FIG. 14illustrates generally at1400some example operations accessible via an event limited field picker1202in accordance with one or more implementations. In particular, a drilldown menu1402is depicted that may be accessible via controls associated with events in the event limited field picker1202. In this example, the drilldown menu1402is configured as a drop down or pop-up box that is exposed responsive to selection of toggle controls associated with individual fields. As mentioned previously, the drilldown menu1402may provide options to refine the search criteria for an active query. Example options include but are not limited to selections to add the individual field in the query, exclude the individual field in the query, or launch a new search using the individual field, as represented inFIG. 14. The query, search results, and corresponding views may be automatically updated based on selections made via the drilldown menu1404or other field selection functionality. By way of example and not limitation, a search query that is updated using a drilldown menu1404, event limited field picker1202, or other field selection functionality to select a field and/or value combinations may be listed with the updates in a search bar602as well as in other views/location in which representations of a search query are made available.

The event limited field picker1202also includes a tag action control1404associated with each field. The tag action control1404is selectable to define a tag for a field-value pair. For example, tag action control1404may be configured to expose an input box (as shown), dialog, or other mechanism that enables definition of a tag based on a corresponding field-value pair. In this example, the field-value pair is a particular combination of the field “clientip” and value “183.60.213.53.” The tag action control1404enables input of a tag name to associate with the field-value pair. Tags that are defined via a tag action control1404or otherwise may be used to refer to field-value pairs in search queries, label instances of field-value pairs using the tag name, or otherwise make use of a field and particular value in combination.

The event limited field picker1202as described herein represents one of many ways in which a search user interface may be configured to enable selection and deselection of fields for different views. Fields may also be selected by way of an all fields list805that may be accessible via a fields sidebar608as discussed previously. The all fields list805may be configured as a picker that is similar to the associated event limited field picker1202except that selections may be made for fields across different events rather than in relation to one selected event. In addition or alternatively, interaction with fields represented in the fields sidebar608may also be employed to make selections regarding various fields. For example, a pop-up field picker for a field selected via the fields sidebar608may be exposed responsive to selection of the field, details of which are discussed in relation to the following figures.

For instance,FIG. 15illustrates generally at1500an example pop-up field picker1502in accordance with one or more implementations. The pop-up field picker1502may be configured as a pop-up or slide out window configured to show details regarding a selected field. Various details may be presented via the pop-up field picker1502and the information that is shown may vary based on the type of field selected. For example, different details may be shown for numeric fields and string fields. The example ofFIG. 15represents a numeric selection1504of a “bytes” field (e.g., bytes has numeric values). Here, the pop-up field picker1502includes a selector1506to designate the field as being selected or not selected. The selector1506may be provided using any suitable user interface instrumentalities. By way of example, the selector1506inFIG. 15is configured as yes and no buttons that may be used to designate the bytes field as selected or not selected. Details shown regarding the selected field may include reports links1508that may be selected to create reports related to the selected field and statistics1510regarding instances of the field and/or field values in event data for a current query. For this numeric field, statistical values for average, minimum, maximum, standard deviation, and so forth may be presented. Additionally, a top values list configured to indicate and/or visually represent occurrence of different values may be shown, such as the “top 10 values” table shown inFIG. 15.

FIG. 16illustrates another example pop-up field picker1502in accordance with one or more implementations. The example ofFIG. 16represents a string selection1504of a “clientip” field (e.g., clientip has string values). In this case, the statistics1510portion of the pop-up field picker1502may be adapted based on the field type. For example, statistical values associated with numeric fields are omitted in the example ofFIG. 16for the string values, since these values may not be relevant. Other adaptations based on field type are also contemplated such as showing different report links1508, providing different visualizations, rearranging the layout of data shown in the pop-up field picker1502, and so forth.

Having considered the foregoing discussion of example user interfaces and details, consider now a discussion of some example procedures in accordance with one more implementations

Example Procedures

This section described illustrative procedures that may be implemented utilizing the previously described systems and devices. Aspects of the procedures described below may be implemented in hardware, firmware, or software, or a combination thereof. The procedures below are shown as a set of blocks that specify operations performed by one or more devices and are not necessarily limited to the orders shown for performing the operations by the respective blocks. In portions of the following discussion, reference may be made to the example components, devices, details and examples ofFIGS. 1-16.

FIG. 17is a flow diagram depicting a procedure1700in an example implementation in which a service facilitate transitions between views based on selections made via a search user interface. In one or more examples, the procedure may be performed via a search service that may be implemented via system100as described herein to enable searches of event data by client application modules106executed via client computing devices.

Data is stored as events each of which includes a portion of the data correlated with a point in time (block1702). For example, a system100and/or corresponding service may obtain, process, index, and store data in one or more data stores103in the manner described in this document. A search user interface is provided for output by a client computing device and configured to enable searches of the data based on search criteria (block1704). Various examples of search user interfaces108configured to provide functionality to perform searches and interact with search results are discussed throughout this document. Responsive to receiving search criteria input via the search user interface, a late binding schema is applied to extract events that match the search criteria (block1706). As noted the late binding schema may reflect extraction rules that are ascertained directly from search criteria provided by clients or based on indications of fields and parameters included with the search criteria. The late binding schema is applied at search time in response to a search query to extract field data, as opposed to technique in which data is parsed into pre-defined items during data ingestion.

Then, the search service may cause generation of a view of the events that are extracted via the search user interface is caused, the search user interface configured to expose one or more user interface instrumentalities operable to manipulate the view (block1708) and transitions of the search user interface to expose different views of the events are facilitated responsive to receiving indications provided using the one or more user interface instrumentalities (block1710).

For example, the search service may conduct searches based upon input obtained to specify views, fields, time constraints, computations, aggregations, and/or other parameters for search queries in accordance with selection made via kinds of user interface instrumentalities. Generally, input generated via the user interface instrumentalities may be used to modify a current search and cause corresponding manipulations of the underlying data and/or view of the data. various kinds of user interface instrumentalities and corresponding transitions are contemplated, including but not limited to the examples discussed in relation toFIGS. 1 to 16above.

By way of example and not limitation, the transitions may include one or various combinations of event view selector transitions1712from one view to another based on selections made via an event view selector802, event limited field picker transitions1714to change fields include in search queries and results based on selections made via an event limited field picker1202, docking header transitions1716associated with switching between a docked view and other views, and/or pop-up field picker transitions1718based on selections made via a pop-up field picker1502, details regarding each of which are described in the preceding discussion of examples ofFIGS. 1 to 16. Other types of transitions that are triggered using various user interface instrumentalities are also contemplated.

FIG. 18is a flow diagram depicting a procedure1800in an example implementation in which a client exposes a search user interface having one or more user interface instrumentalities operable to manipulate a view of event data presented via the search user interface. In one or more examples, the procedure may be performed via client application module106executed via client computing devices. As noted previously, the client application module106may output a search user interface108, which may enable interaction with a search service implemented via system100or otherwise.

A search user interface configured to enable searches of data maintained in a data store by a service is output at a client computing device (block1802). Various different search user interfaces are contemplated, such as the example search user interfaces108discussed throughout this document. Search criteria communicate to the service via the search user interface to cause the service to generate search results by applying a late binding schema to generate events that match the search criteria (block1804). For example, a search query may be specified via search criteria input via a search bar602of a search user interface108as discussed herein. Time constraints for the search query may also be specified using a time range picker603, as additional search criteria, or otherwise. The search query may cause operation by the search service to conduct the search by applying a late binding schema, generate search results, and provide a response back to the client.

Then, a view of the events via the search user interface is displayed based on the search results provided by the service in response to communication of the search criteria (block1806). Various different views mentioned herein may be displayed to provide a representation of event data.

One or more user interface instrumentalities are exposed in the search user interface operable to manipulate the view (block1808). Various kinds of user interface instrumentalities may be exposed in a search user interface108to enable transitions between views and/or manipulations of the views. The instrumentalities may include but not limited to the examples discussed in relation toFIGS. 1 to 16above. In particular, exposure of user interface instrumentalities may include exposing one or a combination of an event view selector (block1810), exposing an event limited field picker (block1812), exposing a docking header (block1814), and/or exposing a pop-up field picker (block1812), each of which is described in detail in the foregoing description.

Responsive to selections made via the one or more user interface instrumentalities, reconfiguration of the search user interface is initiated to present a different view of the events (block1818). For example, various interaction between a client application module106and a search service may occur in response to selections made via the different instrumentalities described herein. The selections may cause an update to search criteria, view selections, field selections and so forth. The client application module106may communicate indications regarding these selections and other parameters to the search service effective to cause the search service to conduct an updated search and provide a response back to the client. The response may include updated search results, field data, views, and/or pre-configured user interface portions that enable to client to form and/or output and update view via the search user interface108.

FIG. 19is a flow diagram depicting a procedure in which an event view selector is exposed in accordance with one or more implementations. Aspects of the procedure may be performed via one or more clients, one or more servers, and/or in a distributed manner using a combination of devices. Display of an event view selector is caused that enables a user to select from among two or more display formats for displaying a plurality of events retrieved by a search of events, each event associated with a time stamp and including a portion of raw machine data, the two or more display formats including a table view that displays for each event in the plurality of events a value for each field in a set of fields, each event's value for a field extracted using an extraction rule from the portion of raw machine data included in that event (block1902). A selection of one of the display formats is received through the event view selector (block1904). Display of the plurality of the event in the selected display format is caused (block1906).

Various different display formats or views are contemplated examples of which were previously discussed previously. For example the display formats may include a raw view, list view, and table view as discussed herein. Raw view may be configured to represent the portions of the raw machine data for events in a raw format and list view may be configured to represent the portion of raw machine data for events in a list in conjunction with the values for each field that are extracted. The table view is configured to represent values for different fields in different columns and different events in different rows. Moreover, the table view is configured to display the values that are extracted for each field in the set of fields without concurrently display of the portions of raw machine data for the events.

The set of fields may include fields that are selected by a user via interaction with user instrumentalities accessible via the user interface to enable selection of fields. These may include the event limited field picker, all fields picker, and pop-up field picker described herein as well as other suitable selection mechanisms. One or more of the fields in the set of fields may also be preconfigured for inclusion in the set of fields. For example, default setting may specify particular fields that are selected for display in table view, list view and/or other view in which field data is exposed. Some fields may be selected automatically by the system based on field type, such as timestamp, source and/or other index fields. Thus, the set of fields may include a combination of user selected fields and fields preconfigured for inclusion.

It is also noted that the event view selector may be employed either before or after results are rendered in the user interface to specify a display format to use for the event data. Thus, in one approach, causing display of the selected view may involve switching from an initial or prior view in which the results are presented to the selected view. Here, the plurality of the events may be displayed in a first display format responsive to a search of events. Then a transition may occur from the first display format to the selected display format based on a selection via the event view selector. In another approach, he plurality of the events are displayed in the selected display format responsive to interaction with the event view selector and without presenting the plurality of the events in a different view prior to the interaction with the event view selector. Various other aspects discussed in relation toFIGS. 1-18may also be incorporated in the example procedure1900ofFIG. 19.

FIG. 20is a flow diagram depicting a procedure2000in which an event limited field picker is exposed in accordance with one or more implementations. Aspects of the procedure may be performed via one or more clients, one or more servers, and/or in a distributed manner using a combination of devices.

Output via a user interface of a plurality of events each of which includes a portion of raw machine data correlated with a time stamp is caused (block2002)

A control operable to launch an event limited field picker in association with a selected event is exposed in the search user interface, the event limited field picker configured to provide a representation of field data for fields corresponding to the selected event that is extracted by application of extraction rules to the portion of the data for the selected event (block2004). Responsive to operation of the control, display of the event limited field picker with the representation of field data for fields corresponding to the selected event is caused (block2006). Various controls that may be employed to launch an event limited field picker are contemplated examples of which have been discussed in this document. For example, a toggle control may be exposed in association with each event in a view of the events as discussed previously. The toggle controls are operable to launch the event limited field picker using field data that is filtered for a corresponding event (e.g., limited to the event).

The representation of field data for fields corresponding to the selected event includes field headers and corresponding field values that are extracted by application of extraction rules. For example, a list of field headers may be shown in a first column with corresponding field values that are extracted by application of extraction rules shown in a second column as shown inFIGS. 12 and 13. The event limited field picker may additionally display a representation of the portion of the raw machine data for the selected event. In addition or alternatively, a list of fields associated with a selected event may be shown along with user interface instrumentalities, such as check boxes, that are operable to select and deselect fields. In response to receiving an indication of one or more fields selected via the event limited field picker, visibility may be set for one or more fields in different views of the events in accordance with the indication. Selected fields and values may then be presented in table view, list view other views. The event limited field may be configured to indicate fields that are already selected and other fields associated with the selected event that are available for selection, using the check boxes or other visual indications. As discussed herein, the event limited field picker may also provide a representation of statistics for the plurality of events as a whole in connection with the fields and field values for the selected event. This enables a user to compare field values for the selected event with the statistics for all of the events returned in a query. Various other aspects discussed in relation toFIGS. 1-18may also be incorporated in the example procedure2000ofFIG. 20.

In addition to the foregoing details and examples, implementations of methods, computer readable media and systems may involve display of a field information panel, examples of which include the event-limited field and pop-up field picker, and other user interface elements and instrumentalities discussed previously. Implementations may include causing display of a plurality of events, each event associated with a time stamp and including a portion of raw machine data; receiving a selection of a particular event; and based on receiving the selection of the particular event, causing display of a field information panel that displays identifiers for each field in a set of fields having corresponding values for the particular event, each field defined by an extraction rule that extracts the corresponding value for the field from the portion of raw machine data in that particular event.

The identifier for a field may be a name that can be used to reference the field in a search query. The field information panel may display the corresponding value for each field for which an identifier is displayed in the panel. The field information panel may also display a statistic based on the corresponding value for each field for which an identifier is displayed in the panel. Further the field information panel may display a statistic based on the corresponding value for each field for which an identifier is displayed in the panel, with the statistic representing a percentage of events that have the corresponding value for the field relative to a set of events that were retrieved by a search query and that include at least the plurality of displayed events. In an additional example, the field information panel may display both the corresponding value for each field for which an identifier is displayed in the panel and a statistic based on the corresponding value. Further, the field information panel may display a portion of raw machine data included in the selected event. In addition or alternatively, the field information panel may display both the corresponding value for each field for which an identifier is displayed in the panel and the portion of raw machine data included in the selected event.

In other examples, the plurality of displayed events may be included in a set of events retrieved by a search query. In this case implementations may further include causing display in the field information panel of the corresponding value for each field for which an identifier is displayed in the panel; receiving a selection corresponding to a particular field for which an identifier is displayed in the panel;

based on receiving the selection corresponding to the particular field, identifying a subset of the set of events that have a same value for the particular field as the selected particular event; and causing display of the subset of the set of events

In other examples, the plurality of displayed events is included in a set of events retrieved by a search query. In this case, implementations may further include causing display in the field information panel of the corresponding value for each field for which an identifier is displayed in the panel; receiving a selection corresponding to a particular field for which an identifier is displayed in the panel; based on receiving the selection corresponding to the particular field, identifying a subset of the set of events that have a same value for the particular field as the selected particular event; causing display of the subset of the set of events; causing emphasis of the same value in each event in the displayed subset of the set of events.

Implementations may also include causing display in the field information panel of an interactive element (e.g., check box or a user interface instrumentality) for selecting one or more particular fields associated with the displayed identifiers. In addition, the field information panel may display an interactive element for selecting one or more particular fields associated with the displayed identifiers and receive a selection through the interactive element of one or more particular fields associated with the displayed identifiers. Then, events retrieved using a search query may be displayed in a table format (e.g., table view), the table format including information about values for the displayed events for the selected particular fields.

Additional implementations include causing display in the field information panel of an interactive element for selecting one or more particular fields associated with the displayed identifiers; receiving a selection through the interactive element of one or more particular fields associated with the displayed identifiers; and causing display in a list format of events retrieved using a search query, the list format including for each displayed event information about the values for that event for the selected particular fields.

Implementation may include causing display in the field information panel of an interactive element for selecting one or more particular fields associated with the displayed identifiers; receiving a selection through the interactive element of one or more particular fields associated with the displayed identifiers; and causing display in a list format of events retrieved using a search query, the list format including for each displayed event information about the values for that event for the selected particular fields, the information corresponding to a given event displayed proximate to raw machine data included in the given event.

Still further, implementations may include causing display in the field information panel of an interactive element for selecting one or more particular fields associated with the displayed identifiers; receiving a selection through the interactive element of one or more particular fields associated with the displayed identifiers; and causing display in a second field information panel an identification of the selected one or more fields, the second field information panel displaying additional non-selected fields defined for events retrieved by a search query, the second field information panel displayed concurrently with the events retrieved by the search query.

Further, the portion of raw machine data in at least one of the displayed events may include log data. In addition or alternatively, the portion of raw machine data in at least one of the displayed events may include wire data. In addition or alternatively, the portion of raw machine data in at least one of the displayed events may include unstructured data.

Having considered the foregoing discussion of example user interfaces and procedures, consider now a discussion of an example system and device in accordance with one more implementations.

Example System and Device

FIG. 21illustrates an example system generally at2100that includes an example computing device2102that is representative of one or more computing systems and/or devices that may implement the various techniques described herein. This is illustrated through inclusion of the client application module106that is representative of functionality to interact with a search service2103, e.g., to specify and manage searches using a late-binding schema and events as described above. The computing device2002may be, for example, a server of a service provider, a device associated with a client (e.g., a client device), an on-chip system, and/or any other suitable computing device or computing system.

The example computing device2102as illustrated includes a processing system2104, one or more computer-readable media2106, and one or more I/O interface2108that are communicatively coupled, one to another. Although not shown, the computing device2102may further include a system bus or other data and command transfer system that couples the various components, one to another. A system bus can include any one or combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and/or a processor or local bus that utilizes any of a variety of bus architectures. A variety of other examples are also contemplated, such as control and data lines.

Combinations of the foregoing may also be employed to implement various techniques described herein. Accordingly, software, hardware, or executable modules may be implemented as one or more instructions and/or logic embodied on some form of computer-readable storage media and/or by one or more hardware elements2110. The computing device2102may be configured to implement particular instructions and/or functions corresponding to the software and/or hardware modules. Accordingly, implementation of a module that is executable by the computing device2102as software may be achieved at least partially in hardware, e.g., through use of computer-readable storage media and/or hardware elements2110of the processing system2104. The instructions and/or functions may be executable/operable by one or more articles of manufacture (for example, one or more computing devices2102and/or processing systems2104) to implement techniques, modules, and examples described herein.

The cloud2114includes and/or is representative of a platform2116for resources2118. The platform2116abstracts underlying functionality of hardware (e.g., servers) and software resources of the cloud2114. The resources2118may include applications and/or data that can be utilized while computer processing is executed on servers that are remote from the computing device2102. Resources2118can also include services provided over the Internet and/or through a subscriber network, such as a cellular or Wi-Fi network.

The platform2116may abstract resources and functions to connect the computing device2102with other computing devices. The platform2116may also serve to abstract scaling of resources to provide a corresponding level of scale to encountered demand for the resources2118that are implemented via the platform2116. Accordingly, in an interconnected device embodiment, implementation of functionality described herein may be distributed throughout the system2100. For example, the functionality may be implemented in part on the computing device2102as well as via the platform2116that abstracts the functionality of the cloud2114.

CONCLUSION