1 Découverte du réseau

Aperçu

Zabbix offre une fonctionnalité de découverte automatique du réseau, à la fois efficace et très flexible.

Avec une découverte du réseau correctement configurée, vous pouvez :

  • accélérer le déploiement de Zabbix
  • simplifier l’administration
  • utiliser Zabbix dans des environnements en évolution rapide sans administration excessive

La découverte du réseau Zabbix repose sur les informations suivantes :

  • plages d’adresses IP
  • disponibilité des services externes (FTP, SSH, WEB, POP3, IMAP, TCP, etc.)
  • informations reçues de l’agent Zabbix (seul le mode non chiffré est pris en charge)
  • informations reçues de l’agent SNMP

Elle ne fournit PAS :

  • la découverte de la topologie du réseau

La découverte du réseau se compose essentiellement de deux phases : la découverte et les actions.

Découverte

Zabbix analyse périodiquement les plages d'adresses IP définies dans les règles de découverte réseau. La fréquence de la vérification est configurable individuellement pour chaque règle.

Chaque règle dispose d'un ensemble de vérifications de service définies à exécuter pour la plage d'adresses IP.

Les règles de découverte sont traitées par le gestionnaire de découverte. Le gestionnaire de découverte crée une tâche par règle avec une liste de tâches (vérifications réseau). Les vérifications réseau sont exécutées en parallèle par les workers de découverte disponibles (leur nombre est configurable dans l'interface pour chaque règle). L'exception concerne les vérifications SNMPv3, qui sont traitées par un seul worker. Seules les vérifications avec la même adresse IP et le même port sont planifiées séquentiellement, car certains périphériques n'acceptent pas les connexions parallèles sur le même port.

La taille de la file d'attente des vérifications réseau est limitée à 2000000, soit environ 4 Go de mémoire. Si la file d'attente devient pleine, la règle de découverte sera ignorée et un message d'avertissement sera inscrit dans le journal. Vous pouvez utiliser l'élément interne zabbix[discovery_queue] pour surveiller le nombre de vérifications de découverte dans la file d'attente.

Les vérifications de découverte sont traitées indépendamment des autres vérifications. Si certaines vérifications ne trouvent pas de service (ou échouent), les autres vérifications seront tout de même traitées.

Si une règle de découverte est modifiée pendant l'exécution, l'exécution de découverte en cours sera alors interrompue.

Chaque vérification d'un service et d'un hôte (IP) effectuée par le module de découverte réseau génère un événement de découverte.

Event Check of service result
Service Discovered Le service est 'up' après avoir été 'down' ou lorsqu'il est découvert pour la première fois.
Service Up Le service est 'up', après avoir déjà été 'up'.
Service Lost Le service est 'down' après avoir été 'up'.
Service Down Le service est 'down', après avoir déjà été 'down'.
Host Discovered Au moins un service d'un hôte est 'up' après que tous les services de cet hôte étaient 'down', ou un service est découvert et appartient à un hôte non enregistré.
Host Up Au moins un service d'un hôte est 'up', après qu'au moins un service était déjà 'up'.
Host Lost Tous les services d'un hôte sont 'down' après qu'au moins un était 'up'.
Host Down Tous les services d'un hôte sont 'down', après qu'ils étaient déjà 'down'.

Actions

Les événements de découverte peuvent servir de base à des actions pertinentes, telles que :

  • Envoi de notifications
  • Ajout/suppression d’hôtes
  • Activation/désactivation d’hôtes
  • Ajout d’hôtes à un groupe
  • Suppression d’hôtes d’un groupe
  • Ajout de tags à un hôte
  • Suppression de tags d’un hôte
  • Liaison d’un modèle à des hôtes/dissociation d’un modèle d’hôtes
  • Exécution de scripts distants

Ces actions peuvent être configurées en fonction du type d’appareil, de l’IP, du statut, du temps de fonctionnement/d’arrêt, etc. Pour tous les détails sur la configuration des actions pour les événements basés sur la découverte réseau, consultez les pages operation et conditions des actions.

Étant donné que les actions de découverte réseau sont basées sur des événements, elles seront déclenchées à la fois lorsqu’un hôte découvert est en ligne et lorsqu’il est hors ligne. Il est fortement recommandé d’ajouter la condition d’action Discovery status: up afin d’éviter que des actions telles que Add host soient déclenchées lors d’événements Service Lost/Service Down. Sinon, si un hôte découvert est supprimé manuellement, il générera tout de même des événements Service Lost/Service Down et sera recréé lors du prochain cycle de découverte.

La liaison de modèles à un hôte découvert échouera globalement si l’un des modèles pouvant être liés possède une entité unique (par exemple, une clé d’élément) identique à une entité unique (par exemple, une clé d’élément) existant déjà sur l’hôte ou sur un autre des modèles pouvant être liés.

Création d’un hôte

Un hôte est ajouté si l’opération Add host est sélectionnée. Un hôte est également ajouté, même si l’opération Add host est absente, si vous sélectionnez des opérations entraînant des actions sur un hôte. Ces opérations sont les suivantes :

  • activer l’hôte
  • désactiver l’hôte
  • ajouter l’hôte à un groupe d’hôtes
  • lier un modèle à un hôte

Les hôtes créés sont ajoutés au groupe Discovered hosts (par défaut, configurable dans Administration > General > Other). Si vous souhaitez que les hôtes soient ajoutés à un autre groupe, ajoutez une opération Remove from host groups (en spécifiant « Discovered hosts ») et ajoutez également une opération Add to host groups (en spécifiant un autre groupe d’hôtes), car un hôte doit appartenir à un groupe d’hôtes.

L’adresse IP du périphérique découvert, ainsi que la source de découverte (serveur Zabbix, proxy Zabbix ou groupe de proxies) et le type d’interface, sont utilisés comme critère pour trouver un hôte dans le système. Si un hôte avec la même adresse IP, le même type d’interface et la même source de découverte existe déjà, cet hôte sera la cible de l’exécution des opérations. Si la source de découverte diffère, l’entité découverte est traitée comme un hôte différent et un nouvel hôte peut être créé.

Si l’adresse IP de l’hôte découvert est modifiée ou si l’interface est supprimée, un nouvel hôte sera créé lors de la prochaine découverte.

Nommage des hôtes

Lors de l’ajout d’hôtes, le nom d’hôte résulte d’une résolution DNS inverse ou de l’adresse IP si la résolution inverse échoue. La résolution est effectuée depuis le serveur Zabbix ou le proxy Zabbix, selon celui qui réalise la découverte. Si la résolution échoue sur le proxy, elle n’est pas retentée sur le serveur. Si un hôte portant déjà ce nom existe, le nom de l’hôte suivant se verra ajouter _2, puis _3, et ainsi de suite.

Il est également possible de remplacer la résolution DNS/IP et d’utiliser à la place la valeur d’un élément comme nom d’hôte, par exemple :

  • Vous pouvez découvrir plusieurs serveurs exécutant l’agent Zabbix à l’aide d’un élément d’agent Zabbix pour la découverte et leur attribuer automatiquement des noms appropriés, en fonction de la valeur de chaîne renvoyée par cet élément
  • Vous pouvez découvrir plusieurs équipements réseau SNMP à l’aide d’un élément d’agent SNMP pour la découverte et leur attribuer automatiquement des noms appropriés, en fonction de la valeur de chaîne renvoyée par cet élément

Si le nom d’hôte a été défini à l’aide de la valeur d’un élément, il n’est pas mis à jour lors des vérifications de découverte suivantes. S’il n’est pas possible de définir le nom d’hôte à l’aide de la valeur d’un élément, la valeur par défaut (nom DNS) est utilisée.

Si un hôte existe déjà avec l’adresse IP découverte et que la source de découverte (serveur Zabbix, proxy ou groupe de proxys) n’a pas changé, aucun nouvel hôte n’est créé. Si la source de découverte diffère, l’entité découverte est traitée comme distincte et un nouvel hôte peut être créé. Cependant, si l’action de découverte contient des opérations (lier un modèle, ajouter à un groupe d’hôtes, etc.), elles sont exécutées sur l’hôte existant qui correspond à l’adresse IP, au type d’interface et à la source de découverte.

Suppression d’hôte

Les hôtes découverts par une règle de découverte réseau sont supprimés automatiquement de Monitoring > Discovery si une entité découverte ne se trouve plus dans la plage d’adresses IP de la règle. Les hôtes sont supprimés immédiatement.

Création d’interfaces lors de l’ajout d’hôtes

Lorsque des hôtes sont ajoutés à la suite d’une découverte réseau, des interfaces leur sont créées selon les règles suivantes :

  • Les services détectés — par exemple, si une vérification SNMP a réussi, une interface SNMP sera créée.
  • Si un hôte répond à la fois aux requêtes de l’agent Zabbix et aux requêtes SNMP, les deux types d’interfaces seront créés.
  • Si les critères d’unicité sont des données renvoyées par l’agent Zabbix ou par SNMP, la première interface trouvée pour un hôte sera créée comme interface par défaut. D’autres adresses IP seront ajoutées comme interfaces supplémentaires. Les conditions de l’action (telles que l’IP de l’hôte) n’ont pas d’impact sur l’ajout d’interfaces. Notez que cela fonctionnera si toutes les interfaces sont découvertes par la même règle de découverte. Si une autre règle de découverte découvre une interface différente du même hôte, un hôte supplémentaire sera ajouté.
  • Si un hôte répond uniquement aux vérifications de l’agent, il sera créé avec une interface d’agent uniquement. S’il commence plus tard à répondre à SNMP, des interfaces SNMP supplémentaires seront ajoutées.
  • Si 3 hôtes distincts ont été initialement créés, après avoir été découverts selon les critères d’unicité « IP », puis que la règle de découverte est modifiée de sorte que les hôtes A, B et C aient un résultat de critères d’unicité identique, B et C sont créés comme interfaces supplémentaires pour A, le premier hôte. Les hôtes individuels B et C restent. Dans Monitoring > Discovery, les interfaces ajoutées seront affichées dans la colonne « Discovered device », en police noire et avec un retrait, mais la colonne « Monitored host » n’affichera que A, le premier hôte créé. « Uptime/Downtime » n’est pas mesuré pour les IP considérées comme des interfaces supplémentaires.

Modification du paramètre de proxy

Les hôtes découverts par différents proxys ne sont pas toujours traités comme des hôtes différents. La découverte et les vérifications d’unicité dépendent de la structure du groupe de proxys : lorsqu’un proxy exécute une règle de découverte et crée un hôte, cet hôte est ajouté au groupe de proxys parent du proxy, et non attribué au proxy lui-même. Lorsque Zabbix évalue l’unicité de l’adresse IP pendant la découverte, il vérifie les hôtes supervisés par le groupe de proxys parent. Les hôtes supervisés par des proxys individuels au sein de ce groupe (y compris le proxy qui a exécuté la découverte) sont ignorés lors de la vérification d’unicité, ce qui peut entraîner des doublons d’hôtes si plusieurs proxys supervisent des sous-réseaux qui se chevauchent.

Bien que ce comportement permette à la découverte de fonctionner sur des plages d’adresses IP qui se chevauchent et sont utilisées par différents sous-réseaux, la modification du proxy attribué à un sous-réseau déjà supervisé est plus complexe, car les changements de proxy doivent être appliqués de manière cohérente aux hôtes découverts ainsi qu’à l’appartenance au groupe de proxys parent afin d’éviter les doublons.

Par exemple, voici les étapes pour remplacer le proxy dans une règle de découverte :

  1. désactiver la règle de découverte
  2. synchroniser la configuration du proxy
  3. remplacer le proxy dans la règle de découverte
  4. remplacer le proxy pour tous les hôtes découverts par cette règle (s’assurer que les hôtes du groupe de proxys parent ainsi que tous les hôtes supervisés par des proxys individuels de ce groupe sont mis à jour afin d’éviter les doublons)
  5. activer la règle de découverte