Speeding up Splunk dashboards with tstats and accelerated CIM data models

Concrete problem

In many environments a dashboard panel runs a search like this:

index=os sourcetype=linux_secure | stats count by src over last 30 days

Every time the panel refreshes, Splunk re‑reads raw events from the os index, scans the entire 30‑day window, and then aggregates. On a busy cluster this can take 30–60 seconds or more, and the panel lags behind the rest of the dashboard.

Thesis: use tstats with accelerated CIM models

The tstats command reads pre‑computed field values stored in .tsidx files. When the underlying data model is accelerated, those files contain only the fields you need, so the search engine skips the raw event streams entirely. The result is a dramatic speed‑up for the same query.

What tstats can do out of the box

• Works on any indexed field (host, source, sourcetype, indexed keywords) without extra setup.
• Syntax: | tstats [summariesonly=true|false] statistic from datamodel=Model where condition by fields [span=duration]
• When summariesonly=true, tstats reads only accelerated data; otherwise it falls back to raw events for unaccelerated ranges.

Why CIM data models matter

Splunk ships the Common Information Model (CIM) add‑on, which includes data models such as Authentication, Network_Traffic, and Web. These models map vendor‑specific event fields to a shared namespace (e.g., Authentication.src, Authentication.action). Acceleration creates .tsidx files that store exactly those fields, making tstats queries fast and consistent across data sources.

Worked example: from raw SPL to accelerated tstats

Original panel (raw SPL):

index=auth "Failed password" | stats count by src_ip, _time span=1h

Rewrite using the Authentication data model:

| tstats summariesonly=true count 
    from datamodel=Authentication 
    where Authentication.action="failure" 
    by Authentication.src, _time 
    span=1h

Explanation of the rewrite:

• summariesonly=true forces the search to read only the accelerated index.
• Authentication.action="failure" matches the CIM field that maps to the event keyword.
• Field references use the exact CIM object and field names (Authentication.src).
• The span=1h clause groups the data into hourly buckets, matching the original query’s intent.

To verify the performance gain, run both searches in the Search Job Inspector. You should see:

Metric	Raw SPL	tstats
Run time	45 s	1.2 s
Data scanned (GB)	3.5	0.02

Note that the numbers above are illustrative; your own cluster may see different values.

Trade‑offs and limitations

• Disk overhead: Accelerated summaries consume disk space that grows with field cardinality and the retention window. Monitor Settings > Data models to see build progress and indexer disk usage before and after enabling acceleration.
• Backfill load: Enabling acceleration triggers a backfill job that processes historical data. Schedule it during off‑peak hours to avoid impacting search performance.
• Rebuilds on model changes: Editing a data model forces a rebuild of the .tsidx files, which can temporarily slow searches that rely on that model.
• Limited to indexed or model fields: tstats cannot return free‑text fields or fields that aren’t part of the data model. Ad‑hoc investigations still require raw SPL.
• Retention vs. acceleration window: Accelerated data covers only the configured window (e.g., last 90 days). Older data is still searched raw, so dashboards that span longer periods will hit raw events.
• Version differences: The behavior of tstats and data‑model acceleration can vary between Splunk Enterprise and Splunk Cloud, and across major releases. Verify against your specific version’s documentation.

Actionable rollout plan

1. Identify critical dashboards: List panels that run >30 s on large indexes.
2. Map to CIM models: For each panel, find the closest CIM data model that contains the needed fields.
3. Enable acceleration:
   • Navigate to Settings > Data models.
   • Select the model, click Accelerate, choose the retention window, and start the build.
   • Monitor the build progress; once 100% is reached, acceleration is ready.
4. Rewrite panels:
   • Replace raw SPL with the tstats version, using summariesonly=true.
   • Test the new panel in the dashboard editor, then run it in Search Job Inspector to confirm performance.
5. Measure disk impact:
   • Run splunk list index before and after to quantify the summary index size.
   • Adjust the retention window if disk usage becomes a concern.
6. Document changes:
   • Record the original SPL, the rewritten tstats query, and the observed performance metrics.
   • Include the data model name and acceleration window in the documentation for future maintenance.
7. Monitor for regressions:
   • Set up a small alert that fires if a tstats panel’s run time exceeds a threshold (e.g., 5 s).

By following this plan you’ll achieve near‑instant panel refreshes for your most critical dashboards while keeping an eye on disk usage and rebuild impact. Keep raw SPL searches for exploratory work, and reserve tstats for fixed, high‑volume queries that can benefit from acceleration.