Мониторинг раннеров GitHub Actions

Мониторинг раннеров GitHub Actions может потребоваться при отладке сборки ваших приложений, например когда билд стабильно падает из-за нехватки ресурсов, а наблюдать динамику их утилизации в реальном времени не представляется возможным.

Мониторинг раннеров GitHub Actions

GitHub Actions по умолчанию предоставляет до 20 раннеров единовременно для публичных проектов. Каждый раннер создается перед выполнением задачи и существует пока она активна.

Примечание: получить больше информации о раннерах вы можете в статье About GitHub-hosted runners, в ней таже доступны ссылки на списки установленного софта для той или иной операционной системы. Например вот так выглядит список предустановленного ПО для Ubuntu 20.04.

Сразу после завершения задачи раннер уничтожается. Раннеры не переиспользуются и каждый раз создаются с нуля. В процессе выполнения задачи бывает важно контролировать происходящее – отслеживать метрики как аппаратные, так и программные.

Проблема

GitHub не предоставляет инструментов мониторинга раннеров. Отсутствует какая-либо информация даже о примитивных аппаратных метриках, таких как CPU load, RAM, free disk space.

Примечание: у GitHub есть также раннеры с большей производительностью, но за них придется заплатить (см. About larger runners). Если это не входит в ваши планы и единственный вариант – продолжить заниматься оптимизацией производительности, читайте дальше.

Решение

Дополнить список предустановленного на раннерах софта не получится, но вполне возможно самостоятельно установить необходимое вам программное обеспечение (например node_exporter), либо запустить его в контейнерах. Последний вариант даже быстрее и проще, благо Docker уже установлен по умолчанию.

Метрики node_exporter доступны на 9100 порту, но опросить его снаружи не получится.

Примечание: видимо все раннеры заперты где-то внутри виртуальных сетей MS Azure. Тем не менее зайти на раннер по ssh вполне возможно с помощью tmate, для которого есть даже отдельный экшн. Это актуально, когда необходимо что-то отдебажить. Подробнее см. в официальном репозитории Debug your GitHub Actions by using tmate.

Prometheus создан для работы по pull-модели, когда он сам опрашивает целевые хосты, на которых развернуты экспортеры. Но отправлять метрики по push-модели также возможно, для этого есть Pushgateway 1. У него весьма ограниченная область применения и в общих случаях его использование не рекомендуется. Однако наш сценарий подходит идеально.

Примечание: ознакомьтесь со статьями Common pitfalls when using the Pushgateway и WHEN TO USE THE PUSHGATEWAY, чтобы лучше понимать области применения и риски использования Pushgateway.

Локально опросить метрики сможет даже самый обычный curl, его и возьмем.

Запускать node_exporter в контейнере вполне возможно и в нашем случае даже оправдано, но вот что делать с curl? Я предлагаю запускать в контейнере в том числе и его и вот почему:

  • Если ваш пайплайн выполняется в докер-контейнере, то управлять процессами хоста не так-то просто. При том сделать docker run для контейнера с курлом – элементарная задача. К тому же docker.sock по умолчанию уже проброшен в основной контейнер

Примечание: о запуске процессов на хосте изнутри контейнера читайте в статье Увеличение файла подкачки в GitHub Actions.

  • Отслеживать логи curl намного удобнее командой docker logs, чем грепать /var/log и искать по pid (если будет запущено несколько таких экземпляров)

Остается сделать так, чтобы curl снимал метрики раз в 15 секунд и отправлял их на Pushgateway. Попробуем это реализовать.

Реализация

Небольшая инструкция по запуску node_exporter в контейнере есть в официальном репозитории 2 на GitHub:

Теперь переходим к curl. Если вы настаиваете на варианте его запуска прямо на хостовой ОС, то однострочник ниже вам идеально подойдет:

Второй curl в пайпе предназначен для отправки данных на ваш Pushgateway. На вход он принимает имя пользователя и пароль (<username>:<password>) и публично доступный адрес хоста (<pushgateway_host>). ${GITHUB_RUN_ID} и ${HOSTNAME}${HOSTNAME} – встроенные переменные GitHub Actions.

Примечание: pushgateway в базовой конфигурации не требует авторизации и не защищен сертификатом. Тем не менее я настоятельно рекомендую поставить перед ним Nginx, на котором элементарно сделать хотя бы Basic Auth, а с помощью certbot выписать ему сертификат. Разумеется понадобится публичный домен, которым вы реально владеете.

Но, как мы и обсуждали ранее, лучше запускать curl в контейнере:

Примечание: опция –net=”host” в нашем случае обязательна как для экспортеров, так и для контейнеров с curl, их опрашивающих. Нужно это для того, чтобы все они слушали на хостовом интерфейсе и могли обращаться друг к другу по localhost. Грубо говоря, контейнеры должны использовать неймспейс хоста для реализации сетевого стека.

На этом все! Понимаю, что статья получилась больше теоретическая, чем практическая, но описываемое техническое решение очень сильно зависит от вашей инфраструктуры. Тем не менее теперь вы знаете, что настроить мониторинг даже на github-hosted агентах вполне реально. Однако если не хочется разбираться с CI/CD самостоятельно, вы всегда может обратиться ко мне. А вот про pushgateway поговорим уже как-нибудь потом. Успехов!

Яндекс.Метрика