Livestatus

Thruk, NagVis, Checkmk — a whole ecosystem of consoles speaks MK Livestatus (LQL) to read a monitoring engine’s state without caring what that engine actually is. jaque implements that protocol, so those tools point at it without a single config change on their side.

Turning it on

Two flags, both empty (protocol off) by default:

-livestatus-listen 127.0.0.1:6557   # TCP
-livestatus-socket /tmp/jaque-livestatus.sock  # UNIX socket

Either or both can be set at once.

printf 'GET status\nOutputFormat: json\n\n' | nc -U /tmp/jaque-livestatus.sock

What it reads from

Its own projection of the event log, in parallel with the dashboard’s — same mechanism, separate consumer, so a Livestatus client never blocks or is blocked by the dashboard.

The tables

Nine tables: hosts, services, hostgroups, servicegroups, contacts, downtimes, comments, status, plus the meta-table columns describing all of them. Filtering, Stats: aggregation (sum/min/max/avg), and both output formats (csv, the Nagios default, and json) are supported.

The log table is not implemented, so Thruk features that need it will not work.

GET services
Filter: state = 2
Stats: state = 2
OutputFormat: json

Verified against a real client, not just the spec

The status table implements all 20 columns Thruk’s connect probe (get_processinfo) actually requests — not a subset inferred from reading the LQL spec. The exact request/response sequence Thruk sends on connect is pinned in a replay test against real Thruk traffic, so this isn’t “should work” — it’s checked against what a production Nagios console does the moment it connects.

What this unlocks

Any console that already knows how to talk Livestatus — Thruk, NagVis, Checkmk, WOCU — can point at a jaque instance and read its state without modifying its own configuration at all. Combined with the exec plugin protocol and the FIFO, this is the third leg that lets an existing Nagios-adjacent toolchain keep functioning unmodified while the engine underneath changes.