ripgrab

What it does

ripgrab is tail -F but it takes a set of regex filters and, optionally, named capture groups, and it will fan out across N files (or stdin sources) and present one merged, colorized stream. If your log line has a timestamp it’ll sort-merge by timestamp with a small buffer window so interleaved output stays chronological.

I use it most for chasing a single request through four services that all write to different log files on different boxes, piped in via ssh.

Why I made it

multitail is great but the filter syntax has aged badly and the colors are fixed. lnav is fantastic for post-hoc analysis but overkill for live tailing. I wanted something that felt like rg --follow --each-file-labeled-and-merged.

How it works

The hot path is a tokio runtime with one task per input source reading into a bounded channel. A merger task pulls lines, applies regex in order of specificity, extracts named groups with the regex crate, then emits to a rendering task. Filters compile once at startup; named groups map to column indices so rendering is a straight format.

The sort-merge uses a small heap with a configurable buffer (default 500ms). If a source stalls the heap will emit anyway after the watermark so you don’t get head-of-line blocking.

Install

Not on crates.io — I stopped publishing to avoid name collisions. The source is at /src/ripgrab/. Copy it into a local crate and cargo build --release. Linux and macOS; Windows compiles but I don’t test it.

Typical invocation:

ripgrab -f 'request_id=(?P<rid>[a-f0-9-]+)' \
        --color-by rid \
        svc-a.log svc-b.log svc-c.log

Each distinct rid gets its own stable color. Makes it very easy to see one request’s path through the system.

Known issues

• Extremely long (>64KB) log lines get truncated. I keep meaning to make this configurable.
• The sort-merge window can reorder lines if one source is way behind. Usually fine, occasionally confusing.