Comment surveiller les hôtes et les services avec Icinga sur Ubuntu 16.04

introduction

Icinga est un système de surveillance open source utilisé pour surveiller la santé des hôtes et des services en réseau. Dans ce didacticiel, nous utiliserons Icinga pour configurer deux types de configuration de surveillance. La première repose sur de simples vérifications réseau des services externes de votre hôte, telles que l’envoi d’une requête HTTP périodique à votre site Web. L’autre configuration utilise un agent logiciel qui s’exécute sur l’hôte pour collecter des informations système plus détaillées telles que la charge et le nombre de processus en cours d’exécution.

Conditions préalables

Avant de commencer ce didacticiel, vous devez avoir achevé le didacticiel précédent de cette série, à l’adresse https://www.digitalocean.com/community/tutorials/how-to-install-icing-and-icing-web-on-ubuntu-16-. 04 [Comment installer Icinga et Icinga Web sur Ubuntu 16.04]. Cela vous laissera avec le noyau Icinga et l’interface Web Icinga s’exécutant sur un seul hôte, que nous appellerons le nœud * icinga-master * tout au long.

Vous aurez également besoin de serveurs à surveiller. Nous allons utiliser deux serveurs Ubuntu 16.04 avec Apache installé pour nos exemples. Vous pouvez utiliser uniquement la partie Apache de the LAMP tutoriel mentionné ci-dessus pour les configurer.

Étape 1 - Configuration de la surveillance d’hôte simple

Un moyen simple de surveiller un serveur avec Icinga consiste à configurer un contrôle régulier de ses services disponibles en externe. Donc, pour un hôte Web, nous envoyons régulièrement une requête à l’adresse IP du serveur et essayons également d’accéder à une page Web. Cela nous dira si l’hôte est actif et si le serveur Web fonctionne correctement.

Configurons la surveillance pour un serveur Web. Choisissez l’un des serveurs Apache mentionnés comme condition préalable et assurez-vous que la page d’espace réservé Apache par défaut est correctement utilisée. Nous appellerons ce serveur ++. Nous n’aurons pas besoin de nous y connecter du tout, tous les contrôles de santé seront configurés et exécutés sur le nœud maître.

Connectez-vous au noeud principal. Pour ajouter un nouvel hôte, nous devons éditer le fichier Icinga + hosts.conf. Ouvrez-le dans un éditeur de texte:

sudo nano /etc/icinga2/conf.d/hosts.conf

Cela ouvrira un fichier avec des commentaires explicatifs et un hôte unique défini block. Le bloc de configuration + object Host NodeName + existant définit l’hôte * icinga-master *, l’hôte sur lequel nous avons installé Icinga et Icinga Web. Positionnez votre curseur au bas du fichier et ajoutez un nouvel hôte:

/etc/icinga2/conf.d/hosts.conf

. . .
object Host "" {
 import "generic-host"
 address = ""
 vars.http_vhosts["http"] = {
   http_uri = "/"
 }
 vars.notification["mail"] = {
   groups = [ "icingaadmins" ]
 }
}

Ceci définit un hôte appelé «+», importe certaines configurations d’hôte par défaut à partir d’un modèle appelé ` generic-host `, pointe Icinga vers la bonne adresse IP, puis définit quelques variables qui indiquent à Icinga de rechercher une réponse HTTP à l’URL racine (` / `) et informez le groupe ` icingaadmins +` par e-mail lorsque des problèmes se produisent.

Enregistrez et fermez le fichier, puis redémarrez Icinga:

sudo systemctl restart icinga2

Revenez à l’interface Web Icinga dans votre navigateur. L’interface se met à jour assez rapidement, vous n’avez donc pas besoin d’actualiser la page. Les informations sur le nouvel hôte doivent être renseignées rapidement, et les contrôles de santé passeront de * En attente * à * Ok * une fois que Icinga aura réuni suffisamment d’informations.

C’est un excellent moyen de surveiller les services externes sur un hôte. D’autres contrôles sont également disponibles pour les serveurs SSH, SMTP, etc. Mais il serait également intéressant de connaître davantage de détails sur la santé interne des serveurs que nous surveillons.

Nous allons ensuite configurer la surveillance via un agent Icinga afin de pouvoir garder un œil sur les informations système plus détaillées.

Étape 2 - Configuration de la surveillance par agent

Icinga fournit un mécanisme permettant une communication sécurisée entre un nœud maître et un nœud client afin d’exécuter des contrôles d’intégrité à distance plus étendus. Plutôt que de savoir que notre serveur Web gère correctement les pages, nous pouvons également surveiller la charge du processeur, le nombre de processus, l’espace disque, etc.

