Мониторинг AI агентов: как следить за здоровьем всей системы

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

В этой статье разберу, как выстроить систему мониторинга AI агентов с нуля: что именно отслеживать, как реализовать heartbeat через PostgreSQL, настроить алерты в Telegram, считать расходы на токены на уровне каждого агента и построить единый дашборд. Плюс — реальный кейс, когда агент мониторинга лидов молчал три часа, и мы даже не подозревали.

Почему мониторинг AI агентов — это отдельная задача

AI агенты сломаны иначе, чем обычные сервисы. Когда падает веб-сервер — он возвращает 500, и это видно сразу. Когда агент перестаёт работать — он может продолжать "принимать" запросы, отвечать "запускаю задачу" и при этом ничего не делать. Тихий отказ (silent failure) — самый коварный тип сбоя в распределённых системах с AI.

Я управляю 16 AI агентами, каждый из которых отвечает за свою область: мониторинг лидов в WhatsApp-группах, публикация контента в соцсети, управление задачами, анализ бронирований, рассылка предложений. Когда их было три — я мог держать всё в голове. Когда стало больше десяти — начались проблемы, которые я не видел неделями.

Вот конкретная ситуация: агент мониторинга лидов WhatsApp несколько дней исправно "находил" лидов в чатах, оценивал их и собирался сохранять в базу. Но в момент записи всё падало с ошибкой SQL. Два поля перепутаны местами в параметрах запроса. За эти дни не сохранился ни один горячий лид. При этом бот был онлайн, отвечал на команды и выглядел рабочим. Я обнаружил это случайно, когда вручную проверял базу данных.

Мониторинг AI агентов нужен не для красивых графиков. Он нужен, чтобы ты знал: каждый агент делает своё дело прямо сейчас, а не молча висит в воздухе.

Что именно нужно мониторить в AI агентах

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

1. Heartbeat — последний сигнал жизни

Heartbeat — это временная метка последнего успешного действия агента. Каждые 30 секунд (или при выполнении любого действия) агент пишет в базу данных: "я живой, время вот такое". Watchdog — отдельный процесс — читает эту таблицу и проверяет: если агент не обновлял heartbeat больше пяти минут, значит с ним что-то не так.

Это самая важная метрика. Всё остальное бессмысленно, если агент вообще не запущен или завис в бесконечном цикле ожидания.

2. Количество обработанных задач

Каждый агент должен иметь счётчик задач: сколько обработано за последний час, за сутки, за неделю. Это позволяет видеть аномалии. Если агент мониторинга лидов в среднем находит 15 потенциальных клиентов в час, а за последние два часа нашёл ноль — это повод для проверки, даже если heartbeat в порядке.

Важно задать baseline для каждого агента отдельно. У агента публикации контента может быть 3 задачи в день — это нормально. У агента мониторинга WhatsApp-групп — 50 событий в час. Пороги аномалий для каждого свои.

3. Время ответа (latency)

Агент обрабатывает задачу — сколько это занимает? Если обычно ответ приходит за 3 секунды, а последние полчаса занимает 45 секунд — это сигнал. Либо перегружен внешний API, либо агент попал в бесконечный цикл переповторов, либо выросла очередь задач.

Latency — это часто первый симптом проблемы. Агент ещё работает, задачи обрабатываются, но медленно. Если ловить этот момент, можно устранить причину до того, как система полностью встанет.

4. Процент ошибок (error rate)

Сколько задач завершается ошибкой от общего числа? 1–2% ошибок — нормально для системы, которая работает с внешними API и пользовательскими данными. 20% ошибок — явная проблема. 80% — система фактически не работает, несмотря на то что формально запущена.

Именно такую ситуацию мы поймали с агентом сохранения лидов. Error rate был близок к 100% — каждая попытка записать лид в базу завершалась ошибкой SQL. Но без мониторинга error rate мы бы увидели это только при ручной проверке.

5. Потребление токенов и расходы на AI API

Это метрика, о которой часто забывают — и очень зря. Каждый вызов к Claude, GPT-4o или другой языковой модели стоит денег. Если не считать расходы на уровне каждого агента, ты быстро получишь неприятный сюрприз в счёте.

У меня был случай: один агент работал на Claude Opus, хотя вполне справился бы с задачами на более дешёвой модели. В результате только этот агент тратил $320 в месяц из общего бюджета в $1000. Аудит токенов на уровне каждого агента — это стандартная практика в зрелой AI-инфраструктуре. Подробнее об оптимизации расходов я писал в статье про оптимизацию стоимости AI агентов.

6. Системные ресурсы: память и CPU

AI агенты — это процессы на сервере. Если один агент начал потреблять всю доступную память, остальные начнут деградировать или падать. Мониторинг RSS памяти и загрузки CPU для каждого процесса — базовая гигиена инфраструктуры.

Особенно важно следить за memory leak: агент может работать нормально часами, но постепенно накапливать данные в памяти и через сутки начать тормозить весь сервер.

Реализация: heartbeat через PostgreSQL

Самый надёжный и простой способ реализовать heartbeat для AI агентов — писать метки в PostgreSQL. Никаких дополнительных сервисов, никакой сложной инфраструктуры. База данных у тебя уже есть, если агенты хранят в ней рабочие данные.

Структура таблицы heartbeat

Каждый агент при каждом действии (или просто по таймеру раз в 30 секунд) выполняет UPSERT в эту таблицу. Это занимает миллисекунды и не влияет на производительность.

Watchdog — процесс-надсмотрщик

Watchdog — это отдельный лёгкий процесс, который раз в минуту читает таблицу heartbeat и проверяет условия тревоги. Логика простая: если last_seen у агента старше пяти минут — что-то пошло не так.

Watchdog не должен зависеть от агентов, которые мониторит. Это отдельный процесс с собственным циклом выполнения, supervisord или systemd unit. Если упадёт сам watchdog — это тоже нужно отслеживать, поэтому у него тоже есть внешняя проверка (например, UptimeRobot пингует HTTP endpoint watchdog каждую минуту).

Алерты в Telegram

Telegram — идеальный канал для алертов. API простой, боты бесплатные, уведомления приходят мгновенно на телефон. Когда watchdog обнаруживает проблему, он отправляет сообщение в специальный Telegram-чат:

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

Важно настроить debounce для алертов — чтобы одна и та же проблема не спамила десятками уведомлений. Об этом я подробно писал в статье про debounce для AI-ассистента.

Единый дашборд: один экран для всех агентов

Алерты решают реактивную задачу: что-то сломалось — ты узнал. Дашборд решает проактивную: ты в любой момент видишь состояние всей системы без необходимости что-то специально проверять.

Prometheus + Grafana: промышленный стандарт

Если у тебя серьёзная инфраструктура с десятками агентов, Prometheus + Grafana — правильный выбор. Prometheus собирает метрики по HTTP endpoint от каждого агента (/metrics в формате OpenMetrics). Grafana строит дашборды с историей, алертами и аннотациями.

Преимущества: история метрик за месяцы, мощные запросы на PromQL, готовые дашборды для Node.js/Python/любого стека, алерты с routing (разные проблемы — разные каналы уведомлений). Недостатки: это инфраструктура, которую нужно поддерживать. Для небольшой системы может быть избыточно.

Кастомный дашборд на PostgreSQL

Для нашего стека я выбрал более простой путь: кастомный веб-дашборд, который читает данные напрямую из PostgreSQL таблицы heartbeat. Небольшой Node.js или Python сервер, который отдаёт HTML страницу с таблицей агентов, обновляющейся каждые 30 секунд.

Страница выглядит так: таблица, одна строка — один агент. Колонки: имя агента, статус (зелёный/красный кружок), время последнего heartbeat, задачи за час, error rate, расходы за сегодня. Никакого JavaScript-фреймворка, минимум зависимостей, максимум надёжности.

Такой дашборд занимает полдня на реализацию, работает без внешних зависимостей и даёт всё необходимое для повседневного наблюдения за системой.

Что показывает хороший дашборд

• Статус в реальном времени: каждый агент — зелёный (активен), жёлтый (давно не обновлял heartbeat), красный (превышен порог молчания)
• Последний heartbeat: время и сколько минут назад
• Throughput: задачи за последние час и сутки
• Error rate: процент ошибок за последние 24 часа
• Latency: среднее время обработки задачи
• Токены и расходы: сколько потрачено сегодня на AI API
• Тренд: стрелка вверх/вниз относительно вчера

Мониторинг расходов на токены: деньги как метрика

Стоимость токенов — это метрика, которую редко включают в системы мониторинга, и совершенно напрасно. В нашей системе с 16 агентами разница между правильно настроенным расходом токенов и неоптимальным — это разница между $300 и $1000 в месяц.

Каждый вызов к Claude или GPT-4o возвращает в ответе количество использованных токенов (prompt_tokens и completion_tokens). Агент должен логировать это число при каждом вызове и суммировать в heartbeat таблице.

Как считать стоимость в реальном времени

Алгоритм простой. При каждом вызове AI API:

• Получаем prompt_tokens и completion_tokens из ответа
• Умножаем на текущую стоимость модели (например, для Claude Sonnet: $3 за 1M input tokens, $15 за 1M output tokens)
• Добавляем к счётчику tokens_used_today и cost_usd_today в heartbeat
• Watchdog проверяет: если агент потратил больше дневного лимита — отправляет алерт

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

Выбор модели как часть архитектуры мониторинга

Когда ты видишь расходы каждого агента в реальном времени, возникает естественный вопрос: а эта задача вообще требует самой умной и дорогой модели? Многие задачи в автоматизации бизнеса — это структурированное извлечение данных, классификация, простые ответы по шаблону. Для этого не нужен Claude Opus или GPT-4o. Sonnet или Haiku справятся за 10% стоимости.

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

Централизованные логи: видеть картину целиком

Heartbeat и метрики говорят "что происходит". Логи говорят "почему". Централизованные логи — это когда все агенты пишут в одно место, и ты можешь искать по всем сразу.

Простой вариант: tail в Telegram

Если не хочется разворачивать сложную инфраструктуру — самый простой вариант: каждый агент при ошибке отправляет стектрейс и контекст в специальный Telegram-чат "Логи". Не все логи — только ошибки и предупреждения. Плюс — ежедневная сводка утром: сколько задач обработал каждый агент вчера.

Этого достаточно для небольшой системы из 5–10 агентов. Минус — поиск по истории неудобен, Telegram не очень подходит для анализа логов.

ELK Stack: промышленный подход

ELK (Elasticsearch + Logstash + Kibana) — стандарт для централизованного логирования. Агенты пишут структурированные JSON-логи (с полями: timestamp, agent_id, level, message, context). Logstash или Filebeat собирают логи и отправляют в Elasticsearch. Kibana предоставляет интерфейс для поиска и визуализации.

Ключевые преимущества ELK: полнотекстовый поиск по всем логам всех агентов, фильтрация по времени и агенту, автоматические алерты на паттерны ошибок. Это серьёзная инфраструктура, но если у тебя 16+ агентов, генерирующих тысячи событий в день — без неё сложно.

Структура лога как контракт

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

• timestamp — ISO 8601 с временной зоной
• agent_id — идентификатор агента
• level — DEBUG / INFO / WARN / ERROR / CRITICAL
• message — человекочитаемое описание события
• task_id — идентификатор задачи, если событие привязано к конкретной задаче
• duration_ms — время выполнения для операций
• error — объект с типом и стектрейсом для ошибок

Кейс: как мы обнаружили что WhatsApp-агент молчал 3 часа

Это случилось в один из обычных рабочих дней. Агент мониторинга лидов в WhatsApp-группах был запущен, отвечал на heartbeat запросы, показывал статус "active". Всё выглядело нормально.

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

Обнаружили случайно: я открыл базу данных проверить статистику лидов за день и увидел, что за три часа в рабочее время не записано ни одного лида. При нормальной работе должно быть 30–50. Это был тот самый баг с перепутанными параметрами SQL запроса — два поля в другом порядке, и вставка в таблицу падала с ошибкой несоответствия типов.

После этого инцидента мы добавили в мониторинг:

