Datadog и New Relic отпали: собираем мониторинг своими силами

MAATRIX

Оплата с российской карты не проходит, корпоративный доступ обрубили без предупреждения, а дашборды Datadog или New Relic, на которые вы полагались полгода, в любой момент могут просто перестать открываться. Паниковать поздно, а откладывать нельзя: за несколько дней вполне реально поднять свой стек мониторинга — не идентичную копию SaaS, но рабочую замену, которая покажет метрики, логи и пришлёт алерт, когда что-то упадёт. Разберём, из каких компонентов собирать такой стек, сколько под него нужно железа, что из старых дашбордов и алертов перенести не получится, и на каких граблях спотыкается почти каждый при первом развёртывании.

Почему это системный риск, и из чего собирать замену

Datadog, New Relic, платная Grafana Cloud — все выставляют счета через зарубежный процессинг, и для российских карт это рулетка: сегодня платёж проходит, через месяц банк или платёжная система блокируют транзакцию без объяснений. Даже если оплата решена, остаётся вторая проблема — сам доступ: компании из юрисдикций с санкционными ограничениями время от времени блокируют аккаунты по геопризнаку IP, без апелляции в разумный срок.

Это не история про везение, а вопрос времени. Если инфраструктура рассчитана на годы, зависимость от одного внешнего SaaS, который может отвалиться по причинам, не связанным с качеством продукта, — архитектурный риск, который стоит устранить заранее. Похожая логика применима и к другим корпоративным SaaS: что поднять у себя, если Jira и Confluence отключили.

Мониторинг — одна из немногих областей, где open source не догоняет коммерческие SaaS, а задаёт стандарт: Prometheus и Grafana де-факто являются отраслевой нормой, и весь рынок, включая сам Datadog, ориентируется на их модель данных. Свой стек — это не один продукт, а связка специализированных слоёв:

Все компоненты open source, разворачиваются через Docker Compose, и у всех совместимая модель меток — это избавляет от рассинхронизации между слоями.

Метрики: Prometheus или VictoriaMetrics

Prometheus — очевидный выбор для сбора и хранения метрик: pull-модель (сам забирает метрики по HTTP), язык запросов PromQL, готовые exporter'ы под большинство типовых сервисов. Для проекта на одном-нескольких серверах его штатного хранилища на локальном диске обычно достаточно.

Ограничение — на масштабе и при долгом хранении истории: у Prometheus нет встроенной кластеризации, а retention упирается в объём диска одного инстанса. Здесь пригождается VictoriaMetrics — TSDB, совместимая с Prometheus по протоколу сбора и PromQL, но заметно эффективнее по сжатию данных, с опцией кластерного режима при необходимости. Ориентир, не измеренная гарантия — у вас цифры будут другими в зависимости от кардинальности метрик: VictoriaMetrics обычно занимает на диске меньше, чем «сырой» Prometheus при сопоставимой нагрузке.

Начинать разумно с Prometheus — он проще в модели и лучше документирован для тех, кто раньше со стеком не работал. Пошаговая установка с рабочим конфигом разобрана отдельно: установка Grafana и Prometheus на VPS. Переезд на VictoriaMetrics осмыслен, когда вы упираетесь в диск или в кардинальность — это отдельная миграция по факту проблемы, а не решение «про запас», усложняющее стек без немедленной выгоды.

Минимальный набор exporter'ов для старта:

services:
  node-exporter:
    image: prom/node-exporter:latest
    network_mode: host
    pid: host

  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    ports: ["8080:8080"]
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro

Этого достаточно для CPU, памяти, диска, сети хоста и метрик каждого контейнера — тот же набор, что показывает инфраструктурная вкладка Datadog из коробки.

Логи: зачем Loki, а не ELK или journald

Голый journald не даёт поиска по нескольким серверам и агрегации. Классический ELK (Elasticsearch) даёт мощный полнотекстовый поиск, но индексирует каждую строку целиком и требует заметно больше памяти и диска на тот же объём логов.

Grafana Loki индексирует не текст, а только метки — сервис, хост, уровень, — а сами строки хранит сжатыми блоками. Это дешевле по ресурсам, чем Elasticsearch, ценой меньшей гибкости запроса без фильтра по меткам. Для типичной задачи «найти ошибки конкретного сервиса за последний час» — а это большинство обращений к логам — Loki справляется отлично, и главное: рисуется на тех же дашбордах Grafana, что и метрики, единым интерфейсом.

Агент сбора — Promtail (постепенно вытесняется Grafana Alloy) — читает логи контейнеров и файлы, размечает их теми же метками, что и Prometheus. Это не случайность: единая модель меток — главный аргумент за связку Prometheus + Loki вместо разнородных систем.

Важно заложить retention сразу, а не постфактум — по умолчанию Loki может копить данные бесконечно:

limits_config:
  retention_period: 336h  # 14 дней, подберите под бюджет диска

Алертинг: Alertmanager и доставка в Telegram

