Use persistent queues to help prevent data loss
Persistent queuing lets you store data in an input queue to disk. In a Splunk Cloud Platform deployment, persistent queues can help prevent data loss if a forwarder that you configured to send data to your Splunk Cloud Platform instance backs up. In a Splunk Enterprise deployment, persistent queues work for either forwarders or indexers. You can't configure persistent queues directly on a Splunk Cloud Platform instance.
By default, forwarders and indexers have an in-memory input queue of 500 KB. If the input stream runs at a faster rate than the forwarder or indexer can process, to a point where the input queue on the forwarder maxes out, undesired consequences occur. In the case where you send network data over the UDP protocol, that data drops off of the queue and gets lost. For other types of data inputs, the application that generates the data can get backed up.
By implementing persistent queues, you can help prevent this data drop or loss from happening. With persistent queuing, after the in-memory queue is full, the forwarder or indexer writes the input stream to files on disk. It then processes data from the in-memory and disk queues until it reaches the point when it can again start processing directly from the data stream.
While persistent queues help prevent data loss if processing gets backed up, you can still lose data if the forwarder or indexer crashes. For example, the forwarder holds some input data in the in-memory queue as well as in the persistent queue files. The in-memory data can get lost if the forwarder crashes. Similarly, data that is in the parsing or indexing pipeline but that has not yet been written to disk can get lost in a crash.
When can you use persistent queues?
Persistent queuing is available for certain types of inputs, but not all. Generally speaking, persistent queuing is available for inputs of an ephemeral nature, such as network inputs, but isn't available for inputs that have their own form of persistence, such as monitoring files.
Persistent queues are available for these input types:
- Network inputs that use the TCP protocol
- Network inputs that use the UDP protocol
- First-In, First-Out (FIFO) inputs
- Scripted inputs
- Windows Event Log inputs
- HTTP Event Collector tokens
Persistent queues aren't available for these input types:
- Monitor inputs
- Batch inputs
- File system change monitor
Configure a persistent queue
Use the inputs.conf configuration file to configure a persistent queue. You can configure the persistent queue on the universal forwarder that you configured to send data to Splunk Cloud Platform. You can also configure persistent queues on Splunk Enterprise indexers. Use the same procedure directly on the indexer or forwarder that sends data to the indexer.
Inputs don't share queues. You configure a persistent queue in the stanza for the specific input.
- On the machine that forwards data to Splunk Cloud Platform, use a text editor to open the $SPLUNK_HOME/etc/system/local/inputs.conf file for editing.
- Locate or add the input stanza where you want to enable persistent queuing.
- Specify the following setting within that input stanza:
persistentQueueSize = <integer>[KB|MB|GB|TB]
- Save the file and close it
- Restart the forwarder.
For more information about the inputs.conf file, see inputs.conf in the Splunk Enterprise Admin Manual.
Example of configuring a persistent queue
Here's an example of specifying a 10MB persistent queue for a TCP network input:
[tcp://9994] persistentQueueSize=10MB
Here is another example for specifying a 15MB persistent queue for a Windows Event Log input:
[WinEventLog] persistentQueueSize=15MB
The Windows Event Log monitor accepts a persistent queue configuration for the default Windows Event Log stanza only. You cannot configure a persistent queue for a specific Event Log channel. You can configure a persistent queue for a specific Windows host monitoring input.
Persistent queue location
The persistent queue has a hardcoded location, which varies according to the type of input.
For network inputs, the persistent queue is located at $SPLUNK_HOME/var/run/splunk/[tcpin|udpin]/pq__<port>.
Put two underscores in the file name: pq__
, not pq_
.
See the following examples:
- The persistent queue for TCP port 2012 is $SPLUNK_HOME/var/run/splunk/tcpin/pq__2012.
- The persistent queue for UDP port 2012 is $SPLUNK_HOME/var/run/splunk/udpin/pq__2012.
For FIFO inputs, the persistent queue resides in $SPLUNK_HOME/var/run/splunk/fifoin/<encoded path>.
For scripted inputs, the persistent queue resides in $SPLUNK_HOME/var/run/splunk/exec/<encoded path>. The FIFO scripted input stanza in the inputs.conf file derives the <encoded path>
.
Use a test index to test your inputs | Use ingest actions to improve the data input process |
This documentation applies to the following versions of Splunk® Enterprise: 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.0.11, 7.0.13, 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.11, 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.0.7, 9.0.8, 9.0.9, 9.0.10, 9.1.0, 9.1.1, 9.1.2, 9.1.3, 9.1.4, 9.1.5, 9.1.6, 9.1.7, 9.2.0, 9.2.1, 9.2.2, 9.2.3, 9.2.4, 9.3.0, 9.3.1, 9.3.2, 8.1.10, 8.1.12, 8.1.13, 8.1.14
Feedback submitted, thanks!