Naemon & Nagios, event by event

Every monitoring event, stored and streamed

Statusengine takes every event out of your monitoring core the moment it happens and hands it to a message queue. A Go worker drains that queue: history and current state into MySQL, performance data into Graphite, and a live WebSocket stream for anything that wants the events as they arrive.

Read the documentation Source on GitHub
The three moving parts
Broker module
A small C++ library loaded into Naemon or Nagios Core. It picks up status data through the NEB callback API, encodes it as JSON, and publishes it to Gearman or RabbitMQ.
Worker
A Go daemon that consumes the queue, writes to MySQL in throttled bulk inserts, routes performance data to Graphite, and exposes a live WebSocket stream.
Queue
Gearman or RabbitMQ sits between the two. Both are supported by broker and worker alike, and the choice is a single configuration key on each side.
How data flows
  flowchart LR
  core["Naemon / Nagios Core"] -->|NEB callbacks| broker["Broker module<br/>libstatusengine.so"]
  broker -->|JSON| queue{{"Gearman<br/>or RabbitMQ"}}
  queue --> worker["Statusengine Worker<br/>(Go)"]
  worker -->|bulk INSERT| mysql[("MySQL")]
  worker -->|perfdata| graphite[("Graphite")]
  mysql -->|current state| ui["Web Interface<br/>seid"]
  worker -->|live events, WebSocket| ui
  worker -->|live events, WebSocket| clients["Other WebSocket clients<br/>dashboards, notifiers"]
  ui -.->|POST /commands| worker
  worker -.-> queue
  queue -.-> broker
  broker -.->|external commands| core

Reading runs left to right and ends at the database. The web interface picks it up from there: current state comes out of MySQL, and a WebSocket to the worker keeps it live instead of polling.

It is not a privileged client, only the first one. The worker fans the same stream out to as many subscribers as connect, each with its own buffer, so a dashboard or a chat notifier of your own reads exactly what the interface reads.

The dotted path is the same route in reverse, and it is what makes the queue two-way. Acknowledging a problem or forcing a check posts to the worker’s /commands API, the worker publishes it onto the command queue, the broker consumes it, and the core receives it as an external command.

Why a queue at all
The core never blocks
Publishing to Gearman or RabbitMQ is a local, non-blocking hand-off. Database maintenance, a full disk, or a restarted worker no longer delay check execution.
Spread the load
Several monitoring nodes can publish into the same queue, and several workers can drain it. Adding capacity means adding a process, not resizing a server.
Bulk, not row by row
The broker batches events into bulk messages and the worker writes them in batched INSERTs, so the database sees a fraction of the statements it would otherwise.
Start here
Install the broker module
Build it with Meson and load it into your monitoring core.
Install the worker
Build the Go binaries, point them at MySQL, run them under systemd.
Tutorials
Step-by-step guides for the pieces around Statusengine.