Manage report acceleration

Report acceleration is the easiest way to speed up transforming searches and reports that take a long time to complete because they have to cover a large volume of data. You enable acceleration for a transforming search when you save it as a report. You can also accelerate report-based dashboard panels that use a transforming search.

This topic covers various aspects of report acceleration in more detail. It includes:

  • A quick guide to enabling automatic acceleration for a transforming report.
  • Examples of qualifying and nonqualifying reports (only specific kinds of reports qualify for report acceleration).
  • Details on how report acceleration summaries are created and maintained
  • An overview of the Report acceleration summaries page in Settings, which you can use to review and maintain the data summaries that are used for automatic report acceleration.

Restrictions on report acceleration

You cannot accelerate a report if:

  • You created it through Pivot. Pivot reports are accelerated via data model acceleration. See Manage data models.
  • Your permissions do not enable you to accelerate searches. You cannot accelerate reports if your role does not have the schedule_search and accelerate_search capabilities.
  • Your role does not have write permissions for the report.
  • The search that the report is based upon is disqualified for acceleration. For more information, see How reports qualify for acceleration.

In addition, be careful when accelerating reports whose base searches include tags, event types, search macros, and other knowledge objects whose definitions can change independently of the report after the report is accelerated. If this happens, the accelerated report can return invalid results.

If you suspect that your accelerated report is returning invalid results, you can verify its summary to see if the data contained in the summary is consistent. See Verify a summary.

Enabling report acceleration

You can enable report acceleration when you create a report, or later, after the report is created.

For a more thorough description of this procedure, see Create and edit reports, in the Reporting Manual.

Enabling report acceleration when you create a report

You can enable report acceleration for qualifying reports.

Prerequisites

Steps

  1. In Search, run a search that qualifies for report acceleration.
  2. Select Save As > Report.
  3. Give your report a Name and optionally, a Description.
  4. Select Save to save the search as a report.

  5. Select Acceleration.

    You can accelerate the report only if the report qualifies for acceleration and your permissions allow you to accelerate reports. To be able to accelerate reports your role has to have the schedule_search and accelerate_search capabilities.

  6. Select Accelerate Report.

  7. Select a Summary Range.

    Base your selection on the range of time over which you plan to run the report. For example, if you only plan to run the report over periods of time within the last seven days, choose 7 Days.

  8. Select Save to save your acceleration settings.

Enabling report acceleration for an existing report

You can enable acceleration for a qualifying existing report.

Prerequisites

Steps

  1. On the Reports listing page, find a report that you want to accelerate.

  2. Expand the report row by clicking on the > symbol in the first column.

    The Acceleration line item displays the acceleration status for the report. Its value will be Disabled if it is not accelerated.

  3. Select Edit.

    You can only accelerate the report if the report qualifies for acceleration and your permissions allow you to accelerate reports. To be able to accelerate reports your role has to have the schedule_search and accelerate_search capabilities.

  4. Select Accelerate Report.

  5. Select a Summary Range.

    Base your selection on the range of time over which you plan to run the report. For example, if you only plan to run the report over periods of time within the last seven days, choose 7 Days.

  6. Select Save to save your acceleration settings.

Alternatively, you can enable report acceleration for an existing report at Settings > Searches, Reports, and Alerts.

After you enable acceleration for a report

When you enable acceleration for your report, the Splunk software begins building a report acceleration summary for the report if it determines that the report would benefit from summarization. To find out whether your report summary is being constructed, go to Settings > Report Acceleration Summaries. If the Summary Status is stuck at 0% complete for an extended amount of time, the summary is not being built.

See Conditions under which Splunk software cannot build or update a summary.

Once the summary is built, future runs of an accelerated report should complete faster than they did before. See the subtopics below for more information on summaries and how they work.

Note: Report acceleration only works for reports that have Search Mode set to Smart or Fast. If you select the Verbose search mode for a report that benefits from report acceleration, it will run as slow as it would if no summary existed for it. Search Mode does not affect searches powering dashboard panels.

For more information about the Search Mode settings, see Search modes in the Search Manual.

How reports qualify for acceleration

