Наблюдаемость систем LLM: метрики, трассировки, журналы и тестирование в production

Системы LLM (больших языковых моделей) выходят из строя способами, которые невозможно выявить с помощью традиционного мониторинга API: очереди заполняются незаметно, память GPU насыщается задолго до того, как CPU начинает выглядеть загруженным, а задержки растут на уровне пакетной обработки, а не на уровне приложения.

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

Полные стеки ассистентов добавляют извлечение данных, вызовы инструментов и маршрутизацию поверх сырого инференса; Архитектура AI-ассистентов показывает, куда встраивается наблюдаемость среди этих слоев.

TL;DR (Исполнительное резюме)

Системы LLM деградируют способами, которые классический мониторинг «HTTP-латентность + уровень ошибок» не может объяснить. Системы Наблюдаемости для LLM производственного уровня должны быстро и обоснованно отвечать на следующие вопросы:

• Ухудшается ли пользовательский опыт (хвостовая латентность, время до первого токена, латентность между токенами, ошибки и прерывания).
• Где тратится время (очерwaiting vs пакетная обработка vs выполнение модели; извлечение/инструменты/фильтры безопасности vs инференс).
• Что насыщается первым (утилизация GPU и давление на память, давление на KV-кэш/очередь, токенизация CPU).
• Как дрейфуют затраты и емкость (токены на запрос, токены/сек на GPU, частота попаданий в кэш, потраченные впустую генерации).
• Безопасно ли хранить телеметрию (промпты могут содержать PII; предотвращение утечки конфиденциальных данных в логи/атрибуты).

Наиболее устойчивая архитектура — это конвейер с множественными сигналами:

• Метрики для быстрого обнаружения и планирования емкости (Prometheus + PromQL; опциональное долгосрочное хранение через Thanos/Cortex/Mimir/VictoriaMetrics).
• Трассы для причинно-следственных связей на уровне запросов (OpenTelemetry с OTLP; бэкенды, такие как Tempo/Jaeger/Zipkin/Elastic APM).
• Логи для контекста, коррелированные с трассами (Loki/Elastic/OpenSearch), разработанные для метаданных с низкой кардинальностью.
• Профилирование для выявления узких мест CPU/памяти и хвостовой латентности (Grafana Pyroscope).
• Синтетические и нагрузочные тесты для обнаружения регрессий до того, как это заметят пользователи (Grafana k6; зондирование в стиле blackbox).
• SLO для измерения результатов для пользователей и обеспечения действующих алертов (бюджеты ошибок; стиль burn-rate).

Чем отличается наблюдаемость для систем LLM

Примечание по области применения: целевая фреймворк LLM в данном руководстве не указан. Примеры в этой статье охватывают распространенные серверы/фреймворки (Triton, vLLM, TGI, LangChain/LangSmith) и остаются применимыми к другим стекам путем замены эквивалентными метриками и спанами.

LLM вводят операционные поведения, отличающиеся от обычных веб-сервисов:

• Переменная нагрузка на запрос: количество токенов (вход/выход) сильно варьируется, поэтому «запросы в секунду» могут выглядеть стабильными, в то время как пропускная способность токенов обваливается. TGI и vLLM явно экспортируют телеметрию, связанную с токенами и латентностью токенов, для поддержки такого стиля мониторинга.
• Очереди и непрерывная пакетная обработка: пропускная способность зависит от дисциплин пакетирования/очередей; размер очереди и размер пакета становятся индикаторами первого класса (TGI экспонирует оба).
• Потоковый UX: пользователей заботит TTFT (время до первого токена) и латентность между токенами не меньше, чем полное время ответа; OpenTelemetry даже стандартизирует метрики сервера TTFT/время-на-токен в рамках семантических соглашений GenAI.
• Давление на GPU доминирует в режимах отказа: утилизация GPU и память GPU (включая используемую память) являются центральными для надежности; экспортер NVIDIA DCGM существует специально для экспозиции телеметрии GPU в эндпоинт Prometheus /metrics.
• Многоэтапные конвейеры: извлечение, вызовы инструментов, фильтры безопасности и постобработка означают, что сквозная латентность является композицией нескольких спанов/очередей, что делает распределенную трассировку и тщательный дизайн метрикessential.

Конкретные примеры из популярных серверов инференса подчеркивают это:

• NVIDIA Triton Inference Server экспонирует метрики как обычный текст через /metrics (обычно :8002/metrics) и предоставляет флаги для включения/отключения метрик и выбора порта метрик.
• vLLM экспонирует обширный эндпоинт Prometheus /metrics с префиксом vllm:; его документация включает счетчики для сгенерированных токенов и гистограммы, такие как время до первого токена.
• Hugging Face TGI документирует эндпоинт /metrics с размером очереди, размером пакета, продолжительностью сквозного запроса, сгенерированными токенами и продолжительностью ожидания в очереди.

