OpenTelemetry Android: шлях до стабільності
TL;DR — Ми хочемо отримати ваші відгуки щодо API агента OpenTelemetry для Android перед його стабілізацією.
Чудова новина! SIG OpenTelemetry Android активно працює над стабілізацією головних API ініціалізації та конфігурації, готуючись до випуску 1.0.0 стабільної версії. Що це означає для розробника мобільного RUM? Чи хочете ви долучитися до тестування та надати відгуки? Читайте далі, щоб дізнатися більше.
Звідки ми починали
Два роки тому OpenTelemetry Android тільки зʼявився, спільнота тепло сприйняла внесок від Splunk. Він складався з одного репозиторію GitHub з одним монолітним модулем, який публікував один артефакт. Проєкт базувався на opentelemetry-java API та SDK і переважно був написаний на Java. Це був міцний старт, що викликав швидкий початковий інтерес. Навіть тоді його вже використовували у промислових розгортаннях.
Спільнота згуртувалася, і ми зібрали групу підтримки та рецензентів (від 4 різних вендорів), щоб супроводжувати код і сприяти поступовому покращенню проєкту.
Чого ми досягли
Ми швидко виявили напрямки для покращення і досягли значного прогресу — понад 1250 pull request від більш ніж 40 учасників! Якщо ви серед цих 40 — ми щиро дякуємо та цінуємо вашу допомогу. ❤️
Ось короткий огляд основних покращень за останні два роки.
Модульність
Монолітна структура проєкту виявилася обтяжливою: вона збільшувала розмір бінарного файлу та прагнула включати всі функції для всіх користувачів. Пласка структура пакунків ускладнювала розуміння, які частини є API, а які є внутрішніми. Тому ми провели модернізацію, розділивши проєкт на граф модулів, кожен з яких має власну відповідальність, кожен з яких публікує власний артефакт. Цей чіткіший розподіл обовʼязків — велика перемога!
Окрім публікації окремих модулів, ми також публікуємо bill-of-materials (bom), який дозволяє розробникам синхронізувати версії цих модулів.
Нова інструментація
Завдяки участі спільноти проєкт OpenTelemetry Android отримав низку корисних бібліотек інструменталізації. Серед них:
- android-log — можливість генерувати OTel лог-записи з ідіоматичних викликів Android
Log.x(...). - httpurlconnection — трасування для цього клієнта HTTP, що постачається середовищем виконання.
- view-click — генерує події натискань для Android Views.
- compose-click — генерує події натискань у компонентах Jetpack Compose.
- sessions — генерує події при зміні життєвого циклу сесії.
Автоінструментування
На відміну від OpenTelemetry Java agent, Android-агент не може виконувати байткод-інʼєкцію в під час виконання коду через обмеження платформи. Однак автоінструментування дуже зручне, і користувачі часто віддають перевагу автоматичним змінам без правки коду.
Деяку інструментацію можна застосувати втулком Gradle під час збірки, без ручних змін у коді або явного використання обгорток OpenTelemetry. На момент написання це включає інструментацію Android log та HTTP-клієнта, і ми очікуємо більше автоінструментування в майбутньому.
Документація
Ми нещодавно завершили ініціативу зі створення документації для кожного модуля інструментації. Це дає змогу користувачам швидко визначити, яку телеметрію генерує кожен модуль, а також інструкції для тих, хто хоче використовувати інструментацію окремо від агента.
Події/семантичні домовленості
У мобільному світі події користувача скрізь. Real User Monitoring (RUM) часто відображає поведінку користувача як серію подій у сесії. Коли OpenTelemetry Android тільки починався, сигнал подій OpenTelemetry (events signal) був ще в зародку, і всі події моделювалися як відрізки нульової тривалості. Також було мало семантичних домовленостей у цій області, і назви відрізків та атрибути не завжди відповідали загальним домовленостям OpenTelemetry (наприклад, крапки та простори імен).
Невелика група брала участь у визначенні семантичних домовленостей для Android, мобільних та клієнтських сценаріїв. Вони були прийняті проєктом Android, і відрізки нульової тривалості тепер правильно моделюються як події.
Міграція на Kotlin
Kotlin — основна мова сучасних Android-розробників. Хоча Kotlin добре взаємодіє з Java, користувачі очікують підхід “Kotlin перш за все”. На початку більшість коду була на Java з невеликим обсягом Kotlin. Наприклад, у квітні 2024 року (перший знімок Wayback Machine):
Хоча робота ще триває, ми досягли значного прогресу. Дивіться що у нас є сьогодні, вересень 2025:
Демонстраційний застосунок
Щоб показати, як інтегрувати OpenTelemetry Android у мобільні застосунки, ми створили новий демонстраційний застосунок. Цей демо застосунок зроблено за зразком OpenTelemetry Demo — Astronomy Shop, і він міститься в репозиторії Android. Окрім демонстрації налаштування агента та встановлення інструментації, демо має функції для генерації готових логів та трейсингу.
Щоб показати мобільні проблеми реальніше, у застосунку також є функції, які навмисно створюють проблеми, наприклад, повільний рендеринг або аварійне закриття.
Дивимося вперед
Ми хочемо, щоб ви надали ваші відгуки про API агента!
Ми досягли моменту, коли час думати про наступну фазу OpenTelemetry Android: стабільність. Після багатьох PR, обговорень, переробок і поступового вдосконалення ми вважаємо, що наближаємося до API ініціалізації, який можемо підтримувати як «стабільний» для лінійки 1.x.
Випуск у жовтні 2025 буде нашим першим release candidate: 1.0.0-rc1.
Починаючи з цієї версії, усі артефакти, окрім android-agent, будуть публікуватися з суфіксом -alpha. Цей суфікс чітко показує, які модулі ще в альфа-стані і можуть зазнати змін в API. Уся інструментація залишатиметься «alpha», а згенерована телеметрія — в статусі «development», поки відповідні семантичні домовленості не стабілізуються.
Ми вважаємо, що android-agent — основний спосіб, яким більшість Android-розробників буде взаємодіяти з цією інструментацією OTel. Тому ми вважаємо, що досягли стану, коли:
- API зручні у використанні
- API покривають 90% типових сценаріїв
- Нестандартні випадки та експертні налаштування все ще можливі
І тут потрібні ви! Будь ласка, спробуйте android-agent і надайте відгук про API OpenTelemetryRumInitializer. Ми щиро вдячні за всі відгуки і використаємо їх під час остаточного доопрацювання цього API та перед прийняттям остаточного рішення про його «стабільність». Дякуємо за увагу і чекаємо на ваші відгуки.