Технический мониторинг показывает состояние инфраструктуры, но не всегда позволяет понять, может ли пользователь прямо сейчас войти в приложение, получить SMS или скачать документ. Поэтому для высоконагруженного клиентского сервиса мы дополнили технические метрики мониторингом пользовательских сценариев и выстроили процесс работы с ними.
Почему технического мониторинга было недостаточно
Технический мониторинг был настроен с самого начала проекта. Мы отслеживали загрузку CPU и памяти, сетевые соединения, состояние базы данных и другие инфраструктурные показатели. Но нормальные значения этих метрик не означают, что все функции сервиса доступны пользователю. Например, инфраструктура может работать штатно, но SMS-код не приходит, распознавание документа не срабатывает или сформированный файл невозможно скачать. Из-за этого о части проблем команда узнавала из обращений в поддержку, уже после того, как с ними столкнулись пользователи. Чтобы обнаруживать такие ситуации раньше, технический мониторинг дополнили отдельным уровнем бизнес-метрик.
Два уровня мониторинга
Мы разделили мониторинг на два связанных уровня.
Технический мониторинг контролирует состояние инфраструктуры: серверов, контейнеров, очередей сообщений, сертификатов, хранилищ и наличие логов по каждому микросервису.
Какие пользовательские сценарии мы контролируем
Для бизнес-мониторинга мы определили точки, проблемы в которых непосредственно влияют на работу пользователя.
Среди них:
- авторизация и работа с базой данных
- доставка push- и SMS-уведомлений
- скачивание документов
- интеграции с внешними системами
- обработка заявок на изменение или расторжение договора
- обновление профиля и согласий на обработку данных
По дашборду с двумя графиками выше инженер видит на первом графике в количественном разрезе способы входа в мобильное приложение (биометрия, pin-code и т.д), Можем заметить, что в 14:45 почти по всем способам пошёл рост активности, но сравнивая с другими днями инженер понимает, что это относительно типичная нагрузка на приложение.
На втором графике мы видим ошибки авторизации пользователей по конкретным событиям. Появление ошибок может сигнализировать о разных проблемах:
- ввод смс-кода позднее 30 сек – проблемы с доставкой смс-сообщений, провайдером
- повторный ввод смс-пароля – смс могут дублироваться на стороне оператора
- ввод неверного кода из смс – при массовости возможно мошеничество или более длительная задержка в доставке смс-сообщений.
На этом скриншоте видим график обогащения профиля пользователей из смежных систем при входе. «Ничего не обновлено», означает что данные получены, но они у пользователя актуальные, обновлять не потребовалось. На этом графике мы зафиксировали инфраструктурную проблему с получением самих данных из ELK – это отражается в характерном провале запросов в промежутке времени 22:00-00:30.
Как настраиваем алерты
Для разных ситуаций используются разные условия срабатывания.
В одном случае система отслеживает отклонение показателя от заданного порога. Например, аномально большое количество входов за 30 минут может быть признаком того, что пользователей массово разлогинило и они авторизуются повторно.
В другом случае алерт привязан к конкретной технической ошибке. На старте для новой функциональности можно отслеживать все необработанные исключения, а после появления данных о реальных инцидентах — выделять отдельные ошибки и настраивать для них точечные проверки.
Так мониторинг уточняется по мере эксплуатации продукта и накопления данных.
На графиках видим резкий всплеск входов, на втором графике наоборот резкое падение успешных запросов. В обоих случаях граница срабатывания алерта пройдена и будет отправлено оповещение инженерам поддержки.
Настраиваем пороги под реальную активность
Одинаковые пороги подходят не для всех периодов. Ночью пользовательская активность ниже, поэтому для этого времени задаются отдельные условия срабатывания. Для редких событий период проверки также увеличивается: например, отсутствие заявок на изменение договора имеет смысл оценивать за несколько часов, а не за несколько минут.
Часть мониторингов намеренно пересекается. Если один из них не зафиксировал отклонение из-за слишком широкого порога, проблему может обнаружить другой.
Периодически мы пересматриваем частоту срабатывания алертов. Если проверка начинает давать слишком много ложных сигналов, корректируются ее пороги или логика.
Как новая метрика появляется в продакшене
Мониторинг новой функциональности закладывается еще на этапе разработки. Для добавления метрики команда проходит несколько шагов:
1. Команда разработки логирует необходимое событие и готовит запрос для его поиска в логах
2. Сопровождение описывает метрику в базе знаний: ее бизнес-смысл, способ ручной проверки, критерии проблемы и техническую реализацию в Grafana, Zabbix и Kibana
3. Поддержка настраивает сбор метрики с помощью VictoriaMetrics и Prometheus
4. Метрика добавляется на дашборд. По возможности для нее используется существующий шаблон панели, чтобы сохранять единообразие
5. Условия срабатывания согласовываются с ответственным менеджером. До выхода функциональности в прод алерт остается на паузе
6. После запуска функциональности алерт включается
Вместе с самой метрикой заранее готовим инструкцию для поддержки. В базе знаний зафиксированы правила именования графиков, способы проверки метрик и алгоритмы действий при срабатывании алертов, включая запросы для поиска соответствующих событий в Kibana.
Что происходит после срабатывания алерта
Дежурному инженеру не нужно каждый раз самостоятельно определять, как диагностировать проблему. Он открывает инструкцию для конкретного алерта и проверяет соответствующие события в логах.
Чтобы понять масштаб проблемы, инженер сравнивает количество успешных и неуспешных вызовов с аналогичным периодом ранее. Если сбой подтверждается, создается дефект, а при высокой критичности информация сразу передается команде.
За счет такого процесса дежурная смена может сразу проверить сработавший алерт, оценить масштаб проблемы и подключить нужную команду, не тратя время на поиск способа диагностики.
Важно поддерживать такое покрытие инструкциями на высоком уровне, чтобы в ближайший год перевести обработку алертов на MCP, RAG, RPC автоматизаию.
Результат
Выстроенный процесс мониторинга позволяет обнаруживать проблемы не только на уровне инфраструктуры, но и непосредственно в пользовательских сценариях.
- Полная недоступность сервиса, которую раньше могли устранять несколько часов, теперь фиксируется и устраняется менее чем за 30 минут — с учетом времени на подключение специалистов. Доступность сервиса сохраняется на уровне 99,9% и выше, а крупных инцидентов с простоем не было уже больше двух лет.
- Большую часть проблемных событий команда обнаруживает до обращения пользователей в поддержку. При этом с ростом количества пользователей число обращений в поддержку снизилось на 80%.
- Документированный процесс помогает быстрее подключаться к работе и новым специалистам поддержки: для каждой метрики зафиксированы условия срабатывания, способы диагностики и необходимые действия.
- Мониторинг при этом продолжает развиваться вместе с сервисом: команда корректирует пороги, отключает устаревшие проверки и добавляет новые по мере появления функциональности и накопления данных об инцидентах.