До основного вмісту

Grafana + Prometheus: метрики та дашборди

VDS / VPS · 16.02.2025 · 4 хв читання
Ілюстрація до статті «Grafana + Prometheus: метрики та дашборди»

Стек моніторингу через 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.com: ID 1860 (Node Exporter Full) — одні з найкращих для моніторингу Linux-серверів.

Розбір типових помилок

У 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, якщо загальний обсяг перевищить ліміт, замість того щоб впасти з помилкою нестачі місця.

Перевірка результату

  1. Відкрийте http://ВАША_IP:9090/targets — усі job'и мають бути в статусі UP, а не DOWN.
  2. Відкрийте Grafana на http://ВАША_IP:3000, додайте datasource Prometheus з адресою http://prometheus:9090 (імʼя сервісу з compose, не localhost) і імпортуйте дашборд за ID.
  3. Виконайте тестовий PromQL-запит up — він має повернути 1 для кожного робочого експортера.
  4. Перевірте, що дані переживають перезапуск контейнера: docker compose restart prometheus grafana, після чого старі графіки мають лишитися на місці завдяки іменованим томам.

Якщо задача — просто швидкий огляд ресурсів без Docker і PromQL, погляньте статтю про Netdata. Сам стек зручно піднімати через Docker Compose, якщо ще не знайомі з цим інструментом.

Чи була стаття корисною?
← Назад до бази знань Поставити питання підтримці