Ошибка.log(): как логируются ошибки в мобильном приложении Авито

Вы настроили в приложении краш-репортинг, всё протестировали и выложили в магазин. Постоянно мониторите crash rate, в котором всегда четыре девятки, — приложение работает отлично и все довольны. Но всё-таки вы смотрите на него как будто сквозь замочную скважину и не видите полной картины. Чтобы это исправить, нужен полноценный лог ошибок.

Привет! Меня зовут Тимур Юсипов, я работаю над мобильной версией Авито. В статье рассказываю, как мы логируем бэкендовые и картиночные ошибки, и какую пользу от этого получаем.

Зачем нужно логирование

В мобильном приложении ошибки могут случаться в нескольких точках: на уровне бэкенда, CDN или DDoS-щита, сети или кода мобильного приложения.

На бэкенде причины ошибок видны хорошо — у разработчика есть к нему доступ. DDoS-щиты и CDN для большинства компаний являются сторонними инструментами, поэтому в них всё уже не так прозрачно. Сеть и вовсе априори ненадежна. Хорошо хоть, что в коде мобильного приложения ошибок почти никогда не бывает (всегда же виноват бэкенд…). Короче говоря, точек отказа много, поэтому без логирования ошибок сложно понять, что же на самом деле ощущает пользователь.

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

1. Мониторить состояние приложения в реальном времени, чтобы быстро реагировать на резкий скачок какой-либо метрики у пользователей.

2. Обнаруживать изменения во время AB-тестирования на небольшой аудитории. Например, если AB-тест запущен на 5% пользователей и в нём растут ошибки на 1%, то на общем графике реалтайм-мониторинга они будут незаметны. 

3. Дебажить причины возникновения ошибок. Например, если уже произошёл отказ на одном из уровней, нужно разобраться, почему это случилось.

Чтобы решать эти задачи, нужно логировать разные данные и обрабатывать их по-разному.

Какой инструмент логирования используется в Авито

Готовых решений для логирования много, например Firebase, Grafana или Sentry. Среди них нужно выбрать то, которое подходит для конкретного проекта. При этом стоит смотреть:

• какие из трёх видов задач решает выбранный инструмент;

• какая версия доступна — платная или бесплатная; 

• какие ограничения есть у инструмента, например, по длительности хранения данных и их объёму;

• облачный ли инструмент или устанавливается на локальный сервер.

Последний пункт важен в контексте безопасности персональных данных и импортозамещения — многие готовые решения работают только на зарубежных серверах.

В Авито мы используем несколько инструментов под разные задачи. 

Для логирования ошибок в мобильном приложении мы пользуемся своей системой аналитики — с её помощью отслеживаем продуктовые события. Она состоит из мобильного SDK для отправки событий, транспорта и аналитического хранилища данных. Его дополняет система AB-тестирования — она показывает, в какой группе пользователей и с какой статистической значимостью изменилась каждая метрика.

У нашего инструмента логирования ошибок есть плюсы и минусы.

Что логируется в Авито, чтобы видеть работу приложения целиком

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

Типы ошибок зависят от точки отказа, на которой они происходят: отказ бэкенда, некорректная загрузка картинок из CDN, сбой подключения к сети, баг в приложении. При этом для каждого типа есть подтипы. Скриншоты в основном будут про iOS, но на Android логирование работает плюс-минус также, за исключением некоторых деталей.

Ошибки бэкенда классифицируем и разделяем по статус-кодам HTTP и кастомным ответам, которые используются внутри Авито.

Ошибки сети определяем по каталогу NSURLErrorDomain. В нём есть понятные описания каждого кода ошибки, поэтому логировать по ним удобно. Ещё учитываем в логах низкоуровневые недокументированные ошибки из других доменов — они появляются редко. 

