Search Job Inspector

Search Job Inspector

Splunk provides a tool called the search job inspector, which lets you take a closer look at what your search is doing and where Splunk is spending most of its time. This topic discusses how to use the search job inspector to both troubleshoot the performance of the search and understand the behavior of knowledge objects such as event types, tags, lookups and so on within the search.

How to find the job inspector

You can access the Search Job Inspector for a search job as long as the search artifact still exists (which means that the search has not expired). The search does not still have to be running.

To view a search's properties with the job inspector:

1. Run the search.

2. From the Actions dropdown menu, select Inspect search job...

This opens the Search Job Inspector in a new browser window.

To view the properties of a search artifact:

You can use the URL to inspect a search job artifact if you have its search ID (SID). You can find the SID of a search in the Job Manager (click the Jobs link in the upper right hand corner) or listed in Splunk's dispatch directory, $SPLUNK_HOME/var/run/splunk/dispatch . For more information about the Job Manager, see Supervise your search jobs in the User Manual.

If you look at the URI path for the Search Job Inspector window, you will see something like this at the end of the string:

.../inspector?sid=1299600721.22&namespace=search

The sid and namespace are the SID number and the name of the app that it belongs to. Here, the SID is 1299600721.22.

Type the search artifact's SID into the URI path, after sid= and hit return. As long as you have the necessary ownership permissions to view the search, you will be able to inspect it.

Now, what exactly are you looking at?

What the job inspector shows you

While the search is running, the job inspector shows you two different panels. Execution costs lists information about the components of the search and how much impact each component has on the overall performance of the search. Search job properties lists other characteristics of the job. When the search finishes, the job inspector tells you how many results it found and the time it took to complete the search. Most of the information is self-explanatory, but this section will discuss the panels in more detail.

Execution costs

The Execution costs panel enables you to troubleshoot the efficiency of your search by narrowing it down to the performance impact of specific components that relate to a search-time event processing action. This panel displays a table of the components, their individual durations in seconds, how many times each was invoked while the search ran, and the input and output event counts for each component. The components are listed alphabetically and you will see more or fewer components depending on the search you run. The following table describes the significance of each individual search command and distributed search component. (These are the components you will see if you just run a keyword search.)

Search command component name	Description
command.search	Once Splunk identifies the events containing the indexed fields matching your search, it looks into the events themselves to identify the ones that match other criteria. These are concurrent operations, not consecutive. command.search.index - tells how long it took to look into the TSIDX files for the location to read in the rawdata. command.search.rawdata - tells how long it took to read the actual events from the rawdata files command.search.typer - tells how long it took identify event types. command.search.kv - tells how long it took to apply field extractions to the events. command.search.fieldalias - tells how long it took to rename fields based according to props.conf. command.search.lookups - tells how long it took to create new fields based on existing fields (perform field lookups). command.search.filter - tells how long it took to filter out events that don't match (for example, fields and phrases). command.search.typer - tells how long it took to assign event types to events. command.search.tags - tells how long it took to assign tags to events.
Distributed search component name	Description
dispatch.createProviderQueue	The time to connect to all search peers.
dispatch.evaluate	The time spent on argument parsing and subsearch evaluation. This is broken down further on each search command that is used. dispatch.evaluate.search - This tells you that the search command was run.
dispatch.fetch	The time spent waiting for or fetching events from search peers.
dispatch.preview	The time spent generating preview results.
dispatch.process_remote_timeline	The time spent decoding timeline information generated by search peers.
dispatch.stream.local	The time spent by search head on the streaming part of the search.
dispatch.timeline	The time spent generating the timeline and field picker information.

Search job properties

The Search job properties fields are listed in alphabetical order.

Parameter name	Description
createTime	The time the search was run.
diskUsage	The total amount of disk space used.
eai:acl	This describes the app and user-level permissions. For example, is the app shared globally and what users can run or view the search?
eventAvailableCount	The number of events that are available for export.
eventCount	The number of events returned by the search.
eventFieldCount	The number of fields found in the search results.
messages	Errors and debug messages.
performance	This is another representation of the Executive costs.
remoteSearch	The search string that is sent to every search peer.
reportSearch	If reporting commands are used, the reporting search.
request	GET arguments that the search sends to splunkd.
resultCount	The total number of results returned by the search.
runDuration	Time in seconds that the search took to complete.
scanCount	The number of events that are scanned or read off disk.
search	The search string.
searchProviders	A list of all the search peers that were contacted.
sid	The search ID number.
ttl	The time to live, or time before the search job expires after it completes.
Additional info	Links to further information about your search. These links may not always be available. timeline field summary search.log

Examples of Search Job Inspector output

Here's an example of the execution costs for a dedup search, run over All time:

The search commands component of the Execution costs panel might look something like this:

The command.search component and everything under it, gives you the performance impact of the search command portion of your search, which is everything before the pipe character.

Then, command.prededup gives you the performance impact of processing the results of the search command before passing it into the dedup command. The Input count of command.prededup matches the Output count of command.search, and the Input count of command.dedup matches the Output count of command.prededup. In this case, the Output count of command.dedup should match the number of events returned at the completion of the search (which is the value of resultCount, under Search job properties).

Answers

Have questions? Visit Splunk Answers and see what questions and answers the Splunk community has about using the Search Job Inspector.

• Was this topic useful?
• Post a comment