About real-time searches and reports
- You can design alerts based on real-time searches that run continuously in the background. Such real-time alerts can provide timelier notifications than alerts that are based on scheduled reports. For more information, see the Alerting Manual.
- You can also display real-time search results and reports in dashboards. For more information, see the dashboard overview in Dashboards and Visualizations.
The number of concurrent real-time searches can greatly affect indexing performance. To lessen the impact on the indexer, you can enable indexed real-time searches, which is described later in this topic. See Expected performance and known limitations of real-time searches and reports.
By default, only Splunk Enterprise users with the Admin role can run and save real-time searches. For more information on managing roles and assigning roles to users, see Create and manage roles with Splunk Web in Securing Splunk Enterprise.
For Splunk Cloud Platform, real-time search is disabled by default. For more information, see the differences section in the Splunk Cloud Platform Service Details topic in the Splunk Cloud Platform Service Description.
Real-time search mechanics
Real-time searches scan events as the events arrive for indexing. When you kick off a real-time search, Splunk software scans the incoming events. The scan looks for events that contain index-time fields that indicate the event could be a match for your search.
As the real-time search runs, the software periodically evaluates the scanned events against your search criteria to find actual matches within the sliding time range window that you have defined for the search. The number of matching events can fluctuate up or down over time as the search discovers matching events at a faster or slower rate. If you are running the search in Splunk Web, the search timeline also displays the matching events that the search has returned within the chosen time range.
Here is an example of a real-time search with a one minute time range window. At the point that the following screen capture was taken, the search had scanned a total of 436 events since it was launched. The matching event count of 333 represents the number of events matching the search criteria that were identified in the past minute. This number fluctuated between 312 and 357 for the following minute. If the number spiked or dropped dramatically, that could indicate that something interesting was happening that requires a closer look.
As you can see, the newest events are on the right-hand side of the timeline. As time passes, the events move left until the events move off the left-hand side, disappearing from the time range window entirely.
A real-time search should continue running until you or another user stops the search or deletes the search job. The real-time search should not "time out" for any other reason. If your events are stopping it could be a performance-related issue (see "Expected performance and known limitations").
Real-time searches can take advantage of all search functionality, including advanced functionality like lookups, transactions, and so on. There are also search commands that are to be used specifically in conjunction with real-time searches, such as
Indexed real-time search
Enabling your real-time searches to run after the events are indexed can greatly improve indexing performance. This is especially true if there are a large number of concurrent real-time searches. To lessen the impact on the indexer, you can enable indexed real-time search. This runs searches like historical searches, but also continually updates the search with new events as the events appear on disk.
Use indexed real-time search when up-to-the-second accuracy is not needed.
- Splunk Cloud Platform
- For Splunk Cloud Platform, real-time search is disabled by default. For more information, see the differences section in Splunk Cloud Platform Service Details in the Splunk Cloud Platform Service Description.
- Splunk Enterprise
- Only users with file system access, such as system administrators, can enable indexed real-time search.
- Review the steps in How to edit a configuration file in the Admin Manual.
Never change or copy the configuration files in the default directory. The files in the default directory must remain intact and in their original location. Make the changes in the local directory.
- Open the local
limits.conffile for the Search app. For example,
- Open the local
- Under the
- Under the
Indexed real-time search and newly added search peers
If your deployment includes newly added search peers and you are using indexed real-time search, all events from the new search peers show up by default in historical searches. However, existing indexed real-time searches will not pick up events from the search peers until you kick off another indexed real-time search. As a result, you should restart your indexed real-time searches every time you add new search peers.
If you want to automatically pick up all events in your real-time searches after you've added new search peers to your deployment, use real-time search instead of indexed real-time search. You can do this by changing the
indexed_realtime_use_by_default setting in the local limits.conf file from
true back to the default, which is
false. See How to edit a configuration file in the Splunk Enterprise Admin Manual.
Using real-time search by setting
false makes events available to searches with lower latency, but reduces indexing throughput.
About the sync delay lag time
The results returned by an indexed real-time search will always lag behind a real-time search. Built into indexed real-time searches is a sync (synchronizing) delay. The sync delay is a precaution so that none of the data is missed.
Indexed data does not necessarily appear on disk in the order that the data is indexed because:
- Multiple threads are used for indexing simultaneously
- The sync delay ordering that is on your operating system
An indexed real-time must remember the latest indexed event that is returned for the current iteration of the time range window. That event is used as the start point for the next iteration of the time range window. If a sync delay is not imposed, some of the events before the latest event might not be searchable yet. These events are not returned during that iteration of the time range window and will never be returned. The likelihood of an unreturned event increases as the indexing and system load increases.
You can control the number of seconds of sync delay lag time with the
indexed_realtime_disk_sync_delay = <int> setting. By default, this delay is set to 60 seconds.
The default of 60 seconds is fairly conservative. For most systems a 30 second delay will probably work successfully. If, for your system and usage, it is acceptable for indexed real-time searches to miss some events, you can set a very low or 0 sync delay. However, you will not be able to tell if you are missing events, except for searches that should match all events.
Other indexed real time settings
There are other settings that you can use to configure indexed real-time search behavior, including:
These settings are described in the limits.conf.spec file.
- Real-time searches and reports in Splunk Web
- Real-time searches and reports in the CLI
- Expected performance and known limitations of real-time searches and reports
- How to restrict usage of real-time searches
- Splunk: Limiting Real-Time Searches and Maximizing Performance Gainz by Hurricane Labs
Open a non-transforming search in Pivot to create tables and charts
Real-time searches and reports in Splunk Web
This documentation applies to the following versions of Splunk® Enterprise: 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.1.8, 7.1.9, 7.1.10, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.2.7, 7.2.8, 7.2.9, 7.2.10, 7.3.0, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.3.5, 7.3.6, 7.3.7, 7.3.8, 7.3.9, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6, 8.0.7, 8.0.8, 8.0.9, 8.0.10, 8.1.0, 8.1.1, 8.1.2, 8.1.3, 8.1.4, 8.1.5, 8.1.6, 8.1.7, 8.1.8, 8.1.9, 8.1.10, 8.1.11, 8.1.12, 8.1.13, 8.1.14, 8.2.0, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.2.7, 8.2.8, 8.2.9, 8.2.10, 8.2.11, 8.2.12, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 9.0.4, 9.0.5, 9.0.6, 9.1.0, 9.1.1