Мониторинг VDS и Docker в Grafana: развертывание легковесного стека VictoriaMetrics, Node Exporter и cAdvisor без прожорливости Prometheus

Каждый системный администратор и разработчик сталкивался с неприятной ситуацией: рабочий сайт внезапно перестает отвечать, база данных выдает Connection refused, а консоль SSH либо не открывается, либо отвечает с задержкой в несколько десятков секунд. После долгожданного входа на сервер выясняется, что система зависла в дисковом ступоре (I/O wait) или системный демон Linux OOM Killer принудительно убил ключевой рабочий процесс.

Самое досадное в такой аварии — отсутствие истории. Без непрерывного сбора метрик невозможно понять первопричину: был ли это внезапный всплеск нагрузки от поисковых роботов, утечка памяти в Node.js или PHP-скрипте, зависший тяжелый запрос в PostgreSQL или исчерпание дескрипторов файлов.

Классическим стандартом мониторинга в индустрии многие годы считается стек Prometheus + Grafana. Однако попытка развернуть стандартный Prometheus на недорогом виртуальном сервере (VDS с 1–2 ГБ RAM) быстро оборачивается новой проблемой: TSDB-хранилище Prometheus само по себе крайне прожорливо к оперативной памяти и дисковым операциям. Под нагрузкой сервер мониторинга падает первым.

Современное инженерное решение этой проблемы — открытая база данных временных рядов VictoriaMetrics (Single-node версия). Ниже подробно разбираем, как развернуть полноценный отказоустойчивый стек мониторинга на VDS за 10 минут, связать его с Grafana, настроить сбор метрик системы и Docker, изолировать служебные порты от публичного интернета и настроить оповещения в Telegram.

1. Почему Prometheus перегружает дешевый VDS и как устроена архитектура VictoriaMetrics

Движок хранения данных Prometheus оптимизирован под корпоративные серверы с десятками гигабайт оперативной памяти. Входящие временные ряды он сначала удерживает в так называемых in-memory chunks (кусках оперативной памяти). При росте числа собираемых метрик (особенно с высокой кардинальностью меток в Docker) потребление RAM стремительно растет до 1.5–3 ГБ, а сброс данных на диск сопровождается массированной серией мелких операций случайной записи, парализующей недорогие виртуальные диски.

VictoriaMetrics спроектирована на языке Go с нуля специально для решения проблем эффективности и плотности упаковки метрик:

• Экстремально низкое потребление памяти: инстанс VictoriaMetrics Single утилизирует всего 50–90 МБ RAM при сборе метрик с десятка серверов.
• Плотное сжатие данных (MergeTree архитектура): метрики сжимаются в 5–7 раз эффективнее Prometheus. На хранение одной точки данных (timestamp + float64 значение) требуется менее 1 байта на диске.
• 100% совместимость с экосистемой PromQL: VictoriaMetrics полностью поддерживает протоколы Prometheus API и диалект PromQL (с полезными расширениями MetricsQL). Все официальные и пользовательские дашборды Grafana работают из коробки без переделки.
• Монолитный компактный бинарник: отсутствие громоздких внешних зависимостей, моментальный холодный старт за 200 миллисекунд и тривиальное резервное копирование простым созданием моментального снимка каталога данных.

2. Системные требования и сайзинг ресурсов VDS под сервер мониторинга

При планировании сервера мониторинга важно рассчитать объем оперативной памяти и дискового пространства с учетом срока хранения (Retention Period). VictoriaMetrics автоматически ротирует и удаляет устаревшие метрики по истечении заданного срока (по умолчанию 1 месяц).

Оценим требования к конфигурации в зависимости от масштаба вашей инфраструктуры:

Для гарантированной стабильности на сервере мониторинга рекомендуется настроить файл подкачки (Swap) на 2–4 ГБ. Подробно правильная настройка Swap и zRAM разобрана в нашем руководстве Правильная настройка Swap и zRAM на VDS с 1–2 ГБ RAM.

3. Надежные VDS-провайдеры для центрального узла мониторинга

Сервер мониторинга должен работать максимально изолированно и стабильно: если целевой сервер подвергается DDoS-атаке или падает, узел мониторинга обязан оставаться в сети и вовремя доставить уведомление администратору. Ниже представлены надежные российские провайдеры с гарантированным аптаймом и быстрыми NVMe-дисками:

4. Единый compose.yaml: развертывание VictoriaMetrics, vmagent и Grafana

Развернем стек мониторинга с помощью современного Docker Compose. В архитектуре мы разделим роли между тремя ключевыми компонентами:

• VictoriaMetrics (Сервер TSDB): хранилище данных, принимающее метрики и отвечающее на запросы Grafana по HTTP API на порту 8428.
• vmagent (Сборщик метрик): сверхлегкий агент сбора метрик (замена подсистемы скрапинга Prometheus). Он опрашивает экспортеры по расписанию и передает данные в VictoriaMetrics с буферизацией на диск в случае сетевых сбоев.
• Grafana: веб-интерфейс визуализации графиков, дашбордов и управления алертами на порту 3000.

Создадим рабочую директорию на сервере:

sudo mkdir -p /opt/monitoring/{vmagent,grafana/provisioning/datasources}
cd /opt/monitoring

Сначала подготовим конфигурационный файл сборщика метрик /opt/monitoring/vmagent/prometheus.yml:

global:
  scrape_interval: 15s
  scrape_timeout: 10s

scrape_configs:
  - job_name: 'victoriametrics'
    static_configs:
      - targets: ['victoriametrics:8428']

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

  - job_name: 'cadvisor'
    static_configs:
      - targets: ['cadvisor:8080']

Настроим автоматическое подключение источника данных в Grafana, чтобы не настраивать его вручную через веб-панель. Создадим файл /opt/monitoring/grafana/provisioning/datasources/datasource.yml:

apiVersion: 1

datasources:
  - name: VictoriaMetrics
    type: prometheus
    access: proxy
    url: http://victoriametrics:8428
    isDefault: true
    editable: false

Теперь создадим основной файл оркестрации /opt/monitoring/compose.yaml с жесткими лимитами памяти для каждого сервиса:

services:
  victoriametrics:
    image: victoriametrics/victoria-metrics:v1.102.0
    container_name: monitoring-victoriametrics
    restart: unless-stopped
    command:
      - "-storageDataPath=/vmetrics-data"
      - "-retentionPeriod=30d"
      - "-httpListenAddr=:8428"
    volumes:
      - vmdata:/vmetrics-data
    networks:
      - monitoring-net
    mem_limit: 384m
    deploy:
      resources:
        limits:
          memory: 384M

  vmagent:
    image: victoriametrics/vmagent:v1.102.0
    container_name: monitoring-vmagent
    restart: unless-stopped
    mem_limit: 128m
    depends_on:
      - victoriametrics
    command:
      - "-promscrape.config=/etc/prometheus/prometheus.yml"
      - "-remoteWrite.url=http://victoriametrics:8428/api/v1/write"
    volumes:
      - ./vmagent/prometheus.yml:/etc/prometheus/prometheus.yml:ro
    networks:
      - monitoring-net
    deploy:
      resources:
        limits:
          memory: 128M

  grafana:
    image: grafana/grafana-oss:11.2.0
    container_name: monitoring-grafana
    restart: unless-stopped
    mem_limit: 256m
    depends_on:
      - victoriametrics
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=СВЕРХНАДЕЖНЫЙ_ПАРОЛЬ_ИЗ_ГЕНЕРАТОРА
      - GF_USERS_ALLOW_SIGN_UP=false
      - GF_SERVER_ROOT_URL=http://localhost:3000
    volumes:
      - grafanadata:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning:ro
    ports:
      - "127.0.0.1:3000:3000"
    networks:
      - monitoring-net
    deploy:
      resources:
        limits:
          memory: 256M

  node-exporter:
    image: prom/node-exporter:v1.8.2
    container_name: monitoring-node-exporter
    restart: unless-stopped
    mem_limit: 64m
    command:
      - '--path.procfs=/host/proc'
      - '--path.sysfs=/host/sys'
      - '--path.rootfs=/rootfs'
      - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
    pid: host
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    networks:
      - monitoring-net
    deploy:
      resources:
        limits:
          memory: 64M

  cadvisor:
    image: gcr.io/cadvisor/cadvisor:v0.49.1
    container_name: monitoring-cadvisor
    restart: unless-stopped
    mem_limit: 128m
    privileged: true
    devices:
      - /dev/kmsg
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
      - /dev/disk/:/dev/disk:ro
    networks:
      - monitoring-net
    deploy:
      resources:
        limits:
          memory: 160M

