lenec ru

← все посты

Эльвира Соболева Подписаться

Мониторинг VPS: Netdata vs Grafana с Prometheus

15K

Без мониторинга на VPS — как ехать без зеркал заднего вида. Можно, но плохо. У меня в проде стоит Grafana + Prometheus на одном кластере и Netdata на пяти других серверах. И тот, и другой инструмент я считаю рабочим, но они под разные задачи. Расскажу, в каких случаях я что выбираю.

Что я хочу от мониторинга

  • Метрики: CPU, RAM, диск, сеть, нагрузка процессов.
  • Метрики приложения: RPS, latency, ошибки, очереди.
  • Логи (и связь с метриками).
  • Алерты по правилам.
  • Простой просмотр графиков — не уходить в PromQL ради «покажи занятие диска».

Netdata — простой и быстрый старт

Netdata — агент, который ставится на сервер и сразу показывает сотни метрик в красивом UI. Конфигурация минимальная.

curl -fsSL https://my-netdata.io/kickstart.sh | sh -s -- --stable-channel

После установки на http://<server_ip>:19999 уже доступны графики: CPU, диски, сеть, процессы, swap, контейнеры — всё это видно мгновенно. Никаких exporters, никаких ручных правил.

Что мне в Netdata нравится:

  • Гранулярность секунда. Большинство мониторингов снимают раз в 30–60 секунд. Netdata — раз в секунду. На скачках это спасает.
  • Auto-discover. Стоит у тебя Postgres, nginx, redis — Netdata сам найдёт и нарисует им графики.
  • Лёгкий по ресурсам. На сервере с 1 GB RAM ест 30–50 MB.
  • Cloud-агрегатор. Бесплатный тариф Netdata Cloud собирает данные с агентов в один кабинет, удобно для парка серверов.

Что не нравится:

  • Краткая история. По умолчанию хранит метрики локально, ограниченно. Для long-term нужно настраивать backend (Prometheus, InfluxDB).
  • Алерты есть, но проще, чем у Prometheus. Подойдут для базовых правил, для сложных — не хватит.
  • Дашборды кастомизируются хуже Grafana.

Беру Netdata, когда:

  • Один-три сервера, нужно быстро.
  • Команда не девопс, и тратить день на настройку Prometheus не хочется.
  • Достаточно стандартных дашбордов, не нужно строить свои.
  • Нужно показать клиенту «вот вам мониторинг» в день деплоя.

Grafana + Prometheus — мощно и гибко

Связка стандартная: Prometheus собирает метрики через scrape, Grafana их рисует и алертит. Поверх — куча экспортёров для всего на свете.

Базовый стек на одной машине

Я обычно поднимаю всё в Docker Compose:

services:
  prometheus:
    image: prom/prometheus:v2.55.0
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prom-data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=30d'
    ports: ['127.0.0.1:9090:9090']
    restart: unless-stopped

  grafana:
    image: grafana/grafana:11.2.0
    volumes:
      - grafana-data:/var/lib/grafana
    environment:
      GF_SECURITY_ADMIN_PASSWORD: ${GF_PASS}
      GF_INSTALL_PLUGINS: ''
    ports: ['127.0.0.1:3000:3000']
    restart: unless-stopped

  node-exporter:
    image: prom/node-exporter:v1.8.0
    pid: host
    volumes:
      - /:/host:ro,rslave
    command:
      - '--path.rootfs=/host'
    network_mode: host
    restart: unless-stopped

volumes:
  prom-data:
  grafana-data:

nginx перед Grafana и Prometheus с Basic Auth или Cloudflare Access. Сами порты 9090 и 3000 в интернет не светим.

prometheus.yml

global:
  scrape_interval: 15s
  evaluation_interval: 30s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node'
    static_configs:
      - targets: ['127.0.0.1:9100']

  - job_name: 'app'
    metrics_path: /metrics
    static_configs:
      - targets: ['127.0.0.1:3001']

  - job_name: 'postgres'
    static_configs:
      - targets: ['127.0.0.1:9187']

Дальше навешиваешь node-exporter, postgres-exporter, redis-exporter и пр. У большинства приложений есть готовый /metrics endpoint в Prometheus-формате; для Node это prom-client, и метрики появляются за пять минут работы.

Grafana дашборды

