Use fields to retrieve events
Fields are searchable name/value pairings in event data. All fields have names and can be searched with those names. Searches with field expressions are more precise (and therefore more efficient) than searches using only keywords and quoted phrases.
Look at the following search:
In this search,
host=webserver indicates that you are searching for events with
host fields that have values of
webserver. When you run this search, events with different
host field values are not retrieved, nor are events that contain other fields that share
webserver as a value. This means that this search returns a more focused set of results than you might get if you just searched for
webserver in the search bar.
For more information, read "About fields" in the Knowledge Manage Manual.
Index-time and search-time fields
As Splunk software processes event data, it extracts and defines fields from that data, first at index time, and again at search time.
See "Index time versus search time" in the Managing Indexers and Clusters manual.
Field extraction at index time
Default fields exist in all events. Three important default fields are host, source, and source type. They describe where the event originated. Other default fields include datetime fields, which provide additional searchable granularity to event timestamps. Splunk software also automatically adds default fields classified as internal fields.
Custom indexed fields are fields that you have manually configured for index-time extraction. See "Create custom fields at index time" in the Getting Data In manual.
Finally, when Splunk software indexes structured data, it creates index-time field extractions for the fields that it finds. Examples of structured data include:
- comma-separated value files (CSV)
- tab-separated value files (TSV)
- pipe-separated value files
When searching for default field values and custom indexed field values you can use the standard
<field>=<value> syntax. This syntax matches default fields, custom indexed fields, and search-time fields.
However if you are searching specifically for a field that has been extracted at index-time from structured data, you can search more efficiently if you exchange the equal sign for a double colon, as follows:
This syntax works best in searches for fields that were indexed from structured data. However, you can use it to search for default and custom indexed fields as well. You cannot use it to search on Search-time fields.
For more information about extracting fields from structured data files, see "Extract data from files with headers" in the Getting Data In manual.
Field extraction at search time
Example 1: Search for events on all "corp" servers for accesses by the user "strawsky". It then reports the 20 most recent events.
host=corp* eventtype=access user=strawsky
In this example,
host is a default field, while
user are additional fields that might have been automatically extracted or that you defined.
In general, an event type is a user-defined field that simplifies search by letting you categorize events. You can save a search as an event type and quickly retrieve those events using the
eventtype field. For more information, read "About event types" in the Knowledge Manager Manual.
Example 2: Search for events from the source "/var/www/log/php_error.log".
The source of an event is the name of the file, stream, or other input from which the event originates.
Example 3: Search for all events that have an Apache web access source type.
The source type of an event is the format of the data input from which it originates. In this search uses a wildcard to match any Apache web access log that begins with "access_". This includes access_common and access_combined (and you might also see access_combined_wcookie).
Example 4: Search indexed information from various CSV files to get a list of Plano-based employees.
You have indexed several CSV files of employee records. Each of these CSV files share the same fields. You want to search for the employees from these files that are affiliated with the office in Plano, Texas.
This example uses the
<field>::<value> syntax to find the fields from those CSV files, which are extracted at index time. This syntax works best for fields extracted from indexed structured data, although it can handle other kinds of index time fields as well. It cannot find fields that are extracted at search time.
Example 5: Search corp1 for events that have more than 4 lines, and omit events that contain the term 400.
host=corp1 linecount>4 NOT 400
You can use comparison expressions to match field/value pairs. Comparison expressions with "=" and "!=" work with all field/value pairs. Comparison expressions with < > <= >= work only with fields that have numeric values. This example specifies a search for events that have more than 4 lines,
Example 6: Searching with the boolean "NOT" versus the comparison operator "!=" is not the same. The following search returns events where
field is undefined (or NULL).
The following search returns events where
field exists and does not have the value "value".
In the case where the value in question is the wildcard "*",
NOT field=* will return events where field is null/undefined, and
field!=* will never return any events.
More about fields
This topic only discussed a handful of searches with fields.
- You can restrict searches to specific indexes and, in distributed topologies, to specific search peers.
- You can see more search examples "Using default fields" in the Knowledge Manager Manual.
Fields become more important when you start using the Splunk search language to summarize and transform your data into reports. For more information, read "About reporting commands".
About retrieving events
This documentation applies to the following versions of Splunk® Enterprise: 6.3.0, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.5.0, 6.5.1, 6.5.1612 (Splunk Cloud only), 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.1.0, 7.1.1