Understanding Search - Implementing Splunk: Big Data Reporting and Development for Operational Intelligence - page 31

Supplementing wildcards in fields
Given the following events, a search for world would return both events:
2012-02-07T01:04:31.102-0600 INFO AuthClass Hello world. [user=Bobby,
ip=1.2.3.3]
2012-02-07T01:23:34.204-0600 INFO BarClass Goodbye. [user=Bobby,
ip=1.2.3.3, message="Out of this world"]
What if you only wanted the second event, but all you know is that the event
contains world somewhere in the field message ? The query message="*world*"
would work but is very inefficient because Splunk must scan every event looking
for *world* and then determine whether world is in the field message .
You can take advantage of the behavior mentioned before—wildcards are
tested last. Rewriting the query as world message="*world*" gives Splunk
a chance to find all records with world , then inspect those events for the more
specific wildcard condition.
All about time
Time is an important and confusing topic in Splunk. If you want to skip this section,
absorb one concept—time must be parsed properly on the way into the index as it
cannot be changed later without indexing the raw data again.
How Splunk parses time
Given the date 11-03-04 , how would you interpret this date? Your answer probably
depends on where you live. In the United States, you would probably read this as
November 3, 2004. In Europe, you would probably read this as March 11, 2004. It
would also be reasonable to read this as March 4, 2011.
Luckily, most dates are not this ambiguous, and Splunk makes a good effort. It is
absolutely worth the trouble to give Splunk a little help by configuring the time
format. We'll discuss the relevant configurations in Chapter 10 , Configuring Splunk .
How Splunk stores time
Once the date is parsed, the date stored in Splunk is always stored as GMT epoch.
Epoch time is the number of seconds since January 1, 1970, the birthday of Unix. By
storing all events using a single time zone, there is never a problem lining up events
that happen in different time zones. This, of course, only works properly if the time
zone of the event can be determined when it is indexed. This numeric value is stored
in the field _time .