За 30 секунд#

Мониторинг: моя система работает? (да/нет)
Observability: почему моя система сломалась? (поиск корневой причины)
Логирование: что произошло? (запись событий)

Мониторинг отвечает на вопросы «да/нет». Observability позволяет задать любой вопрос о вашей системе. Логирование — это сбор данных; мониторинг и observability — это анализ.

Многие команды используют термины как синонимы. Это создаёт путаницу, раздувает бюджет и — что хуже — даёт слепые зоны во время аварий.

Почему это важно (реальная цена путаницы)

Ваша инженерная команда только что задеплоила код. Через 30 минут платежи начали тормозить. Происходит вот что:

Без observability (старая школа):

Алерт: «Время ответа Payment API >3 секунд»
Дежурный инженер открывает дашборд: видит график времени ответа. И всё.
Инженер начинает гадать: «Это БД? Сеть? Недавний деплой?»
Инженер вручную смотрит логи: 500 000 строк за 30 минут. Куда смотреть?
Через 45 минут отладки: новый код добавил медленный SQL-запрос
Длительность инцидента: 1 час. Потеря выручки: ~$7 000

С observability (современный подход):

Алерт: «Время ответа Payment API >3 секунд»
Дежурный открывает observability-дашборд
Дашборд автоматически подсказывает: «Новый код добавил N+1-запрос к таблице payment_verification»
Инженер сразу идёт к запросу и оптимизирует его
Длительность инцидента: 5 минут. Потеря выручки: ~$600

Разница: сэкономлено 55 минут + $6 400 выручки на одном инциденте.

Для компании с 2–3 инцидентами в месяц ROI observability легко превышает $100K в год.

Что такое мониторинг? (старый фундамент)

Мониторинг отвечает: моя система сейчас работает?

Мониторинг = логические (да/нет) вопросы

Сервер отвечает на запросы? (да/нет)
Время ответа <2 секунд? (да/нет)
Загрузка CPU БД <80%? (да/нет)
Уровень ошибок <1%? (да/нет)
Синтетический тест прошёл? (да/нет)

Как работает мониторинг

Собираем метрику: проверяем время ответа каждые 60 секунд
Сравниваем с порогом: если время ответа >2 с, отправляем алерт
Алерт при нарушении: будим дежурного

Мониторинг бинарен. Вы задаёте правила; система их применяет. Когда правило нарушено — приходит алерт. Это и есть мониторинг.

Ограничение мониторинга

Мониторинг говорит, что что-то не так, но не почему не так.

Пример:

Алерт: «CPU БД на 95%»
Мониторинг показывает: график CPU вверх
Но непонятно: почему CPU высок? какой запрос? какой пользователь? новый код? всплеск трафика?

Приходится копать вручную. Здесь и появляется observability.

Что такое observability? (современный подход)#

Observability отвечает: почему моя система не работает?

Observability = бесконечные вопросы#

Вместо «X — это правда?» — любой вопрос о поведении системы:

«Какой запрос вызвал всплеск CPU?»
«Почему время ответа выросло после этого деплоя?»
«Какие пользователи затронуты?»
«Что изменилось в системе за 2 минуты до алерта?»
«Какие запросы заняли >5 секунд за последний час?»
«Как сегодняшний уровень ошибок сравнивается с прошлой неделей в это же время?»

С observability вы можете ответить на ЛЮБОЙ вопрос о поведении системы.

3 столпа observability#

Столп 1: Метрики (что произошло, в цифрах)

Время ответа: 1,2 с
Уровень ошибок: 0,5%
Запросов к БД в секунду: 1 200
Использование памяти: 4,2 ГБ
Это агрегированные, обобщённые точки данных

Столп 2: Логи (что произошло, в деталях)

«Пользователь john@example.com вошёл»
«Запрос верификации платежа занял 1,2 с»
«Соединение с БД закрыто из-за таймаута»
Подробные, гранулярные события. Большой объём.

Столп 3: Трейсы (как запрос двигался по системе)

