Мониторинг Docker контейнеров, Docker-хостов в Docker Swarm и в ECS-кластерах с помощью Prometheus+Grafana+AlertManager+Node-exporter+Cadvisor

За основу был взять стек мониторинга отсюда
https://github.com/stefanprodan/swarmprom

В наличие 3 ноды в Docker Swarm-кластере: одна нода — manager и две ноды — worker

Например, мониторинг стек будем запускать на мастере(на продакшен для этого нужно выделить отдельную ноду, которую нужно добавить в Swarm-кластер и именно на этой ноде запускать мониторинг)

А также имеется одна отдельная нода в ECS-кластере в AWS, которую также нужно мониторить (как ресурсы самой ноды, так и контейнеры,запущенные на ней)

Базовая архитектрная схема мониторинг стека имеет вид

Mониторинг стек состоит из следующих компонентов:

Все компоненты в Docker-swarm запускаются в контейнерах с помощью docker-compose.yml файла

Иерархия каталогов/файлов имеет следующий вид

Мониторинг стек запускается командой

Переменные, указанные при запуске/обновлении стека используются ,как переменные окружения в соответствующих контейнерах

в Prometheus — для аутентификации и авторизации в AWS

в AlertManager – для отправки уведомлений

в Mongodb-exporter — для снятия статистики с mongodb в mongodb-сервисе

в Caddy – пароль для аутентификации в Prometheus, AlertManager, Unsee, а также пароль для аутентификации в Grafana

ADMIN_USER(не указывется и по дефолту используется admin)

Prometheus использует правила для мониторинга различных параметров(rules-файлы) в виде docker-конфигов.
Blackbox-exporter также использует docker-config для своего конфигурационного файла.
Поэтому при изменении, например, правил Prometheus, необходимо изменить(увеличить на 1) значение версии файла при запуске/обновлении monitoring-стека(Например, до изменений правил стек запускался с командой RULES_CONF_VERSION=7 …., то после изменений правил стек должен запускаться командой RULES_CONF_VERSION=8)
Аналогично и для blackbox-экспортера (например, запускался до изменений конф.файла blackbox.yml с парметром BLACKBOX_CONF_VERSION=1, а после изменения файла blackbox.yml — должен запускаться с с параметром BLACKBOX_CONF_VERSION=2)
Текущие версии RULES_CONF_VERSION и BLACKBOX_CONF_VERSION доступны через docker service inspect соответствующих сервисов(mon_prometheus или mon_blckbox-exporter).

На ноде в ECS-кластере через ECS tasks/services также запускаются cadvisor, node-exporter, couchdb-exporter

Docker-контейнеры, запускаемые через Docker-compose-файл используют уже существующую overlay сеть, в которой запущены другие сервисы(например, наше приложение)
Т.е. интегрируется в эту сеть не создавая новой сети.
Запуск мониторинг стека в той же сети, что и основные уже запущенные docker-сервисы позволяет prometheus обнаруживать и использовать их как цели для мониторинга используя DNS service discovery по имени сервиса
Когда Prometheus выполняет DNS-запрос, Docker Swarm отдает список IP-адресов каждого контейнера(таска). Используя эти IP-адреса, Prometheus будет обходить SWARM-кий load-balancer(который используется по умолчанию и представляет overlay IP-адрес сервиса т.н. vip-адрес, за которым уже стоят реальные IP-адреса контейнеров, на которых запущен сервис)
и собирать метрики с каждого экспортера инстанса(node-exporter, cadvisor, mongodb-exporter)
Проблема с DNS discovery в Docker Swarm состоит в том, что SWARM не отдает никаких меток/запиcей для контейнеров/тасков, запущенных в Docker SWARM-кластере за исключением overlay IP-адреса, который динамически назначается Docker-ом каждому контейнеру/таску и по которому невозможно определить, какой ноде соответствует экспортер, который имеет такой IP-адрес
Для сопоставления ноды и node-exporter-а, который запускается на этой ноде, в скрипте, который выполняется при запуске контейнера c node-exporter (docker-entrypoint.sh) выполняется создание файла /etc/node-exporter/node-meta.prom в контейнере с node-exporter, в котором указан идентификатор ноды в SWARM-кластере (NODE_ID), а также имя ноды, на которой этот node-exporter запущен(берется из файла /etc/hostname с ноды).
Более подробно об этом у источника
https://github.com/stefanprodan/swarmprom

