Дашборд ИИ-агента в Grafana: 12 метрик, которые ловят проблему раньше клиента

Вечер пятницы, уже собирался домой. Пишет менеджер из логистической компании: «Секретарь второй час молчит на письма от клиентов». Открываю дашборд — http_requests_total зелёный, p99 latency в норме, CPU не греется, память спокойная. По всем классическим метрикам прод здоров как бык. А секретарь, который должен разбирать входящие, действительно их не разбирает.

Разобрались не сразу. GigaChat Pro начал отдавать пустые completions на большой доле запросов — формально с кодом 200, без единой ошибки, просто choices[0].message.content = "". Наш агент честно записывал результат «ничего не делать» и шёл за следующим письмом. HTTP-метрики счастливы. Бизнес-логика мертва. Клиент недоволен.

После той истории мы переписали наблюдаемость с нуля. Ниже — 12 метрик, которые сейчас крутятся на дашборде каждого нашего проекта с ИИ-агентом. Это не «список лучших практик из статьи на Medium», а живой набор, где каждая позиция появилась после конкретной боли. Если вы строите систему ИИ-агентов в 2026 году и до сих пор смотрите только на латентность — этот текст для вас.

Почему классический APM не видит ИИ-агента

Стандартный набор «RED + USE» (Rate, Errors, Duration / Utilization, Saturation, Errors) был придуман для синхронных HTTP-сервисов. ИИ-агент — это длинный пайплайн с обращением во внешний сервис, который умеет вернуть «успех», но семантически провалить задачу. У вас 200 OK, но JSON битый. У вас латентность в норме, но модель ответила «извините, не могу помочь». У вас нагрузки нет, потому что агент ждёт ответа на висящий запрос уже неприлично долго.

Поэтому метрики ИИ-агента у нас делятся на три слоя: транспортный (как себя чувствует HTTP до LLM), смысловой (что именно модель вернула) и бизнесовый (что в итоге произошло с задачей). На дашборде должны быть все три, иначе будете чинить здоровый сервис, пока клиент чинит ваш бизнес. Это относится и к облачным моделям, и к локальному ИИ-агенту на своей инфраструктуре — снаружи разница только в природе тайм-аутов, а слои те же.

Транспортный слой: четыре метрики

1. llm_request_duration_seconds (гистограмма по модели и эндпоинту). Очевидная вещь, но дьявол в нарезке. У GigaChat Pro на типовой запрос средних размеров медиана держится в районе пары секунд, хвост уползает на десяток. Если p99 внезапно уехал сильно выше привычного — у провайдера деградация, пора включать резервный маршрут. Гистограмму обязательно бить по модели: смешивать тайминги Pro и Lite — потеря времени.

2. llm_request_failures_total (счётчик по типу ошибки). Ключевое — нормализованный label error_type: timeout, rate_limit, auth, 5xx, parse_error, empty_completion. Последний — самое подлое. Пустой ответ для нас это отдельная категория ошибки, потому что HTTP-слой не считает её ошибкой, а агент — должен.

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

3. llm_retry_attempts (гистограмма по числу попыток до успеха). Если у вас в норме почти всё проходит с первой попытки, а вдруг гистограмма расползлась в сторону вторых и третьих ретраев — у провайдера тонкая деградация. В ошибках её ещё не видно, но она уже стоит вам денег и латентности. Мы такое ловили пару раз, и оба раза починка на стороне провайдера прилетала часа через полтора.

4. llm_circuit_breaker_state (gauge: 0/1/2). Закрыт/полуоткрыт/открыт. Когда автоматика переключается на резервную модель — это должно быть видно цифрой на дашборде, а не догадкой по логам в три часа ночи.

Смысловой слой: четыре метрики, ради которых всё затевалось

5. llm_response_tokens (гистограмма output-токенов). Когда GigaChat в ту пятницу начал отдавать пустые ответы, эта метрика рухнула буквально за считанные минуты — медиана обвалилась почти в ноль. Если бы у нас тогда был алерт «медиана output-токенов заметно просела за короткое окно» — мы бы узнали о проблеме до того, как клиент дошёл до чата поддержки. Сейчас есть.

6. llm_schema_validation_failures_total. У нас почти все вызовы со structured output: JSON Schema, валидируется pydantic. Каждый провал валидации — это бесплатный сигнал «модель поплыла». В норме процент валидационных провалов держится где-то на уровне долей процента. Если он внезапно вырос в разы — повод не откладывать разбор до понедельника.

7. llm_refusal_rate (counter). Грубая эвристика на ключевые фразы: «извините, я не могу», «как языковая модель», «у меня нет доступа». Считаем долю refusal-ответов в пятиминутном окне. Обычно она околонулевая. Когда мы катили миграцию на новую версию модели и забыли перенести в системный промпт часть про роль — refusal-rate заметно подскочил, а в чате клиента секретарь начал жалобно отказываться отвечать на простые вопросы. Смешно, если бы не было стыдно.

