Shinken versus Nagios feature comparison

Shinken versus Nagios feature comparison

Shinken is a Nagios-compatible monitoring tool with a modern architecture. Shinken excludes Nagios configurations deemed incompatible, dangerous or no longer required.

Technical comparison of Shinken and Nagios

Here is how Shinken (basically) compares to Nagios. For each feature, you will see whether it is present, missing or “not fully working” :

	Ok, fully working
	Not fully working or difficult to get working
	Not available

Now the comparison table :

Feature	Nagios	Shinken	In Shinken roadmap	Notes
Host/Service monitoring with HARD/SOFT status management
Active monitoring with plugins
Passive monitoring
Compatible with RRDtool based data graphing addons (pnp, nagiosgrapher, etc.)				Shinken also supports  forwarding performance data to Graphite and has native Graphite template based graphs in the WebUI.
Network host hierarchy
Hosts and services dependencies
Proactive problem resolution
User-defined notifications
Notifications escalation
Syslog logging
Flap detection
Obessive compulsive commands				It’s not useful in the Shinken architecture but it makes the switch to Shinken easier.
State freshness check
Event broker modules: Livestatus API, ndo, pnp, sqlite and other modules.				Shinken includes a host of native Python modules to make it easy to extend and support. Other supported integration modules : Graphite time-series database, GLPI, MongoDB, memcached, redis and more.
Load modules for any daemon. (Poller, Scheduler, Receiver, etc.)				Modules can be loaded for any daemon. This makes supporting, extending and scaling Shinken very easy.
Graphite integration in the WebUI				Graphite is a next-generation time-series database and visualisation web application/API. It stores non interpolated data in a distributed and scalable manner. The current standard RRD interpolates all data limiting its applicability. Starting with 0.8 and with major enhancements in 1.0 and  1.2. (available in current git version)
Notifications escalation is  not a pain in the ass to configure				You can call an escalation from any host or service. That’s way easier to use!
Distributed monitoring				Nagios can do DNX, but it’s not as easy to manage than Shinken architecture, and not as efficient.You think “easy as in cloud”?That’s Shinken.
High availability				With Nagios, high availability implies a huge performance hit.
Distributed AND high availability				With Nagios, high availability implies a huge performance hit, and it is harder to get working and to maintain.
Integrated business rules				With Nagios it’s an addon, so it’s not easily manageable in a distributed configuration.
Problem/impacts				With Nagios it is only available in the notification part, but with Shinken it’s also available in the real time monitoring views!
Easy DMZ monitoring				Shinken has poller_tag that allow the user to put a poller in a DMZ and do all DMZhosts/services with it. It make less Firewall holes.
UTF-8 support				Thank you Python. Now %µ~@^-nöel is supported as a host name.
Scheduling 100K checks in 5 minutes. Loading and using 60K+ hosts and services. Storing time-series data for 500K data points in Graphite via a broker module.				Need performance and scalability ? Try that with Nagios…
Runs on Windows				Thank you Python again. Flexible monitoring : direct WMI or Powershell queries!
Configure flap history				Nagios handles flapping for the 20 latest states only. It’s hard-coded. In Shinken it’s a configuration option.
Impact management				For Nagios it’s as important when an incident impacts a qualification application or a production one. Shinken computes dynamically the business impact of the root problem based on criticality!
Modern language and program design				Python is a forward looking and easy to program language. Shinken was developed using a TDD approach and makes use of modules with all the daemons to make it easy to extend and stability oriented. We have great respect for the C core programmers of Nagios/Icinga/Opsview, but does it have to be so painful?
Modern Web Interface built on twitter bootstart and jquery. Including a mobile interface.				Shinken 1.2 introduces a rebuilt WebUI interface which exposes the unique features of the underlying monitoring system.
MongoDB distributed DB				Shinken 1.0 introduces mongoDB support for Livestatus and as the configuration database for the skonf preview.
Configuration pre-cache support				Pre-cache was useful for host circular relation check. I corrected it in Nagios and in Shinken as well. Pre-cache is no longer a required feature.
Limit external command slots				Shinken does not need to limit the number of external command in queue.
Advanced retain options				No one uses this.
Inter check sleep time				This is a historical Nagios option. Shinken has a real scheduler.
Configure reaper time				Reaping? That is one reason which makes Nagios so slow. Shinken does everything in memory.
Auto rescheduling option				In Nagios, it’s still experimental and not documented. This feature is in the roadmap. It can be useful to “smooth” the scheduling load.
Embedded Perl				Shinken is in Python. Perl checks can be loaded using persistent perl, which is a near equivalent to embedded perl, it requires changing the first line of each check. So you do this for the most used perl scripts.
Embedded Python				Shinken is in Python. Checks can be executed as poller or receiver modules for maximum scalability.
Regular expression matching				We believe this is a dangerous feature for the configuration and that most administrators avoid using it.
Binary Event broker compatibility				Shinken does not load binary modules like the ndomod.o file. It has its own loadable modules written in python : ndo,  pnp, graphite, mongodb, sqlite, Livestatus API, NSCA, NRPE, TSCA, syslog, merlin and others