Сервер может показывать нормальные CPU и память, пока заявки не попадают в CRM, платежи зависают или фоновые задачи перестают завершаться. Инфраструктурные метрики нужны, но они не доказывают работоспособность пользовательского процесса.

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

Что сделать в первую очередь

  • Опишите ключевые пути: заявка, оплата, доставка сообщения или создание документа.
  • Назначьте каждому пути событие начала и подтвержденный результат.
  • Определите допустимую задержку и нормальный объем по времени суток.
  • Укажите ответственного и действие для каждого критического алерта.

Почему возникает проблема

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

  • Мониторинг собирает только состояние хостов и контейнеров.
  • Успешный HTTP-ответ считается успешной бизнес-операцией без проверки результата.
  • Фоновые очереди растут, но нет метрики возраста старейшей задачи.
  • Алерты построены на фиксированном пороге без учета сезонности.

Пошаговая диагностика

  • Сопоставьте последние инциденты с тем, какие метрики могли заметить их раньше.
  • Проверьте полноту счетчиков success, failed, pending и canceled.
  • Измерьте end-to-end latency, а не только время одного API.
  • Найдите silent failure: процесс завершился без ошибки, но результат не создан.
  • Проверьте cardinality labels и отсутствие персональных данных в метриках.

Как исправить

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

  • Добавьте счетчики завершенных операций по ограниченному набору статусов.
  • Измеряйте возраст очереди и время от входного события до результата.
  • Создайте SLI и целевые SLO для критических потоков.
  • Настройте предупреждение и критический алерт с разными маршрутами.
  • Свяжите дашборд с журналом и correlation id для быстрого расследования.

Как проверить результат

  • Контролируемый сбой бизнес-процесса вызывает алерт до жалобы пользователя.
  • Алерт содержит сервис, период, масштаб проблемы и ссылку на диагностику.
  • Плановый спад трафика не создает постоянных ложных тревог.

Как не допустить повторения

  • Пересматривайте SLO после изменений продукта и сезонности.
  • Проводите короткие тесты алертов и маршрутов уведомлений.
  • Удаляйте неиспользуемые метрики и контролируйте cardinality.

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

Нужно ли отправлять в мониторинг выручку?

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

Чем бизнес-метрика отличается от лога?

Метрика показывает масштаб и динамику, а лог помогает исследовать конкретный случай. Они дополняют друг друга.

Когда стоит обратиться за помощью

Начните с одного процесса, который напрямую влияет на клиентов. Для проектирования достаточно схемы статусов и обезличенных примеров сбоев.

Итог

Полезный мониторинг отвечает, работает ли услуга для клиента, а не только жив ли сервер. Я могу внедрить бизнес-метрики, Grafana-дашборд и алерты с понятной реакцией.