For a report to qualify for acceleration its search must meet three criteria:

  • The search string must use a transforming command (such as chart, timechart, stats, and top).
  • If the search string has any commands before the first transforming command, they must be streamable.
  • The search cannot use event sampling.
Note: You can use non-streaming commands after the first transforming command and still have the report qualify for automatic acceleration. It's just non-streaming commands before the first transforming command that disqualify the report.

For more information about event sampling, see Event sampling in the Search Manual.

Examples of qualifying search strings

Here are examples of search strings that qualify for report acceleration:

CODE 
index=_internal | stats count by sourcetype
CODE 
index=_audit search=* | rex field=search "'(?.*)'" | chart count by user search
CODE 
test foo bar | bin _time span=1d | stats count by _time x y
CODE 
index=_audit | lookup usertogroup user OUTPUT group | top searches by group

Examples of nonqualifying search strings

And here are examples of search strings that do not qualify for report acceleration:

Reason the following search string fails: This is a simple event search, with no transforming command.

CODE 
index=_internal metrics group=per_source_thruput

Reason the following search string fails:eventstats is not a transforming command.

CODE 
index=_internal sourcetype=splunkd *thruput | eventstats avg(kb) as avgkb by group

Reason the following search string fails:transaction is not a streaming command. Other non-streaming commands include dedup, head, tail, and any other search command that is not on the list of streaming commands.

CODE 
index=_internal | transaction user maxspan=30m | timechart avg(duration) by user

Search strings that qualify for report acceleration but won't get much out of it

In addition, you can have reports that technically qualify for report acceleration, but which may not be helped much by it. This is often the case with reports with high data cardinality--something you'll find when there are two or more transforming commands in the search string and the first transforming command generates many (50k+) output rows. For example:

CODE 
index=* | stats count by id | stats avg(count) as avg, count as distinct_ids

Set report acceleration summary time ranges

Report acceleration summaries span an approximate range of time. You determine this time range when you choose a value from the Summary Range list. At times, a report acceleration summary can have a store of data that slightly exceeds its summary range, but the summary never fails to meet that range, except while it is first being created.

For example, if you set a Summary Range of 7 days for an accelerated report, a data summary that approximately covers the past seven days is created. Every 10 minutes, by default, a summary creation search runs to ensure that the summary always covers the selected range. Every 30 minutes, by default, a maintenance search removes older summary data that passes out of the Summary Range.

When you then run the accelerated report over a range that falls within the past 7 days, the report searches its summary rather than the source index (the index the report originally searched). In most cases the summary has far less data than the source index, and this--along with the fact that the report summary contains precomputed results for portions of the search pipeline--means that the report should complete faster than it did on its initial run.

When you run the accelerated report over a period of time that is only partially covered by its summary, the report does not complete quite as fast because the Splunk software has to go to the source index for the portion of the report time range that does not fall within the summary range.

If the Summary Range setting for a report is 7 Days and you run the report over the last 9 days, the Splunk software only gets acceleration benefits for the portion of the report that covers the past 7 days. The portion of the report that runs over days 8 and 9 will run at normal speed.

Keep this in mind when you set the Summary Range value. If you always plan to run a report over time ranges that exceed the past 7 days, but don't extend further out than 30 days, you should select a Summary Range of 1 month when you set up report acceleration for that report.

How the Splunk platform builds report acceleration summaries

After you enable acceleration for an eligible report, Splunk software determines whether it will build a summary for the report. A summary for an eligible report is generated only when the number of events in the hot bucket covered by the chosen Summary Range is equal to or greater than 100,000. For more information, see Conditions under which the Splunk platform cannot build or update a summary.

When Splunk software determines that it will build a summary for the report, it begins running the report to populate the summary with data. When the summary is complete, the report is run every ten minutes to keep the summary up to date. Each update ensures that the entire configured time range is covered without a significant gap in data. This method of summary building also ensures that late-arriving data will be summarized without complication.

Report acceleration summaries can take time to build and maintain

It can take some time to build a report summary. The creation time depends on the number of events involved, the overall summary range, and the length of the summary timespans (chunks) in the summary.

You can track progress toward summary completion on the Report Acceleration Summaries page in Settings. On the main page you can check the Summary Status to see what percentage of the summary is complete.

