Мониторинг и observability веб-приложения

Коротко. Мониторинг отвечает на вопрос «работает ли система» по заранее заданным метрикам и алертам. Observability (наблюдаемость) позволяет выяснить, почему система ведёт себя именно так, даже в ситуации, которую никто не предвидел. Для этого нужны метрики, логи, трейсы и данные реальных пользователей, связанные общим trace_id. Внедрять наблюдаемость стоит поэтапно, начиная с четырёх золотых сигналов.

Чем быстрее команды выпускают код, тем чаще он ломается в продакшене: в отчёте New Relic Observability Forecast 2026, где опрошены 2 575 IT- и инженерных руководителей, 78% команд говорят о росте числа инцидентов на фоне ускорения разработки. Там же отмечено, что каждая четвёртая команда запускает AI-агентов в продакшен вообще без мониторинга. Инженеры Google ещё в книге Site Reliability Engineering поставили мониторинг в основание иерархии надёжности сервиса: без него команда просто не знает, работает ли продукт. Мониторинг и observability веб-приложения — это способ увидеть её изнутри.

Для бизнеса проблема выглядит буднично: о падении оплаты или медленной корзине чаще всего узнают от клиентов, а не от собственных систем. Каждая минута между началом сбоя и его обнаружением — это потерянные заказы, звонки в поддержку и подорванное доверие. Поэтому в SRE-поддержку и мониторинг по SLA мы закладываем наблюдаемость с первого дня: без неё обещания по времени реакции и восстановления остаются словами.

Ниже разберём, чем мониторинг отличается от observability, какие сигналы собирать (метрики, логи, трейсы, RUM и синтетику), как связать их в одно расследование инцидента, что мониторить по слоям приложения, как настроить алерты, которым доверяет команда, и какой стек выбрать с учётом российских реалий. В качестве опоры используем открытый стандарт телеметрии, описанный в Observability Primer проекта OpenTelemetry.

Что такое мониторинг веб-приложения

Мониторинг веб-приложения — это сбор, обработка и отображение количественных данных о работе системы в реальном времени (число и типы запросов, ошибки, время ответа, загрузка ресурсов). Так его определяет Google SRE Book, а на практике к сбору данных всегда добавляют автоматическое оповещение, когда показатели выходят за допустимые границы. Задача мониторинга — заметить проблему раньше пользователя и подсказать, где искать.

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

Белый и чёрный ящик

Google SRE Book делит мониторинг на два вида, и в веб-приложении нужны оба:

Black-box (чёрный ящик) — проверка снаружи, глазами пользователя: открывается ли главная страница, проходит ли авторизация, отвечает ли API. Такой мониторинг показывает, что проблема уже есть и пользователи её чувствуют.
White-box (белый ящик) — данные изнутри системы: метрики приложения, логи, состояние очередей, пул соединений с базой. Он помогает увидеть надвигающуюся проблему и найти её причину.

Только чёрный ящик скажет «сайт лежит», но не скажет почему. Только белый ящик покажет сотни графиков, но может пропустить сбой, который видит пользователь (например, неверно настроенный CDN). Поэтому внешние проверки и внутренняя телеметрия дополняют друг друга.

Четыре золотых сигнала Google SRE

Если мониторить можно только четыре показателя пользовательской системы, Google SRE рекомендует выбрать эти. Для веб-приложения они выглядят так:

Latency (задержка) — время обработки запроса. Смотрят не среднее, а перцентили: p95 и p99 времени ответа API. Отдельно считают задержку успешных и неуспешных запросов: быстрый ответ с ошибкой не должен «улучшать» статистику.
Traffic (трафик) — нагрузка на систему: запросы в секунду (RPS) к API, число активных сессий, сообщений в очереди.
Errors (ошибки) — доля неуспешных запросов. Google выделяет три типа: явные (HTTP 500), неявные (ответ 200 с неверным содержимым — например, пустая корзина вместо товаров) и ошибки «по политике» (ответ пришёл, но медленнее обещанной секунды).
Saturation (насыщение) — насколько система близка к пределу: загрузка CPU и памяти, заполненность пула соединений с базой данных, длина очереди фоновых задач.

