Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.
All products
Administrateurs d’entreprise

Supervision de nœuds de cluster

Dans cet article

Un cluster GitHub Enterprise Server est composé de services redondants distribués sur deux nœuds ou plus. La défaillance d’un service individuel ou d’un nœud entier ne doit pas être immédiatement perceptible par les utilisateurs du cluster. Toutefois, dans la mesure où les performances et la redondance sont affectées, il est important d’effectuer un monitoring de l’intégrité d’un cluster GitHub Enterprise Server.

À propos de la surveillance de l’intégrité de votre cluster

La topologie de cluster pour GitHub Enterprise Server fournit une mise à l’échelle horizontale pour les entreprises comptant des dizaines de milliers de développeurs. GitHub recommande le clustering si un nœud principal unique subit régulièrement un épuisement des ressources. Le clustering nécessite une planification minutieuse et une surcharge administrative supplémentaire. Pour plus d’informations, consultez « À propos du clustering ».

Vous pouvez surveiller l’intégrité de l’ensemble de votre cluster GitHub Enterprise Server à l’aide d’un utilitaire de ligne de commande ou d’un outil de surveillance externe comme Nagios.

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

Remarque : En l’absence de tests non concluants, cette commande ne produit aucune sortie. Cela indique que le cluster est sain.

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.

    Avertissement de sécurité : Une clé SSH sans phrase secrète peut présenter un risque de sécurité si elle est autorisée pour un accès complet à 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
}

  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.