Configuring Splunk - Implementing Splunk: Big Data Reporting and Development for Operational Intelligence - page 306

If we know ahead of time that a value of req_time>999 is bad, and we can come up
with a regular expression to specify what bad is, we can tag these events for quicker
retrieval. Say we have this transforms.conf stanza:
[myapp_slow]
REGEX = req_time=\d{4,}
FORMAT = slow_request::1
WRITE_META = True
This REGEX will match any event containing req_time= followed by four or
more digits.
After adding slow_request to fields.conf (see the fields.conf section), we can
search for slow_request=1 and find all slow events very efficiently. This will not
apply to events that were indexed before this transform existed. If the events that
are slow are uncommon, this query will be much faster.
Creating host categorization fields
It is common, to have parts of a hostname mean something in particular. If this
pattern is well known and predictable, it may be worthwhile to pull the value out
into fields. Working from our fictitious host value, vlbmba.local (which happens
to be my laptop), we might want to create fields for owner and hosttype . Out stanza
might look like this:
[host_parts]
SOURCE_KEY = MetaData:Host
REGEX = (...)(...)\.
FORMAT = host_owner::$1 host_type::$2
WRITE_META = True
With our new fields, we can now easily categorize errors by whatever information
is encoded into the hostname. Another approach would be to use a lookup, which
has the advantage of being retroactive. This approach has the advantage of faster
searches for the specific fields.
Modifying metadata fields
It is sometimes convenient to override the main metadata fields. We will look at one
possible reason for overriding each base metadata value.