Belajar Envoy Proxy - Observability at Scale & SLOs

#Pendahuluan

Di episode 11 kalian menghubungkan Envoy ke Prometheus, tracing, dan access log. Episode 21 menjawab pertanyaan yang muncul saat skala bertambah: bagaimana memantau ribuan Envoy tanpa membuat storage observability meledak, dan bagaimana mengubah data itu menjadi janji yang bisa diukur — SLO (Service Level Objectives).

Kalian akan belajar menangani metric berkardinalitas tinggi, memilih strategi sampling untuk tracing, mengaggregasi log tanpa kehilangan konteks, dan merancang SLI/SLO untuk proxy layer yang benar-benar mencerminkan pengalaman pengguna.

#Memantau Metric Envoy Berkardinalitas Tinggi

#Dari Mana Cardinality Datang

Metric Envoy per listener dan per cluster sudah banyak, tapi cardinality meledak saat label dinamis masuk — misalnya nilai header per request, virtual host yang banyak, atau tag custom dari stats_tags. Setiap kombinasi label baru berarti deret time series baru di Prometheus.

stats_config:
  stats_tags:
    - tag_name: cluster
      regex: "^cluster\\.(.+?)\\.(upstream|membership)\\."
    - tag_name: virtual_host
      regex: "^vhost\\.(.+?)\\."

Aturan stats_tags menentukan label apa yang diekstrak. Semakin banyak tag yang didefinisikan, semakin tinggi cardinality. Pilih tag yang benar-benar dipakai di query dan graf — sisanya biarkan menjadi bagian nama metric.

#Praktik Mengendalikan Cardinality

Beberapa kebiasaan yang menjaga Prometheus tetap sehat:

• Batasi tag ke beberapa dimensi kunci: cluster, listener, zone.
• Hindari memasukkan nilai request header sebagai label.
• Gunakan histogram_buckets yang masuk akal, bukan bucket yang terlalu halus.
• Pantau jumlah deret time series per instance dan tetap dalam target scrape.

curl -s localhost:9901/stats/prometheus | grep -c "^envoy"

Grep ^envoy menghitung jumlah deret metric yang diekspor satu Envoy. Kalikan dengan jumlah instance untuk memperkirakan beban Prometheus. Jika angka mulai tidak terkendali, evaluasi lagi tag yang didefinisikan.

#Sampling Metric

Untuk metric yang sangat banyak, sampling mungkin diperlukan. Konsepnya: jangan scrape semua instance setiap interval; scrape subset atau kurangi interval. Trade-off antara granularitas dan biaya harus diputuskan secara sadar.

#Trace Sampling dan Log Aggregation

#Strategi Sampling Tracing

Mencatat 100 persen trace di skala besar tidak realistis. Strategi sampling umum:

• Head-based sampling: putuskan sejak awal apakah trace diambil.
• Tail-based sampling: tunggu akhir trace, lalu putuskan berdasarkan kejadian menarik (error, latency tinggi).
• Error-only sampling: selalu simpan trace yang mengandung error.

tracing:
  http:
    name: envoy.tracers.opentelemetry
    typed_config:
      "@type": type.googleapis.com/envoy.tracers.opentelemetry.v3.OpenTelemetryConfig
      grpc_service:
        envoy_grpc:
          cluster_name: otel_collector
      service_name: envoy-gateway
      sampling_config:
        default_sampling_percentage: 10

Nilai default_sampling_percentage: 10 membuat Envoy hanya men-sampling 10 persen request untuk tracing. Mulai dari persentase rendah, lalu naikkan hanya saat kebutuhan investigasi memang tinggi.

#Log Aggregation yang Efisien

Access log Envoy bisa sangat besar. Kunci aggregasi yang efisien:

• Log ke stdout dan biarkan agent (Fluent Bit, OpenTelemetry Collector) yang mem-parsing.
• Simpan log lengkap di penyimpanan dingin; query dengan index terbatas.
• Jaga format log stabil agar parsing agent tidak berubah.
• Manfaatkan field trace ID untuk menggabungkan log dan trace saat investigasi.