Основные задачи наблюдаемости и необходимая телеметрия LLM

Наблюдаемость для систем LLM реализуется проще всего, когда вы маппите задачи → сигналы → инструменты, а затем ограничиваете кардинальность и сэмплирование с первого дня.

Метрики: Для систем онлайн-сервиса руководство по инструментации самого Prometheus выделяет количество запросов, ошибки и латентность как ключевые метрики; LLM расширяют это TTFT, пропускной способностью/латентностью на токен, длиной очереди, размером пакета и утилизацией GPU.

Трассы: Трассы — это способ атрибутировать латентность и сбои на этапах извлечения/инструментов/безопасности/инференса; OpenTelemetry рассматривает трассы/экспортеры как независимый от вендора способ эмиссии и отправки телеметрии в коллекторы или бэкенды.

Логи: Логи предоставляют человеко-читаемый контекст и «почему», но остаются usable в масштабе только если вы избегаете индексирования неограниченных значений (пример: Loki индексирует только лейблы и хранит сжатые чанки логов в объектном хранилище).

Профилирование: Непрерывное профилирование захватывает производственное поведение CPU/памяти с низким накладным сэмплированием; Grafana Pyroscope явно позиционируется для этого.

Синтетические тесты и нагрузочные тесты: Grafana k6 — это инструмент нагрузочного тестирования с открытым исходным кодом, и Grafana отмечает, что Синтетический Мониторинг работает на базе k6 и выходит за рамки простых проверок протоколов.

SLO: Руководство Google по SRE определяет SLO как целевое значение/диапазон для уровня сервиса, измеряемого SLI, и предоставляет руководство по алертингу на SLO (компромиссы точность/полнота/время обнаружения).

Ключевые метрики LLM: чертеж

Семантические соглашения OpenTelemetry GenAI для стандартизации

OpenTelemetry предоставляет семантические соглашения GenAI (статус: «Разработка») со стандартным наименованием для метрик GenAI, таких как:

• gen_ai.client.token.usage и gen_ai.client.operation.duration
• gen_ai.server.request.duration, gen_ai.server.time_per_output_token и gen_ai.server.time_to_first_token

Эта стандартизация является практическим рычагом для портативных стратегий «мониторинга моделей LLM с OpenTelemetry»: эмиссия один раз и маршрутизация той же телеметрии в OSS или бэкенды вендоров позже.

Проектирование конвейера телеметрии

Pull vs push

Prometheus — это pull-first. Процессы экспонируют метрики в поддерживаемом формате экспозиции, и Prometheus скрейпит их в соответствии с настроенными задачами скрейпинга.

Push — для исключений. Руководство Prometheus «Когда использовать Pushgateway» явно рекомендует Pushgateway только в ограниченных случаях (не как общую замену push), и README Pushgateway подчеркивает, что он не может «превратить Prometheus в систему мониторинга на основе push».

Практический паттерн для LLM:

• Используйте pull для серверов инференса/экспортеров (эндпоинты метрик Triton/vLLM/TGI; экспортер DCGM; метрики узлов).
• Используйте OTLP push для трасс/логов/метрик OTel (Протокол OpenTelemetry определяет транспорт/кодирование/доставку между источниками, коллекторами и бэкендами).
• Используйте remote write при масштабировании за пределы одного Prometheus (Prometheus предоставляет руководство по настройке remote write; Mimir/Thanos/Cortex предоставляют опции долгосрочного и/или HA хранения).

Агент vs sidecar vs gateway-коллекторы

OpenTelemetry документирует паттерн развертывания агента, где телеметрия отправляется в Коллектор, работающий рядом с приложением или на том же хосте (sidecar/DaemonSet), а затем экспортируется.

Для Kubernetes инъекция sidecar поддерживается через OpenTelemetry Operator (инъекция на основе аннотаций).

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

• Используйте агент DaemonSet для обогащения на уровне хоста и общих конвейеров для многих подов.
• Используйте sidecar, когда вам нужна строгая изоляция на уровне рабочей нагрузки или локальная фильтрация (часто, когда промпты могут содержать конфиденциальные данные).
• Используйте gateway-коллектор для централизованного хвостового сэмплирования, пакетной обработки, повторных попыток и экспорта fan-out.

Сэмплирование и контроль кардинальности

