Отладка и аудит LLM-приложений

Исторические логи запросов и ответов, ваша телеметрия в Prometheus, опциональный audit-лог изменений конфигурации. Расследование LLM-инцидентов сокращается с дней до минут.

Проблема

LLM-запросы непрозрачны в отличие от обычных API-вызовов:

Промпт динамический — собирается из шаблонов, контекста пользователя, RAG-результатов; одна и та же кнопка приложения может каждый раз отправлять разный запрос.
Ответ нестабильный — даже при temperature: 0 модели возвращают разные ответы между вызовами.
Ошибки воспроизводимы через раз — 429, 5xx, тайм-ауты появляются у одних пользователей и не появляются у других.

Без полной истории «какой именно prompt был отправлен и какой completion вернулся» отладка превращается в гадание; расследование инцидентов безопасности и compliance — невозможны.

Кого это касается: разработчики (отладка качества ответов и регрессий), SRE (incident response, поиск root cause), compliance/безопасность (аудит того, кто, когда и что отправлял в LLM).

Решение

Расследование LLM-инцидентов: часы → минуты. Прямой переход «жалоба → конкретный запрос → prompt и completion» без воспроизведения с нуля.
Аудит compliance отчёт за минуты. Запрос к Audit log даёт упорядоченную историю изменений вместо ручного сбора по почте и тикетам. Можно интегрировать в вашу систему compliance и security мониторинга.
Видимость расхода в реальном времени. Гистограммы по провайдерам, моделям, командам показывают, куда уходит бюджет; алерт срабатывает до того, как лимит достигнут предела.
Воспроизводимость поведения. Полные логи позволяют разработчику отладить регрессии модели; A/B-сравнения между моделями делаются на реальных запросах, а не синтетике.
Готовая интеграция с корпоративным мониторингом. Prometheus + OpenTelemetry экспозиции работают «из коробки»; SIEM и витрины данных подключаются к /api/logs.

Что предлагает Meridian

Meridian даёт три уровня видимости, каждый из которых решает свой класс задач:

Метрики (Prometheus / OpenTelemetry) — время отклика, ошибки, токены, стоимость, эффективность кэша, агрегированные по провайдеру/модели/команде. Это сигналы для алертинга и тренды для планирования.
Полные исторические логи запросов — каждый запрос/ответ с промптом, completion, метаданными VK/Team/Customer/модели/стоимости. Доступны через UI с фильтрацией и текстовым поиском, через API — для интеграции с SIEM/витриной данных.
Audit log изменений конфигурации (Enterprise) — кто и когда создал/удалил/изменил Customer, Team, VK, provider key, бюджет. Источник правды для compliance-аудитов и расследований внутренних инцидентов.

Сценарий

Инцидент 1: «Бот выдаёт неверный ответ».

Поддержка получает жалобу: пользователь u-12345 команды alpha получил некорректный ответ от ассистента в 14:23.
Разработчик открывает Logs в Meridian, ставит фильтр team=alpha, временное окно 14:20–14:25, добавляет текстовый поиск по фрагменту жалобы.
Находит конкретную запись: видит полный prompt (с RAG-контекстом), фактически выбранный provider/model, completion, стоимость, latency, использованный VK.
Воспроизводит запрос локально с тем же prompt и моделью — баг подтверждён, чинится в коде сборки контекста.

Инцидент 2: «Скачок расходов».

SRE получает алерт bifrost_governance_spend_total (метрика расхода) превысил порог.
Открывает Grafana → дашборд Cost by Team → видит, что у команды beta расход вырос в 5× за последний час.
Переходит в Logs, фильтрует team=beta, видит частые вызовы модели gpt-4o вместо ожидаемой gpt-4o-mini.
Связывается с командой; выясняется ошибочный выбор модели в новом релизе; команда временно ограничивает allowed_models в VK.

Инцидент 3: «Кто изменил бюджет?»

Финансы спрашивают, почему месячный бюджет команды alpha неожиданно увеличен на $3000.
Compliance открывает Audit log (Enterprise), фильтрует по entity_type=budget, entity_id=budget-alpha, видит запись: пользователь admin@company.com, время, старое значение, новое значение, source IP.

Конфигурация

Шаг 1. Включение полного логирования.

Откройте Config → Logging.
Включите Enable Logging (client.enable_logging: true).
Выберите backend хранилища логов: file (для разработки) или postgres (для production).

Шаг 2. Настройка Prometheus.

Откройте Observability → Metrics.
Убедитесь, что плагин Prometheus включён; эндпоинт метрик доступен на /metrics.

Шаг 3. Просмотр и фильтрация логов.

Откройте Logs.
Используйте фильтры: VK, Team, Customer, provider, model, временное окно, статус.
Кликните на запись для просмотра полного prompt и completion.

Получение логов:

# Поиск по фильтрам (последний час, конкретная команда)
curl "http://localhost:8080/api/logs?team_id=team-alpha&from=2026-05-18T13:00:00Z&to=2026-05-18T14:00:00Z"

# Конкретный запрос по ID
curl "http://localhost:8080/api/logs/{log_id}"

# Гистограмма расходов по провайдерам
curl "http://localhost:8080/api/logs/histogram/cost/by-provider?from=2026-05-01T00:00:00Z"

# Гистограмма латентности
curl "http://localhost:8080/api/logs/histogram/latency"

# Агрегированная статистика
curl "http://localhost:8080/api/logs/stats"

Prometheus-метрики:

# Сырые метрики Prometheus
curl http://localhost:8080/metrics

Ключевые семейства метрик: http_requests_total, http_request_duration_seconds, bifrost_governance_spend_total, bifrost_governance_rejections_total, метрики upstream-провайдеров с метками provider, model, status.

{
  "client": {
    "enable_logging": true
  },
  "logs_store": {
    "type": "postgres",
    "config": {
      "dsn": "env.LOGS_DB_DSN"
    }
  },
  "plugins": {
    "prometheus": {
      "enabled": true,
      "labels": ["team_id", "customer_id", "provider", "model"]
    },
    "otel": {
      "enabled": true,
      "endpoint": "env.OTEL_EXPORTER_OTLP_ENDPOINT"
    }
  },
  "audit_logs": {
    "enabled": true,
    "retention_days": 365
  }
}

Поле	Назначение
`client.enable_logging`	Сохранение полных запросов/ответов в `logs_store`
`logs_store.type`	`file` для разработки, `postgres` для production
`plugins.prometheus.labels`	Какие измерения экспонируются в метках Prometheus
`plugins.otel.endpoint`	OTLP endpoint для трейсов (Tempo, Jaeger, Datadog)
`audit_logs.enabled`	Включает аудит-журнал изменений конфигурации (Enterprise)

Audit log (audit_logs.enabled) — возможность Enterprise-редакции. Полные исторические логи запросов/ответов (client.enable_logging) и Prometheus-метрики доступны в OSS.

Связанные материалы

Телеметрия — детальный список метрик Prometheus, метки, кастомные заголовки x-bf-prom-*.
Виртуальные ключи — атрибуция запросов к VK/Team/Customer (даёт метки в логах и метриках).
Самообслуживание команд и контроль затрат — выстраивание иерархии, которая даёт осмысленные срезы в логах.
Защита от опустошения бюджета и отказа в обслуживании — алерты на превышения по метрикам governance.