About lookups and workflow actions

Lookups and workflow actions enable you to enrich and extend the usefulness of your event data through interactions with external resources.

Lookup tables

Lookup tables use information in your events to determine how to add other fields from external data sources such as static tables (CSV files), Python- and binary-based scripts, and App Key Value Store (KV Store) collections. Each of these lookup types can optionally add fields based on time information.

An example of this functionality would be a CSV lookup that takes the http_status value in an event, matches that value with its definition in a CSV file, and then adds that definition to the event as the value of a new status_description field. So if you have an event where http_status = 503 the lookup would add status_description = Service Unavailable, Server Error to that event.

Of course, there are more advanced ways to work with lookups. For example, you can:

• Arrange to have a static lookup table be populated by the results of a report.
• Define a field lookup that is based on an external Python script rather than a lookup table. For example, you could create a lookup that uses a Python script that returns an IP address when given a host name, and returns a host name when given an IP address.
• Define a lookup that matches fields in your events with fields in a KV Store lookup, and then returns fields to your events. You can also design searches that write search results to KV Store collections.
• Create a time-based lookup, if you are working with a lookup table that includes a field value that represents time. For example, this could come in handy if you need to use DHCP logs to identify users on your network based on their IP address and the event timestamp.

For more information, see "Configure CSV and external lookups" and "Configure KV Store lookups"in this manual.

Workflow actions

Workflow actions enable you to set up interactions between specific fields in your data and other applications or web resources. A really simple workflow action would be one that is associated with an IP_address field, which, when launched, opens an external WHOIS search in a separate browser window based on the IP_address value.

You can also set up workflow actions that:

• Apply only to particular fields (as opposed to all fields in an event).
• Apply only to events belonging to a specific event type or group of event types.
• Are accessed either via event dropdown menus, field dropdown menus, or both.
• Perform HTTP GET requests, enabling you to pass information to an external web resource, such as a search engine or IP lookup service.
• Perform HTTP POST requests that can send field values to an external resource. For example, you could design one that sends a status value to an external issue-tracking application.
• Take certain field values from a chosen event and insert them into a secondary search that is populated with those field values and which launches in a secondary browser window.

For information about setting workflow actions up in Splunk Web, see "Create and maintain workflow actions in Splunk Web", in this chapter.