Table des matières
Nagios est conçu pour permettre aux plugins de retourner des données de performance en plus des données normales de statut, ce qui vous permet ainsi de tranférer ces données de performances vers une application externe pour y être traitées. Une description des différents type de données de performance, ainsi que des informations sur la façon de traiter ces données sont décrites ci-dessous…
Il existe deux catégories de base de données de performance qui peuvent être obtenues à partir de Nagios:
Les données de performance relatives au contrôle
Les données de performance relatives au plugin
Les données de performance relatives à un contrôle sont des données internes relatives à l'exécution courante d'un contrôle de l'hôte ou du service. Cela peut comprendre des choses comme la latence d'un contrôle de service (par exemple combien de retard a un contrôle de service par rapport à l'horaire planifié d'exécution) et le nombre de secondes qu'il aura fallut pour exécuter un contrôle d'hôte ou des service. Ce type de données de performance sont valables pour tous les contrôles qui sont effectués. Les macros $HOSTEXECUTIONTIME$ et $SERVICEEXECUTIONTIME$ peuvent être utilisées pour determiner le nombre de secondes qu'aura duré un contrôle d'hôte ou de service et les macros $HOSTLATENCY$ et $SERVICELATENCY$ peuvent être utilisées afin de derterminer le "retard" que pourrait avoir un contrôle régulier d'un hôte ou d'un service.
Les données de performance d'un plugin sont des données spécifiques au plugin utilisé pour contrôler l'hôte ou le service. Les données spécifiques d'un plugin peuvent contenir des choses comme le pourcentage de paquets perdus, l'espace disque restant, la charge processeur, le nombre d'utilisateurs connectés, etc. - en fait, tout type de données que le plugin contrôle quand il est exécuté. Les données de performance spécifiques au plugin sont facultatives et ne sont pas forcement disponibles avec tous les plugins. Les données de performances spécifiques au plugin (si disponibles) peuvent être obtenues en utilisant les macros $HOSTPERFDATA$ et $SERVICEPERFDATA$. Lire la suite pour plus d'informations sur la façon dont les plugins peuvent retourner les données de performance à Nagios afin de les stocker dans les macros $HOSTPERFDATA$ and $SERVICEPERFDATA$.
Au minimum, les plugins Nagios doivent au moins retourner une simple ligne de texte compréhensible par l'utilisateur lambda qui indique l'état de certains types de données mesurables. Par exemple, le plugin check_ping pourrait retourner une ligne de texte comme celle qui suit:
PING ok - Packet loss = 0%, RTA = 0.80 ms
Avec ce simple type de sortie, la ligne entière est disponible dans les macros $HOSTOUTPUT$ ou $SERVICEOUTPUT$ (Cela dépend si le pllugin est utilisé pour le contrôle d'un hôte ou d'un service).
Les plugins peuvent renvoyer des données de performance dans leur message normal de sortie, un texte clair (lisible par l'homme) habituellement suivi du caractère 'pipe' (|), et d'une chaîne contenant une ou plusieurs données de performance. Prenons le plugin check_ping comme exemple et supposons qu'il a été configuré pour retourner le pourcentage de paquets perdus et la moyenne des aller-retour comme données de performance. Un exemple de sortie du plugin pourrait ressembler à ceci:
PING ok - Packet loss = 0%, RTA = 0.80 ms | percent_packet_loss=0, rta=0.80
Quand Nagios rencontre ce type de format pour le message de de sortie du plugin, il le scindera en deux parties:
Tout ce qui est situé avant le caratère 'pipe' ( | ) est considéré comme le message de sortie normal du plugin et sera alors stocké selon le cas dans les macros $HOSTOUTPUT$ ou $SERVICEOUTPUT$
Tout ce qui est situé après le caractère 'pipe' ( | ) est considéré comme étant les données de performance du plugin et seront stockées selon le cas dans les macros $HOSTPERFDATA$ ou $SERVICEPERFDATA$
Dans l'exemple ci-dessus, la macro $HOSTOUTPUT$ ou $SERVICEOUTPUT$ contiendra
PING ok - Packet loss = 0%, RTA = 0.80 ms
(sans les guillemets) et la macro $HOSTPERFDATA$ ou $SERVICEPERFDATA$ contiendra
percent_packet_loss=0, rta=0.80
(sans les guillemets).
Plusieurs lignes de données de performance (comme pour le texte normal de sortie) peuvent être transmises par les plugins, comme décrit dans la documentation sur les !! FIXME !! APIs des plugins .
Le démon Nagios ne traite pas directement les données de performance des plugins, du coup il ne sait pas vraiment à quoi elles ressemblent. Il n'y a pas vraiment de limites inhérentes au format ou au contenu des données de performance. Toutefois, si vous utilisez un module externe pour traiter les données de performance (par exemple PerfParse), le module attend que le plugin renvoie les données de performance dans un format spécifique. Vérifiez la documentation du module pour plus d'information.
Si vous voulez traiter les données de performance disponible dans Nagios au travers des plugins, vous devez configurer ce qui suit:
Activer l'option process_performance_data
Configurer Nagios pour que les données de performance soient écrites dans des fichiers et/ou traitées directement en exécutant des commandes.
Lire la suite pour plus d'informations sur la façon de traiter les données de performance en les écrivant des des fichiers ou en exécutant des commandes.
Le moyen le plus souple pour traiter les données de performance est de faire exécuter à Nagios des commandes (que vous avez spécifié) pour traiter ou rediriger les données pour un traitement ultérieur par des applications externes. Les commandes que Nagios exécute pour traiter les données de performances sont définies par les options host_perfdata_command et service_perfdata_command , respectivement.
Un exemple de définition de commande qui redirige les données de performance dans un fichier texte pour un traitement ultérieur par une autre application est montré ci-dessous:
define command{
command_name store-service-perfdata
command_line /bin/echo -e "$LASTSERVICECHECK$\t$HOSTNAME$\t$SERVICEDESC$\t$SERVICESTATE$\t$SERVICEATTEMPT$\t$SERVICESTATETYPE$\t$SERVICEEXECUTIONTIME$\t$SERVICELATENCY$\t$SERVICEOUTPUT$\t$SERVICEPERFDATA$" >> /usr/local/nagios/var/service-perfdata.dat
}
Cette méthode, bien que souple, est synonyme d'un niveau relativement élevé en terme de charge du CPU. Si vous traitez les données de performance d'un grand nombre de serveurs et de services, vous voudriez probablement que Nagios écrive les données de performance dans des fichiers à la place. Cette méthode est décrite dans la section suivante.
Vous pouvez faire en sorte que Nagios écrive toutes les données de performances des hôtes et des services directement dans un fichier texte en utilisant les options host_perfdata_file et service_perfdata_file . Le format dans lequel les données de performance des hôtes et des services seront écrites est défini dans les options host_perfdata_file_template et service_perfdata_file_template .
Un exemple de format de modèle pour les données de performance d'un service pourrait ressembler à ceci:
service_perfdata_file_template=[SERVICEPERFDATA]\t$TIMET$\t$HOSTNAME$\t$SERVICEDESC$\t$SERVICEEXECUTIONTIME$\t$SERVICELATENCY$\t$SERVICEOUTPUT$\t$SERVICEPERFDATA$
Par défaut, les fichiers texte seront ouverts en mode append. Si vous avez besoin de changer les modes en write ou non-blocking read/write (utile lors d'écriture via 'pipe'), vous pouvez utiliser les options host_perfdata_file_mode et service_perfdata_file_mode .
En outre, vous pouvez avoir Nagios qui exécute périodiquement des commandes traite périodiquement les fichiers de données de performance (par exemple à tour de rôle) en utilisant les options host_perfdata_file_processing_command et service_perfdata_file_processing_command . L'intervalle à laquelle ces commandes sont exécutées sont régies par les options host_perfdata_file_processing_interval et service_perfdata_file_processing_interval , respectivement.