Resetting the Filebeat registry discards saved read positions so inputs start tracking files from scratch, which helps recover from corrupted state and enables controlled replays of historical logs. The same reset can also cause duplicate events to be shipped to downstream outputs.
Filebeat persists file state in a registry stored under its path.data directory, recording a file identity and the last acknowledged offset per harvester. On common Linux package installs, path.data defaults to /var/lib/filebeat and the registry lives at /var/lib/filebeat/registry.
Registry changes must be done while the filebeat service is stopped to avoid concurrent writes and partial state. Input options such as ignore_older or tail_files can change what gets replayed after a reset, so results depend on the active input configuration and file timestamps.
Steps to reset the Filebeat registry:
- Stop the Filebeat service.
$ sudo systemctl stop filebeat
- Move the registry path to a backup name.
$ sudo mv /var/lib/filebeat/registry /var/lib/filebeat/registry.bak
Reverse the move for rollback while the service is stopped, and replace /var/lib/filebeat with the path.data directory when customized.
Resetting the registry can replay previously shipped logs.
- Start the Filebeat service.
$ sudo systemctl start filebeat
- Confirm the Filebeat service is active.
$ sudo systemctl is-active filebeat active
- List the registry path to confirm it exists after startup.
$ sudo ls -ld /var/lib/filebeat/registry drwxr-x--- 3 root root 4096 Jan 6 22:56 /var/lib/filebeat/registry
An empty registry directory can be normal until at least one file is harvested.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
