1.4 opsi-checks
1.4.2 opsi-check-plugin
Au niveau du serveur nagios il n’existe qu’un seul opsi-check-plugin qui fournit un large éventail de différents contrôles.
En fonction du nombre de fonctionnalités il y a aussi un grand nombre d’options de ligne de commande. Lister toutes ces options ne vous aidera pas trop. Au lieu de cela, l’option sera expliqué dans le contexte de la documentation des possibles contrôles.
Toutefois, pour obtenir une liste de toutes les options vous pouvez utilisercheck_opsiavec les paramètres--helpou -h.
Les options générales suivantes sont nécessaires pour chaque contrôle:
Table2: General Options
Option Description Exemple
-H,--host serveur opsi qui devrait exécuter le
contrôle
configserver.domain.local
-P,--port opsi webservice port 4447 (Default)
-u,--username opsi monitoring user monitoring
-p,--password opsi monitoring password monitoring123
-t,--task opsi check method (case sensitive)
Le chapitre suivant décrit comment appeler opsi-check-plugin en ligne de commande. Comment vous devez configurer ces appels à votre serveur Nagios est décrit au chapitreconfiguration.
Afin d’installer opsi-check-plugin sur votre serveur Nagios vous devez ajouter le dépôt OPSI sur votre serveur et installer le paquetopsi-nagios-plugins.
Par exemple, dans Debian ou Ubuntu avec les commandes suivantes:
apt-get install opsi-nagios-plugins
Sur RedHat/CentOS serveurs s’il vous plaît utilisez la commande suivante:
yum install opsi-nagios-plugins
Et enfin pour des installations openSUSE/SLES:
zypper install opsi-nagios-plugins
Le plugin en lui-même est écrit en python et devrait fonctionner sur n’importe quelle distribution.
Le paquet se base sur les paquetsnagios-plugins-basicetnagios-pluginset il installe le plugin dans/usr/lib/nagios/
plugins.
Selon la flexibilité de check_plugin il n’y a pas de configuration automatique.
Contrôle: opsi web service
Cette vérification surveille le processus opsi web service (opsiconfd). Cette vérification renvoie également les données de performance. Vous devez exécuter cette vérification sur chaque serveur OPSI parce que chaque serveur OPSI dispose d’un processus opsiconfd.
check_opsi.py -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiWebservice
Cette vérification renvoi normalement OK.
Vous obtiendrez d’autres valeurs de retour dans les situations suivantes:
– Critical:
– Si opsiconfd a des problèmes et ne peut pas répondre correctement.
– Si opsiconfd consomme plus de 80% de la cpu.
– Si vous avez un taux d’erreurs RPC de plus de 20%.
– Warning:
– Si opsiconfd consomme plus de 60% (mais moins de 80%) de la cpu.
– Si vous avez un taux d’erreurs RPC de plus de 10% mais moins de 20%
– Unknown:
Le service web OPSI n’a pas pu être atteint.
NOTICE: La valeur en pourcentage de la consommation cpu appartient toujours à une cpu parce que opsiconfd peut seulement utiliser une cpu. (Cela pourrait changer avec l’extension de multitraitement d’opsi)
Contrôle: opsi web service pnp4nagios template
Pour l’affichage des données de performance il y a un modèle pour pnp4nagios qui affiche les données d’une manière combinée.
Ici, n’est pas décrit comment installer pnp4nagios. Nous supposons que pnp4nagios est installé et configuré correcte-ment. La façon dont vous avez à utiliser pour configurer notre modèle peut différer de la façon ci-dessous décrite en fonction de votre installation pnp4nagios (qui peut utiliser un chemin différent).
Les modèles standard affichent pour toutes les données de performance un diagramme propre. Pour créer un affichage combiné vous devez passer aux étapes suivantes:
Étape 1:
créez dans /etc/pnp4nagios/check_commands un fichier nommé check_opsiwebservice.cfg et insérez le contenu suivant:
CUSTOM_TEMPLATE = 0
DATATYPE = ABSOLUTE,ABSOLUTE,ABSOLUTE,ABSOLUTE,DERIVE,GAUGE,GAUGE,GAUGE
Étape 2:
accédez au répertoire/usr/share/pnp4nagios/html/templateset placez dedans le fichiercheck_opsiwebservice.
phpque vous pouvez consulter à partir de svn.opsi.org:
cd /usr/share/pnp4nagios/html/templates
svn co https://svn.opsi.org/opsi-pnp4nagios-template/trunk/check_opsiwebservice.php
S’il vous plaît vérifiez que votre fichier php est nommé exactement comme le command_name qui est défini dans / etc/nagios3/conf.d/opsi/opsicommands.cfg. Si les noms ne correspondent pas, un modèle standard sera utilisé à la place de notre modèle combiné.
Après l’installation de ce modèle vous devez supprimer la bases de données RRD qui appartiennent à ce contrôle (s’il y a une existante). Vous trouverez ces bases de données dans/var/pnp4nagios/perfdata/<host>/ où vous devriez (seulement) supprimer les fichiersopsi-webservice.rrdetopsi-webservice.xml.
Si vous avez tout configuré correctement vous devriez maintenant pouvoir voir les diagrammes comme dans la capture d’écran ci-dessous.
Contrôle: opsi-check-diskusage
Ce contrôle surveille l’utilisation des ressources (répertoires) qui sont utilisées par OPSI. Le tableau suivant montre les noms des ressources et les répertoires correspondants:
Table3: ressources opsi
Resource name Path
/ /usr/share/opsiconfd/static
configed /usr/lib/configed
depot /opt/pcbin/install
repository /var/lib/opsi/repository
S’il vous plaît notez que ce contrôle surveille uniquement les données pertinentes d’opsi et remplace une vérification général de l’usage du disque pour le serveur.
La commande suivante extrait toutes les ressources en même temps:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDiskUsage
En plus de cette variante standard vous pouvez restreindre la vérification à la ressourcedepot:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDiskUsage -r depot
La valeur par défaut du résultat de cette vérification estOK et l’espace libre des ressources. L’espace libre est donnée en Gigabyte. Les valeurs par défaut pour les résultats deWarning etCritical sont:
– WARNING: Si au moins une ressource as 5GB ou moins d’espace libre.
– CRITICAL: Si au moins une ressource as 1GB ou moins d’espace libre.
Ce sont les seuils par défaut. Elles peuvent changer en donnant d’autres valeurs pour Warning avec les options -W ou --warning et pour Critical avec les options -C ou --critical. Avec ces options, vous pouvez indiquer les seuils en Gigabyte (G) et en pourcentage (%) ainsi. La sortie produite utilise la même unité qui est utilisé pour définir les seuils.
Enfin un exemple:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDiskUsage -r depot --warning\
10% --critical 5%
Contrôle: opsi-client-status
L’un des objectifs du connecteur OPSI Nagios est la surveillance du déploiement de logiciel par l’écoute des clients individuels. C’est l’un des contrôles, qui est conçu pour cet emploi. Plus exactement: les situations déploiement du logiciel etvu la dernière fois d’un certain client sont vérifiées.
Le résultat des contrôles suivants est déterminée par deux états différents:
– L’état de déploiement d’un ou plusieurs logiciels:
Le résultat de l’état du déploiement de logiciels peut être:
– OK si le logiciel est installé dans le même produit et version du paquet qui est disponible au niveau du serveur et aucune demande d’action est définie.
– Warning si le logiciel est installé dans une version qui est différente de la version serveurs ou si une demande d’action est définie.
– Critical s’il y a unéchecrapporté par la dernière action.
– Le temps écoulé depuisvu la dernière fois:
Le résultat du temps écoulé depuisvu la dernière fois peut être:
– OK si le client a été vu moins ou égale à 30 jours avant.
– Warning si le client a été vu plus de 30 jours avant.
Ce contrôle peut être utilisé avec différentes variantes, ici la plus simple, qui comprend tous les logiciels:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkClientStatus -c opsiclient.\
domain.local
Comme variante, il est possible d’exclure des produits de la vérification. par exemple:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkClientStatus -c opsiclient.\
domain.local -x firefox
Dans l’exemple ci-dessus le produit firefox a été exclu de la vérification. Donc, cette vérification ne passera pas à critique parce que la dernière action surfirefox a signalé une défaillance.
Contrôle: opsi-check-ProductStatus
Un autre objectif du connecteur OPSI Nagios est la surveillance du déploiement de logiciel par l’écoute de produit unique ou de groupe de produits.
Le résultat de ces contrôles est déterminé par les états suivants:
Le résultat de l’état du déploiement de logiciels peut être: * OK si le logiciel est installé dans le même produit et version du paquet qui est disponible au niveau du serveur et aucune demande d’action est définie. * Warning si le logiciel est installé dans une version qui est différente de la version serveurs ou si une demande d’action est définie. * Critical s’il y a unéchecrapporté par la dernière action.
Ces contrôles ont de nombreuses variantes et sont donc très souples. La meilleur façon d’expliquer ces variantes c’est avec des exemples.
La variante simple verifie un produit sur tous les clients. Il faut specifier le produit par son opsiproductId.
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkProductStatus -e firefox
Dans un environnement avec un seul serveur opsi, ce contrôle est tout ce dont vous avez besoin pour verifier l’état du produitfirefox sur tous les clients.
Vous sauriez combien de clients sont dans l’étatWarning etCritical.
Pour savoir quel client a effectivement des problémes, vous devez l’appeler en modalitéverbeuse:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkProductStatus -e firefox -v
Une autre variante vous permet d’exclure un client de la verification.
//// produkt muss angegebn werden ?! ////
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkProductStatus -e firefox -x \ client.domain.local
Dans un environnement opsi avec plusieurs serveurs de depot vous devez utiliser des options supplémentaires pour vérifier aussi les clients que ne sont pas assigné au depot du serveur de configuration. Si vous avez les dépôts multiple, vous pouvez passer le nom des dépôts comme parametres:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkProductStatus -e firefox -d \ depotserver.domain.local
La raison est que la version du paquet peut être différente entre vos depots. Donc la version de chaque client devra être vérifié à partir du depot qui lui est assignè. Un avantage est qu’il pourra placer l’affichage des résultats sur le serveur de depot.
Vous pouvez donner au lieu du nom du serveur de depot le mot clefallce qui signifie tous les serveurs de depot connus.
Mais cela normalement a seulement sens si vous avez un ou deux serveurs de depot. Vous pouvez aussi donner une liste de serveurs de depot sépare par une virgule.
Une autre façon de definir le contrôle est de donner le nom d’un ou plusieurs groups opsi. Ainsi vous pouvez verifier l’état du déploiement de logiciels pour tous les produits dans un group de produits opsi donné. Si vous avez par exemple un group de produitsaccounting vous pouvez utiliser l’appel suivant:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkProductStatus -g accounting
Maintenant vous pouvez vérifier tous les produits qui sont membre du group de produits opsi accounting avec ce simple contrôle. L’important est de voir, que la résolution du groupe OPSI se fait au moment du contrôle au niveau du serveur OPSI. De cette façon vous pouvez changer le group opsi dans l’interface web the gestion d’opsi et changer le produits à tester sans apporter de modification sur le serveur Nagios.
Note
Sub groups (groups in groups) will not be resolved.
De la même façon sera possible de définir les clients que vous voulez verifier en donnent le nom d’un groupe de clients opsi.
Un exemple pour un group de clientsproductiveclients:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkProductStatus -g accounting -G \ productiveclients
Ceci vérifiera tous les produits du groupe de produitsaccounting sur tous les clients du groupe de clients productive-clients.
Note
Sub groups (groups in groups) will not be resolved.
Note
Vous pouvez aussi donner une liste de groupes opsi separè par virgule.
Contrôle: opsi-check-depotsync
Si vous utilisez des dépôts multiple est importante de surveiller aussi la synchronicité. Même si vos dépôts ne son pas, pour des bonnes raison, complètement synchronisé ils devraient, autant que possible, l’être pour pallier au problèmes de déplacement d’un client depuis un depot vers un autre.
Ce contrôle surveille si vos depots sont synchronisé en fonction de l’ids des produits, des versions du produits et des versions du paquet.
Ce contrôle renvoi:
– OK
Si tout est sincronisè.
– Warning
S’il y a des difference.
Vous devez exécuter ce contrôle toujours sur un serveur de config parce que tous les données viennent du backend du serveur de config.
Ici quelques exemples.
La variante de base:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDepotSyncStatus
Cette variante de base est équivalente à l’appel suivant:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDepotSyncStatus -d all
Donc si vous ne donnez pas le depot à verifier, tous les depots connus seront vérifiés. Si vous avez beaucoup de depots, l’interprétation des résultats sera compliqué, donc ce sera une bonne idée de définir un ensemble de contrôles simples où les dépôts sont donnés comme liste séparé par virgule:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDepotSyncStatus -d \ configserver.domain.local,depotserver.domain.local
Avec ce contrôle vous comparez tous les produits qui sont installés sur les deux depots. Tous les produits installès seulement dans un depot seront ignoré et n’affectera pas le résultat.
Si vous voulez inclure des produits which qui ne sont pas installés dans tous les depots vérifiés, vous devez utiliser le commutateurstrictmode:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDepotSyncStatus -d \ configserver.domain.local,depotserver.domain.local --strictmode
Maintenant aussi les différences sur les produits manquants seront affichèes.
Si vous voulez exclure un produit de la verification (peut-être parce que ce produit doit être dans des versions différentes sur différents dépôts) vous devez utiliser l’option-x. Vous pouvez aussi utiliser une liste separè par virgule:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDepotSyncStatus -d \ configserver.domain.local,depotserver.domain.local --strictmode -x firefox,thunderbird
Ce contrôle ne vous averti pas si les produitsfirefox outhunderbird ne sont pas synchronisé.
Au lieu d’exclure des produits vous pouvez donner une liste explicite de produits à vérifier:
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDepotSyncStatus -d \ configserver.domain.local,depotserver.domain.local --strictmode -e firefox,thunderbird
Dans ce casseulementfirefox etthunderbird seront vérifié. Nous vous recommandons d’utiliser cette variantestric tmodedu contrôle pour voir si l’un des produits est manquante.
./check_opsi.py -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkOpsiDepotSync
Contrôle: contrôle nagios client plugin via opsiclientd
Cette vérification vous donne un moyen facile pour intégrer les contrôles qui collectent les données directement sur le client avec un minimum de travail de configuration.
Donc, ce contrôle demande à opsiclientd qui est en cours d’exécution au niveau du client opsi d’exécuter une commande, récupérer la sortie et de la renvoyer.
Cette extension n’est pas destiné à être un remplacement complet d’un agent Windows Nagios avec toutes ces fonc-tionnalité . C’est seulement une alternative légère.
Les plugins que opsiclientd peut appeler doivent être compatibles avec laNagios plug-in development guidelines.
(More details at:http://nagiosplug.sourceforge.net/developer-guidelines.html).
Afin d’exécuter un tel plugin sur le client, il doit être installé sur le client. La solution du problème est de le déployer comme un paquet opsi. Le chemin dans lequel le plugin est installé chez le client n’a pas d’importance parce que vous devez donner le chemin complet à la définition du contrôle. Nous recommandons d’installer tous les plugins dans un répertoire pour faciliter l’entretien des plugins sur le client.
Pour des raisons de sécurité, vous devriez faire en sorte que les utilisateurs non privilégiés n’ont pas accès en écriture à des plugins, parce qu’ils seront exécutés à partir de opsiclientd avec des privilègessystème.
Il ya beaucoup de plugins prêts à l’emploi sur Internet. Une adresse à regarder est:
http://exchange.nagios.org/
Dans ce qui suit, nous supposons que vos plugins sont installés dans C:\opsi.org\nagiosplugins\et nous y trou-verons le plugincheck_win_disk.exesorti de son paquet nagioscol depuis
http://sourceforge.net/projects/nagiosplugincol/
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkPluginOnClient --plugin "C:\\\
opsi.org\\nagiosplugincol\\check_win_disk.exe C:" -c client.domain.local
Cet appel contrôle le clientclient.domain.local. Au niveau du client le plugincheck_win_disk.exeest appelé avec le paramètre C:. Cela signifie que le disque dur avec la lettreC doit être vérifiée. La sortie et la valeur du résultat du plugin seront récupérées par opsiclientd et seront donnée au serveur Nagios (via le serveur OPSI) dans un format correct pour Nagios.
Une autre caractéristique spéciale est de garder les résultats de la dernière vérification, même si le client n’est pas joignable.
Cette fonctionnalité a été mis en œuvre selon le fait que les clients ne sont pas toujours en cours d’exécution comme les serveurs, mais le plus de temps dans leur vie sont généralement éteint. Normalement Nagios montrera pour les clients éteints le résultatInconnu. En fait le plus de problèmes sur les clients surveillés ne vont pas disparaître simplement en les éteignant et en les allumant à nouveau. Ainsi, les informations que le client avait un problème avant qu’il ne soit éteints peuvent être des informations essentielles pour l’administrateur système. (Vous pouvez essayer de résoudre ce problème en utilisant Timeperiodsà la configuration de Nagios, mais nous pensons que ce n’est pas assez souple et conduit à un travail de configuration permanente). Donc, cette extension OPSI vous donne la possibilité de renvoier les derniers résultats de contrôle réels, si le client n’est pas joignable en ce moment.
Pour utiliser cette fonctionnalité, vous devez utiliser les macros Nagios $SERVICESTATEID$ et $SERVICEOUTPUT$.
$SERVICESTATEID$donne le dernier résultat et devrait être passé à l’option-s.$SERVICEOUTPUT$donne la dernière ligne de sortie et devrait être passé à l’option-o. Ainsi le contrôle peut donner ces dernières valeurs au lieu deInconnu si le client n’est pas joignable.
check_opsi -H configserver.domain.local -P 4447 -u monitoring -p monitoring123 -t checkPluginOnClient --plugin "C:\\\
opsi.org\\nagiosplugincol\\check_win_disk.exe C:" -c client.domain.local -s $SERVICESTATEID$ -o $SERVICEOUTPUT$