Shinken: Monitoring That Feels Familiar — But Scales Smarter
What Is It, Really?
Shinken is a monitoring framework that was built to pick up where Nagios leaves off. It keeps the same configuration logic — so anyone used to `.cfg` files won’t be lost — but the internals are reworked. It’s Python-based, modular, and easier to spread across multiple systems.
Instead of trying to be a one-size-fits-all tool, Shinken separates its roles: scheduling, executing, brokering, and notifying all run as independent daemons. That makes it easier to scale, easier to troubleshoot, and a lot more flexible in terms of deployment.
How It Actually Works
You start with the config — which is still in the Nagios format — and load it through the Shinken arbiter. From there, it hands off tasks to whichever processes are running: scheduler, pollers, brokers, and so on.
Each of these daemons can live on the same machine, or be spread out across different nodes. For example, you can have pollers close to the machines they’re checking, and brokers near your database. This cuts down on load and latency without re-engineering your whole monitoring logic.
It supports SNMP, NRDP, NSCA, and passive checks — so it fits well in mixed environments, especially those with older infrastructure still in place.
What It’s Good At
| Capability | What It Brings |
| Modular Components | Run scheduler, poller, receiver, etc. on separate systems |
| Nagios Compatibility | Drop in existing `.cfg` files — no rewrites |
| Distributed Monitoring | Use satellites and pollers in different networks |
| Custom Backends | Integrate with Thruk, Graphite, or InfluxDB |
| Python Base | Easier to hack on or extend than C-based systems |
| Alert Prioritization | Business impact modules to control alert flow |
Setup Basics
1. Install Python 2.7 (yes, it’s dated — but some forks now support Python 3)
2. Get Shinken
Either clone from GitHub or install via pip (if using older builds).
3. Configure It
Stick with Nagios-style config. No YAML, no DSLs — just `.cfg`.
4. Start the Core
Launch `shinken-arbiter`, `shinken-scheduler`, `shinken-poller`, and other daemons.
5. Optional Add-ons
Hook it into a frontend like Thruk, and wire up metrics to Graphite or other storage.
When It’s the Right Tool
– You’re already using Nagios and don’t want to start over
– Your network spans sites or data centers, and local pollers make more sense
– You need passive checks and SNMP alongside custom scripts
– You want something that won’t choke at scale, even if it’s not flashy
– You’re comfortable editing `.cfg` files and deploying by hand
Comparison Snapshot
| Tool | Strength | Shinken Works Better When… |
| Nagios | Simple, stable, but limited | You hit scale limits or need distributed checks |
| Icinga | More modern UI, better DB model | You want modular processes, not a monolith |
| Prometheus | Metrics-first, no checks | You need hybrid alerting and legacy integration |
| Zabbix | All-in-one, more opinionated | You prefer modularity and CLI configs |
Bottom Line
Shinken isn’t the newest thing out there — and it doesn’t try to be. But for teams running mixed systems, or stuck between legacy tools and modern infrastructure, it offers a clean path forward. It scales well, it’s modular, and it gets the job done without throwing away what already works.