networks:
  monitoring-net:
    driver: bridge

volumes:
  vmdata:
  grafanadata:

5. Сбор системных метрик хоста и контейнеров: Node Exporter и cAdvisor

Для глубокого понимания состояния сервера нам требуются два уровня телеметрии: уровень операционной системы хоста и уровень контейнеров Docker.

1. Node Exporter: метрики «железа» и ядра Linux

Сервис node-exporter собирает информацию о загрузке ядер процессора, температуре, очереди ввода-вывода (iowait), доступной оперативной памяти, свободном месте на смонтированных дисках и сетевых интерфейсах.

Чтобы Node Exporter видел реальные метрики хост-системы, а не изолированного контейнера, в конфигурации заданы три критически важных параметра:

• pid: host — доступ к таблице процессов хоста;
• /:/rootfs:ro — монтирование корневой файловой системы хоста в режиме только для чтения;
• Параметры --path.procfs и --path.sysfs — перенаправление коллекторов на виртуальные файловые системы ядра хоста.

2. cAdvisor: поконтейнерный учет ресурсов Docker

Демон cAdvisor (Container Advisor от Google) анализирует контрольные группы ядра Linux (cgroups). Он отслеживает:

• Сколько именно мегабайт памяти расходует каждый конкретный контейнер (MySQL, Nginx, Redis);
• Случаи удушения процессора (CPU throttling), когда контейнер упирается в заданный лимит;
• Объем сетевого трафика каждого контейнера и скорость дискового чтения/записи.

Запустим стек командой:

docker compose up -d

Проверим статус работы всех контейнеров:

docker compose ps

Все пять сервисов должны находиться в состоянии running или Up, а их суммарное потребление памяти не превысит 300–400 МБ RAM.

6. Подключение источника данных и готовые дашборды в Grafana

Благодаря подготовленному файлу datasource.yml при первом запуске Grafana уже знает об источнике VictoriaMetrics. Вам не придется вручную вбивать адреса и тестировать соединение.

Для визуализации метрик нет необходимости рисовать графики вручную. Сообщество создало великолепные проверенные временем дашборды. Импортируем два лучших стандарта:

1. Node Exporter Full (ID дашборда: 1860): абсолютный эталон для мониторинга Linux-серверов. Дашборд отображает загрузку CPU по ядрам, свободную память с учетом буферов и кэша, дисковую активность (IOPS и очереди), системные прерывания и сетевые ошибки.
2. cAdvisor Docker Monitoring (ID дашборда: 14282): наглядная визуализация всех запущенных Docker-контейнеров с сортировкой по расходу памяти, графиками сетевого ввода-вывода и фиксацией аварийных завершений.

Чтобы импортировать дашборд в Grafana:

• Откройте меню Dashboards → New → Import;
• В поле «Import via grafana.com» введите число 1860 и нажмите кнопку Load;
• В выпадающем списке источников данных выберите наш преднастроенный VictoriaMetrics и нажмите Import.

Через несколько секунд перед вами откроется интерактивная панель мониторинга реального времени с историей и детализацией до секунд.

7. Безопасный доступ к панели Grafana с автопродлением SSL

Поскольку порт Grafana привязан к 127.0.0.1:3000, прямой доступ из интернета закрыт. Настроим публикацию веб-интерфейса на отдельном поддомене (например, grafana.mydomain.ru) через обратный прокси Nginx с автоматическим выпуском SSL-сертификата Let's Encrypt.

Создадим базовый виртуальный хост в Nginx /etc/nginx/sites-available/grafana.conf:

server {
    listen 80;
    listen [::]:80;
    server_name grafana.mydomain.ru;

    location / {
        proxy_pass http://127.0.0.1:3000;
        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_set_header X-Forwarded-Proto $scheme;

        # Поддержка WebSockets для живых обновлений Grafana Live
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Активируйте конфигурацию, проверьте синтаксис и выпустите бесплатный SSL-сертификат Let's Encrypt через Certbot с автоматической настройкой HTTPS и редиректа:

# Активация хоста и применение настроек Nginx
sudo ln -s /etc/nginx/sites-available/grafana.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

# Автоматический выпуск сертификата и настройка 301 редиректа
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d grafana.mydomain.ru --redirect

Проверьте корректность настройки и безопасность сетевых портов с помощью онлайн-утилиты Сканер открытых портов онлайн: порт 3000, 8428, 9100 и 8080 должны быть строго закрыты для внешних IP-адресов, а снаружи должны отвечать исключительно 80 и 443 порты веб-сервера.

8. Мониторинг парка удаленных VDS: безопасная отправка метрик через vmagent

Одна из сильнейших сторон связки VictoriaMetrics — легкое объединение метрик с десятков серверов без необходимости поднимать сложные VPN-сети или выставлять порты метрик наружу.

В классическом Prometheus сервер мониторинга должен сам опрашивать удаленные узлы (Pull-модель), из-за чего приходится открывать порт 9100 на каждом сервере для внешнего IP. VictoriaMetrics поддерживает Push-модель:

1. На удаленный клиентский VDS устанавливается только легковесный бинарник node_exporter и компактный vmagent.
2. Агент vmagent локально собирает метрики хоста и сам отправляет их по HTTPS на защищенный эндпоинт вашего центрального сервера: https://grafana.mydomain.ru/api/v1/write.
3. В конфигурацию vmagent на удаленном сервере добавляется метка сервера:

   global:
     scrape_interval: 15s
     external_labels:
       server_name: 'vds-client-production-01'

В дашборде Grafana мгновенно появляется выпадающий список server_name: вы переключаетесь между серверами одним кликом, видя общую картину здоровья всех своих проектов.

9. Настройка критических алертов в Telegram

Мониторинг бесполезен, если администратор узнает об аварии только после звонка недовольного клиента. Настроим отправку мгновенных уведомлений в Telegram через встроенный механизм Grafana Alerting.

1. Создание Contact Point в Grafana

• Создайте бота в Telegram через @BotFather и сохраните полученный токен;
• Создайте закрытый чат или канал для оповещений, добавьте в него бота и узнайте ID чата (например, через @userinfobot);
• В Grafana перейдите в Alerting → Contact points → Add contact point;
• Выберите тип Telegram, укажите BOT API Token и Chat ID, после чего нажмите Test для проверки доставки сообщения.

2. Создание критических правил оповещения (Alert Rules)

Настройте два обязательных правила, предотвращающих 95% внезапных сбоев:

1. Критический дефицит свободной памяти (RAM < 10%):

   (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 < 10

   Если условие выполняется непрерывно более 3 минут, Grafana отправляет алерт с указанием проблемного хоста, позволяя перезапустить проблемный контейнер до вмешательства OOM Killer.

2. Заполнение системного диска (Свободно < 15%):

   (node_filesystem_free_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 15

   Позволяет вовремя очистить журналы systemd или старые Docker-слои до наступления ошибки No space left on device.

10. Резюме и чек-лист готовности к промышленной эксплуатации

Переход со стандартного тяжелого Prometheus на стек VictoriaMetrics + Grafana решает главную дилемму системного администратора: вы получаете мощную, наглядную и масштабируемую систему телеметрии, которая расходует минимум ресурсов сервера и не рискует упасть в момент пиковой нагрузки.

Перед вводом стека мониторинга в промышленную эксплуатацию сверьтесь с контрольным чек-листом:

• [x] Сервисы VictoriaMetrics, vmagent и Grafana запущены с явными лимитами оперативной памяти (deploy.resources.limits.memory).
• [x] Порты сбора метрик 8428, 9100 и 8080 полностью скрыты внутри локальной Docker-сети и не доступны из публичного интернета.
• [x] Порт Grafana 3000 привязан к 127.0.0.1 и защищен обратным прокси Nginx с SSL-сертификатом.
• [x] В Grafana отключена публичная регистрация новых пользователей (GF_USERS_ALLOW_SIGN_UP=false).
• [x] Импортированы проверенные дашборды: Node Exporter Full (1860) и cAdvisor (14282).
• [x] Настроен Contact Point в Telegram и протестирована доставка тестового алерта.