Observabilitas Sistem Terdistribusi Menggunakan Prometheus, Grafana, dan OpenTelemetry

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern yang menuntut ketersediaan tinggi (high availability) dan latensi rendah, sistem terdistribusi (distributed systems) telah menjadi standar emas. Namun, kompleksitas yang menyertainya meningkat secara eksponensial. Ketika sebuah aplikasi web monolitik dipecah menjadi arsitektur microservices—didukung oleh backend Go dan Node.js, web server Nginx dan Caddy, sistem antrian (message queues) seperti RabbitMQ atau Redis, serta database terdistribusi—pelacakan kegagalan menjadi mimpi buruk bagi seorang Site Reliability Engineer (SRE) dan Backend Engineer.

Bottleneck Performa dan Keamanan di Dunia Nyata

Di lingkungan produksi berskala besar, masalah performa jarang terjadi di satu titik tunggal. Bottleneck sering kali tersembunyi di balik:

1. Keterlambatan Jaringan Antar-Layanan (Network Latency & Cascade Failures): Permintaan HTTP yang masuk melalui Cloudflare CDN dan WAF, melewati Nginx Reverse Proxy, diteruskan ke Node.js API Gateway, lalu memanggil backend Go, dan berujung pada query MySQL atau operasi Redis.
2. Kelebihan Beban Sumber Daya (Resource Exhaustion): Ketiadaan visibilitas terhadap konsumsi memori PHP-FPM, thread pool web server, atau koneksi pool database dapat menyebabkan kegagalan sistem total (out-of-memory crashes).
3. Isolasi Log dan Metrik: Debugging secara manual menggunakan perintah tail -f pada file log masing-masing server secara terpisah tidak lagi efektif untuk mendiagnosis latensi end-to-end.

Perbandingan Kondisi: Sebelum vs Sesudah Penerapan Observabilitas

[!IMPORTANT] Observabilitas bukan sekadar pengumpulan log (logging) atau pemantauan (monitoring). Observabilitas adalah kemampuan untuk memahami kondisi internal sistem hanya dengan memeriksa output eksternalnya, memadukan metrik (Metrics), log (Logs), dan tracing (Traces) secara terpadu.

2. Konteks Inti & Deep Dive Arsitektur

Sistem observabilitas enterprise yang tangguh dibangun di atas tiga pilar utama (Three Pillars of Observability): Metrik, Log, dan Tracing. Dalam ekosistem modern, OpenTelemetry (OTel) bertindak sebagai standar tunggal untuk instrumentasi, pengumpulan, dan ekspor data telemetri. Sementara itu, Prometheus mengumpulkan dan menyimpan metrik berbasis time-series, dan Grafana menyajikan visualisasi data serta manajemen alerting.

Alur Data dan Eksekusi (Under the Hood)

Diagram alur arsitektur pengumpulan data dari edge hingga penyimpanan:

[ Client / Browser ]
         │
         ▼ (HTTPS)
[ Cloudflare CDN / WAF ]
         │
         ▼
[ Nginx / Caddy Reverse Proxy ] ──(Metrics / Stub Status)──┐
         │                                                  │
         ├──────────────────────────────┐                   │
         ▼                              ▼                   ▼
[ Node.js / Go Backend ]    [ PHP-FPM / Laravel ]  [ Prometheus Server ]
 (OpenTelemetry SDK)         (OpenTelemetry SDK)    (Scrapes / Pulls Metrics)
         │                              │                   │
         └──────────────┬───────────────┘                   │
                        ▼                                   ▼
               [ OTel Collector ] ──────────────────► [ Grafana Dashboard ]
               (Receives Traces/Logs)                 (Visualizes Metrics & Traces)
                        │
                        ▼
               [ Tempo / Jaeger ] (Distributed Tracing Storage)

1. Instrumentasi Aplikasi: Aplikasi backend (Node.js, Go, PHP) menggunakan OpenTelemetry SDK untuk menyisipkan trace context (W3C Trace Context) pada setiap HTTP request yang masuk.
2. Pengumpulan Data (Collector): OpenTelemetry Collector menerima data traces dan metrics dari berbagai sumber, melakukan proses batching, pembersihan (sanitization), lalu meneruskannya ke backend penyimpanan.
3. Scraping Metrik: Prometheus secara berkala melakukan pull (mengambil data) dari endpoint /metrics yang diekspos oleh aplikasi, Nginx, Node Exporter, dan OTel Collector.
4. Visualisasi: Grafana membaca sumber data dari Prometheus (untuk metrik) dan Jaeger/Tempo (untuk tracing) guna menampilkan dashboard terpadu.

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam merancang sistem telemetri, arsitek sering kali dihadapkan pada pilihan alat pengumpul dan protokol transmisi. Berikut adalah analisis komparatif pendekatan pengumpulan data:

[!TIP] Gunakan Prometheus untuk metrik sistem dan kesehatan infrastruktur (CPU, RAM, Network I/O), dan gunakan OpenTelemetry Collector bersama Grafana Tempo khusus untuk distributed tracing dan korelasi log.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melakukan instalasi, pastikan infrastruktur memenuhi spesifikasi standar enterprise berikut:

Spesifikasi Minimum Hardware

• OS: Ubuntu 22.04 LTS / Debian 12 (Kernel Linux >= 5.15)
• CPU: 4 vCPU
• RAM: 8 GB
• Storage: 100 GB SSD (NVMe sangat disarankan untuk performa Prometheus TSDB)

Dependensi dan Hak Akses

• Docker & Docker Compose (v2.20+)
• Akses sudo atau root pada server
• Port firewall yang harus dibuka:
  • 9090 (Prometheus)
  • 3000 (Grafana)
  • 4317 (OTLP gRPC Receiver)
  • 4318 (OTLP HTTP Receiver)
  • 9100 (Node Exporter)

Verifikasi awal sistem operasi:

sysctl -n vm.max_map_count
# Jika hasilnya di bawah 262144, ubah secara permanen:
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

5. Panduan Implementasi Langkah demi Langkah

Implementasi penuh akan menggunakan Docker Compose untuk menjalankan stack observabilitas secara modular dan terisolasi.

Langkah 1: Struktur Direktori Proyek

Buat direktori kerja untuk infrastruktur observabilitas:

mkdir -p /opt/observability/{prometheus,grafana/provisioning/datasources,grafana/provisioning/dashboards,otel-collector}
cd /opt/observability

Langkah 2: Konfigurasi Prometheus (prometheus/prometheus.yml)

Buat file konfigurasi Prometheus untuk melakukan scraping metrik dari Node Exporter dan OTel Collector:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

alerting:
  alertmanagers:
    - static_configs:
        - targets: []

rule_files:
  - "alert.rules.yml"

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter:9100']

  - job_name: 'otel-collector'
    static_configs:
      - targets: ['otel-collector:8889']

Langkah 3: Konfigurasi OpenTelemetry Collector (otel-collector/otel-collector-config.yml)

Konfigurasi collector untuk menerima data OTLP dan mengekspornya ke Prometheus:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 1s
    limit_percentage: 80
    spike_limit_percentage: 20
  batch:
    send_batch_size: 8192
    timeout: 1s
    send_batch_max_size: 10240

exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
    namespace: "otel"
  logging:
    verbosity: detailed

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [prometheus, logging]
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [logging]

Langkah 4: Provisioning Grafana DataSource (grafana/provisioning/datasources/datasource.yml)

Otomatisasi penyambungan Prometheus ke Grafana:

apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    orgId: 1
    url: http://prometheus:9090
    isDefault: true
    editable: false
    jsonData:
      httpMethod: POST
      timeInterval: 15s

Langkah 5: Deployment dengan Docker Compose (docker-compose.yml)

Gabungkan seluruh layanan dalam satu file orkestrasi:

version: '3.8'

networks:
  observability-net:
    driver: bridge

services:
  prometheus:
    image: prom/prometheus:v2.45.0
    container_name: prometheus
    restart: unless-stopped
    volumes:
      - ./prometheus:/etc/prometheus
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.console.libraries=/usr/share/prometheus/console_libraries'
      - '--web.console.templates=/usr/share/prometheus/consoles'
    ports:
      - "9090:9090"
    networks:
      - observability-net

  node-exporter:
    image: prom/node-exporter:v1.6.0
    container_name: node-exporter
    restart: unless-stopped
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - '--path.procfs=/host/proc'
      - '--path.sysfs=/host/sys'
      - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)$$'
    ports:
      - "9100:9100"
    networks:
      - observability-net

  otel-collector:
    image: otel/opentelemetry-collector-contrib:0.83.0
    container_name: otel-collector
    restart: unless-stopped
    volumes:
      - ./otel-collector/otel-collector-config.yml:/etc/otelcol/config.yaml
    command: ["--config=/etc/otelcol/config.yaml"]
    ports:
      - "4317:4317"
      - "4318:4318"
      - "8889:8889"
    networks:
      - observability-net

  grafana:
    image: grafana/grafana:10.1.0
    container_name: grafana
    restart: unless-stopped
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=securepassword123
      - GF_USERS_ALLOW_SIGN_UP=false
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning
    ports:
      - "3000:3000"
    networks:
      - observability-net

