Обзор мониторинга
В этом разделе описывается инфраструктура мониторинга и алертинга платформы.
1. Веб-интерфейсы
-
Мониторинг (Perses / Prometheus): https://monitoring.byyd.app
-
Алертинг (Karma / Alertmanager): https://alerting.byyd.app
2. Стек технологий
Стек мониторинга разворачивается с помощью Ansible-роли monitoring_stack и включает следующие основные компоненты:
-
Prometheus: Собирает метрики с таргетов и оценивает правила алертинга.
-
Alertmanager: Обрабатывает алерты, поступающие от Prometheus, и маршрутизирует их в приватный канал Slack (
#dsp-alerts). -
Perses: Основной инструмент для визуализации дашбордов.
-
Karma: Дашборд для управления и контроля алертов.
3. Рабочий процесс для дашбордов (GitOps)
Управление дашбордами в Perses осуществляется через автоматизированный GitOps-пайплайн. Данный подход предотвращает расхождение конфигураций (drift) в продакшене.
Проекты и дашборды, не имеющие префикса Playground, доступны только в режиме чтения (read-only). Любые изменения, внесенные в них вручную, будут автоматически отменены скриптом синхронизации в течение нескольких минут.
|
3.1. Как вносить изменения в дашборды
Если вам необходимо изменить дашборд, следуйте этому алгоритму:
-
Найдите необходимый дашборд в проекте с префиксом
Playground. -
Внесите изменения (визуальные или сами запросы) в рамках этого проекта
Playground. -
Как только изменения будут готовы, повысьте мажорную версию в теге дашборда. Например, если текущий тег был
version-3, установите его наversion-4. -
В системе каждые 10 минут запускается скрипт автоматической синхронизации. Как только он обнаруживает изменение мажорного тега, он:
-
Делает коммит обновленного JSON-конфига дашборда в новую ветку репозитория Git.
-
Создает Merge Request (MR) для этих изменений в GitLab.
-
Параллельно применяет ваши изменения в соответствующий "боевой" дашборд без префикса
Playground(перезаписывая read-only файлы).
-
-
После этого вы обязаны провести ревью созданного Merge Request’а в GitLab и вмержить его в основную ветку репозитория инфраструктуры.
4. Развертывание и автообнаружение (Service Discovery)
Для базового деплоя стека мониторинга используется Ansible-плейбук ansible-infra/playbooks/deploy_monitoring.yml.
В качестве источника инвентаря (Dynamic Inventory) выступает NetBox: ansible-infra/inventory/netbox.yml.
Команда для деплоя мониторинга:
ansible-playbook -i inventory/netbox.yml playbooks/deploy_monitoring.yml
4.1. Интеграция с NetBox
-
Автодеплой экспортеров: При добавлении в NetBox Application Service с именем
node_exporterи тегомauto-deployна конкретный Device, срабатывает событиеDevice Update. NetBox отправляет Webhook, который автоматически запускает деплойnode_exporterна соответствующий сервер. -
Автоматический сбор метрик: При добавлении в NetBox тега
prometheus-targetна любой Application Service, который поддерживает отдачу метрик для Prometheus, этот сервис автоматически будет добавлен в мониторинг через несколько минут. Инженеру необходимо только убедиться, что открыты соответствующие доступы в таблице маршрутизации/файрволе.