В продолжение постов о развёртывании Prometheus для мониторинга проекта в Azure (привет, Azure, давно не виделись! см. Azure: почему никогда).
Спустя три месяца — проект решил, что мониторинг им всё-таки нужен, и меня «вернули».
Посты по теме:
Остановился я на добавлении к Prometheus серверу виртуальных машин из VMSS с помощью Prometheus exporter_proxy
Ниже описывается продолжение настройки мониторинга сервисов — теперь к Prometheus серверу добавим мониторинг виртуальных машин из Azure VMSS и Docker Swarm managers и Docker Swarm workers, которые работают в этих VMSS.
Содержание
Описание проекта
Очень кратко — про сам проект, который будет мониторится.
Рабочие окружения состоят из двух Azure VMSS (
Перед каждым VMSS имеется свой Load Balancer, который разруливает трафик к интансам в этих VMSS.
Собственно само приложение включает в себя 6 контейнеров, которые запущены на Swarm Workers нодах:
Описание Prometheus сервера
Теперь кратко о самом Prometheus сервере.
Prometheus и Grafana запущены на виртуальной машине, в отдельной Azure Resource Group.
К виртуальной машине во время развёртывания Resource Group (с помощью Azure Resource Manager шаблонов, см. пост Azure: provisioning с Resource Manager, Jenkins и Groovy) подключается внешний диск, который монтируется в /data
из Ansible-задачи:
Задачи в Ansible — создание каталога /data
и монтирование диска:
... - name: Create "{{ data_mount_path }}" directory file: path: "{{ data_mount_path }}" owner: root group: root mode: 0755 state: directory - name: Mount volume "{{ data_volume }}" mount: path: "{{ data_mount_path }}" src: "{{ data_volume }}" state: mounted fstype: ext4 ...
В /data
хранятся данные самого Prometheus, Grafana и сертификаты Let’s Ecnrypt:
Для доступа к Prometheus и Grafana, а так же для завершения SSL-сессии — перед ними запущен NGINX со следующим конфигом:
upstream prometheus_server { server 127.0.0.1:9090; } upstream grafana_ui { server 127.0.0.1:3000; } server { server_name www.monitor.domain.tld; listen 80; return 301 https://monitor.domain.tld$request_uri; } server { server_name monitor.domain.tld; listen 80; root /var/www/monitor.domain.tld; location ~ /.well-known { allow all; } location / { allow 194.***.***.45; allow 37.***.***.130; deny all; return 301 https://monitor.domain.tld$request_uri; } } server { server_name monitor.domain.tld; listen 443 ssl; access_log /var/log/nginx/monitor.domain.tld-access.log proxy; error_log /var/log/nginx/monitor.domain.tld-error.log notice; ssl on; ssl_certificate /data/letsencrypt/live/monitor.domain.tld/fullchain.pem; ssl_certificate_key /data/letsencrypt/live/monitor.domain.tld/privkey.pem; root /var/www/monitor.domain.tld; location / { auth_basic_user_file /var/www/monitor.domain.tld/.htaccess; auth_basic "Password-protected Area"; allow 194.***.***.45; allow 37.***.***.130; deny all; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://grafana_ui$request_uri; } location /prometheus { auth_basic_user_file /var/www/monitor.domain.tld/.htaccess; auth_basic "Password-protected Area"; allow 194.***.***.45; allow 37.***.***.130; deny all; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://prometheus_server$request_uri; } }
Добавление мониторинга VMSS
Задача на сегодня — добавить мониторинг виртуальных машин Docker Swarm менеджеров и воркеров, мониторинг Docker engine на них и контейнеров на воркерах, в которых работает само приложение.
Большая часть уже настроена (см. Prometheus: exporter_proxy – мониторинг сервисов в приватной сети), поэтому этот пост больше обзорный и как документация для самого себя — на случай, если проект опять «пропадёт» на три месяца.
Запуск exporter_proxy
Начнём с запуска exporter_proxy
сервисов на менеджер-ноде.
Сейчас установка выполняется на QA, у которого 1 Manager нода и 3 workers.
Со Staging и Production будет немного сложнее, т.к. там три менеджера, и придётся обновлять правила Azure Load Balancer, но пока можно обойтись простым Compose файлом.
На manager ноде потребуется запустить exporter_proxy
и подключить ему файл настроек.
Файл настроек сейчас выглядит так:
listen: "0.0.0.0:9099" access_log: path: "/dev/stdout" format: "ltsv" fields: ['time', 'time_nsec', 'status', 'size', 'reqtime_nsec', 'backend', 'path', 'query', 'method'] error_log: path: "/dev/stderr" exporters: master_exporter: url: "http://10.0.0.4:9100/metrics" path: "/master_exporter/metrics" worker_1_exporter: url: "http://192.168.0.4:9100/metrics" path: "/worker_1_node_exporter/metrics" worker_2_exporter: url: "http://192.168.0.5:9100/metrics" path: "/worker_2_node_exporter/metrics" worker_3_exporter: url: "http://192.168.0.6:9100/metrics" path: "/worker_3_node_exporter/metrics"
node_exporter
-ы пока не запущены нигде, к ним перейдём чуть позже.
Создаём Compose файл для exporter_proxy
:
version: '3' networks: prometheus: services: prometheus-proxy: image: rrreeeyyy/exporter_proxy volumes: - /home/admin/prometheus-proxy-config.yml:/etc/config.yml ports: - "9099:9099" command: - '-config=/etc/config.yml' networks: - prometheus deploy: placement: constraints: - node.role == manager
Тут в блоке:
... placement: constraints: - node.role == manager
указываем на запуск exporter_proxy
только на менеджер-нодах. (см. constraint
Тут ещё один нюанс, который связан чисто с текущим сетапом — менеджер ноды находятся в статусе drain
, что бы не запускать на них сервисы вообще:
Что бы Docker Swarm запустил наш прокси — обновляем стаус менеджер-ноды на active
:
Проверяем стеки сейчас:
Создаём новый:
Проверяем:
Проверяем сам сервис:
Пробуем получить метрики от proxy:
ОК — т.к. сам node_exporter
ещё не запущен.
node_exporter
и cAdvisor
Далее создадим сервис, который будет запускать контейнеры с node_exporter
и cAdvisor на каждой ноде кластера — и менеджерах, и воркерах.
Созадём Compose файл:
version: '3' networks: prometheus: services: node-exporter: image: prom/node-exporter volumes: - /proc:/host/proc:ro - /sys:/host/sys:ro - /:/rootfs:ro command: - '--path.procfs=/host/proc' - '--path.sysfs=/host/sys' - --collector.filesystem.ignored-mount-points - "^/(sys|proc|dev|host|etc|rootfs/var/lib/docker/containers|rootfs/var/lib/docker/overlay2|rootfs/run/docker/netns|rootfs/var/lib/docker/aufs)($$|/)" ports: - 9100:9100 networks: - prometheus deploy: mode: global cadvisor: image: google/cadvisor volumes: - /:/rootfs:ro - /var/run:/var/run:rw - /sys:/sys:ro - /var/lib/docker/:/var/lib/docker:ro ports: - 8081:8080 networks: - prometheus deploy: mode: global
В блоке:
... deploy: mode: global
указываем на запуск на всех нодах кластера (см. mode
Создаём новый сервис:
Проверяем стеки:
Сервисы этого стека:
Всё поднялось, на всех нодах — 1 менеджер + 3 воркера == по 4 контейнера с cAdvisor и node_exporter.
Проверим метрики:
ОК — node_exporter
метрики отдаёт, проверим через exporter_proxy
:
Вернёмся к prometheus-proxy-config.yml
и добавим сбор метрик от cAdvisor.
Сначала проверим метрики от него напрямую:
Обновляем конфиг для прокси:
listen: "0.0.0.0:9099" access_log: path: "/dev/stdout" format: "ltsv" fields: ['time', 'time_nsec', 'status', 'size', 'reqtime_nsec', 'backend', 'path', 'query', 'method'] error_log: path: "/dev/stderr" exporters: manager_exporter: url: "http://10.0.0.4:9100/metrics" path: "/manager_exporter/metrics" worker_1_node_exporter: url: "http://192.168.0.4:9100/metrics" path: "/worker_1_node_exporter/metrics" worker_2_node_exporter: url: "http://192.168.0.5:9100/metrics" path: "/worker_2_node_exporter/metrics" worker_3_node_exporter: url: "http://192.168.0.6:9100/metrics" path: "/worker_3_node_exporter/metrics" worker_1_cadvisor_exporter: url: "http://192.168.0.4:8081/metrics" path: "/worker_1_cadvisor_exporter/metrics" worker_2_cadvisor_exporter: url: "http://192.168.0.5:8081/metrics" path: "/worker_2_cadvisor_exporter/metrics" worker_3_cadvisor_exporter: url: "http://192.168.0.6:8081/metrics" path: "/worker_3_cadvisor_exporter/metrics"
Пересоздаём стек прокси:
Проверяем метрики cAdvisor через прокси:
ОК — пошли метрики от cAdvisor.
Добавление targets в Prometeus сервер
Последний шаг — это добавить таргеты в Prometheus сервер.
Находим конфиг сервера:
Обновляем его блок scrape_configs
, пока используем static_configs
... - job_name: 'jm-website-qa' static_configs: - targets: - jm-website-qa-master-ip.westeurope.cloudapp.azure.com:9099 labels: __metrics_path__: /manager_exporter/metrics name: jm-website-qa-manager-vm - targets: - jm-website-qa-master-ip.westeurope.cloudapp.azure.com:9099 labels: __metrics_path__: /worker_1_node_exporter/metrics name: jm-website-qa-worker-1-vm - targets: - jm-website-qa-master-ip.westeurope.cloudapp.azure.com:9099 labels: __metrics_path__: /worker_2_node_exporter/metrics name: jm-website-qa-worker-2-vm - targets: - jm-website-qa-master-ip.westeurope.cloudapp.azure.com:9099 labels: __metrics_path__: /worker_3_node_exporter/metrics name: jm-website-qa-worker-3-vm - targets: - jm-website-qa-master-ip.westeurope.cloudapp.azure.com:9099 labels: __metrics_path__: /worker_1_cadvisor_exporter/metrics name: jm-website-qa-worker-1-docker - targets: - jm-website-qa-master-ip.westeurope.cloudapp.azure.com:9099 labels: __metrics_path__: /worker_2_cadvisor_exporter/metrics name: jm-website-qa-worker-2-docker - targets: - jm-website-qa-master-ip.westeurope.cloudapp.azure.com:9099 labels: __metrics_path__: /worker_3_cadvisor_exporter/metrics name: jm-website-qa-worker-3-docker ...
[/simterm]
Проверяем сервисы Prometheus сервера:
Перезапускаем Prometheus сервер:
И проверяем targets:
Проверим метрики от cAdvisor, в Prometheus graphs вызываем, например, container_cpu_user_seconds_total
, добавляем фильтры:
container_cpu_user_seconds_total{container_label_com_docker_stack_namespace="jm_website",container_label_com_docker_swarm_service_name="jm_website_proxy"}
Grafana dashboard
И по-быстрому — добавим дашборд в Grafana, через импорт, например
Осталось навести порядок в labels.
Ну и ещё кучу всего поделать.