serveur_hebergement:icinga:modifier_un_service_sur_icinga2

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision		 Révision précédente
serveur_hebergement:icinga:modifier_un_service_sur_icinga2 [2022/07/17 16:42] – [Créer un service] fateserveur_hebergement:icinga:modifier_un_service_sur_icinga2 [2023/08/08 14:00] (Version actuelle) – modification externe 127.0.0.1
Ligne 13: Ligne 13:
 Ce répertoire est uniquement présent sur le serveur maître. Ce répertoire est uniquement présent sur le serveur maître.
  
-Les fichiers que vous serez amené à modifier sont sont hosts.conf, services.conf, commands.conf et templates.conf. On va voir à quoi servent ces fichiers et comment ils interagissent les uns avec les autres. +Les fichiers que vous serez amené à modifier sont hosts.conf, services.conf, commands.conf et templates.conf. On va voir à quoi servent ces fichiers et comment ils interagissent les uns avec les autres. 
-  * services.conf : liste tous les services. Pour chaque service il faut indiquer quel template, défini dans le fichier templates.conf, utiliser et quelle commande, définie dans commands.conf, lancer pour tester ce service. On indique également une condition (exemple : telle variable doit avoir telle valeur) qui devra être vraie pour que le service soit actif sur tel ou tel host. Comprendre par « host » les serveurs que vous souhaitez surveiller. La valeur de la variable utilisé pour cette condition sera définie dans le fichier hosts.conf. Le but de cette condition, qui est obligatoire, est de pouvoir limiter l’activation de certains services sur des hosts spécifiques uniquement. Par exemple, si on créé un service pour tester que le protocole smtp soit actif, ça n’a aucun sens de le tester sur les hosts n’ayant pas de serveur mail. Ce fichier se trouve dans le répertoire zones.d/master.+  * services.conf : liste tous les services. Pour chaque service il faut indiquer quel template, défini dans le fichier templates.conf, utiliser et quelle commande, définie dans commands.conf, lancer pour tester ce service. On indique également une condition (exemple : telle variable doit avoir telle valeur) qui devra être vraie pour que le service soit actif sur tel ou tel host. Comprendre par « host » les serveurs que vous souhaitez surveiller. La valeur de la variable utilisée pour cette condition sera définie dans le fichier hosts.conf. Le but de cette condition, qui est obligatoire, est de pouvoir limiter l’activation de certains services sur des hosts spécifiques uniquement. Par exemple, si on crée un service pour tester que le protocole smtp soit actif, ça n’a aucun sens de le tester sur les hosts n’ayant pas de serveur mail. Ce fichier se trouve dans le répertoire zones.d/master.
   * hosts.conf : ce fichier liste votre ou vos hosts. A l’intérieur de chaque host est indiqué des services à tester spécifiques à ce host ou la valeur de variables de condition servant à activer certains services. Il sert également à pouvoir modifier des arguments de tests services. Par exemple, le service check_ssh va tester que le SSH est actif et va tester par défaut le port 22. Si vous utiliser un autre port, vous pouvez l’indiquer dans le fichier hosts.conf et ce pour chaque host. Ce fichier se trouve dans le répertoire zones.d/master.   * hosts.conf : ce fichier liste votre ou vos hosts. A l’intérieur de chaque host est indiqué des services à tester spécifiques à ce host ou la valeur de variables de condition servant à activer certains services. Il sert également à pouvoir modifier des arguments de tests services. Par exemple, le service check_ssh va tester que le SSH est actif et va tester par défaut le port 22. Si vous utiliser un autre port, vous pouvez l’indiquer dans le fichier hosts.conf et ce pour chaque host. Ce fichier se trouve dans le répertoire zones.d/master.
