Urme distribuite

Urme distribuite

1) De ce și ce este

Urmărirea distribuită este o modalitate de a lega operațiunile de-a lungul întregii căi de solicitare: gateway-ul frontal → API → microservicii → baze de date/cache → brokeri → jabs/conducte.
Rezultatul este o urmă de la intervale (span), în cazul în care fiecare interval surprinde funcționarea componentei cu atribute, evenimente și stare. Acest lucru accelerează RCA, ajută la păstrarea SLO-urilor și reduce MTTR.

• Vizibilitatea căii critice și blocajele.
• Corelarea simptomelor (metrici) cu cauze (deschideri) și detalii (jurnale).
• Analiza retroys, cozi, DLQ, fan-out, „ferăstraie” de latență.

2) Modelul de date de urmărire

Trace - graficul apelurilor cu 'trace _ id'.
Span - операция: 'name', 'kind' (SERVER/CLIENT/PRODUCATOR/CONSUMATOR/INTERN), 'start/end',' status ',' atribute ',' evenimente ',' link-uri [] '.
Atribute - cheie valoare (traseu, db. sistem, mesagerie. sistem, nor. regiune, etc.).
Evenimente - etichete instant în interiorul intervalului (de exemplu, "încercați din nou", "cache _ miss').
Span Link-uri - conexiuni în afara „părinte-copil” (batchi, retrai, fan-in/out).
Resurse - metadate de proces/serviciu ('service. nume ", versiune, mediu).

3) Contextul și tolerabilitatea

3. 1 Context de urmărire W3C

• „traceparent”: „drapele version-traceid-spanid” (pavilioanele includ prelevarea de probe).
• „tracestate”: statul specific vânzătorului (minim).
• Bagaje - chei pentru contextul de afaceri (limitat, fără PII/secrete).

3. 2 Context de aruncare

HTTP: „traceparent ”/„ tracestate”; gRPC: metadate; WebSocket: la actualizarea și în mesaje;

Mesaje: în anteturi (Kafka/NATS/RabbitMQ) - salvați contextul original cu PRODUCĂTORUL și transferul cu CONSUMATORUL.
Baze: nu „transporta” contextul - ne log atribute la span (interogare, rânduri, db. sistem), dar nu și valorile.

4) Prelevare de probe: Cum să nu meargă rupt

Eșantionarea capului: probabilistică/după reguli (traseu, chiriaș, punct final).
Prelevarea de probe (pe colector): salvați trasee „interesante” - erori, lungi p95/p99, căi rare.
Exemplare: Metrica histogramei stochează referințe la specificul 'trace _ id'.
Recomandare: combina - cap 5-20% + coada reguli 100% pentru 5xx/timeout/p99.

5) Atribute și taxonomie (minim necesar)

• "service. nume „,” serviciu. versiune ',' implementare. mediu „,” nor. regiunea „,” http. ruta ',' http. metoda „,” http. status_code', 'db. system ',' db. declarație „(scurtat/fără date)”, mesagerie. sistem „,” mesagerie. operaţiunea „,” peer. service ',' net. peer. nume ',' chiriaş. id', "cerere. id'.

Etichete business: curat, fara PII. Exemplu: "ordine. segment ',' plan. nivelul ".

6) scripturi asincrone, cozi și loturi

PRODUCĂTOR → CONSUMATOR: creați un PRODUCĂTOR DE INTERVAL cu context; în mesaj - anteturi (traceparent, bagaje). CONSUMATOR începe SERVER/CONSUMER-span de la link la PRODUCATOR (dacă nu există o ierarhie strictă).
Fan-out: o singură intrare - multe ieșiri → copii se întinde sau link-uri.
Lot: CONSUMATORUL citește o explozie de mesaje N → o singură deschidere cu 'evenimente' pentru fiecare mesajId sau 'link-uri' pentru N contexte separate.
DLQ: span 'messaging separat. dlq. Publică motiv conta.
Retrai: 'event: retry' + 'retry. conta "atribut; preferabil un nou interval CHILD pentru a încerca.

7) Integrarea cu jurnale și valori

Scriem jurnale JSON cu 'trace _ id'/' span _ id' → de la deschidere mergem la jurnalele făcând clic.
Măsurătorile RED/USE conțin exemplare → de la vârfurile p99 la deschiderile „rele”.
Urmele generează semnale tehnice (erori de dependență) și semnale de afaceri (conversie) prin evenimente.

8) Performanță și cost

Eșantionarea evenimentului și accelerarea.
Reducerea cardinalității atributelor (no 'user _ id'/' session _ id' as label!).
Comprimarea/măcelărirea de către exportator; export limite de timp.
Depozitare: fierbinte 1-7 zile, apoi - unități/numai trasee „problemă”.
Categorii de cheltuieli: colectori, indici, depozitare, ieșire.

9) Securitate și confidențialitate

În tranzit: TLS 1. ; În rest: criptare, chei private (vezi „Criptare în tranzit/În repaus”).
PII și secrete: nu scrieți în atribute/evenimente; tokenizarea/mascarea producătorului.
Multi-chirie: "chiriaș. identificarea "ca etichetă de resurse și izolarea spațiilor, a politicilor de citire; auditarea accesului la urme (a se vedea jurnalele de audit și nemodificate).

10) Sisteme de punere în aplicare (de referință)

10. 1 OpenTelemetry SDK (pseudocod)

python from opentelemetry import trace from opentelemetry. sdk. trace import TracerProvider from opentelemetry. sdk. resources import Resource from opentelemetry. sdk. trace. export import BatchSpanProcessor from opentelemetry. exporter. otlp. proto. grpc. trace_exporter import OTLPSpanExporter