У мониторинга есть встроенное ограничение: он отвечает только на те вопросы, которые вы задали заранее. Когда у части пользователей из одного региона на одной версии браузера падает оплата через конкретный банк, дашборд «доля 5xx» может даже не шелохнуться. Здесь и начинается observability.

Что такое observability и чем она отличается от мониторинга

Observability (наблюдаемость) — это свойство системы, позволяющее понять её внутреннее состояние по внешним выходам — телеметрии, которую она производит. Такое определение даёт OpenTelemetry: если по метрикам, логам и трейсам можно ответить на любой новый вопрос о поведении системы, не дописывая код и не выкатывая релиз, система наблюдаема.

Главное отличие — в типе вопросов. Мониторинг работает с «известными неизвестными» (known unknowns): мы знаем, что база может упасть, и следим за ней. Observability нужна для «неизвестных неизвестных» (unknown unknowns): проблем, которые никто не предвидел и под которые нет готового графика.

Параметр	Мониторинг	Observability
На какой вопрос отвечает	«Работает ли система?» «Что сломалось?»	«Почему система ведёт себя так?» «Кого и как это затронуло?»
Данные	Агрегированные метрики, проверки доступности	Метрики, логи, трейсы, RUM — с богатым контекстом и общими идентификаторами
Когда полезен	Типовые, ожидаемые сбои	Новые, редкие, сложные сбои в распределённых системах
Тип проблем	Known unknowns — известные риски	Unknown unknowns — непредвиденные ситуации
Кто пользуется	Дежурный, администраторы, поддержка	Разработчики, SRE, продуктовая команда
Как реагирует	Алерт по порогу	Исследование: срез по любому атрибуту, переход от метрики к трейсу и логу
Стоимость	Ниже: метрики компактны	Выше: логи и трейсы требуют хранения и дисциплины инструментирования

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

Зачем мониторинг и observability нужны бизнесу

Мониторинг и observability нужны бизнесу, чтобы сокращать время от начала сбоя до его обнаружения и устранения, а значит — потери выручки и репутации. Для технической команды это инструмент, для владельца продукта — страховка и источник данных для решений.

Меньше MTTD и MTTR. MTTD (mean time to detect) — среднее время до обнаружения инцидента, MTTR (mean time to restore) — до восстановления. Наблюдаемость сокращает оба: алерт срабатывает раньше жалоб клиентов, а причина находится за минуты, а не за часы перебора гипотез.
Защита выручки в часы пик. Распродажа, рассылка, рекламная кампания — именно тогда нагрузка максимальна и цена каждой минуты простоя выше всего.
Релизы без страха. Когда видно, как новая версия влияет на ошибки и время ответа, можно выпускать чаще и мельче. Особенно в связке с постепенной раскаткой, о которой мы писали в статье о feature flags и безопасном выпуске функций.
Выполнение SLA. Если вы обещаете клиентам доступность 99,9%, её нужно измерять — иначе спор о нарушении SLA решается мнениями, а не данными.
Планирование мощностей. Тренды трафика и насыщения показывают, когда пора масштабироваться, и помогают не переплачивать за лишние серверы.
Данные для продукта. Время загрузки страниц, ошибки в браузере и провалы в воронке оформления заказа — это не только инженерные, но и продуктовые сигналы.

Посчитаем цену часа простоя на условном примере (цифры не статистика, а иллюстрация метода). Интернет-магазин получает 60 заказов в час со средним чеком 4 000 ₽ — это 240 000 ₽ выручки в час. Если оплата тихо не работает 3 часа, потому что никто не заметил ошибку платёжного шлюза, потери составят около 720 000 ₽. К ним добавятся компенсации, расходы на рекламу, которая вела трафик в пустоту, и ушедшие к конкурентам клиенты. Алерт на падение числа успешных оплат сократил бы этот интервал до нескольких минут.

Рынок тоже голосует за вложения в наблюдаемость: по данным того же New Relic Observability Forecast 2026, лидеры по зрелости observability получают более чем трёхкратную отдачу на вложения в неё. При этом среднее число инструментов наблюдаемости в компаниях выросло с 4,4 до 5,0. Это значит, что рядом с пользой растёт и риск «зоопарка», который сам по себе требует порядка.

