Obserwowalność systemów LLM: metryki, śledzenia, logi i testy w środowisku produkcyjnym

Systemy LLM zawodzą w sposób, który klasyczne monitorowanie API nie potrafi wykryć — kolejki wypełniają się cicho, pamięć GPU osiąga maksymalny poziom dłużej niż CPU wygląda na zajęte, a opóźnienia rosną na warstwie partii, a nie na warstwie aplikacji. Niniejszy przewodnik pokrывает kompleksową strategię obserwowalności dla wnioskowania LLM i aplikacji LLM: co mierzyć, jak je zainstalować za pomocą Prometheus, OpenTelemetry i Grafana, oraz jak wdrożyć pipeline telemetryczny w dużej skali.

TL;DR (Streszczenie dla menedżerów)

Systemy LLM degradują w sposób, który klasyczne monitorowanie „opóźnienia HTTP + stawki błędów” nie potrafi wytłumaczyć. Obserwowalność produkcyjna Obserwowalność dla systemów LLM musi szybko i uzasadnione odpowiedzieć na pytania:

• Czy doświadczenie użytkownika się pogarsza (ogon opóźnienia, czas do pierwszego tokena, opóźnienie między tokenami, błędy i przerwania).
• Gdzie jest zużywany czas (oczekiwanie na kolejce vs partycjonowanie vs wykonywanie modelu; odzyskiwanie danych/narzędzia/filtry bezpieczeństwa vs wnioskowanie).
• Co pierwsze się wyczerpuje (zużycie GPU i presja pamięci, presja KV-cache/kolejki, tokenizacja CPU).
• Jak zmienia się koszt i pojemność (liczba tokenów na żądanie, tokenów na sekundę na GPU, stopa trafienia do cache, bezużyteczne generacje).
• Czy telemetryczne dane są bezpieczne do przechowywania (prompty mogą zawierać dane osobowe; zapobiegaj wyciekowi wrażliwych danych do logów/attributów).

Najbardziej odpornym projektem jest pipeline wielu sygnałów:

• Metryki do szybkiego wykrywania i planowania pojemności (Prometheus + PromQL; opcjonalne długoterminowe przechowywanie za pomocą Thanos/Cortex/Mimir/VictoriaMetrics).
• Śledzenie do przypisywania opóźnień i błędów na poziomie żądania (OpenTelemetry z OTLP; backendy takie jak Tempo/Jaeger/Zipkin/Elastic APM).
• Logi do kontekstu, skorelowane z śledzeniem (Loki/Elastic/OpenSearch), zaprojektowane do niskiej kardynalności metadanych.
• Profiling do lokalizacji problemów CPU/pamięci i ogonu opóźnienia (Grafana Pyroscope).
• Testy syntetyczne + obciążeniowe do wykrywania regresji przed użytkownikami (Grafana k6; testy typu blackbox).
• SLOs do mierzenia wyników użytkownika i wywoływania alertów (budżet błędów; styl wygarańcji).

Co sprawia, że obserwowalność systemów LLM jest inna

Uwaga dotycząca zakresu: docelowy framework LLM nie jest określony. Przykłady w tym artykule obejmują typowe serwery/frameworki (Triton, vLLM, TGI, LangChain/LangSmith) i nadal są stosowalne do innych stosów poprzez zastąpienie odpowiednich metryk i spanów.

LLM wprowadzają zachowania operacyjne, które różnią się od konwencjonalnych usług sieciowych:

• Zmienne obciążenie na żądanie: liczba tokenów (wejście/wyjście) znacznie się różni, więc „liczba żądań na sekundę” może wyglądać stabilnie, podczas gdy przepustowość tokenów kryje się. TGI i vLLM eksplikatnie eksportują telemetryczne dane dotyczące tokenów i opóźnienia tokenów, aby wspierać ten styl monitorowania.
• Kolejkowanie + ciągłe partycjonowanie: przepustowość zależy od zasad partycjonowania/kolejkowania; rozmiar kolejki i rozmiar partii stają się pierwszorzędowymi wskaźnikami (TGI eksponuje oba).
• Streaming UX: użytkownicy dbają o TTFT i opóźnienie między tokenami przynajmniej tak samo jak o pełny czas odpowiedzi; OpenTelemetry nawet standardyzuje metryki TTFT/czas na token serwera pod konwencjami GenAI.
• Presja GPU dominuje w trybach awarii: wykorzystanie GPU i pamięć GPU (w tym zużycie pamięci) są centralne dla niezawodności; eksporter NVIDIA DCGM istnieje specjalnie, aby eksponować telemetryczne dane GPU na końcu punktu końcowego /metrics Prometheus.
• Wieloetapowe pipeline: odzyskiwanie danych, wywołania narzędzi, filtry bezpieczeństwa i przetwarzanie poza przetwarzaniem oznaczają, że całkowite opóźnienie jest kompozycją wielu spanów/kolejek — co sprawia, że śledzenie rozproszone i staranny projekt metryk są niezbędne.

