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

Systemy LLM zawodują w sposób, który tradycyjne monitorowanie API nie jest w stanie wykazać — kolejki wypełniają się cicho, pamięć GPU nasyca się znacznie wcześniej, niż CPU wydaje się być obciążone, a opóźnienia rosną eksponencjalnie na poziomie warstwy batchingowej, a nie na poziomie aplikacji.

Ten przewodnik omawia kompleksową strategię obserwowalności dla wnioskowania LLM i aplikacji LLM: co mierzyć, jak instrumentować przy użyciu Prometheus, OpenTelemetry i Grafany, oraz jak wdrożyć potok telemetryczny w skali.

Pełne stosy asystentów dodają do surowego wnioskowania mechanizmy odzyskiwania danych (retrieval), wywołania narzędzi i routing; Architektura Asystentów AI wskazuje, gdzie obserwowalność wpasowuje się w te warstwy.

TL;DR (Streszczenie wykonawcze)

Systemy LLM degradują się w sposób, którego klasyczne monitorowanie „opóźnienia HTTP + wskaźnika błędów” nie potrafi wyjaśnić. Produkcyjna Obserwowalność dla systemów LLM musi szybko i w sposób mierzalny odpowiadać na pytania:

• Czy doświadczenie użytkownika się pogarsza (opóźnienie ogona, czas do pierwszego tokenu, opóźnienie między tokenami, błędy i anulowania).
• Gdzie mija czas (kolejkowanie vs batching vs wykonanie modelu; odzyskiwanie/narzędzia/filtry bezpieczeństwa vs wnioskowanie).
• Co nasyca się jako pierwsze (wykorzystanie GPU i presja na pamięć, presja na cache KV/kolejkę, tokenizacja CPU).
• Jak zmieniają się koszty i pojemność (tokeny na żądanie, tokeny/sek na GPU, wskaźnik trafień w cache, marnowane generacje).
• Czy telemetria jest bezpieczna do przechowywania (prompty mogą zawierać PII; zapobieganie wyciekom poufnych danych do logów/attributów).

Najbardziej odporną architekturą jest potok wielosygnałowy:

• Metryki do szybkiego wykrywania i planowania pojemności (Prometheus + PromQL; opcjonalne długoterminowe przechowywanie przez Thanos/Cortex/Mimir/VictoriaMetrics).
• Śledzenia (Traces) do przyczynowości na poziomie żądań (OpenTelemetry z OTLP; zaplecza takie jak Tempo/Jaeger/Zipkin/Elastic APM).
• Logi do kontekstu, skorelowane ze śledzeniami (Loki/Elastic/OpenSearch), zaprojektowane dla metadanych o niskiej kardynalności.
• Profilowanie do wykrywania gorących punktów CPU/pamięci i opóźnień ogonowych (Grafana Pyroscope).
• Testy syntetyczne i obciążeniowe do wykrywania regresji przed użytkownikami (Grafana k6; sondowanie w stylu blackbox).
• SLO do pomiaru wyników użytkownika i napędzania aktywnego alertowania (budżety błędów; styl wskaźnika zużycia).

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

Uwaga dotycząca zakresu: docelowa struktura ramowa LLM jest nieokreślona. Przykłady w tym artykule obejmują popularne serwery/ramy (Triton, vLLM, TGI, LangChain/LangSmith) i pozostają przydatne dla innych stosów poprzez podstawienie równoważnych metryk i rozpiętości (spans).

LLM wprowadzają zachowania operacyjne różniące się od konwencjonalnych usług internetowych:

• Zmienna praca na żądanie: liczby tokenów (wejście/wyjście) różnią się znacznie, więc „żądania na sekundę” mogą wyglądać stabilnie, podczas gdy przepustowość tokenów załamuje się. TGI i vLLM jawnie eksportują telemetrię związaną z tokenami i opóźnieniami tokenów, aby wspierać ten styl monitorowania.
• Kolejkowanie + ciągłe batching: przepustowość zależy od dyscyplin batching/kolejkowania; rozmiar kolejki i rozmiar batcha stają się wskaźnikami pierwszej klasy (TGI eksponuje oba).
• Strumieniowe UX: użytkownicy dbają o TTFT (czas do pierwszego tokena) i opóźnienie między tokenami co najmniej tak samo jak o całkowity czas odpowiedzi; OpenTelemetry nawet standaryzuje metryki serwera TTFT/czas na token w ramach konwencji semantycznych GenAI.
• Presja GPU dominuje tryby awarii: wykorzystanie GPU i pamięć GPU (w tym zużyta pamięć) są kluczowe dla niezawodności; eksporter DCGM firmy NVIDIA istnieje specjalnie po to, aby eksponować telemetrię GPU na końcu punktu /metrics Prometheus.
• Wielokrotne potoki: odzyskiwanie, wywołania narzędzi, filtry bezpieczeństwa i postprocessing oznaczają, że całkowite opóźnienie jest kompozycją wielu rozpiętości/kolejek – co czyni rozproszone śledzenie i staranne projektowanie metryk niezbędnymi.

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