Метрики, логи и трейсы: три столпа observability

Три столпа observability — это метрики, логи и трейсы: три типа телеметрии, которые отвечают на разные вопросы и по-разному стоят в хранении. По отдельности каждый столп даёт частичную картину, вместе — полную.

Метрики, логи и трейсы сходятся в единую картину observability

Метрики — числа во времени

Метрика — это числовое измерение, собранное через равные промежутки времени: число запросов, доля ошибок, время ответа, загрузка CPU. Метрики компактны, их дёшево хранить годами, по ним строят дашборды и алерты.

Основные типы метрик:

Counter (счётчик) — только растёт: всего запросов, всего ошибок. Из него считают скорость (запросы в секунду).
Gauge (датчик) — текущее значение, которое растёт и падает: занятая память, длина очереди, активные соединения.
Histogram (гистограмма) — распределение значений по корзинам: из неё получают перцентили времени ответа.

Ключевое правило — смотреть на перцентили, а не на среднее. Если 95 запросов из 100 выполняются за 100 мс, а 5 — за 10 секунд, среднее покажет вполне приличные 0,6 секунды. А p99 покажет, что каждый сотый пользователь ждёт 10 секунд и, скорее всего, уходит.

Логи — события с контекстом

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

Логи должны быть структурированными, то есть машиночитаемыми, обычно в формате JSON, а не свободным текстом. Тогда их можно фильтровать по полям и связывать с трейсами. Пример записи:

{
  "timestamp": "2026-10-24T09:41:07.312Z",
  "level": "error",
  "msg": "payment gateway timeout",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "user_id": "u_1842",
  "route": "POST /api/checkout",
  "duration_ms": 30012
}

Обратите внимание на trace_id: именно он связывает эту строку лога с трейсом запроса. А user_id — внутренний псевдонимный идентификатор, а не телефон или email: персональные данные в логах создают и риски утечки, и обязанности по 152-ФЗ.

Трейсы — путь одного запроса

Трейс (распределённая трассировка) — это запись пути одного запроса через все компоненты системы: фронтенд, API-шлюз, сервисы, базу данных, внешние API. Трейс состоит из спанов (span) — отрезков работы с началом, длительностью и атрибутами. По трейсу видно, на каком именно шаге запрос провёл 29 из 30 секунд.

Чтобы трейс не обрывался на границе сервиса, нужен context propagation: идентификатор трейса передаётся дальше в заголовках запросов (стандарт W3C Trace Context). Особенно это важно в распределённых системах — подробнее об их устройстве в статье о выборе между микросервисами и монолитом. Хранить трейсы каждого запроса дорого, поэтому применяют сэмплирование: сохраняют, например, все трейсы с ошибками и медленные, а из остальных — небольшую долю.

Столп	Отвечает на вопрос	Пример	Стоимость хранения	Типичный инструмент
Метрики	Что происходит и насколько всё плохо?	p95 ответа API вырос с 300 мс до 2 с	Низкая	Prometheus, VictoriaMetrics
Логи	Что именно произошло в конкретном событии?	«payment gateway timeout» для POST /api/checkout	Высокая: главная статья расходов	Loki, ELK / OpenSearch
Трейсы	Где в цепочке теряется время или возникает ошибка?	Спан вызова платёжного шлюза — 29,8 с	Средняя, регулируется сэмплированием	Tempo, Jaeger

Как мониторить фронтенд: RUM, Core Web Vitals и синтетика

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

RUM (Real User Monitoring) — сбор метрик производительности и ошибок прямо из браузеров реальных посетителей. Небольшой скрипт на странице отправляет данные о загрузке, взаимодействиях и исключениях. RUM показывает реальный опыт людей на разных устройствах, сетях и в разных регионах.

Основа пользовательских метрик — Core Web Vitals. Google считает опыт «хорошим», если на 75-м перцентиле визитов выполняются три порога:

