Помню, как на собеседовании в одну крупную компанию мне задали вопрос: "Чем отличается observability от monitoring?" Я уверенно ответил что-то про "три столпа" и "unknown unknowns". Интервьюер кивнул, но потом спросил: "А зачем платить $100k в год за Datadog, если можно поставить бесплатный Prometheus?"

Тогда я не смог внятно ответить. Сейчас, спустя три года и несколько миграций между системами мониторинга, я знаю ответ. И он стоил нашей компании около полумиллиона долларов в экспериментах. Давайте разберемся, за что же мы платим такие деньги.

История двух инцидентов

Лучше всего разницу между monitoring и observability иллюстрируют две истории из моей практики.

Инцидент первый: известная проблема

Пятница, 16:00. Сработал алерт "CPU usage > 80%". Классика. Захожу в Grafana, смотрю на заранее настроенный дашборд. Да, CPU высокий. Проверяю стандартный чеклист: нет ли деплоя, не увеличился ли трафик, не зациклился ли какой-то процесс. Нахожу процесс-виновник, рестартую, проблема решена. 15 минут от алерта до решения.

Это monitoring. У нас была известная проблема (высокий CPU), известное решение (найти процесс и рестартнуть), и заранее подготовленные инструменты (дашборд и алерт). Все по учебнику.

Инцидент второй: призрак в машине

Понедельник, 11:00. Звонок от продакт-менеджера: "Пользователи жалуются, что чекаут иногда занимает 30 секунд вместо обычных 2". Иногда. Не всегда. У некоторых пользователей. Не у всех.

Смотрю на дашборды — все зеленое. CPU в норме, память в порядке, latency p95 показывает 2 секунды. По всем метрикам мы здоровы как космонавты. Но пользователи продолжают жаловаться.

И вот тут начинается observability. Мне нужно найти иголку в стоге сена, не зная, как выглядит иголка.

Открываю трейсинг. Ищу все запросы к /checkout за последний час, которые заняли больше 10 секунд. Нахожу 15 из 10,000. 0.15% — неудивительно, что p95 это не показывает.

Смотрю на эти медленные трейсы. У всех есть общий паттерн — они идут через определенный инстанс payment-service. Но не всегда! Только когда в запросе есть определенный тип карты.

Иду в логи этого инстанса. Фильтрую по trace_id медленных запросов. Нахожу исключение, которое проглатывается и не логируется на уровне ERROR — таймаут при обращении к внешнему API проверки карт, но только для карт определенного банка, и только с этого инстанса, потому что у него почему-то другая версия библиотеки (спасибо тому, кто делал hotfix в обход CI/CD).

Три часа расследования. Без observability я бы это просто не нашел. Все метрики были "зелеными", проблема проявлялась в 0.15% случаев, и только при определенной комбинации условий.

Три столпа, которые держат вашу систему

Все говорят про "три столпа observability", но мало кто объясняет, зачем они нужны вместе. Я объясню на примере расследования реального инцидента.

Метрики показали, что что-то не так. Рост error rate с обычных 0.1% до 0.5%. Небольшой, но заметный.

Логи рассказали, что именно не так. NullPointerException в конкретном методе при обработке заказов с промокодом.

Трейсы показали, почему это происходит. Оказалось, что новый микросервис промокодов иногда возвращает null вместо пустого массива, но только когда к нему обращаются через API Gateway версии 2.3.1, которая стоит только в одном регионе.

Попробуйте найти такое только с метриками. Или только с логами. Не получится. Нужны все три компонента, и главное — возможность коррелировать их между собой.

Ценники, от которых хочется плакать

Теперь о больном — о деньгах. Сколько стоит "видеть все"?

Наш путь по граблям

Мы начинали как стартап с 10 серверами. Поставили Prometheus + Grafana + ELK. Бесплатно! Ну, почти бесплатно — нужны были серверы для запуска. $500 в месяц за инфраструктуру. Красота!

Потом мы выросли до 100 серверов. ELK начал требовать уже 5 нод для нормальной работы. Prometheus нужен был federation для сбора метрик. Появился dedicated инженер, который этим занимался. $5,000 за инфраструктуру + $10,000 за инженера = $15,000 в месяц. Уже не так весело.