-  * templates.conf : comme son nom l’indique, ce fichier regroupe les templates, c’est à dire les configurations par défaut (temps entre chaque test, nombre d’essai en cas d’échec, etc), pour chaque type : test sur le serveur (tester s’il est accessible ou non), test des services (http, test de charge serveur, espace libre disque, etc), notification mail, etc. Ce fichier est dans le répertoire conf.d.+  * templates.conf : comme son nom l’indique, ce fichier regroupe les templates, c’est-à-dire les configurations par défaut (temps entre chaque test, nombre d’essais en cas d’échec, etc), pour chaque type : test sur le serveur (tester s’il est accessible ou non), test des services (http, test de charge serveur, espace libre disque, etc), notification mail, etc. Ce fichier est dans le répertoire conf.d.
   * commandes.conf : permet de configurer les commandes à lancer pour réaliser les tests ou les notifications. Ce fichier est dans le répertoire conf.d.   * commandes.conf : permet de configurer les commandes à lancer pour réaliser les tests ou les notifications. Ce fichier est dans le répertoire conf.d.
  
Ligne 22: Ligne 22:
 <code>/usr/lib/nagios/plugins</code>  <code>/usr/lib/nagios/plugins</code> 
  
-Ces plugins sont configurés via les fichier +Ces plugins sont configurés via les fichiers 
 <code>/usr/share/icinga2/include/command-plugins.conf</code>  <code>/usr/share/icinga2/include/command-plugins.conf</code> 
 ainsi que les fichiers de configuration présents dans le répertoire  ainsi que les fichiers de configuration présents dans le répertoire 
Ligne 31: Ligne 31:
 ==== Modifier un service : modifier le port SSH ==== ==== Modifier un service : modifier le port SSH ====
  
-Comme j’ai indiqué précédemment, il est possible de modifier les arguments de tests existant, comme le numéro de port, l’adresse ip, le répertoire à tester, etc…+Comme j’ai indiqué précédemment, il est possible de modifier les arguments de tests existant, comme le numéro de port, l’adresse IP, le répertoire à tester, etc.
 On va prendre comme exemple le port SSH à utiliser, une modification que la plupart des gens devront faire. Comme il est fortement déconseillé d’utiliser le port par défaut, il y a de forte chance que le port 22 ne corresponde pas à votre port SSH. On va prendre comme exemple le port SSH à utiliser, une modification que la plupart des gens devront faire. Comme il est fortement déconseillé d’utiliser le port par défaut, il y a de forte chance que le port 22 ne corresponde pas à votre port SSH.
  
 Tout d’abord, il nous faut vérifier que le test du SSH, activé par défaut sur Icinga2, permette de modifier le port. Pour ça, lancez la commande suivante : Tout d’abord, il nous faut vérifier que le test du SSH, activé par défaut sur Icinga2, permette de modifier le port. Pour ça, lancez la commande suivante :
-icinga2 object list --name ssh --type checkcommand.+<code>icinga2 object list --name ssh --type checkcommand</code>.
  
 La commande icinga2 object list affiche tous les objets actifs. Qu’est-ce qu’un objet ? C’est un service (le test du SSH par exemple) ou une commande (la commande à lancer pour tester le SSH par exemple). La commande icinga2 object list affiche tous les objets actifs. Qu’est-ce qu’un objet ? C’est un service (le test du SSH par exemple) ou une commande (la commande à lancer pour tester le SSH par exemple).
Ligne 83: Ligne 83:
 === Tester un protocole === === Tester un protocole ===
  
-Quand on créé un service on doit ajouter une condition qui activera ce service si elle est vraie+Quand on crée un service on doit ajouter une condition qui activera ce service si elle est vraie
  
 Le premier truc à faire, c’est d’identifier quel plugin nous allons utiliser pour notre test. Pour l’exemple, on va choisir le protocole ftp. Parmi tous les plugins, le plugin check_ftp, sert à tester la connexion au serveur ftp. Le premier truc à faire, c’est d’identifier quel plugin nous allons utiliser pour notre test. Pour l’exemple, on va choisir le protocole ftp. Parmi tous les plugins, le plugin check_ftp, sert à tester la connexion au serveur ftp.
Ligne 94: Ligne 94:
  
 Que nous dit cette aide : Que nous dit cette aide :