LCP (Largest Contentful Paint) — отрисовка основного контента не позже 2,5 секунды;
INP (Interaction to Next Paint) — отклик на действия пользователя не дольше 200 мс;
CLS (Cumulative Layout Shift) — сдвиг макета не больше 0,1.

Эти показатели влияют не только на удобство, но и на поиск — подробно о них в статье о Core Web Vitals и их влиянии на позиции сайта. Помимо них RUM собирает JavaScript-ошибки в браузере: необработанные исключения, упавшие запросы к API, ошибки загрузки ресурсов. Если к событию на фронтенде прикреплён trace_id, медленный клик можно проследить до конкретного запроса к базе.

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

Параметр	RUM	Синтетический мониторинг
Источник данных	Браузеры реальных пользователей	Роботы-проверки по расписанию
Что показывает	Фактический опыт на разных устройствах и сетях	Доступность и работоспособность ключевых сценариев
Когда незаменим	Оптимизация скорости, поиск ошибок у части аудитории	Ночью, до релиза, на редко посещаемых страницах
Ограничения	Нет данных, если нет трафика; шум от медленных устройств	Не отражает разнообразие реальных условий

Как связать сигналы: trace_id и расследование инцидента

Связка сигналов — это возможность за несколько кликов перейти от аномалии на графике к конкретному запросу и строке лога, которые её объясняют. Её обеспечивают общие идентификаторы: trace_id в логах и спанах, единые атрибуты сервиса, версии и окружения во всей телеметрии.

Вот как выглядит типичное расследование, когда сигналы связаны:

Срабатывает алерт. p95 времени ответа POST /api/checkout больше 10 минут держится выше 2 секунд при норме 400 мс. Дежурный получает уведомление.
Дашборд показывает масштаб. Трафик обычный, доля 5xx выросла незначительно, но падает число успешных оплат. Проблема затрагивает только оформление заказа.
Переход к медленному трейсу. С графика задержки дежурный открывает пример медленного запроса. Связь графика и конкретного трейса дают exemplars — ссылки на trace_id, сохранённые рядом с точкой метрики.
Поиск проблемного спана. В трейсе видно: запрос к базе занял 40 мс, а вызов внешнего платёжного шлюза — 29,8 секунды до таймаута.
Логи по trace_id. Фильтр логов по идентификатору трейса показывает: «payment gateway timeout» и повторные попытки соединения.
Причина и фикс. Срез трейсов по атрибуту показывает, что проблема только у одного эквайера. Команда переключает оплату на резервного провайдера и уменьшает таймаут, чтобы пользователи не ждали по 30 секунд.
Постмортем. После инцидента команда без поиска виноватых разбирает хронологию и добавляет алерт на долю успешных оплат по каждому провайдеру и runbook на переключение.

Без связанных сигналов шаги 3–5 превращаются в ручной поиск по десяткам логов разных сервисов в окне «примерно в 14:20». С trace_id расследование занимает минуты, а не часы.

Что мониторить в веб-приложении: чек-лист по слоям

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

Слой	Что мониторить
Пользователь и фронтенд	LCP, INP, CLS по RUM; JS-ошибки; доля упавших запросов из браузера; uptime и сценарные синтетические проверки
API и бэкенд	Четыре золотых сигнала по каждому эндпоинту: RPS, p95/p99 задержки, доля 4xx/5xx, насыщение воркеров; ошибки и исключения
База данных и кэш	Медленные запросы, пул соединений, блокировки, репликационная задержка, доля попаданий в кэш, заполненность диска
Очереди и фоновые задачи	Длина очереди, возраст самого старого сообщения, доля упавших задач, время выполнения cron-задач и факт их запуска
Инфраструктура и Kubernetes	CPU, память, диск, сеть; перезапуски и OOM-килы контейнеров; поды в статусе не Ready; сроки действия TLS-сертификатов
Внешние зависимости	Время ответа и доля ошибок платёжных шлюзов, SMS-провайдеров, API партнёров, служб доставки — отдельно по каждому
Бизнес-метрики	Заказы в минуту, конверсия checkout, успешные оплаты, регистрации, отправленные письма — в сравнении с тем же временем неделю назад

Последний слой стоит выделить особо. Бизнес-метрики часто первыми показывают тихий сбой: все сервисы «зелёные», ошибок нет, а заказов стало вдвое меньше. Причиной может оказаться сломанная кнопка в одном браузере, просроченный промокод или ответ 200 с пустым списком товаров — та самая неявная ошибка из классификации Google SRE.

Как настроить алерты, чтобы команда им доверяла

Хороший алерт — это уведомление, которое сообщает о реальной или неизбежной проблеме для пользователей и требует конкретного действия человека. Всё остальное должно быть на дашбордах и в отчётах, а не будить дежурного.

Главное правило: алертить на симптомы, а не на причины. «Доля ошибок оформления заказа выше 2%» — симптом, который видят пользователи. «CPU сервера 85%» — возможная причина, которая может ни на что не влиять. Перед тем как завести алерт, задайте ему три вопроса:

Это срочно? Нужно ли действовать прямо сейчас, или проблема подождёт до утра?
Понятно, что делать? Есть ли у дежурного runbook — инструкция с первыми шагами диагностики и восстановления?
Это влияет на пользователей? Если нет и не повлияет в ближайшие часы — это не алерт, а задача в бэклог.

Уровень	Пример	Время реакции	Канал
P1 — критический	Сайт недоступен, не проходят оплаты	Немедленно, круглосуточно	Звонок и пуш дежурному, эскалация
P2 — высокий	Деградация ключевого сценария, рост ошибок у части пользователей	В течение часа	Пуш дежурному, канал инцидентов
P3 — средний	Медленная второстепенная страница, растёт очередь фоновых задач	В рабочее время	Рабочий чат команды
P4 — низкий	Сертификат истекает через 20 дней, диск заполнен на 70%	Плановая задача	Тикет, еженедельный отчёт

Главный враг алертинга — alert fatigue, усталость от уведомлений. Когда дежурному за ночь приходит 40 сообщений, из которых 38 не требуют действий, он перестаёт их читать — и пропускает два важных. Шумные алерты нужно регулярно пересматривать: удалять, повышать пороги, объединять, переводить в отчёты. Каждый алерт должен ссылаться на свой runbook.

Следующий уровень зрелости — алерты по SLO. SLI (индикатор) — измеряемый показатель качества, например доля запросов быстрее 500 мс. SLO (цель) — его целевое значение, например 99,5% за 30 дней. Разница между 100% и SLO — бюджет ошибок: алерт срабатывает, когда бюджет сгорает слишком быстро, а не на каждый всплеск. Подробнее об SLI, SLO и SLA и о том, как они живут в сопровождении проекта, — в статье о том, что включает SRE-поддержка после релиза.

Какой стек выбрать: open source, облако или SaaS

Стек observability — это набор инструментов для сбора, хранения, визуализации телеметрии и оповещений. Выбирают его по трём критериям: масштаб системы, наличие людей для администрирования и требования к хранению данных. Для российских проектов к ним добавляются доступность оплаты зарубежных сервисов и 152-ФЗ.

Задача	Open source / self-hosted	Managed в РФ	Зарубежный SaaS
Метрики	Prometheus, VictoriaMetrics	Yandex Cloud Monitoring, мониторинг VK Cloud	Datadog, New Relic
Дашборды	Grafana	Встроенные дашборды облака, Managed Grafana у ряда провайдеров	Встроены в платформу
Логи	Loki, ELK / OpenSearch	Yandex Cloud Logging, логирование VK Cloud	Встроены в платформу
Трейсы	Tempo, Jaeger	Приём трейсов по OpenTelemetry — уточняйте у провайдера	APM платформы
Сбор телеметрии	OpenTelemetry SDK и OpenTelemetry Collector — общий стандарт для всех вариантов
Ошибки приложения	Sentry (self-hosted)	—	Sentry SaaS и аналоги
Алерты	Alertmanager, Grafana Alerting	Алертинг облака	Встроены в платформу

Общий знаменатель всех вариантов — OpenTelemetry. Это открытый вендор-нейтральный стандарт проекта CNCF: SDK для инструментирования кода и Collector для приёма, обработки и отправки телеметрии. Если инструментировать приложение через OpenTelemetry, хранилище и интерфейс можно поменять позже, не переписывая код.

