La surveillance d’infrastructure, Services réseau et l’état du système avec icinga2

Dans cet article nous allons examiner le bilan de santés techniques du système commun pour les serveurs Windows et Linux et les périphériques réseau, ainsi que leur configuration, et la mise en relation parent-enfant entre les hôtes et les services icinga 2.

Le paquet nagios-plugins fournit de nombreux plugins de contrôle pour la vérification de beaucoup de choses communes qu’on peut les intégrer facilement avec Icinga 2. Plus de plugins peuvent être trouvés en ligne pour une utilisation spécifique.

ICINGA/Nagios Exchange : http://exchange.nagios.org/ et http://exchange.icinga.org/

MonitoringExchange: http://www.monitoringexchange.org

Monitoring-plugins: https://www.monitoring-plugins.org/

La plus part de ces plugins installés sous /usr/lib/nagios/plugins ou /usr/lib64/nagios/plugins, selon l’architecture de l'ordinateur superviseur.

Avant de passer aux chose sérieux on va voir la configuration de localhost sur la quelle elle est installée icinga2:

Donc jetons un coup d'œil étroit à notre configuration actuelle, que nous avons créé dans le dernier chapitre, l’installation d’icinga2 par défaut nous a crée un ensemble de fichier de configuration sous le répertoire /etc/icnga2/conf.d :

Regardons d'abord à hosts.conf, avec sa configuration par défaut.

Nous avons une définition de l'hôte icinga2 ci-dessous:

object Host NodeName {

import "generic-host"

address = "127.0.0.1"

address6 = "::1"

vars.os = "Linux"

vars.disks["disk /"] = {

disk_partitions = "/"

}

vars.notification["mail"] = {

groups = [ "icingaadmins" ]

}

Le bloc objet précédent définit un objet, qui est, l'hôte que nous voulons surveiller, avec des détails tels que le nom d’hôte (NodeName définit dans constants.conf), le groupe ou elle appartient l'hôte et l'adresse du serveur … .

La définition des groupes de machines, services… se fait dans le fichier groups.conf:

Exemple de groupes de services et hôtes :

Hosts

object HostGroup "linux-servers" {

display_name = "Linux Servers"

assign where host.vars.os == "Linux"

}

Services

object ServiceGroup "ping" {

display_name = "Ping Checks"

assign where match("ping*", service.name)

}

Dans notre cas ici nous avons un groupe d’hôtes linux servers et un autre groupe de service Ping.

Il existe plusieurs définitions de services qui sont placés sur un hôte. Chaque service

a une directive assign qui spécifie la commande de suivi de ce service dans notre cas ici Ping définie dans template.conf.

Les « Templates » sont utilisés pour appliquer un ensemble d’attributs identiques à

plusieurs objets. Les objets et les « Templates » peuvent hériter plusieurs attributs d’autres objets ou « Templates ». Si nécessaire, les attributs hérités peuvent être surchargés par les objets fils. Dans notre configuration, la définition localhost ,l’hôte hérite de l'objet modèle « generic-host » en utilisant la directive import .La template generic-hsot est défini dans templates.conf est utilisable pour chaque objet de HostGroup.

Exemple de modèle pour les hôtes:

template Host "generic-host" {

max_check_attempts = 3

check_interval = 1m

retry_interval = 30s

check_command = "hostalive"

}

Exemple de modèle pour les services:

template Service "generic-service" {

max_check_attempts = 5

check_interval = 1m

retry_interval = 30s

}

Serveurs Linux:

Nous allons ajouter l'objet hôte d'un exemple serveur linux au hostgroup Linux.

Avant de procédé la configuration et l’ajout de configuration de chaque service il est obligatoirement d’installer les paquets associés à nagios-plugins avec la commande yum install nagios-plugins sous les environnements Centos/RedHat/Fedora, environnement utilisé dans notre cas Centos.

object Host "ESXI-5.5" {

import "generic-host"

address = "10.1.1.211"

vars.os = "Linux"

}

Les contrôles de services communs pour les serveurs Linux incluent:

• Vérification de SSH (Secure Shell check)

• Vérification de la charge (load check)

• Vérification de disque (disk check)

......

SSH

Bien que la vérification de SSH soit un service public, il est important de mentionner ce contrôle de service ici parce que tous les vérifications via SSH comptent sur ce dernier, et c’est une bonne idée de placer une vérification (check de SSH) de lui-même.

apply Service "ssh" {

import "generic-service"

check_command = "ssh"

assign where host.address && host.vars.os == "Linux"

}

Ce contrôle de service serait de générer des alertes, qui nous remarquerons sur l'interface web, s'il y avait un problème à obtenir un accès SSH sur le serveur et par la suite. Tous les vérifications comptent sur elles aussi commencer à l'échec, va générer une alerte.

Load

Le plugin check_load est fourni dans le répertoire standard comme mentionné plus tôt. Il prend un avertissement et les valeurs des charges critiques et renvoie l'état de sortie correspondant pour la charge moyenne du système actuellement rapporté pour les 1, 5 et 15 dernières minutes. La définition de service est la suivante avec le plugin nrpe:

apply Service "nrpe-load" {

import "generic-service"

check_command = "nrpe"

vars.nrpe_command = "check_load"

assign where match("nrpe-*", host.name)

}

Cette vérification de service donnera :

• CRITIQUE pour des moyennes de plus de 2, 10,15 de charge

• AVERTISSEMENT pour des moyennes de plus de 1, 7,11 de charge

• OK pour les moyennes de moins de 1, 7,11 de charge

Desk

Le plugin check_disk est disponible dans le cadre des paquets standard des plugins de nagios. Il nous permet de mettre avertissement(WARNING) et critique (CRITICAL) des seuils pour l’espace disque libre, en termes de quantité spécifique d'espace disque ou de pourcentage.

apply Service "nrpe-disk" {

import "generic-service"

check_command = "nrpe"

vars.nrpe_command = "check_disk"

assign where match("nrpe-*", host.name)

}

Cela générerait:

• CRITIQUE pour moins de 10 pour cent de l'espace disque libre

• MISE EN GARDE pour moins de 20 pour cent de l'espace disque libre

• OK pour plus de 20 pour cent de l'espace disque libre

Serveurs Windows:

Ajoutons l'objet hôte d'un exemple de serveur de Windows à la fenêtre hostgroup.

object HostGroup "windows-servers" {

display_name = "Windows Servers"

assign where host.vars.os == "Windows"

}

De même, nous ajoutons la directive vars.os dans la définition de tous les hôtes de nos serveurs Windows.

object Host "Windows-srv-2008" {

import "generic-host"

address = "10.1.5.249"

vars.os = "Windows"

check_command = "hostalive"

}

NSClient++

Nous allons utiliser check_nrpe avec l'agent NSClient ++ pour surveiller les services privé sur les serveurs Windows, pour cela il faut qu’il soit bien installé et configurer sur le serveur en question. La définition d’un exemple commune est la suivante:

apply Service "RAM" {

import "generic-service"

check_command = "nscp"

vars.nscp_variable = "MEMUSE"

vars.nscp_password = "P@ssword"

assign where "windows-servers" in host.groups

}

La variable nscp_password est fourni lors de l’installation de l’agent NSClient++ (Annexe 1 : Installation NSClient++)

Les équipements réseaux:

Les agents SNMP sur les routeurs et les commutateurs, etc peuvent être utilisés pour surveiller les points de contrôle ou de services sur eux. La surveillance des périphériques réseau comprend la plupart du temps tout simplement le trafic réseau et les ports ouverts. Une large gamme de telles valeurs est disponible via SNMP et sont appelés les OID. Chaque identificateur d'objet (OID) a une valeur qui lui est associée comme ils sont décrits précédemment. Par exemple, l'OID sysUpTime.0 donne le temps de fonctionnement de l'appareil.

Le statut SNMP

Le démon SNMP fonctionne sur le système distant et répond aux requêtes SNMP par les binaires du plugin, il y a beaucoup de plugins existants pour des cas d'utilisation spécifiques déjà autour, par exemple la surveillance des routeurs Cisco.

L'exemple suivant utilise SNMP CheckCommand remplace tout simplement l'attribut personnalisé snmp_oid. Un service est créé pour tous les hôtes qui ont l'attribut personnalisé snmp-community.

apply Service "uptime" {

import "generic-service"

check_command = "snmp"

vars.snmp_oid = "1.3.6.1.2.1.1.3.0"

assign where host.vars.snmp_community != ""

}

Dans le code précédent, sysUpTime.0 (1.3.6.1.2.1.1.3.0) est un OID SNMP pour obtenir la valeur de disponibilité. Si cette vérification de service échoue, tous les autres contrôles de service reposant sur SNMP seront également commencer à échouer.

VMware:

Dans cette partie nous allons penser à la façon de recueillir effectivement l'information relative à la technologie de VMware sur tous leurs hyperviseurs niveau 1. VMware fournit quelques interfaces qui pourraient être utilisés pour nos besoins:

ICMP

ESXi et serveurs vCenter répond aux requêtes ICMP ECHO : requête/ réponse ICMP ECHO et la sont généralement connus comme « ping ».

Secure Shell

ESXi peuvent être configurés pour démarrer un serveur SSH sur le port 22 qui permettra la connexion de l'utilisateur root. Ceci peut être utilisé pour exécuter des commandes à distance sur l'ordinateur hôte et analyser leur sortie. La même chose est applicable pour les systèmes de vCenter Server qui se base sur Linux, ils permettent d'accéder via SSH, aussi.

vSphere API

L'API vSphere est une interface SOAP fournie par ESXi et vCenter Server. Il permet un accès programmatique à tous les objets vSphere, leurs états et la configuration. Le service écoute sur le port 443 et peut être consulté en utilisant l'un des SDKs fournis par VMware. Aux fins de la surveillance par Nagios /Icinga, le SDK pour Perl est très pratique.

SNMP

Le protocole de gestion de réseau simple (SNMP) est implémenté dans tous les hôtes ESXi. Alors que les hôtes ESXi peuvent être interrogés pour les données SNMP sur le port UDP 161 et être configuré pour envoyer des traps. Les serveurs vCenter peuvent envoyer seulement les traps.

Les serveurs ESXi prennent en charge une grande variété de MIBs permettant beaucoup d'informations à recueillir et à surveiller. Depuis la version 5.1, VMware prend en charge un total de 44 fichiers MIB qui peut être téléchargé à partir du site officiel www.vmware.com .

CIM

CIM (Common Information Model) définit une méthode standard pour accéder aux éléments dans un environnement informatique et les relations entre les composants. Créé par le DTMF (Distributed Management Task Force), CIM vise l'unification des normes en vigueur comme IPMI, SNMP, etc. ESXi exécutent le service sfcb qui écoute sur le port 5989 pour les connexions SSL. WSMAN (Web Service Management) clients peuvent se connecter, authentifier et demander des informations au système.