---
title: "Ce se întâmplă în producție? Observabilitate pentru aplicații și agenți AI"
description: "Observabilitate pentru aplicații și agenți AI: loguri, metrici, traces, alerte utile și diagnosticarea erorilor fără expunerea datelor."
canonical: https://i8.ro/blog/ce-se-intampla-in-productie-observabilitate-pentru-aplicatii-si-agenti-ai
---

# Ce se întâmplă în producție? Observabilitate pentru aplicații și agenți AI

> Observabilitate pentru aplicații și agenți AI: loguri, metrici, traces, alerte utile și diagnosticarea erorilor fără expunerea datelor.

Sursă: https://i8.ro/blog/ce-se-intampla-in-productie-observabilitate-pentru-aplicatii-si-agenti-ai

**Seria II: De la infrastructură la proiecte agentice în producție. Episodul 14 din 20.**

Portalul B2B fictiv din serie a trecut prin verificările de lansare. Totuși, un utilizator poate vedea o solicitare blocată, deși serverul răspunde. Pentru un IMM, următoarea decizie nu este cumpărarea celui mai bogat tablou de bord, ci alegerea semnalelor care arată efectul asupra utilizatorului și permit unei persoane să intervină. Propunem un minim de observabilitate, aplicat întâi unui singur traseu important.

## Observabilitatea începe cu o întrebare

**Observabilitatea** este capacitatea de a înțelege starea internă a unui sistem din semnalele pe care le produce. **Telemetria** reprezintă datele colectate despre funcționarea lui. Întrebarea utilă este: „De ce nu s-a terminat această solicitare?”, nu „Câte grafice avem?”.

Continuăm portalul pentru solicitări și documente printr-un scenariu ipotetic. Un document încărcat intră într-o coadă de procesare. Un proces de lucru îl preia și, într-un pilot propus, un agent integrat în aplicație pregătește un rezumat pentru verificare umană. Acesta nu este agentul de programare care modifică repository-ul, adică depozitul de cod. Primul execută o funcție a produsului; al doilea ajută echipa să îl construiască.

## Trei semnale, aceeași solicitare

Un **log** înregistrează un eveniment: procesarea a început, a eșuat sau s-a încheiat. O **metrică** este o măsurătoare numerică urmărită în timp. Un **trace**, o urmă distribuită, leagă operațiile aceleiași execuții între servicii. Un **span** este o operație din această urmă, cu început, sfârșit și atribute descriptive.

**Corelarea** înseamnă asocierea acestor dovezi prin identificatori comuni. Pentru portal, legăm primirea cererii, publicarea mesajului în coadă, prelucrarea și apelurile către model sau alte servicii. Contextul trebuie transmis și prin mesajele asincrone, procesate ulterior; altfel, traseul pare întrerupt. Identificatorul de trasare nu înlocuiește verificarea drepturilor de acces.

Lucrarea tehnică Dapper, publicată de Google în 2010, este un reper pentru urmărirea operațiilor distribuite. Nu dovedește performanța portalului nostru. Lecția practică este că timpii unor servicii izolate nu explică întotdeauna așteptarea întregului proces.

## OpenTelemetry nu este întregul sistem

**OpenTelemetry** oferă instrumente și convenții pentru producerea, colectarea și exportarea telemetriei. Nu reprezintă, singur, soluția de stocare, căutare și alertare. Alegem separat unde ajung datele, cine le accesează și cât costă păstrarea lor.

**Instrumentarea** este adăugarea mecanismelor care emit semnale. Începem cu serviciul web și procesul care preia documentele, apoi adăugăm etapele relevante pentru utilizator. Înregistrăm versiunea aplicației și mediul, pentru a compara comportamentul înainte și după lansarea controlată din episodul anterior.

La verificarea din 15 octombrie 2026, convențiile OpenTelemetry pentru AI generativ din repository-ul dedicat sunt marcate „Development”. Nu tratăm toate denumirile și câmpurile ca interfețe definitive. Fixăm versiunile bibliotecilor de instrumentare și testăm compatibilitatea după actualizare. Dacă o integrare nu furnizează o măsurătoare, o afișăm ca indisponibilă, nu ca zero.

## Tabloul de bord minim al portalului

Propunerea de pornire combină rezultatul procesului cu explicațiile tehnice. Un răspuns web reușit poate confirma doar acceptarea documentului, nu terminarea prelucrării.

| Întrebarea echipei | Semnalul propus |
| --- | --- |
| Utilizatorul primește rezultatul? | Solicitări finalizate, eșuate și încă în așteptare |
| Unde se pierde timpul? | Durata totală, durata etapelor și vechimea celui mai vechi mesaj |
| Ce face componenta AI? | Durata apelurilor, erori, reîncercări și consum disponibil de tokenuri |
| Putem avea încredere în vizibilitate? | Resurse ocupate, erori de export și lipsa neașteptată a telemetriei |

Un **token** este o unitate de text procesată de model; consumul raportat nu este automat o factură. Calculul costului cere condițiile furnizorului și contextul utilizării. Pentru durate, putem urmări **p95**, percentila sub care se situează aproximativ 95% dintre observațiile din intervalul ales. Arătăm și numărul de observații: un interval cu puține cereri nu descrie fidel încărcarea viitoare.

