Nerdlog

Nerdlog is a fast, remote-first, multi-host TUI log viewer with timeline histogram and no central server. Loosely inspired by Graylog/Kibana, but without the bloat. Pretty much no setup needed, either.

It's laser-focused on being efficient while querying logs from multiple remote machines simultaneously, filtering them by time range and patterns, while also drawing an interactive timeline histogram for quick visual insight.

Primary use case: reading system logs (from the files /var/log/messages or /var/log/syslog, or straight from journalctl) from one or more remote hosts. Very efficient even on large log files (like 1GB or more).

It does support some other log formats and can use any log files, but that was the primary use case which was driving the implementation: we were having our web service backend running as systemd services on a bunch of Linux instances, printing a lot of logs, and wanted to be able to read these logs efficiently and having the timeline histogram, much like tools like Graylog have.

Design highlights

• No centralized server required; nerdlog establishes an ssh connection to every node that the user wants to collect logs from, and keeps them idle in the background (although a separate server to store the log files might still help in some cases; see the Limitations section in the docs);
• Logs are not downloaded to the local machine in full: all the log analysis is done on the remote nodes, and on each query, only the following data is downloaded from each node: up to 250 messages from every logstream (configurable), and data for the timeline histogram. It's obviously possible to paginate over the logs, to get the next bunch of messages, etc. Nerdlog then merges the responses from all nodes together, and presents to the user in a unified form;
• Most of the data is gzipped in transit, thus saving the bandwidth as well.
• Supports arbitrary command to establish shell session with the remote hosts, so can be used with Teleport or other similar tools.

Demo

Here’s a quick demo showing how Nerdlog works across four remote nodes:

Project history

It might be useful to know the history to understand the project motivation and overall direction, you can read it in the article: Implementing a Radically Simple Alternative to Graylog.

Project state

Originally hacked together in 2022 to replace painfully slow Splunk setups. Revisited in 2025 to clean it up to a certain extent, and open source it.

Tested on various Linux distros, FreeBSD, MacOS and Windows (only the client app can run on Windows though, we can't get logs from Windows hosts).

The code still has some traces of the hackathon style here and there, and could be more polished, but overall it matured significantly. There are decent tests as well.

I've been using it at work and for my personal projects for a few years now, and I consider it ready to be used in the wild on production systems.

Installation

The easiest is to just use a prebuilt binary for your platform, see the releases page.

To build it from source, you need Go.

Also on Linux, the X11 dev package is required because of access to clipboard (here's the library that nerdlog uses), e.g. on Ubuntu it can be installed with this:

sudo apt install libx11-dev

On MacOS and Windows, no extra dependencies are required.

Using go install

Latest release (might miss newest features which are not yet officially released):

go install github.com/dimonomid/nerdlog/cmd/nerdlog@latest

Latest master:

go install github.com/dimonomid/nerdlog/cmd/nerdlog@master

Unless you have custom GOPATH or GOBIN env vars set, it will install the nerdlog binary to $HOME/go/bin.

Using make

To install nerdlog binary to your /usr/local/bin:

$ make && sudo make install

Or to build and run without installing:

$ make && bin/nerdlog

Usage

When you open the app (nerdlog binary), it'll show a query edit form with a few fields:

Time range is self-explanatory.

Next one is "Logstreams": shortly, as the name suggests, a logstream is a contiguous stream of log messages, on a particular server accessible via ssh (or on the local server). As of now, two kinds of logstreams are supported:

• One or more consecutive log files like /var/log/syslog and /var/log/syslog.1 (actually as of now there can be at most 2 files in a logstream, but this limitation will hopefully be removed).
• Logs returned from journalctl

By default, nerdlog checks available logstreams in the following order:

• If available, use the /var/log/messages file (and the older /var/log/messages.1)
• If available, use the /var/log/syslog file (and the older /var/log/syslog.1)
• As the last resort, use journalctl if available.

Why preferring the logfiles instead of journalctl: shortly, because it's less reliable and much slower. See FAQ for details. However, journalctl is more universally available these days (alas), and it often also has longer history, so nerdlog has full support for it. So far there's no option to prefer journalctl instead of log files by default, lmk if you need it; shouldn't be hard to implement.

So if you have a server like myserver.com accessible via ssh on port 22, then the logstream to read its /var/log/messages file (or /var/log/syslog file, or from journalctl if none of these files are present) could be:

[email protected]

If you need a different port and/or different log files, then a more explicit form is:

[email protected]:1234:/some/other/logfile

To select journalctl explicitly, specify journalctl as the log file:

[email protected]:1234:journalctl

Multiple logstreams can be provided separated by commas, like this:

[email protected], [email protected]:1234:/some/other/logfile

Nerdlog also reads ssh config (~/.ssh/config) and can take the port, username and hostname from there. It supports globs too, so e.g. in your ssh config you have two hosts like myhost-01 and myhost-02, then instead of specifying your logstreams as myhost-01,myhost-02 it can be simply myhost-*.

Obviously though, we can't specify the log files in the ssh config, so if you need to configure a logstream for non-default log file on some host(s), you can use the nerdlog's own logstreams config file ~/.config/nerdlog/logstreams.yaml, which can look like this:

log_streams:
  myhost-01:
    hostname: actualhost1.com
    port: 1234
    user: myuser
    log_files:
      - /some/custom/logfile
  myhost-02:
    hostname: actualhost2.com
    port: 7890
    user: myuser
    log_files:
      - /some/custom/logfile

The last thing on that query form is the "Select field expression", it looks like this:

time STICKY, lstream, message, *

It only affects the presentation of the logs in the UI. The syntax somewhat resembles the SQL SELECT syntax, although a lot more limited.

The STICKY here just means that when the table is scrolled to the right, these sticky columns will remain visible at the left side.

Another supported keyword here is AS, so e.g. message AS msg is a valid syntax.

For a more extensive discussion on the logstreams and other core concepts, and advanced options like using sudo to read log files, consider reading the Core concepts section in the docs.

Requirements

• SSH access to the hosts is required (except for localhost). You can read about the related limitations and possible workarounds here: Consequences of requiring SSH access;
• Gawk (GNU awk) is a requirement on the hosts, since nerlog relies on the -b option. So notably, mawk will not work. You need gawk;

For more details, see Requirements and Limitations in the docs.

UI

UI consists of a few key elements:

• Awk pattern input: just a filter for logs. Empty filter obviously means no filter, and some examples of valid filters are:
  • Simple regexp: /foo bar/
  • Regexps with complex conditions: ( /foo bar/ || /other stuff/ ) && !/baz/
• Edit button: opens a complete query edit form discussed above.
• Menu button: just opens a menu with a few extra items:
  • Back: Go to the previous query, just like in the browser
  • Forward: Go to the next query, just like in the browser
  • Copy query command: