Observabilitate: ce este, cum diferă de monitoring, de ce contează

Observabilitatea este capacitatea de a înțelege ce se întâmplă în interiorul unui sistem doar pe baza datelor pe care sistemul le emite în exterior. Cu alte cuvinte, dacă apare un comportament neașteptat, poți afla cauza fără să mai adaugi instrumentare nouă și fără să mai faci redeploy.

Termenul vine din teoria controlului (Rudolf Kálmán, 1960) și s-a stabilit în software pe la mijlocul anilor 2010, când serviciile distribuite au depășit ce putea explica un singur grafic de CPU. Confuzia obișnuită este că observabilitatea ar fi „monitoring premium". Nu este. Monitoring-ul răspunde la întrebări preconfigurate; observabilitatea te lasă să pui întrebări pe care nu le-ai anticipat.

Ce este observabilitatea mai exact?

O proprietate a sistemului tău, nu un produs pe care îl cumperi. Un sistem este observabil dacă, atunci când apare ceva neașteptat, ai în mână datele necesare ca să răspunzi la întrebări noi. Dacă mereu trebuie să adaugi încă un log sau încă o metrică pentru a diagnostica un incident, sistemul tău nu este observabil, ci doar monitorizat.

Distincția contează pentru că schimbă cum gândești instrumentarea. Pentru monitoring, întrebi „ce dashboard vreau?". Pentru observabilitate, întrebi „ce date trebuie să emit ca să pot răspunde la orice întrebare rezonabilă?". A doua întrebare produce telemetrie bogată, structurată, indexabilă. Prima produce dashboard-uri frumoase și incidente lungi.

Din ce este alcătuită observabilitatea?

În practică, observabilitatea se sprijină pe trei tipuri de telemetrie. Combinate, acoperă majoritatea covârșitoare a întrebărilor pe care le-ai pune unui sistem în producție:

• Logs. Evenimente discrete, cu timestamp, descriind ce s-a întâmplat. Un log bun este structurat (JSON, nu text liber) și include identificatori corelabili: trace ID, user ID, request ID. Fără identificatori, log-urile sunt zgomot.
• Metrics. Valori numerice agregate în timp: latență, rată de erori, throughput, saturație. Sunt ieftine de stocat și rapide de interogat. Răspund la întrebări de tip „cât" și „cât de des", dar nu la „de ce".
• Traces. Lanțul de operații pe care l-a parcurs o singură cerere prin sistem, de la nginx la aplicație la baza de date și înapoi. Esențiale când ai mai mult de un serviciu sau când un singur request lent îți strică SLO-ul.

Cei trei piloni nu sunt o ierarhie. Sunt vederi diferite ale aceluiași sistem, fiecare răspunzând la o clasă diferită de întrebări. Un sistem cu metrici excelenți și log-uri zero este greu de depanat. Un sistem cu log-uri abundente și fără metrici nu îți permite să dormi noaptea pentru că nu ai alertare ieftină.

Care sunt capcanele frecvente în observabilitate?

După doi ani de operare a stack-ului propriu și a celor șase produse de pe care colectăm telemetrie¹, capcanele care întorc cele mai multe ore sunt:

• Dashboard fără owner. Dacă nimeni nu se uită la el zilnic, nu există. La crawlerra am închis patru dashboard-uri în primul trimestru pentru exact motivul ăsta. Un dashboard nemonitorizat nu doar că nu ajută, ci diluează atenția de la cele care chiar contează.
• Alerte zgomotoase, niciodată acționabile. Dacă o alertă se aprinde de zece ori pe zi și de fiecare dată concluzia este „o ignorăm", alerta nu măsoară nimic util. Sau pragul e greșit, sau metricul nu reflectă o problemă reală. În ambele cazuri trebuie tăiată, nu lăsată pe „later".
• Log-uri nestructurate. Un printf("user logged in: %s", email) este inutil când vrei să cauți toți userii care au eșuat la login în ultimele cinci minute. Structurează din prima zi (JSON, câmpuri stabile, identificatori).
• Trace-uri active doar pentru request-uri „interesante". Sampling-ul agresiv pierde exact request-urile pe care vrei să le analizezi (cele rare și lente). Începe cu sampling 100% pe trafic mic, scade rata doar când costul devine problemă reală.
• Retenție mai lungă decât folosirea. Dacă păstrezi log-uri de 90 de zile dar nimeni nu se uită niciodată mai în urmă de 7 zile, plătești pentru stocare moartă. Retenția trebuie aliniată cu modul în care echipa investighează efectiv.

Cum o folosim noi la crawlerra?

Stack-ul nostru este Prometheus pentru metrici, Loki pentru log-uri agregate, Grafana pentru vizualizare și Tempo pentru trace-uri. Toate rulează self-hosted pe același VPS pe care rulează și produsele monitorizate, în Docker Compose, cu retenție de 14 zile pentru metrici și 7 zile pentru log-uri. Alertele merg prin Alertmanager către o ramificație n8n care decide canalul de comunicare (Slack, SMS sau e-mail, după severitate).

Politica este simplă: răspundem propriilor noastre alerte. Dacă un produs ne trezește la 3 dimineața, alerta sau pragul ei se schimbă în următorul sprint, nu peste șase luni. Asta e diferența concretă dintre un setup de monitoring „pus și uitat" și o practică reală de site reliability engineering. Latența medie de la incident la primul ping este sub un minut², iar fiecare alertă are un runbook asociat în repo (acum sunt douăzeci de runbook-uri active³). Detaliile complete de stack și configurația Compose sunt în ghidul nostru despre stack-ul Prometheus, Grafana și Loki pus în producție.

Cum verifici că observabilitatea funcționează?

Singurul test onest este să provoci un incident controlat și să vezi cât de repede ajungi de la „ceva e stricat" la „știu exact ce s-a întâmplat și de ce". Dacă durează mai mult de cincisprezece minute pentru o problemă cunoscută (rate spike, eroare repetitivă într-un endpoint, query lent), instrumentarea ta nu te-a ajutat suficient.

În practică, organizează un exercițiu de tip game day o dată pe trimestru: generează o eroare într-un mediu de staging și măsoară detection time, time to diagnosis și time to mitigation. Notează ce întrebări ai vrut să pui și nu ai putut. Acelea sunt găurile de observabilitate. Le închizi una câte una și nu adaugi nimic în plus „pentru orice eventualitate".

Cele patru grafice esențiale pe care ar trebui să le aibă orice serviciu sunt latența pe percentile (p50, p95, p99), rata de erori, traficul și saturația resursei principale, plus o singură alertă pe rata de erori. Pe baza acestor patru grafice plus log-urile structurate adăugate la nevoie, am ținut SLA-ul la 99,9% pe RestoInsights timp de doi ani fără pager fatigue⁴. Restul telemetriei vine la cerere, pe măsură ce incidentele cer întrebări noi.

1. Stack-ul de observabilitate crawlerra acoperă șase produse în producție: PromoAzi, RestoInsights, FarmaAzi, Crawlerra.com, Hub Travel Domus și o instanță medical-blog. [ops.products_count]
2. Mediana măsurată pe ultimele 90 de zile a duratei dintre eventul declanșator (eroare în log, prag depășit la metrică) și primul ping pe canalul de alertare. [ops.alert_latency]
3. Numărul de runbook-uri active în repo-ul de operațiuni la momentul ultimei revizii (mai 2026). [ops.runbooks_count]
4. Uptime cumulat pe RestoInsights pe perioada mai 2024 – mai 2026, calculat după regulile noastre interne descrise în articolul despre software-ul care durează. [resto.uptime_two_year]