Nous allons configurer un deuxième serveur à surveiller. Nous l’appellerons ++. Nous devons installer le logiciel Icinga sur la machine distante, exécuter des assistants de configuration pour établir la connexion, puis mettre à jour certains fichiers de configuration sur le nœud principal Icinga.

Configurer le nœud principal

Premièrement, nous devons configurer le nœud maître pour établir des connexions client. Nous faisons cela en exécutant le nœud setup wizard sur notre nœud maître:

sudo icinga2 node wizard

Cela créera un script qui nous posera quelques questions et nous organisera les choses. Dans ce qui suit, nous avons appuyé sur + ENTER + pour accepter la plupart des valeurs par défaut. Les réponses autres que celles par défaut sont mises en surbrillance. Certaines informations ont été supprimées pour plus de clarté:

OutputPlease specify if this is a satellite setup ('n' installs a master setup) [Y/n]:
Starting the Master setup routine...
Please specify the common name (CN) [icinga-master.example.com]:
Checking for existing certificates for common name 'icinga-master.example.com'...
Certificates not yet generated. Running 'api setup' now.
Enabling feature api. Make sure to restart Icinga 2 for these changes to take effect.
Please specify the API bind host/port (optional):
Bind Host []:
Bind Port []:
Done.

Now restart your Icinga 2 daemon to finish the installation!

Redémarrez Icinga pour terminer la mise à jour de la configuration:

sudo systemctl restart icinga2

Ouvrez un port de pare-feu pour autoriser les connexions externes à Icinga:

sudo ufw allow 5665

Nous allons maintenant basculer sur le poste client, installer Icinga et exécuter le même assistant.

Configurer le nœud client

Connectez-vous au serveur que nous appelons **. Nous devons réinstaller le référentiel Icinga, puis installer Icinga lui-même. C’est la même procédure que nous avons utilisée sur le nœud maître. Installez d’abord la clé:

curl -sSL https://packages.icinga.com/icinga.key | sudo apt-key add -

Ouvrez le fichier + icinga.list +:

sudo nano /etc/apt/sources.list.d/icinga.list

Coller dans les détails du référentiel:

/etc/apt/sources.list.d/icinga.list

deb https://packages.icinga.com/ubuntu icinga-xenial main

Enregistrez et fermez le fichier, puis mettez à jour le cache du paquet:

sudo apt-get update

Ensuite, installez + icinga2 +. Notez que nous n’avons pas besoin du paquet + icinga2-ido-mysql + que nous avons installé sur le noeud maître:

sudo apt-get install icinga2

Nous passons maintenant à travers l’assistant de nœud sur ce serveur, mais nous faisons un config satellite au lieu de master:

sudo icinga2 node wizard
OutputPlease specify if this is a satellite setup ('n' installs a master setup) [Y/n]:
Starting the Node setup routine...
Please specify the common name (CN) []:
Please specify the master endpoint(s) this node should connect to:
Master Common Name (CN from your master setup):
Do you want to establish a connection to the master from this node? [Y/n]:
Please fill out the master connection information:
Master endpoint host (Your master's IP address or FQDN):
Master endpoint port [5665]:
Add more master endpoints? [y/N]:
Please specify the master connection for CSR auto-signing (defaults to master endpoint host):
Host []:
Port [5665]:

L’assistant va maintenant récupérer le certificat public de notre nœud maître et nous montrer ses détails. Confirmez les informations, puis continuez:

Output. . .
Is this information correct? [y/N]:
information/cli: Received trusted master certificate.

Please specify the request ticket generated on your Icinga 2 master.
(Hint: # icinga2 pki ticket --cn ''):

À ce stade, revenez sur votre serveur + maître + et exécutez la commande que l’assistant vous a demandé. N’oubliez pas + sudo + devant lui:

sudo icinga2 pki ticket --cn ''

La commande affichera une clé. Copiez-le dans votre presse-papiers, puis revenez au nœud client, collez-le et appuyez sur + ENTER + pour continuer avec l’assistant.

Output. . .
information/cli: Requesting certificate with ticket ''.

Please specify the API bind host/port (optional):
Bind Host []:
Bind Port []:
Accept config from master? [y/N]:
Accept commands from master? [y/N]:
Done.

Now restart your Icinga 2 daemon to finish the installation!

Ouvrez maintenant le port Icinga sur votre pare-feu:

sudo ufw allow 5665

Et redémarrez Icinga pour mettre à jour complètement la configuration:

sudo systemctl restart icinga2

Vous pouvez vérifier qu’il existe une connexion entre les deux serveurs avec + netstat +:

netstat | grep :5665

Cela peut prendre un moment pour que la connexion soit établie. Finalement, + netstat + affichera une ligne indiquant une connexion + ESTABLISHED + sur le bon port.

Outputtcp        0      0 :     :5665     ESTABLISHED

Cela montre que nos serveurs sont connectés et que nous sommes prêts à configurer les contrôles client.

Configurer la surveillance de l’agent

Même si le maître et le client sont maintenant connectés, il reste encore une configuration à faire sur le maître pour permettre la surveillance. Nous devons créer un nouveau fichier hôte. Revenez au nœud maître.

Un concept important dans une installation Icinga est le concept de zone. Tous les nœuds client doivent créer leur propre zone et se rapporter à une zone parent, dans ce cas notre nœud maître. Par défaut, la zone de notre nœud maître est nommée d’après son nom de domaine complet. Nous allons créer un répertoire nommé d’après notre zone maîtresse dans le répertoire + zones.d + de Icinga. Cela contiendra les informations pour tous les clients de la zone maître.

Créez le répertoire de zone:

sudo mkdir /etc/icinga2/zones.d/

Nous allons créer un fichier de configuration des services. Cela définira certaines vérifications de service que nous effectuerons sur n’importe quel poste client distant. Ouvrez le fichier maintenant:

sudo nano /etc/icinga2/zones.d//services.conf

Collez les éléments suivants, puis enregistrez et fermez:

services.conf

apply Service "load" {
 import "generic-service"
 check_command = "load"
 command_endpoint = host.vars.client_endpoint
 assign where host.vars.client_endpoint
}

apply Service "procs" {
 import "generic-service"
 check_command = "procs"
 command_endpoint = host.vars.client_endpoint
 assign where host.vars.client_endpoint
}

Ceci définit deux contrôles de service. Le premier rendra compte de la charge du processeur et le second vérifiera le nombre de processus sur le serveur. Les deux dernières lignes de chaque définition de service sont importantes. + command_endpoint + indique à Icinga que cette vérification de service doit être envoyée à un noeud final de commande distant. La ligne + assign où + attribue automatiquement le contrôle de service à tout hôte pour lequel une variable + client_endpoint + est définie.

Créons un tel hôte maintenant. Ouvrez un nouveau fichier dans le répertoire de zone créé précédemment. Ici, nous avons nommé le fichier d’après l’hôte distant:

sudo nano /etc/icinga2/zones.d/web-2.example.com<^>.conf

Collez-le dans la configuration suivante, puis enregistrez et fermez le fichier:

web-2.exemple.com.conf

object Zone "" {
 endpoints = [ "" ]
 parent = ""
}

object Endpoint "" {
 host = ""
}

object Host "" {
 import "generic-host"
 address = ""
 vars.http_vhosts["http"] = {
   http_uri = "/"
 }
 vars.notification["mail"] = {
   groups = [ "icingaadmins" ]
 }
 vars.client_endpoint = name
}

Ce fichier définit une zone pour notre hôte distant et la lie à la zone parent. Il définit également l’hôte en tant que point de terminaison, puis définit l’hôte lui-même, en important certaines règles par défaut du modèle + generic-host +. Il définit également certains + vars + pour créer une vérification HTTP et activer les notifications par courrier électronique. Notez que, comme cet hôte a + vars.client_endpoint = name +, il sera également affecté aux contrôles de service que nous venons de définir dans + services.conf +.

Redémarrez Icinga pour mettre à jour la configuration:

sudo systemctl restart icinga2

Revenez à l’interface Web Icinga et le nouvel hôte s’affichera avec les vérifications * En attente *. Après quelques instants, ces vérifications devraient tourner * Ok *. Cela signifie que notre poste client exécute avec succès les contrôles du poste principal.

Conclusion

Dans ce didacticiel, nous avons défini deux types de surveillance avec Icinga, les contrôles de service externe et les contrôles d’hôte basés sur agent. Il reste encore beaucoup à apprendre sur la configuration et l’utilisation de Icinga. Vous voudrez donc vous plonger plus profondément dans la documentation détaillée de Icinga.

Notez que si vous avez besoin de commandes check personnalisées, vous devrez les synchroniser à partir du maître vers les nœuds clients à l’aide d’une global configuration zone. Vous pouvez en savoir plus sur cette fonctionnalité spécifique https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring#distributed-monitoring-global-zone-config-synchérhere].

Enfin, si vous devez surveiller un grand nombre de serveurs, vous pouvez utiliser un logiciel de gestion de la configuration pour automatiser les mises à jour de votre configuration Icinga. Notre série de didacticiels (dependre de la gestion de la configuration donne un aperçu complet des concepts et des logiciels impliqués.