ИИ изменил то, как мы создаем программное обеспечение, но он не изменил базовую истину о машинах: они тонут в шуме точно так же, как и мы. Когда инженеры впервые экспериментируют с отладкой с помощью ИИ, их инстинкт прост: скормить модели всё. Сырые логи, трассировки и метрики — всё сваливается в контекстное окно. Результатом становится не понимание, а провал. Объем данных слишком велик. Сигнал теряется. Метрики находятся в одном инструменте, трассировки — в другом, и модель не может связать их в единую связную историю. Прежде чем ИИ сможет помочь вам в наблюдении за вашими системами, вы должны научиться наблюдать за ними сами. Сначала нужно структурировать данные.

Почему сырые логи ломают конвейеры ИИ

Современные системы генерируют телеметрию со скоростью, которую не может прочитать ни один человек. Казалось бы, это должно делать их идеальными для искусственного интеллекта. Но это не так. Контекстное окно большой языковой модели, хоть и растет, все еще остается конечным каналом. Забивая его нефильтрованными логами из продакшена, вы тратите токены на сигналы активности (heartbeats) задач cron и шум проверок состояния (health-checks), скрывая при этом информацию о реальном сбое. Хуже того, сырым логам не хватает взаимосвязей. Скачок задержки в 14:00 и ошибка подключения к базе данных в логе с той же временной меткой явно связаны, но пока кто-то не выстроил эту связь заранее, ИИ приходится гадать. Гадание — это дорого, медленно и часто ошибочно.

Решение лежит в области архитектуры, а не алгоритмов. Вы должны решить, что собирать, как структурировать данные и какой бэкенд отвечает на какой вопрос, еще до того, как отправите промпт модели.

Четыре оси мониторинга

В airCloset инженерная команда перестала относиться к наблюдаемости (observability) как к единому бесконечному потоку данных. Они разделили мониторинг на четыре отдельные оси. Каждая из них имеет свою структуру и отвечает на конкретный вопрос.

  • Application: Логи и трассировки отвечают на вопрос: «Что происходит прямо сейчас?»
  • Infrastructure: Метрики отвечают на вопрос: «Достаточно ли у нас ресурсов?»
  • CI: Логи и алерты отвечают на вопрос: «Что сломалось и когда?»
  • LLM: Метрики и структурированные записи отвечают на вопрос: «Сколько мы тратим?»

Это разделение важно, потому что формат данных, подходящий для графика задержки в реальном времени, бесполезен для апостериорного анализа затрат. Навязывание одной схемы для всех четырех доменов создает именно тот шум, который делает помощь ИИ бесполезной.

CI Observability: Pull, а не Push

Непрерывная интеграция (CI) — это место, где код сталкивается с реальностью. Когда сборка завершается ошибкой, разработчикам нужно быстро получить информацию о причинах. Наивный подход заключается в том, чтобы CI-раннер напрямую отправлял (push) логи в ваш бэкенд наблюдаемости по мере их выполнения. Это кажется эффективным, но на самом деле это опасно.

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

Такая архитектура типа pull дает три конкретных преимущества.

Развязка. Если в конвейере загрузки данных произойдет сбой или Grafana будет недоступна, сам запуск тестов не пострадает. Сборка проходит или проваливается исходя из собственных результатов. Сбой в системе наблюдаемости никогда не должен приводить к срыву развертывания.

Безопасность. Workflow CI никогда не требует API-ключ Grafana. Тестовый код известен тем, что может затронуть секреты, к которым у него не должно быть доступа, и устранение этой возможности уменьшает радиус поражения в случае компрометации зависимости.

Кросс-запросы. Как только CI