Observabilitate dincolo de monitorizare: log-uri, metrici și trace-uri în practică

„Monitorizarea noastră spune că totul e verde, dar clienții se plâng.” Auzim asta cel puțin o dată pe lună.

Asta pentru că monitorizarea și observabilitatea nu sunt același lucru. Monitorizarea răspunde la întrebări cunoscute: serverul este up? CPU-ul este peste 80%? Observabilitatea răspunde la întrebări la care nu te-ai gândit încă: de ce primește acest utilizator anume erori 500 doar marți dimineața, din regiunea Frankfurt?

Cei trei piloni

Ai mai auzit asta. Dar majoritatea echipelor îi implementează izolat, ceea ce anulează scopul.

Metrici — Imaginea de ansamblu

Metricile sunt măsurători numerice în timp. Sunt ieftin de stocat, rapid de interogat și perfecte pentru dashboard-uri și alerte.

# Request rate
rate(http_requests_total{service="api"}[5m])

# Error rate (as a percentage)
rate(http_requests_total{service="api", status=~"5.."}[5m])
/ rate(http_requests_total{service="api"}[5m]) * 100

# 95th percentile latency
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket{service="api"}[5m]))

Urmăm metoda RED pentru servicii (Rate, Errors, Duration) și metoda USE pentru infrastructură (Utilization, Saturation, Errors).

Tooling: Prometheus pentru colectare și alertare, Grafana pentru vizualizare, Thanos pentru stocare pe termen lung și agregare multi-cluster.

Log-uri — Detaliul

Log-urile îți spun ce s-a întâmplat. Dar log-urile nestructurate sunt aproape inutile la scară.

# Bad — unstructured, unparseable at scale
[2026-01-12 14:23:01] ERROR: Failed to process request from user 12345

# Good — structured JSON, every field is queryable
{"timestamp":"2026-01-12T14:23:01Z","level":"error","service":"api","trace_id":"abc123","user_id":"12345","method":"POST","path":"/api/orders","status":500,"duration_ms":234,"error":"connection refused: postgres:5432"}

Logging-ul structurat este nenegociabil. Dacă nu poți filtra simultan după user_id, trace_id și status, vei petrece ore întregi făcând grep prin fișiere.

Tooling: Loki pentru agregarea log-urilor (se potrivește perfect cu Grafana — aceeași interfață de interogare ca la metrici), Promtail sau Alloy pentru colectare.

Trace-uri — Traseul

Trace-urile arată drumul unui request prin sistemul tău. Când un request ajunge la API, apelează un microserviciu, interoghează o bază de date și scrie într-un cache — un trace leagă toate aceste span-uri:

[Trace: abc123] Total: 450ms
├── [api-gateway] 12ms
│   └── [auth-service] 34ms
│       └── [redis-cache] 2ms
├── [order-service] 380ms     ← bottleneck
│   ├── [postgres-query] 310ms ← root cause
│   └── [inventory-check] 45ms
└── [notification-service] 24ms (async)

Fără trace-uri, ai vedea în metrici „API-ul e lent” și ai petrece o oră ghicind care serviciu este bottleneck-ul. Cu trace-uri, vezi răspunsul instantaneu: query-ul Postgres din order service durează 310ms.

Tooling: OpenTelemetry pentru instrumentare (independent de vendor), Tempo pentru stocarea trace-urilor, Grafana pentru vizualizare.

Funcționalitatea decisivă: corelarea

Cei trei piloni devin puternici atunci când sunt conectați:

1. Se declanșează o alertă pe rată mare de erori (metrici)
2. Dai click ca să vezi log-urile de eroare din acea fereastră de timp (log-uri)
3. Dai click pe un trace_id din log ca să vezi traseul complet al request-ului (trace-uri)
4. Găsești cauza — un query lent în baza de date, un serviciu downstream care eșuează, un timeout configurat greșit

În Grafana, acest flux este fără fricțiune. Dashboard-urile de metrici trimit către query-uri Loki. Intrările din log trimit către trace-uri în Tempo. Poți ajunge de la „ceva e stricat” la „iată de ce” în mai puțin de un minut.

Strategia de instrumentare

La nivel de aplicație

Folosește SDK-urile OpenTelemetry. Suportă fiecare limbaj și framework important:

# Python example with OpenTelemetry
from opentelemetry import trace, metrics

tracer = trace.get_tracer("order-service")
meter = metrics.get_meter("order-service")

order_counter = meter.create_counter(
    "orders.created",
    description="Number of orders created"
)

@tracer.start_as_current_span("create_order")
def create_order(user_id: str, items: list):
    span = trace.get_current_span()
    span.set_attribute("user.id", user_id)
    span.set_attribute("order.items_count", len(items))
    
    order_counter.add(1, {"region": "eu-west"})
    # ... business logic

La nivel de infrastructură

Pentru metricile de infrastructură folosim:

• Node Exporter — Metrici de host Linux (CPU, memorie, disc, rețea)
• cAdvisor — Metrici de containere
• kube-state-metrics — Metrici ale obiectelor Kubernetes
• SNMP Exporter — Metrici ale echipamentelor de rețea

Stack-ul Grafana

Stack-ul nostru complet de observabilitate:

Componentă	Rol	Date
Prometheus	Bază de date time-series	Metrici
Loki	Agregare de log-uri	Log-uri
Tempo	Backend pentru trace-uri	Trace-uri
Grafana	Vizualizare	Toate trei
Alloy	Agent de colectare	Trimite toată telemetria
Alertmanager	Rutarea alertelor	Notificări

Totul open-source. Totul self-hosted pe infrastructura noastră. Fără prețuri per utilizator, fără taxe de egress pentru date, fără vendor lock-in.

Greșeli frecvente

1. Alertare pe simptome, nu pe cauze — Alertează pe rata de erori, nu pe utilizarea CPU. CPU-ul ridicat este un simptom.
2. Prea multe dashboard-uri — Dacă ai 200 de dashboard-uri, nimeni nu se uită la niciunul. Ai 5 foarte bune.
3. Lipsa ownership-ului pe servicii — Fiecare metrică, log și alertă are nevoie de un owner. Altfel, alertele sunt ignorate.
4. Fără SLO-uri — Fără SLO-uri, nu știi când ceva este „suficient de rău” încât să trezești pe cineva. Citește ghidul nostru despre SLO-uri.
5. Sampling prea agresiv — Head-based sampling la 1% înseamnă că vei rata erori rare, dar critice. Folosește tail-based sampling.

Cum începi

Dacă pornești de la zero:

1. Săptămâna 1 — Instalează Prometheus + Grafana, instrumentează metrici RED pentru primele 3 servicii ca importanță
2. Săptămâna 2 — Adaugă Loki pentru logging structurat, creează un dashboard bazat pe log-uri
3. Săptămâna 3 — Adaugă tracing OpenTelemetry la un serviciu, instalează Tempo
4. Săptămâna 4 — Conectează totul în Grafana, configurează exemplars care leagă metricile → trace-uri

Sau sari peste configurare și lasă-ne pe noi să îl construim pentru tine. Am instalat acest stack pentru echipe de 5 și pentru echipe de 500.