4 метрики, которые мы отслеживаем для обеспечения бесперебойной работы многокомпонентной системы

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

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

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

Главная функция работы всей системы — это продажа авиабилетов пользователям. По тому, насколько быстро отрабатывают взаимодействия между каналом продаж, биллинг сервисом, и сервисами партнеров, мы можем заметить, если какая-то из систем работает некорректно и вызывает ошибки. Мы наблюдаем за работой трех приложений: iOS, Android, и альтернативное приложение для iOS. Отслеживая тайминги и время последнего платежа, мы можем быстро узнать если какое-то из них перестанет работать корректно.

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

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

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

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

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

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