GH GambleHub

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 ".

Mini-schemă de valori (logică. model):

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.

Exemplu de șir de jurnal (JSON):
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.

Alertarea prin simptome (exemplu):
  • „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).

Exemplu de eșantionare a cozii (conceptual, OTel Collector):
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.
Funcționare:
  • 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.

Anomalie în date (jurnal DWH):

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ă.

Materiale conexe:
  • „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”
Contact

Contactați-ne

Scrieți-ne pentru orice întrebare sau solicitare de suport.Suntem mereu gata să ajutăm!

Pornește integrarea

Email-ul este obligatoriu. Telegram sau WhatsApp sunt opționale.

Numele dumneavoastră opțional
Email opțional
Subiect opțional
Mesaj opțional
Telegram opțional
@
Dacă indicați Telegram — vă vom răspunde și acolo, pe lângă Email.
WhatsApp opțional
Format: cod de țară și număr (de exemplu, +40XXXXXXXXX).

Apăsând butonul, sunteți de acord cu prelucrarea datelor dumneavoastră.