Menganalisis trace dan peta layanan

Pemantauan dan Pemecahan Masalah AWS

John Q. Martin

Principal Consultant

Apa itu peta layanan?

Dibuat otomatis dari data trace Anda: tanpa penyiapan manual

Papan keberangkatan kereta dengan baris layanan, masing-masing dengan lampu status berwarna: hijau tepat waktu, kuning tertunda, merah berhenti

Sekilas: hijau = tepat waktu · kuning = tertunda · merah = berhenti

Cara mengakses:

X-Ray console → Service map
Terapkan filter
Klik node → rincian lengkap

Kode warna peta layanan

Kunci warna peta layanan: hijau panggilan sukses, kuning kesalahan klien, merah kesalahan server, ungu throttling, abu-abu tanpa trafik

Saat membuka peta layanan, langsung cari yang bukan hijau.

Klik node mana pun untuk melihat: sebaran waktu respons, rincian status HTTP, jenis error.

Membaca peta layanan

Peta layanan dengan API Gateway dan OrderService bercabang ke DynamoDB Inventory dan layanan Payment berwarna kuning

Analisis jalur kritis

Jalur kritis = rantai panggilan layanan terpanjang

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

Total: 400ms

External API = 50% dari total latensi

Tindak lanjut:

External API adalah target optimasi Anda
Opsi: tambah caching, terapkan timeout + fallback, negosiasikan SLA

Bandingkan jalur alternatif:

OrderService -> DynamoDB
Total: 120ms (cepat)

Risiko ketergantungan

Risiko ketergantungan peta layanan: ketergantungan melingkar, titik kegagalan tunggal, dan ketergantungan eksternal berisiko

Memahami linimasa trace

Linimasa trace dengan subsegmen sepanjang sumbu waktu menampilkan panggilan payment-api sebagai operasi terlama

Sumbu horizontal waktu: kapan operasi mulai dan berapa lama durasinya
Sumbu vertikal hierarki layanan: subsegmen mengindent di bawah induk
HTTP.POST ke payment-api (100-250ms) = operasi tunggal terlama

Pola 1: Bottleneck sekuensial

Sebelum (sekuensial - 80ms):

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

Sesudah (paralel - 20ms):

Linimasa trace empat kueri berjalan paralel saling tumpang tindih hingga selesai dalam 20ms

Pola 2: Kueri N+1 dan layanan "chatty"

Masalah Kueri N+1:

Ambil daftar pengguna       (10-20ms)
Ambil detail pengguna 1     (20-30ms)
Ambil detail pengguna 2     (30-40ms)
... ×100 kueri sekuensial

Perbaikan: batch query, eager loading

Layanan "chatty":

50 panggilan kecil antar dua layanan alih-alih 1 batch
Tiap panggilan: penyiapan koneksi + serialisasi + round-trip
50× overhead

Perbaikan: batch request, message queue, caching

Pola 3: Cold start dan kegagalan berantai

Dua bilah linimasa: cold start memiliki blok inisialisasi oranye besar lalu handler hijau kecil; warm start hanya handler hijau kecil

Lambda Cold Start:

Cold: 3000ms (2500ms init + 500ms handler)
Warm: 500ms (hanya handler)
Terlihat sebagai segmen init besar pada pemanggilan pertama

Perbaikan: provisioned concurrency, optimalkan inisialisasi

Kegagalan Berantai:

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

Blok timeout serupa menumpuk sepanjang hierarki trace

Perbaikan: timeout, circuit breaker, fallback

Memfilter trace dengan anotasi

Konsol X-Ray memfilter trace berdasarkan pasangan kunci-nilai anotasi

Bandingkan grup:

Pengguna premium rata-rata 200ms vs. pengguna gratis 150ms → fitur premium menambah latensi
EU West 3× lebih lambat dari US East → masalah akses data lintas region

Alur kerja analisis trace

Identifikasi - filter: response_time > 1000ms, urutkan menurut durasi
Analisis - temukan operasi terlama, bottleneck sekuensial, peluang paralel
Anotasi - cek anotasi untuk konteks bisnis: user ID, order ID, environment
Tinjau - periksa metadata: detail permintaan, pesan error
Korelasi - rujuk silang dengan CloudWatch Logs
Diagnosis - akar masalah: kueri lambat, timeout, algoritma, kehabisan sumber daya
Perbaiki - optimalkan kode, tambah caching, paralelkan, skalakan
Verifikasi - bandingkan trace sebelum/sesudah, pantau latensi dan tingkat error

Membuat peringatan dari data X-Ray

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

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

Ringkasan video

Peta layanan - diagram arsitektur otomatis: node (layanan), edge (koneksi), kesehatan berkode warna
Kode warna - hijau (sukses), kuning (4xx), merah (kesalahan 5xx), ungu (429), abu-abu (tanpa trafik)
Jalur kritis - rantai panggilan terpanjang, menentukan target optimasi Anda
Linimasa trace - mengungkap bottleneck sekuensial, kueri N+1, cold start, kegagalan berantai
Anotasi - memfilter dan mengelompokkan trace menurut konteks bisnis
Alur kerja - delapan langkah: identifikasi → analisis → anotasi → tinjau → korelasi → diagnosis → perbaiki → verifikasi

Menganalisis trace dan peta layanan

Pemantauan dan Pemecahan Masalah AWS