Что такое observability в приложениях
Что проверяют
Понимаете ли вы разницу между мониторингом и наблюдаемостью и переносите ли её на мобильный контекст. На сервер можно зайти и посмотреть логи, на устройство пользователя нельзя: сигнал нужно заранее предусмотреть, собрать и доставить.
Мониторинг отвечает на заранее заданные вопросы. Observability это свойство системы, при котором по внешним сигналам восстанавливается её внутреннее состояние, причём без выпуска новой сборки.
Как отвечать
Три сигнала и что они дают в приложении:
- логи: события с контекстом (идентификатор сессии, экран, версия сборки), локально Logcat и Timber, наружу только отобранные и без персональных данных;
- метрики: агрегаты по парку устройств, доля сессий без сбоев, частота зависаний, время холодного и тёплого старта, пропущенные кадры, доля сетевых ошибок по кодам;
- трассировки: путь сценария по этапам, от нажатия до отрисовки, со связкой с серверной трассой через идентификатор запроса в заголовке.
Дальше стоит назвать инструменты (сбор сбоев и зависаний, Firebase Performance или OpenTelemetry, Perfetto и StrictMode при отладке) и ограничения мобильного: батарея, трафик, офлайн. Поэтому события буферизуются и уходят пачкой, а объём режется семплированием.
Где спотыкаются
Сводят тему к подключению сборщика сбоев. Падение самый заметный, но не самый частый вид отказа: зависания, молчаливые ошибки сети, деградация старта после обновления библиотеки видны только в метриках.
Пишут логи без структуры и без корреляции. Строки, которые нельзя сгруппировать по сессии и запросу, не складываются в историю обращения, а нужное для группировки поле часто оказывается персональными данными, которых в логах быть не должно.
Меряют на своём флагмане в отладочной сборке и делают выводы о продукте. Наблюдаемость нужна именно на реальном парке: медиана там заметно отличается от хвоста распределения, а решения принимаются по хвосту.