Belajar OpenTelemetry - Collector: Arsitektur & Deployment

#Pendahuluan

Sejauh ini telemetry kalian dikirim langsung dari SDK ke Jaeger. Di episode 9 kita memperkenalkan komponen yang mengubah game: OpenTelemetry Collector — daemon yang berdiri di antara aplikasi dan backend. Collector adalah jantung deployment OTel skala nyata, dan kegagalan memahami arsitekturnya adalah penyebab paling umum observability mahal dan tidak terkelola.

Mengapa perlu collector? Karena aplikasi tidak seharusnya tahu ke mana data pergi. SDK hanya tahu "kirim ke collector"; collector yang tahu topology backend, redaksi PII, sampling, dan buffering. Ini memisahkan produksi telemetry dari konsumsi telemetry — dan membuat backend bisa diganti tanpa menyentuh aplikasi.

#Arsitektur: Pipeline Tiga Tahap

Collector bekerja dengan pipeline sederhana: receivers → processors → exporters.

• Receivers — titik masuk data: OTLP, Jaeger, Zipkin, Prometheus scrape, filelog, dan lainnya. Sebuah receiver bisa aktif tanpa pipeline yang memakainya (contoh: menerima OTLP tetapi belum mengirim ke mana pun).
• Processors — memproses data di antara penerimaan dan pengiriman: batching, filtering, redaksi PII, penambahan Resource, sampling.
• Exporters — titik keluar ke backend: OTLP, debug/stdout, Prometheus remote write, dan banyak lagi.

Config menentukan pipeline mana yang menghubungkan receiver → processor → exporter mana. Konsep ini adalah episode 10; di sini kita fokus pada dua pola deployment.

#Pola Deployment: Agent vs Gateway

#Agent (Sidecar / DaemonSet)

Collector berjalan di dekat aplikasi — satu per pod (sidecar) atau satu per node (DaemonSet di Kubernetes). Keunggulannya:

• Data tidak lewat jaringan sampai keluar node — latensi rendah.
• Redaksi dan filtering bisa dilakukan sebelum data meninggalkan aplikasi.
• Kegagalan collector lokal tidak memengaruhi node lain.

#Gateway (Deployment / Central)

Satu atau beberapa collector terpusat menerima data dari banyak agent. Keunggulannya:

• Satu tempat untuk kebijakan global: sampling tail, redaksi, routing multi-backend.
• Rate limiting dan quota terpusat.
• Satu endpoint stabil yang boleh di-whitelist di firewall.

#Kombinasi: Dua-Tingkat (Rekomendasi Produksi)

Produksi ideal memakai dua tingkat: agent di tiap node melakukan batch + redaksi awal, gateway terpusat melakukan tail sampling dan routing ke backend. Aplikasi hanya bicara ke agent lokal; agent bicara ke gateway; gateway bicara ke backend.

#Distribusi: Core vs Contrib

Collector hadir dalam dua distribusi resmi:

• otelcol (core) — komponen inti yang stabil: receiver otlp, processor batch, exporter otlp/debug. Ringan dan aman untuk kebutuhan dasar.
• otelcol-contrib — core + semua komponen kontribusi: filelog, hostmetrics, prometheus, kafka, tailsampling, redaction, dan ratusan lainnya.

Image resminya otel/opentelemetry-collector (core) dan otel/opentelemetry-collector-contrib. Sepanjang series ini kita memakai contrib karena kaya fitur untuk eksperimen.

docker run --rm otel/opentelemetry-collector-contrib:0.156.0 --version

Output menunjukkan versi modul inti (core module v1.64.0 untuk collector 0.156.x) dan versi distribusi:

otelcol-contrib version 0.156.0 (buildinfo: ... core v1.64.0 ...)

#Stability: Mixed Status

Status stabilitas komponen collector tidak seragam:

• Stable — komponen inti yang sudah mencapai kestabilan (otlp receiver, batch processor, otlp exporter, debug exporter).
• Beta — banyak komponen contrib yang berfungsi baik tetapi masih bisa berubah perilakunya.
• Alpha — komponen percobaan, API bisa berubah sewaktu-waktu; hindari di produksi.

Karena itu: pin versi collector (0.156.0, bukan :latest) dan periksa status tiap komponen di registry opentelemetry.io/ecosystem/registry/ sebelum memakainya di produksi. Collector rilis sangat sering; update perlu dilakukan terkontrol, bukan pasif mengikuti tag terbaru.

#Mengapa Collector Begitu Penting

Empat alasan collector wajib ada di deployment nyata:

1. Satu titik keluar — aplikasi tidak perlu tahu endpoint backend; whitelist firewall jadi sederhana.
2. Batasan di luar aplikasi — redaksi PII dan sampling tidak perlu ditulis ulang per bahasa/framework.
3. Buffering — saat backend down, collector menahan data (episode 14), aplikasi tidak terblokir.
4. Fan-out — satu data dikirim ke beberapa backend sekaligus (episode 20).

#Common Pitfalls

• Memakai :latest — perubahan perilaku mendadak; selalu pin versi.
• Pipeline tanpa processor batch — setiap span diekspor satu-satu, boros resource.
• Agent dan gateway konfigurasinya sama — padahal perannya beda; agent fokus ringan, gateway fokus kebijakan global.
• Memakai komponen alpha di produksi — cek stability di registry dulu.

#Penutup

Pada episode 9 ini, kalian telah menguasai arsitektur collector dan pola deployment-nya.

Inti yang harus dibawa pulang:

• Pipeline collector: receivers → processors → exporters, dikonfigurasi per pipeline.
• Dua pola: agent (sidecar/DaemonSet, lokal, cepat) dan gateway (terpusat, kebijakan global); produksi memakai keduanya.
• Distribusi: otelcol core vs otelcol-contrib; status stabilitas campuran — pin versi dan cek registry.
• otelcol version memverifikasi versi modul inti dan distribusi.

Di episode 10 selanjutnya, kita akan membahas collector configuration (YAML) — mendefinisikan receivers, processors, exporters, dan service: pipelines, lalu menyusun full pipeline OTLP in → batch → export yang siap dipakai. Sampai jumpa di episode 10!