Rôle

Le démon Poller exécute les sondes tel que planifié par les Schedulers.

Il se connecte au(x) Scheduler(s) de son royaume et récupère les checks pour exécuter les commandes/sondes. Quand la commande est terminée, le retour de la sonde est envoyé aux Schedulers. Les Pollers peuvent être définis pour des vérifications spécifiques dans des environnements spécifiques  (ex. Windows versus Unix, client A versus client B, DMZ).

Il peut également y avoir plusieurs Pollers pour des questions de répartition de charge (load-balancing).

Connexions avec les autres démons 

L'Arbiter envoie la configuration du Poller via le port 7771 de ce dernier.

Sa configuration correspond à la liste du ou des Schedulers du royaume auxquels il devra se connecter pour récupérer des checks à exécuter. Le Poller se connecte au(x) Scheduler(s) via le port 7768 de ce dernier.

Différents types de Pollers: Les Pollers TAG

L'architecture actuelle de Shinken Enterprise est très utile pour une organisation qui utilise le même type de Poller pour tous les checks. Mais il peut être nécessaire d'avoir différents types de Poller.  

Cela peut être utile quand l'utilisateur a besoin d'avoir ses hôtes dans le même Scheduler (comme avec les dépendances) ou alors s'il a besoin d'avoir des hôtes ou des checks pris en charge par un Poller spécifique. 

Ces vérifications peuvent être qualifiés à 3 niveaux :

  • Hôte
  • Check
  • Commande

Le paramètre pour qualifier une commande, un hôte ou un check est le "poller_tag". 

L’existence du paramètre est déterminée dans l'ordre de priorité suivant:

  • On regarde d'abord sur la commande
  • puis le check
  • puis sur l’hôte.

Les Pollers peuvent être identifiés par plusieurs poller_tags.

S'ils ont des tags, ils ne prendront que les checks qui correspondent à ce tag.

C'est principalement utilisé dans un réseau en DMZ, voyons voir pour pourquoi dans le chapitre suivant.

Poller en DMZ

 

Il se peut que vous ayez des checks à exécuter dans une DMZ (Zone Réseau Démilitarisé). Il est alors possible de définir un Poller en DMZ, et les Schedulers (et autres démons) dans le réseau interne, le LAN.

Un Poller dédié (Linux ou Windows) pourra être directement placé en DMZ pour des soucis de sécurité, de latence/temps d'exécution, ou car l'environnement est différent (hors domaine AD, DMZ exclusivement Windows, etc..).

Dans ce cas, pour respecter la sécurité de l'espace démilitarisé, les connections réseaux de DMZ (Poller) vers LAN (Schedulers) ne sont pas autorisées par les Firewall.

Pourtant, comme on l'a vu précédemment, par défaut, le Poller ouvre une connexion vers le ou les Schedulers.

Il est alors possible de définir le Poller comme passif. Le Scheduler va alors ouvrir une connexion vers le Poller.

 

Pour que le Scheduler n'envoie au Poller passif que les checks à réaliser dans la DMZ, il faut tagguer les hôtes, les checks ou les commandes.

Seuls les hôtes, checks et commandes taggués seront alors lancés par ce Poller DMZ.

De cette manière, vous pouvez toujours avoir des dépendances entre les hôtes dans la DMZ et le LAN, et pourtant être certain que les checks voulus sont effectués par le Poller dans la DMZ.

 

Données

Le poller reçoit la commande des schedulers.

Il est important de noter que les sondes lancées par le poller auront un accès direct aux hôtes et devront récupérer des données venant de ceux-ci. 

Poller Internes

Résumé des connexions du poller 

sourceDestinationPortProtocoleNote
PollerScheduler7768HTTPS 

Descriptions des variables

PropriétéDéfautDescription
poller_nameN/ACette variable est utilisée pour définir le nom raccourci du poller auquel sont rattachées les données .
addressN/ACette directive est utilisée pur définir l'adresse d'où l'arbiter principal peut joindre le poller. ça peut être un nom DNS ou une adresse IP .
port7771Cette directive est utilisée pour définir le port TCP utilisé par ce démon .
spare0Cette variable est utilisée pour définir si le poller peut être géré comme spare (ne chargera la configuration que si le maître tombe )
realmN/ACette variable est utilisée pour définir le royaume où sera mis le poller . Si aucun n'est spécifié, il sera rattaché au royaume par défaut.
manage_sub_realms0Cette variable est utilisée pour définir si le poller acceptera les tâches du scheduler provenant des sous-royaumes de son royaume.
poller_tagsNoneCette variable est utilisée pour définir les checks que peut lancer le poller. Si il n'y a aucun poller_tags spécifié, il prendra tous les checks non qualifiés.
Par défaut, il n'y a aucun poller_tag, donc il prend tous les checks non qualifiés. .
modulesN/ACette variable est utilisée pour définir tous les modules que le scheduler va charger. .

Exemple de définition

 

 

define poller{
   poller_name           Europe-poller
   address               node1.mydomain
   port                  7771
   spare                 0
   manage_sub_realms     0
   poller_tags           DMZ, Another-DMZ
   modules               module1,module2
   realm                 Europe
   min_workers           0 ; Starts with N processes (0 = 1 per CPU)
   processes_by_worker   256 ; Each worker manages N checks
   polling_interval      1 ; Get jobs from schedulers each N seconds
}