Пользователь отправляет платеж → API-обработчик → запрос к БД → вызов платёжного шлюза → email-сервис
Показывает полный путь запроса и где он провёл время
Распределённый трейсинг между сервисами

Как работает observability#

Инструментируйте всё: добавьте логирование во все ветки кода
Собирайте данные: метрики, логи и трейсы
Храните данные: долгосрочное хранение (недели/месяцы истории)
Свободный запрос: задавайте любые вопросы о поведении системы
Авто-корреляция: «Этот всплеск CPU коррелирует с этим участком кода; эта ошибка — с этим действием пользователя»

Мониторинг vs observability: рядом#

Аспект	Мониторинг	Observability
Тип вопроса	X — это правда?	Почему происходит X?
Точки данных	10–50 метрик	Миллионы точек
Время настройки	Быстро (1 час)	Дольше (1–2 недели)
Кривая обучения	Простая (дашборд)	Крутая (язык запросов)
MTTR (среднее время восстановления)	30–60 мин	5–10 мин
Цена	$100–500/мес	$1 000–5 000/мес
Лучше всего для	«Моя система жива?»	«Почему сломалась?»
Когда «вырастаешь»	>5 сервисов, >10 алертов	Работает и в масштабе

3-уровневая система (как реально работают команды)#

Уровень 1. Мониторинг (база — это нужно всем)#

Стандартный мониторинг доступности:

Доступность сайта: главная отвечает за <2 с?
Здоровье API: критичные эндпоинты отвечают?
Сторонние зависимости: Stripe доступен?
Базовая инфраструктура: CPU, память, диск

Примеры инструментов: UptimeRobot, Pingdom, Hyperping, Datadog (базовый тариф)

Цена: $20–100/мес

Время настройки: 1–2 часа

Когда нужно: с 1-го дня, маленький стартап с 1–2 сервисами

Уровень 2. Базовое логирование (детали — скорее всего, тоже нужно)#

Когда мониторинг говорит, что что-то не так, куда смотреть?

Логи показывают, что произошло:

Сообщения об ошибках: «Database connection timeout»
Детали запроса: ID пользователя, путь, код ответа
Бизнес-события: «пользователь купил товар», «платеж не прошёл»
Системные события: «сервер запущен», «давление по памяти»

Примеры инструментов: Datadog, New Relic, Better Stack, ELK Stack

Цена: $100–500/мес

Время настройки: 2–4 часа (базово), 1–2 недели (всеобъемлюще)

Когда нужно: мониторинг алертит 5+ раз в день, и не получается найти корневую причину

Уровень 3. Полноценный observability (понимание — нужен в масштабе)#

Когда есть логи, хочется коррелировать их с метриками и трейсами.

Observability позволяет:

Видеть, какой код вызвал алерт
Понимать, как запрос прошёл через 10 сервисов
Связывать поведение пользователей → поведение приложения → влияние на инфраструктуру

Примеры инструментов: Datadog (full stack), Dynatrace, New Relic, Splunk

Цена: $1 000–10 000+/мес

Время настройки: 2–4 недели (всеобъемлюще)

Когда нужно: >10 микросервисов, >5 инженеров, сложная распределённая система

Реальный пример: алерт на время ответа API#

Сценарий: время ответа платёжного API подскочило до 3 секунд (норма — 500 мс)

Только с мониторингом

Алерт: «время ответа Payment API 3000 мс»
Видим: график времени ответа со всплеском
Думаем: «БД? всплеск нагрузки? баг?»
Проверяем: CPU сервера (норма), память (норма), соединения (норма)
Проверяем: недавние деплои (за 2 часа — нет)
Проверяем: логи трафика (трафик удвоился)
Проверяем: логи БД (много запросов про payment_verification)
НАКОНЕЦ: находим медленный запрос в логах
Время: 45 минут

С observability#

