Наблюдаемость нативных мобильных приложений¶
Требования применяются к iOS- и Android-приложениям. Уровни обязательности
определены в корневом README.md.
OpenTelemetry и GlitchTip являются рекомендуемыми каналами. Требования
MOB-OBS-003–MOB-OBS-007 применяются только к выбранным проектом сигналам и
каналам mobile-наблюдаемости.
MOB-OBS-001. Маршрут телеметрии¶
Уровень: SHOULD
Применяется к: решению о сборе трасс, метрик и mobile performance
Приложению следует использовать OpenTelemetry SDK и передавать выбранные сигналы по OTLP в OpenTelemetry Collector с последующей доставкой в OpenObserve. При выборе канала не следует использовать прямой exporter в OpenObserve; экспорт следует ограничивать по памяти, диску, повторам и времени.
Обоснование¶
Collector отделяет мобильный код от хранилища и ограничивает влияние отказа.
Проверка¶
- integration-тест полного маршрута;
- тест offline и медленного Collector;
- проверка отсутствия прямого exporter.
Исключения¶
Проект MAY не собирать mobile-телеметрию через OpenTelemetry без ADR.
MOB-OBS-002. Маршрут ошибок¶
Уровень: SHOULD
Применяется к: решению о централизованном сборе mobile-ошибок
Расследуемые ошибки следует передавать Sentry SDK в GlitchTip. При выборе канала следует автоматически собирать crash и необработанные ошибки, не отправлять ожидаемые бизнес-отказы и отмены и ограничивать влияние недоступности GlitchTip на очередь SDK.
Для поддерживаемой платформы dSYM iOS либо mapping files Android следует загружать в GlitchTip для точного release и хранить вне публичного artifact. Тестовую minified или native ошибку следует восстанавливать до исходного файла, строки и символа.
Обоснование¶
Отдельный канал обеспечивает crash reporting и symbolication.
Проверка¶
- тест crash и обработанной ошибки;
- проверка единственного события;
- проверка symbolication тестовой ошибки;
- тест недоступного GlitchTip.
Исключения¶
Проект MAY не интегрировать GlitchTip без ADR. OS termination без доступного callback MAY обнаруживаться средствами store и платформы.
MOB-OBS-003. Идентификация выпуска и сигнала¶
Уровень: MUST
Применяется к: каждому сигналу
Сигнал должен содержать одинаковые service.name, service.version,
deployment.environment.name, os.name, os.version и app.build_number.
service.version должен обозначать публичную версию приложения, а
app.build_number — номер конкретной сборки. Release должен однозначно
сопоставляться с commit и artifact по MOB-BUILD-002. Device и user ID не
должны использоваться как resource identity.
Событие ошибки должно дополнительно содержать стабильные event.name и
error.type: тип наблюдаемого события и класс ошибки соответственно.
Динамический текст и идентификаторы экземпляров не должны использоваться как
их значения.
Обоснование¶
Общие поля связывают сигналы конкретного store release, а стабильная классификация позволяет сопоставлять причины ошибок между выпусками.
Проверка¶
- сравнение GlitchTip и OpenObserve;
- сопоставление с artifact metadata;
- запрос на отсутствующие поля;
- проверка стабильности
event.nameиerror.typeмежду повторами ошибки.
Исключения¶
Не допускаются для production.
MOB-OBS-004. Корреляция и ограниченная кардинальность¶
Уровень: MUST
Применяется к: span, событию ошибки и метрике
Активный trace должен распространяться на backend по MOB-API-004; событие
ошибки внутри trace должно содержать совпадающие trace_id и span_id.
Маршруты должны использовать стабильные имена экранов и операций. Device ID,
user ID, URL с параметрами, текст ошибки и случайные значения запрещены в
атрибутах метрик.
Обоснование¶
Корреляция нужна для диагностики, а высококардинальные ID разрушают агрегацию.
Проверка¶
- сквозной trace test;
- анализ кардинальности;
- тест динамических данных.
Исключения¶
Псевдонимная сессия может быть атрибутом события, но не временного ряда.
MOB-OBS-005. Mobile performance и стабильность¶
Уровень: SHOULD
Применяется к: production-приложению
Следует измерять crash-free sessions, cold start и длительность объявленных критичных пользовательских операций. Для сетевой критичной операции следует измерять её сквозную длительность, а для поддерживаемой платформы — доступный SDK сигнал зависания интерфейса: iOS hang либо Android Application Not Responding (ANR).
Этим измерениям следует предоставлять данные для применимых SLI/SLO по
OPS-SLO-001–OPS-SLO-002 и сегментироваться через os.name,
service.version и os.version без device-level кардинальности.
Обоснование¶
Backend SLI не отражает запуск, зависание и rendering на устройстве.
Проверка¶
- контролируемый slow-start и применимый сигнал зависания;
- review формул по
OPS-SLO-001; - проверка dashboard по release.
Исключения¶
Метрика, недоступная SDK на одной платформе, MAY быть заменена эквивалентным проверяемым сигналом; отдельный ADR не требуется.
MOB-OBS-006. Защита данных телеметрии¶
Уровень: MUST
Применяется к: telemetry payload
Телеметрия не должна содержать токены, ввод пользователя, содержимое экранов, точную геолокацию или персональные данные без утверждённого основания и маскирования. Фильтрация должна выполняться в приложении до отправки; server- side фильтрация является только дополнительным защитным слоем.
Обоснование¶
Диагностический контекст может раскрыть данные пользователя через внешние по отношению к устройству системы.
Проверка¶
- before-send filtering test;
- security review атрибутов.
Исключения¶
Сбор персональных данных возможен только по принятой политике и согласию.
MOB-OBS-007. Rendering performance¶
Уровень: SHOULD
Применяется к: экрану с прокруткой, animation или частым обновлением UI
Приложению следует измерять slow и frozen frames, frame-time percentile или эквивалентный платформенный сигнал jank для критичных пользовательских сценариев. Сигнал следует сегментировать по release, OS и классу устройства без device-level identifier и связывать с численным порогом регрессии.
Если SDK не предоставляет frame metrics, следует использовать воспроизводимый UI performance test с тем же наблюдаемым результатом.
Обоснование¶
Приложение может не иметь crash, hang или ANR, но оставаться практически непригодным из-за устойчивых пропусков кадров.
Проверка¶
- controlled медленный render или scroll;
- performance test на минимально поддерживаемом классе устройства;
- сравнение release с baseline по критичному сценарию.
Исключения¶
Статический экран без animation и прокрутки MAY не иметь отдельной frame метрики, если длительность его критичной операции уже измеряется.