Observabilitate: busteni, valori, urme
Observabilitate: busteni, valori, urme
1) De ce aveți nevoie de ea
Observabilitate - Capacitatea unui sistem de a răspunde la întrebări neplanificate despre starea sa. Se bazează pe trei semnale principale:- Valorile sunt agregate compacte pentru SLI/SLO și alertarea simptomelor.
- Urme - lanțuri de interogare end-to-end.
- Jurnale - evenimente detaliate pentru investigații și audituri.
Scop: RCA rapid, alerte preventive și fiabilitate gestionată într-un buget de eroare.
2) Principii de arhitectură
Context unic: oriunde aruncăm 'trace _ id',' span _ id', 'tenant _ id',' request _ id', 'user _ agent', 'client _ ip _ hash'.
Standarde: OpenTelemetry (OTel) pentru SDK/agenți, format jurnal JSON (canonic, cu schema).
Simptome> cauze: alertă după simptomele utilizatorului (latență/erori), nu după procesor.
Comunicarea semnalului: de la metrica → la exemplare → la busteni specifici prin 'trace _ id'.
Securitate și confidențialitate: mascare PII în jurnale, criptare în tranzit/în repaus, jurnale de audit imuabile.
Multi-chirie: separarea namespaces/chei/politici.
3) taxonomie semnal și scheme
3. 1 Măsurători
RED (rată, erori, durată) pentru servicii și utilizare (utilizare, saturație, erori) pentru infrastructură.
Типы: contra, ecartament, histogramă/rezumat. Pentru latență, histogramă cu găleți fixe.
Exemplare: trimitere la "trace _ id' în pubele histogramă" fierbinte ".
name: http_server_duration_seconds labels: {service, route, method, code, tenant}
type: histogram buckets: [0. 01, 0. 025, 0. 05, 0. 1, 0. 25, 0. 5, 1, 2, 5]
exemplar: trace_id
3. 2 Urme
Span = operație cu 'nume', 'start/end',' atribute ',' evenimente ',' stare '.
W3C Trace Context pentru tolerabilitate.
Eșantionare: bază (cap) + dinamică (coadă) + reguli de „importanță” (erori, p95 ridicat).
3. 3 Busteni
Numai JSON structurat; niveluri: DEPANARE/INFO/WARN/EROARE.
Câmpurile obligatorii sunt 'ts _ utc',' level ',' message ',' trace _ id', 'span _ id',' tenant _ id', 'env', 'service', 'region', 'host', 'labels {}'.
Interzis: secrete, jetoane, PAN, parole. PII - numai tokenizat/mascat.
json
{"ts":"2025-10-31T12:05:42. 123Z","level":"ERROR","service":"checkout","env":"prod",
"trace_id":"c03c...","span_id":"9ab1...","tenant_id":"t-42","route":"/pay",
"code":502,"msg":"payment gateway timeout","retry":true}
4) Colectarea și transportul
Agenții/exportatorii (daemonset/sidecar) → un tampon pe nodul → bus/ingera (TLS/mTLS) → magazinul de semnal.
Cerințe: back-pressure, retrays, deduplication, cardinality restriction (etichete!), Protection against „jurnal furtuni”.
Metrics: pull (Prometheus-compatibil) sau push prin OTLP.
Urme: OTLP/HTTP (gRPC), eșantioane de coadă pe colector.
Busteni: colectie locala (jurnal/docker/stdout) → parser → normalizator.
5) Depozitare și reținere (pe niveluri)
Valori: fierbinte TSDB 7-30 zile (cu downsample), agregate pentru o perioadă mai lungă (90-365 zile).
Urme: 1-7 zile pline, apoi agregate/intervale de servicii „importante”; store indexes on 'service', 'status', 'error'.
Busteni: indice cald 7-14 zile, cald 3-6 luni, arhiva până la 1-7 ani (conformitate). Audit - WORM.
Optimizarea costurilor: sub-eșantionare, filtrarea DEBUG în vânzări, cote de etichete, eșantionare pentru piese.
6) SLI/SLO, alertă și taxă
SLI: disponibilitate (% cereri de succes), latență (p95/p99), 5xx share, prospețime a datelor, cota de locuri de muncă de succes.
SLO: țintă pe SLI (ex. 99. 9% succes ≤ 400 ms).
Bugetul de eroare: 0. 1% „marjă de eroare” → regulile de ficțiune/experimente.
- „ALERT HighLatency” если „p99 (http_server_duration_seconds{route="/pay"})> 1s” 5мин.
- 'ALERT ErrorRate' если 'rată (http_requests_total{code=~"5.."}[5m] )/rată (http_requests_total[5m])> 0. 02`.
- Alerte Silo (CPU/Disk) - numai ca auxiliare, fără paginare.
7) Corelarea semnalului
Metrica este „roșie” → faceți clic pe exemplar → un anumit 'trace _ id' → uitați-vă la intervalul „lent” → deschideți jurnalele prin același' trace _ id'.
Corelarea cu versiunile: atribute 'versiune', 'image _ sha', 'feature _ flag'.
Pentru date/ETL: 'dataset _ urn',' run _ id', link către descendență (vezi articolul corespunzător).
8) Prelevarea de probe și cardinalitatea
Valori: restricționați etichetele (fără 'user _ id',' session _ id'); cote/validare la înregistrare.
Urme: combinați eșantionul de cap (la intrare) și eșantionul de coadă (la colector) cu regulile: „tot ceea ce este 5xx, p99, erori - 100%”.
Busteni: niveluri și throttling; pentru erori recurente frecvente - agregarea evenimentelor (cheie dedupe).
yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_code: ERROR rate_allocation: 1. 0
- type: latency threshold_ms: 900 rate_allocation: 1. 0
- type: probabilistic hash_seed: 42 sampling_percentage: 10
9) Securitate și confidențialitate
În tranzit/în repaus: criptare (TLS 1. 3, AEAD, KMS/HSM).
PII/secrete: dezinfectanți înainte de expediere, tokenizare, mascare.
Acces: ABAC/RBAC pentru a citi; separarea rolurilor producătorilor/cititorilor/administratorilor.
Audit: jurnal neschimbat de acces la busteni/urme; export - în formă criptată.
Multi-chirie: namespaces/chiriaș-etichete cu politici; izolarea cheii de criptare.
10) Profile de configurare (fragmente)
Prometheus (valori HTTP + alertă):yaml global: { scrape_interval: 15s, evaluation_interval: 30s }
scrape_configs:
- job_name: 'app'
static_configs: [{ targets: ['app-1:8080','app-2:8080'] }]
rule_files: ['slo. rules. yaml']
slo. reguli. yaml (exemplu RED):
yaml groups:
- name: http_slo rules:
- record: job:http_request_duration_seconds:p99 expr: histogram_quantile(0. 99, sum(rate(http_server_duration_seconds_bucket[5m])) by (le,route))
- alert: HighLatencyP99 expr: job:http_request_duration_seconds:p99{route="/pay"} > 1 for: 5m
OpenTelemetry SDK (pseudocod):
python provider = TracerProvider(resource=Resource. create({"service. name":"checkout","service. version":"1. 8. 3"}))
provider. add_span_processor(BatchSpanProcessor(OTLPExporter(endpoint="otel-collector:4317")))
set_tracer_provider(provider)
with tracer. start_as_current_span("pay", attributes={"route":"/pay","tenant":"t-42"}):
business logic pass
Jurnalele de aplicare (stdout JSON):
python log. info("gw_timeout", extra={"route":"/pay","code":502,"trace_id":get_trace_id()})
11) Date/ETL și streaming
SLI pentru date: prospețime (max lag), completitudine (rânduri vs așteptare), „calitate” (validatoare/duplicate).
Alerte: saltul ferestrelor, întârzierea consumatorilor, creșterea DLQ.
Corelație: 'run _ id',' dataset _ urn', evenimente de linie; urme pentru conducte (interval per lot/partiție).
Kafka/NATS: metrica producătorului/consumatorului, decalaj/eșec; urme de antet (inclusiv „traceparent”).
12) Profilare și eBPF (semnal suplimentar)
Low-level hot paths CPU/allocare/IO; profiluri per incident.
Telemetria eBPF (întârzieri de rețea, DNS, apeluri de sistem) legată de 'trace _ id'/PID.
13) Testarea observabilității
Contract de semnal - Verifică exportul de metrici/etichete/histograme în CI.
Sonde sintetice: scenarii RUM/clienți simulați pentru SLI-uri externe.
Haos/Exerciții de incendiu: dezactivarea dependențelor, degradarea - ne uităm la modul în care reacționează alertele și însoțitorii.
Fum în Prod: Post-Implementați verificați dacă noile puncte finale au valori și urme.
14) Controlul costurilor și al volumului
Bugete după semnal/comandă; tabloul de bord „cost per semnal”.
Cardinalitatea în cadrul bugetului (SLO pentru cardinalitate), limitele noilor etichete.
Sub-eșantionare, prezentări de clasă de date, arhive reci și WORM pentru audit.
15) Funcționarea și SLO a platformei de observabilitate
Platforma SLO: 99. 9% din ingestiile de succes; întârziere la indicele metric ≤ 30 s, busteni ≤ 2 min, urme ≤ 1 min.
Alerte platformă: întârziere injecție, creștere picătură, eroare de semnătură/criptare, depășire tampon.
DR/HA: multi-zonă, replicare, config/regula backup-uri.
16) Liste de verificare
Înainte de vânzare:- Oriunde se aruncă 'trace _ id'/' span _ id'; Jurnalele JSON cu o diagramă.
- RED/UTILIZAȚI valori cu histograme; exemplar → aliniere.
- Coada-eșantionare activată; 5xx/p99 reguli = 100%.
- Alerte după simptome + Cărți de alergare; ore liniștite/anti-clapa.
- dezinfectante PII; Criptare în repaus/în tranzit WORM pentru audit.
- Retenții și bugete pentru volume/cardinalitate.
- Recenzie lunară de alertă (zgomot/precizie), praguri de tuning.
- Raport de eroare buget și acțiuni luate (fichfreeze, întărire).
- Verificarea de acoperiri tablou de bord/jurnal/urmă pentru căi critice.
- Incidente de formare și actualizări runbook.
17) Runbook'и
RCA: p99/creştere salarială
1. Deschide tabloul de bord RED pentru „checkout”.
2. Du-te la exemplar → o pistă lentă → dezvăluie o „deschidere îngustă” (ex. 'gateway. call').
3. Deschideți jurnalele prin 'trace _ id' → vizualizați timeouts/retrays.
4. Activați funcția rollback/limita RPS, notificați proprietarii de dependență.
5. După stabilizare - RCA, bilete de optimizare, test de redare.
1. SLI „prospețime” roșu → piesa de locuri de muncă → pitch în lipsa.
2. Verificați jurnalul broker/DLQ, erorile conectorului.
3. Începeți reprocesarea, notificați consumatorii (BI/produs) prin canalul de stare.
18) Erori frecvente
Jurnale fără schemă și fără 'trace _ id'. Investigațiile sunt întârziate uneori.
Alerte privind infrastructura în loc de simptome. Paging merge „în lapte”.
Cardinalitatea nemărginită a măsurătorilor. Explozia costurilor şi instabilitatea.
Toate piesele 100%. Costisitoare și inutile; activați eșantionarea inteligentă.
PII/secrete în jurnalele. Include dezinfectante și liste roșii.
„Mute” caracteristici. Cod nou fără valori/urme/jurnale.
19) ÎNTREBĂRI FRECVENTE
Î: Trebuie să stochez textul brut al jurnalelor?
R: Da, dar cu retenție și arhive; pentru alerte și SLO-uri, agregatele sunt suficiente. Audit - în WORM.
Î: Ce să alegeți pentru piese - eșantionare cap sau coadă?
R: Combină: cap-probabilistic pentru basecoat + coada-reguli pentru erori și anomalii.
Î: Cum pot lega măsurătorile utilizatorilor și măsurătorile tehnice?
R: Prin intermediul etichetelor generale "trace _ id' și business (" route "," chiriaș "," plan "), precum și prin evenimente de produs (conversii) cu corelație la piste.
Î: Cum să nu se înece în alerte?
R: Bateți pe simptome, introduceți ore liniștite, deduplicarea, gruparea, prioritizarea SLO și proprietarul în mod implicit per alertă.
- „Audit și jurnale imuabile”
- „În tranzit/În repaus criptare”
- „Managementul secret”
- „Originea datelor (Lineage)”
- „Confidențialitate prin design (GDPR)”
- „Garanții de livrare prin broșură web”