Логирование AI-запросов в мобильном приложении: где ломается
Пользователь нажимает кнопку, приложение уходит в запрос к модели, ответ приходит — а на сервере об этом обращении нет ни строки. Журнал складывается в локальный буфер на устройстве и уходит пачкой при следующем запуске, если уходит вообще. Приложение свернули, система выгрузила его из памяти, сеть пропала на середине отправки — и прослеживаемость запросов обрывается ровно там, где начинается разбор инцидента.
Воспроизвести такую ситуацию по обращению в поддержку почти невозможно. Нет идентификатора запроса, нет связи между жалобой и конкретным ответом модели, не сохранились версия подсказки и параметры вызова. Инженер видит только «у меня не работает» и пустой серверный журнал, а телеметрия мобильного приложения показывает лишь факт открытия экрана.
Отдельно всплывает расход на обращения. Их считают в панели аналитики, а не в трассировке: непонятно, сколько вызовов делает один сценарий, где идут повторы при обрыве связи и сколько запросов уходит в фоне со свёрнутого приложения. После релиза счётчик растёт, а объяснить рост нечем.
Сквозное логирование AI-запросов закрывает обе дыры: каждое обращение получает идентификатор и доезжает до хранилища, инцидент разбирается по шагам, а расход видно по функциям и сессиям. Ниже разбираем, как выстроить такую схему.
Что даёт управляемая телеметрия обращений к моделям
Каждый вызов модели из приложения превращается в запись: идентификатор сессии, версия сборки, экран, тип запроса, размер контекста, задержка и признак отказа. Так наблюдаемость мобильного приложения перестаёт зависеть от пересказа тестировщика — состояние воспроизводится по данным, а не по описанию. Дальше эти записи дают три измеримых эффекта, которые проверяются на первой же неделе.
Расход на обращение к модели виден в разбивке: сколько ушло на вход, сколько модель вернула, какой сценарий тянет полный контекст. Обычно обнаруживается, что часть экранов отправляет историю диалога целиком там, где достаточно последней реплики, — и это правится на уровне промпта и маршрутизации между лёгкой и тяжёлой моделью, без урезания функций. Экономия здесь следствие точности, а не отдельная задача.
Объём хранимых журналов держим под контролем политикой хранения: полные цепочки вызовов пишем только для отказов и медленных обращений, для успешных — агрегаты по сценарию. Разметку ведём по OpenTelemetry, поэтому данные не привязаны к одному поставщику моделей, а срок хранения задаётся отдельно для каждого уровня детализации — реестр не растёт линейно вместе с трафиком.
Время разбора отказа сокращается до минут: по идентификатору сессии поднимается вся цепочка — запрос, ответ, повтор, версия клиента на устройстве. Инженер видит, где именно расходятся ожидание и факт, вместо попыток воспроизвести сбой на стенде с похожими условиями.
Способы сбора журналов: на устройстве, на сервере, гибрид
Выбор режима определяется тем, где физически оказывается запись и что нужно восстановить при разборе. Клиентские журналы пишутся в буфер приложения и уходят пачкой при следующем запуске или появлении сети — только так ловится падение до первого сетевого запроса, но при жёстком завершении буфер теряется.
Серверный сбор журналов фиксирует ответы бэкенда: код, задержку, идентификатор сессии и версию приложения. Контекст интерфейса при этом остаётся за кадром — по таким записям не видно, какое действие предшествовало ошибке и на каком экране пользователь остановился.
| Схема | Когда подходит | Ограничения |
|---|---|---|
| Клиентские журналы | Разбор падений и зависаний на конкретных моделях и версиях системы | Запись теряется при жёстком завершении, объём растёт с числом устройств |
| Серверный сбор | Контроль стабильности сервисов и сквозной задержки ответа | Нет контекста интерфейса — непонятно, чем вызвано обращение |
| Гибридная схема | Нужен полный путь от действия пользователя до ответа сервиса | Требует сквозного идентификатора и единой схемы полей в обоих потоках |
Гибридная схема журналирования сводит оба потока по общему идентификатору сессии, поэтому инцидент прослеживается от нажатия до ответа бэкенда. Выборочная запись журналов делает такую схему рабочей на длинной дистанции: базовые события схлопываются в счётчики, а полный поток включается флагом или для доли сессий.
В итоге объём журналов перестаёт расти линейно с числом пользователей, а разбор инцидента остаётся полным. Что именно логировать и на каком уровне — разбираем на этапе проектирования, под профиль нагрузки вашего приложения.
Этапы внедрения логирования в мобильное приложение
Логирование обращений к AI в мобильном приложении редко сводится к добавлению одной строки кода: нужно заранее решить, что писать, где хранить и как не съесть батарею и трафик пользователя. Поэтому идём последовательно — от инвентаризации точек обращения до передачи наблюдаемости вашей команде.
- Аудит журналирования. Инвентаризируем точки обращения к AI: экраны, фоновые задачи, офлайн-сценарии; для каждой фиксируем набор полей — идентификатор сессии, тип запроса, время ответа, код ошибки, версия приложения.
- Схема хранения журналов. Делим записи на локальные и серверные: буфер на устройстве с ограничением объёма и ротацией, срок хранения, маскирование персональных данных перед отправкой.
- Настройка отправки журналов. Пакетная выгрузка по событию и таймеру, дозапись после обрыва сети, отдельные правила для роуминга и слабого канала — журналы не конкурируют с основным трафиком.
- Проверка на реальной нагрузке. Прогон на живом трафике: доля потерянных записей, задержка доставки, влияние на время запуска и расход батареи.
- Приёмка наблюдаемости. Проверяем, что путь запроса восстанавливается от нажатия до ответа, а на всплеск ошибок и рост времени ответа срабатывают оповещения.
- Передача и сопровождение. Отдаём описание формата записей, регламент добавления новых полей и порядок дежурства по оповещениям.
Каждый этап заканчивается артефактом, который можно проверить, — так видно, что уже работает, а что ещё предстоит.
Что остаётся в проекте: схема журналов, правила, регламенты
Проект считается сданным не тогда, когда приложение собрано, а когда дежурный инженер по одному инциденту восстанавливает всю цепочку — от действия пользователя до ответа модели. Поэтому в пакет передачи входят не только исходники, но и артефакты наблюдаемости: их можно открыть, прочитать и передать другой команде без устных пояснений.
- Схема потоков журналов — откуда берётся каждый поток, где агрегируется, что уходит в долгое хранение, а что отбрасывается на входе.
- Правила маскирования персональных данных — перечень полей, которые не покидают контур в открытом виде, и проверка, что правило срабатывает до записи, а не после.
- Сроки жизни журналов — по каждому типу: сколько держим в горячем доступе, когда переносим в архив, что удаляется безвозвратно.
- Уровни и объём записи — что пишется всегда, что включается переключателем на время разбора: иначе объём журналов растёт быстрее нагрузки.
- Регламент разбора инцидентов — кто поднимает разбор, за какое время, какие срезы смотрит первым, в какой момент подключает разработчика.
- Панели мониторинга и оповещения — доля ошибок по сценариям, время ответа модели, всплески отказов, порог срабатывания и адресат уведомления.
- Документация наблюдаемости — где лежат журналы, как найти цепочку по идентификатору запроса, как добавить новое поле и не сломать маскирование.
- План при росте объёма — порядок действий: частичная выборка событий, понижение детализации, архивация старых периодов вместо отключения записи.
Кейс: разбор отказов ускорился, объём журналов сократился
Мобильное приложение с ИИ-ассистентом писало в журнал каждый запрос целиком: текст обращения, ответ модели, вложения пользователя, служебные заголовки. Через несколько месяцев разбор одного инцидента занимал часы — нужные события тонули в однотипных записях, а часть сведений вообще нельзя было хранить из-за персональных данных. Хуже другое: отказы внешней модели в журнал не попадали вовсе, в приложении оставалась общая ошибка без деталей.
Что изменили
Наши инженеры перевели журналирование на структурированные события через OpenTelemetry: каждому обращению к модели присваивается идентификатор, который связывает записи приложения, шлюза и ответа модели в одну цепочку. Уровни разделили — в обычном режиме пишутся результат, время ответа и код ошибки, полные тексты включаются точечно, по переключателю на устройстве или по доле запросов. Персональные данные вырезаются на входе в журнал, а срок хранения задан политикой отдельно для каждого типа события.
Что стало
Разбор инцидента сократился с нескольких часов до 15–20 минут: по идентификатору поднимается вся цепочка, включая ответ внешней модели. Объём журналов уменьшился примерно в семь раз — за счёт выборочной записи и короткого срока хранения подробных событий. Ушёл целый класс отказов: превышение времени ожидания и ошибки модели теперь видны по доле неуспешных обращений и времени ответа, а время восстановления сервиса считается не по жалобам пользователей, а по графику отказов.
Что делать, если журналы уже уходят в сторонний сервис?
Если сбор журналов уже отдан стороннему сервису аналитики, событие уходит с устройства напрямую в чужой контур, и точки контроля на вашей стороне нет. Формально логирование AI-запросов работает, но при разборе сбоя доступен только агрегат в чужой панели, а не сырые записи по конкретному обращению.
Развилка одна: оставить как есть и надстроить, дублировать поток журналов или заменить сбор целиком. У каждого пути свои ограничения по данным и по объёму работ.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Надстроить своим сборщиком поверх стороннего сервиса | Нужна вторая точка контроля, а текущая аналитика должна работать без пауз | Две схемы событий живут параллельно — имена полей и разметку версий приходится сводить вручную |
| Дублирование потока журналов | Нужно убедиться, что ничего не теряется, до отказа от прежнего приёмника | Двойной объём на устройстве и в канале, обязательны прореживание и лимиты на отправку |
| Заменить сбор целиком | Свой контур уже покрывает запросы, есть своё хранилище и разбор инцидентов | Обратной совместимости нет: история из чужого сервиса переезжает только выгрузкой, в реальном времени её не догнать |
На практике миграция журналирования идёт через дублирование: собственный сборщик включаем параллельно, сравниваем объёмы и состав полей, и только потом переключаем поток. Так переход остаётся обратимым — прежний приёмник доступен, пока расхождение не сойдёт к нулю.
Отдельно фиксируем, что именно хранить: уровни событий, долю выборки и срок жизни записей. Без этого объём растёт линейно от числа обращений, и логирование само становится источником расходов — срок хранения по горячему контуру снимает это без потери разбираемости.
Хранение, доступ и нагрузка: технические сомнения команд
Вопросы про журналы всплывают не на старте, а на объёме: одна сессия ассистента — это десятки записей. Спрашивают обычно про хранение журналов, доступ к журналам, нагрузку на приложение и очистку.
Мы закладываем это в схему сбора сразу: буфер на диске, пакетная отправка, маскирование на клиенте, политика хранения с фиксированным сроком. Формат совместим с OpenTelemetry — коллектор можно поднять на вашей стороне.
Журналы теряются при закрытии приложения?
Нет, если запись идёт в буфер на диске, а не в память: неотправленное досылается при следующем запуске. Потеря возможна при отзыве разрешений или сбое устройства — размер буфера задаётся в конфигурации.
Как маскируются персональные данные?
Маскирование идёт до записи, по списку правил, согласованному с вашей службой безопасности: телефоны, адреса и токены заменяются, в журнале остаётся идентификатор сессии.
Что будет, если сборщик недоступен?
Отправка асинхронная — ответ пользователю её не ждёт. Записи копятся в буфере, повтор идёт с растущей паузой, старые вытесняются новыми: приложение не растёт по памяти и не падает по таймауту.
Как посчитать объём хранения и когда чистить журналы?
Число запросов в сутки × средний размер записи × срок хранения — считаем на недельном срезе. Очистка по сроку, автоматически: горячее хранение для разбора сбоев, дальше агрегаты без персональных данных.
Обсудим задачу и вернёмся с оценкой и планом работ
Чтобы оценка проекта опиралась на факты, а не на предположения, к обсуждению достаточно принести то, что уже есть в вашей инфраструктуре: выгрузки журналов, описания потоков и понимание, какие данные терять нельзя.
- список обращений к моделям за типичный период — по нему видно объём логирования AI-запросов, пиковую нагрузку и долю повторных вызовов;
- текущие журналы приложения и серверной части: формат, глубина хранения, пишутся готовым слоем или самописным кодом;
- требования к хранению: срок, кому доступно содержимое, есть ли персональные данные и правила работы с ними;
- перечень сбоев за последнее время — превышения времени ответа, отказы внешних сервисов, жалобы пользователей: отсюда понятно, какие события обязаны попадать в журнал;
- схема окружений и порядок доступа к ним с ролями — от тестового до рабочего;
- показатели, по которым вы судите о качестве: время ответа, доля успешных вызовов, объём данных на одно обращение.
По этим материалам мы возвращаемся с оценкой и планом работ: состав работ по этапам, схема хранения и ротации журналов, требования к доступам, набор метрик и порядок отката на предыдущую конфигурацию. Опишите задачу — соберём недостающее вместе на созвоне и зафиксируем план внедрения с ответственными и сроками.
