---
title: "Observability pre AI agentov: tracing, metriky, logy a evals"
description: "AI Agent Observability zviditeľňuje vnútorné fungovanie autonómneho agenta: prostredníctvom tracingu (spany cez reasoning- a tool-cally), metrík (latencia, tokeny, náklady, miera úspešnosti), štruktúrovaných logov a kontinuálnych evals. Odpovedá na otázku, prečo sa agent takto rozhodol, a je predpokladom toho, aby sa multi-step agenti v produkcii vôbec dali debugovať, zabezpečiť a auditovať."
locale: "sk"
canonical: "https://blckalpaca.at/sk/vedomosti/ai-agenti/budovanie-infrastruktury-ai-agentov/observability-stack-fuer-agents"
category: "AI agenti"
topic: "Budovanie infraštruktúry AI Agentov"
updated: "2026-07-29T08:52:49.236Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# Observability pre AI agentov: tracing, metriky, logy a evals

AI Agent Observability zviditeľňuje vnútorné fungovanie autonómneho agenta: prostredníctvom tracingu (spany cez reasoning- a tool-cally), metrík (latencia, tokeny, náklady, miera úspešnosti), štruktúrovaných logov a kontinuálnych evals. Odpovedá na otázku, prečo sa agent takto rozhodol, a je predpokladom toho, aby sa multi-step agenti v produkcii vôbec dali debugovať, zabezpečiť a auditovať.

## Klucove body

- Observability pre agentov stojí na štyroch pilieroch: tracing, metriky, logy a evals. Bez tracingu cez reasoning- a tool-call-spany sú multi-step agenti fakticky nedebugovateľní.
- Trace agenta je hierarchický: jeden root-span na požiadavku, pod ním vnorené spany pre každé volanie LLM, tool-call, retrieval-krok a guardrail, s promptom, odpoveďou, počtom tokenov, latenciou a nákladmi na každý span.
- Krajina nástrojov (stav 2026): LangSmith (blízky k LangChain/LangGraph), Langfuse (open source, self-hostovateľný v EU), Arize Phoenix, ako aj výrobcovsky neutrálna cesta cez OpenTelemetry-GenAI-konvencie a OpenInference.
- Pre DACH-B2B je dátová rezidencia observability-backendu samostatnou compliance-témou: Langfuse self-hosted v EU, Datadog EU alebo Honeycomb EU udržiavajú prompty a odpovede v priestore EU.
- Evals patria do observability: miera úspešnosti, korektnosť tool-callov a kvalita odpovedí sa taguje voči fixovaným verziám modelov a promptov, povinnosť pre vysokorizikové audity relevantné z hľadiska AI Act.
- Tracing je aj bezpečnostný signál: poskytuje audit-log pre vysoký blast radius agenta a dopĺňa egress-kontrolu a hygienu service-accountov z bezpečnostného piliera.

[AI Agent](/sk/slovnik/ai-agent) Observability sprístupňuje vnútorné fungovanie autonómneho agenta: prostredníctvom tracingu (spany cez reasoning a [volania nástrojov](/sk/vedomosti/ai-agenti/co-su-ai-agenti/zaklady-tool-callingu)), metrík (latencia, tokeny, náklady, miera úspešnosti), štruktúrovaných logov a kontinuálnych evalov. Odpovedá na otázku, prečo [agent](/sk/slovnik/agent) rozhodol tak, ako rozhodol, a je predpokladom na to, aby bolo možné multi-step agentov v produkcii vůbec debugovať, zabezpečiť a auditovať.

Na rozdiel od klasickej webovej služby agent nevykoná jedno rozhodnutie typu požiadavka-odpoveď, ale prechádza pri každej úlohe viacerými [reasoning kolami](/sk/vedomosti/ai-agenti/co-su-ai-agenti/reasoning-a-planning-agentov) s medzizaradenými volaniami nástrojov. Práve táto viacstupňovosť robí konvenčný monitoring slepým: HTTP-200 nevypovedá nič o tom, či bol zavolaný správny nástroj so správnymi argumentmi alebo či model odbočil nesprávnym smerom v polovici cesty.

**Tri kľúčové body vopred:**