На 500 серверах self-hosted решение превратилось в отдельный проект. Три инженера фултайм занимались только поддержкой мониторинга. Апгрейды, траблшутинг, оптимизация. $50,000 в месяц только на зарплаты. Плюс инфраструктура. Плюс то, что эти инженеры не делали продукт.

Покупка Datadog: шок и принятие

Когда вендор прислал первый счет, я думал, это опечатка. $38,000 в месяц. За мониторинг! Но давайте посчитаем детально:

  • 150 хостов × $31 = $4,650

  • 500 GB логов в день × 30 дней × $0.10 за GB = $1,500

  • APM для 50 сервисов = $2,000

  • Synthetic monitoring (20 тестов) = $100

  • Real User Monitoring = $1,500

  • И это еще базовый план!

Итого около $10,000 в месяц. Откуда $38,000? А, ну да, мы же не учли custom metrics, дополнительные dashboard, увеличенную retention, security monitoring... Все эти "мелочи" утроили счет.

Альтернативы и их подводные камни

New Relic казался дешевле — $99 за пользователя. У нас 50 инженеров, $5,000, отлично! Но потом выяснилось, что это только базовая цена. Хочешь больше 8GB логов в день? Доплати. Хочешь хранить данные больше 3 дней? Доплати. В итоге вышло те же $30,000.

Elastic Cloud обещал $95 за 8GB RAM. Но для наших объемов нужно было минимум 128GB кластер. Плюс отдельно Kibana. Плюс APM. Плюс... В общем, $15,000 в месяц, но это только хранилище. Визуализация, алертинг, корреляция — все это нужно было допиливать самим.

Grafana Cloud — новый игрок, обещающий "все включено". Начинается с $49 в месяц. Звучит прекрасно! Пока не понимаешь, что это за 10,000 активных серий метрик. А у нас их 10 миллионов. Умножаем... Опять $30,000+.

Когда стоит платить, а когда — строить самим

После всех экспериментов я вывел простое правило.

Стройте сами, если:

У вас меньше 100 серверов и есть инженер, который любит возиться с инфраструктурой. Prometheus + Grafana + Loki справятся с базовыми задачами. Вы потратите $1,000-2,000 на инфраструктуру и 20% времени одного человека.

У вас очень специфические требования. Например, нужно хранить логи 5 лет по compliance. Или нужна интеграция с вашей самописной системой. Или у вас настолько большие объемы, что любой вендор разорит.

У вас есть команда, которая хочет и может этим заниматься. Не один энтузиаст, а именно команда. Потому что энтузиаст рано или поздно уволится, и вы останетесь с системой, которую никто не понимает.

Платите вендору, если:

У вас нет времени. Серьезно, если ваш бизнес растет, последнее, на что стоит тратить время — это изобретение велосипеда в мониторинге.

Вам нужна надежность. Когда production лежит, вы хотите искать проблему, а не чинить сам мониторинг, который тоже упал.

Вам важна скорость. Установка Datadog агента занимает 5 минут. Настройка всего остального — час. Попробуйте за час настроить ELK с нуля.

У вас нет expertise. Можно научиться, конечно. Но пока вы учитесь, конкуренты, которые купили готовое решение, уже выпустили 10 фич.

Хаки для оптимизации расходов

За три года использования разных систем я научился экономить десятки тысяч долларов. Делюсь секретами.

Sampling — ваш лучший друг

Мы логировали все. Вообще все. Каждый request, каждый response. 2TB логов в день. $6,000 в месяц только за логи.

Потом мы включили мозг. DEBUG логи в production? Серьезно? Отключили. INFO логи для успешных запросов? Семплируем 1%. ERROR и WARNING — оставляем все.

Результат: 200GB логов в день. Экономия $4,500 в месяц. При этом мы не потеряли ни одного важного лога.

Custom metrics — это дорого

Каждая custom метрика в Datadog стоит денег. У нас был разработчик, который создал метрику для каждого эндпоинта, каждого статус-кода, каждого пользователя. 100,000 уникальных временных рядов. $5,000 в месяц только за его эксперименты.

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

Гибридный подход работает

Мы не отказались от self-hosted полностью. Критичные сервисы мониторятся Datadog — нам нужна 100% надежность. Но инфраструктурные метрики (CPU, память, диски) собирает Prometheus. Это дешевле и для таких метрик достаточно.

