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
sourceDestinationPortProtocolNote
PollerScheduler7768HTTPS 

 

Different types of Pollers: poller_tag

The current Shinken Enterprise architecture is useful for someone that uses the same type of poller for checks. But it can be useful to have different types of pollers. We already saw that all pollers talk to all schedulers. In fact, pollers can be "tagged" so that they will execute only some checks.

This is useful when the user needs to have hosts in the same scheduler (like with dependencies) but needs some hosts or services to be checked by specific pollers (see usage cases below).

These checks can in fact be tagged on 3 levels :

The parameter to tag a command, host or service, is "poller_tag". If a check uses a "tagged" or "untagged" command in a untagged host/service, it takes the poller_tag of this host/service. In a "untagged" host/service, it's the command tag that is taken into account.

The pollers can be tagged with multiple poller_tags. If they are tagged, they will only take checks that are tagged, not the untagged ones, unless they defined the tag "None".

It's mainly used when you have a DMZ network, you need to have a dedicated poller that is in the DMZ, and return results to a scheduler in LAN. With this, you can still have dependencies between DMZ hosts and LAN hosts, and still be sure that checks are done in a DMZ-only poller.