Konkretne przykłady z popularnych serwerów wnioskowania podkreślają to:

• NVIDIA Triton Inference Server eksponuje metryki jako tekst prosty przez /metrics (zwykle :8002/metrics) i dostarcza flagi do włączania/wyłączania metryk i wyboru portu metryk.
• vLLM eksponuje rozbudowany punkt końcowy /metrics Prometheus z prefiksem vllm:; jego dokumentacja zawiera liczniki tokenów generowanych i histogramy takie jak czas do pierwszego tokena.
• Hugging Face TGI dokumentuje punkt końcowy /metrics z rozmiarem kolejki, rozmiarem partii, czasem trwania żądania end-to-end, wygenerowanymi tokenami i czasem kolejki.

Podstawowe zadania obserwowalności i wymagane telemetryczne dane LLM

Obserwowalność systemów LLM jest najłatwiej do wdrożenia, gdy mapujesz zadania → sygnały → narzędzia, a następnie ograniczysz kardynalność i próbkowanie od samego początku.

Metryki: Dla systemów online, własne wskazówki dotyczące instrumentacji Prometheus podkreślają liczbę zapytań, błędy i opóźnienie jako kluczowe metryki; LLM rozszerzają to o TTFT, przepustowość/latencję na token, długość kolejki, rozmiar partii i wykorzystanie GPU.

Śledzenie: Śledzenie to sposób, w jaki przypisujesz opóźnienia i błędy na etapach odzyskiwania danych/narzędzi/filtra bezpieczeństwa/wnioskowania; OpenTelemetry prezentuje śledzenie/exportery jako neutralny względem dostawcy sposób na emitowanie i wysyłanie telemetrycznych danych do kolektorów lub backendów.

Logi: Logi dostarczają czytelny dla człowieka kontekst i „dlaczego”, ale tylko pozostają użyteczne w dużej skali, jeśli unikasz indeksowania wartości nieograniczonych (przykład: Loki indeksuje tylko etykiety i przechowuje skompresowane fragmenty logów w magazynie obiektów).

Profiling: Profiling ciągły przechwytuje zachowanie CPU/pamięci w środowisku produkcyjnym z niskim nakładem próbkowania; Grafana Pyroscope jest wyraźnie pozycjonowana do tego.

Testy syntetyczne i obciążeniowe: Grafana k6 to otwarty narzędzie do testowania obciążenia, a Grafana zauważa, że Monitoring Syntetyczny jest napędzany przez k6 i rozciąga się poza proste sprawdzanie protokołów.

SLOs: Wskazówki Google SRE definiują SLO jako docelowy wartość/ zakres dla poziomu usługi zmierzonego przez SLI i dostarczają wskazówki dotyczące alertowania na SLO (wzajemne kompromisy precyzji/odzyskiwania/detekcji czasu).

Podstawowy plan kluczowych metryk LLM

Konwencje semantyczne GenAI OpenTelemetry dla standaryzacji

OpenTelemetry dostarcza konwencje semantyczne GenAI (status: „Development”) z standaryzowaną nazwą metryk GenAI takich jak:

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

Ta standaryzacja to praktyczny mechanizm do portowalnych strategii „monitorowanie modeli LLM za pomocą OpenTelemetry”: emituj raz i kieruj te same telemetryczne dane do źródeł OSS lub dostawców później.

Projektowanie pipeline telemetrycznego

Pull vs push

Prometheus to pull-first. Procesy eksponują metryki w obsługiwanej formie eksponowania, a Prometheus skanuje je zgodnie z skonfigurowanymi zadaniami skanowania.

Push to dla wyjątków. „Kiedy używać Pushgateway” w przewodniku Prometheus wyraźnie zaleca Pushgateway tylko w ograniczonych przypadkach (nie jako ogólne zastąpienie pusha), a README Pushgateway podkreśla, że nie może „zamienić Prometheus na system monitorowania oparty na push”.

Praktyczny wzorzec dla stosów LLM:

• Użyj pull dla serwerów wnioskowania/exporterów (punkty końcowe metryk Triton/vLLM/TGI; eksporter DCGM; metryki node).
• Użyj OTLP push dla śledzenia/logów/OTel metryk (protokół OpenTelemetry definiuje transport/encode/transport między źródłami, kolektorami i backendami).
• Użyj remote write przy skalowaniu poza pojedynczym Prometheus (Prometheus dostarcza wskazówki do dostosowania remote write; Mimir/Thanos/Cortex dostarczają opcje długoterminowego przechowywania i/lub HA).

Agent vs sidecar vs gateway kolektorów

OpenTelemetry dokumentuje wzorzec wdrożenia agenta, gdzie telemetryczne dane są wysyłane do kolektora działającego obok aplikacji lub na tym samym hoście (sidecar/DaemonSet), a następnie eksportowane.

Dla Kubernetes, wstrzykiwanie sidecar jest wspierane przez Operatora OpenTelemetry (wstrzykiwanie oparte na adnotacjach).

Praktyczna zasada dla stosów LLM:

• Użyj DaemonSet agenta dla wzbogacania poziomu hosta i udostępniania wspólnych pipeline dla wielu podów.
• Użyj sidecar gdy potrzebujesz ściślego izolowania obciążenia na poziomie pracy lub lokalnego filtrowania (często, gdy prompty mogą zawierać wrażliwe dane).
• Użyj gateway kolektora do centralnego ogonowego próbkowania, partycjonowania, ponownych prób i eksportu.

Próbkowanie i kontrola kardynalności

OpenTelemetry wyjaśnia, że ogonowe próbkowanie umożliwia decyzje o próbkowaniu na podstawie kryteriów pochodzących z śledzenia (nie jest to możliwe tylko z próbkowaniem głowicy).

Wskazówki dotyczące instrumentacji Prometheus ostrzegają przed nadmiernym użyciem etykiet, dostarczają zasady, aby utrzymać niską kardynalność, i radzą przeprojektować metryki, jeśli potencjalna kardynalność przekracza ok. 100.

„Pułapki kardynalności” specyficzne dla LLM, które należy zbanować wczesnie:

• Tekst promptu, tekst odpowiedzi, identyfikatory rozmów, identyfikatory żądań jako etykiety/attributy.
• Bloki argumentów narzędzi jako atrybuty spanów.
• Nieograniczone „identyfikatory użytkownika” jako etykiety.

Preferuj ograniczone wymiary: model, model_family, endpoint, region, status_code, deployment, tenant (tylko jeśli ograniczone).

Porównanie narzędzi obserwowalności LLM

Narzędzia odwzorowane na zadania obserwowalności

Grafana vs alternatywy dla wizualizacji

• Paneli Grafana składają się z paneli, które zapytują źródła danych (w tym Loki i Mimir), aby wygenerować wykresy i wizualizacje.
• Kibana dostarcza panele/wizualizacje jako warstwę interfejsu użytkownika w ramach Stacku Elastic.
• OpenSearch Dashboards dostarcza narzędzi do wizualizacji danych dla OpenSearch.
• Dokumentacja InfluxData pozycjonuje Chronograf jako komponent wizualizacji w ramach ekosystemu Influx.

Prometheus vs alternatywy dla backendów metryk

• Domyślne lokalne przechowywanie Prometheus: jeśli flagi przechowywania nie są ustawione, domyślnie przechowywanie wynosi 15d (planuj przechowywanie/koszt wczesnie).
• Grafana Mimir opisuje się jako skalowalna poziomie poziomie, HA, wielodostępne długoterminowe przechowywanie metryk dla Prometheus i OpenTelemetry.
• Thanos opisuje się jako bardzo dostępna konfiguracja Prometheus z możliwością długoterminowego przechowywania.
• Cortex opisuje się jako skalowalna poziomie poziomie, HA, wielodostępne długoterminowe przechowywanie metryk dla Prometheus i OpenTelemetry.
• VictoriaMetrics Cloud dokumentuje integrację zdalnego zapisu Prometheus dla długoterminowego przechowywania.
• Amazon Managed Service for Prometheus opisuje się jako zarządzana oferta, która skaluje się z potrzebami wdrażania/zapytań i obsługuje PromQL i zdalny zapis.

Praktyczny kuchenny przewodnik

Nazwy metryk i typy do wdrożenia dzisiaj

Konwencje semantyczne GenAI OpenTelemetry (status: Development) definiują nazwy metryk, które możesz natychmiast standaryzować:

• 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

Przykłady serwerowe, które możesz natychmiast wykryć:

• Punkty końcowe Prometheus vLLM zawierają liczniki (np. całkowita liczba tokenów generowanych) i histogramy (TTFT) i dokumentują strategię etykiet model_name.
• TGI dokumentuje metryki, w tym rozmiar kolejki, czas trwania żądania, wygenerowane tokeny i średni czas na token.
• Triton dokumentuje wykrywanie /metrics i przełączniki metryk.

Przykłady PromQL dla paneli opóźnienia i przepustowości LLM

# p95 opóźnienie end-to-end dla histogramu aplikacji
histogram_quantile(
  0.95,
  sum(rate(llm_request_latency_seconds_bucket[5m])) by (le, model)
)

# Procentowy współczynnik błędów (5xx)
100 *
(
  sum(rate(llm_requests_total{status_code=~"5.."}[5m]))
  /
  sum(rate(llm_requests_total[5m]))
)

# Tokeny/sec (wyjście) dla wszystkich modeli
sum(rate(llm_tokens_total{direction="out"}[5m]))

# Rozmiar kolejki TGI (wskazówka)
max(tgi_queue_size) by (instance)

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

Wskazówki dotyczące histogramów w Prometheus wyjaśniają, że kwantyle histogramu są obliczane serwerowo z bucketów przy użyciu histogram_quantile().

Uwagi dotyczące instrumentacji OpenTelemetry dla systemów LLM

• OTLP to Protokół OpenTelemetry, który definiuje, jak telemetryczne dane są kodowane/przesyłane między źródłami, kolektorami a backendami.
• Dokumentacja konfiguracji SDK OpenTelemetry zawiera zmienne środowiskowe takie jak OTEL_EXPORTER_OTLP_ENDPOINT (i opcje protokołu) do eksportowania telemetrycznych danych.
• Dokumentacja Python contrib OpenTelemetry zawiera wsparcie dla instrumentacji FastAPI, zarówno automatycznej, jak i ręcznej.
• Konwencje semantyczne GenAI zawierają mechanizm stabilności opcjonalnej poprzez OTEL_SEMCONV_STABILITY_OPT_IN dla migracji konwencji GenAI.

Krótki przykład Pythona: metryki + śledzenie + logi

Poniższy fragment demonstruje:

• Eksponowanie metryk Prometheus (/metrics) dla „monitorowania wnioskowania LLM za pomocą Prometheus”
• Śledzenie eksportowane przez OTLP (neutralne względem dostawcy)
• Strukturalne logi skorelowane z kontekstem śledzenia, z domyślnym bezpieczeństwem prywatności (nie loguj surowych promptów)

import logging
import time

from fastapi import FastAPI, Request
from pydantic import BaseModel

# Prometheus (pull-based metrics)
from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST
from starlette.responses import Response

# OpenTelemetry (OTLP traces)
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)

# --- Logging (privacy-safe default) ---
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 metrics ---
LLM_REQUESTS = Counter(
    "llm_requests_total",
    "LLM requests total",
    ["route", "status_code", "model"],
)
LLM_LATENCY = Histogram(
    "llm_request_latency_seconds",
    "End-to-end LLM request latency (seconds)",
    ["route", "model"],
    buckets=(0.1, 0.2, 0.35, 0.5, 0.75, 1, 1.5, 2, 3, 5, 8, 13),
)

# --- OpenTelemetry tracer provider ---
resource = Resource.create({"service.name": "llm-inference-api"})
trace.set_tracer_provider(TracerProvider(resource=resource))
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter())  # konfiguracja przez OTEL_EXPORTER_OTLP_* zmienne środowiskowe
)
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:
        # Unikaj logowania pełnego promptu; emituj bezpieczne metadane
        span.set_attribute("gen_ai.request.model", req.model)
        span.set_attribute("gen_ai.request.max_tokens", req.max_tokens)

        # Zastąp rzeczywistym wywołaniem LLM (klient Triton/vLLM/TGI)
        time.sleep(0.15)
        output = "Witaj od modelu."

        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),
                # Nie dodawaj surowego promptu/wyjścia, chyba że polityka tego dozwala.
            }
        )

        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)

Wdrażanie, skalowanie, bezpieczeństwo i rozwiązywanie problemów

Opcje wdrażania

Skalowanie i przechowywanie: praktyczne ograniczenia

• Lokalne przechowywanie Prometheus: bez jawnych flag rozmiaru/czasu, domyślny czas przechowywania wynosi 15d.
• Zdalny zapis Prometheus: dokumentacja Prometheus opisuje dostosowanie zapisu zdalnego do skalowania poza „sensownymi domyślnymi wartościami”.
• Grafana Tempo: pozycjonowane jako backend śledzenia w dużej skali i może generować metryki z spanów za pomocą generatora metryk (zapisy zdalne do źródła danych Prometheus).
• Przechowywanie Loki: dokumentacja Loki podkreśla indeksowanie tylko etykiet i przechowywanie skompresowanych fragmentów (magazyn obiektów), co sprawia, że strategia etykiet jest centralna dla skalowania i kosztu.

Bezpieczeństwo i prywatność: prompty mogą zawierać dane osobowe

Wskazówki dotyczące bezpieczeństwa OpenTelemetry podkreślają, że zbieranie telemetrycznych danych może przypadkowo przechwycić wrażliwe / osobowe informacje; jesteś odpowiedzialny za ich odpowiednie obsłużenie.

Model bezpieczeństwa Prometheus ostrzega, że punkty końcowe Prometheus nie powinny być dostępne w sieciach publicznie dostępnych (np. internet) ponieważ dostarczają informacje o monitorowanych systemach.

Operacyjne kontrole prywatności, które utrzymują „obserwowalność systemów LLM” bezpieczne:

• Domyślnie nie loguj surowe prompty/odpowiedzi; zamiast tego loguj liczbę tokenów, nazwę modelu, opóźnienie i identyfikatory śledzenia.
• Usuń / usuń wrażliwe atrybuty w kolektorach/pipeline (filtracja na poziomie kolektora jest powszechnym podejściem w ekosystemach).
• Wymuszaj RBAC i polityki przechowywania dla logów/śledzeń; rozważ skanery danych wrażliwych, gdzie to odpowiednie (np. dostawcy dokumentują skanery dla telemetrycznych danych).

Lista kontrolna do rozwiązywania problemów

Jeśli Twój panel Grafana do opóźnień LLM wygląda niepoprawnie, debuguj w tej kolejności:

• Zdrowie wdrażania
  • Prometheus: zweryfikuj sukces skanowania i semantykę konfiguracji (konfiguracja Prometheus definiuje zadania skanowania/instancje).
  • OTLP: potwierdź konfigurację punktu końcowego eksporter (SDK używają OTEL_EXPORTER_OTLP_ENDPOINT, ustawienia protokołu).
• Niezgodność schematu
  • Panel oczekuje model, ale Twój serwer eksponuje model_name (vLLM jawnie dokumentuje etykiety model_name).
• Eksplozja kardynalności
  • Ktoś etykietował przez identyfikatory żądań/hashe promptów; Prometheus ostrzega, że zwiększenie zestawów etykiet zwiększa koszty RAM/CPU/dysku/sieci i dostarcza wskazówki dotyczące kardynalności.
• Nieprawidłowe użycie histogramów
  • Upewnij się, że obliczasz kwantyle z serii _bucket z rate() i le; Prometheus wyjaśnia kompromisy w obliczaniu kwantyli histogramów.
• Luki w próbkowaniu śledzenia
  • Jeśli zbyt agresywnie próbkujesz głowicę, rzadkie wolne / błędne śledzenia znikają; próbkowanie ogona zachowuje „ważne” śledzenia na podstawie pełnych kryteriów śledzenia.
• Problemy z metrykami w Tempo
  • Jeśli korzystasz z generatora metryk i metryk span w Tempo, potwierdź, że jest włączony i dostosowany (Tempo dokumentuje generator metryk i procesory metryk span; istnieje pomoc przy problemach z generatorem).
• Brak metryk GPU
  • Potwierdź, że eksporter DCGM został wdrożony i /metrics jest dostępny (eksporter DCGM eksponuje metryki GPU przez HTTP dla Prometheus).

Przydatne linki

• Obserwowalność: Monitorowanie, metryki, przewodnik Prometheus & Grafana
• Monitorowanie Prometheus: Konfiguracja & najlepsze praktyki
• Wydajność LLM: Testy, wąskie gardła i optymalizacja
• Hosting LLM: Porównanie lokalnego, samodzielnie hostowanego i chmurowego infrastruktury
• Krok po kroku tutorial RAG
• Dokumentacja konfiguracji Prometheus
• Formaty eksponowania Prometheus
• Najlepsze praktyki instrumentacji Prometheus
• Nazewnictwo metryk Prometheus
• Histogramy i sumy w Prometheus
• Reguły alertów w Prometheus
• Przegląd alertów w Prometheus
• Konfiguracja Alertmanager
• Model JSON paneli Grafana
• Wdrażanie Grafana
• Metryki serwera wnioskowania NVIDIA Triton
• API metryk TorchServe
• Eksporter DCGM NVIDIA
• Helm chart kube-prometheus-stack
• Dokumentacja wstępna Prometheus Operator
• Specyfikacja eksporter prometheus OpenTelemetry
• Przewodnik Prometheus dla odbioru OTLP
• Śledzenie w LangSmith z OpenTelemetry