Проверка доступности ничего не показывает
Мониторинг ограничен пингом раз в пять минут: он видит, что сайт лежит, но не замечает, что 40% заказов не проходит из-за ошибок на шаге оплаты при полностью доступной главной.
Наблюдаемость
О проблеме узнаём из алерта а не из звонка клиента
Собираем метрики, централизуем логи и добавляем сквозной трейсинг. Настраиваем алерты, которые означают реальный сбой, а не шум, и прикладываем к каждому из них порядок действий.
Или сразу: +7 (962) 368-39-51 Telegram
Prometheus
метрики приложения и инфраструктуры
Loki
логи с поиском по correlation id
OTel
трейсы через сервисы и очереди
runbook
порядок действий на каждый алерт
Почему о сбоях узнают последними
Формально мониторинг есть почти всегда. Проблема в том, что он отвечает не на те вопросы, которые возникают во время инцидента.
Логи разбросаны по машинам
У каждого сервера свои файлы, форматы разные, срок хранения не определён. Разбор инцидента превращается в последовательность ssh и grep, а после перезапуска контейнера логи исчезают вовсе.
Алертов так много, что их не читают
Двести уведомлений в сутки на всё подряд, включая временные всплески CPU. Дежурный перестаёт реагировать, и настоящее падение теряется среди шума.
Нет метрик приложения
Известна загрузка процессора, но неизвестно, сколько занимает запрос к каталогу, какая доля ошибок 5xx и как растёт очередь. Объяснить вчерашние тормоза нечем.
Запрос проходит шесть сервисов, и непонятно где
Без трейсинга невозможно определить, добавила ли две секунды ваша база, внешний платёжный шлюз или воркер очереди. Гипотезы проверяются вслепую.
Персональные данные попадают в логи
В тело запроса пишутся телефоны, адреса и токены авторизации, а срок хранения логов не определён. Это одновременно и риск утечки, и вопрос к соответствию требованиям по персональным данным.
Что входит в наблюдаемость
Три уровня дополняют друг друга: метрики показывают, что сломалось, логи — что именно произошло, трейсы — где потерялось время.
Метрики и дашборды
Собираем показатели инфраструктуры и приложения и сводим их в дашборды, по которым действительно можно вести инцидент.
- Prometheus с экспортёрами для узлов, MySQL, Redis, nginx и очередей
- Метрики приложения: длительность запросов по маршрутам, доля ошибок, время ответа внешних API
- Recording rules и агрегаты за длительные периоды без перегрузки хранилища
- Дашборды Grafana: обзор сервиса, детализация по маршрутам, состояние очередей и фоновых задач
Централизованные логи
Логи собираются в одном месте, приводятся к структурному виду и становятся пригодными для поиска, а не только для чтения глазами.
- Сбор через Promtail или Fluent Bit в Loki, либо ELK — под ваши требования и ресурсы
- Структурированный JSON, уровни логирования и correlation id в каждой записи
- Маскирование персональных данных и токенов до записи в хранилище
- Политика хранения: горячий период для разбора, архивная выгрузка для истории
Трейсинг и профилирование
Сквозной трейс показывает путь запроса через сервисы, очереди и базы — и сразу отвечает на вопрос, где именно потрачено время.
- OpenTelemetry SDK в приложении и коллектор для приёма и маршрутизации данных
- Jaeger или Tempo для хранения трейсов, выборка медленных запросов
- Связка «метрика → трейс → лог»: от роста ошибок к конкретному запросу и его логам
- Профилирование тяжёлых сценариев для поиска узких мест в коде и SQL
Алерты и дежурство
Алерт — это не «CPU выше 70%», а «пользователи не могут оформить заказ». К каждому прилагается порядок действий.
- Alertmanager с маршрутизацией: критичное звонит, второстепенное ждёт рабочего дня
- Многоуровневые условия и подавление связанных уведомлений во время инцидента
- Синтетические проверки ключевых сценариев: вход, поиск, оформление заказа
- Runbook на каждый алерт и разбор дежурств после инцидентов
Как мы внедряем мониторинг
От минимального работающего набора к полной картине. Метрики и алерты по ключевым сценариям появляются в первую неделю.
-
01 3–5 дней
Цели и точки отказа
Определяем, какие сценарии критичны для бизнеса, как они измеряются и какие отказы должны поднимать дежурного. Фиксируем целевые показатели.
-
02 1–2 недели
Метрики и дашборды
Разворачиваем Prometheus и экспортёры, добавляем метрики приложения, собираем первые дашборды и синтетические проверки ключевых сценариев.
-
03 2–3 недели
Логи и трейсинг
Настраиваем сбор логов с маскированием данных и политикой хранения, подключаем OpenTelemetry и связываем трейсы с логами и метриками.
-
04 1–2 недели
Алерты, runbook, дежурство
Настраиваем маршрутизацию уведомлений, убираем шум, пишем инструкции на каждый алерт, проводим разбор реальных срабатываний и корректируем пороги.
Метрики, логи и трейсы: что чем отвечает
Три инструмента наблюдаемости стоят разного и отвечают на разные вопросы. Метрики — это числа, которые дешёво хранить годами: они показывают, что поведение системы изменилось, и служат основой для алертов. Логи — детальные записи о событиях: они дороже в хранении, зато позволяют восстановить точную последовательность действий при разборе инцидента. Трейсы — путь одного запроса через все сервисы: они отвечают на вопрос «где именно потерялось время».
На практике мы опираемся на две проверенные системы показателей. Для инфраструктуры — USE: загрузка (utilization), насыщение (saturation), ошибки (errors) по каждому ресурсу. Для сервисов — RED: частота запросов (rate), ошибки (errors), длительность (duration). Если эти метрики собираются по ключевым сценариям, большинство инцидентов обнаруживается до обращений пользователей.
Как перестать тонуть в алертах
Шумные алерты опаснее их отсутствия: команда привыкает игнорировать уведомления, и настоящее падение проходит незамеченным. Главная причина шума — алерты по причинам вместо симптомов. Загрузка процессора на 85% сама по себе не проблема, если запросы обслуживаются за обычное время.
Мы ставим уведомления на пользовательские симптомы: рост доли ошибок, превышение времени ответа, снижение числа успешных заказов, исчерпание error budget. Дополнительно настраиваем уровни: критичное будит дежурного, предупреждения копятся и разбираются в рабочее время, а связанные уведомления подавляются на время активного инцидента. У каждого алерта есть владелец и инструкция: что проверить, что сделать, кого позвать. Пороги пересматриваются после каждого разбора — это и есть способ поддерживать сигнал чистым.
Сколько хранить логи и как не нарушить требования
Хранение всех логов «на всякий случай» быстро становится одной из самых дорогих статей инфраструктурных расходов: объём растёт вместе с трафиком, а полезность большинства записей исчерпывается в первые дни. Мы разделяем данные по ценности: горячее хранилище на 14–30 дней для оперативного разбора, тёплое — на 3–6 месяцев для расследований, дальше — выборочная архивная выгрузка значимых событий.
Отдельный обязательный шаг — работа с персональными данными. Телефоны, адреса, номера документов и токены авторизации не должны попадать в логи в открытом виде: маскируем их на этапе сбора, ограничиваем доступ к хранилищу ролями и фиксируем сроки хранения в политике. Такой порядок снимает большую часть вопросов при проверках и одновременно уменьшает объём хранимых данных.
Частые вопросы
Зависит от требований к размещению данных и от готовности команды эксплуатировать хранилища. Собственный контур на Prometheus, Loki и Grafana даёт полный контроль и предсказуемые расходы на инфраструктуру, но требует сопровождения, места на дисках и обновлений. Облачные сервисы снимают эксплуатацию и быстро масштабируются, но данные уходят наружу, а счёт растёт вместе с объёмом метрик и логов. Мы считаем оба варианта под ваш профиль нагрузки.
Логи отвечают на вопрос «что произошло», но плохо отвечают на вопрос «где потерялось время», когда запрос проходит несколько сервисов, очередей и внешних API. Трейсинг показывает длительность каждого шага и позволяет сразу увидеть, что, например, две секунды добавил вызов платёжного шлюза, а не запрос к базе. Мы внедряем OpenTelemetry постепенно: сначала на критичных сценариях, где такие вопросы возникают чаще всего.
Для проекта среднего размера с десятком сервисов достаточно выделенного узла с 4–8 ядрами, 16 ГБ памяти и SSD-диском: Prometheus с разумным retention, Loki для логов и Grafana живут на одной машине. Основной потребитель — хранилище метрик и логов, поэтому важнее не процессор, а диск и настроенные правила хранения. Точные цифры мы считаем после оценки объёма метрик, числа сервисов и требуемого срока хранения.
Базовая версия — метрики узлов и приложения, дашборд ключевого сценария и три-четыре алерта на симптомы — настраивается за одну-две недели и уже закрывает большую часть задач дежурства. Логи с централизованным поиском и трейсинг добавляются следующими этапами. Мы сознательно идём в таком порядке: сначала то, что уменьшает время обнаружения, затем то, что уменьшает время разбора.
DevOps: другие направления
Смежные задачи, которые обычно решаются в одном проекте с этой.
Хотите видеть проблемы до того, как о них сообщат клиенты?
Расскажите, что уже собирается и какие сценарии критичны, — предложим минимальный набор метрик и алертов.