Modern Replacements for tail
lnav and stern compared as tail replacements: local log files, journald and compressed logs with lnav, Kubernetes pod logs with stern.
Updated
short verdict
Pick lnav if you follow log files on a host and want format detection, merged sources, filtering and SQL in one TUI. Pick stern if the logs live in Kubernetes pods and you want one stream across many pods and containers. They cover different sources, so neither replaces tail everywhere.
tail -f follows one file and prints raw lines. The tools here keep the follow behavior but add parsing, filtering and multi-source merging. lnav works on local log files and journald output. stern works on Kubernetes pods and containers.
this page is for
- Developers and admins following log files on a host
- Engineers tailing logs across many Kubernetes pods
- Anyone who pipes tail into grep and wants built-in filtering
A terminal log viewer that follows files in real time, merges several sources chronologically and filters with regex or SQLite expressions.
best for
- Following local log files and directories
- Correlating several log sources in time order
- Reading journalctl output interactively
strengths
- Detects log formats automatically and merges multiple sources into one chronological view
- Reads compressed log files without manual decompression
- Follows file renames and watches directories for new files
- Jumps between errors with e/E, searches with /, runs SQLite queries with ;
weaknesses
- Interactive TUI, so it does not behave like a plain line-streaming tail in a pipe
- No Kubernetes pod discovery; journald data must be piped in from journalctl
- Installation is documented via Homebrew and FreeBSD pkg only
A Kubernetes log tailer that follows every pod and container matching a regex and adjusts as pods come and go.
best for
- Following logs across all pods of a deployment
- Kubernetes users replacing kubectl logs -f on one pod
- Piping structured pod logs into other tooling
strengths
- Matches pod names by regex and picks up created or deleted pods dynamically
- Accepts resource/name queries such as deployments, plus label and field selectors
- Color-codes output per pod and container, with JSON output and custom Go templates
- Installs through Homebrew, go install or kubectl krew
weaknesses
- Only reads Kubernetes logs; it cannot follow a local file
- Needs access to a cluster through standard Kubernetes authentication
What changes compared to tail
Both tools keep the follow behavior but change what you see and what you select.
- lnav opens an interactive TUI instead of writing raw lines to stdout
- lnav merges multiple log sources into one chronological view
- lnav reads compressed files directly and follows renamed files
- stern selects pods by regex or resource/name instead of a file path
- stern color-codes each pod and container, and offers JSON or Go template output
When not to use these
- You need a plain line-by-line stream of one local file in a script; neither entry documents a tail-compatible mode
- Your logs are not in local files, journald output or Kubernetes pods
FAQ
- Can lnav or stern be used as drop-in replacements for tail in scripts?
- This is not documented by either project. lnav is an interactive TUI, and stern reads Kubernetes pods rather than files, so check flags and output before replacing tail in a script.
- Which tool should I use to follow logs from several Kubernetes pods?
- Use stern. It matches pod names with regular expressions and follows all matching pods and containers, adjusting as pods are created or deleted.
- Can lnav read journald logs?
- Yes, through piped input from journalctl. It supports standard and JSON output, and with JSON it recognizes fields such as PRIORITY and _SYSTEMD_UNIT.