С зарубежными SaaS вроде Datadog и New Relic у российских компаний две оговорки. Во-первых, оплата и заключение договора из РФ могут быть затруднены. Во-вторых, логи и трейсы нередко содержат персональные данные (IP-адреса, идентификаторы, иногда — по ошибке — телефоны и email). Их отправка за рубеж — трансграничная передача, которую нужно оценивать по 152-ФЗ. Поэтому мы чаще рекомендуем self-hosted-стек или российское облако.

Self-hosted или managed: плюсы и минусы

Self-hosted (Prometheus, Grafana, Loki, Tempo). Плюсы: данные в своём контуре, нет платы за объём, полный контроль над retention. Минусы: стек нужно разворачивать, обновлять, масштабировать и бэкапить — это время инженеров.
Managed в российском облаке. Плюсы: быстрый старт, не нужно администрировать хранилища, данные в РФ. Минусы: оплата за объём телеметрии, привязка к провайдеру, возможности уже, чем у специализированных платформ.
Зарубежный SaaS. Плюсы: максимум функций «из коробки», включая APM и AI-анализ. Минусы: стоимость при росте объёмов, сложности с оплатой из РФ, вопросы 152-ФЗ.

Если своей команды эксплуатации нет, настройку и поддержку стека мониторинга можно отдать на DevOps-аутсорсинг: тогда инфраструктура наблюдаемости разворачивается вместе с CI/CD и окружениями, а не собирается по кусочкам после первой аварии.

Структура затрат на observability

Конкретные цены провайдеров часто меняются, поэтому полезнее понимать, из чего складываются расходы и чем ими управлять:

Хранение логов — обычно главная статья расходов. Управляется уровнем логирования в продакшене (без debug), отказом от логирования каждого успешного запроса и сроком хранения (retention): горячие логи — дни или недели, архив — дольше.
Трейсы — регулируются сэмплированием: все ошибки и медленные запросы плюс небольшая доля остальных.
Метрики — стоимость растёт от кардинальности, то есть числа уникальных комбинаций меток. Одна метка с user_id превращает одну метрику в миллионы временных рядов.
Люди — время инженеров на поддержку стека, разбор алертов и инструментирование кода. Эту статью часто забывают, а она нередко больше инфраструктурной.

Как внедрить observability по шагам

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

Определите критичные сценарии и SLI. Выпишите 3–5 пользовательских путей, от которых зависит выручка: вход, поиск, корзина, оплата. Для каждого решите, что считать успехом и какая задержка приемлема.
Включите uptime-пробы и четыре золотых сигнала. Внешние проверки ключевых страниц и сценариев из нескольких регионов плюс задержка, трафик, ошибки и насыщение по основным эндпоинтам. Добавьте алерты P1 на полную недоступность.
Сделайте логи структурированными и добавьте trace_id. Единый JSON-формат во всех сервисах, общие поля (сервис, версия, окружение, маршрут), маскирование персональных данных и секретов.
Инструментируйте сервисы через OpenTelemetry. Начните с автоинструментирования для вашего языка и фреймворка: оно сразу даёт спаны HTTP-запросов, обращений к базе и внешним API. Затем добавьте ручные спаны и атрибуты в ключевую бизнес-логику.
Подключите RUM на фронтенде. Core Web Vitals и JS-ошибки из браузеров реальных пользователей, с передачей trace_id в запросы к API.
Настройте алерты по SLO, runbook и дежурство. Алерты на симптомы и сжигание бюджета ошибок, у каждого — инструкция и ответственный; график дежурств и правила эскалации.
Проводите постмортемы и чистите шум. После каждого инцидента — разбор без поиска виноватых и действия по итогам. Раз в месяц — ревизия алертов и дашбордов: что не срабатывало по делу, то удаляется или переделывается.

Ориентировочный таймлайн для типичного веб-приложения выглядит так:

Первые 2 недели — шаги 1–2: команда перестаёт узнавать о падениях от клиентов.
Первый месяц — шаги 3–4: появляется возможность быстро находить причину, а не только факт сбоя.
Первый квартал — шаги 5–7: видна картина глазами пользователя, алерты работают по SLO, а процесс улучшения становится регулярным.

