Belajar Istio - Observability at Scale & Correlation

#Pendahuluan

Pada skala kecil, Prometheus bisa menyimpan semua metrik dan semuanya terlihat jelas. Saat mesh membesar, biaya telemetry meledak: metrik ber-kardinalitas tinggi memakan storage, trace membanjiri backend, dan alert berisiko jadi kebisingan. Episode 20 ini membahas cara mengelola observability yang bisa bertahan di skala besar dan menyusun SLO yang benar-benar diukur.

#Menangani Metrik Kardinalitas Tinggi

#Sumber Kardinalitas

Metrik istio_requests_total punya banyak label: destination_service, response_code, response_flags, source_workload, dan lainnya. Saat ada ribuan service, kombinasi nilai label menjadi jutaan series. Kardinalitas tak terkendali adalah musuh utama Prometheus.

#Menyusutkan Dimensi

Jangan hapus label secara membabi buta. Kurangi yang tidak dipakai untuk keputusan:

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: metric-reduce
  namespace: istio-system
spec:
  metrics:
  - providers:
    - name: prometheus
    overrides:
    - match:
        metric: REQUEST_COUNT
      tagOverrides:
        connection_security_policy:
          operation: REMOVE

tagOverrides dengan operation: REMOVE menghapus dimensi connection_security_policy dari REQUEST_COUNT. Prinsipnya: simpan dimensi yang dipakai SLI dan debugging, buang sisanya. Ukur efeknya pada jumlah series di Prometheus.

#Agregasi dan Downsampling

Gunakan recording rules Prometheus untuk menghitung metrik agregat (misalnya error rate per service per jam) dan simpan metrik mentah lebih pendek. Ini memangkas query berat dan penyimpanan jangka panjang.

#Strategi Sampling Trace

Di episode 8 kita memakai sampling acak 10 persen. Di skala besar, sampling perlu lebih cerdas:

• Head-based sampling: keputusan di awal trace (di klien), sederhana tapi bisa melewatkan trace penting.
• Tail-based sampling: keputusan setelah trace selesai, mempertahankan trace dengan error atau latency ekstrem — lebih akurat, lebih mahal.
• Prioritized sampling: selalu sample trace yang mengandung error, endpoint kritis, atau akun penting.

spec:
  tracing:
  - providers:
    - name: otel
    randomSamplingPercentage: 5
    useRequestIdForTraceSampling: true

useRequestIdForTraceSampling: true membuat keputusan sampling konsisten untuk satu request di semua hop. Target: data trace cukup untuk debugging tanpa membanjiri storage.

#Agregasi Log

Log akses Envoy jumlahnya besar. Strategi agregasi yang sehat:

• Ubah format log ke JSON agar mudah di-parse.
• Kirim log ke pipeline terpusat (misalnya Loki atau Elasticsearch).
• Terapkan sampling log untuk request 2xx; simpan semua 4xx dan 5xx.
• Korelasikan log dengan trace lewat request_id atau x-request-id.

Struktur log terpusat memungkinkan kalian menelusuri satu request dari gateway sampai backend, melengkapi metrik dan trace.

#SLO, SLI, dan Alerting

#Menentukan SLI dan SLO

SLI adalah ukuran kuantitatif kualitas layanan; SLO adalah target yang disepakati. Untuk mesh, SLI yang umum:

• Availability: persentase request tanpa error, misalnya target 99.9 persen.
• Latency: p95 atau p99 latency di bawah ambang tertentu.
• Throughput: request per detik.

Contoh SLI latency dengan Prometheus:

histogram_quantile(0.99, sum(rate(istio_request_duration_milliseconds_bucket{reporter="destination",destination_service="productpage.default.svc.cluster.local"}[5m])) by (le))

histogram_quantile(0.99, ...) menghitung p99 latency productpage dalam lima menit. Metrik ini dipakai untuk menentukan apakah SLO terpenuhi.

#Alerting Berbasis Error Budget

Aturan emas SLO: alert saat error budget menipis, bukan saat satu request gagal. Error budget adalah 100 minus SLO. Jika SLO 99.9 persen, budget adalah 0.1 persen per bulan. Alerting yang sehat:

• Page hanya saat budget hampir habis atau habis.
• Dashboard untuk tren normal harian.
• Runbook untuk setiap alert yang bisa di-page.

Prinsip ini mencegah alert fatigue dan memastikan halaman yang masuk benar-benar membutuhkan respons manusia.

#Penutup

Episode 20 mempersiapkan observability untuk skala besar: mengelola kardinalitas metrik, memakai sampling trace yang cerdas, agregasi log terpusat, serta menyusun SLO berbasis SLI yang terukur dengan alerting dari error budget.

Inti yang harus dibawa pulang:

• Kardinalitas tinggi adalah musuh Prometheus; buang dimensi yang tidak dipakai.
• Recording rules dan downsampling memangkas beban storage.
• Tail-based atau prioritized sampling lebih akurat daripada acak.
• useRequestIdForTraceSampling membuat sampling konsisten lintas hop.
• Agregasi log terpusat memungkinkan korelasi dengan trace.
• SLI diukur dulu, SLO ditetapkan dari baseline nyata.
• Alert dari error budget, bukan dari satu kegagalan.

Di episode 21 selanjutnya kita akan melindungi perjalanan panjang mesh: upgrade, backup, dan disaster recovery — jalur upgrade yang aman dengan canary, strategi rollback, backup dan restore konfigurasi Istio, serta pemulihan cluster.