Shinken

Last reviewed Sep 13, 2026 · 809 words

Do not deploy Shinken on a new server in 2026. The project's last tagged release came out before Python 2 reached end of life in January 2020, the codebase targets Python 2, and the fork that tried to carry it forward (Alignak) has gone quiet too. Shinken mattered because it proved that a Nagios-compatible monitoring core could be split into cooperating daemons and scaled across machines, and that idea lives on in the tools that replaced it. This guide is for two readers: the person who inherited a Shinken install and needs to understand it, and the person who found it while searching for a Nagios alternative and needs redirecting.

Why it existed: Nagios could not scale sideways

Nagios Core runs one scheduler on one host, and by the late 2000s large sites were hitting the ceiling: thousands of hosts, tens of thousands of checks, one process doing all the scheduling and result handling. Shinken rewrote the core in Python and cut it into six daemon roles. The arbiter reads the configuration and dispatches it. Schedulers decide when checks run. Pollers execute the check plugins. Reactionners send notifications. Brokers export results to databases, the web interface, and log files. Receivers accept passive check results. Each role can run on several machines, pollers can be tagged so that checks for a remote site run from a poller inside it, and a failed scheduler's work can be reassigned. For its era, that was the most elegant distributed design in open-source monitoring.

Nagios compatibility was the adoption trick

Shinken read Nagios configuration files unchanged: hosts, services, templates, hostgroups, contacts, escalations, the lot. It ran the same check plugins (the Monitoring Plugins collection, NRPE, agent-based checks) and emitted compatible status output, so an existing Nagios shop could swap the core, keep years of config, and gain distribution. It added a few things Nagios lacked: business rules for "critical only if 2 of 3 backends are down", discovery for building configuration from scans, and a module system for the broker that fed Graphite, databases, and its own WebUI. The WebUI itself was serviceable, never beautiful.

What running it means today

If you have an existing install, it is almost certainly on a distribution release from years ago, because a current OS ships no Python 2 and the package ecosystem for it has largely evaporated. That box cannot be patched, cannot be rebuilt from scratch without heroics, and is monitoring things that presumably matter. The realistic plan is not to upgrade Shinken but to run something new alongside it, migrate the configuration (which is Nagios-format, so it moves easily), and switch the notification contacts over once both agree for a month. The check plugins themselves carry across unchanged; that is the one part of the investment that survives.

Where to go instead

Three destinations, depending on what you valued. Naemon is the closest: a maintained C fork of Nagios Core with the same config format, Thruk as the web interface, and Livestatus built in, so your files load with minimal edits, though it does not distribute the way Shinken did. Icinga 2 is the successor for distribution: a native cluster with master, satellite, and agent zones, a new configuration language that is worth the rewrite, and an ecosystem still shipping releases. Checkmk is the choice if you want the agent-driven auto-discovery Shinken's discovery module hinted at, wrapped in a product with a free raw edition. For a homelab that landed here by mistake, none of these is right either; the monitoring category is dominated by Prometheus plus Grafana and by Uptime Kuma for a reason, and those are lighter to learn than any Nagios descendant.

The lesson worth keeping

Shinken's architecture influenced everything after it. Icinga 2's zones, the separation of scheduling from execution in later tools, and the broker-style export of results to a time-series database all echo the six-daemon model. The AGPL licence, the Python implementation, and 1,135 stars are what remain on GitHub; the ideas moved on. Read the old architecture docs if you are designing a monitoring pipeline; do not pip install it.

What I'd do

Inheriting a Shinken box, I would freeze it, export the configuration and plugins, stand up Icinga 2 in a distributed layout if the site is large or Naemon if it is a single node, run both until a month of alerts agreed, and then decommission the Python 2 host. Starting fresh, I would not consider Shinken at all: Icinga 2 for a Nagios-shaped estate, Prometheus and Grafana for services that expose metrics, and Uptime Kuma if the question is only "is it up". Shinken earned its place in the history of the category, and history is where it should stay.