Prometheus обнаруживает цели для мониторинга:
— в Docker Swarm-кластере — с помощью DNS service discovery(prometheus запускается в той же overlay-сети, как и остальные ноды Docker Swarm кластера)( о чем было рассказано выше)
— в ECS-кластерах с помощью EC2 service discovery

Для обнаружения целей для мониторинга с помощью EC2 service discovery необходимо создать пользователя с соответствующими правами(достаточно привязать политику AmazonEC2ReadOnlyAccess к пользователю) и создать для этого пользователя AWS_ACCESS_KEY и AWS_SECRET_KEY ключи, которые будут использоваться для аутентификации и авторизации в EC2 и использоваться в конфигурационном файле Prometheus
Создание пользователя для аутентификации и авторизации в AWS изложено/доступно в конце статьи

Prometheus хранит данные за месяц, после чего автоматически удаляет/очищает устаревшие данные(—storage.tsdb.retention=750h)

Node-exporter, cadvisor запускаются в GLOBAL-режиме в Docker Swarm-кластере и в DAEMON-режиме в ECS-кластере

Следующие сервисы запускаются только на Monitoring-ноде(это достигается за счет использования .placement.constraints в docker-compose.yml файле,что позволяет запускать определенные сервисы на ноде с определенной меткой)

Установим необходимую метку с ее значением(type=monitoring) для ноды, на которой будем запускать мониторинг стек

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

Couchdb-exporter запускается на той же EC2-ноде в ECS-кластере, что и couchdb-сервис(с которого couchdb-eхporter будет собирать метрики)

Запуск Couchdb-exporter с безопасным хранением credentials для доступа и снятия статистики с couchdb-сервиса(couchdn-логин,couchdb-пароль,couchdb-url) в AWS Parameter Store изложены в этой статье
https://kamaok.org.ua/?p=3061

Docker-compose-файл имеет вид

 

Docker-контейнеры, запускаемые через Docker-compose-файл используют уже существующую overlay сеть, в которой запущены другие сервисы
Если необходимо запускать monitoring стек в своей отдельной сети, тогда закомментируем то, что сейчас используется и расскомментируем то, что сейчас закомментировано

 

Создаем необходимые тома для постоянного хранения своих данных Prometheus-ом, grafana-ой, alertmanager-ом

 

Создание Docker-конфигов,которые используются для конфигурационных файлов
Caddy – Caddyfile
Blackbox-exporter – blackbox.yml
Prometheus – node_rules, task_rules ,site_rules – файлы описания правил для срабатывания оповещения

 

Cadvisor, Unsee, Blackbox-exporter используем официальные публично доступные

Prometheus, Alertmanager, Node-exporter, Grafana — собираем свои образы на основе Dockerfile

Перед сборкой образов, проверить/убедиться, что все sh-файлы имеют бит исполнения

Prometheus

Alertmanager

Node-exporter

Grafana

Сaddy — просто перетегируем образ с stefanprodan/caddy

Mongodb-exporter – собираем Docker-образ на основе офицального Docker-файла

 

Для проверки синтаксиса конфигурационного файла Prometheus(prometheus.yml) и файлов с правилами(swarm_node.rules.yml, swarm_task.rules.yml, swarm_site.rules.yml) удобно/можно использовать утилиту promtool, которая доступна в архиве с prometheus

Находясь в каталоге с мониторинг стеком(monitoring-stack-swarm-prod)

Переходим на пару каталогов выше, загружаем и распаковываем архив с prometheus

После распаковки архива доступна утилита promtool

Команды для проверки файла с правилами prometheus

Или проверка конфигурационного файла prometheus и всех правил с помощью одной команды

 

Содержимое файлов стека

AlertManager
Изменяем дефолтные настройки параметров title и text путем созадния собственных шаблонов, которые используются в этих параметрах
AlertManager отправляет сообщения в соответствующий канал информирования (в нашем случае в Slack)

Файл с описанием шаблонов

Более подробно здесь
https://medium.com/quiq-blog/better-slack-alerts-from-prometheus-49125c8c672b

Динамическая замена параметров SLACK_URL, SLACK_CHANNEL, SLACK_USER на указанные либо при запуске мониторинг стека либо указанных в docker-compose.yml файле

Dockerfile для сборки образа AlertManager

 

Blackbox-exporter

Конфигурационный файл

В модулях