Логи application идут в Datadog, но nginx access логи — в self-hosted Loki. Они занимают 80% объема, но нужны редко.

Такой подход сократил наш счет с $38,000 до $22,000 в месяц. Экономия $192,000 в год!

Что я понял за эти годы

Observability — это не продукт, а подход. Можно купить Datadog за $100k в год и не иметь observability. А можно с помощью open source инструментов построить систему, которая реально помогает находить проблемы.

Дорого — не значит плохо. Да, $30,000 в месяц звучит как грабеж. Но если это позволяет 10 инженерам работать эффективнее и предотвращает один серьезный инцидент в месяц — оно того стоит.

Дешево — тоже не значит плохо. Для многих задач достаточно Prometheus + Grafana. Не нужно покупать Ferrari, чтобы ездить в магазин за хлебом.

Главное — это культура. Самый дорогой мониторинг не поможет, если разработчики не пишут нормальные логи, не добавляют трейсинг, не создают метрики. А если команда понимает важность observability, то и с базовыми инструментами можно творить чудеса.

Что выбрал бы я, начиная с нуля

Если бы я сейчас делал выбор для новой компании, вот мой подход:

До 50 серверов: Prometheus + Grafana + Loki. Максимум $1,000 в месяц, можно управиться одному человеку part-time.

50-200 серверов: Grafana Cloud или Elastic Cloud. $5,000-10,000 в месяц, но без головной боли с поддержкой.

200+ серверов: Datadog или New Relic для критичных сервисов, self-hosted для всего остального. $15,000-30,000 в месяц, но с полным контролем над расходами.

Enterprise (1000+ серверов): Однозначно гибридный подход. Коммерческое решение для product-facing сервисов, open source для инфраструктуры. И обязательно выделенная команда для оптимизации расходов.

Заключительная мысль

Когда-то я думал, что $100k в год за мониторинг — это безумие. Теперь я понимаю, что безумие — это не иметь нормальный мониторинг. Каждый серьезный инцидент может стоить сотни тысяч долларов. Каждый час простоя — это потерянные клиенты и репутация.

Но это не значит, что нужно покупать самое дорогое решение. Нужно покупать то, что решает ваши проблемы. Иногда это Prometheus за $0. Иногда это Datadog за $100k.

Главное — помните, за что вы платите. Не за красивые графики. Не за модные buzzwords. А за возможность спать спокойно, зная, что если что-то пойдет не так, вы узнаете об этом первым и сможете быстро найти и исправить проблему.

И да, тот вопрос с собеседования. Правильный ответ был: "Monitoring говорит, что что-то сломалось. Observability говорит, почему оно сломалось и как это починить." За возможность ответить на "почему" и "как" мы и платим эти безумные деньги. И знаете что? Оно того стоит.

Комментарии (4)


  1. NuGan
    28.10.2025 19:42

    Спасибо за статью, бальзам на душу. Один из самых частых вопросов наших клиентов: "зачем мне платить несколько миллионов рублей, если есть бесплатный Zabbix?"

    Мы в своей эволюции пришли к тем же выводам: наблюдаемость — это не набор тулов, а культура и архитектура данных. Важно, чтобы метрики, логи, трейсы и события “жили” в единой системе с контекстом CMDB и автоматизацией реакций. Только тогда возможна настоящая зонтичная Observability, где “не просто видно, что упало”, а понятно — почему, на кого повлияло, кто ответственный и что с этим делать.

    В наших российских реалиях это особенно актуально: многие компании уже прошли этап «собери свой Datadog из open-source», и теперь ищут устойчивую, поддерживаемую платформу, которая объединит инфраструктурный, бизнес- и прикладной мониторинг со сквозной аналитикой на уровне бизнес-сервиса.


  1. trabl
    28.10.2025 19:42

    Спасибо за статью, было интересно, особенно с точки зрения финансовой составляющей. 50-200 серверов в контексте данной статьи это что конкретно, физические серверы, VM в cloud или хосты k8s?


  1. Kenya-West
    28.10.2025 19:42

    О, спасибо, пойду логи Vector наконец для своих VPS'ок допилю...


  1. itGuevara
    28.10.2025 19:42

    Хотелось бы хотя бы базовую классификацию Observability и Monitoring.
    В условном HP OpenView Network Node Manager (Monitoring) что есть из класса Observability?