Skip to main content

Esta versão do GitHub Enterprise Server foi descontinuada em 2024-03-26. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a última versão do GitHub Enterprise Server. Para obter ajuda com a atualização, entre em contato com o suporte do GitHub Enterprise.

Monitorar a integridade do cluster

Para garantir o desempenho e a redundância de um cluster do GitHub Enterprise Server, é possível monitorar a integridade dele.

Quem pode usar esse recurso?

A GitHub determina a qualificação para clustering e deve habilitar a configuração para a licença da instância. O clustering requer um planejamento cuidadoso e sobrecarga administrativa adicional. Para obter mais informações, confira "Sobre clustering".

Sobre a integridade de um cluster do GitHub Enterprise Server

Um cluster do GitHub Enterprise Server compreende diversos nós, com serviços redundantes distribuídos em dois ou mais deles. Quando um serviço individual ou um nó inteiro falha, os usuários não notam. As falhas afetam o desempenho e a redundância, por isso, é importante monitorar a integridade do cluster. É possível monitorar a integridade do cluster usando um utilitário de linha de comando ou uma ferramenta de monitoramento externo como o Nagios.

Verificar o status do cluster manualmente

O GitHub Enterprise Server tem um utilitário integrado de linha de comando para monitorar a integridade do cluster. No shell administrativo, a execução do comando ghe-cluster-status executa uma série de verificações de integridade em cada nó, incluindo verificação de conectividade e status do serviço. A saída mostra todos os resultados do teste, incluindo o texto ok ou error. Por exemplo, para exibir somente os testes com falha, execute:

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

Observação: se não houver nenhum teste com falha, esse comando não produzirá nenhuma saída. Nesse caso, a integridade do cluster terá sido preservada.

Monitorar o status do cluster com o Nagios

Configure o Nagios para monitorar o GitHub Enterprise Server. Além de monitorar a conectividade básica de cada um dos nós de cluster, você pode verificar o status do cluster configurando o Nagios para usar o comando ghe-cluster-status -n. Fazer isso gera uma saída em um formato que o Nagios consegue interpretar.

Pré-requisitos

  • Host Linux com Nagios;
  • Acesso de rede ao cluster do GitHub Enterprise Server.

Configurar o host do Nagios

  1. Gere uma chave SSH com a frase secreta em branco. O Nagios usa essa informação para fazer a autenticação ao cluster do 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.
    

    Aviso de segurança: uma chave SSH sem uma frase secreta pode representar um risco de segurança se autorizada para acesso total a um host. Limite o acesso desse tipo de chave a comandos de somente leitura.

Observação: se você estiver usando uma distribuição do Linux que não dê suporte ao algoritmo Ed25519, use o comando:

nagiosuser@nagios:~$ ssh-keygen -t rsa -b 4096
1. Copie a chave privada (`id_ed25519`) para a pasta base `nagios` e defina a propriedade apropriada.
nagiosuser@nagios:~$ sudo cp .ssh/id_ed25519 /var/lib/nagios/.ssh/
nagiosuser@nagios:~$ sudo chown nagios:nagios /var/lib/nagios/.ssh/id_ed25519
  1. Para autorizar a chave pública a executar apenas o comando ghe-cluster-status -n, use um prefixo command= no arquivo /data/user/common/authorized_keys. No shell administrativo de qualquer nó, modifique esse arquivo para incluir a chave pública gerada na etapa 1. Por exemplo: command="/usr/local/bin/ghe-cluster-status -n" ssh-ed25519 AAAA....

  2. Valide e copie a configuração de cada nó no cluster executando ghe-cluster-config-apply no nó em que você modificou o arquivo /data/user/common/authorized_keys.

    admin@ghe-data-node-0:~$ ghe-cluster-config-apply
    > Validating configuration
    > ...
    > Finished cluster configuration
    
  3. Para testar se o plugin do Nagios consegue executar o comando, execute-o de forma interativa no host do 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
    
  4. Crie uma definição de comando na sua configuração do Nagios.

    Definição de exemplo

    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
    }
    
  5. Adicione este comando a uma definição de serviço para um nó no cluster do GitHub Enterprise Server.

    Definição de exemplo

    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
           }
    

Depois de adicionar a definição ao Nagios, a verificação de serviço será executada conforme a sua configuração. Você deve conseguir ver o serviço recém-configurado na interface da web do Nagios.