8. llm_output_quality_score. Самое интересное. Берём небольшую долю ответов в семпл, гоним их через лёгкую модель-судью с фиксированным промптом «оцени, осмыслен ли ответ от 1 до 5». Метрика, честно, грязноватая, но тренд показывает правдиво. Когда RAG в очередной раз поплыл из-за обновления эмбеддингов (векторы у нас размерности 1024) — score сполз вниз ещё до того, как это заметили менеджеры. Пришлось признаваться и откатывать.

Бизнес-слой: четыре метрики, на которые смотрит CEO

9. agent_task_completion_rate. Сколько задач из тех, что взялись в работу, доехали до выхода со статусом «выполнено». Не «модель ответила без ошибки», а именно «выход бизнес-пайплайна». Для секретаря это «письмо разобрано, маршрут проставлен, ответственный назначен». Для агента с MCP-инструментами — «нужное действие в подключённой системе действительно произошло». Кстати, отдельная песня: если ИИ-агент через MCP ходит в чужие сервисы, статус «выполнено» иногда врёт из-за eventual consistency на той стороне. Мы для критичных вызовов делаем догоняющую проверку.

10. agent_human_handoff_rate. Доля задач, которые агент эскалировал на оператора. Если она ползёт вверх — модель потеряла уверенность или поменялось входящее распределение задач. Падение тоже подозрительно: возможно, агент стал слишком самоуверенным и начал брать на себя то, что должен пасовать человеку. Один из заказчиков (производственная компания) как раз на этом поймал момент, когда обновление промпта сделало агента чересчур бодрым — стали проскакивать ответы, где он «додумывал» реквизиты.

11. agent_queue_age_seconds (gauge: возраст самой старой задачи в очереди). Не длина очереди, а именно возраст. Длина в две сотни при среднем времени обработки в несколько секунд — норма. Длина пять при возрасте старшей задачи под час — катастрофа: что-то застряло, и об этом обязан узнать дежурный. Именно эта метрика у нас чаще всего первой видит редкие, но противные подвисания.

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

Алерты: что орёт ночью, а что ждёт утра

Правило простое: будит дежурного только то, что бьёт по клиенту прямо сейчас. Всё остальное — в утренний дайджест.

Будит ночью: agent_queue_age_seconds уехал за несколько минут (задача явно зависла), пошёл вал empty_completion, agent_task_completion_rate за пятнадцатиминутное окно провалился ниже нашего порога, circuit breaker открылся.

Ждёт утра: медленный дрейф llm_output_quality_score, постепенный рост стоимости задачи, рост числа ретраев в норме. Это инженерные сигналы, а не пожар.

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

Как это вынуто из FastAPI

Метрики кладём через prometheus_client, экспортируем /metrics, Grafana подтягивает с интервалом в пятнадцать секунд. Лейблы держим короткими: model, endpoint, tenant, error_type. Никаких user_id в лейблах — это прямой путь к взрыву кардинальности и мёртвому Prometheus. Обжигались, знаем.

Для трассировки конкретных задач — OpenTelemetry-спаны и Tempo, метрики и трейсы связаны через exemplars. Клик по «горбику» на гистограмме открывает конкретный trace с полным путём задачи: получили письмо, распарсили, сходили в RAG, дёрнули модель, вызвали MCP-инструмент, записали результат. Если агент работает с персональными данными клиентов — а по 152-ФЗ у нас это почти всегда — трейсы храним отдельно и с более коротким retention, чтобы не таскать лишнего.

Дашборд разбит на три ряда — ровно по трём слоям. Сверху бизнес: completion rate, handoff, queue age, стоимость. Посередине смысловой слой. Внизу транспорт. Глаз дежурного бежит сверху вниз — от «болит ли клиенту» к «что именно сломалось».

Что мы поняли за два года такого мониторинга

ИИ-агент здоров не тогда, когда у него зелёные HTTP-метрики, а тогда, когда зелёная нижняя строчка отчёта: задачи закрываются, клиенты не пишут в поддержку, стоимость на задачу не растёт. Всё остальное — диагностические сигналы, которые помогают понять, почему вдруг покраснело.

И главное: половина этих метрик появилась на дашборде после конкретного инцидента, в котором мы узнали о проблеме от клиента, а не от системы. Это неприятно, стыдно, полезно — именно в таком порядке. Если вы держите ИИ-агента в проде и до сих пор смотрите только на p99 latency, у вас просто пока не было своего вечера пятницы. Он будет. Лучше встретить его с включённым светом.

Похожие статьи

• Как мы научили ИИ-агента на GigaChat Pro не путать живого клиента с ночным батчем
• Как мы настроили ИИ-агента для поиска в 1С: MCP-сервер вместо метаний между окнами
• Один вопрос — три темы: как мы научили ИИ-агента разбирать составные запросы
• Text2SQL для 340 таблиц: как мы собирали ИИ-агента для анализа корпоративных данных на GigaChat Pro