volumes:
  prometheus_data:
    :
  grafana_data:
    :

Jalankan stack menggunakan perintah:

docker compose up -d

6. Bedah Kode & Penjelasan Detail Baris Kunci

• scrape_interval: 15s (Prometheus Config): Menentukan seberapa sering Prometheus menarik metrik dari target. Interval 15 detik adalah standar optimal yang menyeimbangkan antara akurasi data real-time dan beban I/O disk penyimpanan TSDB.
• memory_limiter (OTel Collector Config): Fitur pengaman krusial. Jika Collector mengalami lonjakan traffic tracing, prosesor ini secara otomatis membatasi penggunaan memori hingga 80% untuk mencegah Out-Of-Memory (OOM) Killer mematikan container secara paksa.
• --path.rootfs=/rootfs (Node Exporter): Memungkinkan Node Exporter membaca metrik sistem filesystem host Linux secara akurat melalui mount volume kontainer.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Kasus: Menangani Lonjakan Traffic Flash Sale E-Commerce

Pada sistem e-commerce berkapasitas tinggi, lonjakan 50.000 request per detik pada backend Go dan Redis dapat menyebabkan kehabisan koneksi database MySQL.

1. Deteksi Dini: Grafana memicu alert melalui Prometheus saat persentase error HTTP 5xx pada Nginx melebihi 1% selama 3 menit berturut-turut.
2. Tracer Analysis: Melalui OpenTelemetry, SRE melacak trace ID pada header HTTP respons untuk melihat bahwa latensi tertinggi terjadi pada fungsi query Redis yang mengalami antrian panjang (connection pool exhaustion).
3. Mitigasi Cepat: Tim SRE segera menambah kapasitas replica Redis dan melakukan penyesuaian parameter max_connections pada pool aplikasi backend tanpa harus menebak-nebak letak masalah.

8. Common Pitfalls, Anti-Patterns & Solusi

• Anti-Pattern 1: High Cardinality Metrics. Menggunakan label Prometheus yang nilainya unik tanpa batas (seperti user_id atau request_url dengan parameter dinamis).
  • Dampak: Meledaknya ukuran TSDB, mengakibatkan memori penuh dan Prometheus crash.
  • Solusi: Batasi label hanya pada dimensi dengan kardinalitas rendah (seperti status_code, method, service_name).
• Anti-Pattern 2: Mengabaikan Retention Policy. Membiarkan data metrik tersimpan selamanya.
  • Solusi: Tambahkan flag --storage.tsdb.retention.time=15d pada konfigurasi Prometheus untuk menghapus data lama secara otomatis.

9. Benchmark, Metrik Kinerja & Tuning Performa

Lakukan pengujian beban menggunakan tool benchmark k6 untuk memastikan kestabilan sistem observabilitas di bawah tekanan:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '30s', target: 500 },
    { duration: '1m', target: 2000 },
    { duration: '30s', target: 0 },
  ],
};

export default function () {
  const res = http.get('http://localhost:8080/api/v1/products');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 200ms': (r) => r.timings.duration < 200,
  });
  sleep(1);
}

Hasil Analisis & Tuning: Jika pemakaian CPU Prometheus melonjak di atas 80% saat beban puncak, lakukan tuning pada indeks chunk TSDB atau tingkatkan sumber daya alokasi CPU container.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum merilis sistem observabilitas ke lingkungan produksi live, pastikan seluruh item dalam checklist berikut terpenuhi:

• Konfigurasi keamanan Grafana mengubah password default (admin).
• Pembatasan akses port Prometheus dan OTel Collector menggunakan Firewall (UFW/iptables) atau VPC internal.
• Kebijakan retensi penyimpanan (retention period) metrik dan log telah ditetapkan.
• Pengujian failover pada OTel Collector dan Prometheus berhasil dilakukan.
• Integrasi sistem alerting (Alertmanager ke Slack/PagerDuty) aktif dan teruji.

Dengan mengintegrasikan Prometheus, Grafana, dan OpenTelemetry secara tepat, organisasi Anda tidak hanya sekadar memantau sistem, melainkan membangun fondasi rekayasa keandalan yang proaktif, aman, dan siap menghadapi skala enterprise modern.