Belajar OpenTelemetry - Receivers & Exporters Ecosystem

#Pendahuluan

Di episode 10 kita memakai receiver dan exporter paling umum. Episode 11 melebarkan pandangan: collector bisa menerima dari dan mengirim ke hampir semua format observability yang ada — dan inilah yang membuatnya menjadi titik integrasi universal dalam arsitektur kalian.

Mengapa penting? Karena dunia nyata tidak mulai dari nol. Ada aplikasi yang sudah mengirim data ke backend lama (Jaeger agent, Zipkin, Prometheus scraper), ada tim yang mengirim logs via file, dan ada kebutuhan menyalurkan data ke Kafka. Menguasai ekosistem receiver/exporter berarti bisa mengadopsi OTel tanpa menghentikan apa pun yang sudah berjalan.

#Ekosistem Receivers

Receiver adalah pintu masuk data ke collector. Yang paling relevan:

Receiver	Kegunaan	Sinyal
`otlp`	Terima OTLP dari SDK/collector lain	traces, metrics, logs
`jaeger`	Terima format Jaeger lama (proto/thrift/compact)	traces
`zipkin`	Terima format Zipkin (v1/v2, JSON)	traces
`prometheus`	Scrape endpoint `/metrics` ala Prometheus	metrics
`filelog`	Baca file log dari disk (stdout container, app log)	logs
`hostmetrics`	Kumpulkan metrics sistem dari host	metrics
`kafka`	Konsumsi pesan dari topic Kafka	traces, metrics, logs
`otlp_json_file`	Baca telemetry dari file JSON	traces, metrics, logs

#Pola Migrasi: Backend Lama Masih Hidup

Skenario klasik: tim sudah memakai Jaeger agent dan Zipkin collector selama bertahun-tahun. Mengganti semuanya sekaligus berisiko. Solusinya: biarkan receiver lama tetap ada sementara migrasi berjalan bertahap.

Terima format lama dan OTLP bersamaan

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  jaeger:
    protocols:
      grpc:
        endpoint: 0.0.0.0:14250
  zipkin:
    endpoint: 0.0.0.0:9411
 
processors:
  batch:
 
exporters:
  otlp/backend:
    endpoint: otlp-backend:4317
    tls:
      insecure: true
 
service:
  pipelines:
    traces:
      receivers: [otlp, jaeger, zipkin]
      processors: [batch]
      exporters: [otlp/backend]

Sekarang tiga jalur masuk — OTLP, Jaeger, Zipkin — di-normalisasi menjadi satu format OTLP menuju backend baru. Aplikasi lama tetap bekerja; tim punya waktu berpindah ke SDK OTel.

#filelog: Logs dari File Container

Pola umum untuk logs: collector membaca stdout container yang ditulis ke file JSON oleh container runtime:

filelog membaca stdout container

receivers:
  filelog/stdout:
    include:
      - /var/log/pods/*/*/*.log
    start_at: beginning
 
service:
  pipelines:
    logs:
      receivers: [filelog/stdout]
      processors: [batch]
      exporters: [otlp/backend]

Ini pola yang sama dipakai pola DaemonSet di Kubernetes (episode 18) — setiap node punya collector yang membaca log pod setempat.

#Ekosistem Exporters

Exporter adalah pintu keluar. Kategorinya:

Exporter	Kegunaan
`otlp`	Kirim ke collector/backend lain via OTLP
`debug`	Tampilkan di stdout/stderr (debugging)
`prometheus`	Ekspos endpoint untuk di-scrape Prometheus
`prometheusremotewrite`	Push ke Prometheus via remote write
`kafka`	Publikasikan telemetry ke topic Kafka
`loki`	Kirim logs ke Grafana Loki
`elasticsearch`	Kirim ke ES/OpenSearch
Cloud: `awsemf`, `awsxray`, `googlecloud`, `azuremonitor`	Kirim langsung ke cloud observability

#Pola Streaming: Collector → Kafka

Saat scale besar, arsitektur umum adalah menempatkan Kafka sebagai buffer antara collector agent dan gateway. Agent mengirim ke Kafka, gateway mengonsumsi, lalu meneruskan ke backend. Ini memberi decoupling dan replay capability.

Exporter Kafka di agent, receiver Kafka di gateway

# agent exporter
exporters:
  kafka:
    protocol_version: 2.0.0
    brokers: [kafka:9092]
    topic: otlp-spans

gateway receiver

receivers:
  kafka:
    protocol_version: 2.0.0
    brokers: [kafka:9092]
    topic: otlp-spans

Note

Kafka di collector adalah keputusan arsitektur, bukan keputusan default. Tambahkan Kafka hanya jika kalian benar-benar butuh buffer persisten, replay, atau konsumsi oleh beberapa tim sekaligus. Untuk kebanyakan skala, buffering internal collector (episode 14) sudah cukup.

#Memilih Komponen: Cek Registry

Dengan ratusan receiver/exporter, pertanyaan "mana yang boleh dipakai produksi?" dijawab oleh stability level di registry OTel (opentelemetry.io/ecosystem/registry/):

Stable — komponen inti, aman untuk semua produksi.
Beta — berfungsi baik, perilaku bisa berubah dengan migrasi ringan.
Alpha — percobaan, jangan untuk produksi.

Aturan cepat: komponen yang hanya ada di distribusi contrib umumnya belum stable. Komponen di core umumnya stable. Selalu cek sebelum mengandalkan komponen baru.

#Common Pitfalls

Receiver didefinisikan tapi tak dipakai pipeline — data masuk tapi "hilang" tanpa jejak; periksa service.pipelines.
Salah format receiver — memakai zipkin untuk data yang sebenarnya Jaeger; perhatikan format dan port tiap komponen.
Kafka tanpa protocol_version — handshake gagal dengan broker modern.
Mengandalkan exporter alpha di produksi — perilaku berubah tanpa warning; cek registry.

#Penutup

Pada episode 11 ini, kalian telah menjelajahi ekosistem receiver dan exporter collector.

Inti yang harus dibawa pulang:

Receiver adalah titik masuk: otlp, jaeger, zipkin, prometheus, kafka, filelog, hostmetrics.
Exporter adalah titik keluar: otlp, debug, prometheus/remotewrite, kafka, loki/elasticsearch, cloud.
Pola migrasi: terima format lama dan OTLP bersamaan, lalu normalisasi ke satu backend.
Periksa stability level di registry sebelum memakai komponen produksi.

Di episode 12 selanjutnya, kita akan membahas processors: batching, filtering, redaction — batch, memory_limiter, attributes, resource detection, filter, redaction PII, dan tailsampling, lalu menyusun pipeline lengkap receiv → detect → filter → redact → batch → export. Sampai jumpa di episode 12!