-  * l’argument -H permet d’indiquer à quelle adresse ip se connecter.+  * l’argument -H permet d’indiquer à quelle adresse IP se connecter.
   * l’argument -p permet d’indiquer quel port utiliser. Il y a peu de chance que vous utilisiez un port différent de celui par défaut pour le serveur ftp. Nous n’aurons donc pas besoin de cet argument   * l’argument -p permet d’indiquer quel port utiliser. Il y a peu de chance que vous utilisiez un port différent de celui par défaut pour le serveur ftp. Nous n’aurons donc pas besoin de cet argument
   * les arguments -w et -c permettent d’indiquer à partir de quel temps de réponse déclencher, respectivement, un avertissement et une alerte. Comme je souhaite juste un test binaire, le serveur ftp répond/ne répond pas, nous ne les utiliserons pas.   * les arguments -w et -c permettent d’indiquer à partir de quel temps de réponse déclencher, respectivement, un avertissement et une alerte. Comme je souhaite juste un test binaire, le serveur ftp répond/ne répond pas, nous ne les utiliserons pas.
Ligne 128: Ligne 128:
 La commande étant créée, on va pouvoir créer le service. Il y a plusieurs manières de créer un service. En voici une. La commande étant créée, on va pouvoir créer le service. Il y a plusieurs manières de créer un service. En voici une.
 Ouvrez le fichier services.conf. Rajoutez les lignes suivantes à la fin du fichier Ouvrez le fichier services.conf. Rajoutez les lignes suivantes à la fin du fichier
