Skip to main content

Мониторинг работоспособности кластера

Чтобы обеспечить производительность и избыточность кластера GitHub Enterprise Server можно отслеживать работоспособность кластера.

Кто может использовать эту функцию?

GitHub определяет право на кластеризация и должен включить конфигурацию лицензии вашего экземпляра. Кластеризация требует тщательного планирования и дополнительных административных накладных расходов. Дополнительные сведения см. в разделе Сведения о кластеризации.

Сведения о работоспособности кластера GitHub Enterprise Server

Кластер GitHub Enterprise Server состоит из нескольких узлов с избыточными службами, распределенными между двумя или более узлами. Если сбой отдельной службы или всего узла, пользователи не должны заметить. Сбои влияют на производительность и избыточность, поэтому важно отслеживать работоспособность кластера. Вы можете отслеживать работоспособность кластера с помощью служебной программы командной строки или внешнего средства мониторинга, например Nagios.

Вы также можете отслеживать работоспособность отдельных узлов с помощью Node Eligibility Service. Дополнительные сведения см. в разделе Мониторинг работоспособности узлов кластера с помощью службы "Соответствие узлам".

Проверка состояния кластера вручную

GitHub Enterprise Server имеет встроенную программу командной строки для мониторинга работоспособности кластера. При запуске команды ghe-cluster-status в административной оболочке выполняется ряд проверок работоспособности на каждом узле, включая проверку подключения и состояния службы. В выходных данных отображаются все результаты теста, включая текст ok или error. Например, чтобы отобразить только неудачные тесты, выполните следующую команду:

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

Note

Если неудачные тесты отсутствуют, эта команда не выдает выходных данных. Это означает, что кластер работоспособен.

Мониторинг состояния кластера с помощью GitHub CLI

Расширение для GitHub CLI можно использовать gh es для проверки состояния кластера GitHub Enterprise Server. Дополнительные сведения см. в документации по использованию ES CLI GH и Администрирование экземпляра с помощью интерфейса командной строки GitHub.

Мониторинг состояния кластера с помощью Nagios

Можно настроить Nagios для мониторинга GitHub Enterprise Server. Помимо мониторинга базового подключения к каждому из узлов кластера, можно проверять состояние кластера, настроив Nagios для использования команды ghe-cluster-status -n. В результате выполнения возвращаются выходные данные в формате, понятном Nagios.

Необходимые компоненты

  • Узел Linux, где выполняется Nagios.
  • Сетевой доступ к кластеру GitHub Enterprise Server.

Настройка узла Nagios

  1. Создайте ключ SSH с пустой парольной фразой. Nagios использует его для проверки подлинности в кластере 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

    Ключ SSH без парольной фразы может представлять угрозу безопасности, если авторизован для полного доступа к узлу. Ограничьте авторизацию этого ключа одной командой только для чтения.

    Note

    Если вы используете дистрибутив Linux, который не поддерживает алгоритм Ed25519, используйте команду:

    nagiosuser@nagios:~$ ssh-keygen -t rsa -b 4096
    
  2. Скопируйте закрытый ключ (id_ed25519) в домашнюю папку nagios и задайте соответствующие права владения.

    nagiosuser@nagios:~$ sudo cp .ssh/id_ed25519 /var/lib/nagios/.ssh/
    nagiosuser@nagios:~$ sudo chown nagios:nagios /var/lib/nagios/.ssh/id_ed25519
    
  3. Чтобы авторизовать открытый ключ для выполнения только команды ghe-cluster-status -n, используйте префикс command= в файле /data/user/common/authorized_keys. В административной оболочке на любом узле измените этот файл, добавив открытый ключ, созданный на шаге 1. Например: command="/usr/local/bin/ghe-cluster-status -n" ssh-ed25519 AAAA....

  4. Проверьте и скопируйте конфигурацию на каждый узел в кластере, выполнив команду ghe-cluster-config-apply на узле, где был изменен файл /data/user/common/authorized_keys.

    admin@ghe-data-node-0:~$ ghe-cluster-config-apply
    > Validating configuration
    > ...
    > Finished cluster configuration
    
  5. Чтобы проверить, может ли подключаемый модуль Nagios успешно выполнить команду, запустите ее в интерактивном режиме с узла 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. Создайте определение команды в конфигурации Nagios.

    Пример определения

    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. Добавьте эту команду в определение службы для узла в кластере GitHub Enterprise Server.

    Пример определения

    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
           }
    

После добавления определения в Nagios проверка службы выполняется в соответствии с конфигурацией. Вы должны увидеть только что настроенную службу в веб-интерфейсе Nagios.