Surveillance de la santé de votre cluster

À propos de l’état de santé GitHub Enterprise Server du cluster

Un GitHub Enterprise Server cluster comprend plusieurs nœuds, avec des services redondants répartis sur deux nœuds ou plus. 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’état de chaque nœud à l’aide de Node Eligibility Service. Pour plus d’informations, consultez « Suivi de l'état de santé des nœuds de votre cluster avec le service d'éligibilité des nœuds ».

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

GitHub Enterprise Server dispose d’un utilitaire de ligne de commande intégré pour surveiller l’intégrité du 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 de l’état du cluster à l’aide de GitHub CLI

Vous pouvez utiliser l’extension gh es pour GitHub CLI afin de vérifier l’état 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 surveiller 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 GitHub Enterprise Server cluster.

Configuration de l’hôte Nagios

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

   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.
   

   Attention

   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.

   Remarque

   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
}

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

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.