Evităm adresele de e-mail și identificatorii fiecărei solicitări în etichetele metricilor. Ele pot crește **cardinalitatea**, numărul combinațiilor distincte de etichete, făcând colectarea și analiza mai costisitoare. Detaliile necesare investigației apar controlat în loguri și traces.

În scenariul nostru, un rezumat întârziat nu justifică imediat schimbarea modelului. Urma ar putea arăta că documentul a așteptat în coadă, iar apelul AI a fost scurt. Investigăm atunci capacitatea procesului de lucru, nu optimizarea promptului. Dacă durata crește după o lansare, filtrăm după versiunea instalată și comparăm cereri similare, fără a confunda simpla coincidență cu o cauză demonstrată.

Înainte de extindere, provocăm și o eroare cunoscută într-un mediu izolat. Verificăm dacă evenimentul apare în log, este numărat în metrică și poate fi legat de urma corespunzătoare. Acest test arată dacă instrumentarea explică problema reală, nu doar dacă trimite date.

## O alertă trebuie să ducă la o acțiune

Ca exemplu strict ipotetic, echipa poate testa o alertă dacă există documente în așteptare de peste zece minute, iar situația persistă cinci minute. Aceste praguri ilustrează mecanismul, nu reprezintă o promisiune de serviciu sau valori universal potrivite. Le ajustăm după nevoia utilizatorilor și măsurătorile portalului.

Alerta ajunge la responsabilul operațional desemnat și conține mediul, intervalul, efectul observat și legătura către instrucțiunile de intervenție. Acesta verifică dacă procesul de lucru rulează, dacă mesajele sunt preluate și dacă dependența externă răspunde. Nu repornește automat toate operațiile: unele reîncercări pot dubla acțiuni.

Testăm regula în preproducție, mediul de verificare dinaintea producției, printr-o oprire controlată a procesului de lucru. Confirmăm primirea notificării și dispariția alertei după remediere. O alertă fără destinatar disponibil și fără acțiune clară este doar zgomot.

## Vizibilitate fără copierea documentelor

Pentru acest traseu propunem o listă explicită de câmpuri permise: serviciu, versiune, tip de operație, durată, rezultat și categorie de eroare. Nu trimitem implicit documente, prompturi, răspunsuri integrale, credențiale sau antete de autentificare în platforma de observabilitate.

Verificăm inclusiv datele emise automat de biblioteci. Eliminarea informațiilor sensibile trebuie aplicată înainte de transmiterea către stocarea externă, nu doar ascunderea lor într-un ecran. Limităm accesul și stabilim perioada de păstrare în funcție de scop și risc. Înlocuirea unui identificator cu o amprentă nu garantează anonimizarea.

**Eșantionarea** păstrează numai o parte dintre traces pentru a controla volumul. Absența unei urme nu demonstrează absența unei execuții. Documentăm ce este eșantionat și monitorizăm separat sănătatea colectării, ca o problemă a telemetriei să nu pară funcționare perfectă.

## Execuție reușită nu înseamnă răspuns corect

Agentul poate termina rapid și fără erori tehnice, dar poate omite o obligație din document. Păstrăm separat evaluarea calității, cu exemple verificate și criterii de acceptare, discutată în episodul despre evaluarea agenților. Telemetria ajută investigația, nu stabilește singură adevărul rezumatului.

Rezultatul utilizabil este o fișă cu traseul urmărit, semnalele colectate, câmpurile interzise, tabloul de bord și proprietarul alertei. Agentul de dezvoltare poate propune instrumentarea și testele; echipa verifică datele efectiv exportate. Episodul următor adaugă backupul, recuperarea și răspunsul la incidente, pentru situațiile în care diagnosticarea trebuie urmată de refacerea serviciului.

## Surse

Surse verificate la 15 octombrie 2026:

- [OpenTelemetry, Signals](https://opentelemetry.io/docs/concepts/signals/), [Traces](https://opentelemetry.io/docs/concepts/signals/traces/) și [Metrics](https://opentelemetry.io/docs/concepts/signals/metrics/), pentru semnale, spanuri, propagarea contextului și cardinalitate.
- [OpenTelemetry, Generative AI semantic conventions](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/README.md), pentru domeniul convențiilor și stadiul Development.
- [OpenTelemetry, Handling sensitive data](https://opentelemetry.io/docs/security/handling-sensitive-data/), pentru minimizare și limitele anonimizării prin hashing.
- [Google, Site Reliability Engineering, Monitoring Distributed Systems](https://sre.google/sre-book/monitoring-distributed-systems/), pentru monitorizare și alerte utile.
- [Sigelman și colaboratorii, Dapper, a Large-Scale Distributed Systems Tracing Infrastructure, 2010](https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/), raport tehnic de cercetare despre trasarea distribuită.

Vrei să afli unde apar erorile și întârzierile din aplicațiile tale? [Discută cu i8 despre observabilitate, date protejate și alerte care duc la acțiune.](https://i8.ro/contact)