Note: Just like ordinary scheduled reports, the reports that automatically populate report acceleration summaries on a regular schedule are managed by the report scheduler. By default, the report scheduler is allowed to allocate up to 25% of its total search bandwidth for report acceleration summary creation.

The report scheduler also runs reports that populate report acceleration summaries at the lowest priority. If these "auto-summarization" reports have a scheduling conflict with user-defined alerts, summary-index reports, and regular scheduled reports, the user-defined reports always get run first. This means that you may run into situations where a summary is not created or updated because reports with a higher priority are running.

For more information about the search scheduler see Configure the priority of scheduled reports in the Reporting Manual.

Use parallel summarization to speed up creation and maintenance of report summaries

If you feel that the summaries for some of your accelerated reports are building or updating too slowly, you can turn on parallel summarization for those reports to speed the process up. To do this you add a parameter in savedsearches.conf for the report or reports in question.

Under parallel summarization, multiple search jobs are run concurrently to build a report acceleration summary. It also runs the same number of concurrent searches on a 10 minute schedule to maintain those summary files. Parallel summarization decreases the amount of time it takes for report acceleration summaries to be built and maintained.

There is a cost for this improvement in summarization search performance. The concurrent searches count against the total number of concurrent search jobs that your Splunk deployment can run, which means that they can cause increased indexer resource usage.

1. Open the savedsearches.conf file that contains the report that you want to update summarization settings for.

2. Locate the stanza for the report.

3. Add auto_summarize.max_concurrent = 2 if that parameter is not present in the stanza.

4. Save your changes.

If you turn on parallel summarization for some reports and find that your overall search performance is impacted, either because you have too many searches running at once or your concurrent search limit is reached, you can easily restore the auto_summarize.max_concurrent value of your accelerated reports back to 1.

In general we do not recommend increasing auto_summarize.max_concurrent to a value higher than 2. However, if your Splunk deployment has the capacity for a large amount of search concurrency, you can try setting auto_summarize.max_concurrent to 3 or higher for selected accelerated reports.

See:

Summary data is divided into chunks with regular timespans

As Splunk software builds and maintains the summary, it breaks the data up into chunks to ensure statistical accuracy, according to a "timespan" determined automatically, based on the overall summary range. For example, when the summary range for a report is 1 month, a timespan of 1d (one day) might be selected.

A summary timespan represents the smallest time range for which the summary contains statistically accurate data. If you are running a report against a summary that has a one hour timespan, the time range you choose for the report should be evenly divisible by that timespan, if you want the report to use the summarized data. When you are dealing with a 1h timespan, a report that runs over the past 24 hours would work fine, but a report running over the past 90 minutes might not be able to use the summarized data.

Summaries can have multiple timespans

Report acceleration summaries might be assigned multiple timespans if necessary to make them as searchable as possible. For example, a summary with a summary range of 3 months can have timespans of 1mon and 1d. In addition, extra timespans might be assigned when the summary spans more than one index bucket and the buckets cover very different amounts of time. For example, if a summary spans two buckets, and the first bucket spans two months and the next bucket spans 40 minutes, the summary will have chunks with 1d and 1m timespans.

