Belajar OpenTelemetry - Buffering, Backpressure & Retry

#Pendahuluan

Di episode 13 kita mengurangi volume data dengan sampling. Episode 14 membahas sisi lain dari keandalan: apa yang terjadi saat backend observability down, lambat, atau menolak data? Tanpa mekanisme buffering dan retry yang benar, telemetry kalian hilang diam-diam — dan ironisnya, observability justru tidak bisa dipakai untuk menyelidiki insiden yang sedang berlangsung.

Ini bukan topik eksotis. Backend observability sering menjadi korban pertama saat beban tinggi — dan saat itulah kalian paling membutuhkan datanya. Pipeline telemetry yang andal dibangun dari tiga mekanisme: buffering (menahan data), backpressure (memberi tahu hulu untuk menunda), dan retry (mencoba lagi dengan strategi yang benar).

#Buffering di Collector: sending_queue

Exporter di collector memakai queue internal (sending_queue) untuk menahan data sebelum dikirim. Saat backend lambat, data menumpuk di queue, bukan dibuang:

exporters:
  otlp/backend:
    endpoint: jaeger:4317
    tls:
      insecure: true
    sending_queue:
      enabled: true
      queue_size: 5120          # jumlah item dalam memory
      num_consumers: 4          # goroutine pengirim paralel
      storage: file_storage     # opsi persist ke disk
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 30s
      max_elapsed_time: 5m

Parameter penting sending_queue:

• queue_size — kapasitas queue dalam memory; 5120 item default.
• num_consumers — berapa pengirim paralel; naikkan saat banyak backend.
• storage — saat memakai file_storage extension, queue persisten ke disk — data selamat dari restart collector. Ini kunci pencegahan data loss.

#Backpressure: Bahasa "Jangan Kirim Dulu"

Backpressure adalah mekanisme hulu-menunda saat hilir kewalahan. Di ekosistem OTel, sinyalnya mengalir mundur:

1. Backend menolak dengan HTTP 429 Too Many Requests atau gRPC ResourceExhausted.
2. Exporter mengenali sinyal ini, berhenti sementara, dan mengirim ulang dengan backoff.
3. Queue penuh → collector menolak data masuk dari SDK.
4. SDK melihat penolakan dan melakukan retry sendiri — telemetry tersimpan di aplikasi sesaat.

Kunci pemahamannya: penolakan bukan kegagalan, melainkan sinyal kendali. Sistem yang merespons backpressure dengan benar tidak kehilangan data — ia memperlambat aliran sampai hilir pulih.

#Retry & Backoff di Exporter

retry_on_failure mengatur perilaku ekspor ulang:

• initial_interval — jeda pertama (5 detik).
• max_interval — jeda maksimal (30 detik); interval tumbuh eksponensial dengan jitter.
• max_elapsed_time — berapa lama total mencoba sebelum menyerah (5 menit).
• Error yang di-retry: Unavailable, ResourceExhausted, DeadlineExceeded (gRPC), 429 dan 5xx (HTTP).
• Error yang tidak di-retry: InvalidArgument (payload salah) — retry tidak akan pernah berhasil.

Jitter penting: tanpa jitter, semua eksporter yang gagal akan retry pada momen yang sama dan kembali saling membanjiri — fenomena yang disebut thundering herd.

#Sisi SDK: Menangani Collector Turun

Saat collector turun sepenuhnya, SDKlah yang jadi buffer terakhir. Exporter SDK punya retry otomatis (episode 8), tetapi kapasitasnya terbatas: data yang tidak terkirim dalam beberapa kali percobaan akan di-drop oleh BatchSpanProcessor. Jika ini tidak bisa diterima, opsi lain:

• File exporter — tulis telemetry ke file lokal lalu diambil collector lain (pola filelog + otlp_json_file).
• Kafka sebagai buffer — SDK mengirim ke Kafka; collector mengonsumsi (episode 11).

Untuk kebanyakan kasus, retry + queue collector sudah memadai. Penyimpanan tambahan baru dibutuhkan saat SLA pengiriman telemetry menjadi komitmen formal.

#Mendiagnosis Data Loss

Saat telemetry "hilang", ikuti alur ini secara sistematis:

1. Cek collector — lihat metrics internal collector (otelcol_exporter_send_failed_*, otelcol_receiver_refused_*) di endpoint 8888 atau port prometheus.
2. Cek error log — --config dengan service.telemetry.logs.level: debug akan mencetak alasan penolakan.
3. Cek SDK — log Failed to export menunjukkan retry; jika berhenti, cek apakah queue SDK menyerah.
4. Cek queue collector — otelcol_exporter_queue_size menurun tapi tidak pernah kosong = hilir lambat.

receivers:
  prometheus/self:
    config:
      scrape_configs:
        - job_name: otel-collector
          scrape_interval: 10s
          static_configs:
            - targets: ["localhost:8888"]
 
service:
  pipelines:
    metrics:
      receivers: [prometheus/self]
      processors: [batch]
      exporters: [debug]

#Common Pitfalls

• Queue hanya memory tanpa file_storage — data hilang saat restart; gunakan storage persisten untuk jaminan.
• Retry tanpa jitter — thundering herd memperburuk backend yang sudah down.
• max_elapsed_time terlalu kecil — retry menyerah sebelum backend pulih; set minimal beberapa menit.
• Memory_limiter tidak ada — queue raksasa menguras memory dan menambah beban saat krisis.
• Tidak memonitor collector — tidak tahu data sedang ditolak sampai pengguna mengeluh.

#Penutup

Pada episode 14 ini, kalian telah memahami mekanisme keandalan pipeline telemetry.

Inti yang harus dibawa pulang:

• Buffering — sending_queue menahan data saat hilir lambat; file_storage membuatnya persisten.
• Backpressure — 429/ResourceExhausted adalah sinyal kendali; rantai SDK → collector → backend saling menunda dengan benar.
• Retry — backoff eksponensial dengan jitter; jangan retry error yang tidak bisa dipulihkan.
• Observasi collector itu sendiri — metrics internal di 8888 adalah garis pertahanan pertama melawan data loss diam-diam.

Di episode 15 selanjutnya, kita masuk Fase 4 dan membahas propagasi & distributed tracing across services — korelasi trace melewati HTTP, gRPC, dan queue Kafka, inject/extract context di Express, Gin, dan Spring, serta teknik melacak latency antar-service untuk menemukan bottleneck. Sampai jumpa di episode 15!