- **Observability pre agentov pozostáva zo štyroch pilierov**tracing, metriky, logy a evaly. Navzájom sa dopĺňajú: trace poskytuje cestu, metriky poskytujú agregáciu, logy poskytujú kontext, evaly poskytujú hodnotenie kvality.
- **Bez tracingu sú agenti ne-debugovateľní.** Len hierarchický trace cez všetky reasoning a tool-call spany ukazuje, v ktorom kroku sa viacstupňový reťazec zlomil.
- **Dátová rezidencia je povinné kritérium.** Keďže trace obsahujú prompty a odpovede, teda potenciálne zákaznícke dáta, je observability backend pre DACH-B2B sám compliance objektom (Langfuse self-hosted v EÚ, Datadog EU, Honeycomb EU).

## Prečo sú agenti bez tracingu ne-debugovateľní

Agent je nedeterministický. Tá istá požiadavka môže viesť k rôznym volaniam nástrojov, rôznemu počtu reasoning kôl a rôznym výsledkom. Ak beh zlyhá alebo vyprodukuje odborne nesprávnu odpoveď, bez [tracingu neexistuje spoľahlivý spôsob](/sk/vedomosti/ai-agenti/bezpecnost-ai-agentov-owasp/ai-agent-monitoring-langsmith-langfuse), ako izolovať príčinu. Možné zdroje chýb v jednej požiadavke:

- [LLM](/sk/slovnik/llm) nesprávne reasonoval a zvolil nevhodný nástroj.
- Nástroj bol zavolaný s chybnými argumentmi.
- Retrieval krok ([RAG](/sk/slovnik/rag)) stiahol nesprávne dokumenty.
- Guardrail alebo PII filter zasiahol a zmenil kontext.
- Verzia modelu sa zmenila na strane servera (managed [API](/sk/slovnik/api) aktualizujú modely podľa harmonogramu poskytovateľa).

Plochý output log tieto prípady nerozlišuje. Tracing robí každý z týchto krokov viditeľným ako vlastný, časovo a kauzálne zaradený **span** . Tým sa debugging posúva z „hádania na základe konečného výsledku" na „nájdenie konkrétneho spanu, ktorý je zlomený". Research dossier zakotvuje tento pohľad aj architektonicky: service meshe poskytujú observability na sieťovej úrovni a agentské stacky z mnohých microservices (orchestrator, tool server, memory store, vector DB, retrieval service, guardrail service) sú zvládnuteľné len s prierezovou observability vrstvou.

## Štyri piliere agentskej observability

### Tracing, spany cez reasoning a tool-cally

Trace zobrazuje kompletnú agentskú požiadavku ako strom. **Root span** zahŕňa celú požiadavku; pod ním visia vnorené spany pre každé LLM volanie, každý tool-call, každý retrieval krok a každú guardrail kontrolu. Každý span nesie vstupy a výstupy ako aj atribúty ako názov modelu, [prompt](/sk/slovnik/prompt) a completion tokeny, latenciu a, odvodené, náklady. Táto hierarchická štruktúra je rozhodujúci rozdiel oproti klasickému, plochému request logu.

### Metriky, latencia, tokeny, náklady, miera úspešnosti

Metriky agregujú cez mnoho trace. Štyri signály tvoria jadro:

- **Latencia**, end-to-end a na tool-call kolo. Relevantné, pretože podľa dossier agent vo Frankfurte, ktorý volá US-východ API, buduje na smer približne 80–130 ms navyše, pri viacerých tool kolách sa to násobí.
- **Tokeny** (prompt a completion) na span ako základ nákladovej atribúcie.
- **Náklady** na požiadavku, tím a use-case.
- **Miera úspešnosti**podiel správne dokončených úloh.

### Logy, štruktúrovaný kontext

Štruktúrované logy dopĺňajú spany o detailný kontext: surové odpovede nástrojov, retry pokusy, guardrail spustenia, orezané kontexty. Dôležitá je korelácia: každý log záznam by mal byť cez trace ID priraďovateľný ku konkrétnemu spanu, inak opäť vzniká slepá škvrna.

### Evaly, kvalita ako súčasť observability

