ШІ змінив те, як ми розробляємо програмне забезпечення, але він не змінив базову істину про машини. Вони тонуть у шумі так само, як і ми. Коли інженери вперше експериментують із налагодженням за допомогою ШІ, інстинкт простий: згодувати моделі все. Сирі логи, трасування та метрики — усе скидається у контекстне вікно. Результатом є не розуміння, а невдача. Обсяг занадто великий. Сигнал зникає. Метрики знаходяться в одному інструменті, трасування — в іншому, і модель не може зшити їх у цілісну історію. Перш ніж ШІ зможе допомогти вам спостерігати за вашими системами, ви повинні спостерігати за ними самі. Ви повинні спочатку структурувати дані.

Чому сирі логи руйнують конвеєри ШІ

Сучасні системи генерують телеметрію зі швидкістю, яку не здатна прочитати жодна людина. Це мало б зробити їх ідеальними для штучного інтелекту. Але це не так. Контекстне вікно великої мовної моделі, хоча воно й зростає, все одно залишається обмеженим каналом. Наповніть його невідфільтрованими логами продуктивного середовища, і ви витратите токени на серцебиття cron-завдань та шум перевірок стану (health-checks), водночас поховавши фактичний збій. Гірше того, сирим логам бракує зв'язків. Стрибок затримки о 14:00 і помилка підключення до бази даних у логах з тим самим часовим штампом явно пов'язані, але поки хтось не структурує цей зв'язок заздалегідь, ШІ доведеться вгадувати. Вгадування — це дорого, повільно і часто помилково.

Виправлення є архітектурним, а не алгоритмічним. Ви повинні вирішити, що саме збирати, як це структурувати та який бекенд на яке запитання відповідає, ще до того, як надішлете запит (prompt) моделі.

Чотири осі моніторингу

В airCloset інженерна команда перестала сприймати observability як єдиний потік даних. Вони розділили моніторинг на чотири окремі осі. Кожна з них має свою специфічну форму та відповідає на конкретне запитання.

  • Application: Логи та трасування відповідають на питання «Що відбувається прямо зараз?»
  • Infrastructure: Метрики відповідають на питання «Чи достатньо у нас ресурсів?»
  • CI: Логи та сповіщення відповідають на питання «Що зламалося і коли?»
  • LLM: Метрики та структуровані записи відповідають на питання «Скільки ми витрачаємо?»

Таке розділення має значення, тому що правильна форма для графіка затримки в реальному часі є марною для ретроспективного аналізу витрат. Нав'язування однієї схеми для всіх чотирьох доменів створює саме той шум, який робить допомогу ШІ марною.

CI Observability: Pull, а не Push

Безперервна інтеграція (CI) — це місце, де код стикається з реальністю. Коли збірка (build) завершується помилкою, розробникам потрібно швидко отримати історію подій. Наївний підхід полягає в тому, щоб CI-раннер безпосередньо надсилав (push) логи у ваш бекенд observability під час виконання. Це здається ефективним. Насправді це небезпечно.

В airCloset вони змінили модель. CI-раннер не торкається стека observability. Після завершення робочого процесу GitHub Actions вони витягують (pull) логи через GitHub API та завантажують їх у Loki.

Така архітектура pull забезпечує три конкретні переваги.

Розв'язка (Decoupling). Якщо в конвеєрі збору даних (ingestion pipeline) стався збій або Grafana недоступна, сам запуск тесту не постраждає. Збірка проходить або провалюється на основі власних показників. Помилка в системі observability ніколи не повинна зупиняти розгортання (deployment).

Безпека. Робочому процесу CI ніколи не потрібен API-ключ Grafana. Тестовий код відомий тим, що може торкатися секретів, до яких не повинен мати доступу, і усунення такої вразливості зменшує радіус ураження (blast radius) у разі компрометації залежності.

Перехресні запити. Як тільки CI