Shinken Architecture

Shinken’s architecture has been designed according to the Unix Way : one tool, one task. Shinken has an architecture where each part is isolated and connects to the others via standard interfaces. Shinken is based on the Python Pyro remote objects library. Which makes building a highly available or distributed monitoring architecture quite easy. In contrast, the Nagios daemon does nearly everything: it loads the configuration, schedules and launches checks, and raises notifications.

One of the major innovations of Shinken over Nagios is to split the different roles into separate daemons.

Another innovation is to permit the use of modules to extend and enrich the various Shinken daemons.

• Arbiter : The arbiter daemon reads the configuration, divides it into parts (N schedulers = N parts), and distributes them to the appropriate Shinken daemons. Additionally, it manages the high availability features: if a particular daemon dies, it re-routes the configuration managed by this failed daemon to the configured spare. Finally, it receives input from users (such as external commands from nagios.cmd) or passive check results and routes them to the appropriate daemon. Passive check results are forwarded to the Scheduler responsible for the check. There can only be one active arbiter with other arbiters acting as hot standby spares in the architecture.
  • Modules for data collection : NSCA
  • Modules for configuration data storage : MongoDB,
  • Modules for status retention : PickleRententionArbiter
  • Modules for configuration manipulation : IP_Tag, MySQLImport, GLPI, vmware autolinking

• Scheduler : The scheduler daemon manages the dispatching of checks and actions to the poller and reactionner daemons respectively. The scheduler daemon is also responsible for processing the check result queue, analyzing the results, doing correlation and following up actions accordingly (if a service is down, ask for a host check). It does not launch checks or notifications. It just keeps a queue of pending checks and notifications for other daemons of the architecture (like pollers or reactionners). This permits distributing load equally across many pollers. There can be many schedulers for load-balancing or hot standby roles. Status persistence is achieved using a retention module.
  • Modules for status retention : pickle, nagios, memcache, redis and MongoDB are available.

• Poller : The poller daemon launches check plugins as requested by schedulers. When the check is finished it returns the result to the schedulers. Pollers can be tagged for specialized checks (ex. Windows versus Unix, customer A versus customer B, DMZ) There can be many pollers for load-balancing or hot standby spare roles.
  • Module for data acquisition : NRPEbooster
  • Module for data acquisition : CommandFile (Used for check_mk integration which depends on the nagios.cmd named pipe )

• Reactionner : The reactionner daemon issues notifications and launches event_handlers. This centralizes communication channels with external systems in order to simplify SMTP authorisations or RSS feed sources (only one for all hosts/services). There can be many reactionners for load-balancing and spare roles
  • Module for external communications : AndroidSMS

• Broker : The broker daemon exports and manages data from schedulers. The management can is done exclusively with modules. Multiple Broker modules can be enabled simultaneously.
  • Modules for data retention: Pickle , Simple-log (flat file), ToNdodb_Mysql, ToNdodb_Oracle, ToMerlindb_Mysql, ToMerlindb_Sqlite, couchdb.
  • Modules for exporting data : Graphite-Perfdata, NPCDMOD(PNP4Nagios) and Syslog.
  • Modules for the Livestatus API - status retention and history : SQLite (default), MongoDB.
  • Module for the Shinken WebUI, GRAPHITE_UI, PNP_UI.
  • Modules for compatibility : Service-Perfdata, Host-Perfdata and Status-Dat

• Receiver (optionnal): The receiver daemon receives passive check data and serves as a distributed passive command buffer that will be read by the arbiter daemon. There can be many receivers for load-balancing and hot standby spare roles. The receiver can also use modules to accept data from different protocols. Anyone serious about using NSCA check results should use a receiver to ensure that when the arbiter is not available (when updating a configuration) all check results are buffered by the receiver and forwarding when the arbiter is back on-line.
  • Module for data collection : Nagios NSCA

If you wish to learn more about the Shinken distributed architecture , you can consult the official documentation.

If you are just starting out, you can continue with the next tutorial, which will help you configure a web front-end.

If you wish to plan a large scale installation of Shinken, you can consult the Scaling Shinken reference.

This is essential to avoid making time consuming mistakes and aggravation.