Page History

...

The synchronizer

The synchronizer role

The synchronizer daemon manage the whole configuration. It uses modules to detect new hosts and host modifications. It presents the configuration web interface to the administrators. Here are the optional sources the daemon can use to get information:

• Active directory
• VSphere (VMWare)
• Nagios or Shinken framework configuration files
• Network scans

Active directory

The Active Directory discovery is done with a domain account, and only need a read access. The connexion can be done in LDAPS to be sure the connexion is secure.

It is possible to define a top level OU in order to list only the elements (servers and users) that are defined below this OU level.

The information that the module is getting are server names, FQDN, the server OS, and if defined in the LDAP entry, its localization.

VSphere from VMWare

The VSphere discovery is designed to discover physical servers (ESX) and their virtual servers. It will also get OS and their IP address, but only if the VMware tools are enabled and running on the virtual server.

The Synchronizer to VMware connexion is always through the VSphere server, and only need a read only access to it. The Shinken Enterprise servers do not need any direct access to the ESX servers.

The Shinken Enterprise to VSphere communication is done with the SOAP API from VMWare, onto an HTTPS connexion.

Nagios or Shinken Framework configuration files

Shinken Enterprise is able to load any Nagios or Shinken Framework configuration files. It will automatically load the defined objects into its configuration.

Network scans

The network scan discovery is optional. It's done thanks to the nmap command, launched on the Synchronizer server. It allows to scan networks defined by the Shinken Enterprise administrators.

The scans are done on the TCP and UDP ports. It will also try to get additionnals data from the servers and services running on them (it use the -O option of the nmap command).

Data storage of the configuration

All discovered data from the Synchronizer are saved into a Mongodb database. If possible, it's better for the database to be set aside the Synchronizer daemon. this database do not need to be shared with other daemons, and so its communications should be limited to the local synchronizer server.

Configuration interface and its access

The configuration interface is hosted on the Synchronizer daemon, and use another TCP port than the visualization UI. You can use two different credential systems:

• Manage directly on the configuration interface
• Manage credentials with Active directory accounts. the daemon will use Ldap connexions to check for the credentials.

The non-admon users will be restricted in the visibility onto the hosts they are direct contacts linked to, or are in a contact group linked with the hosts.

This interface is using the save Mongodb databse than the synchronizer daemon. The default port for this configuration interface is 7766.

Synchonizer connexion summary

The arbiter

Role

The arbiter daemon reads the configuration from the synchronizer. It divides it into parts (N schedulers = N parts), and distributes them to the appropriate Shinken Enterprise 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  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.

Connexion with the synchronizer

The communication between the arbiter and the synchronizer is done on the standard port of the synchronizer (7765).

Connexion with the other daemons

This daemon is used to check and dispatch configuration to the others daemons, but not the Synchronizer. The connexion is done on the standard port of the others daemons, and will use a HTTPS connexion if the others daemons are defined to use it.

Data

This daemon is hosting the whole system configuration into memory. It has access to all server names, address, types, and also the defined command used to check them.

It also host in memory the defined contacts that should receive notification for the defined hosts and services.

Arbiter connexion summary

The scheduler

Role

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.

Other daemon connexions

The scheduler daemon open the 7768 port. It will get from it the configuration from the Arbiter daemon at each configuration change.

It will also get on this port the jobs from the other daemons (poller, reactionner and broker). The other daemons are consuming action and data from the scheduler.

The scheduler connexions

In one specific case, the scehduler open connexions to another daemons. This case is when there is a passive poller. this case will be saw on the poller part.

Data

This daemon is hosting the whole configuration. It have access to the whole contact list, but only a part of the realm hosts.

Connexions summary

The poller

Role

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.

Other daemon connexions

The poller get its configuration from the Arbiter daemon, by default on its 7771 port.

The configuration is the realm scheduler list where the poller will have to connect.

DMZ Poller

It's possible to set poller in a DMZ zone, and the schedulers into the LAN. In this situation, the goal is to avoid DMZ (poller) to LAN (schedulers) connexions. In this case, it's possible to set the poller as passive. In this case, the scheduler will open a connexion to the poller.

This is the recommanded setup in a DMZ.

Only checks for host in this DMZ will be launched by this poller.

Data

The poller get command from the schedulers.

It do not known about hosts or checks. It only get commands to execute, and the commands are created by the schedulers.

It's important to note that the plugins launched by the pollers will have a direct access to the monitored hosts, and they will need to get data from them.

Poller connexions summary

The reactionner

Role

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

Connexions with other daemons

The reactionner get it's configuration from the Arbiter daemon, on its 7769 port.

The configuration is the realm scheduler list where the reactionner will have to connect.

Mail server visibility

The reactionner launch notification plugins in order to notify contacts from host or checks alerts. Notification plugins are mainly based on the mail system, and so the reactionner server need a local MTA configured to relay emails to the contacts. The MTA configuration is up to the administrators.

Data

The reactionner get command from the schedulers.

It do not known about contacts. It only get commands to execute, and the commands are created by the schedulers.

Reactionner connexion summary

The broker

Role

The broker daemon exports and manages data from schedulers. The management can be done exclusively with modules. Multiple broker modules can be enabled simultaneously. Example of broker modules:

• Module for centralizing Shinken logs: Simple-log (flat file)

• Modules for exporting data: Graphite-Perfdata

• Modules for the Livestatus API

Data

The broker daemon get all monitoring data from the schedulers. it will also keep in memory host and service data. It also save checks results into a mongodb database. If possible, this database should be local to the broker server.

Metrology data

The metrology data are saved on the broker server by the graphite application. This application is listening to the 2003 port, and this connexion is without authentification. So this application should be local and limited to the localhost address of the broker server.

Broker connexion summary

The receiver

Role

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.

• Module for passive data collection: WS arbiter module

Other daemon communications

The arbiter will get data from the receiver each seconds.

Data

The receiver keep in memory a buffer of external commands. Theses external commands have host and checks names.

Receiver connexion summary

None.

Architecture summary

This architecture is fully flexible and scalable: the daemons that require more performance are the poller and the schedulers. The administrator can add as many as he wants.

...