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.
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)
......
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.
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
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"
}
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 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:
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 ».
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.
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.
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 (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.
Tests de recette
La page principal d'icinga2 avec l'interface graphique icingaweb2:
Vue en résumé:
