Surveillance de l’intégrité de votre cluster

À propos de l’intégrité d’un cluster GitHub Enterprise Server

Un cluster GitHub Enterprise Server comprend plusieurs nœuds, avec des services redondants distribués sur plusieurs nœuds. Si un service individuel ou un nœud entier échoue, les utilisateurs ne doivent pas le remarquer. Les échecs affectent les performances et la redondance. Il est donc important de surveiller l’intégrité de votre cluster. Vous pouvez surveiller l’intégrité de votre cluster à l’aide d’un utilitaire de ligne de commande ou d’un outil de surveillance externe comme Nagios.

Vous pouvez également surveiller l’intégrité de nœuds individuels avec Node Eligibility Service. Pour plus d’informations, consultez « Surveillance de l’intégrité de vos nœuds de cluster avec Node Eligibility Service ».

Vérification manuelle de l’état d’un cluster

GitHub Enterprise Server intègre un utilitaire en ligne de commande qui permet de superviser l’intégrité d’un cluster. Dans l’interpréteur de commandes d’administration, l’exécution de la commande ghe-cluster-status déclenche une série de contrôles d’intégrité sur chaque nœud, avec notamment une vérification de la connectivité et de l’état du service. La sortie présente tous les résultats de test, dont le texte ok ou error. Par exemple, pour afficher uniquement les tests non concluants, exécutez :

admin@ghe-data-node-0:~$ ghe-cluster-status | grep error
> mysql-replication ghe-data-node-0: error Stopped
> mysql cluster: error

Surveillance du statut du cluster à l'aide de GitHub CLI

Vous pouvez utiliser l'extension gh es pour GitHub CLI pour vérifier le statut de votre cluster GitHub Enterprise Server. Pour plus d’informations, consultez la documentation sur l’utilisation de GH ES CLI et Administration de votre instance à l’aide de l’interface CLI GitHub.

Supervision de l’état d’un cluster avec Nagios

Vous pouvez configurer Nagios pour qu’il supervise GitHub Enterprise Server. En plus de superviser la connectivité de base de chaque nœud du cluster, vous pouvez vérifier l’état du cluster en configurant Nagios pour qu’il utilise la commande ghe-cluster-status -n. Elle retourne une sortie dans un format que comprend Nagios.

Prérequis

• Hôte Linux exécutant Nagios.
• Accès réseau au cluster GitHub Enterprise Server.

Configuration de l’hôte Nagios

1. Générez une clé SSH avec une phrase secrète vide. Nagios l’utilise pour s’authentifier auprès du cluster GitHub Enterprise Server.

   nagiosuser@nagios:~$ ssh-keygen -t ed25519
   > Generating public/private ed25519 key pair.
   > Enter file in which to save the key (/home/nagiosuser/.ssh/id_ed25519):
   > Enter passphrase (empty for no passphrase): LEAVE BLANK BY PRESSING ENTER
   > Enter same passphrase again: PRESS ENTER AGAIN
   > Your identification has been saved in /home/nagiosuser/.ssh/id_ed25519.
   > Your public key has been saved in /home/nagiosuser/.ssh/id_ed25519.pub.
   

   Caution

   Une clé SSH sans phrase secrète peut présenter un risque de sécurité si elle est autorisée à accéder pleinement à un hôte. Limitez l’autorisation de cette clé à une simple commande en lecture seule.

   Note

   Si vous utilisez une distribution de Linux qui ne prend pas en charge l’algorithme Ed25519, utilisez la commande :

   nagiosuser@nagios:~$ ssh-keygen -t rsa -b 4096
   

2. Copiez la clé privée (id_ed25519) dans le dossier de base de nagios et définissez la propriété appropriée.

   nagiosuser@nagios:~$ sudo cp .ssh/id_ed25519 /var/lib/nagios/.ssh/
   nagiosuser@nagios:~$ sudo chown nagios:nagios /var/lib/nagios/.ssh/id_ed25519
   

3. Pour autoriser la clé publique à exécuter uniquement la commande ghe-cluster-status -n, utilisez un préfixe command= dans le fichier /data/user/common/authorized_keys. À partir de l’interpréteur de commandes d’administration de n’importe quel nœud, modifiez ce fichier pour ajouter la clé publique générée à l’étape 1. Par exemple : command="/usr/local/bin/ghe-cluster-status -n" ssh-ed25519 AAAA....

4. Validez et copiez la configuration sur chaque nœud du cluster en exécutant ghe-cluster-config-apply sur le nœud où vous avez modifié le fichier /data/user/common/authorized_keys.

   admin@ghe-data-node-0:~$ ghe-cluster-config-apply
   > Validating configuration
   > ...
   > Finished cluster configuration
   

5. Pour vérifier que le plug-in Nagios peut bien exécuter la commande, exécutez-la de manière interactive à partir de l’hôte Nagios.

   nagiosuser@nagios:~$ /usr/lib/nagios/plugins/check_by_ssh -l admin -p 122 -H HOSTNAME -C "ghe-cluster-status -n" -t 30
   > OK - No errors detected
   

6. Créez une définition de commande dans votre configuration Nagios.

   Exemple de définition

   define command {
        command_name    check_ssh_ghe_cluster
        command_line    $USER1$/check_by_ssh -H $HOSTADDRESS$ -C "ghe-cluster-status -n" -l admin -p 122 -t 30
   }
   

7. Ajoutez cette commande à une définition de service pour un nœud du cluster GitHub Enterprise Server.

   Exemple de définition

   define host{
        use                     generic-host
        host_name               ghe-data-node-0
        alias                   ghe-data-node-0
        address                 10.11.17.180
        }
   
   define service{
          use                             generic-service
          host_name                       ghe-data-node-0
          service_description             GitHub Cluster Status
          check_command                   check_ssh_ghe_cluster
          }
   

Une fois que vous avez ajouté la définition à Nagios, la vérification du service s’exécute en fonction de votre configuration. Le service nouvellement configuré doit apparaître dans l’interface web Nagios.