You can manually set summary timespans (but we don't recommend it)

You can set summary timespans manually at the report level in savedsearches.conf by changing the value of the auto_summarize.timespan parameter. If you do set your summary timespans manually, keep in mind that very small timespans can result in extremely slow summary creation times, especially if the summary range is long. On the other hand, large timespans can result in quick-building summaries that cannot be used by reports with short time ranges.

In almost all cases, for optimal performance and usability, it's best to let Splunk software determine summary timespans.

The way that Splunk software gathers data for accelerated reports can result in a lot of files over a very short amount of time

Because report acceleration summaries gather information for multiple timespans, many files can be created for the same summary over a short amount of time. If file and folder management is an issue for you, this is something to be aware of.

For every accelerated report and search head combination in your system, you get:

  • 2 files (data + info) for each 1-day span
  • 2 files (data + info) for each 1-hour span
  • 2 files (data + info) for each 10-minute span
  • SOMETIMES: 2 files (data + info) for each 1-minute span

So if you have an accelerated report with a 30-day range and a 10 minute granularity, the result is:

(30x1 + 30x24 + 30x144)x2 = 10,140 files

If you switch to a 1 minute granularity, the result is:

(30x1 + 30x24 + 30x144 + 30x1440)x2 = 96,540 files

If you use Deployment Monitor, which ships with 12 accelerated reports by default, an immediate backfill could generate between 122k and 1.2 million files on each indexer in $SPLUNK_HOME/var/lib/splunk/_internaldb/summary, for each search-head on which it is enabled.

Where report acceleration summaries are created and stored

The Splunk platform creates report acceleration summaries on indexers and associates each summary with the index bucket or buckets containing the summarized events.

The storage and replication behavior depends on whether the associated index uses SmartStore.

Non-SmartStore indexes

For a non-SmartStore index, report acceleration summaries reside on the indexer's local storage. By default, they are created in a summary directory alongside the index's hot and warm bucket directory. For example, if an index's homePath is:

homePath = /opt/splunk/var/lib/splunk/index1/db

its report acceleration summaries are stored at:

/opt/splunk/var/lib/splunk/index1/summary

You can configure the report acceleration summary location with summaryHomePath in indexes.conf.

Note: Data model acceleration summaries are stored in the same manner, but in directories labeled datamodel_summary instead of summary. You configure data model acceleration summary locations with tstatsHomePath and, by default, the _splunk_summaries volume.

In an indexer cluster, summaries are created on the peer containing the primary copy of the associated bucket. Indexer clusters do not replicate report acceleration summaries by default. If you use Splunk Enterprise, you can configure summary replication so that all searchable bucket copies have associated summaries. See How indexer clusters handle report and data model acceleration summaries in Manage indexers and indexer clusters.

For information about when report acceleration summaries in non-SmartStore indexes are removed, see Manage retention and removal of report acceleration summaries.

SmartStore indexes

For a SmartStore index, the Splunk platform uploads report acceleration summaries to separate locations in remote storage. Each summary is keyed to its associated source index bucket.

In an indexer cluster, summaries are created by the peer or peers holding the applicable primary copies of the associated source buckets. In a multisite cluster, primary selection is site-aware, meaning that a bucket can have a primary copy for more than one site. Because the summary in remote storage is available to all peers, summary replication is unnecessary and unsupported.

When a peer needs a summary, its cache manager fetches the required files from remote storage into the local cache. The cache manager can later evict the local cached files without deleting the authoritative summary in remote storage.

If you use Splunk Enterprise, do not override summaryHomePath for a SmartStore index. SmartStore indexes do not support custom local report acceleration summary paths. Cache Manager controls the remote placement and caching of report acceleration summaries. For more information, see How indexing works in SmartStore, in Manage Indexers and Indexer Clusters.

Manage retention and removal of report acceleration summaries

A report's Summary Range determines the finite time span covered by its report acceleration summary. Approximately every 10 minutes by default, a summary creation search adds new data to the summary. Approximately every 30 minutes by default, a separate maintenance search removes data older than the Summary Range from the summary. See Set report acceleration summary time ranges.

Storage-retention behavior depends on whether the source index uses SmartStore.

Configure size-based summary retention for non-SmartStore indexes

For non-SmartStore indexes, report acceleration summaries are stored on local indexer storage. If you have a Splunk Enterprise deployment, you can limit non-SmartStore index storage by defining a local volume with maxVolumeDataSizeMB and setting summaryHomePath for each applicable index.

When the volume exceeds maxVolumeDataSizeMB, the volume manager removes the oldest report acceleration summary data. It also creates a marker in the associated index bucket so that the removed summary data is not rebuilt.

If you use Splunk Enterprise, and want more information about configuring the size of non-SmartStore indexes with volumes, see Configure maximum index size in Manage Indexers and Indexer Clusters.

Remove summaries for SmartStore indexes

For a SmartStore index, the peer that is primary for an associated source index bucket creates the report acceleration summary and uploads it to remote storage. Other peers fetch the summary into their local caches when needed. See Configure SmartStore in Manage Indexers and Indexer Clusters.

SmartStore indexes do not support custom local report acceleration summary paths. Cache Manager controls the remote placement and caching of report acceleration summaries. See How indexing works in SmartStore, in Manage Indexers and Indexer Clusters.

SmartStore indexes ignore the maxVolumeDataSizeMB limit.
Note: If you have a Splunk Enterprise deployment, do not override summaryHomePath for SmartStore indexes. SmartStore indexes do not support custom report acceleration summary paths. Cache Manager manages the remote report acceleration summary and its locally cached representation.
Use the following methods to trim or remove report acceleration summaries for SmartStore indexes:

  • Use a finite Summary Range. Maintenance searches remove summary data that falls outside the configured range. Reducing the Summary Range therefore reduces the amount of historical summary data retained. An All Time range does not provide this form of aging.

  • Freeze the associated source SmartStore index buckets. If your environment uses the Victoria Experience, SmartStore freezes index buckets when maxGlobalRawDataSizeMB or frozenTimePeriodInSecs are reached. If your environment uses the Classic Experience, SmartStore freezes index buckets when maxGlobalDataSizeMB, maxGlobalRawDataSizeMB, or frozenTimePeriodInSecs is reached. In either case, the first applicable limit reached can cause the qualifying source buckets to freeze and be removed from the platform.

    When a source bucket is removed, the platform also removes its associated report acceleration summary data.

    Report acceleration and data model acceleration summary files are excluded from the calculations for the SmartStore size limits. These settings can therefore remove summary data indirectly by freezing source buckets, but they do not impose a size limit on the summaries themselves. See Configure data retention for SmartStore indexes in Manage Indexers and Indexer Clusters.

  • Delete the complete summary. Go to Settings > Report Acceleration Summaries, select the summary, and select Delete to remove the summary from the system and prevent it from being regenerated. To recreate the summary, re-enable acceleration for an associated report from Settings > Searches, Reports, and Alerts. Alternatively, you can simply turn off acceleration for the report that is associated with the summary. Eventually the summary will be removed.

Note: Cache eviction is not summary removal. Cache Manager can evict a locally cached copy of a report acceleration summary to free local disk space. The authoritative copy of the summary remains in remote storage and can be fetched again when needed. See

How indexing works in SmartStore, in Manage Indexers and Indexer Clusters.

Multiple reports for a single summary

A single report summary can be associated with multiple searches when the searches meet the following two conditions.

  • The searches are identical up to and including the first reporting command.
  • The searches are associated with the same app.

Searches that meet the first condition, but which belong to different apps, cannot share the same summary.

For example, these two reports use the same report acceleration summary.

CODE 
sourcetype=access_* status=2* | stats count by price
CODE 
sourcetype=access_* status=2* | stats count by price | eval discount = price/2

These two reports use different report acceleration summaries.

CODE 
sourcetype=access_* status=2* | stats count by price
CODE 
sourcetype=access_* status=2* | timechart by price

Two reports that are identical except for syntax differences that do not cause one to output different results than the other can also use the same summary.

These two searches use the same report acceleration summary.

CODE 
sourcetype = access_* status=2* | fields - clientip, bytes | stats count by price
CODE 
sourcetype = access_* status=2* | fields - bytes, clientip | stats count by price

You can also run non-saved searches against the summary, as long as the basic search matches the populating saved search up to the first reporting command and the search time range fits within the summary span.

You can see which searches are associated with your summaries by navigating to Settings > Report Acceleration Summaries. See Use the Report Acceleration Summaries Page.

Conditions under which the Splunk platform cannot build or update a summary

Splunk software cannot build a summary for a report when either of the following conditions exist.

  • The number of events in the hot bucket covered by the chosen Summary Range is less than 100k. When this condition exists you see a Summary Status warning that says Not enough data to summarize.
  • The completed summary exceeds both the configured absolute summary size limit (max_summary_size) and the configured maximum ratio of summary size to source bucket size (max_summary_ratio). The default ratio is 10%. When it makes this estimation, it suspends the summary for 24 hours. You will see a Summary Status of Suspended.

You can see the Summary Status for a summary in Settings > Report Acceleration Summaries.

If you define a summary and the Splunk software does not create it because these conditions exist, the software checks periodically to see if conditions improve. When these conditions are resolved, Splunk software begins creating or updating the summary.

How can you tell if a report is using its summary?

The obvious clue that a report is using its summary is if you run it and find that its report performance has improved (it completes faster than it did before).

But if that's not enough, or if you aren't sure if there's a performance improvement, you can View search job properties in the Search Manual for a debug message that indicates whether the report is using a specific report acceleration summary. Here's an example:

CODE 
DEBUG: [thething] Using summaries for search, summary_id=246B0E5B-A8A2-484E-840C-78CB43595A84_search_admin_b7a7b033b6a72b45, maxtimespan=

In this example, that last string of numbers, b7a7b033b6a72b45, corresponds to the Summary ID displayed on the Report Acceleration Summaries page.

Use the Report Acceleration Summaries page

You can review the your report acceleration summaries and even manage various aspects of them with the Report Acceleration Summaries page in Settings. Go to Settings > Report Acceleration Summaries.

Settings report acceleration summaries.png

The main Report Acceleration Summaries page enables you to see basic information about the summaries that you have permission to view.

The Summary ID and Normalized Summary ID columns display the unique hashes that assigned to those summaries. The IDs are derived from the remote search string for the report. They are used as part of the directory name that is created for the summary files. Click a summary ID or normalized summary ID to view summary details and perform summary management actions. For more information about this detail view, see the subtopic "Review summary details," below.

The Reports Using Summary column lists the saved reports that are associated with each of your summaries. It indicates that each report associated with a particular summary will get report acceleration benefits from that summary. Click on a report title to drill down to the detail page for that report.

Check Summarization Load to get an idea of the effort that Splunk software has to put into updating the summary. It's calculated by dividing the number of seconds it takes to run the populating report by the interval of the populating report. So if the report runs every 10 minutes (600 seconds) and takes 30 seconds to run, the summarization load is 0.05. If the summarization load is high and the Access Count for the summary shows that the summary is rarely used or hasn't been used in a long time, you might consider deleting the summary to reduce the strain on your system.

The Summary Status column reports on the general state of the summary and tells you when it was last updated with new data. Possible status values are Summarization not started, Pending, Building summary, Complete, Suspended, and Not enough data to summarize. The Pending and Building summary statuses can display the percentage of the summary that is complete at the moment. If you want to update a summary to the present moment, click its summary ID to go to its detail page and click Update to run a new summary-populating report.

If the Summary Status is Pending it means that the summary may be slightly outdated and the search head is about to schedule a new update job for it.

If the Summary Status is Suspended it means that the report is creating a summary that is too large. See Conditions under which the Splunk platform cannot build or update a summary.

You cannot override summary suspension, but you can adjust the length of time that summaries are suspended by changing the value of the auto_summarize.suspend_period attribute in savedsearches.conf,

If the Summary Status reads Not enough data to summarize, it means that Splunk software is not currently generating or updating a summary because the reports associated with it are returning less than 100k events from the hot buckets covered by the summary range. See Conditions under which the Splunk platform cannot build or update a summary.

Review summary details

You use the summary details page to view detail information about a specific summary and to initiate actions for that summary. You get to this page by selecting a Summary ID on the Report Acceleration Summaries page in Settings.

5.0-Report Acceleration Summaries-Summary Detail.jpg

Summary Status

Under Summary Status you'll see basic status information for the summary. It mirrors the Summary Status listed on the Report Acceleration Summaries page (see above) but also provides information about the verification status of the summary.

If you want to update a summary to the present moment, select the Update button under Actions to kick off a new summary-populating report.

No verification status will appear here if you've never initiated verification for the summary. After you initiate verification this status shows the verification percentage complete. Otherwise this status shows the results of the last attempt at summary verification; the possible values are Verified and Failed to verify, with an indication of how far back in the past this attempt took place.

For more information about summary verification, see Verify a summary.

Reports using the summary

The Reports Using This Summary section lists the reports that are associated with the summary, along with their owner and home app. Select a report title to drill down to the detail page for that report. Similar reports (reports with search strings that all transform the same root search with different transforming commands, for example) can use the same summary.

Summary details

The Details section provides a set of metrics about the summary.

Summarization Load and Access Count are mirrored from the main Report Acceleration Summaries page. See Use the Report Acceleration Summaries page for more information.

Size on Disk shows you how much space the summary takes up in terms of storage. You can use this metric along with the Summarization Load and Access Count to determine which summaries should be deleted.

Note: If the Size value stays at 0.00MB that means that Splunk software is not currently generating this summary because the reports associated with the summary either don't have enough events or have too many events. See Conditions under which the Splunk platform cannot build or update a summary.

Splunk software periodically checks this report and automatically begins or resumes building a summary when the report meets the criteria for summary creation.

Summary range is the range of time spanned by the summary, always relative to the present moment. You set this up when you define the report that populates the summary. SeeSet report acceleration summary time ranges.

Timespans displays the size of the data chunks that make up the summary. A summary timespan represents the smallest time range for which the summary contains statistically accurate data. So if you are running a report against a summary that has a one hour timespan, the time range you choose for the report should be evenly divisible by that timespan if you want to get good results. So if you are dealing with a 1h timespan, a report over the past 24 hours would work fine, but a report over the past 90 minutes might be problematic. See How the Splunk platform builds report acceleration summaries.

Buckets shows you how many index buckets the summary spans, and Chunks tells you how many data chunks comprise the summary. Both of these metrics are informational for the most part, though they may aid with troubleshooting issues you may be encountering with your summary.

Verify a summary

At some point you may find that an accelerated report seems to be returning results that don't fit with the results the report returned when it was first created. This can happen when certain aspects of the report change without your knowledge, such as a change in the definition of a tag, event type, or field extraction rule used by the report.

If you suspect that this has happened with one of your accelerated reports, go to the detail page for the summary with which the report is associated. You can run a verification process that examines a subset of the summary and verifies that all of the examined data is consistent. If it finds that the data is inconsistent, it notifies you that the verification has failed.

For example, say you have a report that uses an event type, netsecurity, which is associated with a specific kind of network security event. You enable acceleration for this report, and Splunk software builds a summary for it. At some later point, the definition of the event type netsecurity is changed, so it finds an entirely different set of events, which means your summary is now being populated by a different set of data than it was before. You notice that the results being returned by the accelerated report seem to be different, so you run the verification process on it from the Report acceleration summaries page in Settings. The summary fails verification, so you begin investigating the root report to find out what happened.

Ideally the verification process should only have to look at a subset of the summary data in order to save time; a full verification of the entire summary will take as long to complete as the building of the summary itself. But in some cases a more thorough verification is required.

5.0-Report Acceleration Summaries-Verify Summary.jpg

Selecting Verify opens a Verify Summary dialog box. Verify Summary provides two verification options:

  • A Fast verification, which is set to quickly verify a small subset of the summary data at the cost of thoroughness.
  • A Thorough verification, which is set to thoroughly review the summary data at the cost of speed.

In both cases, the estimated verification time is provided.

After you select Start to kick off the verification process, you can follow its progress on the detail page for your summary under Summary Status. When the verification process completes, this is where you'll be notified whether it succeeded or failed. Either way you can select the verification status to see details about what happened.

When verification fails, the Verification Failed dialog can tell you what went wrong:

5.0-Report Acceleration Summaries-Verification Failed.jpg

During the verification process, hot buckets and buckets that are in the process of building are skipped.

When a summary fails verification you can review the root search string (or strings) to see if it can be fixed to provide correct results. Once the report is working, select Rebuild to rebuild the summary so it is entirely consistent. Or, if you're fine with the report as-is, just rebuild the report. And if you'd rather start over from scratch, delete the summary and start over with an entirely new report.

Update, rebuild, and delete summaries

Select Update if the Summary Status shows that the summary has not been updated in some time and you would like to make it current. Update kicks off a standard summary update report to pull in events so that it is not missing data from the last few hours (for example).

Note: When a summary's Summary Status is Suspended, you cannot use Update to bring it current.

Select Rebuild to delete and rebuild the report acceleration summary from its source index data. You may want to do this in situations where you suspect there has been data loss due to a system crash or similar mishap, or if it failed verification and you've either fixed the underlying report(s) or have decided that the summary is ok with the data it is currently bringing in.

Select Delete to remove the summary from the system (and not regenerate summaries in the future). You may want to do this if the summary is used infrequently and is taking up space that could better be used for something else. You can use the Searches and Reports page in Settings to reenable report acceleration for the report or reports associated with the summary.