Belajar OpenTelemetry - Multi-Backend & Cloud Observability

#Pendahuluan

Sejauh ini semua telemetry menuju satu backend. Episode 20 melebarkan ke multi-backend: mengirim data ke beberapa tujuan sekaligus, memilih tujuan per sinyal, dan berintegrasi dengan observability cloud. Ini topik yang muncul begitu skala dan tim bertumbuh — tim platform menginginkan satu sumber, tim security ingin yang lain, dan cloud provider menawarkan penerima OTLP langsung.

Mengapa penting? Karena vendor lock-in observability adalah biaya tersembunyi terbesar: sekali menumpuk data di satu proprietary agent, pindah vendor berarti mengulang seluruh instrumentasi. OTel memecahkan ini dengan menjadikan aplikasi buta terhadap backend — dan episode ini menunjukkan cara memanfaatkannya sampai tuntas.

#Fan-Out: Satu Data ke Banyak Backend

Fan-out berarti satu telemetry dikirim ke beberapa backend sekaligus — misalnya internal Grafana + SaaS Datadog, atau staging + production vendor. Di collector, cukup daftarkan beberapa exporter dalam satu pipeline:

Fan-out ke dua backend

exporters:
  otlp/internal:
    endpoint: internal-backend:4317
    tls:
      insecure: true
  otlp/saas:
    endpoint: https://otlp.vendor.com:443
    auth:
      authenticator: oauth2clientcredential
 
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/internal, otlp/saas]

Satu trace mengalir ke dua backend sekaligus. Gunakan ini untuk: migrasi backend (uji backend baru sambil yang lama tetap aktif), redundancy, atau memenuhi kebutuhan tim berbeda.

Warning

Fan-out menggandakan semua biaya: storage, egress network, dan kuota vendor. Mulailah fan-out untuk satu sinyal (biasanya traces) sebelum menerapkannya ke semua. Beberapa vendor juga menerapkan pemisahan identitas yang membuat harga berbeda — hitung total cost of ownership sebelum fan-out permanen.

#Routing Per-Sinyal

Tidak semua backend harus menerima semua sinyal. Routing per-sinyal memanfaatkan satu pipeline per sinyal:

Routing per-sinyal

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/tempo]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [prometheusremotewrite/mimir]
    logs:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/loki]

Pola umum:

Traces → backend tracing khusus (Tempo, Jaeger, X-Ray).
Metrics → Prometheus/Mimir/Thanos.
Logs → Loki/Elasticsearch.

Routing ini memungkinkan tiap sinyal memakai backend terbaik tanpa harus seragam.

#Cloud Observability: Distro dan Endpoint OTLP

Tiga cloud besar menerima OTLP secara native — dan masing-masing punya distro collector resmi.

#AWS: ADOT (AWS Distro for OpenTelemetry)

ADOT adalah distribusi collector resmi AWS yang teruji untuk diintegrasikan dengan layanan AWS (X-Ray, CloudWatch, Managed Prometheus, EKS).

ADOT: AWS X-Ray + CloudWatch

exporters:
  awsxray:
    region: ap-southeast-1
  awsemf:
    region: ap-southeast-1
    namespace: myapp
 
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [awsxray]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [awsemf]

#Google Cloud: Google Cloud OTel

GCP menawarkan Google Cloud Managed Service for Prometheus dan Cloud Trace/Logging, menerima OTLP via collector googlecloud exporter:

Google Cloud exporter

exporters:
  googlecloud:
    project: my-gcp-project
    metric:
      prefix: custom.googleapis.com/otel

#Azure: Azure Monitor

Azure Monitor menerima OTLP dan memiliki distro collector resmi untuk Application Insights:

Azure Monitor exporter

exporters:
  azuremonitor:
    connection_string: ${env:AZURE_APPINSIGHTS_CONNECTION_STRING}

Tip

Karena semua cloud ini menerima OTLP, kalian bisa berpindah dari on-premise ke cloud, atau antar-cloud, tanpa mengubah instrumentasi aplikasi — hanya mengubah config exporter collector. Inilah nilai jual paling konkret dari vendor-neutrality OTel.

#Strategi Multi-Vendor & Migrasi

#Kapan Multi-Vendor Masuk Akal

Redundancy kritis — observability itu sendiri harus survive (lapis kedua vendor).
Tim berbeda, kebutuhan berbeda — platform engineering vs security.
Transisi vendor — periode paralel sebelum cut-over.

#Kapan Tidak

Untuk alasan politik saja — biaya menggandakan tanpa nilai operasional.
Tanpa anggaran jelas — fan-out selalu berbiaya.

#Pola Migrasi Aman

Mulai kirim salinan ke backend baru (fan-out, satu sinyal).
Validasi kelengkapan & biaya di backend baru selama beberapa minggu.
Alihkan primary traffic, nonaktifkan backend lama secara bertahap.
Setelah masa cut-off, matikan exporter lama dan hapus config.

#Common Pitfalls

Fan-out tanpa perhitungan biaya — menggandakan storage dan egress tanpa sadar.
Routing per-sinyal mengirim sinyal ke backend yang tidak memahaminya — cek kompatibilitas exporter-backend.
ADOT/cloud exporter dengan permission salah — data ditolak diam-diam; verifikasi IAM/Service Account.
Config multi-backend tanpa observasi collector — tidak tahu mana exporter yang gagal; pantau metric per-exporter.

#Penutup

Pada episode 20 ini, kalian telah menguasai multi-backend dan cloud observability.

Inti yang harus dibawa pulang:

Fan-out mengirim satu data ke banyak backend — berguna untuk migrasi/redundansi, tetapi berbiaya.
Routing per-sinyal memilih backend terbaik per sinyal melalui satu pipeline OTLP.
Cloud besar menerima OTLP native: ADOT (AWS), googlecloud (GCP), azuremonitor (Azure).
Migrasi vendor = ubah config collector, bukan instrumentasi aplikasi — itulah kekuatan vendor-neutral.

Di episode 21 selanjutnya, kita masuk Fase 6 dan membahas GenAI & AI observability — semantic conventions GenAI OTel untuk span LLM/agent calls, tracing prompt/response, evaluasi (evals), serta instrumentasi SDK OpenAI/LangChain dan korelasinya dengan aplikasi. Sampai jumpa di episode 21!