I understand that Splunk first uncompresses the monitored zip files and only then indexes them.
Where does the uncompressing take place? Universal forwarder or Indexer? In other words, at what box should I allocate enough disk space and cpu resources for the uncompressing?
This is done on the forwarder. Check out this Q&A:
https://answers.splunk.com/answers/91386/the-limitation-of-monitor-files-in-one-directory.html
Most people who put compressed files directly into inputs.conf
will eventually see logs like this In splunkd.log
:
DateTime INFO TailingProcessor - failed to insert into AQ, retrying...
This will be accompanied by logs like this in metrics.log
:
DateTime INFO Metrics - group=queue, name=aq, blocked=true, max_size=10000,filled_count=7, empty_count=0, current_size=10000, largest_size=10000, smallest_size=9996*
Here AQ
is the queue feeding the ArchiveProcessor
, which is the thread that handles compressed and archived inputs (.gz, .bz2, .Z, .tar, .zip, .tgz). The ArchiveProcessor
is single-threaded and handles archives one at a time. This means that the file processing code has found more than 10000 archive files that we are processing in turn. The only hope in this case is that the workload will have light periods to allow the ArchiveProcessor
catch up on the backlog, but this may never happen.
Original point of ingestion handles the decompress and reading of contents.