Алерт: «время ответа Payment API 3000 мс»
Видим: observability-дашборд автоматически показывает:
  - Какой код медленный: payment_verification
  - Какой запрос: SELECT * FROM users ... (обнаружен N+1-запрос)
  - Какой пользователь триггернул: john@example.com
  - Когда началось: ровно во время деплоя нового кода
  - Затронуто запросов: 150 из 2000
Видим: трейс с точным стектрейсом медленного кода
Чиним: оптимизируем запрос
Время: 5 минут

Разница:

Без observability: 45 минут до корневой причины
С observability: 5 минут до корневой причины
Сэкономленная выручка: ~$6 500 на одном инциденте

Логирование: фундамент (но это не мониторинг и не observability)#

Логирование — сбор данных. Мониторинг и observability — анализ данных.

Что такое логирование

Запись событий в централизованное место:

// In your application
logger.info("User logged in", {
  user_id: "12345",
  timestamp: "2026-02-20T14:23:45Z",
  ip_address: "203.0.113.42"
})

logger.error("Payment verification failed", {
  user_id: "12345",
  amount: 99.99,
  error: "Stripe API timeout",
  duration_ms: 5000
})

Логи пишутся. Хранятся. Доступны для поиска.

Ограничения логирования

Слишком много данных: типичное веб-приложение выдаёт 1 000+ строк логов в секунду. Искать по 1 млн строк в час — мучение.

Нет контекста: строка лога говорит «платеж не прошёл», но не говорит, это часть атаки, системная проблема или одиночный сбой.

Нет корреляции: одна строка про сбой платежа не показывает 500 похожих сбоев одновременно.

Логирование — фундамент observability#

Хорошее логирование нужно, чтобы построить observability. Но одно логирование — не observability.

Когда что использовать (дерево решений)

Только начинаете?
├─ Да → используйте только мониторинг
│       (UptimeRobot, Hyperping)
│       Фокус: жива ли система?
│       Цена: $20–50/мес
│       Настройка: 1 час

Чините 5+ инцидентов в месяц?
├─ Да → добавьте логирование
│       (Datadog, Better Stack)
│       Фокус: что произошло?
│       Цена: +$100–300/мес
│       Настройка: 2–4 часа базово, 1–2 недели всеобъемлюще

Запускаете >5 микросервисов или >10 инженеров?
├─ Да → переходите к observability
│       (Datadog full stack, Dynatrace, Splunk)
│       Фокус: почему это случилось?
│       Цена: $1 000+/мес
│       Настройка: 2–4 недели

Enterprise-масштаб (100+ инженеров)?
└─ Да → нужно всё
        (полный observability + специализированные инструменты)
        Цена: $5 000+/мес
        Настройка: постоянно, 1–2 выделенных человека

Распространённые заблуждения

Заблуждение 1. «Observability — это просто крутое логирование»#

Реальность: observability — это сочетание метрик + логов + трейсов плюс возможность автоматически их коррелировать.

Логирование — часть observability, но не всё. Также нужны метрики (время ответа, уровень ошибок) и трейсы (распределённый трейсинг).

Заблуждение 2. «Больше логов = лучше observability»#

Реальность: 1 миллион строк логов бесполезен, если по ним нельзя искать. Качество > количество.

Логируйте стратегически:

Ошибки (всегда)
Бизнес-события (покупка, вход, платеж)
Проблемы производительности (медленные запросы, таймауты)
Не логируйте каждый вызов функции (это шум)

Заблуждение 3. «Мониторинг ловит любые проблемы»#

Реальность: мониторинг ловит проблемы, попадающие под ваши правила. То, что вне правил, не замечается.

Пример: правило «алерт, если время ответа >3 с». Но норма — 1,5 с, а после деплоя — 2,5 с. Это +67%, но порог не пройден. Мониторинг не алертит. Observability — алертит.

Заблуждение 4. «Observability заменяет мониторинг»#

Реальность: observability требует мониторинга как фундамента.

Алерты по критичным проблемам всё равно нужны. Но плюс к ним нужна возможность расследовать.

Заблуждение 5. «Observability обязательно дорого»#