OpenTelemetry уточняет, что хвостовое сэмплирование позволяет принимать решения о сэмплировании, используя критерии, полученные из трассы (невозможно только с головным сэмплированием).

Руководство по инструментации Prometheus предупреждает против чрезмерного использования лейблов, предоставляет правило большого пальца для сохранения низкой кардинальности и советует перепроектировать метрики, если потенциальная кардинальность превышает ~100.

«Ловушки кардинальности» для LLM, которые нужно запретить заранее:

• Текст промпта, текст ответа, идентификаторы разговора, идентификаторы запросов как лейблы/атрибуты.
• Блобы аргументов инструментов как атрибуты спана.
• Неограниченные лейблы «user_id».

Предпочитайте ограниченные измерения: model, model_family, endpoint, region, status_code, deployment, tenant (только если ограничено).

Сравнение инструментов наблюдаемости LLM

Инструменты, маппированные к задачам наблюдаемости

Grafana vs альтернативы для визуализации

• Дашборды Grafana состоят из панелей, которые запрашивают источники данных (включая Loki и Mimir) для создания графиков и визуализаций.
• Kibana предоставляет дашборды/визуализации как UI-слой внутри Elastic Stack.
• OpenSearch Dashboards предоставляет инструменты визуализации данных для OpenSearch.
• Документация InfluxData позиционирует Chronograf как компонент визуализации внутри экосистемы Influx.

Prometheus vs альтернативы для бэкендов метрик

• Локальное хранилище Prometheus по умолчанию: если флаги удержания не установлены, время удержания по умолчанию составляет 15d.
• Remote write Prometheus: Prometheus документирует настройку remote write для масштабирования за пределы «разумных значений по умолчанию».
• Grafana Tempo: позиционируется как бэкенд трассировки высокой масштабируемости и может генерировать метрики из спанов, используя metrics-generator (remote write в источник данных Prometheus).
• Хранилище Loki: документация Loki подчеркивает индексирование только лейблов и хранение сжатых чанков (объектное хранилище), делая стратегию лейблов центральной для масштаба и стоимости.

Практический кулинарный рецепт реализации

Имена и типы метрик для внедрения сегодня

Семантические соглашения OpenTelemetry GenAI (статус: Разработка) определяют имена метрик, на которые вы можете стандартизироваться немедленно:

• gen_ai.client.token.usage
• gen_ai.client.operation.duration
• gen_ai.server.request.duration
• gen_ai.server.time_per_output_token
• gen_ai.server.time_to_first_token

Примеры серверной стороны, которые можно скрейпить прямо сейчас:

• Эндпоинт Prometheus vLLM включает счетчики (например, общее количество сгенерированных токенов) и гистограммы (TTFT) и документирует стратегию лейбла model_name.
• TGI документирует метрики, включая размер очереди, продолжительность запроса, сгенерированные токены и среднее время на токен.
• Triton документирует экспозицию /metrics и переключатели метрик.

Примеры PromQL для дашбордов латентности и пропускной способности LLM

# p95 сквозной латентности для гистограммы приложения
histogram_quantile(
  0.95,
  sum(rate(llm_request_latency_seconds_bucket[5m])) by (le, model)
)

# Процент ошибок (5xx)
100 *
(
  sum(rate(llm_requests_total{status_code=~"5.."}[5m]))
  /
  sum(rate(llm_requests_total[5m]))
)

# Токены/сек (выход) по всем моделям
sum(rate(llm_tokens_total{direction="out"}[5m]))

# Размер очереди TGI (gauge)
max(tgi_queue_size) by (instance)

# vLLM TTFT p95
histogram_quantile(
  0.95,
  sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le, model_name)
)

Руководство Prometheus по гистограммам объясняет, что квантили гистограммы вычисляются на стороне сервера из бакетов с использованием histogram_quantile().

Примечания по инструментации OpenTelemetry для систем LLM

• OTLP — это Протокол OpenTelemetry, специфицирующий, как телеметрия кодируется/передается между источниками, коллекторами и бэкендами.
• Документация по конфигурации SDK OpenTelemetry документирует переменные среды, такие как OTEL_EXPORTER_OTLP_ENDPOINT (и варианты протокола) для экспорта телеметрии.
• OpenTelemetry Python contrib документирует поддержку инструментации FastAPI для автоматической и ручной инструментации.
• Семантические соглашения GenAI включают механизм опциональной стабильности через OTEL_SEMCONV_STABILITY_OPT_IN для миграции соглашений GenAI.

Короткий пример на Python: метрики + трассы + логи

Ниже приведенный фрагмент демонстрирует:

• Экспозицию метрик Prometheus (/metrics) для «мониторинга инференса LLM с Prometheus»
• Трассы OpenTelemetry, экспортируемые через OTLP (независимо от вендора)
• Структурированные логи, коррелированные с контекстом трассы, с безопасным по умолчанию для конфиденциальности (не логировать сырые промпты)

import logging
import time

from fastapi import FastAPI, Request
from pydantic import BaseModel

# Prometheus (метрики на основе pull)
from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST
from starlette.responses import Response

# OpenTelemetry (трассы OTLP)
from opentelemetry import trace
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter

app = FastAPI(title="LLM Inference API", version="1.0.0")
FastAPIInstrumentor.instrument_app(app)

# --- Логирование (безопасное по умолчанию) ---
logger = logging.getLogger("llm")
logging.basicConfig(level=logging.INFO, format="%(message)s")

def trace_id_hex() -> str:
    span = trace.get_current_span()
    ctx = span.get_span_context()
    return format(ctx.trace_id, "032x") if ctx.is_valid else ""

# --- Метрики Prometheus ---
LLM_REQUESTS = Counter(
    "llm_requests_total",
    "Общее количество запросов LLM",
    ["route", "status_code", "model"],
)
LLM_LATENCY = Histogram(
    "llm_request_latency_seconds",
    "Сквозная латентность запроса LLM (секунды)",
    ["route", "model"],
    buckets=(0.1, 0.2, 0.35, 0.5, 0.75, 1, 1.5, 2, 3, 5, 8, 13),
)

# --- Провайдер трассировки OpenTelemetry ---
resource = Resource.create({"service.name": "llm-inference-api"})
trace.set_tracer_provider(TracerProvider(resource=resource))
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter())  # настраивается через переменные среды OTEL_EXPORTER_OTLP_*
)
tracer = trace.get_tracer(__name__)

class GenerateRequest(BaseModel):
    prompt: str
    model: str = "unspecified"
    max_tokens: int = 256

class GenerateResponse(BaseModel):
    model: str
    output: str
    latency_ms: int

@app.post("/v1/generate", response_model=GenerateResponse)
async def generate(req: GenerateRequest, request: Request):
    route = "/v1/generate"
    start = time.perf_counter()

    with tracer.start_as_current_span("llm.generate") as span:
        # Избегайте логирования полного промпта; эмиссия безопасных метаданных
        span.set_attribute("gen_ai.request.model", req.model)
        span.set_attribute("gen_ai.request.max_tokens", req.max_tokens)

        # Замените на фактический вызов LLM (клиент Triton/vLLM/TGI)
        time.sleep(0.15)
        output = "Hello from the model."

        latency_s = time.perf_counter() - start
        LLM_LATENCY.labels(route=route, model=req.model).observe(latency_s)
        LLM_REQUESTS.labels(route=route, status_code="200", model=req.model).inc()

        logger.info(
            {
                "msg": "llm_request_complete",
                "trace_id": trace_id_hex(),
                "model": req.model,
                "latency_ms": int(latency_s * 1000),
                # НЕ включайте сырой промпт/вывод, если политика не разрешает.
            }
        )

        return GenerateResponse(model=req.model, output=output, latency_ms=int(latency_s * 1000))

@app.get("/metrics")
def metrics():
    return Response(generate_latest(), media_type=CONTENT_TYPE_LATEST)

Развертывание, масштабирование, безопасность и устранение неполадок

Варианты развертывания

Масштабирование и удержание: практические ограничения

• Локальное хранилище Prometheus: без явных флагов размера/времени, время удержания по умолчанию составляет 15d.
• Remote write Prometheus: Prometheus документирует настройку remote write для масштабирования за пределы «разумных значений по умолчанию».
• Grafana Tempo: позиционируется как бэкенд трассировки высокой масштабируемости и может генерировать метрики из спанов, используя metrics-generator (remote write в источник данных Prometheus).
• Хранилище Loki: документация Loki подчеркивает индексирование только лейблов и хранение сжатых чанков (объектное хранилище), делая стратегию лейблов центральной для масштаба и стоимости.

Безопасность и конфиденциальность: промпты могут содержать PII

Руководство OpenTelemetry по безопасности подчеркивает, что сбор телеметрии может непреднамеренно захватить конфиденциальную/персональную информацию; вы несете ответственность за ее надлежащую обработку.

Модель безопасности Prometheus предупреждает, что эндпоинты Prometheus не должны быть экспонированы в общедоступные сети (например, интернет), поскольку они обслуживают информацию о наблюдаемых системах.

Операционные контролы конфиденциальности, которые сохраняют «наблюдаемость для систем LLM» безопасной:

• По умолчанию не логировать сырые промпты/ответы; логировать количество токенов, имя модели, латентность и идентификаторы трассы вместо этого.
• Удалять/отбрасывать конфиденциальные атрибуты в коллекторах/конвейерах (фильтрация на уровне коллектора является распространенным подходом в экосистемах).
• Применять RBAC и политики удержания для логов/трасс; рассмотреть сканеры конфиденциальных данных там, где это уместно (например, вендоры документируют сканеры для телеметрии).

Чек-лист по устранению неполадок

Если ваш дашборд Grafana для латентности LLM выглядит неправильно, отлаживайте в этом порядке:

• Здоровье ingestion
  • Prometheus: валидируйте успех скрейпинга и семантику конфигурации (конфигурация Prometheus определяет задачи/инстансы скрейпинга).
  • OTLP: подтвердите конфигурацию эндпоинта экспортера (SDK используют OTEL_EXPORTER_OTLP_ENDPOINT, настройки протокола).
• Несоответствие схемы
  • Дашборд ожидает model, но ваш сервер экспонирует model_name (vLLM явно документирует лейблы model_name).
• Взрыв кардинальности
  • Кто-то пометил лейблами идентификаторы запросов/хэши промптов; Prometheus предупреждает, что наборы лейблов увеличивают затраты RAM/CPU/диска/сети и предоставляет руководство по кардинальности.
• Неправильное использование гистограмм
  • Убедитесь, что вы вычисляете квантили из серий _bucket с помощью rate() и le; Prometheus объясняет компромиссы вычисления квантилей гистограмм.
• Пропуски сэмплирования трасс
  • Если вы слишком агрессивно головно сэмплируете, редкие медленные/ошибочные трассы исчезают; хвостовое сэмплирование сохраняет «важные» трассы на основе критериев полной трассы.
• Проблемы метрик спанов Tempo
  • Если вы используете metrics-generator Tempo и span-metrics, подтвердите, что он включен и настроен (Tempo документирует процессоры metrics-generator и span-metrics; существуют руководства по устранению неполадок генератора).
• Отсутствие метрик GPU
  • Подтвердите, что экспортер DCGM развернут и /metrics доступен (экспортер DCGM экспонирует метрики GPU через HTTP для Prometheus).

Полезные ссылки

• Агенты опроса в AI-ассистентах: 11 паттернов реализации — раздел чек-листа наблюдаемости охватывает именно те метрики фонового агента, поля логов и административные представления, которые нужно инструментировать для систем опроса производственного уровня
• Наблюдаемость: Мониторинг, Метрики, Prometheus & Руководство по Grafana
• A2A vs MCP: Действительно ли AI-агентам нужны оба протокола? — разделы наблюдаемости и безопасности там охватывают, что трассировать в системах с множественными агентами, сочетающими оба протокола
• Паттерны оркестрации множественных агентов — раздел наблюдаемости охватывает требования распределенной трассировки, специфичные для каждого паттерна: воспроизведение черной доски для роя, атрибуция затрат на агента и мониторинг сходимости для сетки
• Протокол Google A2A в 2026 году: Принятие, Гипс и Реальность — разделы безопасности и распространенных ошибок охватывают именно ту наблюдаемость, которая вам нужна при развертывании агентов за границами A2A
• Что такое протокол A2A? Объяснение Agent Cards и Задач — раздел наблюдаемости объясняет, что должна захватывать трасса кросс-агентской задачи: изменения состояния задачи, цепочки делегирования, артефакты и сообщения между агентами
• Мониторинг Prometheus: Установка & Лучшие Практики
• Производительность LLM: Бенчмарки, Узкие Места & Оптимизация
• Хостинг LLM: Локальный, Самодостаточный & Облачная Инфраструктура Сравнены
• Пошаговое Руководство по RAG
• Документация конфигурации Prometheus
• Форматы экспозиции Prometheus
• Лучшие практики инструментации Prometheus
• Наименование метрик Prometheus
• Гистограммы и сводки Prometheus
• Правила алертинга Prometheus
• Обзор алертинга Prometheus
• Конфигурация Alertmanager
• JSON-модель дашборда Grafana
• Проビジонирование Grafana
• Метрики сервера инференса NVIDIA Triton
• API метрик TorchServe
• Экспортер NVIDIA DCGM
• Helm-чарт kube-prometheus-stack
• Начало работы с Prometheus Operator
• Спецификация экспортера Prometheus OpenTelemetry
• Руководство Prometheus для приема OTLP
• Трассировка LangSmith с OpenTelemetry