Analiza urmelor și hărților de servicii

Monitorizare și depanare în AWS

John Q. Martin

Principal Consultant

Ce este o hartă de servicii?

Generat automat din datele urmelor: fără configurare manuală

Panou de plecări feroviare cu rânduri de servicii, fiecare cu un indicator colorat: verde pentru la timp, portocaliu pentru întârziat, roșu pentru oprit

Dintr-o privire: verde = la timp · portocaliu = întârziat · roșu = oprit

Accesare:

Consola X-Ray → Service map
Aplică filtre
Apasă un nod → detalii complete

Codificarea culorilor pe harta de servicii

Legendă coduri culori hartă de servicii: verde apeluri reușite, galben erori client, roșu defecțiuni server, mov limitare trafic, gri fără trafic

Când deschizi o hartă de servicii, îndreaptă-te direct spre tot ce nu este verde.

Apasă orice nod pentru a vedea: distribuția timpului de răspuns, defalcarea statusurilor HTTP, tipurile de erori.

Cum citești o hartă de servicii

Hartă de servicii cu API Gateway și OrderService ramificându-se spre DynamoDB Inventory și un serviciu Payment galben

Analiza căii critice

Calea critică = cel mai lung lanț de apeluri

API Gateway (50ms)
  -> OrderService (50ms)
    -> PaymentService (100ms)
      -> External API (200ms)

Total: 400ms

External API = 50% din latența totală

Ce faci cu aceste informații:

External API este ținta ta de optimizare
Opțiuni: adaugă caching, implementează timeout + fallback, negociază SLA-uri

Comparație cu o cale alternativă:

OrderService -> DynamoDB
Total: 120ms (rapid)

Riscuri de dependențe

Riscuri de dependențe pe harta de servicii: dependențe circulare, puncte unice de defecțiune și dependențe externe riscante

Înțelegerea cronologiilor urmelor

Cronologie de urmă cu subsegmente pe o axă temporală, evidențiind apelul payment-api ca operațiunea cea mai lungă

Axa orizontală timp: când au început operațiunile și cât au durat
Axa verticală ierarhia serviciilor: subsegmentele sunt indentate sub părinți
HTTP.POST către payment-api (100-250ms) = cea mai lungă operațiune

Tiparul 1: Blocaje secvențiale

Înainte (secvențial - 80ms):

Query 1 (10-30ms)
         -> Query 2 (30-50ms)
                  -> Query 3 (50-70ms)
                           -> Query 4 (70-90ms)

După (paralel - 20ms):

Cronologie de urmă cu patru interogări executate în paralel, suprapuse, finalizate în 20ms

Tiparul 2: Interogări N+1 și servicii zgomotoase

Problema N+1 la interogări:

Get user list       (10-20ms)
Get user 1 details  (20-30ms)
Get user 2 details  (30-40ms)
... ×100 sequential queries

Soluție: interogări batch, eager loading

Servicii „zgomotoase":

50 apeluri mici între două servicii în loc de 1 batch
Fiecare apel: inițializare conexiune + serializare + dus-întors
Overhead de 50×

Soluție: cereri batch, cozi de mesaje, caching

Tiparul 3: Porniri la rece și defecțiuni în cascadă

Două bare de cronologie: pornire la rece cu un bloc mare de inițializare portocaliu urmat de un handler verde mic; pornire la cald conține doar handlerul verde mic

Pornire la rece Lambda:

La rece: 3000ms (2500ms inițializare + 500ms handler)
La cald: 500ms (doar handler)
Vizibil ca segment mare de inițializare la prima invocare

Soluție: concurență provizionată, optimizarea inițializării

Defecțiune în cascadă:

Service A [Error]
  -> Service B [Timeout 5s]
    -> Service C [Timeout 5s]
      -> Database [Timeout 5s]

Timeout-uri identice stivuite în ierarhia urmei

Soluție: timeout-uri, circuit breakers, fallback-uri

Filtrarea urmelor cu adnotări

Consola X-Ray filtrând urmele după perechi cheie-valoare de adnotare

Compară grupuri:

Utilizatori premium avg 200ms vs. utilizatori gratuiți avg 150ms → funcționalitățile premium adaugă latență
EU West de 3× mai lent decât US East → problemă de acces la date între regiuni

Fluxul de analiză a urmelor

Identifică - filtru: response_time > 1000ms, sortează după durată
Analizează - găsește operațiunile cele mai lente, blocajele secvențiale, oportunitățile de paralelizare
Adnotează - verifică adnotările pentru context business: ID utilizator, ID comandă, mediu
Revizuiește - examinează metadatele: detalii cerere, mesaje de eroare
Corelează - încrucișează cu CloudWatch Logs
Diagnostichează - cauza principală: interogare lentă, timeout, algoritm, epuizare resurse
Remediază - optimizează codul, adaugă caching, paralelizează, scalează
Verifică - compară urmele înainte/după, monitorizează latența și ratele de eroare

Crearea alertelor din datele X-Ray

# High latency alarm
aws cloudwatch put-metric-alarm \
  --alarm-name HighLatency \
  --metric-name ResponseTime \
  --namespace AWS/XRay \
  --statistic Average \
  --period 300 \
  --threshold 1000 \
  --comparison-operator GreaterThanThreshold

# High error count alarm
aws cloudwatch put-metric-alarm \
  --alarm-name HighErrorCount \
  --metric-name ErrorCount \
  --namespace AWS/XRay \
  --statistic Sum \
  --period 300 \
  --threshold 50 \
  --comparison-operator GreaterThanThreshold

Rezumatul videoclipului

Hărți de servicii - diagrame arhitecturale generate automat: noduri (servicii), muchii (conexiuni), stare codificată prin culori
Codificarea culorilor - verde (succes), galben (4xx), roșu (defecțiuni 5xx), mov (429), gri (fără trafic)
Calea critică - cel mai lung lanț de apeluri, îți identifică ținta de optimizare
Cronologii de urmă - evidențiază blocaje secvențiale, interogări N+1, porniri la rece, defecțiuni în cascadă
Adnotări - filtrează și grupează urmele după context business
Flux de lucru - opt pași: identifică → analizează → adnotează → revizuiește → corelează → diagnostichează → remediază → verifică

Analiza urmelor și hărților de servicii

Monitorizare și depanare în AWS