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