Определяем допустимые/желаемые коды ответов(200,302,301,304)
Regexps/patterns, которые должны быть найдены на стартовых страницах сайтов, которые мониторятся blackbox-экспортером
Эти модули будут использоваться/подключаться в конфигурационном файле Prometheus

 

Caddy
Конфигурационный файл имеет вид

По умолчанию значения переменных ADMIN_USER и ADMIN_PASSWORD берутся из файла prometheus.conf(задаются при описании caddy-сервиса)

Но при запуске мониторинг стека мы переопределяем значение переменной ADMIN_PASSWORD с помощью переменной окружения

 

Grafana
Docker-файл имеет вид

Grafana поддержует динамический provisioning как источников данных/метрик(datasource), так и dashboard-ов
http://docs.grafana.org/administration/provisioning/

Файл для динамического provisioning datasource с нашего prometheus-сервера

Файл для подключения динамического provisioning dashboard-ов

В grafana/dashboards размещаем dashboard-ы
Например, у меня их несколько — для нод в Swarm и ECS-кластерах, для контейнеров в
Swarm и ECS-кластерах, для сайтов, для mongodb,couchdb,prometheus-сервисов

 

Node-exporter
Dockerfile имееет вид

Стартовый скрипт(docker-entrypoint.sh) создает файл в node-exporter контейнере с необходимым содержимым для определения ноды, на которой запущен этот node-exporter
После чего непосредственно запускается node-exporter

 

Prometheus
Конфигурационный файл имеет вид

Стартовый скрипт(docker-entrypoint.sh), который выполняется в качестве ENTRYPOINT имеет вид

В нем выполняется динамическая замена access_key и secret_key ключей, которые передаются, как переменные окружения PROMETHEUS_AWS_ACCESS_KEY и PROMETHEUS_AWS_SECRET_KEY при запуске мониторинг стека
Также происходит непосредственно запуск Prometheus через его бинарный файл, а в качестве аргументов передаются параметры из поля CMD, указанного в Dockerfile.

Правила мониторинга, на основании которых запускается процесс оповещения имеют вид

 

Правила для мониторинга нод

 

Правила для мониторинга контейнеров

 

Правила для мониторинга сайтов

 

Конфигурационный файл Prometheus имеет вид

 

Интервал сбора метрик

 

Интервал проверки правил

 

Метка,используемая для определения сервера, с которого было отправлено оповещение в AlertManager

 

Файлы с правилами

 

Удаление ненужных меток-т.е. меток, отправка которых не нужна.
Prometheus будет удалять эти типы меток при отправке push-уведомления в AlertManager, который в свою очередь отправляет сообщений в соответствующий канал информирования(в нашем случае в Slack)

 

Отправка уведомление в AlertManager при срабатывании правила

 

Снятие метрик/мониторинг самого себя prometheus-ом

 

Снятие метрик/мониторинг node-exporter, cadvisor, mongodb-exporter, запущенных в Docker SWARM-кластере

 

Снятие метрик/мониторинг node-exporter, cadvisor, mongodb-exporter, запущенных в Docker ECS-кластере
Несколько пояснений
1.Acceess и Secret ключи будут динамически заменены при старте контейнера на указынные в командной строке при запуске мониторинг стека

2.Будут мониториться только те EC2-ноды,которые имеют следующий тег(в значениие тега используется regexp)

3.Происходит динамическое изменение меток
По умолчанию в EC2-service-discovery используется внутренний IP-адрес в качестве метки address
Именно по значении метки address и происходит подключение к EC2-нодам к ecs-node-exporter,ecs-advisor,ecs-couchdb-exporter для снятия c них статистики
Поэтому для того,чтобы prometheus смог подключиться к этим экспортерам выполняется переназначение метки address на внешний/публичный IP-адрес EC2-инстанса

Также добавляем пару дополнительных меток
Instance – со значением равным внешнему доменному имени EC2-инстанса
node_id – идентификатор EC2-инстанса в AWS

 

Мониторинг сайтов
Модули (http_2xx-kamaok, http_2xx-nexus, http_2xx-sonarqube)
были определены в конфигурационном файле blackbox-экспортера

 

Создание пользователя для аутентификации и авторизации в AWS

 

1.Создание пользователя в IAM

 

 

2.Добавление тега а ECS EC2-инстансе(например,через AWS console)

 

3.Настройка Prometheus
Настройка Prometheus для мониторинга только тех нод, у которых стоит тег

Комментирование и размещение ссылок запрещено.

Комментарии закрыты.

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