-<code>+<code bash>
 apply Service "protocole_ftp" { apply Service "protocole_ftp" {
   import "generic-service"   import "generic-service"
Ligne 140: Ligne 140:
 Expliquons de nouveau ces lignes : Expliquons de nouveau ces lignes :
   * apply Service "protocole_ftp" { : indique que vous allez créer un service qui s’appelle “protocole_ftp” (vous pouvez modifier le nom).   * apply Service "protocole_ftp" { : indique que vous allez créer un service qui s’appelle “protocole_ftp” (vous pouvez modifier le nom).
-  * import "generic-service" : on importe le template des services, qui se trouve dans le fichier templates.conf. Pour rappel, ce template sert à avoir des valeur par défaut pour le délai entre chaque test,  le nombre d’essai en cas d’échec, etc.+  * import "generic-service" : on importe le template des services, qui se trouve dans le fichier templates.conf. Pour rappel, ce template sert à avoir des valeurs par défaut pour le délai entre chaque test,  le nombre d’essai en cas d’échec, etc.
   * check_command = "check_ftp" : indique quelle commande on va utiliser pour tester ce service. Le nom de la commande doit être le même que dans le fichier commands.conf.   * check_command = "check_ftp" : indique quelle commande on va utiliser pour tester ce service. Le nom de la commande doit être le même que dans le fichier commands.conf.
   * vars.ftp_host = host.address : on attribue à la variable “ftp_host” la valeur host.adress qui correspond à l’adresse ip du host définie dans le fichier hosts.conf. Comme ftp_host est la valeur que prendra l’argument “-H”, on se retrouvera bien avec “-H adresseipduhost”.   * vars.ftp_host = host.address : on attribue à la variable “ftp_host” la valeur host.adress qui correspond à l’adresse ip du host définie dans le fichier hosts.conf. Comme ftp_host est la valeur que prendra l’argument “-H”, on se retrouvera bien avec “-H adresseipduhost”.
-  * command_endpoint = host.vars.endpoint : indique que la commande devra être lancée sur le host (client ou maître) correspondant au conditions du "assign" et non pas en local sur le serveur maître (utile uniquement en multiserveur).+  * command_endpoint = host.vars.endpoint : indique que la commande devra être lancée sur le host (client ou maître) correspondant aux conditions du "assign" et non pas en local sur le serveur maître (utile uniquement en multiserveur).
   * assign where host.address : indique la condition qui doit être présente sur le host pour que le service soit actif. Là on a indiqué que si une adresse ip est spécifiée dans le host, cela rendra le service actif. Comme les hosts ont forcément une adresse ip spécifiée, ce service s’appliquera bien à notre host. Cette ligne est obligatoire.   * assign where host.address : indique la condition qui doit être présente sur le host pour que le service soit actif. Là on a indiqué que si une adresse ip est spécifiée dans le host, cela rendra le service actif. Comme les hosts ont forcément une adresse ip spécifiée, ce service s’appliquera bien à notre host. Cette ligne est obligatoire.
  
-Petit parenthèse sur les conditions. Il est possible de mettre d’autres condition que celle-là. On pourrait par exemple remplacer cette ligne par +Petite parenthèse sur les conditions. Il est possible de mettre d’autres conditions que celle-là. On pourrait par exemple remplacer cette ligne par 
 <code>assign where host.vars.serveurFTP == true</code> <code>assign where host.vars.serveurFTP == true</code>
 Dans ce cas, ce service ne sera actif que si la variable serveurFTP, qui sera déclarée dans le fichier hosts.conf, est vraie. Dans ce cas, ce service ne sera actif que si la variable serveurFTP, qui sera déclarée dans le fichier hosts.conf, est vraie.
Ligne 171: Ligne 171:
 <code>vars += config</code> <code>vars += config</code>
  
-La première ligne signifie que ce service sera activé dans le fichier hosts.conf grâce à la variable protocole_ftp.  Elle remplace la ligne “assign where” qui a disparue.+La première ligne signifie que ce service sera activé dans le fichier hosts.conf grâce à la variable protocole_ftp.  Elle remplace la ligne “assign where” qui a disparu.
  
 La seconde signifie qu’au lieu de renseigner la valeur des variables, créées dans le fichier commands.conf, dans le fichier services.conf lors de la création du service, on va les renseigner directement dans le fichier hosts.conf. La seconde signifie qu’au lieu de renseigner la valeur des variables, créées dans le fichier commands.conf, dans le fichier services.conf lors de la création du service, on va les renseigner directement dans le fichier hosts.conf.
Ligne 182: Ligne 182:
  
 Avec la méthode vu précédemment, il vous faudrait créer 3 services dans le fichier services.conf, avec pour chacun une valeur différente pour la variable “ftp_port”. Avec la méthode vu précédemment, il vous faudrait créer 3 services dans le fichier services.conf, avec pour chacun une valeur différente pour la variable “ftp_port”.
-Avec cette nouvelle méthode, vous aller indiquer dans le fichier hosts.conf la valeur que prendra chaque variable déclarée dans la commande du test. Dans notre cas il nous faudra renseigner la valeur des variables “ftp_port” et “ftp_host”. +Avec cette nouvelle méthode, vous allez indiquer dans le fichier hosts.conf la valeur que prendra chaque variable déclarée dans la commande du test. Dans notre cas il nous faudra renseigner la valeur des variables “ftp_port” et “ftp_host”. 
-Pour ce faire, il suffit de rajouter dans le fichier hosts.conf les ligne suivante dans la configuration de chaque host pour lesquels vous souhaitez activez ce service (note : il faut forcément que les valeurs des variables soient entres des guillemets)+Pour ce faire, il suffit de rajouter dans le fichier hosts.conf les ligne suivante dans la configuration de chaque host pour lesquels vous souhaitez activer ce service (note : il faut forcément que les valeurs des variables soient entre des guillemets)
 <code> <code>
 vars.protocole_ftp["ftp1"] = { vars.protocole_ftp["ftp1"] = {
Ligne 199: Ligne 199:
 </code> </code>
  
-Pour info, il est tout à fait possible de déclarer les valeurs des variables à la fois dans services.conf et dans hosts.conf. Reprenons notre exemple avec deux variables, une pour le port et une autre pour l’adresse ip. L’adresse ip est déjà déclarée dans le fichier hosts.conf. Le mieux à faire dans ce cas est donc de déclarer la valeur de la variable “ftp_host” dans le services.conf avec la ligne +Pour info, il est tout à fait possible de déclarer les valeurs des variables à la fois dans services.conf et dans hosts.conf. Reprenons notre exemple avec deux variables, une pour le port et une autre pour l’adresse ip. L’adresse ip est déjà déclarée dans le fichier hosts.conf. Le mieux à faire dans ce cas est donc de déclarer la valeur de la variable “ftp_host” dans le fichier services.conf avec la ligne 
 <code>vars.ftp_host = host.address</code>  <code>vars.ftp_host = host.address</code> 
 et de ne déclarer que la valeur de la variable “ftp_port” dans hosts.conf car elle sera propre à chaque serveur ftp. et de ne déclarer que la valeur de la variable “ftp_port” dans hosts.conf car elle sera propre à chaque serveur ftp.
Ligne 207: Ligne 207:
 === Tester un processus === === Tester un processus ===
  
-Comme vous devez vous en douter, le principe va rester globalement le même que pour tester un protocole. Commençons par le plugin à utiliser. On va utiliser le plugin “check_procs”. Affichez l'aide ce plugins <code bash>/usr/lib/nagios/plugins/check_procs -h</code>+Comme vous devez vous en douter, le principe va rester globalement le même que pour tester un protocole. Commençons par le plugin à utiliser. On va utiliser le plugin “check_procs”. Affichez l'aide ce plugin <code bash>/usr/lib/nagios/plugins/check_procs -h</code>
 <code> <code>
 Utilisation: Utilisation:
Ligne 242: Ligne 242:
  
 J’ai appelé la commande “check_processus”. Cette commande va exécuter le plugin “check_procs” avec “sudo” et on va utiliser 2 arguments : J’ai appelé la commande “check_processus”. Cette commande va exécuter le plugin “check_procs” avec “sudo” et on va utiliser 2 arguments :
-  * “-c” qui prendra la valeur de la variable “critical_arg”. Cette valeur indique combien de processus doivent être en cours d’exécution. Cette valeur doit être exprimée sous forme de limite “min:max”. Imaginons que vous vouliez vérifier l’application “toto” et que cette application est lancée 3 fois. Cette valeur devra donc plus tard être déclaré comme suit : “3:3”. Dés qu’Icinga2 trouvera moins ou plus de 3 processus nommés toto, il déclenchera une alarme. Si le nombre d’application lancé est variable, disons entre 3 et 6, vous pourrez déclarer comme valeur “3:6” quand vous créerez le service. La plupart des processus ne se lançant qu’une fois, la valeur que vous mettrez le plus souvent sera “1:1”.+  * “-c” qui prendra la valeur de la variable “critical_arg”. Cette valeur indique combien de processus doivent être en cours d’exécution. Cette valeur doit être exprimée sous forme de limite “min:max”. Imaginons que vous vouliez vérifier l’application “toto” et que cette application est lancée 3 fois. Cette valeur devra donc plus tard être déclarée comme suit : “3:3”. Dès qu’Icinga2 trouvera moins ou plus de 3 processus nommés toto, il déclenchera une alarme. Si le nombre d’application lancé est variable, disons entre 3 et 6, vous pourrez déclarer comme valeur “3:6” quand vous créerez le service. La plupart des processus ne se lançant qu’une fois, la valeur que vous mettrez le plus souvent sera “1:1”.
   * “-C” qui prendra la valeur de la variable “name_processus”. Cette valeur devra correspondre au nom du processus.   * “-C” qui prendra la valeur de la variable “name_processus”. Cette valeur devra correspondre au nom du processus.
  
-Je n’utilise pas l’argument “-w” car il n’y a pas d’intérêt à avoir des avertissement pour ce genre de test. A part cas très particulier.+Je n’utilise pas l’argument “-w” car il n’y a pas d’intérêt à avoir des avertissements pour ce genre de test. A part cas très particulier.
  
 Cette commande servira pour tous les tests de processus. Passons maintenant à la création du service.  Cette commande servira pour tous les tests de processus. Passons maintenant à la création du service. 
Ligne 261: Ligne 261:
 </code> </code>
  
-Si vous le souhaitez vous pouvez utiliser la méthode vu au chapitre précédent pour créer un seul service générique et renseigner la variable “name_processus et “critical_arg” dans hosts.conf en appelant plusieurs fois le service. Pour ma part j’ai préféré créé plusieurs services car je trouve que c’est plus clair d’avoir un service = une application.+Si vous le souhaitez vous pouvez utiliser la méthode vue au chapitre précédent pour créer un seul service générique et renseigner la variable “name_processus et “critical_arg” dans hosts.conf en appelant plusieurs fois le service. Pour ma part j’ai préféré créer plusieurs services car je trouve que c’est plus clair d’avoir un service = une application.
  
  • serveur_hebergement/icinga/modifier_un_service_sur_icinga2.1658076128.txt.gz
  • Dernière modification : 2023/08/08 14:01
  • (modification externe)