Компания Embrace спонсировала этот пост.
Сезон наблюдения за внешним интерфейсом меняется, поскольку мы видим активное участие сообщества в улучшении поддержки OpenTelemetry для веб-приложений и мобильных приложений. Например, в проекте OpenTelemetry появилась новая группа по особым интересам браузера (SIG), и они работают над улучшением поддержки OTel для среды выполнения браузера. Вы можете узнать больше о том, над чем они будут работать, в этом групповом обсуждении по запросу.
Сообщество OTel также имеет специальные SIG для Android и Swift для улучшения API, библиотек инструментов и семантических соглашений для сбора телеметрии на двух собственных платформах мобильных приложений. И организации это принимают к сведению: недавний опрос, проведенный Enterprise Management Associates (EMA), показал, что использование OpenTelemetry для сбора мобильных данных утроится в ближайшие 12–24 месяца.
Я встретился с несколькими ключевыми членами SIG Android и Swift, чтобы провести веселую осеннюю панельную дискуссию о ключевых проблемах в сборе мобильной телеметрии и состоянии поддержки OpenTelemetry для мобильных устройств. В число участников дискуссии вошли:
- Ари Демарко, инженер-программист iOS в Embrace, сопровождающий OTel Swift.
- Брайс Бьюкенен, главный инженер Elastic, сопровождающий OTel Swift.
- Хэнсон Хо, архитектор Android в Embrace, участник OTel и утверждающий OTel Android.
- Джейсон Пламб, старший главный инженер-программист в Splunk, сопровождающий OTel Android и утверждающий OTel Java.
- Начо Бонафонте, старший инженер-программист, сопровождающий OTel Swift.
Проблемы со сбором телеметрии на мобильных платформах
Когда разработчики мобильных приложений используют OpenTelemetry, они должны помнить о масштабах данных, которые могут генерировать мобильные приложения. Бьюкенен отметил, что, хотя серверные системы работают на тысячах клиентов в строго контролируемых условиях, мобильные приложения могут работать на миллионах клиентов.
Демарко вмешался: «Это также приводит к проблеме объемов данных, потому что в зависимости от приложения мобильное приложение может генерировать огромное количество телеметрических данных. Таким образом, в отличие от бэкэндов, которыми вы можете централизованно управлять выборкой, в мобильных устройствах решения о выборке, вероятно, должны приниматься на устройстве с ограниченным представлением о более широкой картине. И тогда у вас возникает вопрос: если вы передискретизируете слишком много данных, вы потратите много трафика или батареи. […] Но если вы занижаете выборку, вы, вероятно, пропустите важную телеметрию, необходимую для выявления проблем или понимания поведения».
Разработчики мобильных устройств также уделяют повышенное внимание производительности своих приложений, на которую могут влиять эксплуатационные расходы на сбор телеметрии. Пламб упомянул несколько вещей, которые следует учитывать разработчикам, в том числе, какие API-вызовы приложение должно выполнять к платформе, сколько времени приложение тратит на эти обратные вызовы или обработчики событий, а также размер полезной нагрузки сетевых запросов в сети.
«Я думаю, что эффективная обработка этих полезных данных — это также то, с чем люди особенно сталкиваются на мобильных устройствах, чего нет на других платформах, и мы не можем позволить себе роскошь просто…[scaling] по горизонтали, типа, запусти еще несколько экземпляров, — сказал Пламб.
Платформы, на которых работают мобильные приложения, также жестко контролируются Google и Apple. Как сказал Бонафонте: «Конфиденциальность, которую предоставляет вам платформа, очень сложна». Разработчикам мобильных устройств необходима поддержка операционной системы для сбора данных, поэтому, если система не позволяет им собирать определенные типы телеметрии, они ограничены в том, как они могут эффективно наблюдать за своими приложениями.
В отличие от серверов, мобильные приложения имеют сложный жизненный цикл, из-за чего может быть невероятно сложно понять условия, которые приводят к проблемам.
Как отметил Демарко: «Мобильные приложения не работают непрерывно, поэтому они приостанавливаются, переводятся в фоновый режим, завершаются, завершаются ОС, происходит сбой… ОС может предварительно разогреть ваше приложение, приложение может запуститься из-за push-уведомления, фоновой выборки или из-за того, что человек нажал на значок. Итак, когда вы сбрасываете свои телеметрические данные?… Как вы отслеживаете непрерывность сеанса при перезапуске приложения? Что происходит, я не знаю, с интервалами в реальном времени, когда происходит произойдет сбой или ОС уничтожит ваш процесс? Итак, есть много сложностей с точки зрения того, что вы решите делать в таких случаях? И это нетривиально… простое решение одного из этих вопросов — это не однострочная задача, которую вы действительно должны решить, чтобы действительно решить эту проблему».
Проблемы, с которыми сталкиваются мобильные разработчики при использовании методов наблюдения
Традиционно наблюдаемость считается сферой компетенции серверных команд, поэтому мобильные разработчики часто этого не понимают. Хо упомянул, что мобильные разработчики обычно взаимодействуют с OpenTelemetry потому, что им говорят, а не потому, что они сами этого добиваются.
«Отслеживание и… телеметрия не являются основной компетенцией мобильных разработчиков… потому что, как вы знаете, проблемы, с которыми они сталкиваются, различны… На самом деле команде нужно многому научить, а архитектура мобильных приложений также не очень хорошо спроектирована для удобства обслуживания», — сказал Хо.
Менеджеры по продуктам могут захотеть большей наглядности, чтобы объяснить производительность (или ее отсутствие) новой функции, поэтому они просят разработчиков мобильных устройств собирать больше данных о наблюдаемости. Но ни мобильный разработчик, ни продакт-менеджер не знают, что собирать. Отсутствие ясности в отношении инструментов наблюдения для мобильных приложений было общей темой в нашей дискуссии.
Бьюкенен отметил, что даже такая простая вещь, как момент запуска интервала, не является тривиальной на мобильном устройстве. «Что касается серверной части, это очень тривиально. Это что-то вроде: «О, когда я получаю запрос, тогда начинается интервал». Но что касается мобильного разработчика… должен ли я делать это, когда кто-то нажимает кнопку? Когда сеть запускается? … На этот вопрос нет правильного ответа, например, как это следует использовать? Это действительно зависит от того, что делает ваше приложение и что вы пытаетесь отслеживать».
Пламб согласился, что OpenTelemetry не имеет отличных рекомендаций для разработчиков по некоторым из этих случаев использования на стороне клиента.
«У нас пока нет действительно хорошей модели данных или просто концептуального описания того, что такое сеансы».
Он сравнил эту задачу с инструментами наблюдения за серверной частью, у которых на данный момент очень четко определены несколько вариантов использования. Например, каждый поставщик, у которого есть решение для отслеживания, будет иметь каскадное представление трассировки, а каждый реальный поставщик мониторинга пользователей (RUM) будет иметь способ анализа воронок.
Как отметил Хо: «Когда вы работаете с серверной службой, цель состоит в том, чтобы принять запрос и дать ответ. Вы хотите регистрировать, сколько времени это заняло и происходит ли что-нибудь интересное в середине. Цель проста. Цель мобильного приложения должна быть определена».
То, что волнует команду Uber Eats, отличается от команды Pinterest, которая отличается от банковского приложения.
«Понять цели и перевести это в какую телеметрию — нетривиальный скачок. Кажется тривиальным, если ты этого не сделал, но когда ты это делаешь, ты такой: «Меня все волнует». Тебя действительно все волнует?» — сказал Хо.
Улучшенная поддержка OpenTelemetry для Android и Swift
SIG Android и Swift улучшают возможности разработчиков при использовании OpenTelemetry. Помимо ручного сбора ключевых сигналов журналов и трассировок OpenTelemetry, оба пакета SDK также могут собирать телеметрию, специфичную для мобильных устройств:
- В Android SDK есть инструментарий для ошибок «Приложение не отвечает» (ANR), отчетов о сбоях, отслеживания просмотров и сетевых вызовов.
- Swift SDK имеет инструменты для сетевых вызовов, выполняемых с использованием URLSession, а также событий сеанса, которые запускают изменения жизненного цикла приложения.
Swift SIG также решил ключевую проблему, связанную с работой на жестко контролируемой мобильной платформе Apple. Официальный менеджер пакетов Apple, Swift Package Manager, требует загрузки всех зависимостей всех библиотек в ваших проектах, даже если вы не используете их в своем приложении. Как следствие, репозиторий OpenTelemetry Swift был очень большим, а это означало, что мобильные разработчики сталкивались с большими размерами загружаемых пакетов для использования OTel в своих приложениях для iOS.
Как поделился Бонафонте: «[OpenTelemetry Swift] пришлось поддерживать protobuf OTLP [OpenTelemetry Line Protocol] протокол с protobuf, и это означает, что у вас есть зависимость от Apple, библиотека от Apple, которая зависит от другой библиотеки от Apple, и она зависит от другой библиотеки, и еще, и еще, и еще».
Ари вмешался: «Всякий раз, когда вам нужно загрузить или скомпилировать приложение, запустить тесты, запустить это в CI, построить приложение и развернуть его, все это занимает кучу времени, и очевидно, например, с точки зрения CI, минуты — это деньги, так что… для каждого разработчика iOS это будет болью. И, возможно, возможно, они просто хотели использовать API или просто нашу реализацию OpenTelemetry SDK».
В качестве решения Swift SIG разделил код на два отдельных репозитория. Официальный репозиторий OpenTelemetry Swift является основным и содержит все необходимое для работы с OTLP. Разработчики создали еще один репозиторий под названием OpenTelemetry Swift Core, который содержит только OpenTelemetry Swift API и OpenTelemetry Swift SDK. Эти две части — минимум для начала работы, создания трассировок и создания журналов. Разработчики iOS теперь могут инструментировать приложения, обрабатывать данные и экспортировать их без каких-либо затрат на основной репозиторий.
Android SIG работает над тремя основными улучшениями. Первый — это улучшенная стабилизация API инициализации агента Android, и ожидается, что он будет вскоре завершен. Второе — это расширение инструментария, в том числе усиление поддержки автоматического инструментария во время сборки.
Как сказал Пламб: «Третья категория, которая, я думаю, не менее важна, — это семантические соглашения… С каждым инструментом, с каждой новой функцией, которую мы добавляем, мы пытаемся отразить это в семантических соглашениях, даже если первый проход находится в стадии разработки или эксперимента, по крайней мере, когда это доступно и задокументировано, что это означает, какова цель, когда вы видите фрагмент данных, помеченный этим именем, что означают эти атрибуты, связанные с ним».
Задача состоит в том, чтобы учесть все различные мнения, когда дело доходит до наблюдения за мобильными приложениями. Хо привел пример сложности определения мобильного сеанса: проблема поведения приложений на переднем и фоновом уровнях. Когда должен начинаться сеанс приложения подкаста, которое работает преимущественно в фоновом режиме? Что происходит с приложениями, которые в основном запускаются на переднем плане, но имеют фоновые действия, вызывающие обновление контента и обновления пользовательского интерфейса (UI), которые должны быть готовы к следующему запуску приложения? Каким должен быть сеанс для приложений точек продаж (POS), которые постоянно работают на переднем плане в течение многих часов?
Затем Хо поделился разработкой Android SIG в предложении Embrace о пожертвовании Kotlin API для OpenTelemetry. Kotlin — официальный язык разработки Android; однако OpenTelemetry Android SDK в настоящее время использует OpenTelemetry Java SDK для записи телеметрии. Внедрение API и SDK Kotlin облегчит мобильным разработчикам использование OpenTelemetry, поскольку язык программирования Kotlin более знаком, идиоматичен и удобен для разработки современных мобильных приложений.
Embrace — это ориентированная на пользователя платформа наблюдения, которая связывает техническую производительность с воздействием на конечного пользователя. Embrace, основанный на OpenTelemetry, обеспечивает реальный мониторинг пользователей на мобильных устройствах и в Интернете, поэтому инженерные группы могут быстрее решать проблемы, повышать производительность и предоставлять исключительные цифровые возможности. Узнайте больше Последние новости от Embrace TRENDING STORIES YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Колин Контрири — руководитель отдела контента в Embrace. Его карьера охватывает множество ролей в трех основных увлечениях: писательство, технологии и развлечения. До работы в сфере технологий он писал и выступал для сцены и экрана, а также… Подробнее от Колина Контрири