Метрики и логи без алертинга — просто красивые графики, на которые никто не смотрит, пока не станет поздно. Alertmanager берёт правила срабатывания (PromQL-условия из Prometheus/VictoriaMetrics) и занимается маршрутизацией: группирует похожие алерты, чтобы не заваливать дежурного дублями, подавляет менее важные при срабатывании более критичного (inhibition), разводит уведомления по каналам в зависимости от важности.

Базовое правило на нехватку места на диске:

groups:
  - name: disk
    rules:
      - alert: DiskSpaceLow
        expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 15
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Свободного места на диске меньше 15%"

Доставка в Telegram — самый практичный канал для небольшой команды: не требует отдельной подписки на пейджинг-сервис, уведомление приходит на телефон мгновенно, легко развести отдельные группы под разные уровни критичности. Пошаговая настройка с рабочим ботом и конфигом маршрутизации разобрана отдельно: настройка алертов в Telegram на VPS. Для команд побольше, где нужна эскалация (не среагировали за 15 минут — звонок дежурному), Alertmanager заводится через вебхук в специализированные системы дежурств — но для старта это избыточно: начните с Telegram и одного уровня критичности.

Сервер, перенос старого и типичные грабли

Требования к серверу сильно зависят от числа наблюдаемых хостов, интервала сбора и retention. Ориентировочные цифры для старта с десятком-другим серверов под наблюдением, не измеренные лично для вашей нагрузки:

Главный фактор роста памяти Prometheus — не число серверов, а кардинальность: количество уникальных комбинаций меток. Каждая новая пара «сервис + инстанс + эндпоинт + код ответа» — новый временной ряд, и если приложение кладёт в метку что-то уникальное на каждый запрос (session_id, полный URL с параметрами), потребление памяти может вырасти на порядок без роста числа серверов — думайте об этом заранее, а не когда Prometheus начнёт падать по OOM.

Отдельно стоит сразу снять иллюзии про перенос: автоматической миграции дашбордов и алертов из Datadog или New Relic в Grafana не существует — модели данных и языки запросов принципиально разные (свой query language у Datadog, NRQL у New Relic, PromQL/LogQL у Grafana). Экспорт JSON из Datadog даёт структуру дашборда, но не рабочие запросы — их придётся переписывать вручную. Что реально ускоряет перенос:

• Список того, что отслеживали и на что реагировали — даже вручную, скриншотами, если доступ уже ограничен. Это техзадание для новых дашбордов, важнее самого экспорта.
• Готовые community-дашборды Grafana — для типовых стеков (node_exporter, PostgreSQL, nginx, Docker) на grafana.com выложены дашборды под ID, импортируются за минуты и закрывают большую часть типовых потребностей.
• Не всё сразу. Начните с 3–5 критичных алертов (диск, память, доступность, ошибки 5xx) и одного обзорного дашборда — остальное воссоздавайте по мере реальной необходимости, а не восстанавливайте зоопарк из полусотни виджетов, половину которых никто не открывал и в Datadog.
• Пороги пересчитайте, а не копируйте — значения, откалиброванные под агрегацию и семплирование Datadog, не переносятся один в один на сырые метрики Prometheus.

Честно: на полноценное повторение того, что копилось в SaaS месяцами, уйдёт не пара дней, а несколько недель итеративной доводки. Первая неделя — минимальный каркас, дальше — по мере того, что реально понадобилось.

Типичные грабли первого развёртывания:

• Мониторинг живёт на том же сервере, что и продакшен. Самая частая и болезненная ошибка: при падении хоста целиком молчит и наблюдатель — то есть именно то, что должно было прислать алерт. Разбор антипаттерна и как разнести компоненты правильно: мониторинг на том же сервере, что и прод.
• Grafana открыта без нормальной аутентификации. Дефолтный admin/admin меняют не все — а Grafana с дашбордами инфраструктуры без пароля отдаёт атакующему карту вашей сети.
• Retention не настроен заранее. И Prometheus, и Loki по умолчанию копят данные без разумного лимита под ваш диск — итог одинаковый: диск заполняется, и вся система, включая логи о заполнении диска, останавливается одновременно.
• Алерты настроены, но канал доставки никто не проверял боевым сбоем. Конфиг выглядит правильно, тестовое сообщение доходит — а в реальной аварии не доходит, потому что бот заблокирован, токен просрочен или маршрутизация не покрывает конкретный severity. Проверяйте цепочку целиком раз в квартал.
• Часы на серверах расходятся. Если наблюдаемые серверы и сервер мониторинга разошлись по времени даже на минуты, графики визуально «плывут» относительно реальных событий, а for: 10m в правиле может сработать не тогда, когда ожидалось. NTP на всех узлах — не опция.
• Забыли бэкап конфигурации самого мониторинга. Дашборды, правила алертов, маршрутизация — тоже конфигурация, её стоит хранить в git, а не только в базе Grafana на диске, иначе пересборка после сбоя самого сервера мониторинга повторит весь путь миграции ещё раз.

Частые вопросы