Evaly sú signál, ktorý čistý tracing neposkytuje: systematické hodnotenie kvality výstupu. Hodnotí sa typicky miera úspešnosti, správnosť tool-callu (bol zavolaný správny nástroj so správnymi argumentmi?) a kvalita odpovede, pomocou heuristiky, referenčného datasetu alebo „LLM-as-a-Judge". Rozhodujúce pre regulované kontexty: evaly a verzie promptov sú tagované voči **fixným verziám modelov** . Dossier uvádza tento vzor explicitne, verzie promptov a evaly sú v gateway resp. observability stacku označené voči konkrétnym verziám modelov, okrem iného na prípravu [AI-Act vysokorizikových auditov](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai).

## Matica signál-nástroj

Nasledujúca tabuľka priradí každý observability signál jeho meranej veličine a typickému nástroju (nástroje uvedené z research dossier; stav 2026).

| Signál | Čo merať | Nástroj (príklady) |
| --- | --- | --- |
| Tracing | Span strom cez reasoning a tool-call kroky; prompt/odpoveď, vnorenie, trvanie na span | LangSmith, Langfuse, Arize Phoenix; výrobcovo neutrálne cez OpenTelemetry-GenAI konvencie / OpenInference |
| Latencia | End-to-end a na tool-call kolo; tail latencia | Langfuse, LangSmith, Datadog EU / Honeycomb EU |
| Tokeny | Prompt a completion tokeny na span | Langfuse, LangSmith ([token](/sk/slovnik/token)-level nákladová atribúcia) |
| Náklady | Náklady na požiadavku, tím, use-case | Langfuse, LangSmith; agregácia často v [AI](/sk/slovnik/ai)-Gateway (LiteLLM, Portkey) |
| Miera úspešnosti / kvalita | Eval skóre, správnosť tool-callu, kvalita odpovede voči fixnej verzii modelu | Eval harness v Langfuse / Arize Phoenix / LangSmith |
| Logy | Surové odpovede nástrojov, retry, guardrail zásahy, orezané kontexty | Štruktúrované logy, korelované cez trace ID |
| Guardrails / PII | spustené filtre, redaction eventy | AI-Gateway (Portkey, LiteLLM) plus trace anotácia |

## LLM observability stack: prehľad nástrojov

Research dossier uvádza pre observability vrstvu jasný výber (stav 2026):