Не пиши свои. Берёшь готовые с grafana.com/dashboards: «Node Exporter Full», «PostgreSQL Database», «Redis Dashboard». Импортируешь по ID и получаешь профессиональный дашборд за минуту.

Свой делаешь только под бизнес-метрики приложения: «количество новых регистраций за час», «успешные платежи».

Алерты

Правила пишутся на PromQL. Базовый набор:

groups:
- name: server
  rules:
  - alert: HighCPU
    expr: 100 - avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100 > 85
    for: 10m
    labels: { severity: warning }
    annotations:
      summary: "CPU usage above 85% on {{ $labels.instance }}"

  - alert: DiskAlmostFull
    expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 < 10
    for: 5m
    labels: { severity: critical }
    annotations:
      summary: "Less than 10% disk left on {{ $labels.instance }}"

Эти правила подключаются в Prometheus, оттуда уходят в Alertmanager, который рассылает в Telegram, email, OpsGenie или что у тебя.

Сравнение в цифрах

На моём VPS с 4 vCPU / 8 GB RAM:

  • Netdata: ~50 MB RAM, <1% CPU, история 1 час по умолчанию.
  • Prometheus + node-exporter: ~200 MB RAM, ~2% CPU, история 30 дней (зависит от scrape_interval).
  • Grafana: ~150 MB RAM, минимальный CPU.

Netdata кратно легче. Если у тебя 8 серверов, Netdata-агент на каждом не съест ничего, а Prometheus на одном из них может стать bottleneck.

Гибридный подход

На больших проектах я часто комбинирую: Netdata стоит на всех серверах для удобного «зайти и посмотреть, что прямо сейчас». Prometheus + Grafana — центральный для долгой истории, бизнес-метрик, алертов.

Netdata умеет писать в Prometheus как remote_write. То есть метрики Netdata можно пробросить в Prometheus, и в Grafana они будут наравне с остальными. Получается «удобно сразу, и история на месяц».

Логи — отдельная тема

Метрики и логи — разные вещи. Метрики говорят «CPU 90%», логи говорят «вот этот запрос упал». Связку обеспечиваю через Loki (часть Grafana-стэка):

  • На сервере — vector или promtail, читает journald или файлы и шлёт в Loki.
  • В Grafana добавляю Loki как datasource. Можно прыгнуть из дашборда метрик в логи того же временного окна.

Netdata логами тоже занимается через свой Logs feature, но Loki + Grafana богаче и стабильнее на нагрузках.

Сценарии

Один сервис, личный проект

Netdata. Поставил, открыл, увидел.

2–5 сервисов, разработчик-одиночка

Netdata + Cloud-аккаунт для агрегации. Ноль настроек, графики со всех серверов в одном месте.

Команда, продакшен с SLA

Prometheus + Grafana + Alertmanager + Loki. Дашборды, бизнес-метрики, алерты в чат, on-call ротация.

Кубернетес

Тут только Prometheus-стэк. Helm-чарт kube-prometheus-stack ставит всё разом: Prometheus, Grafana, exporters, дашборды.

На что обратить внимание в любом случае

  • Алерты включены. Без них мониторинг — это просто красивые графики, которые никто не смотрит до инцидента.
  • Критичные метрики покрыты. Диск, RAM, CPU, latency приложения, очереди.
  • Бизнес-метрики. Успешные платежи, активные пользователи. Они часто говорят громче технических.
  • Доступ закрыт. Grafana и Prometheus наружу не торчат. Через VPN, Cloudflare Access или хотя бы Basic Auth.
  • Бэкап Grafana. Дашборды и пользователи лежат в SQLite или Postgres. Бэкапь.

Что я в итоге выбираю

На простом VPS с одним приложением — Netdata. Поставил за минуту, забыл. Когда количество сервисов вырастает или появляются бизнес-метрики, переезжаю на Prometheus + Grafana. Гибрид с Netdata-агентами на машинах + центральный Grafana — мой текущий стандарт для команд от 5 человек.

Главное — не откладывать. Бэкапы и мониторинг — две вещи, которые ставятся в первый день эксплуатации, а не «потом, когда будет время». Иначе «потом» наступает в самый неудобный момент.

Комментарии 0

  • Будьте первым, кто оставит комментарий.

Войдите, чтобы оставить комментарий.