• NVIDIA Triton Inference Server eksponuje metryki jako zwykły tekst przez /metrics (zwykle :8002/metrics) i dostarcza flagi do włączania/wyłączania metryk oraz wyboru portu metryk.
• vLLM eksponuje rozległy punkt końcowy Prometheus /metrics z prefixem vllm:; jego dokumentacja zawiera liczniki dla tokenów generacji i histogramy takie jak czas do pierwszego tokena.
• Hugging Face TGI dokumentuje punkt końcowy /metrics z rozmiarem kolejki, rozmiarem batcha, całkowitym czasem trwania żądania, wygenerowanymi tokenami i czasem trwania kolejki.

Podstawowe zadania obserwowalności i wymagana telemetria LLM

Obserwowalność dla systemów LLM jest najłatwiej wdrożyć, gdy mapujesz zadania → sygnały → narzędzia, a następnie od pierwszego dnia ograniczasz kardynalność i próbkowanie.

Metryki: Dla systemów online-serving, własne wytyczne instrumentacyjne Prometheus wyróżniają liczbę zapytań, błędy i opóźnienia jako kluczowe metryki; LLM rozszerza to o TTFT, przepustowość/opóźnienie na token, długość kolejki, rozmiar batcha i wykorzystanie GPU.

Śledzenia (Traces): Śledzenia są sposobem na przypisanie opóźnień i awarii między etapami odzyskiwania/narzędzi/bezpieczeństwa/wnioskowania; OpenTelemetry ukazuje śledzenia/exportery jako niezależne od dostawcy sposób emisji i wysyłania telemetrii do kolektorów lub zapleczy.

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

Profilowanie: Ciągłe profilowanie przechwytuje produkcyjne zachowanie CPU/pamięci z niskim narzutowym próbkowaniem; Grafana Pyroscope jest jawnie pozycjonowana do tego celu.

Testy syntetyczne i obciążeniowe: Grafana k6 to narzędzie do testowania obciążenia open-source, a Grafana zauważa, że Syntetyczne Monitorowanie jest zasilane przez k6 i wykracza poza proste kontrole protokołów.

SLO: Wytyczne SRE Google definiują SLO jako docelową wartość/zakres dla poziomu usługi mierzony przez SLI i dostarczają wytycznych dotyczących alertowania na SLO (kompromisy precyzji/przeglądu/czasu wykrywania).

Kluczowe metryki LLM – plan

Konwencje semantyczne OpenTelemetry GenAI dla standaryzacji

OpenTelemetry dostarcza konwencje semantyczne GenAI (status: „W rozwoju”) ze standardową nazewnictwem dla 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 jest praktycznym dźwignią dla przenośnych strategii „monitorowania modeli LLM z OpenTelemetry”: emituj raz i kieruj tę samą telemetrię do zapleczy OSS lub dostawczych później.

Projektowanie potoku telemetrycznego

Pull vs push

Prometheus jest najpierw pull. Procesy eksponują metryki w obsługiwanym formacie ekspozycji, a Prometheus skanuje je zgodnie z skonfigurowanymi pracami skanowania.

Push jest dla wyjątków. Przewodnik Prometheus „Kiedy użyć Pushgateway” jawnie rekomenduje Pushgateway tylko w ograniczonych przypadkach (nie jako ogólne zastąpienie push), a README Pushgateway podkreśla, że nie może „przemienić Prometheus w system monitorowania oparty na push”.

Praktyczny wzorzec specyficzny dla LLM:

• Używaj pull dla serwerów wnioskowania/eksporterów (punkty końcowe metryk Triton/vLLM/TGI; eksporter DCGM; metryki węzła).
• Używaj push OTLP dla śledzeń/logów/metryk OTel (Protokół OpenTelemetry definiuje transport/kodowanie/dostawę między źródłami, kolektorami i zapleciami).
• Używaj remote write przy skalowaniu poza pojedynczy Prometheus (Prometheus dostarcza wytyczne dotyczące strojenia remote write; Mimir/Thanos/Cortex dostarczają opcje długoterminowego i/lub HA magazynowania).

Agent vs sidecar vs gateway collectors

OpenTelemetry dokumentuje wzorzec wdrożenia agenta, gdzie telemetria jest wysyłana do Kolektora działającego obok aplikacji lub na tym samym hoście (sidecar/DaemonSet), a następnie eksportowana.

Dla Kubernetes, wstrzykiwanie sidecar jest obsługiwane przez Operatora OpenTelemetry (wstrzykiwanie oparte na adnotacjach).

Pragmatyczne reguły kciuka dla stosów LLM:

• Używaj agenta DaemonSet do wzbogacania na poziomie hosta i wspólnych potoków przez wiele podów.
• Używaj sidecar, gdy potrzebujesz ścisłej izolacji per obciążenie lub dedykowanego filtrowania lokalnego (częste, gdy prompty mogą zawierać poufne dane).
• Używaj kolektora gateway do centralnego próbkowania ogonowego (tail sampling), batchinga, ponownych prób i rozbieżności eksportu.

Próbkowanie i kontrola kardynalności

OpenTelemetry wyjaśnia, że próbkowanie ogonowe (tail sampling) pozwala na decyzje próbkowania przy użyciu kryteriów wyprowadzonych ze śledzenia (niemożliwe przy samym próbkowaniu początkowym/head sampling).

Wytyczne instrumentacyjne Prometheus ostrzegają przed nadużywaniem etykiet, dostarczają reguły kciuka, aby utrzymać niską kardynalność, i doradzają przeprojektowanie metryk, jeśli potencjalna kardynalność przekracza ~100.

„Pułapki kardynalności” specyficzne dla LLM do zakazu wczesnego:

• Tekst promptu, tekst odpowiedzi, identyfikatory rozmów, identyfikatory żądań jako etykiety/attributy.
• Bloki argumentów narzędzi jako attributy rozpiętości.
• Nieograniczone etykiety „user_id”.

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

Porównanie narzędzi obserwowalności LLM

Narzędzia zmappowane do zadań obserwowalności

Grafana vs alternatywy do wizualizacji

• Dashbory Grafany są złożone z paneli, które zapytują źródła danych (w tym Loki i Mimir), aby produkować wykresy i wizualizacje.
• Kibana dostarcza dashbory/wizualizacje jako warstwę UI w ramach Elastic Stack.
• OpenSearch Dashboards dostarcza narzędzia do wizualizacji danych dla OpenSearch.
• Dokumentacja InfluxData pozycjonuje Chronograf jako komponent wizualizacji w ekosystemie Influx.

Prometheus vs alternatywy dla zapleczy metryk

• Domyślne lokalne magazynowanie Prometheus: jeśli flagi retencji nie są ustawione, czas retencji domyślnie wynosi 15 dni (zaplanuj retencję/koszty wcześnie).
• Grafana Mimir jest opisany jako skalowalny poziomo, HA, wielodostępny długoterminowy magazyn dla metryk Prometheus i OpenTelemetry.
• Thanos jest opisany jako wysoce dostępny setup Prometheus z możliwościami długoterminowego magazynowania.
• Cortex opisuje się jako skalowalne poziomo, HA, wielodostępne rozwiązanie długoterminowego magazynowania dla metryk Prometheus i OpenTelemetry.
• VictoriaMetrics Cloud dokumentuje integrację remote write Prometheus dla długoterminowego magazynowania.
• Amazon Managed Service for Prometheus opisuje zarządzaną ofertę, która skaluje się z potrzebami ingestji/zapytań i obsługuje PromQL oraz remote write.

Praktyczny koktajl implementacji

Nazwy i typy metryk do wdrożenia dziś

Konwencje semantyczne OpenTelemetry GenAI (status: W rozwoju) 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 po stronie serwera, które możesz skanować od razu:

• Punkt końcowy Prometheus vLLM zawiera liczniki (np. całkowite tokeny generacji) i histogramy (TTFT) oraz dokumentuje strategię etykiet model_name.
• TGI dokumentuje metryki, w tym rozmiar kolejki, czas trwania żądania, wygenerowane tokeny i średni czas na token.
• Triton dokumentuje ekspozycję /metrics i przełączniki metryk.

Przykłady PromQL dla dashboardów opóźnień i przepustowości LLM

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

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

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

# Rozmiar kolejki TGI (miernik)
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)
)

Wytyczne histogramów Prometheus wyjaśniają, że kwantyle histogramów są obliczane po stronie serwera z bucketów przy użyciu histogram_quantile().

Uwagi dotyczące instrumentacji OpenTelemetry dla systemów LLM

• OTLP to Protokół OpenTelemetry określający, jak telemetria jest kodowana/transmitowana między źródłami, kolektorami i zapleciami.
• Dokumenty konfiguracji SDK OpenTelemetry dokumentują zmienne środowiskowe, takie jak OTEL_EXPORTER_OTLP_ENDPOINT (i opcje protokołu), do eksportowania telemetrii.
• OpenTelemetry Python contrib dokumentuje obsługę instrumentacji FastAPI dla automatycznej i ręcznej instrumentacji.
• Konwencje semantyczne GenAI obejmują mechanizm opcjonalnej stabilności przez OTEL_SEMCONV_STABILITY_OPT_IN dla migracji konwencji GenAI.

Krótki przykład Python: metryki + śledzenia + logi

Poniższy fragment demonstruje:

• Ekspozycję metryk Prometheus (/metrics) dla „monitorowania wnioskowania LLM z Prometheus”
• Śledzenia OpenTelemetry eksportowane przez OTLP (niezależne od dostawcy)
• Strukturalne logi skorelowane z kontekstem śledzenia, z domyślnym ustawieniem bezpiecznym dla prywatności (nie loguj surowych promptów)

import logging
import time

from fastapi import FastAPI, Request
from pydantic import BaseModel

# Prometheus (metryki oparte na pull)
from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST
from starlette.responses import Response

# OpenTelemetry (śledzenia 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)

# --- Logowanie (domyślnie bezpieczne dla prywatności) ---
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 ""

# --- Metryki Prometheus ---
LLM_REQUESTS = Counter(
    "llm_requests_total",
    "Całkowita liczba żądań LLM",
    ["route", "status_code", "model"],
)
LLM_LATENCY = Histogram(
    "llm_request_latency_seconds",
    "Całkowite opóźnienie żądania LLM (sekundy)",
    ["route", "model"],
    buckets=(0.1, 0.2, 0.35, 0.5, 0.75, 1, 1.5, 2, 3, 5, 8, 13),
)

# --- Dostawca śledzenia 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())  # konfigurowane przez zmienne środowiskowe 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:
        # 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 = "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),
                # NIE dołączaj surowego promptu/wyjścia, chyba że polityka to pozwala.
            }
        )

        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)

Wdrożenie, skalowanie, bezpieczeństwo i rozwiązywanie problemów

Opcje wdrożenia

Skalowanie i retencja: praktyczne ograniczenia

• Lokalne magazynowanie Prometheus: bez jawnych flag rozmiaru/czasu, czas retencji domyślnie wynosi 15 dni.
• Remote write Prometheus: Prometheus dokumentuje strojenie remote write do skalowania poza „zdrowe domyślne wartości”.
• Grafana Tempo: pozycjonowany jako zaplecze śledzenia wysokiej skali i może generować metryki z rozpiętości używając metrics-generator (remote write do źródła danych Prometheus).
• Magazynowanie Loki: dokumentacja Loki podkreśla indeksowanie tylko etykiet i skompresowane magazynowanie fragmentów (magazyn obiektowy), czyniąc strategię etykiet centralną dla skali i kosztu.

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

Wytyczne bezpieczeństwa OpenTelemetry podkreślają, że zbieranie telemetrii może przypadkowo przechwytywać poufne/osobiste informacje; jesteś odpowiedzialny za ich odpowiednie obsłużenie.

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

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

• Domyślnie nie loguj surowych promptów/odpowiedzi; loguj liczby tokenów, nazwę modelu, opóźnienie i identyfikatory śledzenia.
• Cenzuruj/upuszczaj poufne atrybuty w kolektorach/potokach (filtrowanie na poziomie kolektora to powszechny podejście w ekosystemach).
• Wymuszaj RBAC i polityki retencji dla logów/śledzeń; rozważ skanery poufnych danych, gdzie stosowne (np. dostawcy dokumentują skanery dla telemetrii).

Lista kontrolowana rozwiązywania problemów

Jeśli Twój dashboard Grafana dla opóźnień LLM wygląda źle, debuguj w tej kolejności:

• Stan zdrowia ingestji
  • Prometheus: zweryfikuj sukces skanowania i semantykę konfiguracji (konfiguracja Prometheus definiuje prace/instancje skanowania).
  • OTLP: potwierdź konfigurację punktu końcowego eksportera (SDK używa OTEL_EXPORTER_OTLP_ENDPOINT, ustawień protokołu).
• Niespójność schematu
  • Dashboard oczekuje model, ale Twój serwer emituje model_name (vLLM jawnie dokumentuje etykiety model_name).
• Wybuch kardynalności
  • Ktoś oznaczył etykietami identyfikatory żądań/hashe promptów; Prometheus ostrzega, że zbiory etykiet zwiększają koszty RAM/CPU/dysku/sieci i dostarcza wytyczne dotyczące kardynalności.
• Nadużycie histogramów
  • Upewnij się, że obliczasz kwantyle z serii _bucket przy użyciu rate() i le; Prometheus wyjaśnia kompromisy obliczania kwantyli histogramów.
• Luki w próbkowaniu śledzeń
  • Jeśli próbkujesz początkowo (head-sampling) zbyt agresywnie, rzadkie wolne/błędne śledzenia znikają; próbkowanie ogonowe (tail sampling) zachowuje „ważne” śledzenia na podstawie pełnych kryteriów śledzenia.
• Problemy z metrykami rozpiętości Tempo
  • Jeśli używasz metrics-generator Tempo i span-metrics, potwierdź, że są włączone i dostrojone (Tempo dokumentuje procesory metrics-generator i span-metrics; istnieją rozwiązania problemów dla generatora).
• Brak metryk GPU
  • Potwierdź, że eksporter DCGM jest wdrożony i /metrics jest dostępny (eksporter DCGM eksponuje metryki GPU przez HTTP dla Prometheus).

Przydatne linki

• Polling Agents in AI Assistants: 11 Implementation Patterns — sekcja listy kontrolowanej obserwowalności pokrywa dokładnie, które metryki agentów tła, pola logów i widoki admina instrumentować dla systemów pollingowych produkcyjnych
• Observability: Monitoring, Metrics, Prometheus & Grafana Guide
• A2A vs MCP: Do AI Agents Really Need Both Protocols? — sekcje obserwowalności i bezpieczeństwa tam pokrywają, co śledzić w systemach wieloagentowych łączących oba protokoły
• Multi-Agent Orchestration Patterns — sekcja obserwowalności pokrywa wymagania dotyczące rozproszonego śledzenia specyficzne dla każdego wzorca: odtwarzanie blackboard dla swarm, atrybucję kosztów per agent i monitorowanie konwergencji dla mesh
• Google A2A Protocol in 2026: Adoption, Hype, and Reality — sekcje bezpieczeństwa i typowych błędów pokrywają dokładnie, jaką obserwowalność potrzebujesz przy wdrażaniu agentów przez granice A2A
• What Is the A2A Protocol? Agent Cards and Tasks Explained — sekcja obserwowalności wyjaśnia, co musi przechwytywać śledzenie zadania międzyagentowego: zmiany stanu zadania, łańcuchy delegowania, artefakty i wiadomości międzyagentowe
• Prometheus Monitoring: Setup & Best Practices
• LLM Performance: Benchmarks, Bottlenecks & Optimization
• LLM Hosting: Local, Self-Hosted & Cloud Infrastructure Compared
• RAG Step-by-Step Tutorial
• Dokumentacja konfiguracji Prometheus
• Formaty ekspozycji Prometheus
• Najlepsze praktyki instrumentacji Prometheus
• Nazewnictwo metryk Prometheus
• Histogramy i sumary Prometheus
• Reguły alertujące Prometheus
• Przegląd alertowania Prometheus
• Konfiguracja Alertmanager
• Model JSON dashboardów Grafana
• Provisioning Grafana
• Metryki serwera wnioskowania NVIDIA Triton
• API metryk TorchServe
• Eksporter NVIDIA DCGM
• Wykres Helm kube-prometheus-stack
• Zaczynanie z Operatorem Prometheus
• Specyfikacja eksportera Prometheus OpenTelemetry
• Przewodnik Prometheus dla odbierania OTLP
• Śledzenie LangSmith z OpenTelemetry