На Android определять ошибки сети оказалось не так удобно. Нужно отловить java.lang.Exception, потом определить, какое описание можно дать конкретному подтипу Exception, и достать из этого подтипа дополнительную информацию, если это возможно. Для того, чтобы подобрать хорошее описание всем таким подтипам Exception, мы заранее из кода библиотек и фреймворка достали вероятные ошибки на разных слоях и проставили им читаемые названия вручную. Это ошибки слоя OkHttp (все Exception'ы из пакетов okhttp.*), слоя ssl-соединения (ошибки из пакета javax.net.ssl), и «системного» слоя (ошибки из пакета java.net). Этого оказалось достаточно, и самые частые ошибки сети сейчас попадают в наш заготовленный список типов. 

Причины ошибок при загрузке картинок и JSON аналогичны — это бэкэнд и сеть. Но мы выделили картиночные ошибки в отдельный тип, потому что они особенно важны для бизнеса. 

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

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

А чтобы проанализировать саму причину ошибки, понадобится более подробная информация: текст ошибки, полный URL, параметры устройства, версия приложения, имя экрана, IP и тип соединения, имя оператора, response header CDN и так далее.

Откуда логируются ошибки в мобильном приложении

В приложении Авито работает стандартная схема передачи данных. Слои последовательно передают друг другу запрос, затем возвращают его наверх, если возникает ошибка.

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

Когда вы проводите логирование сами, то можете сделать это на сетевом слое приложения. Это работает лучше, если сетевой слой сначала пытается обработать ошибку и решить проблему, а не отправляет её сразу в сервисный слой. В этом случае передавать в верхние слои приложения нечего, потому что проблемы уже нет.

Самый простой пример такой ситуации: когда приложение теряет связь с интернетом, то пытается отправить повторный запрос. Другой сценарий: бэкенд сообщает, что сессия подключения просрочена. Тогда приложение обновляет авторизационную сессию по токену и незаметно для пользователя ещё раз отправляет изначальный запрос.

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

Зачем логировать ошибки с экранов приложения

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

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

Еще есть ошибки бэкенда, которые на самом деле непонятно, являются ли ошибкой с точки зрения бизнес логики приложения. Например, мы получили ответ Not Found при попытке открыть объявление. Возможно, объявления никогда не было, значит его ID попал в приложение по ошибке, и это проблема. Но если владелец удалил объявление, а мы пытаемся его открыть, и поэтому у нас не получается, то мы это уже не считаем за ошибку — это исключительная ситуация, которую приложение должно уметь правильно обрабатывать и рисовать пользователю соответствующий UI.

В общем, не все ошибки сетевого слоя влияют на пользователя, и это важно уметь отличать. Это первая причина, почему стоит логировать и видимые пользователю ошибки.

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

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

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

Как логировать ошибки с экранов приложения

Посмотрим на слои приложения и добавим к ним экранный слой. На нём нужно записать, на каком экране пользователь увидел ошибку. Важно знать, почему она произошла. Поэтому добавляется связь для двух отдельных событий в логах. Для этого в каждом случае — на сетевом слое и на экранном — указывается одинаковый ID ошибки.

Кроме ID ошибки на экранном слое логируются идентификатор экрана, текст сообщения, которое увидел пользователь, и способ его отображения — внутри экрана, в виде алерта или всплывающего баннера (тоста).

Почему сложно логировать ошибки на экранах приложения

Есть две причины:

1. В слое приложения больше разных механик работы экрана и обработки ошибок. Это отличает его от сетевого слоя. Поэтому для каждого экрана приходится вручную заводить логирование ошибок, которые видит пользователь. Обычно сетевой слой в приложении один и используется всеми экранами, поэтому логирование сетевых ошибок можно написать в одном месте для всех запросов сразу, это очень удобно. С экранами всё сложнее

2. В приложении Авито есть несколько экранов, где не отображается диалог об ошибке. Вместо этого появляется экран в пустом состоянии, как будто с бэкенда пришла не ошибка, а пустой массив данных. 

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

Короче говоря, логирование ошибок с экранов — довольно нудный ручной труд (потная катка).

Как залогировать ошибки с экранов приложения и не сойти с ума

Скорее всего у вас есть топ 10–15 экранов, через которые проходит больше 90% пользовательского трафика. Если залогировать видимые пользователю ошибки с этих экранов, то вы уже получите хорошую приближенную оценку реальных ощущений пользователя. С этого можно начать, это дешево.

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

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

Итого, мы приходим к потребности реализовать еще одну метрику (success rate’а). Добавить логирование для нее так же просто, как и в случае логирование низкоуровневых ошибок, тк все сетевые запросы у вас скорее всего проходят через общий сетевой слой. 

Ещё логирование ошибок с экранов приложения можно совместить с логированием перформанс-метрик экранов. Обычно логирование показа ошибки и контента после успешной загрузки находится в коде экранов близко друг к другу. По сути, performance метрики — это метрики успешных (зеленых) сценариев, а метрики ошибок — это метрики неуспешных (красных) сценариев.

Что у нас получилось в итоге

У нас есть число ошибок сетевых запросов по их типам, success rate по каждому URL, детали ошибок, привязка ошибок к экранам и способам их отображения пользователю, число и доля пользователей, которые сталкиваются с ошибкой. Теперь мы можем мониторить состояние приложения в продакшене, обнаруживать рост ошибок в AB-тестах и разбираться в их причинах.

Какую пользу принесло логирование ошибок в мобильном приложении

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

Ещё мы узнали, насколько стабильно работают CDN и DDoS-щит. И что иногда приложение теряет доступ к мобильной сети, и пользователей нужно направлять в системные настройки. 

Также мы исправили большое количество видимых пользователю ошибок. Для этого добавили несколько повторных попыток на ошибки установки SSL-соединения и разрешении DNS. В AB-тесте мы не увидели, как они влияют на продуктовые метрики. Возможно, потому что пользователь и так не уходил из приложения в случае ошибки. Он просто повторно отправлял запрос вручную, а теперь мы стали это делать за него автоматически. Будьте внимательны с повторными попытками, т.к. они могут окончательно завалить ваш бэкенд, когда он и так тяжело работает (читай про exponential backoff retry). 

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