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

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

Какие показатели отслеживать в первую очередь

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

• Количество операций. Сколько запросов или действий зафиксировано за выбранный период. Этот показатель помогает отличить реальный спад активности от сбоя в сборе данных.
• Доля неуспешных операций. Сколько попыток завершилось ошибкой относительно общего числа. Десять ошибок при двадцати попытках и те же десять при тысяче требуют разной реакции.
• Время выполнения. Смотрите не только на среднее. Например, p95 в 800 мс означает, что примерно 95% измеренных операций завершились не дольше чем за 800 мс. Это помогает заметить задержки, которые теряются в среднем значении.
• Запас ресурсов. Помимо загрузки процессора и памяти, отслеживайте ограничения, важные для самого приложения. Например, очередь заданий может расти из-за нехватки свободных обработчиков, даже если процессор не загружен полностью.

Как связать метрики, журналы и трассировки

Метрика показывает масштаб проблемы, журнал помогает понять, что происходило в конкретном компоненте, а трассировка показывает, через какие компоненты прошел запрос и где он провел больше всего времени. Эти данные полезнее всего, когда их можно сопоставить по времени, имени сервиса и версии приложения. Если в журнал передается идентификатор трассировки, инженер может перейти от медленного запроса к относящимся к нему записям.

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

Как настроить оповещения, на которые будут реагировать

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

1. Выберите действие пользователя, нарушение которого требует реакции, и определите, как измерять его успешность.
2. Подберите порог и длительность срабатывания по обычной нагрузке приложения. Для доли ошибок учитывайте число запросов, чтобы единичный сбой при низком трафике не выглядел как массовый отказ.
3. Добавьте в сообщение название сервиса, время начала проблемы, ссылку на панель с метриками и первую проверку для дежурного.
4. Проверьте на тестовом стенде не только срабатывание правила, но и доставку сообщения нужной команде.

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