Реальность: есть много open-source инструментов. Можно построить свой стек.

Но они требуют усилий на поддержку. Для большинства команд SaaS-платформы observability ($1 000–5 000/мес) дешевле, чем нанимать человека для поддержки инфраструктуры.

Стратегия построения observability#

Этап 1. Фундамент мониторинга (месяц 1)#

Базовый мониторинг доступности
Мониторинг критичных эндпоинтов
Подтверждение из 3 регионов (исключение ложных тревог)
Маршрутизация алертов (critical = page, warning = Slack)

Цена: $50/мес Инструменты: UptimeRobot, Hyperping или Nova Uptime

Этап 2. Добавьте логирование (месяцы 2–3)#

Структурированное логирование в коде
Логирование ошибок, бизнес-событий, метрик производительности
Агрегация логов
Дашборды для поиска по логам

Цена: +$100–200/мес Инструменты: Datadog, Better Stack, ELK Stack

Этап 3. Распределённый трейсинг (месяцы 4–6)#

Добавьте трейсинг для запросов между сервисами
Свяжите трейсы с логами
Найдите бутылочные горлышки в потоке запросов

Цена: +$200–500/мес Инструменты: Datadog, New Relic, Jaeger

Этап 4. Полный observability (с месяца 6)#

Метрики + логи + трейсы вместе
Автоматические алерты на аномалии
ML-анализ корневых причин
Исторический анализ и обнаружение трендов

Цена: $1 000–5 000+/мес Инструменты: Datadog, Dynatrace, Splunk

Сравнение инструментов observability (2026)#

Инструмент	Мониторинг	Логи	Трейсы	Цена	Лучше всего для
UptimeRobot	Отлично	Нет	Нет	$10/мес	Простые сайты
Hyperping	Отлично	Ограниченно	Нет	$24/мес	SaaS, API-команды
Datadog	Отлично	Отлично	Отлично	от $100	Enterprise, всё в одном
Better Stack	Отлично	Отлично	Ограниченно	$50/мес	Mid-market
New Relic	Отлично	Отлично	Отлично	от $100	Enterprise APM
Splunk	Ограниченно	Отлично	Отлично	от $200	Enterprise, анализ данных
ELK Stack	Нет	Отлично (self-hosted)	Ограниченно	self-hosted	Бюджетные команды
Dynatrace	Отлично	Отлично	Отлично	от $500	Крупный enterprise
Grafana	Отлично	Ограниченно	Ограниченно	от $50 (self-hosted)	Любители open-source

Итог: мониторинг vs observability#

Мониторинг = «моя система работает?» (да/нет)

10–50 метрик
Алерты по правилам
Простые дашборды
Отлично для сайтов и простых приложений
Цена: $20–100/мес

Observability = «почему моя система сломалась?» (корневая причина)

Миллионы точек данных
Свободные запросы
Сложные дашборды
Обязательно для микросервисов
Цена: $1 000–5 000+/мес

Логирование = «что произошло?» (сбор данных)

Сырые события
История с поиском
Фундамент observability
Нужно для отладки

Большинству команд нужно: мониторинг + логирование как база, потом observability по мере роста.

Когда апгрейдиться:

Только мониторинг: 1–2 сервиса
- Логирование: 3–5 сервисов, 2–3 инженера
- Observability: >10 сервисов, >5 инженеров, сложные зависимости

Не вкладывайтесь слишком рано в observability (дорого и сложно). Не тяните слишком долго (MTTR ухудшается с ростом сложности).

Дальнейшие шаги

Если у вас только мониторинг: добавьте структурированное логирование на этой неделе. Дёшево и эффективно.
Если есть логи: соберите дашборд для корреляции ошибок с деплоями. Начните понимать корневые причины.
Если в масштабе: инвестируйте в распределённый трейсинг. Это ключ к отладке сложных систем.

Готовы перейти от мониторинга к observability? Начните с мониторинга доступности от Nova Uptime как фундамента, затем наслаивайте логирование и трейсинг по мере роста.