- **LangSmith**tracing a eval platforma z prostredia [LangChain](/sk/slovnik/langchain)/LangGraph, ako managed služba. Silná, ak agent aj tak stojí na tomto frameworku; ako managed možnosť v dossier uvedená v jednom rade s Datadog a Honeycomb.
- **Langfuse**open source a tým **self-hostovateľný v EÚ** (vlastné dátové centrum alebo EÚ región). V dossier uvedený ako pre regulovanú sovereign architektúru (zákazníkom kontrolovaná observability) tak aj pre lean-cloud-startup vzor („Langfuse self-hosted") ako [GDPR](/sk/slovnik/gdpr) konformná cesta.
- **Arize Phoenix**open-source observability a evaluácia, v dossier uvedený ako self-hostovateľná alternatíva vedľa Langfuse.
- **OpenTelemetry pre LLM / OpenInference**výrobcovo neutrálny trace štandard. Cez GenAI sémantické konvencie inštrumentovaný, backend zostáva vymeniteľný, dôležitý argument proti lock-inu. Hugging Faces TGI napríklad exportovalo už OpenTelemetry a Prometheus, predtým ako v decembri 2025 prešlo do maintenance módu.
- **Datadog EU / Honeycomb EU**zavedené APM backendy s možnosťou EÚ dátovej rezidencie, v dossier uvedené ako managed cesty pre DACH rezidenciu.

Dôležitý architektonický bod: **AI-Gateway** (LiteLLM, Portkey, Kong) je často už nositeľom častí observability. Gateways preberajú podľa dossier multi-provider failover, virtuálny key management, tímové rozpočty, observability, guardrails a PII redaction. V praxi gateway atribuuje tokeny a náklady, zatiaľ čo tracing platforma drží reasoning cestu a evaly, oboje spolu dáva kompletný obraz.

## Príklad trace: jeden agentský beh, rozčlenený

Nasledujúci pseudo-príklad ukazuje, ako vyzerá jeden support agentský beh ako span strom. Čísla sú ilustratívne; veľkosť latencie pre transatlantické volania (80–130 ms/smer) pochádza z dossier.

\`\`\`
TRACE  id=ag-7f3c  "Zákaznícka požiadavka: stornovať faktúru"   celkom: 4.210 ms | 3.320 tokenov | 0,041 USD
├─ SPAN  llm.reason         model=[gpt](/sk/slovnik/gpt)-4.x   620 ms | in 540 / out 80 tok   "Plán: vyhľadať zákazníka+faktúru"
├─ SPAN  tool.[crm](/sk/slovnik/crm)\_lookup    mTLS, in-VPC    180 ms | status=200            args={kunde\_id:8842}
├─ SPAN  retrieval.vector   qdrant-eu       95 ms  | 4 zásahy             query="Stornovacie pravidlá B2B"
├─ SPAN  llm.reason         model=gpt-4.x   710 ms | in 1.980 / out 130 tok "Storno prípustné, zavolať nástroj"
├─ SPAN  tool.invoice\_void  in-VPC          240 ms | status=200            args={rechnung:RE-2026-0317}
├─ SPAN  guardrail.pii      redaction        40 ms | 0 zásahov
└─ SPAN  llm.compose        model=gpt-4.x   2.325 ms| in 380 / out 210 tok  Text odpovede zákazníkovi
EVAL   tool\_call\_correct=PASS | answer\_quality=0,92 | tagované: model=gpt-4.x, prompt=v7
\`\`\`

Čo tento trace poskytuje, čo output log nemôže: keby stornovanie zlyhalo, strom okamžite ukáže, či `tool.invoice_void` vrátil chybový status, či `retrieval.vector` stiahol nesprávne pravidlá alebo či druhý `llm.reason`span rozhodol nesprávne. Najväčšia latencia (`llm.compose`, 2.325 ms) je okamžite rozpoznateľná ako kandidát na optimalizáciu. A eval riadok viaže hodnotenie kvality na verziu modelu a promptu, základ pre rollback a audit.

## Vzťah k monitoringu v bezpečnostnom pilieri

Tracing nie je len debugging, ale aj **bezpečnostný signál**. Agenti majú nezvyčajne vysoký „blast radius": kompromitovaný agent môže volať mnoho nástrojov. Prierezový trace poskytuje presne ten audit log, ktorý robí túto útočnú plochu sledovateľnou, ktorý agent kedy zavolal ktorý nástroj s akou identitou. To dopĺňa kontroly z bezpečnostného a identitného kontextu: deny-by-default egress s allowlistom a logovaním na gateway, service account na pár agent-nástroj namiesto zdieľaných účtov ako aj spätnú väzbu každého volania na identitu používateľa cez token-exchange reťazec. Observability na sieťovej úrovni cez service mesh (mTLS, workload identity, traffic shaping) uzatvára kruh. Podrobné meracie a kontrolné vzory k egressu, identite a monitoringu rieši bezpečnostný pilier; observability vrstva poskytuje pre to telemetrickú bázu. Konkrétna token ekonómia a nákladové modelovanie je zase predmetom FinOps piliera.

## Pre agentúry a B2B rozhodovateľov

Pre **marketingové agentúry**, ktoré budujú agentské workflow pre zákazníkov, je observability dodávateľský objekt, ktorý oddeľuje pilot od auditovateľného produkčného systému: až trace, eval a EÚ konformný backend robia agenta prevádzkovateľným, účtovateľným a obhájiteľným voči zákazníckej ochrane údajov. Pre **DACH-B2B rozhodovateľov** platí: vyberte observability backend rovnako vedome ako cloud región, self-hosted Langfuse, Datadog EU alebo Honeycomb EU držia prompty a odpovede v EÚ priestore a výrobcovo neutrálny OpenTelemetry tracing chráni pred lock-inom. [Blck Alpaca](/sk) z Viedne koncipuje a prevádzkuje [agentskú infraštruktúru s touto observability vrstvou](/sk/sluzby/integracia-ai-agenta) od začiatku, vrátane tracingu, eval harness a [GDPR](/sk/slovnik/gdpr-2) konformného backendu. Oslovte nás, ak chcete agenta previesť z pilotného stavu do auditovateľnej produkčnej prevádzky.

## FAQ

### Aký je rozdiel medzi observability pre AI agentov a klasickým APM?

Klasický Application Performance Monitoring meria requesty, miery chýb a latenciu na úrovni služby. AI Agent Observability ide hlbšie: na každú požiadavku zaznamenáva celú reasoning-cestu ako trace, každé volanie LLM, každý tool-call, každý retrieval-krok, vrátane promptu, odpovede, spotreby tokenov a nákladov na každý span. Navyše prostredníctvom evals hodnotí kvalitu výstupu, nie len jeho technickú dostupnosť. Agent môže technicky bežať bezchybne (HTTP 200) a napriek tomu urobiť nesprávne rozhodnutie, presne túto medzeru observability agentov uzatvára.
### Prečo sú AI agenti bez tracingu nedebugovateľní?

Agent je nedeterministický a viacstupňový: po jednej požiadavke často nasleduje viacero reasoning-kôl s medzitým vsunutými tool-callmi. Ak konečný výsledok zlyhá, samotný output-log nepovie, či LLM reasonoval nesprávne, či tool dodal chybnú odpoveď, či retrieval-krok vytiahol nesprávne dokumenty alebo či zasiahol guardrail. Tracing zviditeľňuje každý z týchto stupňov ako vlastný span so vstupmi a výstupmi. Až tým sa dá izolovať konkrétny krok, na ktorom sa reťazec prelomil.
### Ktoré observability-nástroje sú vhodné pre DACH-podniky s požiadavkami na dátovú rezidenciu?

Podľa research-dosiera prichádzajú pre GDPR-konformné setupy do úvahy predovšetkým Langfuse self-hosted (open source, prevádzkovateľný v EU-regióne alebo vo vlastnom dátovom centre), Datadog EU a Honeycomb EU. Managed-možnosti ako LangSmith alebo Datadog sú komfortnejšie, musia sa však preveriť voči dátovej rezidencii promptov a odpovedí, keďže trace môže obsahovať zákaznícke dáta. Výrobcovsky neutrálne sa dá inštrumentovať cez OpenTelemetry-GenAI-konvencie, takže backend zostáva vymeniteľný (stav 2026).
### Patria evaluácie (evals) do observability alebo sú to oddelené disciplíny?

V kontexte agentov sa obe zlievajú. Evals, teda systematické hodnotenie miery úspešnosti, korektnosti tool-callov a kvality odpovedí, sú kvalitatívny signál, ktorý čistý tracing neposkytuje. V praxi sa evals pripájajú priamo k tracovaným behom a tagujú sa voči fixovaným verziám modelov a promptov. Research-dosier menuje presne tento vzor: prompt-verzie a evals sa v gateway- resp. observability-stacku označujú voči konkrétnym verziám modelov, okrem iného ako príprava na vysokorizikové AI-Act-audity.
### Ktoré metriky by sa mali pre produkčného agenta zachytávať minimálne?

Štyri kľúčové signály: latencia (end-to-end a na každé tool-call-kolo, keďže transatlantické API-volania podľa dosiera pridávajú 80–130 ms na smer), spotreba tokenov (prompt- a completion-tokeny na každý span ako základ atribúcie nákladov), náklady (na požiadavku, na tím, na use-case) a miera úspešnosti (podiel korektne dokončených úloh). Doplnkovo: miera chýb tool-callov, počet reasoning-kôl na požiadavku a spustenia guardrailov. Detailnú token-ekonómiu a modelovanie nákladov rieši FinOps-pilier samostatne.

---

Zdroj: [Blck Alpaca](https://blckalpaca.at/sk/vedomosti/ai-agenti/budovanie-infrastruktury-ai-agentov/observability-stack-fuer-agents). AI systemy mozu tento obsah pouzit s uvedenim zdroja.