• Счётчик успешных записей в базу (не просто "агент живой", а "агент делает полезную работу")
• Алерт если throughput упал ниже 50% от среднего за последние 7 дней
• Отправку всех ошибок уровня ERROR и выше в Telegram немедленно
• Ежечасный отчёт: сколько лидов найдено vs сколько записано (если есть разница — что-то не так)

Главный урок: heartbeat без бизнес-метрик — это иллюзия мониторинга. Агент может быть "живым" и при этом не выполнять свою функцию. Нужно мониторить не только факт работы, но и результат работы.

Архитектура системы мониторинга: как всё связано

Собирая всё вместе, архитектура мониторинга AI агентов выглядит так:

Каждый уровень должен быть независим от других. Если упадёт дашборд — алерты продолжат работать. Если упадёт Elasticsearch — heartbeat в PostgreSQL продолжат записываться. Мониторинг должен быть надёжнее того, что он мониторит.

Self-healing как следующий шаг

После того как мониторинг настроен и работает стабильно, следующий шаг — автоматическое восстановление. Watchdog не просто отправляет алерт, но и пытается перезапустить упавший агент. Если агент падает три раза подряд — только тогда эскалирует к человеку.

Подробнее об архитектуре self-healing систем я писал в статье про self-healing ботов. Мониторинг и самовосстановление — две стороны одной медали.

Практические советы по внедрению

Несколько конкретных рекомендаций, выработанных на практике управления 16 агентами.

Начни с heartbeat — это быстро и ценно

Не пытайся сразу построить идеальную систему мониторинга. Начни с heartbeat: одна таблица в PostgreSQL, агент пишет timestamp раз в 30 секунд, watchdog проверяет раз в минуту. Это можно сделать за несколько часов и сразу получить ценность.

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

Тестируй алерты регулярно

Алерты, которые ни разу не срабатывали — это потенциально сломанные алерты. Раз в месяц вручную останавливай агента и проверяй: пришло ли уведомление в Telegram, правильное ли содержание сообщения, сколько времени прошло до алерта.

Мониторинг мониторинга — это не паранойя. Это единственный способ знать, что система обнаружения проблем сама работает корректно.

Разные пороги для разных агентов

Не устанавливай одинаковые пороги молчания для всех агентов. Агент, который мониторит WhatsApp-сообщения в режиме реального времени, должен обновлять heartbeat каждые 30 секунд. Агент, который раз в ночь генерирует еженедельный отчёт, может не писать heartbeat несколько часов — и это нормально.

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

Исторические данные для анализа трендов

Текущее состояние — это только половина картины. Важно хранить историю метрик: как менялась latency за последний месяц, есть ли деградация производительности, в какие часы агент обрабатывает больше задач. Для этого нужна отдельная таблица с историческими значениями, куда heartbeat данные копируются с нужной периодичностью (например, каждые 5 минут).

Эта история помогает диагностировать скрытые проблемы: агент не падает, но постепенно становится медленнее. Без трендов такую деградацию заметить сложно.

Мониторинг AI агентов — это инвестиция, которая окупается

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

Автоматизация без мониторинга — это как ехать с завязанными глазами. Система работает, пока не перестаёт. И ты об этом не знаешь, пока не спрашиваешь. А когда начинаешь спрашивать — оказывается, что проблема была уже давно.

Правильный мониторинг AI агентов — это:

• Heartbeat каждые 30 секунд в PostgreSQL — ты знаешь, что агент живой
• Бизнес-метрики (throughput, error rate) — ты знаешь, что агент делает полезную работу
• Мониторинг токенов и расходов — ты знаешь, сколько это стоит
• Алерты в Telegram — ты узнаёшь о проблеме немедленно, а не случайно
• Единый дашборд — ты видишь состояние всей системы одним взглядом
• Централизованные логи — ты понимаешь, почему что-то пошло не так

Если у тебя больше трёх AI агентов, и у тебя нет системы мониторинга — у тебя есть скрытые проблемы, о которых ты просто не знаешь. Это вопрос не "если", а "когда" ты о них узнаешь и как дорого это обойдётся.