Дежурство по логам с контролируемым ИИ-агентом

Логи часто узнают об инциденте раньше дашбордов и пользовательских обращений. Однако поток warn и error быстро становится слишком большим для ручного просмотра, а простые пороговые алерты срабатывают на ожидаемые ретраи. ИИ-агент может стать дополнительным слоем наблюдаемости: раз в несколько минут он получает выборку событий, оценивает контекст и отправляет сообщение только при выполнении строгих условий.

Такой агент нельзя считать автономным инженером. Его полезная роль — отобрать кандидаты на инцидент, приложить проверяемые числа и быстро донести сигнал до команды. Надёжность достигается ограничениями вокруг модели: детерминированным сбором данных, независимой проверкой, дедупликацией и контролем самого процесса мониторинга.

Разделите сбор данных и принятие решения

Начинать стоит с маленького скрипта, который запрашивает Loki или другую систему логирования за фиксированное окно. Например, раз в 30 минут можно получать записи уровня error и warn за последние пять минут. Скрипт должен сам формировать запрос, передавать учётные данные и возвращать нормализованный результат. Модели не следует поручать конструирование произвольных запросов к инфраструктуре.

Это даёт несколько преимуществ:

права доступа скрипта легко ограничить чтением;
формат входных данных стабилен и пригоден для тестов;
запрос можно повторить вручную при разборе алерта;
агенту доступен ровно тот объём телеметрии, который нужен для задачи.

Первый проход должен быть дешёвым. Агент выделяет сигнатуры ошибок, сервисы и частоты, затем расширяет временное окно для кандидатов. Сравнение с часовым или суточным базлайном помогает отличить всплеск от хронического шума. Для практического правила достаточно двух классов: пользовательские 5xx, потеря данных и проблемы с платежами получают высокий приоритет; остальные события требуют измеримого роста частоты, например минимум пяти записей за пять минут и двукратного превышения базлайна.

Молчание — нормальный результат цикла

Ценность канала оповещений определяется отношением полезных сообщений к фону. Когда каждое штатное исключение приходит в Telegram, команда быстро перестаёт читать канал. Поэтому успешным следует считать и цикл, в котором не произошло ничего достойного внимания.

Полезно задать явное целевое значение: 80–90% проверок завершаются без отправки сообщения. Алерт должен содержать причину решения, чтобы человек проверил его за минуту: сервис, временное окно, фактическое число событий, базлайн, коэффициент роста и сработавшее правило. Такой формат превращает сообщение в отправную точку расследования, а не в загадочное мнение модели.

Доставка требует отдельного ограничения. Финальный текст агента не должен автоматически попадать в рабочий канал. Единственный путь отправки — явный вызов API после завершения всех проверок. Это защищает от черновых рассуждений, сообщений об ошибках выполнения и многословных промежуточных выводов. Канал остаётся инструментом оперативной работы даже при смене модели или рантайма.

Дедупликация с эскалацией

Одна проблема часто создаёт сотни одинаковых записей. Для этого нужна память о последних уведомлениях. Практичная сигнатура складывается из имени сервиса, класса ошибки и первого значимого токена сообщения. Хранить её можно в небольшом JSON-файле, обновляемом атомарным скриптом.

После отправки алерта сигнатура подавляется на ограниченное время, например на два часа. Повтор разрешается только при заметном ухудшении — росте частоты в три раза. Такой механизм сохраняет видимость развития инцидента, но не превращает ленту в повтор одного и того же текста.

Память дедупликации тоже нуждается в обслуживании. Если весь архив без ограничений попадает в контекст каждого запуска, стоимость и задержка цикла растут вместе с возрастом агента. Ограничивайте срок хранения записей, оставляйте только поля, которые требуются для решения, и регулярно измеряйте размер контекста.

Проверяйте находки другим способом

Главный риск при использовании модели — уверенное сообщение с неверными цифрами. Модель может ошибиться в подсчёте, экстраполировать короткое окно или принять штатное событие за ошибку. Самопроверка в том же контексте редко помогает: первоначальная гипотеза влияет на повторное решение.

Надёжнее построить контур из детектора и верификатора. Детектор передаёт второму шагу только кандидата, конфигурацию и необработанные данные. Верификатор применяет другой запрос и другой способ подсчёта. Если первый шаг использовал поиск по строке и агрегат count_over_time, второй может выбрать более точное регулярное выражение и посчитать метки времени сырыми строками.

Результаты следует сравнивать формальным правилом. Например, вычислить отношение большего значения к меньшему и отклонять кандидата при коэффициенте больше двух. Отдельный скрипт верификации ещё надёжнее: он пересчитывает число событий без участия LLM и хорошо покрывается smoke-тестами. Если независимая проверка недоступна, корректное действие — записать неопределённый результат и повторить проверку в следующем цикле.

В промпте полезны короткие таблицы типичных рационализаций: «проверка излишня, ошибка очевидна», «числа достаточно близки», «система логов временно недоступна». Рядом должно стоять предписанное действие: проверять, отклонять или отложить. Явные правила уменьшают вероятность того, что модель срежет угол ради убедительного ответа.

Учитывайте недоверенный ввод и доступы

Строки журналов — недоверенный ввод. В них может оказаться пользовательский текст, некорректные данные или попытка повлиять на поведение модели. Агент не должен иметь секретов, прав на изменение прод-среды, доступа к деплою или возможности выполнить произвольную команду. Для задачи мониторинга обычно достаточно чтения логов, чтения кода и отправки сообщения в один контролируемый канал.

Логи также могут содержать персональные данные и токены. До передачи телеметрии внешней модели определите правила логирования: исключите секреты и лишние идентификаторы на уровне приложения, маскируйте чувствительные поля в сборщике либо используйте локальную модель. Это требование относится к наблюдаемости в целом, а не только к агентам.

Агенту нужен свой мониторинг

Тишина бывает хорошим исходом проверки и одновременно симптомом поломки. Планировщик может перестать запускать задания после обновления, рантайм — потерять совместимость с новой версией Node.js, а лимит провайдера модели — закончиться. Без дополнительного сигнала эти состояния выглядят одинаково.

Добавьте heartbeat: ежедневный дайджест с количеством запусков, долей успешных циклов, числом отправленных и подавленных алертов, ошибками доступа и текущими задержками. Отсутствие дайджеста само по себе означает инцидент в контуре мониторинга. Проверяйте и его доставку: длинная сводка может регулярно упираться в таймаут, поэтому у heartbeat должны быть метрики успеха.

Минимальный каркас

Для первого рабочего варианта достаточно восьми компонентов:

Скрипт чтения логов с правами только на чтение.
Расписание с небольшим фиксированным интервалом.
Правила важности, записанные в конфигурации.
Базлайн и пороги роста.
Хранилище сигнатур для дедупликации и эскалации.
Независимая верификация счётчиков.
Явная отправка сообщения после проверки.
Heartbeat и отдельная проверка его доставки.

Такой контур можно постепенно подключить к существующим алертам. Сначала агент работает в тестовом канале и сохраняет решения в журнал. Затем команда сверяет его выводы с реальными инцидентами, корректирует сигнатуры и пороги, а после этого добавляет рабочую доставку. В результате логи становятся источником ранних, объяснимых сигналов без постоянного ручного просмотра.