1. Pengenalan OpenTelemetry
OpenTelemetry (OTel) adalah framework open-source untuk observability — mengumpulkan, memproses, dan mengekspor telemetry data (traces, metrics, dan logs) dari aplikasi. OpenTelemetry adalah project CNCF (Cloud Native Computing Foundation) dengan kontribusi dari Google, Microsoft, Amazon, dan banyak perusahaan teknologi besar lainnya.
Sebelum OpenTelemetry, developer harus memilih vendor proprietary untuk observability — Datadog, New Relic, Dynatrace, dll. Setiap vendor memiliki SDK sendiri yang tidak kompatibel satu sama lain. OpenTelemetry mengubah ini dengan menyediakan standard universal yang bisa digunakan dengan backend apapun.
OpenTelemetry adalah merger dari dua project sebelumnya: OpenTracing (API standar untuk tracing) dan OpenCensus (SDK untuk metrics dan tracing). OTel menggabungkan yang terbaik dari keduanya menjadi satu standar unified yang mencakup traces, metrics, dan logs.
Mengapa OpenTelemetry?
| Keunggulan | Penjelasan |
|---|---|
| Vendor Neutral | Standard universal — bisa export ke backend apapun (Jaeger, Prometheus, Grafana, Datadog, dll) |
| Multi-language | SDK tersedia untuk 11+ bahasa — Java, Python, Go, JavaScript, .NET, Rust, Swift, dll |
| CNCF Project | Didukung oleh perusahaan besar — dijamin long-term sustainability |
| Auto-instrumentation | Instrumentasi otomatis untuk framework populer — minimal code changes |
| Traces + Metrics + Logs | Satu framework untuk semua tipe telemetry data |
| W3C Standard | Trace context propagation mengikuti standar W3C |
| Correlation | Otomatis mengkorelasikan traces, metrics, dan logs |
| Production Ready | Digunakan oleh perusahaan besar di production |
OpenTelemetry vs Alternatif
| Fitur | OpenTelemetry | Datadog | New Relic |
|---|---|---|---|
| Harga | 🟢 Open-source | 🔴 Paid (mahal) | 🟡 Free tier + paid |
| Vendor Lock-in | 🟢 Tidak ada | 🔴 Terikat vendor | 🟡 Sedang |
| Data Ownership | 🟢 Full control | 🔴 Di server vendor | 🟡 Sebagian |
| Setup | 🟡 Lebih kompleks | 🟢 Sangat mudah | 🟢 Mudah |
| Backend | 🔴 Perlu setup sendiri | 🟢 Managed | 🟢 Managed |
| Standardisasi | 🟢 CNCF Standard | 🔴 Proprietary | 🟡 Sebagian |
2. Tiga Pilar Observability
OpenTelemetry mencakup tiga pilar observability yang saling terkorelasi:
3. Arsitektur OpenTelemetry
Komponen Utama
| Komponen | Fungsi |
|---|---|
| API | Interface yang digunakan aplikasi untuk membuat spans, metrics, dan logs. Stabil dan tidak berubah |
| SDK | Implementasi dari API — processing, sampling, export. Bisa dikonfigurasi |
| Collector | Proxy yang menerima, memproses, dan mengekspor telemetry data. Bisa di-deploy sebagai agent atau gateway |
| Instrumentation Libraries | Library yang otomatis instrumentasi framework populer (Express, Flask, Spring, dll) |
| Exporters | Kirim data ke backend (Jaeger, Prometheus, Grafana Tempo, Datadog, dll) |
| Context Propagation | Menyebarluaskan trace context antar service (W3C TraceContext, Baggage) |
Data Flow
Implementasi Tracing di Node.js
flowchart TD
subgraph agent["🔧 Agent Mode (per host)"]
A1["App 1] --> CA[OTel Collector\nAgent"]
A2[App 2] --> CA
A3[App 3] --> CA
CA -->|Forward| GW
end
subgraph gateway["🏭 Gateway Mode (centralized)"]
GW["OTel Collector\nGateway"] --> J[Jaeger]
GW --> P[Prometheus]
GW --> G[Grafana]
GW --> L[Loki]
end
style agent fill:#0f2a1f,stroke:#3ecf8e,stroke-width:2px
style gateway fill:#0f1d3a,stroke:#60a5fa,stroke-width:2px
style GW fill:#2a1f0a,stroke:#f59e0b,stroke-width:2px
11. Best Practices
| Best Practice | Detail |
|---|---|
| Load OTel First | Selalu import/setup OpenTelemetry SEBELUM import library lain — agar auto-instrumentation bisa meng-hook library |
| Resource Attributes | Set service.name, service.version, deployment.environment di semua service |
| Sampling | Gunakan sampling untuk production — jangan trace 100% request. Gunakan tail-based sampling untuk mempertahankan traces error |
| OTLP Protocol | Gunakan OTLP (OpenTelemetry Protocol) sebagai default exporter — paling efisien dan universal |
| Collector | Selalu gunakan OTel Collector sebagai perantara — decouple app dari backend |
| Batch Processor | Gunakan batch processor untuk mengurangi jumlah export calls |
| Semantic Conventions | Gunakan OTel semantic conventions untuk attribute names — konsisten antar service |
| Graceful Shutdown | Panggil sdk.shutdown() saat SIGTERM untuk flush semua data yang belum ter-export |
| Cardinality | Hindari metric attributes dengan cardinality tinggi (misalnya user_id) — bisa memakan banyak memori |
| Context Propagation | Pastikan trace context di-propagate ke semua service calls — HTTP headers, message queue headers |
Mulai dengan auto-instrumentation untuk mendapatkan visibility cepat tanpa banyak code changes. Setelah terbiasa, tambahkan manual instrumentation untuk business-critical paths yang memerlukan detail lebih. Gunakan Grafana + Prometheus + Jaeger + Loki sebagai stack observability open-source yang lengkap.
Hati-hati dengan high cardinality attributes pada metrics — atribut seperti user_id atau request_id bisa menghasilkan jutaan time series yang memakan banyak memori di Prometheus. Simpan high-cardinality data di traces dan logs, bukan di metrics.
12. Quiz Pemahaman
📝 Quiz: Pemahaman OpenTelemetry
1. Apa tiga pilar observability yang dicakup OpenTelemetry?
2. Apa itu "span" dalam distributed tracing?
3. Mengapa OpenTelemetry lebih baik dari vendor proprietary?
4. Apa fungsi OpenTelemetry Collector?
5. Apa itu "auto-instrumentation" di OpenTelemetry?