provider = TracerProvider(resource=Resource. create({
"service. name":"checkout","service. version":"1. 12. 0","deployment. environment":"prod"
}))
provider. add_span_processor(BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317", insecure=True)))
trace. set_tracer_provider(provider)
tr = trace. get_tracer("checkout")

with tr. start_as_current_span("POST /pay", attributes={
"http. route":"/pay","http. method":"POST","tenant. id":"t-42"
}):
business logic, external API call and pass DB

10. 2 OTel Collector - eșantionare coadă (fragment)

yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_codes: [ERROR]
- type: latency threshold_ms: 900
- type: probabilistic sampling_percentage: 10 exporters:
otlphttp: { endpoint: http://trace-backend:4318 }
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, tailsampling]
exporters: [otlphttp]

10. 3 Kafka - Context Transfer (Concept)

PRODUCĂTOR: se adaugă anteturile „traceparent”, „bagaj”.
CONSUMATOR: în cazul în care mesajul inițiază un nou flux - un nou SERVER/CONSUMATOR se întinde de la link la context din anteturi.

11) Date/ETL и ML

Pentru conducte de lot: se întinde pe lot/partiție with 'dataset. Urna, fugi. id', "rânduri. în/out „,” prospețime. lag '.
Pentru ML: se întinde de formare/deducție, versiunea modelului, latență, feature store.
Link către Lineage: 'run. id „и” set de date. urn' allow să sari de la urmă la graficul de origine a datelor.

12) Platforma de urmărire SLO

Disponibilitate ingestie: ≥ 99. 9%

Întârziere la indexare: ≤ 60 s p95

Acoperire cap-eșantion: ≥ 5-10% din rutele cheie

Salvarea 100% a traseelor cu status ERROR și cu latență> prag în conformitate cu directorul „căi critice”

Alertele platformei: creșterea picăturilor, timpii de export, decalajul indexării, supraîncălzirea cardinalității.

13) Testarea și verificarea

Trace contract în CI: prezența de deschideri pe puncte finale cheie, atribute obligatorii, corect „traceparent” zboară prin gateway/proxy.
Probe sintetice/rom: colecta trasee din exterior.
Haos/incidente: dezactivarea dependențelor, verificarea erorilor eșantionului de coadă.
Fum în vânzări: după lansare - „există orice deschideri” și urme exemplare de →.

14) Liste de verificare

Înainte de vânzare

• W3C Trace Context este aruncat peste tot; pentru mesaje - anteturi.
• Eșantionarea capului de bază este activată; sunt configurate reguli de coadă pentru 5xx/p99.
• Atributele obligatorii sunt ruta, metoda, starea, serviciul. Versiune, chiriaş. id.
• Jurnalele JSON cu 'trace _ id'/' span _ id', metrici cu exemplare.
• dezinfectante PII; Criptarea politicilor de acces go/at rest.
• Tablouri de bord: „cale critică”, „erori de dependență”, „retras/timeout”.

Funcționare

• Revizuirea lunară a cardinalității atributelor; cote.
• Tuning eșantionare coada de SLO (mai puțin zgomot, toate „fierbinte” - în proba).
• Instruirea RCA-urilor cu → metric de tranziție exemplar → urme → jurnale.
• Verificarea huse pentru cozi, DLQs, locuri de muncă ETL.

15) Runbook'и

RCA: creștere p99 la/plată

1. Deschideți tabloul de bord RED; de la bin p99 du-te pe exemplar pentru a urmări.
2. Găsiți un "îngust" CLIENT-span (de exemplu, "gateway. apel "), check 'retry. conta ", timeout.
3. Comparați versiunile de servicii/dependențe, regiune/zonă.
4. Activați degradarea (răspuns cache/limită RPS), notificați proprietarii de dependență.
5. După fix - RCA și bilete de optimizare.

Supratensiune DLQ

1. Urmăriți filtrul prin mesagerie. dlq. publicare ".
2. Verificați motivele (evenimentele), corelați cu eliberarea.
3. Începeți reprocesarea, creșteți temporar timpul pentru CONSUMER, notificați proprietarii din aval.

16) Erori frecvente

Nu există o predicție a contextului prin intermediul gateway-urilor/brokerilor. Soluție: middleware/interseptoare, biblioteci unice.
Toate traseele 100%. Scump și inutil - folosiți eșantionarea cozii.
Jurnalele fără 'trace _ id'. Corelația → MTTR ↑ este pierdută.
PII în atribute. Mască/tokenize; să păstreze doar contextul tehnic.
„Mute” background jabs. Adăugați deschideri la lot/partiție și 'run. id'.
Numirea discrepanței. Introduceți un dicționar de deschideri și taste de atribut.

17) ÎNTREBĂRI FRECVENTE

Î: Este mai bine eșantionarea capului sau a cozii?
R: Combinație. Capul dă stratul de bază, coada garantează conservarea anomaliilor/erorilor.

Î: Cum pot urmări prin Kafka fără o ierarhie rigidă?
R: Utilizați legăturile dintre PRODUCĂTOR și CONSUMATOR; context - în anteturi.

Î: Ce trebuie să faceți cu SQL sensibil?
R: "db. extras „scurtat/normalizat (fără valori), sau” db. operație "+ dimensiuni/timp.

Î: Cum vă raportați la valorile de afaceri?
R: Adăugați atribute ale domeniului fără PII (plan/segment), utilizați evenimente de „etape de afaceri” în cadrul intervalului și mergeți de la metrici de conversie la exemplar.

• „Observabilitate: busteni, metrici, urme”
• „Audit și jurnale imuabile”
• „În tranzit/În repaus criptare”
• „Originea datelor (Lineage)”
• „Confidențialitate prin design (GDPR)”
• „Managementul secret”