format: "%START_TIME% %DOWNSTREAM_REMOTE_ADDRESS% %REQ(X-REQUEST-ID)% %REQ(TRACEPARENT)% %RESPONSE_CODE% %RESPONSE_FLAGS% %DURATION%ms %UPSTREAM_CLUSTER% %UPSTREAM_HOST% %REQ(METHOD)% %REQ(PATH)%\n"

Format %RESPONSE_FLAGS% dan trace ID di atas memberi semua informasi untuk debugging tanpa membebani agent dengan parsing rumit. Log yang terstruktur lebih berharga daripada log yang panjang.

#SLO dan SLI untuk Proxy Layer

#Mendefinisikan SLI

SLI adalah pengukuran konkret kualitas layanan. Untuk proxy layer, SLI yang umum:

• Availability: proporsi request yang berhasil dibanding total.
• Latency: persentil latensi seperti p99.
• Throughput: request per detik yang diproses.
• Error rate: proporsi respons 5xx terhadap total.

#Mendefinisikan SLO

SLO adalah target yang dipilih dari SLI, misalnya "latensi p99 di bawah 200ms dalam 99,9 persen waktu". Buat SLO realistis — terlalu ketat dan tim terus dipanggil; terlalu longgar dan tidak melindungi pengguna.

#Query SLI dari Metric Envoy

curl -s localhost:9901/stats/prometheus | grep "upstream_rq_time" | head -3
curl -s localhost:9901/stats/prometheus | grep "upstream_rq_5xx"

Untuk menghitung error budget secara berkala, query Prometheus agregat:

sum(rate(envoy_cluster_upstream_rq_5xx[5m])) by (envoy_cluster_name)
  / sum(rate(envoy_cluster_upstream_rq_total[5m])) by (envoy_cluster_name)

Query PromQL envoy_cluster_upstream_rq_5xx menghitung proporsi error 5xx per cluster dalam 5 menit. Error budget dihitung dari perbandingan SLI aktual terhadap target SLO selama periode berjalan.

#SLO di Service Mesh

Di ekosistem mesh, SLO juga mencakup layanan secara keseluruhan, tapi proxy layer punya peran khusus: mTLS, retry, dan routing memengaruhi availability dari sisi infrastruktur. Pantau SLI proxy terpisah dari SLI aplikasi agar bisa membedakan "proxy bermasalah" dari "aplikasi bermasalah".

#Error Budget dan Decision Making

#Apa yang Harus Dilakukan Saat Budget Habis

Error budget bukan sekadar angka — dia alat keputusan:

• Saat budget aman: bebas deploy fitur baru dan perubahan config.
• Saat budget menipis: perlambat release, fokus ke reliabilitas.
• Saat budget habis: berhenti release, perbaiki penyebab, evaluasi ulang SLO.

SLO yang baik mengubah keputusan "merasa aman" menjadi keputusan berbasis data. Untuk proxy layer, ini berarti menggabungkan metric Envoy dengan proses release yang sudah dibangun di episode 20.

curl -s localhost:9901/stats/prometheus | grep "envoy_cluster_upstream_rq_5xx"

Pantau envoy_cluster_upstream_rq_5xx secara berkala. Lonjakan yang mendekati batas budget adalah sinyal untuk menahan perubahan sampai trend turun.

#Penutup

Episode 21 menutup pilar observability: mengelola cardinality metric, strategi sampling dan aggregasi, serta merancang SLO/SLI yang mengubah data Envoy menjadi keputusan operasional.

Inti yang harus dibawa pulang:

• Cardinality metric meledak lewat label dinamis; batasi dengan stats_tags yang disengaja.
• Trace sampling 10 persen adalah titik awal yang wajar; naikkan hanya saat perlu.
• Format log yang stabil memudahkan parsing agent dan aggregasi.
• SLI proxy: availability, latensi persentil, throughput, error rate.
• Error budget adalah alat keputusan, bukan sekadar angka.
• Bedakan SLI proxy dari SLI aplikasi agar akar masalah mudah ditemukan.

Di episode 22 selanjutnya kita akan membahas production hardening dan best practices — checklist security hardening, checklist operasional dengan runbook dan debugging tools, serta pertimbangan upgrade Envoy dan strategi fallback.