U.S. patent application number 14/448081 was filed with the patent office on 2016-01-21 for wizard for creating a correlation search.
The applicant listed for this patent is Splunk Inc.. Invention is credited to David Hazekamp, Lucas Murphey.
Application Number | 20160019316 14/448081 |
Document ID | / |
Family ID | 55074775 |
Filed Date | 2016-01-21 |
United States Patent
Application |
20160019316 |
Kind Code |
A1 |
Murphey; Lucas ; et
al. |
January 21, 2016 |
WIZARD FOR CREATING A CORRELATION SEARCH
Abstract
One or more processing devices provide a wizard for generating a
correlation search, the wizard facilitating user input of (i) one
or more search criteria for a search query of the correlation
search, (ii) a triggering condition to be applied to a dataset
produced by the search query, and (iii) one or more actions to be
performed when the dataset produced by the search query satisfies
the triggering condition, and causing generation of the correlation
search based on the user input.
Inventors: |
Murphey; Lucas; (Wadsworth,
IL) ; Hazekamp; David; (Tinley Park, IL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Splunk Inc. |
San Francisco |
CA |
US |
|
|
Family ID: |
55074775 |
Appl. No.: |
14/448081 |
Filed: |
July 31, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62027242 |
Jul 21, 2014 |
|
|
|
Current U.S.
Class: |
707/722 |
Current CPC
Class: |
G06F 16/907 20190101;
G06F 16/906 20190101; G06F 16/90335 20190101; G06F 16/9032
20190101 |
International
Class: |
G06F 17/30 20060101
G06F017/30 |
Claims
1. A method comprising: causing display of a sequence of graphical
user interfaces for facilitating user input for generation of a
correlation search, wherein the user input comprises (i) one or
more search criteria for a search query of the correlation search,
(ii) a triggering condition comprising criteria to evaluate a
dataset that the search query produces when applied to a
non-tabular data store the triggering condition causing execution
of one or more actions when the triggering condition is satisfied,
and (iii) the one or more actions that execute when the triggering
condition is satisfied; causing generation of the correlation
search before execution of the search query by storing in memory
the search criteria for the search query, the triggering condition,
and the one or more actions; wherein the sequence of graphical user
interfaces for generating the correlation search comprises (i) a
graphical user interface for selecting the non-tabular data store
against which to run the search query to produce the dataset, (ii)
a graphical user interface for receiving a time range, the time
range defining a scope of data of the non-tabular data store to be
searched using the search query, and (iii) a graphical user
interface for defining the criteria of the triggering condition;
and wherein the method is performed by one or more processing
devices.
2. The method of claim 1, wherein causing generation of the
correlation search comprises: receiving the one or more search
criteria; causing display of the search query in the sequence of
graphical user interfaces; receiving a user request to test an
execution of the search query; causing the execution of the search
query; and causing display of results from the search query.
3. The method of claim 1, further comprising: causing display in
the sequence of graphical user interfaces of a plurality of
statistics types that can be used for producing an aggregate on
data; receiving through the sequence of graphical user interfaces
input identifying one of the plurality of statistics types;
receiving input identifying an evaluation of the aggregate produced
by the statistics type; and wherein causing generation of the
correlation search comprises including the evaluation of the
aggregate produced by the statistics type in the search query.
4. The method of claim 1, further comprising: causing display in
the sequence of graphical user interfaces of a plurality of
statistics types that can be used for producing an aggregate on
data; receiving through the sequence of graphical user interfaces
input identifying one of the plurality of statistics types;
receiving input identifying an evaluation of the aggregate produced
by the statistics type; and wherein causing generation of the
correlation search comprises including the evaluation of the
aggregate produced by the statistics type in the triggering
condition of the correlation search.
5. The method of claim 1, wherein causing generation of the
correlation search comprises: receiving a user request to test an
execution of the search query with the triggering condition; and
obtaining, for presentation, the dataset produced based on the
execution of the search query with the triggering condition.
6. The method of claim 1, wherein causing generation of the
correlation search comprises: displaying in the sequence of
graphical user interfaces options for the one or more actions to be
performed when the dataset produced by search query satisfies the
triggering condition; receiving input identifying the one or more
actions to be performed; and associating the identified one or more
actions with the triggering condition.
7. The method of claim 1, wherein causing generation of the
correlation search comprises: causing the search query included in
the correlation search to be displayed in the sequence of graphical
user interfaces.
8. The method of claim 1, wherein the one or more actions comprise
one or more of updating a display with an entry corresponding to
satisfaction of the triggering condition, adjusting a score of an
object to which data causing satisfaction of the triggering
condition pertains, or sending a notification indicating
satisfaction of the triggering condition.
9. (canceled)
10. The method of claim 1, wherein the sequence of graphical user
interfaces includes an indication of whether the search query
parses successfully.
11. The method of claim 1, wherein the search query corresponds to
a search language that uses a late binding schema.
12. The method of claim 1, further comprising causing execution of
the search query against raw machine data.
13. The method of claim 1, further comprising causing execution of
the search query against time-stamped events that each include a
portion of raw machine data.
14. The method of claim 1, wherein a calculation of a statistics
type is included in the search query.
15. The method of claim 1, wherein an evaluation of a calculation
of a statistics type is included in the search query.
16. The method of claim 1, wherein the dataset satisfies the
triggering condition each time the dataset includes an indicator
that the search criteria of the search query are satisfied.
17. The method of claim 1, wherein the dataset includes a number of
times the search criteria of the query are satisfied, and the
dataset satisfies the triggering condition when the number of times
exceeds a threshold.
18. The method of claim 1, wherein the dataset satisfies the
triggering condition when an aggregated statistic pertaining to the
dataset exceeds a threshold, is under a threshold, or is within a
specified range.
19. A system comprising: a memory; and a processing device coupled
with the memory to: cause display of a sequence of graphical user
interfaces for facilitating user input for generation of a
correlation search, wherein the user input comprises (i) one or
more search criteria for a search query of the correlation search,
(ii) a triggering condition comprising criteria to evaluate a
dataset that the search query produces when applied to a
non-tabular data store, the triggering condition causing execution
of one or more actions when the triggering condition is satisfied,
and (iii) the one or more actions that execute when the triggering
condition is satisfied; cause generation of the correlation search
before execution of the search query by storing in memory the
search criteria for the search query, the triggering condition, and
the one or more actions; and wherein the sequence of graphical user
interfaces for generating the correlation search comprises (i) a
graphical user interface for selecting the non-tabular data store
against which to run the search query to produce the dataset, (ii)
a graphical user interface for receiving a time range, the time
range defining a scope of data of the non-tabular data store to be
searched using the search query, and (iii) a graphical user
interface for defining the criteria of the triggering
condition.
20. The system of claim 19, wherein to cause generation of the
correlation search comprises: receiving the one or more search
criteria; causing display of the search query in the sequence of
graphical user interfaces; receiving a user request to test an
execution of the search query; causing the execution of the search
query; and causing display of results from the search query.
21. The system of claim 19, wherein to cause generation of the
correlation search comprises: receiving a user request to test an
execution of the search query with the triggering condition; and
obtaining, for presentation, the dataset produced based on the
execution of the search query with the triggering condition.
22. The system of claim 19, wherein to cause generation of the
correlation search comprises: displaying in the sequence of
graphical user interfaces options for the one or more actions to be
performed when the dataset produced by search query satisfies the
triggering condition; receiving input identifying the one or more
actions to be performed; and associating the identified one or more
actions with the triggering condition.
23. The system of claim 19, wherein to cause generation of the
correlation search comprises: causing the search query included in
the correlation search to be displayed in the sequence of graphical
user interfaces.
24. The system of claim 19, wherein the one or more actions
comprise one or more of updating a display with an entry
corresponding to satisfaction of the triggering condition,
adjusting a score of an object to which data causing satisfaction
of the triggering condition pertains, or sending a notification
indicating satisfaction of the triggering condition.
25. A non-transitory computer readable storage medium encoding
instructions thereon that, in response to execution by one or more
processing devices, cause the processing device to perform
operations comprising: causing display of a sequence of graphical
user interfaces for facilitating user input for generation of a
correlation search, wherein the user input comprises (i) one or
more search criteria for a search query of the correlation search,
(ii) a triggering condition comprising criteria to evaluate a
dataset that the search query produces when applied to a
non-tabular data store, the triggering condition causing execution
of one or more actions when the triggering condition is satisfied,
and (iii) the one or more actions that execute when the triggering
condition is satisfied; causing generation of the correlation
search before execution of the search query by storing in memory
the search criteria for the search query, the triggering condition,
and the one or more actions; and wherein the sequence of graphical
user interfaces for generating the correlation search comprises (i)
a graphical user interface for selecting the non-tabular data store
against which to run the search query to produce the dataset, (ii)
a graphical user interface for receiving a time range, the time
range defining a scope of data of the non-tabular data store to be
searched using the search query, and (iii) a graphical user
interface for defining the criteria of the triggering
condition.
26-30. (canceled)
31. The method of claim 1, wherein causing generation of the
correlation search comprises generating search processing language
that includes the search query and the criteria for the triggering
condition.
32. The method of claim 31, further comprising causing a preview in
the wizard of the search processing language forming at least part
of the correlation search.
33. The method of claim 31, further comprising: causing a preview,
in the sequence of graphical user interfaces, of search processing
language forming the search query of the correlation search;
enabling a user to execute, from the preview, the search query
against the non-tabular data store to cause display of a sample
dataset.
34. The method of claim 31, wherein the correlation search
comprises a single textual string having the search query and a
processing command for the criteria on which the triggering
condition is based.
35. The method of claim 1, wherein the sequence of graphical user
interfaces includes a plurality of separate graphical user
interfaces comprising a GUI element for requesting a graphical user
interface that is next in the sequence of graphical user
interfaces.
36. The method of claim 1, wherein the graphical user interface for
selection of the non-tabular data store is separate from the
graphical user interface for defining the criteria of the
triggering condition.
Description
RELATED APPLICATION
[0001] This application is related to and claims the benefit of
U.S. Provisional Patent Application No. 62/027,242 filed Jul. 21,
2014, which is hereby incorporated by reference herein.
TECHNICAL FIELD
[0002] The present disclosure relates to correlation searches and,
more particularly, to a wizard for creating a correlation
search.
BACKGROUND
[0003] Modern data centers often comprise thousands of hosts that
operate collectively to service requests from even larger numbers
of remote clients. During operation, components of these data
centers can produce significant volumes of machine-generated data.
The unstructured nature of much of this data has made it
challenging to perform indexing and searching operations because of
the difficulty of applying semantic meaning to unstructured data.
As the number of hosts and clients associated with a data center
continues to grow, processing large volumes of machine-generated
data in an intelligent manner and effectively presenting the
results of such processing continues to be a priority.
BRIEF DESCRIPTION OF THE DRAWINGS
[0004] The present disclosure will be understood more fully from
the detailed description given below and from the accompanying
drawings of various implementations of the disclosure.
[0005] FIG. 1 illustrates an example data structure that can be
utilized by the systems and methods described herein for creating
and/or editing a correlation search via a wizard, in accordance
with one or more aspects of the present disclosure.
[0006] FIG. 2 illustrates an example portion of a graphical user
interface (GUI) of a wizard for initiating a guided mode for
creating and/or editing a correlation search, in accordance with
one or more aspects of the present disclosure.
[0007] FIG. 3 illustrates an example of a GUI of a wizard for
providing an overview of the stages pertaining to the creation
and/or editing of a correlation search, in accordance with one or
more aspects of the present disclosure.
[0008] FIG. 4 illustrates an example of a GUI of a wizard for
defining data to be searched for a search query of a correlation
search, in accordance with one or more aspects of the present
disclosure.
[0009] FIG. 5 illustrates an example of a GUI of a wizard for
defining characteristics of a data source for the data model source
type, in accordance with one or more aspects of the present
disclosure.
[0010] FIG. 6 illustrates an example list of options of the
pre-built data models, which a user can select from a drop-down
menu, in accordance with one or more aspects of the present
disclosure.
[0011] FIG. 7 illustrates an example list of options of the
pre-built data sub-models, which a user can select from a drop-down
menu, in accordance with one or more aspects of the present
disclosure.
[0012] FIG. 8 illustrates an example of a GUI for presenting the
fields of a data sub-model, in accordance with one or more aspects
of the present disclosure.
[0013] FIG. 9 illustrates an example of a GUI of a wizard of
options of pre-built lookup files, in accordance with one or more
aspects of the present disclosure.
[0014] FIG. 10 illustrates an example GUI of a wizard for defining
a time range pertaining to the source data to be searched using the
search query of the correlation search, in accordance with one or
more aspects of the present disclosure.
[0015] FIG. 11 illustrates an example drop-down menu including
various time range options for user selection, in accordance with
one or more aspects of the present disclosure.
[0016] FIG. 12 illustrates an example GUI of a wizard for
displaying a search query in the search processing language, in
accordance with one or more aspects of the present disclosure.
[0017] FIG. 13 illustrates an example GUI of a wizard for defining
a filter for the search query of the correlation search, in
accordance with one or more aspects of the present disclosure.
[0018] FIG. 14 illustrates an example of a GUI for testing the
filter criteria for a search query, in accordance with one or more
aspects of the present disclosure.
[0019] FIG. 15A illustrates an example GUI of a wizard for
facilitating user input to request an aggregation of the dataset to
be produced by the search query of the correlation search, in
accordance with one or more aspects of the present disclosure.
[0020] FIG. 15B illustrates an example GUI of a wizard for defining
an aggregate, in accordance with one or more aspects of the present
disclosure.
[0021] FIG. 16 illustrates an example GUI of a wizard for
displaying multiple aggregates, and allowing a user to edit or
delete any of the displayed aggregates, and/or to create additional
aggregates, in accordance with one or more aspects of the present
disclosure.
[0022] FIG. 17 illustrates an example GUI of a wizard for defining
how to separate aggregated statistics pertaining to the dataset
produced by a search query by fields, in accordance with one or
more aspects of the present disclosure.
[0023] FIG. 18 illustrates an example GUI of a wizard for
facilitating user input to assign an alias to a selected field for
a split-by operation, in accordance with one or more aspects of the
present disclosure.
[0024] FIG. 19 illustrates an example of a GUI of a wizard for
defining one or more triggering conditions for a correlation
search, in accordance with one or more aspects of the present
disclosure.
[0025] FIG. 20 illustrates an example of a GUI of the wizard for
testing the execution of the search query with the triggering
condition, in accordance with one or more aspects of the present
disclosure.
[0026] FIGS. 21-22 illustrate example GUIs, pertaining to a wizard,
for testing the search query with the triggering condition, in
accordance with one or more aspects of the present disclosure.
[0027] FIG. 23 illustrates an example of a GUI of a wizard for
defining one or more actions for a correlation search, in
accordance with one or more aspects of the present disclosure.
[0028] FIG. 24 is a flow diagram of an implementation of a method
for creating and/or editing a correlation search via a wizard, in
accordance with one or more aspects of the present disclosure.
[0029] FIG. 25 is a flow diagram of an implementation of a method
for defining a search query for a correlation search via a wizard,
in accordance with one or more aspects of the present
disclosure.
[0030] FIG. 26 is a flow diagram of an implementation of a method
for defining a search query for a correlation search via a wizard,
in accordance with one or more aspects of the present
disclosure.
[0031] FIG. 27 is a flow diagram of an implementation of a method
for defining a triggering condition for a correlation search via a
wizard, in accordance with one or more aspects of the present
disclosure.
[0032] FIG. 28 is a flow diagram of an implementation of a method
for defining one or more actions for a correlation search via a
wizard, in accordance with one or more aspects of the present
disclosure.
[0033] FIGS. 29A-B are block diagrams of an implementation of
creating and/or editing a correlation search via a wizard, in
accordance with one or more aspects of the present disclosure.
[0034] FIG. 30 presents a block diagram of an event-processing
system in accordance with one or more aspects of the present
disclosure.
[0035] FIG. 31 presents a flowchart illustrating how indexers
process, index, and store data received from forwarders in
accordance with one or more aspects of the present disclosure.
[0036] FIG. 32 presents a flowchart illustrating how a search head
and indexers perform a search query in accordance with one or more
aspects of the present disclosure.
[0037] FIG. 33 presents a block diagram of a system for processing
search requests that uses extraction rules for field values in
accordance with one or more aspects of the present disclosure.
[0038] FIG. 34 illustrates an exemplary search query received from
a client and executed by search peers in accordance with one or
more aspects of the present disclosure.
[0039] FIG. 35A illustrates a search screen in accordance with one
or more aspects of the present disclosure.
[0040] FIG. 35B illustrates a data summary dialog that enables a
user to select various data sources in accordance with one or more
aspects of the present disclosure.
[0041] FIG. 36A illustrates a key indicators view in accordance
with one or more aspects of the present disclosure.
[0042] FIG. 36B illustrates an incident review dashboard in
accordance with one or more aspects of the present disclosure.
[0043] FIG. 36C illustrates a proactive monitoring tree in
accordance with one or more aspects of the present disclosure.
[0044] FIG. 36D illustrates a screen displaying both log data and
performance data in accordance with one or more aspects of the
present disclosure.
[0045] FIG. 37 depicts a block diagram of an example computing
device operating in accordance with one or more aspects of the
present disclosure.
DETAILED DESCRIPTION
[0046] The present disclosure is directed to a wizard for
generating a correlation search. A correlation search (also
referred to as a trigger-based search) represents a search query
that has a triggering condition and one or more actions that
correspond to the trigger condition.
[0047] An example data aggregation and analysis system can
aggregate heterogeneous machine-generated data received from
various sources, including servers, databases, applications,
networks, etc. The aggregated source data can include multiple
events. An event can be represented by a data structure that is
associated with a certain point in time and comprises a portion of
raw machine data (i.e., machine-generated data). Events are
described in greater detail below in conjunction with FIG. 31. The
system can be configured to perform real-time indexing of the
source data and to execute real-time, scheduled, or historic
searches on the source data.
[0048] The example data aggregation and analysis system can provide
a wizard that facilitates user input to create and edit correlation
searches more efficiently than traditional solutions by guiding a
user through the creation process with tools within the wizard. A
wizard hereinafter refers to a sequence of graphical user
interfaces (GUIs) that lead a user through a series of stages for
achieving a certain result (e.g., the creation of a correlation
search).
[0049] When a search query is executed, the search query can
produce a dataset (hereinafter also referred to as "results") that
satisfies the search criteria for the search query. The example
data aggregation and analysis system can execute a search query to
evaluate the data relative to the search criteria to produce a
resulting dataset. The resulting dataset may comprise one or more
data items representing one or more portions of the source data
that satisfy the search criteria. Alternatively, the resulting
dataset may just include an indication that the search criteria
have been satisfied. Yet alternatively, the resulting dataset may
include a number indicating how many times the search criteria have
been satisfied.
[0050] The heterogeneous machine-generated data that is being
searched can include logs that track login attempts that end-users
make when logging into various applications (e.g., email
application, customer relationship management (CRM) application,
human capital management (HCM) application, etc.). A user may wish
to receive up-to-date information indicating how many application
login attempts have failed and can initiate a search query to
obtain results indicating the application logins attempts that may
have failed.
[0051] The data in the logs can represent a large number of
applications, a large number of users, and a large number of login
attempts, and thus, the search results may include an extensive
amount of information. The user may wish to reduce the scope of the
search to a specific application. For example, the user may wish to
have information indicating how many email application login
attempts have failed. The user may wish to receive information only
when the search results satisfy certain triggering conditions.
[0052] A triggering condition can be any condition that is intended
to trigger a specific action. An example triggering condition can
cause an action every time search criteria are satisfied (e.g.,
every time a specific user has a failed authentication attempt).
Another example triggering condition can cause can action when a
number specifying how many times search criteria have been
satisfied exceeds a threshold (e.g., when the number of failed
authentication logins of a specific user exceeds 5). Yet another
example triggering condition pertains to aggregating a dataset
returned by the search query to form statistics pertaining to one
or more attributes of the dataset that were used for aggregation,
where the example triggering condition can cause an action when the
aggregated statistics exceeds a threshold, is less than a
threshold, or falls within a specified range. For example, a
dataset returned by the search query may include failed
authentication attempts for logging into any application (e.g.,
email application, CRM application, HCM application, etc.) and
initiated by numerous source IP (Internet Protocol) addresses; the
dataset may be aggregated to produce counts of failed
authentication attempts on a per application per source basis
(i.e., first aggregated by application and then further aggregated
by source); and the triggering condition may include triggering an
action when any of the counts exceeds a threshold. For example, the
user may wish to receive information only when six or more login
attempts for the email application have failed within the last
hour. It should be noted that in some implementations, the
evaluation of the aggregated statistics can be handled as part of
the search query, and not as part of the triggering condition.
[0053] Implementations of the present disclosure provide a wizard
for facilitating user input for creating and editing correlation
searches. The wizard can include one or more GUIs, which each can
include various GUI elements, to facilitate user input that defines
search criteria for a search query, input that defines one or more
trigger conditions pertaining to the dataset produced by the search
query, and input that specifies one or more actions to take when
the one or more trigger conditions are met for creating and/or
editing a correlation search.
[0054] FIG. 1 illustrates an example data structure that can be
utilized by the systems and methods described herein for creating
and/or editing a correlation search via a wizard, in accordance
with one or more aspects of the present disclosure. As
schematically illustrated by FIG. 1, a correlation search 150 can
include search criteria 153 for a search query, one or more
triggering conditions 155 to be applied to a dataset that is
produced by the search query, and one or more actions 157 to be
performed when the triggering conditions 155 are satisfied by the
dataset that is produced by the search query.
[0055] FIGS. 2-23 illustrate examples of GUIs pertaining to a
wizard, which can be rendered by a client computing device, for
creating and/or editing a correlation search, in accordance with
one or more aspects of the present disclosure.
[0056] FIG. 2 illustrates an example portion of an overview GUI 250
of a wizard for creating and/or editing a correlation search, in
accordance with one or more aspects of the present disclosure. As
illustrated by FIG. 2, the client computing device can render the
GUI 250. The wizard can include a collection of GUIs. The GUIs of
the wizard can include one or more GUI elements to receive input
and to display data. The GUI elements can include, for example, and
are not limited to, a text box, a button, a link, a selection
button, a drop down menu, a sliding bar, a selection button,
etc.
[0057] The GUI 250 can receive user input specifying the name of
the correlation search via a text box 251. If the correlation
search specified in the text box 251 has been previously created,
the GUI 250 can display information about that correlation search.
For example, the GUI 250 can display application context (e.g., a
particular application) 253 pertaining to the correlation search,
the description 255 of the correlation search, a search query
presented in the search processing language 257 for the correlation
search, and time parameters 261 for the search query. The GUI 250
may also display additional information about the correlation
search (e.g., one or more actions to be taken when a triggering
condition of the correlation search is met), as will be discussed
in more detail below in conjunction with FIG. 23.
[0058] The user can view the displayed information about the
correlation search and modify data displayed in the GUI 250 to edit
the correlation search. The GUI 250 can include a link 259, which
can be selected, to initiate a guided mode for editing a
correlation search. The guided mode can present a sequence of
additional GUIs of the wizard, starting with GUI 350 discussed in
more detail below in conjunction with FIG. 3.
[0059] Alternatively, if the correlation search specified in text
box 251 has not been previously created, the creation of a new
correlation search can begin, which may involve receiving user
input identifying application context 253 and a description 255 for
the new correlation search, and receiving user selection of link
259 to initiate a guided mode for creating the new correlation
search. In response to the user selection of link 259, GUI 350 of
FIG. 3 can be displayed to the user.
[0060] FIG. 3 illustrates an example of a GUI 350 of a wizard for
providing an overview of the stages pertaining to the creation
and/or editing of a correlation search, in accordance with one or
more aspects of the present disclosure. One or more GUIs of the
wizard can include GUI elements (e.g., buttons) to allow a user to
request a GUI that is next in the sequence of GUIs or that is a
previous GUI in the sequence of GUIs. For example, GUI 350 can
include a button 353 that can be selected to request the next GUI
in the sequence of GUIs of the wizard.
[0061] In one implementation, the stages 351 presented in the GUI
350 include (i) defining the data (e.g., events) to be searched,
followed by (ii) defining how to filter the data that is to be
searched, followed by (iii) defining how to aggregate the dataset
that is produced by the search query, followed by (iv) defining a
triggering condition, followed by (v) defining actions to be
performed when the triggering condition is met.
[0062] FIGS. 4-18, which are described in greater detail below,
illustrate examples of GUIs of a wizard for defining a search query
for a correlation search, in accordance with one or more aspects of
the present disclosure. Defining a search query can include
selecting the data of interest, filtering the data, and aggregating
the data. FIG. 19, which is described in greater detail below,
illustrates an example GUI of the wizard for defining a triggering
condition for a correlation search, in accordance with one or more
aspects of the present disclosure. FIGS. 20-22, which are described
in greater detail below, illustrate examples of GUIs for testing
the search criteria and the triggering condition, in accordance
with one or more aspects of the present disclosure. FIG. 23, which
is described in greater detail below, illustrates an example GUI of
the wizard for defining one or more actions to be performed for the
correlation search, in accordance with one or more aspects of the
present disclosure.
[0063] FIG. 4 illustrates an example of a GUI 450 of a wizard for
defining data to be searched using a search query of a correlation
search, in accordance with one or more aspects of the present
disclosure. As described above, the data aggregation and analysis
system can aggregate heterogeneous machine-generated data received
from various sources (e.g., servers, databases, applications,
networks, etc.). A user may not be interested in searching the
entire source data, but may be interested in searching a subset of
the data, for example, only the source data that pertains to
authentication, and in particular, failed application login
attempts. For example, the heterogeneous machine-generated data can
include logs pertaining to multiple applications which end-users
are logging into. The logs may be provided by various hardware
vendors and software vendors and can be in different formats.
[0064] The data aggregation and analysis system can provide one or
more pre-built, pre-defined data models and/or one or more
pre-built lookup files to allow the data (e.g., logs), which are in
the various formats, to be searched uniformly irrespective of the
particular vendor that is providing the data. The data aggregation
and analysis system can also provide one or more GUIs to facilitate
user input for creating a data model, data sub-model, and/or a
lookup file.
[0065] A lookup file is a file that includes data fields for a
particular set of events. For example, a lookup file can include
data fields for events pertaining to network assets. The lookup
file can include fields representing an IP address, a server name,
a user device identifier, etc. In one implementation, a lookup file
is in a CSV (comma separated value) file format.
[0066] A data model is a hierarchically structured search-time
mapping of semantic knowledge about one or more datasets. The data
model encodes the domain knowledge necessary to build a variety of
specialized searches of those datasets. Examples of a pre-built
data model can include, and are not limited to, data models
pertaining to authentication, databases, electronic mail, intrusion
detection, malware, application state, alerts, compute inventory,
network sessions, network traffic, performance, audits, updates,
and vulnerabilities.
[0067] A data model can include one or more data sub-models to
group data according to certain criteria (thereby grouping together
data of a common type). For example, the authentication data model
can pertain to events for all types of authentication (e.g.,
successful authentication, failed authentication, privileged
authentication). There can be data sub-models for the
authentication data model to group data pertaining to certain
groups of events. For example, the authentication data model can
have a "Successful_Authentication" data sub-model, a
"Failed_Authentication" data sub-model, a
"Privileged_Authentication" data sub-model, etc. A user that is
interested in only failed login attempts can select the
"Failed_Authentication" data sub-model to further narrow the scope
of the data to be searched to data pertaining to failed
authentication.
[0068] Each data model or sub-model can have attributes (also
hereinafter referred to as "fields") that are included in one or
more events in the model or sub-model. For example, the
authentication data model can have fields that are related to
events pertaining to authentication. For example, the
authentication data model can have a field indicating the machine
for which a login is being attempted, a field indicating the status
of whether the login attempt is successful or has failed, a field
indicating the time the login attempt was made, etc.
[0069] A data sub-model is a child of a parent data model. It
includes a subset of the events include in the parent data model.
In one implementation, a data sub-model may have one or more
attributes that its parent has, and it may have additional
attributes that its parent doesn't have. For example, the data
sub-model "Failed_Authentication" can be a child of the
"Authentication" data model and the events in the
"Failed_Authentication" data sub-model may be a subset of the
events in the "Authentication" data model.
[0070] The events included in a data model or sub-model may be
enumerated. Alternatively, the events that should be included may
be defined by a search query, so the actual events in the data
model or sub-model depends on the data to which the data model or
sub-model is applied.
[0071] The GUI 450 can include a drop-down menu 451 to present data
source options, such as a data model or a lookup file or any other
source of data that is amenable to a search query. For example, a
user that is interested in information pertaining to
authentication, and in particular, application login attempts, may
select "Data model" as the source type from the drop-down menu 451.
In response, GUI 550 of FIG. 5 is presented. Alternatively, if a
user selects "Lookup file" as the source type from the drop-down
menu 451, GUI 900 of FIG. 9 is presented.
[0072] FIG. 5 illustrates an example of a GUI 550 of a wizard for
defining characteristics of a data source for the data model source
type, in accordance with one or more aspects of the present
disclosure. When the data model is selected as a type of data
source, the GUI 550 can include a drop-down menu 553 to provide the
options of the pre-built data models, which a user can select, and
a drop-down menu 555 to provide the options of the pre-built data
sub-models, which a user can select. For example, a user can select
an "Authentication" data model to search the data (e.g., logs)
pertaining to authentication and a "Failed_Authentication" data
sub-model.
[0073] FIG. 6 illustrates an example list 650 of options of the
pre-built data models, which a user can select from a drop-down
menu (e.g., drop-down menu 553 in FIG. 5), in accordance with one
or more aspects of the present disclosure. When a data model (e.g.,
Authentication data model 651) is selected, the wizard can present
options of the pre-built data sub-models that are associated with
the selected data model. FIG. 7 illustrates an example list 750 of
options of the pre-built data sub-models, which a user can select
from a drop-down menu (e.g., drop-down menu 555 in FIG. 5), in
accordance with one or more aspects of the present disclosure. A
user may select, for example, a Failed_Authentication data
sub-model 751.
[0074] The data aggregation and analysis system can provide one or
more GUIs to present the fields for a data model and can provide
one or more GUIs to present the fields for a data sub-model. These
GUIs may be part of the wizard and accessible via a link, a tab,
etc. included in one or more GUIs of the wizard. Alternatively,
these GUIs may not be part of the wizard and may be accessible via
a link, a tab, etc. included in different GUIs provided by the data
aggregation and analysis system.
[0075] FIG. 8 illustrates an example of a GUI 800 for presenting
the fields of a data sub-model (e.g., Failed_Authentication data
sub-model), in accordance with one or more aspects of the present
disclosure. The GUI 800 can also present the type of events 801 for
the selected data sub-model, the attributes 805 for the selected
data sub-model, including a time attribute 803 (e.g., timestamp)
for the selected data sub-model.
[0076] When a user selects "Lookup file" as the source type from
the drop-down menu 451 of FIG. 4, GUI 900 of FIG. 9 is presented.
FIG. 9 illustrates an example of a GUI 900 of a wizard for
presenting options of pre-built lookup files, which a user can
select from a drop-down menu, in accordance with one or more
aspects of the present disclosure. The GUI 900 can include a list
901 of options of the pre-built lookup files. A user may select the
lookup file "access_app_tracker" 903, which includes one or more
fields pertaining to all of the applications that have been
accessed. The "access_app_tracker" lookup file can be used, for
example, to create a correlation search to determine when a
particular application is being accessed excessively.
[0077] FIG. 10 illustrates an example GUI of a wizard for defining
a time range pertaining to the source data to be searched using the
search query of the correlation search, in accordance with one or
more aspects of the present disclosure. The heterogeneous
machine-generated data is apportioned into events, as described in
greater detail below in conjunction with FIG. 31. Each event
includes a timestamp. The time range specified via GUI 1000 is the
time period defining the scope of the data that is to be searched.
When the search query for the correlation search is executed, the
search query can be applied to events that have timestamps that are
within the specified time range. The time range can be defined as a
rolling window. The rolling time window may be defined relative to
the "current time" moment. GUI 1000 can include user interface (UI)
elements to receive input specifying a time range. For example, GUI
1000 can allow a user to select a predefined time range from a
drop-down menu 1001. FIG. 11 illustrates an example drop-down menu
1100 including various time range options for user selection, in
accordance with one or more aspects of the present disclosure.
[0078] Referring to FIG. 10, the GUI 1000 can also include text
boxes 1003,1005 to allow the user to define a custom time range for
the source data to be searched. For example, the user can specify
an earliest time of 65 minutes and a latest time of 5 minutes,
which should result in searching for the events, relating to failed
login attempts that have a timestamp that is between 5 minutes and
65 minutes prior to "current time." Once the time range is
specified by the user (e.g., using drop-down menu 1001 or text box
1003 and text box 1005), the time range can also be displayed in
another GUI, such as an overview GUI (e.g., GUI 200 in FIG. 2) of
the wizard.
[0079] One or more GUIs of the wizard can display the search query
in the search processing language that was automatically created
based on the user input that has been received in the wizard (e.g.,
via some of the GUIs of FIGS. 4 through 11). FIG. 12 illustrates an
example GUI 1200 of a wizard for displaying a search query in the
search processing language, in accordance with one or more aspects
of the present disclosure. For example, input may have been
received selecting the data to be searched. For example, the input
may be the selection of the data model "Authentication" and the
data sub-model "Failed_Authentication". The GUI 1200 can include a
text box 1201 that displays the search query as a search query
string in the search processing language that was created based on
the input of the data model "Authentication" and the data sub-model
"Failed_Authentication". An implementation of creating a search
query is described in greater detail below in conjunction with
FIGS. 29A-B. The search query string, for example, in text box
1201, may comply with the syntax of a certain query language
supported by the data aggregation and retrieval system, such as,
and not limited to, Splunk Search Processing Language (SPL), which
is further described herein below. The search query can correspond
to a search processing language that uses a late binding
schema.
[0080] One or more GUIs of the wizard can display indicators of
indicating whether the resulting search query parses successfully.
For example, referring to FIG. 12, the GUI 1200 can include icon
1203 and/or text 1205 indicating whether or not the search query as
defined by the received input parses successfully.
[0081] FIG. 13 illustrates an example GUI 1300 of a wizard for
defining a filter for the search query of the correlation search,
in accordance with one or more aspects of the present disclosure.
The GUI 1300 can facilitate user input specifying one or more
filters of the search query. For example, the wizard may have
received input selecting the data to be searched as the events
associated with the "Authentication" data model and the
"Failed_Authentication" data sub-model. The GUI 1300 can include
one or more GUI elements to receive input specifying one or more
filters to be used to filter the data that is to be searched. For
example, the GUI 1300 includes a text box 1301 to receive input to
specify a filter. In another example, the GUI 1300 can include
multiple text boxes to receive input specifying multiple filters.
If no input is received via the text box 1301, the wizard does not
add a filter to the search query.
[0082] The filter can include a specific field that is associated
with the events that are being searched and can include a value for
the specific field, in order to limit the scope of the search query
to those events that have a matching value in the field specified
by the filter. As described above, the wizard can include a GUI
(e.g., GUI 800 in FIG. 8) that displays the fields (attributes)
that are associated with a particular data model and/or data
sub-model, and the filter can include a subset (one or more) of
those fields and a certain value for each field in the subset.
[0083] For example, the failed authentication sub-model includes a
"user" field. The search query that uses the failed authentication
sub-model can be applied to events pertaining to failed
authentication, and can filter the events to identify failed
authentication for a particular user (e.g., jsmith). That is, the
filter can be the "user" field being equated to a value (e.g.,
jsmith). In another example, multiple filters may be specified by
user input. For example, input can be received via a text box
specifying a filter based on the "user" field and input can be
received via another text box specifying a filter based on an "IP
address" field. When the filter is specified, the search processing
language for the specified filter can be determined and can be
automatically added to the search and displayed in the GUI 1300,
for example, in a text box 1303. In one implementation, the search
query includes a "where" clause that defines the filter. For
example, "where user=j smith" may automatically be added to the
text box 1303. One implementation for determining the search
processing language for the specified filter is described in
greater detail below in conjunction with FIGS. 29A-B. One or more
GUIs of the wizard can facilitate user input for accessing
information (e.g., documentation) explaining search query
parameters (e.g., parameters used in a search processing language).
For example, GUI 1300 can include a link 1307 to information
describing what the where clause is.
[0084] When the search query is executed, the search results should
include events that have the user field equal to "jsmith". One or
more GUIs of the wizard can allow the user to test the filter
criteria for a search query. For example, GUI 1300 can include a
link 1305 to facilitate user input to request that the filter
criteria be tested by running the search query. In one
implementation, when input is received requesting to test the
filter criteria, the wizard causes a search GUI to be
displayed.
[0085] FIG. 14 illustrates an example of a GUI 1400 for testing the
filter criteria for a search query, in accordance with one or more
aspects of the present disclosure. GUI 1400 can display the search
query, which is defined by the input facilitated by the wizard, in
a text box 1401. The GUI 1400 can display the dataset that is
produced by running the search query in a text box 1403. In one
implementation, other GUIs of the wizard are accessible while the
GUI 1400 is presented. A user can access the GUIs of the wizard to
continue creating a correlation search and/or to edit the filter
criteria for the search query based on the results of testing the
search query.
[0086] As discussed above, once the search query is defined, the
next stage of the wizard, which can be accessed, for example, by a
user selecting a button 1309 in FIG. 13, can focus on guiding the
user on how to aggregate the dataset that is produced by the search
query. FIG. 15A illustrates an example GUI 1500 of a wizard for
facilitating user input to request an aggregation of the dataset to
be produced by the search query of the correlation search, in
accordance with one or more aspects of the present disclosure. For
example, the search results in the dataset can be aggregated to
form statistics pertaining to one or more fields (attributes) used
for aggregation. For example, the search query may produce results
that include failed authentication attempts for logging into any
application (e.g., email application, CRM application, HCM
application, etc.) and can include failed authentication attempts
that were initiated by numerous source IP (Internet Protocol)
addresses. A user may wish to obtain more granular results, for
example, the failed authentication attempts on a per application
per source basis (i.e., first aggregated by application and then
further aggregated by source). The user may also wish the
aggregated results to indicate statistics on a per application per
source basis. For example, the user may wish the aggregated results
to indicate the count of failed authentication attempts on a per
application per source basis.
[0087] The GUI 1500 can include a link 1501 for creating a new
aggregate which represents a desired statistic pertaining to an
attribute to be used for aggregation. A search query can return
individual matching events, individual portions of data matching
events, records that satisfy the search criteria if the search
query is applied to a relational database, and/or a result of a
calculation on the data (such as an aggregate or statistic). An
aggregate and/or an evaluation of an aggregate can be part of the
search criteria. An aggregate is hereinafter also referred to as a
"statistics type". Once the user selects link 1501, a new GUI is
presented that allows the user to define the new aggregate. FIG.
15B illustrates an example GUI 1550 of a wizard for defining an
aggregate, in accordance with one or more aspects of the present
disclosure.
[0088] GUI 1550 can include a drop-down menu 1553 displaying
options for a function which can be selected to define a function
to be used for the aggregate being created. Examples of a function
can include, and are not limited to, average, count, distinct
count, max, mean, median, percentile, range, sum, values, etc.
[0089] The GUI 1550 can include a drop-down menu 1555 displaying
options for an attribute, which can be selected for aggregation.
The attributes displayed in the drop-down menu 1555 can pertain to
the data model and/or data sub-model that is selected. For example,
the drop-down menu 1555 displays the attributes (fields) associated
with the Authentication data model and/or Failed_Authentication
data sub-model.
[0090] A user may have iterated through GUI 1550 of FIG. 15B
multiple times to provide user input to create three aggregates.
For example, GUI 1550 of FIG. 15B may have received user input
identifying a values function and a corresponding attribute
"authentication tag" in a first iteration, user input identifying a
distinct count function and a corresponding attribute "user" in a
second iteration, and user input identifying a distinct count
function and a corresponding attribute "destination" in a third
iteration, in order to create the three aggregates.
[0091] Once the user defines the aggregate(s) and/or as the user
defines the aggregate(s), the aggregate(s) are displayed in a GUI
of the wizard. FIG. 16 illustrates an example GUI 1600 of the
wizard for displaying multiple aggregates that were defined, and
allowing a user to edit or delete any of the displayed aggregates,
and/or to create additional aggregates, in accordance with one or
more aspects of the present disclosure. GUI 1600 can display text
1601 for the three aggregates that were created. GUI 1600 can
include a link 1605 for each aggregate to edit the corresponding
aggregate. GUI 1600 can include a link 1607 for each aggregate to
delete the corresponding aggregate. GUI 1600 can include a link
1603 to create a new aggregate.
[0092] When executed, the values function returns the list of all
distinct values of the field as a multi-value entry. For example,
when executed as part of execution of the search query, the
aggregate "values(Authentication.tag)" can return a list of all
distinct values of the field "tag". When executed, the distinct
count function returns the count of distinct values for the field.
For example, when executed as part of execution of the search
query, the aggregate "dc(Authentication.user)" can return the count
of distinct values for the field "user". The "user" field can be a
string data type and can describe the name of the user involved
with the corresponding event, or who initiated the corresponding
event. In another example, when executed as part of execution of
the search query, the aggregate "dc(Authentication.dest)" can
return the count of distinct values for the field "dest". The
"dest" field can be a string data type and can describe the target
involved in the authentication.
[0093] A user may wish that the scope of the aggregates be narrowed
to result in more focused statistics. The scope of the aggregates
can be narrowed by adding attributes to be used for aggregation,
thereby separating aggregated statistics per the added attributes
(or fields). For example, rather than just obtaining a distinct
count of failed attempts per user for all applications and all
sources, desired aggregate statistics can be provided for each
distinct combination of an application and a source. FIG. 17
illustrates an example GUI 1700 of a wizard for defining how to
separate aggregated statistics pertaining to the dataset produced
by a search query by fields, in accordance with one or more aspects
of the present disclosure. A "split-by" or "split-by operation"
hereinafter refers to breaking down the statistics by the distinct
values of one or more specified split-by field(s). A split-by
operation finds the distinct values for the split-by field(s) and
correlates those distinct values to the field(s) on which an
aggregate or statistic is being calculated.
[0094] GUI 1700 can display the attributes (fields) that pertain to
the data model and/or data sub-model that is selected and can
receive user input selecting the one or more fields to use for the
split-by. GUI 1700 displays the selected field(s) in a box 1701.
For example, GUI 1700 displays a selection of split-by by the
application (app) field and a selection of split-by the source
(src) field.
[0095] GUI 1700 can include a button 1703 for each field that is
selected to facilitate user input for unselecting the corresponding
field. A split-by modifies how a statistic is being calculated. For
example, if the split-by on the source field is selected, but the
split-by on the application field is unselected, then a statistic
may be calculated for the dataset produced by the search query by
grouping the failed authentications for all applications together
for each source IP address. Whereas, if the split-by on the
application field is selected as well as the source field being
selected, as illustrated in GUI 1700, then a statistic may be
calculated for the dataset produced by the search query by grouping
the failed authentications per distinct application and per
distinct source IP address.
[0096] FIG. 18 illustrates an example GUI 1800 of a wizard for
facilitating user input to assign an alias to a selected field for
a split-by operation, in accordance with one or more aspects of the
present disclosure. A user can assign an alias to a split-by field.
The alias can be used to identify the various groups in the dataset
that is produced by the search query, in order to provide a more
readable visualization of the search results. The aliases are
described in greater detail below in conjunction with FIG. 22.
[0097] FIG. 19 illustrates an example of a GUI 1900 of a wizard for
defining one or more triggering conditions for a correlation
search, in accordance with one or more aspects of the present
disclosure. A triggering condition is a condition to be applied to
the dataset that is produced based on the search query of the
correlation search. For example, a user may wish to trigger an
action "when the dataset produced based on the search query
includes at least one result having an authentication failure count
of six or more over a specified time range (e.g., one hour)," where
the specified time range was provided via the GUI 1000 of FIG.
10.
[0098] The aggregates that have been created for the correlation
search can be used to define the triggering condition(s). GUI 1900
can display, in a drop-down menu 1901, a list of the aggregates
created for the correlation search. GUI 1900 can display, in a
drop-down menu 1903, operations that can be used with a selected
aggregate to define the triggering condition(s). GUI 1900 can
include a text box 1905 to allow a user to specify a value to be
used with the operation and selected aggregate for defining the
triggering condition(s). For example, to detect "when the dataset
produced based on the search query includes at least one result
having an authentication failure count of six or more over a
specified time range (e.g., one hour)," a user may select the
"count" aggregate, the "greater than or equal to" operation" and
provide the value "6".
[0099] In one implementation, the GUI 1900 can facilitate user
input to define more than one triggering condition for a
correlation search. For example, the GUI 1900 can include UI
elements for AND/OR operations. For example, a user may wish to
trigger an action "when the authentication failure count is greater
than or equal to 6 and less than or equal to 12". The GUI 1900 can
include multiple GUI elements to facilitate user input to define
multiple triggering conditions for a correlation search. For
example, GUI 1901 may include multiple drop-down menus.
[0100] One or more GUIs of the wizard can facilitate user input for
testing the execution of the search query with the triggering
condition. FIG. 20 illustrates an example of a GUI 2000 of the
wizard for testing the execution of the search query with the
triggering condition, in accordance with one or more aspects of the
present disclosure. GUI 2000 can display search processing language
that defines the search query and the triggering condition. For
example, the GUI 2000 can include a text box 2001 that displays the
search processing language that corresponds to the input of the
data model "Authentication" and the data sub-model
"Failed_Authentication", the aggregates that are created for the
correlation search, the aliases created for the correlation search,
and the triggering condition. For example, the search processing
language that corresponds to the triggering condition to detect
"when the dataset produced based on the search query includes at
least one result having an authentication failure count of six or
more" can include the where clause "where `count` >=6" as
illustrated in GUI 2000. The translation of the input for creating
the correlation search into corresponding search processing
language is described in greater detail below in conjunction with
FIGS. 29A-B.
[0101] One or more GUIs of the wizard can display one or more
elements indicating whether the search query and the triggering
condition as defined by the received input parses successfully. GUI
2000 can include a button 2005 to facilitate user input to save the
data (e.g., input and output) pertaining to the creation and/or
editing of the correlation search. Saving the data pertaining to
the correlation search is described in greater detail below in
conjunction with FIGS. 29A-B. GUI 2000 can include a link 2003 to
facilitate user input to request that the search query and the
triggering condition be tested. In one implementation, when input
is received requesting to test the search criteria with the
triggering condition, the wizard causes a search GUI to be
displayed.
[0102] FIGS. 21-22 illustrate example GUIs, pertaining to a wizard,
for testing the search query with the triggering condition, in
accordance with one or more aspects of the present disclosure.
Referring to FIG. 21, the GUI 2100 can display the search query and
the triggering condition, which are defined by the input
facilitated by the wizard, in a text box 2101. In one
implementation, when input is received (e.g., selecting link 2003
in FIG. 2000) requesting to test the search criteria with the
triggering condition, text box 2101 is automatically populated with
the search processing language corresponding to the search query
and the triggering condition. The GUI 2100 can display the dataset
that is produced by executing the search query with the triggering
condition in a text box 2103. In one implementation, other GUIs of
the wizard are accessible while the GUI 2100 for running the search
query is displayed. A user can access the GUIs of the wizard to
continue creating/editing the correlation search based on the
results of testing the execution of the search query and the
triggering condition.
[0103] Referring to FIG. 22, the GUI 2200 can display the dataset
that is produced by running the search query and the triggering
condition in one or more tabbed panes 2201, 2203. GUI 2200 can
include one or more tabbed panes 2201, 2203 for facilitating user
input for displaying various representations of the dataset that is
produced by executing the search query and the triggering
condition. For example, a selection of tabbed pane 2203 can display
the events that lead to the triggering condition being satisfied.
In another example, a selection of tabbed pane 2201 can display the
statistics that are calculated for the correlation search. The
tabbed pane 2201 can display the search results based on the input
of the split-by fields. For example, tabbed pane 2201 displays the
search results in a tabular format having multiple columns 2207,
2209, 2211, 2213, 2215 to present data pertaining to the search
results. There is a column 2207 to represent the split-by the
application field and there is a column 2209 to represent the
split-by the source field. The columns are displayed with the
corresponding aliases that have been created for the correlation
search. For example, "Authentication.app" was converted to the
alias "app" and "Authentication.src" was converted to the alias
"src". There is a column 2215 that represents the count aggregate
that was created for the correlation search. For example, the
values in the count column 2215 can represent the number of failed
authentications for the particular application, source, and tag
combination. For example, there have been 26 failed authentications
for the application "login", source "10.11.36.1" and tag
"authenticationlerrorlfailureloslunix".
[0104] FIG. 23 illustrates an example of a GUI 2300 of a wizard for
defining one or more actions for a correlation search, in
accordance with one or more aspects of the present disclosure. GUI
2300 corresponds to GUI 250 of FIG. 2 discussed in detail above.
GUI 2300 can present the name 2301 of the correlation search being
created and/or edited, the description 2305 of the correlation
search, and the application context 2303 (e.g., an application or
module) associated with the correlation search.
[0105] GUI 2300 can display actions 2319, 2321, 2323, 2325, 2327
that can be performed when the results produced based on the search
query satisfy the triggering condition. GUI 2300 can include one or
more UI elements for each action option to further configure the
actions that should be taken. For example, when the authentication
failure count is greater than or equal to six over a specified time
range (e.g., one hour) for a particular application and a
particular source, the selected action(s) can be performed. For
example, the selected action 2319 and the selected action 2321 can
be performed when the triggering condition is met.
[0106] Example actions can include, and are not limited to,
presenting in a GUI a representation of an instance of the
triggering condition being satisfied, adjusting a risk score,
sending a notification indicating that the trigger condition is
satisfied, etc. Action 2319 represents a notable event that is
likely to indicate a security threat, as described in greater
detail below. For example, an incident review user interface can
display a notable event when the authentication failure count is
greater than or equal to six over a specified time range (e.g., one
hour) for a particular application and a particular source.
[0107] In another example, the data aggregation and analysis system
can adjust, by a certain risk score modifier value, the risk score
assigned to one or more objects responsive to determining that at
least a portion of a dataset produced by the search query satisfies
a particular triggering condition. Action 2321 represents adjusting
a risk score. The risk score may be assigned to one or more
objects. For example, when the authentication failure count is
greater than or equal to six over a specified time range (e.g., one
hour) for a particular application and a particular source, the
risk score the particular application and/or particular host can be
increased.
[0108] In other examples, the actions can include sending a
notification indicating that the trigger condition is satisfied.
Action 2323 represents creating an RSS feed. The RSS feed can
include, for example, at least a part of the dataset that has
contributed to the trigger condition being satisfied. Action 2325
represents sending an e-mail message indicating the trigger
condition is satisfied. The email message can include, for example,
at least a part of the dataset that has contributed to the trigger
condition being satisfied. Action 2327 represents a shell script
having at least one parameter defined based on the triggering
condition being satisfied.
[0109] GUI 2300 can provide an overview of the correlation search
as the correlation search is being created. For example, the GUI
2300 can present the search processing language 2307 for the
correlation search defined as described above in conjunction with
GUIs in FIGS. 2-20. The GUI 2300 can also allow the search
processing language of the correlation search to be edited.
[0110] GUI 2300 can display time parameters for the correlation
search in text boxes 2309,2311 as the input is received, as
described above in conjunction with GUIs in FIGS. 10-11. In an
illustrative example, the time parameters include a start time and
end time that defines a time window specified relative to the
current time.
[0111] GUI 2300 can include a schedule input element 2313 to define
the schedule according to which the correlation search should be
executed by the example data aggregation and analysis system. The
schedule can be represented by a data structure comprising values
of one or more scheduling parameters (e.g., minute, hour, day,
month, and/or day-of-week).
[0112] GUI 2300 can include a throttling window input element 2315
and a grouping field selection element 2317 to define a throttling
condition. The throttling condition can be utilized to suppress,
for a certain period of time (e.g., for a specified number of
seconds in element 2315), triggering one or more actions associated
with the search query and the triggering condition. The grouping
field selection element 2317 can be utilized to select a field by
the value of which the search results should be grouped for
evaluating the throttling condition. In other words, the actions
associated with the search query and the triggering condition
should be suppressed for a specified number of seconds for the
search results that include the same value in the specified field
(e.g., the same application identifier in the "app" field and the
same source identifier in the "src" field shown in the grouping
field selection element 2317 in the illustrative example GUI
2300).
[0113] GUI 2300 can include a button 2331 to facilitate user input
for saving the correlation search and any data pertaining to
creation and/or editing of the correlation search. In one
implementation, the data pertaining to creation and/or editing of
the correlation search is saved locally. In another implementation,
the data pertaining to creation and/or editing of the correlation
search is saved remotely. The data pertaining to creation and/or
editing of the correlation search can include the input received
and any output produced from the input.
[0114] FIG. 24 is a flow diagram of an implementation of a method
2400 for creating and/or editing a correlation search via a wizard,
in accordance with one or more aspects of the present disclosure.
The method may be performed by processing logic that may comprise
hardware (circuitry, dedicated logic, etc.), software (such as is
run on a general purpose computer system or a dedicated machine),
or a combination of both. In one implementation, the method 2400 is
performed by the client computing machine. In another
implementation, the method 2400 is performed by a server computing
machine coupled to the client computing machine over one or more
networks.
[0115] At block 2401, the computing machine defines a search query
for a correlation search. The search query can be defined using
GUIs described above in conjunction with FIGS. 3-18. The defining
of the search query is described in greater detail below in
conjunction FIGS. 25-26. At block 2403, the computing machine
defines a triggering condition to be applied to a dataset that is
produced by the search query. The dataset that is produced by the
search query can include data derived using a late binding schema.
A late binding schema is described in greater detail below. The
triggering condition can be defined using a GUI described above in
conjunction with FIG. 19. The defining of the triggering condition
is described in greater detail below in conjunction FIG. 27. At
block 2405, the computing machine defines one or more actions to be
performed when the triggering condition is met by the dataset that
is produced by the search query. The one or more actions can be
defined using a GUI described above in conjunction with FIG. 23.
The defining of the one or more actions is described in greater
detail below in conjunction FIG. 28. In one example, the dataset
satisfies the triggering condition each time the dataset includes
an indicator that the search criteria of the search query are
satisfied. In another example, the dataset includes a number of
times the search criteria of the search query are satisfied and the
dataset satisfies the triggering condition when the number of times
exceeds a threshold. In another example, the dataset satisfies the
triggering condition when an aggregated statistic pertaining to the
dataset exceeds a threshold, is under a threshold, or is within a
specified range. At block 2407, the computing machine causes the
generation of the correlation search using the defined search
query, the triggering condition, and the one or more actions. The
correlation search can be created using GUIs described above in
conjunction with FIG. 23. The creation of the correlation search
can include determining the search processing language for the
correlation search based on the defined search query, triggering
condition, and action(s).
[0116] FIG. 25 is a flow diagram of an implementation of a method
2500 for defining a search query for a correlation search via a
wizard, in accordance with one or more aspects of the present
disclosure. The method may be performed by processing logic that
may comprise hardware (circuitry, dedicated logic, etc.), software
(such as is run on a general purpose computer system or a dedicated
machine), or a combination of both. In one implementation, the
method 2500 is performed by the client computing machine. In
another implementation, the method 2500 is performed by a server
computing machine coupled to the client computing machine over one
or more networks.
[0117] At block 2501, the computing machine receives input of one
or more search criteria, as described above in conjunction with
GUIs in FIGS. 4-18. The input can include, for example, a lookup
file, a data model, a data sub-model, a time range, a filter, input
for creating one or more statistics types, fields for split-by
operations, aliases. At block 2503, the computing machine
determines a search query based on the input of the search
criteria. The determining of the search query can include
identifying search processing language that corresponds to the
input. One implementation of determining of the search query is
described in greater detail below in conjunction with FIGS.
29A-B.
[0118] At block 2505, the computing machine causes display of the
search query in the wizard. The search query corresponds to a
search language that uses a late binding schema. The search query
can be displayed in one or more GUIs of the wizard, as described
above in conjunction with GUIs in FIGS. 2, 12, 13, 20, and 23. The
search query can be displayed in one or more GUIs for executing the
search query as described above in conjunction with GUIs in FIGS.
14, 21, and 22. At block 2507, the computing machine may receive a
user request to the test an execution of the search query, as
described above in conjunction with GUIs in FIGS. 13 and 20. At
block 2509, the computing machine causes the execution of the
search query. The execution of the search query can be against raw
machine data. The execution of the search query can be against
time-stamped events that each include a portion of raw machine
data. One implementation of causing the execution of the search
query is described in greater detail below in conjunction with
FIGS. 29A-B. At block 2511, the computing machine obtains a dataset
that is produced based on the execution the search query. At block
2513, the computing machine causes display in the wizard of the
dataset that is produced from the execution of the search query, as
described above in conjunction with GUIs in FIGS. 14, 21, and
22.
[0119] FIG. 26 is a flow diagram of an implementation of a method
2600 for defining a search query for a correlation search via a
wizard, in accordance with one or more aspects of the present
disclosure. A calculation of a statistics type (aggregate) and/or
an evaluation of a statistics type can be part of the search query.
The method may be performed by processing logic that may comprise
hardware (circuitry, dedicated logic, etc.), software (such as is
run on a general purpose computer system or a dedicated machine),
or a combination of both. In one implementation, the method 2600 is
performed by the client computing machine. In another
implementation, the method 2600 is performed by a server computing
machine coupled to the client computing machine over one or more
networks.
[0120] At block 2601, the computing machine receives input
identifying a data model, as described above in conjunction with
the GUI in FIG. 5. At block 2603, the computing machine causes
attributes of the identified data model to be displayed in a GUI of
the wizard, as described above in conjunction with the GUI in FIGS.
15A-B. At block 2605, the computing machine receives input
identifying one or more attributes to use to create one or more
statistics types (aggregates) for aggregating the dataset that is
being produced by the search query, as described above in
conjunction with the GUI in FIGS. 15A-B. At block 2607, the
computing machine causes the one or more statistics types to be
created. One implementation of creating the one or more statistics
types is described in greater detail below in conjunction with
FIGS. 29A-B. At block 2609, the computing machine causes the
created statistics types for producing an aggregate on data to be
displayed in a GUI of the wizard, as described above in conjunction
with the GUI in FIG. 16.
[0121] FIG. 27 is a flow diagram of an implementation of a method
2700 for defining a triggering condition for a correlation search
via a wizard, in accordance with one or more aspects of the present
disclosure. The method may be performed by processing logic that
may comprise hardware (circuitry, dedicated logic, etc.), software
(such as is run on a general purpose computer system or a dedicated
machine), or a combination of both. In one implementation, the
method 2700 is performed by the client computing machine. In
another implementation, the method 2700 is performed by a server
computing machine coupled to the client computing machine over one
or more networks.
[0122] At block 2701, the computing machine receives input
identifying a statistics type (aggregate) to define a triggering
condition, as described above in conjunction with the GUI 1900 in
FIG. 19. For example, the statistics type "count" is identified in
GUI 1900. At block 2703, the computing machine receives user input
identifying an operation to be applied to statistics of the
identifies statistics type, as described above in conjunction with
the GUI in FIG. 19. For example, the operation "greater than or
equal to" is identified in GUI 1900.
[0123] At block 2705, the computing machine receives user input
identifying a value to be used with the identified operation as
applied to the statistics of the identified statistics type, as
described above in conjunction with the GUI in FIG. 19. For
example, the value "6" is identified in GUI 1900. At block 2707,
the computing machine determines search processing language for the
triggering condition based on the identified input (e.g.,
identified statistics type, identified operation, and identified
value). The input can include more than one identified statistics
type, more than one operation, and/or more than one value. For
example, a user may wish to detect "when the authentication failure
count is greater than or equal to 6 and less than or equal to 12".
One implementation of determining the search processing language
for the triggering condition is described in greater detail below
in conjunction with FIGS. 29A-B.
[0124] At block 2709, the computing machine causes the search
processing language for the triggering condition to be displayed in
a GUI of the wizard, as described above in conjunction with the GUI
in FIG. 20. At block 2711, the computing machine may receive a user
request to test an execution of the search query with the
triggering condition, as described above in conjunction with the
GUI in FIG. 20. At block 2713, the computing machine causes the
execution of the search query with the triggering condition, as
described above in conjunction with the GUIs in FIGS. 21-22. At
block 2715, the computing machine obtains a dataset that is produce
based on the execution of the search query with the triggering
condition. One implementation of obtaining the dataset is described
in greater detail below in conjunction with FIGS. 29A-B. At block
2711, the computing machine causes the dataset that is produced
from executing the search query with the triggering condition to be
presented in a GUI, as described above in conjunction with the GUI
in FIG. 22.
[0125] FIG. 28 is a flow diagram of an implementation of a method
2800 for defining one or more actions for a correlation search via
a wizard, in accordance with one or more aspects of the present
disclosure. The method may be performed by processing logic that
may comprise hardware (circuitry, dedicated logic, etc.), software
(such as is run on a general purpose computer system or a dedicated
machine), or a combination of both. In one implementation, the
method 2500 is performed by the client computing machine. In
another implementation, the method 2500 is performed by a server
computing machine coupled to the client computing machine over one
or more networks.
[0126] At block 2801, the computing machine displays options in a
GUI of the wizard for one or more actions that can be performed
when a triggering condition is satisfied by the dataset that is
produced based on the search query, as described above in
conjunction with the GUI in FIG. 23. The options can include, for
example, and is not limited to, updating a display with an entry
corresponding to satisfaction of the trigger condition being
satisfied, adjusting a score or an object to which data causing
satisfaction of the triggering condition pertains, or sending a
notification indicating satisfaction of the triggering condition.
At block 2803, the computing machine receives input identifying one
or more of the actions to be performed when the triggering
condition is satisfied, as described above in conjunction with the
GUI in FIG. 23. At block 2805, the computing machine associates the
identified action(s) with the triggering condition, as described
above in conjunction with the GUI in FIG. 23.
[0127] FIGS. 29A-B are block diagrams of an implementation of
creating and/or editing a correlation search via a wizard, in
accordance with one or more aspects of the present disclosure. A
client computing machine 2906 can communicate with one or more
server computing machines 2903 and one or more search heads 2902
via one or more networks. A search head 2902 is described in
greater detail below in conjunction with FIG. 30.
[0128] The client computing machine 2906 can be portable computing
devices such as cellular telephones, personal digital assistants
(PDAs), portable media players, netbooks, laptop computers,
electronic book readers or tablet computers (e.g., that includes a
book reader application), set-top boxes, gaming consoles,
televisions, and the like. The client computing machine 2906 can
include one or more data stores 2909 to store data.
[0129] The client computing machine 2906 can run an operating
system (OS) that manages hardware and software of the client
computing machine 2906. A media application 2908 can run on the
client computing machine 2906 (e.g., on the OS of the user
devices). For example, the media application 2908 may be a web
browser that can access content served by an application server
(e.g., server computing machine 2903). In another example, the
media application 2908 may be a mobile application (e.g., an app)
that can access content served by a mobile application server
(e.g., server machine 2903).
[0130] The client computing machine 2906 can include a correlation
search wizard module 2907 to provide a wizard for generating and/or
editing a correlation search. The wizard can include a set of GUIs
facilitating user input of (i) one or more search criteria for a
search query of the correlation search, (ii) a triggering condition
to be applied to a dataset that is produced by the search query,
and (iii) one or more actions to be performed when the dataset
produced by the search query satisfies the triggering condition.
The wizard causes the correlation search to be created based on the
user input.
[0131] The correlation search wizard module 2907 can send a request
2911 for the wizard to a server computing machine 2903. For
example, a user may select a link or a button in a GUI to request
the wizard. The server computing machine 2903 can include a
correlation search module 2904 to provide the wizard and facilitate
user input for generating and/or editing a correlation search. The
GUIs for the wizard and the data to be presented in the GUIs of the
wizard can be stored in a data store 2905 that is coupled to the
server computing machine 2903. The correlation search module 2904
can provide 2913 the wizard to the correlation search wizard module
2907. The correlation search module 2904 can provide one or more
GUIs to be rendered by the media application 2908 and data to be
displayed in the one or more GUIs. The correlation search wizard
module 2907 can provide 2915 the wizard to the media application
2908, and the media application 2908 can display 2917 the wizard on
an output device (e.g., display) of the client computing machine
2906.
[0132] A GUI of the wizard that is rendered by the media
application 2908 can receive 2919 input of search criteria to
define a search query for the correlation search. The input can be
received as described above in conjunction with the GUIs in FIGS.
2-14. The input can be provided 2921 to the correlation search
wizard module 2907, and the correlation search wizard module 2907
can provide 2923 the input to the correlation search module 2904.
The correlation search module 2904 can translate the input to
corresponding search processing language to create 2925 the search
query. The correlation search module can provide 2927 the search
query, as represented by the corresponding search processing
language, to the correlation search wizard module 2907. The
correlation search wizard module 2907 obtains the search query and
can provide 2929 the search query to the media application 2908,
which can display 2931 the search processing language for search
query in one or more GUIs of the wizard. The search processing
language for search query can be presented in one or more GUIs of
the wizard as described above in conjunction with the GUIs in FIGS.
2, 12, 13.
[0133] A GUI of the wizard that is rendered by the media
application 2908 can receive 2933 a request to run the search query
for the correlation search, for example, to test the criteria of
the search query before further defining the correlation search.
The input can be received as described above in conjunction with
the GUI in FIG. 13. The request can be provided 2935 to the
correlation search wizard module 2907, and the correlation search
wizard module 2907 can provide 2937 the request to a search head
2902. The search head 2902 can run 2939 the search query and can
provide 2941 the dataset that is produced by the search query to
the correlation search wizard module 2907. The correlation search
wizard module 2907 obtains the dataset and can provide 2943 the
dataset that is produced by the search query to the media
application 2908, which can display 2945 dataset that is produced
by the search query in one or more GUIs. The dataset that is
produced by the search query can be presented in one or more GUIs
as described above in conjunction with the GUI in FIG. 14.
[0134] A GUI of the wizard that is rendered by the media
application 2908 can receive 2947 input for creating statistics
types (aggregates) for the correlation search. The input can be
received as described above in conjunction with the GUI in FIGS.
15A-B. The input can be provided 2949 to the correlation search
wizard module 2907, and the correlation search wizard module 2907
can create 2951 the aggregates. The correlation search wizard
module 2907 can provide 2953 the aggregates to the media
application 2908, which can display 2955 the aggregates in one or
more GUIs of the wizard, as described above in conjunction with
FIG. 16.
[0135] In one implementation, the correlation search module 2904
receives the input of aggregates, alias, and split-by fields from
the correlation search wizard module 2907 and translates the input
for aggregates, alias, and split-by fields to corresponding search
processing language for the aggregates, alias, and split-by fields.
The input can be received as described above in conjunction with
the GUIs in FIGS. 15A-B through FIG. 18. The search processing
language for aggregates, alias, and split-by fields can be
displayed in one or more GUIs of the wizard, as described above in
conjunction with the GUIs in FIGS. 2, 20, 21, 22, 23.
[0136] A GUI of the wizard that is rendered by the media
application 2908 can receive 2957 input defining a triggering
condition for the correlation search. The input can be received as
described above in conjunction with the GUI in FIG. 19. The input
can be provided 2959 to the correlation search wizard module 2907,
and the correlation search wizard module 2907 can provide 2961 the
input to the correlation search module 2904. The correlation search
module 2904 can translate the input to corresponding search
processing language to create 2963 the triggering condition. The
correlation search module can provide 2965 the triggering condition
as represented by the corresponding search processing language to
the correlation search wizard module 2907. The correlation search
wizard module 2907 obtains the triggering condition and can provide
2967 the triggering condition to the media application 2908, which
can display 2931 the search processing language for triggering
condition in one or more GUIs of the wizard, as described above in
conjunction with the GUIs in FIGS. 2, 20, 21, 22, 23. The search
processing language for the triggering condition can include search
processing language corresponding to aggregates, alias, split-by
fields that are associated with the triggering condition.
[0137] A GUI of the wizard that is rendered by the media
application 2908 can receive 2971 (in FIG. 29B) a request to run
the search query and triggering condition for the correlation
search, for example, to test the criteria of the search query and
the triggering condition before further defining the correlation
search. The input can be received as described above in conjunction
with the GUI in FIG. 20. The request can be provided 2973 to the
correlation search wizard module 2907, and the correlation search
wizard module 2907 can provide 2975 the request to a search head
2902. The search head 2902 can run 2977 the search query with the
triggering condition and can provide 2979 the dataset that is
produced by running the search query with the triggering condition
to the correlation search wizard module 2907. The correlation
search wizard module 2907 obtains the dataset and can provide 2980
the dataset that is produced by the search query with the
triggering condition to the media application 2908, which can
display 2981 dataset that is produced by the search query in one or
more GUIs, as described above in conjunction with FIGS. 21 and
22.
[0138] A GUI of the wizard that is rendered by the media
application 2908 can receive 2982 defining one or more actions for
the correlation search, for example, to be taken when the
triggering condition is met. The input can be received as described
above in conjunction with the GUI in FIG. 23. The request can be
provided 2983 to the correlation search wizard module 2907, and the
correlation search wizard module 2907 can provide 2984 the input to
the correlation search module 2904. The correlation search module
2904 can associate the actions with the correlation search. The
correlation search module can store the associations of the actions
with the correlation search.
[0139] The media application 2908 can display 2988 the correlation
search, as described above in conjunction with FIGS. 2 and 23. A
GUI of the wizard that is rendered by the media application 2908
can receive 2989 input to save the correlation search and any data
pertaining to creation and/or editing of the correlation search.
The input can be received as described above in conjunction with
the GUI in FIG. 23. The data pertaining to creation and/or editing
of the correlation search can include the input received and any
output produced from the input. The request to save the correlation
search can be provided 2990 to the correlation search wizard module
2907. The correlation search wizard module 2907 can save the data
pertaining to the correlation search in the data store 2909, and/or
the correlation search wizard module 2907 can provide 2992 the
input to the correlation search module 2904, and the correlation
search module 2904 can save the data pertaining to the correlation
search in the data store 2905.
[0140] The one or more networks can include one or more public
networks (e.g., the Internet), one or more private networks (e.g.,
a local area network (LAN) or one or more wide area networks
(WAN)), one or more wired networks (e.g., Ethernet network), one or
more wireless networks (e.g., an 802.11 network or a Wi-Fi
network), one or more cellular networks (e.g., a Long Term
Evolution (LTE) network), routers, hubs, switches, server
computers, and/or a combination thereof.
[0141] In one implementation, the client computing machine (e.g.,
client computing machine 2906), server computing machines 2903, and
search heads 2902 are not directly connected to each other, but are
coupled via separate networks.
[0142] The computing machines can be a rackmount server computer, a
router computer, a personal computer, a portable digital assistant,
a mobile phone, a laptop computer, a tablet computer, a camera, a
video camera, a netbook, a desktop computer, a media center, or any
combination of the above. The server computing machine can provide
web applications and/or mobile device applications and data for the
mobile device.
[0143] A data store can be a persistent storage that is capable of
storing data. A persistent storage can be a local storage unit or a
remote storage unit. Persistent storage can be a magnetic storage
unit, optical storage unit, solid state storage unit, electronic
storage units (main memory), or similar storage unit. Persistent
storage can be a monolithic device or a distributed set of devices.
A `set`, as used herein, refers to any positive whole number of
items.
[0144] In one implementation, the data that is searched by a search
query of a correlation search includes data derived using a late
binding schema. Late binding schema is described in greater detail
below. Implementations of the present disclosure can process
real-time data. The systems and methods described herein above may
be employed by various data processing systems, e.g., data
aggregation and analysis systems. In various illustrative examples,
the data processing system may be represented by the SPLUNK.RTM.
ENTERPRISE system produced by Splunk Inc. of San Francisco, Calif.,
to store and process performance data.
[0145] 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.
[0146] 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.
[0147] 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.
[0148] These challenges can be addressed by using an event-based
system, such as the SPLUNK.RTM. ENTERPRISE system produced by
Splunk Inc. of San Francisco, Calif., to store and process
performance data. The SPLUNK.RTM. 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.RTM. 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.RTM. ENTERPRISE system,
the techniques are also applicable to other types of data server
systems.
[0149] In the SPLUNK.RTM. ENTERPRISE system, performance data is
stored as "events," wherein 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," wherein time series
data comprises 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,
wherein 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 comprise 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.
[0150] The SPLUNK.RTM. ENTERPRISE system also facilitates using a
flexible schema to specify how to extract information from the
event data, wherein the flexible schema may be developed and
redefined as needed. Note that a flexible schema may be applied to
event data "on the fly," when it is needed (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 needed (e.g., at search time), it is referred to as a
"late-binding schema."
[0151] During operation, the SPLUNK.RTM. 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.
[0152] As noted above, the SPLUNK.RTM. 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 comprises a
regular expression, in which case the rule is referred to as a
"regex rule."
[0153] 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.RTM. 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.
[0154] In the SPLUNK.RTM. 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.
[0155] 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.
[0156] 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.
[0157] FIG. 30 presents a block diagram of an exemplary
event-processing system 100, similar to the SPLUNK.RTM. ENTERPRISE
system. System 100 includes one or more forwarders 101 that collect
data obtained from a variety of different data sources 105, and one
or more indexers 102 that store, process, and/or perform operations
on this data, wherein each indexer operates on data contained in a
specific data store 103. These forwarders and indexers can comprise
separate computer systems in a data center, or may alternatively
comprise separate processes executing on various computer systems
in a data center.
[0158] During operation, the forwarders 101 identify which indexers
102 will receive the collected data and then forward the data to
the identified indexers. Forwarders 101 can also perform operations
to strip out extraneous data and detect timestamps in the data. The
forwarders next determine which indexers 102 will receive each data
item and then forward the data items to the determined indexers
102.
[0159] 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.
[0160] System 100 and the processes described below are 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.
[0161] FIG. 31 presents a flowchart illustrating how an indexer
processes, indexes, and stores data received from forwarders in
accordance with the disclosed embodiments. At block 201, the
indexer receives the data from the forwarder. Next, at block 202,
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, wherein
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, wherein 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.
[0162] Next, the indexer determines a timestamp for each event at
block 203. 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
block 204, for example by storing the timestamp as metadata for
each event.
[0163] Then, the system can apply transformations to data to be
included in events at block 205. 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.
[0164] 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 block 206.
Then, at block 207 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.
[0165] 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."
[0166] Finally, the indexer stores the events in a data store at
block 208, 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.
[0167] Each indexer 102 is responsible for storing and searching a
subset of the events contained in a corresponding data store 103.
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, wherein 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.
[0168] 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.
[0169] FIG. 32 presents a flowchart illustrating how a search head
and indexers 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 at block 301. Next, at block
302, 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 block 303, 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.
[0170] Then, at block 304, 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 block 304 may
involve using the late-binding scheme 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.
[0171] Finally, at block 305, 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.
[0172] Moreover, the results generated by system 100 can 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.
[0173] 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.
[0174] FIG. 33 presents a block diagram illustrating how fields can
be extracted during query processing in accordance with the
disclosed embodiments. At the start of this process, a search query
402 is received at a query processor 404. Query processor 404
includes various mechanisms for processing a query, wherein these
mechanisms can reside in a search head 104 and/or an indexer 102.
Note that the exemplary search query 402 illustrated in FIG. 33 is
expressed in Search Processing Language (SPL), which is used in
conjunction with the SPLUNK.RTM. 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 "I" operates on the results produced by
the first command, and so on for additional commands. Search query
402 can also be expressed in other query languages, such as the
Structured Query Language ("SQL") or any suitable query
language.
[0175] Upon receiving search query 402, query processor 404 sees
that search query 402 includes two fields "IP" and "target." Query
processor 404 also determines that the values for the "IP" and
"target" fields have not already been extracted from events in data
store 414, and consequently determines that query processor 404
needs to use extraction rules to extract values for the fields.
Hence, query processor 404 performs a lookup for the extraction
rules in a rule base 406, wherein rule base 406 maps field names to
corresponding extraction rules and obtains extraction rules
408-409, wherein extraction rule 408 specifies how to extract a
value for the "IP" field from an event, and extraction rule 409
specifies how to extract a value for the "target" field from an
event. As is illustrated in FIG. 33, extraction rules 408-409 can
comprise 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.
[0176] Next, query processor 404 sends extraction rules 408-409 to
a field extractor 412, which applies extraction rules 408-409 to
events 416-418 in a data store 414. Note that data store 414 can
include one or more data stores, and extraction rules 408-409 can
be applied to large numbers of events in data store 414, and are
not meant to be limited to the three events 416-418 illustrated in
FIG. 33. Moreover, the query processor 404 can instruct field
extractor 412 to apply the extraction rules to all the events in a
data store 414, or to a subset of the events that have been
filtered based on some criteria.
[0177] Next, field extractor 412 applies extraction rule 408 for
the first command "Search IP="10*" to events in data store 414
including events 416-418. Extraction rule 408 is used to extract
values for the IP address field from events in data store 414 by
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 extractor 412
returns field values 420 to query processor 404, which uses the
criterion IP="10*" to look for IP addresses that start with "10".
Note that events 416 and 417 match this criterion, but event 418
does not, so the result set for the first command is events
416-417.
[0178] Query processor 404 then sends events 416-417 to the next
command "stats count target." To process this command, query
processor 404 causes field extractor 412 to apply extraction rule
409 to events 416-417. Extraction rule 409 is used to extract
values for the target field for events 416-417 by skipping the
first four commas in events 416-417, and then extracting all of the
following characters until a comma or period is reached. Next,
field extractor 412 returns field values 421 to query processor
404, 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
result 422 for the query.
[0179] 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.
[0180] FIG. 35A illustrates an exemplary search screen 600 in
accordance with the disclosed embodiments. Search screen 600
includes a search bar 602 that accepts user input in the form of a
search string. It also includes a time range picker 612 that
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 screen 600 also initially displays a "data summary" dialog
as is illustrated in FIG. 35B that enables the user to select
different sources for the event data, for example by selecting
specific hosts and log files.
[0181] After the search is executed, the search screen 600 can
display the results through search results tabs 604, wherein search
results tabs 604 includes: 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 in FIG. 35A displays a
timeline graph 605 that graphically illustrates the number of
events that occurred in one-hour intervals over the selected time
range. It also displays an events list 608 that enables a user to
view the raw data in each of the returned events. It additionally
displays a fields sidebar 606 that 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.
[0182] 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.
[0183] 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.
[0184] 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. 34 illustrates how a search query 501 received from a
client at search head 104 can split into two phases, including: (1)
a "map phase" comprising subtasks 502 (e.g., data retrieval or
simple filtering) that may be performed in parallel and are
"mapped" to indexers 102 for execution, and (2) a "reduce phase"
comprising a merging operation 503 to be executed by the search
head when the results are ultimately collected from the
indexers.
[0185] During operation, upon receiving search query 501, search
head 104 modifies search query 501 by substituting "stats" with
"prestats" to produce search query 502, and then distributes search
query 502 to 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 in FIG. 32, 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 operations 503 on the results. Note that by executing the
computation in this way, the system effectively distributes the
computational operations while minimizing data transfers.
[0186] As described above with reference to the flow charts in
FIGS. 31-32, event-processing system 100 can 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.
[0187] To speed up certain types of queries, some embodiments of
system 100 make 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 exemplary 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 all 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 all of the events to find the
specific field-value combination at search time.
[0188] 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, wherein the indexer-specific
summarization table only includes entries for the events in a data
store that is managed by the specific indexer.
[0189] 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.
[0190] In some cases, the summarization tables may not cover all 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.
[0191] In some embodiments, a data server system such as the
SPLUNK.RTM. 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.
[0192] 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.
[0193] The SPLUNK.RTM. 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.RTM. 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.RTM. 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.
[0194] In contrast, the SPLUNK.RTM. 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.RTM. 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.
[0195] The SPLUNK.RTM. 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.
[0196] During operation, the SPLUNK.RTM. 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.
[0197] The SPLUNK.RTM. 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. 36A illustrates an exemplary key indicators view
700 that comprises a dashboard, which can display a value 701, for
various security-related metrics, such as malware infections 702.
It can also display a change in a metric value 703, which indicates
that the number of malware infections increased by 63 during the
preceding interval. Key indicators view 700 additionally displays a
histogram panel 704 that displays a histogram of notable events
organized by urgency values, and a histogram of notable events
organized 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.
[0198] 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. 36B illustrates an
exemplary incident review dashboard 710 that includes a set of
incident attribute fields 711 that, for example, enables a user to
specify a time range field 712 for the displayed events. It also
includes a timeline 713 that graphically illustrates the number of
incidents that occurred in one-hour time intervals over the
selected time range. It additionally displays an events list 714
that enables a user to view a list of all of the notable events
that match the criteria in the incident attributes fields 711. 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/PCl/2.1.1/User/IncidentReviewdashbo-
ard."
[0199] As mentioned above, the SPLUNK.RTM. ENTERPRISE platform
provides various features that make it easy for developers to
create various applications. One such application is the
SPLUNK.RTM. APP FOR VMWARE.RTM., 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.RTM. ENTERPRISE system.
[0200] 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.RTM. APP FOR VMWARE.RTM. 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.
[0201] The SPLUNK.RTM. APP FOR VMWARE.RTM. 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.TM. 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-esx-
i-vcenter-server-551-monitoring-performance-guide.pdf.
[0202] To facilitate retrieving information of interest from
performance data and log files, the SPLUNK.RTM. APP FOR VMWARE.RTM.
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.
[0203] The SPLUNK.RTM. APP FOR VMWARE.RTM. 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). Exemplary node-expansion operations are illustrated
in FIG. 36C, wherein nodes 733 and 734 are selectively expanded.
Note that nodes 731-739 can 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.
[0204] The SPLUNK.RTM. APP FOR VMWARE.RTM. 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 in FIG. 36D displays 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 menus 742 to 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.
[0205] FIG. 37 illustrates a diagram of a machine in an example
form of a computer system 3700 within which a set of instructions,
for causing the machine to perform any one or more of the
methodologies discussed herein, may be executed. The computer
system 3700 can be client computing machine 2906 in FIGS. 29A-B.
The computer system 3700 can be server computing machine 2903 in
FIGS. 29A-B. In alternative implementations, the machine may be
connected (e.g., networked) to other machines in a LAN, an
intranet, an extranet, or the Internet. The machine may operate in
the capacity of a server or a client machine in client-server
network environment, or as a peer machine in a peer-to-peer (or
distributed) network environment. The machine may be a personal
computer (PC), a tablet PC, a set-top box (STB), a Personal Digital
Assistant (PDA), a cellular telephone, a web appliance, a server, a
network router, switch or bridge, or any machine capable of
executing a set of instructions (sequential or otherwise) that
specify actions to be taken by that machine. Further, while only a
single machine is illustrated, the term "machine" shall also be
taken to include any collection of machines that individually or
jointly execute a set (or multiple sets) of instructions to perform
any one or more of the methodologies discussed herein.
[0206] The example computer system 3700 includes a processing
device (processor) 3702, a main memory 3704 (e.g., read-only memory
(ROM), flash memory, dynamic random access memory (DRAM) such as
synchronous DRAM (SDRAM), double data rate (DDR SDRAM), or DRAM
(RDRAM), etc.), a static memory 3706 (e.g., flash memory, static
random access memory (SRAM), etc.), and a data storage device 3718,
which communicate with each other via a bus 3730.
[0207] Processor (processing device) 3702 represents one or more
general-purpose processing devices such as a microprocessor,
central processing unit, or the like. More particularly, the
processor 3702 may be a complex instruction set computing (CISC)
microprocessor, reduced instruction set computing (RISC)
microprocessor, very long instruction word (VLIW) microprocessor,
or a processor implementing other instruction sets or processors
implementing a combination of instruction sets. The processor 3702
may also be one or more special-purpose processing devices such as
an application specific integrated circuit (ASIC), a field
programmable gate array (FPGA), a digital signal processor (DSP),
network processor, or the like. The processor 3702 is configured to
execute instructions 3722 for performing the operations and steps
discussed herein.
[0208] The computer system 3700 may further include a network
interface device 3708. The computer system 3700 also may include a
video display unit 3710 (e.g., a liquid crystal display (LCD) or a
cathode ray tube (CRT)), an input device 3712 (e.g., a keyboard,
and alphanumeric keyboard, a motion sensing input device, touch
screen), a cursor control device 3714 (e.g., a mouse), and a signal
generation device 3716 (e.g., a speaker).
[0209] The data storage device 3718 can include a computer-readable
storage medium 3728 on which is stored one or more sets of
instructions 3722 (e.g., software) embodying any one or more of the
methodologies or functions described herein. The instructions 3722
can also reside, completely or at least partially, within the main
memory 3704 and/or within the processor 3702 during execution
thereof by the computer system 3700, the main memory 3704 and the
processor 3702 also constituting computer-readable storage media.
The instructions 3722 may further be transmitted or received over a
network 3720 via the network interface device 1008.
[0210] In one implementation, the instructions 1022 include
instructions for a correlation search wizard module (e.g.,
correlation search wizard module 2907 in FIGS. 29A-B) and/or a
software library containing methods that call the correlation
search wizard module. In one implementation, the instructions 1022
include instructions for a correlation search module (e.g.,
correlation search module 2904 in FIGS. 29A-B) and/or a software
library containing methods that call the correlation search module.
While the computer-readable storage medium 3728 (machine-readable
storage medium) is shown in an exemplary implementation to be a
single medium, the term "computer-readable storage medium" should
be taken to include a single medium or multiple media (e.g., a
centralized or distributed database, and/or associated caches and
servers) that store the one or more sets of instructions. The term
"computer-readable storage medium" shall also be taken to include
any medium that is capable of storing, encoding or carrying a set
of instructions for execution by the machine and that cause the
machine to perform any one or more of the methodologies of the
present disclosure. The term "computer-readable storage medium"
shall accordingly be taken to include, but not be limited to,
solid-state memories, optical media, and magnetic media.
[0211] In the foregoing description, numerous details are set
forth. It will be apparent, however, to one of ordinary skill in
the art having the benefit of this disclosure, that the present
disclosure may be practiced without these specific details. In some
instances, well-known structures and devices are shown in block
diagram form, rather than in detail, in order to avoid obscuring
the present disclosure.
[0212] Some portions of the detailed description have been
presented in terms of algorithms and symbolic representations of
operations on data bits within a computer memory. These algorithmic
descriptions and representations are the means used by those
skilled in the data processing arts to most effectively convey the
substance of their work to others skilled in the art. An algorithm
is here, and generally, conceived to be a self-consistent sequence
of steps leading to a desired result. The steps are those requiring
physical manipulations of physical quantities. Usually, though not
necessarily, these quantities take the form of electrical or
magnetic signals capable of being stored, transferred, combined,
compared, and otherwise manipulated. It has proven convenient at
times, for reasons of common usage, to refer to these signals as
bits, values, elements, symbols, characters, terms, numbers, or the
like.
[0213] It should be borne in mind, however, that all of these and
similar terms are to be associated with the appropriate physical
quantities and are merely convenient labels applied to these
quantities. Unless specifically stated otherwise as apparent from
the following discussion, it is appreciated that throughout the
description, discussions utilizing terms such as "providing",
"causing", "receiving", "obtaining", "displaying", "associating",
or the like, refer to the actions and processes of a computer
system, or similar electronic computing device, that manipulates
and transforms data represented as physical (e.g., electronic)
quantities within the computer system's registers and memories into
other data similarly represented as physical quantities within the
computer system memories or registers or other such information
storage, transmission or display devices.
[0214] For simplicity of explanation, the methods are depicted and
described herein as a series of acts. However, acts in accordance
with this disclosure can occur in various orders and/or
concurrently, and with other acts not presented and described
herein. Furthermore, not all illustrated acts may be required to
implement the methods in accordance with the disclosed subject
matter. In addition, those skilled in the art will understand and
appreciate that the methods could alternatively be represented as a
series of interrelated states via a state diagram or events.
Additionally, it should be appreciated that the methods disclosed
in this specification are capable of being stored on an article of
manufacture to facilitate transporting and transferring such
methods to computing devices. The term article of manufacture, as
used herein, is intended to encompass a computer program accessible
from any computer-readable device or storage media.
[0215] Certain implementations of the present disclosure also
relate to an apparatus for performing the operations herein. This
apparatus may be constructed for the intended purposes, or it may
comprise a general purpose computer selectively activated or
reconfigured by a computer program stored in the computer. Such a
computer program may be stored in a computer readable storage
medium, such as, but not limited to, any type of disk including
floppy disks, optical disks, CD-ROMs, and magnetic-optical disks,
read-only memories (ROMs), random access memories (RAMs), EPROMs,
EEPROMs, magnetic or optical cards, or any type of media suitable
for storing electronic instructions.
[0216] Reference throughout this specification to "one
implementation" or "an implementation" means that a particular
feature, structure, or characteristic described in connection with
the implementation is included in at least one implementation.
Thus, the appearances of the phrase "in one implementation" or "in
an implementation" in various places throughout this specification
are not necessarily all referring to the same implementation. In
addition, the term "or" is intended to mean an inclusive "or"
rather than an exclusive "or." Moreover, the words "example" or
"exemplary" are used herein to mean serving as an example,
instance, or illustration. Any aspect or design described herein as
"exemplary" is not necessarily to be construed as preferred or
advantageous over other aspects or designs. Rather, use of the
words "example" or "exemplary" is intended to present concepts in a
concrete fashion.
[0217] It is to be understood that the above description is
intended to be illustrative, and not restrictive. Many other
implementations will be apparent to those of skill in the art upon
reading and understanding the above description. The scope of the
disclosure should, therefore, be determined with reference to the
appended claims, along with the full scope of equivalents to which
such claims are entitled.
* * * * *
References