Modifying the fields in your search results

Fine-tune the information that your search returns by dropping or renaming event fields.

Fine-tune the information that your search returns by dropping or renaming event fields.

You can drop unnecessary event fields in order to further refine the scope of your search and reduce the noise in your data. While filtering narrows a search so that it returns fewer events, dropping fields narrows a search so that each returned event includes fewer details.

Additionally, you can make your search results easier to understand by renaming event fields. By assigning clear and context-appropriate names to fields, you can reduce the mental load required to interpret the data and better prepare your search results for sharing with other users.

See the following sections for more information:

Drop event fields

Reduce the noise in your search results by dropping irrelevant or redundant fields.

In some cases, indexed events contain fields that are not pertinent to your investigation, or the fields become redundant after you process the data. You can reduce the noise in your search results by dropping, or removing, these fields.

For example, assume that you search an index that contains product sales information for an online storefront, and the search results include these fields:

  • _time

  • _raw

  • host

  • clientip

  • method

  • action

  • categoryId

  • status

  • quantity

  • bytes

When you’re searching the data to investigate website traffic flow, the quantity and category of the purchases are irrelevant, so you can drop the quantity and categoryId fields. Additionally, if you process the data so that the values in the bytes field are converted into kilobytes and stored in a new field named kbytes, then you can drop the bytes field because it is redundant.

You can use the fields command with the minus sign ( - ) to drop specific fields. To add the fields command to your search, enter a pipe ( | ) character followed by this syntax, where field-list is either the name of a field or a comma-separated list of field names:

fields - <field-list>

For more information about the fields command, see fields in the SPL2 Search Reference.

Note: If you specify a field that doesn’t exist in your data, the fields command ignores that field and does not return any error messages.
The following table shows examples of searches that generate the kbytes field and then drop the quantity, categoryId, and bytes fields:
Example scenarioSearch statement

Using the search command

 
search index=main | eval kbytes = round((bytes / 1024), 3) | fields - quantity, categoryId, bytes

Using the from command, starting with the SELECT clause

 
SELECT * FROM main | eval kbytes = round((bytes / 1024), 3) | fields - quantity, categoryId, bytes

Using the from command, starting with the FROM clause

 
FROM main | eval kbytes = round((bytes / 1024), 3) | fields - quantity, categoryId, bytes

Additional methods for dropping event fields

If you need to drop many fields from your events, then listing all of them in the fields command can be cumbersome. As an alternative, you can use the fields command without the minus sign ( - ) to specify the event fields that you want to keep. In this case, the fields command will keep the event fields that you specified as well as the metadata fields that are used internally by the Splunk platform, such as _time and _raw, but drop all other fields.

For example, the following search keeps the _time, _raw, and kbytes fields but drops the other 7 fields from the example events:

search index=main | eval kbytes = round((bytes / 1024), 3) | fields kbytes

As an alternative to the fields command, you can also use the SELECT clause of the from command to include only specific fields in your search. Unlike the fields command, the SELECT clause will drop all unspecified fields, including internal metadata fields.

Be aware that, because the from command must be used at the beginning of a search, the SELECT clause can drop fields only before event processing occurs. You cannot use the SELECT clause to drop fields that are created by or used in subsequent commands.

For example:

Example scenarioSearch statementFields returned

Using the SELECT clause of the from command to include the _time, _raw, and bytes fields.

 
SELECT _time, _raw, bytes FROM main | eval kbytes = round((bytes / 1024), 3)

This search returns the following event fields:

  • _time

  • _raw

  • bytes

  • kbytes, with correct values

The SELECT clause drops all other fields. However, your final search results also includes the kbytes field, since the eval command creates that field after the SELECT clause drops the other event fields.

Using the SELECT clause of the from command to include the _time and _raw fields.

 
SELECT _time, _raw FROM main | eval kbytes = round((bytes / 1024), 3)

This search returns the following fields:

  • _time

  • _raw

  • kbytes, but returning as null

The SELECT clause drops all other fields, including bytes. This causes the eval command to return kbytes null, since the command cannot access the bytes field.

User interface impact caused by dropped fields

If you use the Search page to run a search that drops the _time or _raw fields, then the Timeline and Events viewer elements of the Search page do not display as expected.

Similarly, if you use the SPL2 module editor to run a search that drops the _time field, then the timeline in the search results panel does not display as expected.

For example, these searches cause the user interface to display incorrectly:

Example scenarioSearch statement

Using the fields command to drop the _time and _raw fields.

 
search index=main | fields - _time, _raw

Using the SELECT clause of the from command to include the host, clientip, and bytes fields only.

The SELECT clause drops the _time and _raw fields along with all other unspecified event fields.

 
SELECT host, clientip, bytes FROM main

For information about specific user interface elements in the Search page and the SPL2 module editor, see Search page overview for SPL2 and SPL2 module editor overview.

Rename event fields

Rename event fields so that they use clear and meaningful labels.

In some cases, you might want to rename an event field so that it uses a label that is more clear or meaningful.

For example, the following search uses the stats command to calculate the sum of the values in a field named bytes:

search index=main | stats sum(bytes)

This search returns the result in a single field named sum(bytes).

You can use the rename command to rename event fields. To add the rename command to your search, enter a pipe ( | ) character followed by this syntax, where source-field is the name of an existing field in your events that you want to rename and target-field is the updated name that you want to use:

rename <source-field> as <target-field>

For more information about the rename command, see rename in the SPL2 Search Reference.

Be aware of the following when using the rename command:

  • If a field name contains anything other than a-z, A-Z, 0-9, or the underscore ( _ ) character, then you must enclose it in single-quotation marks ( ' ).

  • If the source field doesn’t exist in your events, then the rename command ignores it and does not return any error messages.

  • If the target field already exists in your events, then the rename command overwrites it with the data from the source field. In this case, if the source field doesn’t exist, then the rename command removes the target field from your events. In both scenarios, the command does not return any error messages.

The following searches rename the sum(bytes) field to total_bytes_out:
Example scenarioSearch statement

Using the search command

 
search index=main | stats sum(bytes) | rename 'sum(bytes)' as total_bytes_out

Using the from command, starting with the SELECT clause

 
SELECT * FROM main | stats sum(bytes) | rename 'sum(bytes)' as total_bytes_out

Using the from command, starting with the FROM clause

 
FROM main | stats sum(bytes) | rename 'sum(bytes)' as total_bytes_out

If you’re using the from command to search your data, then you can choose to calculate the sum of the bytes field and rename the resulting field by using the SELECT clause of the command instead of adding a stats command to your search.

The following searches achieve the same results as the searches in the previous table:
Example scenarioSearch statement

Starting with the SELECT clause

 
SELECT sum(bytes) AS total_bytes_out FROM main

Starting with the FROM clause

 
FROM main SELECT sum(bytes) AS total_bytes_out

Next step

Continue to work with your searches and the resulting data.

If you followed the guidance in these Quick start topics to build your SPL2 search, you now have a search that returns a curated subset of indexed data that is specific and relevant to your needs.

There are a variety of ways that you can continue to work with this search and the resulting data. For example:

  • You can save the search as a report, alert, or dashboard. For more information, see the Creating reports, alerts, and dashboards chapter.

  • If you wrote the search in the SPL2 module editor, then you can also do the following:

    • Create branched searches that use the results of this initial search as the starting dataset. For more information, see Branching SPL2 searches.

    • Export the search as an SPL2 view, so that you or other users on the Splunk platform deployment can import that view into another SPL2 module and then use the search results as a dataset. For more information, see SPL2 views and the Export, import, and namespaces chapter.