Loghound can only ever see as far back as your own log retention. It reads the files that exist. There is no historical backfill beyond them, and there is no way to reconstruct a log line that has been deleted.
It is often not what you assume:
cat /etc/logrotate.d/apache2 # or /etc/logrotate.d/httpd, nginx sudo crontab -l | grep -i log ls -la /etc/cron.d/ | grep -i log
Rotation configurations commonly keep fourteen or fifty-two files. But a cron entry can also simply delete them, and that is not visible in the logrotate configuration at all. On the first box Loghound was deployed to, the crontab held:
@daily /usr/bin/find /var/log/apache2/ -type f -mtime +10 -exec /usr/bin/rm -f {} +Ten days. Everything older simply did not exist.
So if you care about long-range history, keep it in Loghound
Set the retention window to what you actually want and let the retention job enforce it. A Solr document is roughly an order of magnitude smaller than the raw log line it came from once the raw copy is off, and it is indexed, which the raw log is not.
A newly watched log file is read from its end, so a first install does not spend a day replaying a four-gigabyte backlog. To ingest history you already have, run the tailer once from the start, before your rotation window discards it:
sudo -u loghound php /opt/loghound/bin/loghound-tail --once --from-start
And if you want to see what that would parse without writing anything:
sudo -u loghound php /opt/loghound/bin/loghound-tail --once --from-start --dry-run --verbose
Figure 1 — the inode-recycling check. Without it the tailer looks perfectly healthy while silently skipping the beginning of every rotated file, which is the worst failure this class of software can have. It costs one byte per startup.
Loghound handles rotation, deletion and truncation. Three cases are worth knowing about because they all look healthy from outside:
- A file deleted while it is open. On Linux the descriptor stays valid and reads forever from a file with no name, so a naive tailer looks perfectly healthy while ingesting nothing. It is detected by re-checking the path and the link count.
- Inode recycling on ext4, which is the nastiest of the lot. A rotation that renames the log, compresses it, unlinks the original and creates a fresh one routinely hands the new file the inode number the old one just freed. The stored cursor then matches a file that no longer exists, and resuming at that offset silently skips the beginning of the new file. So the cursor is validated rather than trusted: a valid offset always sits immediately after a newline, because only complete lines are ever committed, and reading the single byte before it tells a genuine resume from a recycled inode. When the check fails the source restarts at zero and the event is counted rather than hidden.
- Compression that arrives too early. If a rotated file is compressed immediately and the daemon happened to be stopped, the original inode is gone and the last few lines are unrecoverable.
delaycompress
It leaves a plain .1 for one cycle, which the tailer can find by inode and drain to the end before switching. The daemon reports this honestly either way — loghound-tail --status --human shows a missed-rotation count when it happens.
loghound-tail --status --human
Everything else about running the daemon is on running it, and the symptoms with their diagnoses are on troubleshooting.