Splunk Search Optimization
Search Optimization
Search Modes determine how much field data is returned, which affects how fast a search is returned.
- 3 modes:
- Smart Mode
- default mode
- balances speed and completeness
- for transforming searches, behave like fast mode
- for non-transforming searches, behaves like verbose mode
- Fast Mode
- prioritizes speed over completeness
- field discovery is disabled
- only returns info on default fields and fields required to fulfill search
- Verbose Mode
- prioritizes completeness over speed
- returns all extracted fields, an event list, and an event timeline
- slowest
- Smart Mode
- Using time to filter events is the most efficient
- followed by:
- index
- source
- host
- sourcetype
- followed by:
Splunk Search Scheduler
Search scheduler defines and manages when scheduled reports and alerts will run.
- limit to the number of searches Splunk can run concurrently
- determined by number of CPUs
- when there are too many searches, the a priority is used to determine which search to run
- Ad hoc historical searches
- e.g., searches run manually
- Manually scheduled searches with real-time scheduling
- e.g., user-saved scheduled reports and alerts that use real-time scheduling
- real-time is a scheduling mechanism (does not mean constantly running)
- these have potentially to be skipped
- Manually scheduled searches with continuous scheduling
- e.g., user-saved scheduled reports or alerts that use continuous scheduling
- searches can be paused for extensive periods of time
- Automatically scheduled searches
- e.g., auto-summarization reports
- Ad hoc historical searches
Search Acceleration Overview
- time it takes to return results is affected by the number of events returned in a search
- Splunk allows creation of summaries of event data
- these are smaller segments of event data populated by background searches that only include the data needed to fulfill the search
- when you run a search against a summary, it should complete much faster
- 3 data summary creation methods:
- Report acceleration
- uses automatically created summaries to speed up completion time for reports
- Summary indexing
- uses manually enabled summaries
- these indexes live separately from other indexes in deployment
- Data model acceleration
- accelerates all fields in a data model
- easiest and most efficient option
- Report acceleration
Report Acceleration
- used to accelerate individual reports
- when an accelerated report is created, Splunk runs the report and populates and acceleration summary
- acceleration summary is a stored search result populated every 10 minutes
- summaries are stored as file chunks by time alongside buckets in your indexes
- when the report is run, the events stored in the summary are used to return results
- before accelerating a report:
- search mode must be Smart or Fast
- users must have the schedule search privilege
- deleting all reports used by a summary, then the summary also gets deleted
- must be aware of commands the report is using
- 3 types:
- Streaming commands
- operate on events as they are returned
- Non-streaming commands
- wait until all events are returned by indexers before executing
- Transforming commands
- order results into a data table
- Streaming commands
- accelerated reports must include a transforming command
- any commands before a transforming command can only be streaming commands
- any commands after a transforming command need to be non-streaming
- 3 types:
Data Model Acceleration
- creates a High-Performance Analytics Store which are files used to speed up searches
- 2 types of data model acceleration
- ad-hoc
- takes place on data models that have not been accelerated
- files created for an acceleration are stored on a search head
- only exist when the user is actively using the pivot tool
- first time opening a pivot runs on all the data in the data model
- so may take long
- pivot editor uses the summary data,
- but reports created in the pivot editor will not
- running ad-hoc acceleration is taxing on a deployment
- only apply to one user
- persistent
- address the problem of ad-hoc acceleration
- the file created for a persistent acceleration are stored alongside buckets on the indexers
- exist as long as the data model exists
- can be scoped to time ranges
- maintained on an on-going basis
- can be used by all users
- ad-hoc
- restrictions
- requires a user with accelerate data models privilege or admin role
- private data models cannot be accelerated
- once a data model is accelerated, it cannot be edited
- only event data set hierarchies and search data set hierarchies that only use streaming commands can be used
- how to:
- Settings > Data Models > Edit > Accelerate > Summary Range
- yellow lightning bolt means data model is accelerated
- Settings > Data Models > Edit > Accelerate > Summary Range
- the files created for data model acceleration are called time-series index files (tsidx)
- 2 main components
- lexicon
- is an alphanumerically ordered list of terms found in the data at index time
- any fields extracted at index time are shown as key-value pairs in lexicon
- posting list
- is an array of pointers that match each term to events in the raw data files
- lexicon
- similar to a complex index for a book
- every word included in the book is found in the index
- 2 main components
Datamodel Command
datamodel command displays the structure of data models and searches against them.
- without arguments, generates a list of data models you have access to
- in json
- select a specific data model by specifying the data model id as argument
modelName
- can also search with data set ID to filter further
- can pull data through the data model in 2 ways:
- use
searchoption- returns a list of events and a field sidebar
- use
flatoption- field sidebar does not indicate which data set defines each field
- don’t have to specify the data set nam
- automatically chooses a data set to use
- defaults to first data set
- use
| dataset [<data-model-id>] [<data-set-id>] [search|flat]- IDs are case sensitive
summariesonly=toption uses only data in data summaries- otherwise uses raw data
Tstats Command
tstats command generates statistics from tsidx files.
- generating command
- requires a stats function
| tstats <stats-func> [from datamodel=<data-model-name>] [where <searchQuery>] [by <field-list>]summariesonly=tuses only data from data summaries- much faster that regular stats
- but can only use fields found in
tsidxfiles
- but can only use fields found in
- can group by
_time- behaves like the
timechartcommand spanto set time buckets
- behaves like the
Example
| tstats sum(apac.price) as Sales from datamodel=vsales.apac by apac.Vendor, apac.VendorCountry, apac.VendorCity
| search Sales > 200