A monitored log file is changing on the forwarder. However, Splunk searches are not finding any new data that has been added. What are possible causes? (select all that apply)

Question

Options

• AAn admin ran splunk clean eventdata -index <indexname> on the indexer.
• BAn admin has removed the Splunk fishbucket on the forwarder.
• CThe last 256 bytes of the monitored file are not changing.
• DThe first 256 bytes of the monitored file are not changing.

Explanation

A and D are the correct answers.

A is correct because splunk clean eventdata -index <indexname> permanently purges all indexed events from that index on the indexer. Even if the forwarder successfully transmitted new data and it was properly indexed, this command wipes it out - making it invisible to any search.

D is correct because Splunk tracks monitored files by computing a CRC checksum of the first 256 bytes, which it stores in the fishbucket alongside the last read (seek) position. If a log file is rotated and the new file starts with the same first 256 bytes as the old one (fingerprint unchanged), Splunk matches it to the old fishbucket entry and seeks to the previously recorded offset - which may be far beyond the end of the smaller, newer file - causing all new content to be silently skipped.

B is incorrect because deleting the fishbucket causes Splunk to lose its seek positions and re-read files from the beginning, leading to duplicate data in the index, not missing data.

C is incorrect because Splunk has no mechanism that uses the last 256 bytes of a file for tracking or change detection - that role belongs exclusively to the first 256 bytes.

Memory tip: Think "First 256 = fingerprint." Splunk's fishbucket identifies files by a CRC of the first 256 bytes. D is the classic trap answer - "not changing" sounds safe, but after log rotation it means the new file shares the old file's fingerprint, causing Splunk to seek past all new content.

No community discussion yet for this question.