Типичные ошибки при построении мониторинга

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

Средние значения вместо перцентилей. Среднее время ответа скрывает «хвост» медленных запросов. Правильно: p95 и p99 для задержки, отдельно для успешных и неуспешных запросов.
Логи без структуры и без trace_id. Свободный текст невозможно надёжно фильтровать и связать с конкретным запросом. Правильно: JSON-логи с едиными полями и идентификатором трейса.
Алерт на каждый чих. Десятки уведомлений о CPU и памяти приучают команду их не читать. Правильно: алерты на пользовательские симптомы, остальное — на дашборды.
Персональные данные и секреты в логах. Телефоны, email, токены и пароли в логах — риск утечки и нарушение 152-ФЗ. Правильно: маскирование на уровне логгера или Collector и псевдонимные идентификаторы.
Взрыв кардинальности метрик. user_id, order_id или полный URL с параметрами в метках метрики создают миллионы временных рядов и кладут хранилище. Правильно: такие поля — в логи и атрибуты трейсов, а в метки — только ограниченные наборы значений (маршрут, код ответа, сервис).
Мониторинг только инфраструктуры. Серверы здоровы, а заказов нет — и никто не знает. Правильно: бизнес-метрики (заказы, оплаты, регистрации) на главном дашборде и с алертами.
Observability «потом, после релиза». Добавлять трассировку и структурные логи в работающий продакшен дороже и рискованнее. Правильно: закладывать телеметрию в архитектуру и критерии готовности задачи с первого спринта.

Частые вопросы о мониторинге и observability

Чем observability отличается от мониторинга простыми словами?

Мониторинг следит за заранее выбранными показателями и сообщает, когда они выходят за норму: он отвечает на вопрос «что сломалось». Observability позволяет по метрикам, логам и трейсам выяснить, почему система ведёт себя именно так, даже если такой проблемы раньше не было. Мониторинг — часть observability, а не её альтернатива.

Нужна ли observability небольшому сайту или MVP?

Полноценный стек с трассировкой на старте обычно избыточен, но минимальный набор нужен любому продукту, который зарабатывает деньги. Это uptime-проверки ключевых страниц, сбор ошибок приложения и фронтенда, структурированные логи и алерт на недоступность. Если сразу использовать OpenTelemetry, трейсы и метрики можно включить позже без переписывания кода.

Что такое OpenTelemetry и обязательно ли его использовать?

OpenTelemetry — открытый вендор-нейтральный стандарт проекта CNCF для сбора метрик, логов и трейсов: SDK для языков программирования и Collector для обработки и отправки данных. Он не обязателен, но избавляет от привязки к конкретному поставщику: приложение инструментируют один раз, а хранилище и интерфейс можно сменить, не трогая код.

Сколько хранить логи и метрики?

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

Можно ли использовать Datadog или New Relic в России?

Технически их агенты работают, но у российских компаний есть две сложности: оплата и заключение договора из РФ, а также трансграничная передача данных. Логи и трейсы часто содержат персональные данные, поэтому их отправку за рубеж нужно оценивать по 152-ФЗ. Многие проекты поэтому выбирают self-hosted-стек на Prometheus, Grafana, Loki и Tempo или российское облако.

С чего начать, если мониторинга нет совсем?

Начните с внешних uptime-проверок главной страницы и ключевых сценариев, сбора ошибок приложения и алерта на недоступность — это можно сделать за день-два. Затем добавьте четыре золотых сигнала по основным эндпоинтам и бизнес-метрику вроде числа успешных заказов. Трассировку и RUM подключайте следующим этапом.

Чем APM отличается от observability?

APM (Application Performance Monitoring) — класс инструментов для мониторинга производительности приложения: время ответа, трассировка запросов, медленные запросы к базе, ошибки. Observability шире: это свойство системы и практика, объединяющая метрики, логи, трейсы, RUM и инфраструктурные данные. Современные APM-системы — один из инструментов достижения наблюдаемости.

Мониторинг и observability веб-приложения: что это и зачем нужны