К основному содержимому

Мониторинг AI-агентов на VDS: Langfuse и метрики

AI-агенты на VDS · 19.04.2026 · 4 мин чтения
Иллюстрация к статье «Мониторинг AI-агентов на VDS: Langfuse и метрики»

Зачем нужен мониторинг AI?

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

Langfuse — open-source AI observability

>docker run -d --name langfuse \
  -p 3000:3000 \
  -e DATABASE_URL=postgresql://postgres:password@host:5432/langfuse \
  -e NEXTAUTH_SECRET=random-secret \
  --restart always \
  langfuse/langfuse:latest

Интеграция с LangChain

from langfuse.callback import CallbackHandler
from langchain_ollama import OllamaLLM

handler = CallbackHandler(
    public_key="pk-...",
    secret_key="sk-...",
    host="http://localhost:3000"
)
llm = OllamaLLM(model="llama3.2", callbacks=[handler])
result = llm.invoke("Тестовый запрос")

Ключевые метрики для AI-агентов

МетрикаЧто измеряетЦель
LatencyВремя ответа< 5 сек
Token usageРасход токеновОптимизация стоимости
Error rateПроцент ошибок< 1%
User feedbackОценка ответовУлучшение качества

Системные метрики через Prometheus

# prometheus.yml
scrape_configs:
  - job_name: "ollama"
    static_configs:
      - targets: ["localhost:11434"]
    metrics_path: "/metrics"
Совет: Логируйте все запросы и ответы в первые недели работы — это поможет найти паттерны проблемных запросов и улучшить системные промпты.

Частые ошибки при настройке

Langfuse не стартует из-за базы данных

Error: P1001: Can't reach database server at `host`:5432

Langfuse требует отдельно поднятую PostgreSQL и не поднимает её сама внутри образа. Проверьте, что переменная DATABASE_URL указывает на реально доступный хост и порт, а сама база создана заранее — контейнер только применяет миграции, но не создаёт сервер СУБД.

Трейсы из LangChain не появляются в интерфейсе

Частая причина — callback-обработчик Langfuse не передан в вызов модели, а только создан в коде. Убедитесь, что объект handler явно указан в параметре callbacks при каждом вызове цепочки, а не только при инициализации LLM.

Дашборд Prometheus показывает пустые графики по Ollama

up{job="ollama"} == 0

Метрика up равна нулю, когда Prometheus не может достучаться до эндпоинта скрейпинга. Проверьте, что порт Ollama доступен с машины, где крутится Prometheus, и что путь /metrics действительно отдаёт данные, а не 404 — часть версий Ollama требует отдельного включения экспорта метрик.

Langfuse формирует неверные ссылки за reverse proxy

Warning: NEXTAUTH_URL is not set, using fallback

Без явно заданного NEXTAUTH_URL, указывающего на реальный публичный адрес за Nginx, сервис может генерировать redirect-ссылки на внутренний адрес контейнера. Задайте эту переменную окружения равной внешнему HTTPS-домену перед первым запуском. Проверить это проще всего, попробовав открыть страницу входа через публичный адрес и убедившись, что после логина браузер не перекидывает на внутренний порт контейнера.

Варианты AI observability

Выбор инструмента зависит от того, что именно нужно наблюдать: содержимое LLM-вызовов, системные метрики сервера или и то, и другое сразу.

ИнструментФокусSelf-hosted
LangfuseТрейсинг LLM-вызовов и промптовДа
Prometheus + GrafanaСистемные и кастомные метрикиДа
Облачные SaaS-платформы observabilityТрейсинг и аналитика без своей инфраструктурыНет
Простое логирование в файлБазовая отладка на старте проектаДа

Когда такой мониторинг избыточен

Полноценный observability-стек оправдан не на любом этапе проекта — иногда он добавляет инфраструктуру без пользы.

  • Прототип с единичными ручными запросами — трейсинг каждого вызова не даёт полезных данных при таком объёме
  • Команда из одного разработчика без внешних пользователей — хватит обычного логирования в файл
  • Бюджет VDS не позволяет держать ещё один сервис с собственной базой данных — Langfuse требует отдельную PostgreSQL и заметный объём RAM
  • Нужна только проверка аптайма сервиса, а не разбор содержимого ответов — для этого достаточно простого healthcheck
  • Все LLM-вызовы уже логируются в существующую систему логирования приложения — дублировать её вторым сервисом не всегда оправдано

Проверка результата

После настройки стоит убедиться, что данные действительно доходят от вызова модели до дашборда.

  1. Откройте интерфейс Langfuse и убедитесь, что тестовый вызов модели появился в списке трейсов
  2. Проверьте, что в трейсе видны промпт, ответ и время выполнения
  3. Откройте /metrics у Ollama напрямую и убедитесь, что эндпоинт отдаёт данные
  4. Проверьте в Prometheus, что таргет ollama находится в статусе UP
  5. Откройте Langfuse через публичный домен и убедитесь, что редиректы не ведут на внутренний адрес контейнера
curl http://localhost:11434/metrics | head

По теме: агенты, которые стоит мониторить — что такое AI-агент, фреймворк с готовыми callback'ами — LangChain на VDS.

Статья помогла?
← Назад в базу знаний Задать вопрос поддержке