Стек моніторингу через Docker Compose
version: '3.9'
services:
prometheus:
image: prom/prometheus:latest
ports:
- "9090:9090"
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
- prometheus-data:/prometheus
grafana:
image: grafana/grafana:latest
ports:
- "3000:3000"
environment:
- GF_SECURITY_ADMIN_PASSWORD=admin123
volumes:
- grafana-data:/var/lib/grafana
node-exporter:
image: prom/node-exporter:latest
pid: host
volumes:
- /proc:/host/proc:ro
- /sys:/host/sys:ro
volumes:
prometheus-data:
grafana-data:
prometheus.yml: конфігурація збору метрик
global:
scrape_interval: 15s
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['node-exporter:9100']
- job_name: 'nginx'
static_configs:
- targets: ['nginx-exporter:9113']
Корисні PromQL запити
# CPU utilization
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
# RAM usage %
(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100
# Disk free
node_filesystem_avail_bytes{mountpoint="/"} / 1024 / 1024 / 1024
Розбір типових помилок
У Grafana дашборд показує No data, хоча контейнер Prometheus запущено — найчастіше Prometheus не може достукатися до експортера, або сама Grafana дивиться не на той datasource.
# В інтерфейсі Prometheus (http://ВАША_IP:9090/targets)
node (0/1 up)
Get "http://node-exporter:9100/metrics": dial tcp: lookup node-exporter on 127.0.0.11:53: no such host
Ця помилка означає, що контейнери не бачать один одного за іменем сервісу — зазвичай тому, що вони оголошені в різних docker-compose.yml без спільної мережі. Усі три сервіси — prometheus, grafana і node-exporter — мають бути в одному compose-файлі або підключені до однієї зовнішньої networks.
Помилка context deadline exceeded у логах Prometheus під час скрейпу означає, що експортер відповідає довше за scrape_timeout (за замовчуванням дорівнює scrape_interval). Зазвичай це симптом перевантаженого сервера або експортера, який сам чекає повільне джерело даних — наприклад, mysqld-exporter за недоступної бази.
Порівняння способів збору метрик
| Спосіб | Що потрібно | Коли використовувати |
|---|---|---|
| node_exporter | Метрики ОС: CPU, RAM, диск, мережа | Базовий моніторинг будь-якого Linux-сервера |
| nginx-exporter | Окремий модуль stub_status у Nginx | Метрики запитів, зʼєднань, кодів відповіді |
| mysqld-exporter | Користувач MySQL з правами PROCESS/REPLICATION | Метрики запитів, зʼєднань, реплікації БД |
| Застосунок з /metrics | Вбудована бібліотека клієнта Prometheus | Бізнес-метрики самого застосунку |
Коли цей стек надлишковий
- Один невеликий VPS з одним сайтом — розгортати три контейнери і розбиратися з PromQL заради базових графіків CPU і RAM надлишково, для цього достатньо Netdata з готовим дашбордом з коробки.
- Потрібен лише зовнішній контроль доступності сайту, а не внутрішні метрики сервера — це задача для аптайм-моніторів на кшталт UptimeRobot, а не для Prometheus.
- Команда не готова підтримувати сховище метрик — без налаштування retention і ресурсів під TSDB Prometheus на активному проєкті швидко зʼїдає диск і потребує постійної уваги.
Скільки диска зʼїдає Prometheus
За замовчуванням Prometheus зберігає дані 15 днів (--storage.tsdb.retention.time=15d). Практична оцінка обсягу — приблизно 1–2 байти на семпл після стиснення; за інтервалу збору 15 секунд і пари сотень часових рядів на невеликому стеку з трьох сервісів це зазвичай 200–500 МБ за два тижні, але зі зростанням кількості експортерів і міток зростає нелінійно.
services:
prometheus:
image: prom/prometheus:latest
command:
- '--storage.tsdb.retention.time=15d'
- '--storage.tsdb.retention.size=2GB'
- '--config.file=/etc/prometheus/prometheus.yml'
Параметр retention.size — страховка від переповнення диска: Prometheus видалить старі блоки даних раніше строку retention.time, якщо загальний обсяг перевищить ліміт, замість того щоб впасти з помилкою нестачі місця.
Перевірка результату
- Відкрийте
http://ВАША_IP:9090/targets— усі job'и мають бути в статусіUP, а неDOWN. - Відкрийте Grafana на
http://ВАША_IP:3000, додайте datasource Prometheus з адресоюhttp://prometheus:9090(імʼя сервісу з compose, не localhost) і імпортуйте дашборд за ID. - Виконайте тестовий PromQL-запит
up— він має повернути1для кожного робочого експортера. - Перевірте, що дані переживають перезапуск контейнера:
docker compose restart prometheus grafana, після чого старі графіки мають лишитися на місці завдяки іменованим томам.
Якщо задача — просто швидкий огляд ресурсів без Docker і PromQL, погляньте статтю про Netdata. Сам стек зручно піднімати через Docker Compose, якщо ще не знайомі з цим інструментом.