Implementasi Observability Stack Terpadu Menggunakan Prometheus, Grafana, dan OpenTelemetry

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap infrastruktur web modern yang mendistribusikan beban kerja di atas arsitektur mikrolayanan, container, dan edge network, pemantauan kesehatan sistem tidak lagi cukup hanya dengan melihat metrik CPU dan penggunaan RAM yang sederhana. Ketika sebuah request HTTP masuk melalui Cloudflare CDN, melewati Nginx reverse proxy, diteruskan ke backend Go atau PHP-FPM, berinteraksi dengan Redis caching layer, dan melakukan query ke kluster MySQL, kegagalan di salah satu titik kecil saja dapat memicu efek domino yang melumpuhkan seluruh aplikasi.

Bottleneck performa klasik di dunia nyata sering kali tersembunyi di balik latensi I/O database yang lambat, cache stampede pada Redis, konfigurasi connection pool PHP-FPM yang jenuh, atau kegagalan resolusi DNS dan SPF/DKIM pada pengiriman email via Postfix. Tanpa observability stack yang terpadu, tim DevOps dan SRE terjebak dalam posisi reaktif: menunggu keluhan pengguna melalui media sosial atau tiket dukungan sebelum menyadari adanya degradasi sistem.

Perbandingan Kondisi Sebelum vs Sesudah Penerapan

2. Konsep Inti & Deep Dive Arsitektur

Pendekatan modern terhadap observability bertumpu pada Three Pillars of Observability: Metrik (apa yang rusak), Log (mengapa itu rusak), dan Traces (di mana letak kerusakannya di dalam alur eksekusi sistem terdistribusi). OpenTelemetry (OTel) hadir sebagai standar industri tunggal yang menyatukan spesifikasi dan perangkat pengumpulan data (collector) untuk ketiga pilar ini.

Alur Data dan Arsitektur Eksekusi

[Client / Browser] 
       │
       ▼
[Cloudflare Edge / WAF] 
       │
       ▼
[Nginx Reverse Proxy] (Mengekspor metrik via nginx-prometheus-exporter)
       │
       ├──────────────┬──────────────┐
       ▼              ▼              ▼
[Backend Go]    [PHP-FPM]     [Node.js WebSocket]
(OTel SDK)      (OTel SDK)    (OTel SDK)
       │              │              │
       └──────────────┼──────────────┘
                      ▼
            [OpenTelemetry Collector]
                      │
          ┌───────────┴───────────┐
          ▼                       ▼
   [Prometheus TSDB]      [Tracing Backend / Jaeger]
          │
          ▼
   [Grafana Dashboard & Alerting]

1. Instrumentation: Aplikasi web (Go, PHP, Node.js) dan layanan infrastruktur (Nginx, MySQL, Redis, Postfix) ditanamkan OpenTelemetry SDK atau exporter khusus untuk menghasilkan sinyal telemetri.
2. Collection: OpenTelemetry Collector menerima, memproses, melakukan batching, dan merutekan data telemetri ke penyimpanan backend yang sesuai.
3. Storage & Query: Prometheus bertindak sebagai Time-Series Database (TSDB) untuk metrik, sementara Grafana melakukan query ke Prometheus dan sumber data lainnya untuk visualisasi real-time.

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam membangun stack pemantauan, terdapat beberapa pendekatan arsitektural yang umum digunakan di industri enterprise. Tabel berikut menyajikan analisis komparatif mendalam:

[!WARNING] Penggunaan ELK Stack murni untuk metrics dan traces sangat tidak disarankan karena konsumsi memori Elasticsearch yang masif dan tidak dioptimalkan untuk penyimpanan time-series numerik murni dibandingkan Prometheus.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melakukan instalasi stack, pastikan infrastruktur memenuhi spesifikasi minimal berikut agar berjalan stabil pada beban produksi:

• OS: Ubuntu 22.04 LTS / Debian 12 Bookworm (Fresh Install)
• Hardware Minimal: 4 vCPU, 8 GB RAM, 80 GB NVMe SSD Storage
• Network: Akses internet untuk mengunduh binary dan dependensi, serta port firewall yang terbuka (9090 untuk Prometheus, 3000 untuk Grafana, 4317/4318 untuk OTel Collector).

Verifikasi Awal dan Persiapan Sistem

Jalankan perintah berikut pada terminal untuk menyiapkan system user khusus dan direktori penyimpanan:

sudo groupadd --system prometheus
sudo useradd -s /sbin/nologin --system -g prometheus prometheus
sudo mkdir -p /var/lib/prometheus /etc/prometheus
sudo chown -R prometheus:prometheus /var/lib/prometheus /etc/prometheus

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Instalasi dan Konfigurasi Prometheus

Unduh dan pasang binary resmi Prometheus:

VERSION="2.48.0"
curl -LO https://github.com/prometheus/prometheus/releases/download/v${VERSION}/prometheus-${VERSION}.linux-amd64.tar.gz
tar xvf prometheus-${VERSION}.linux-amd64.tar.gz
sudo cp prometheus-${VERSION}.linux-amd64/prometheus /usr/local/bin/
sudo cp prometheus-${VERSION}.linux-amd64/promtool /usr/local/bin/
sudo chown prometheus:prometheus /usr/local/bin/prometheus /usr/local/bin/promtool

Buat file konfigurasi /etc/prometheus/prometheus.yml yang valid dan siap produksi:

global:
  scrape_interval: 15s
  evaluation_interval: 15s
  external_labels:
    environment: "production"
    datacenter: "id-jakarta-01"

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['localhost:9093']

rule_files:
  - "/etc/prometheus/alert_rules.yml"

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

  - job_name: 'node_exporter'
    static_configs:
      - targets: ['localhost:9100']

  - job_name: 'nginx'
    static_configs:
      - targets: ['localhost:9113']

  - job_name: 'otel_collector'
    static_configs:
      - targets: ['localhost:8889']

  - job_name: 'backend_go_app'
    metrics_path: '/metrics'
    static_configs:
      - targets: ['localhost:8080']

Buat systemd service untuk Prometheus di /etc/systemd/system/prometheus.service:

[Unit]
Description=Prometheus Time-Series Database
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus/ \
  --web.listen-address=0.0.0.0:9090 \
  --web.enable-lifecycle

[Install]
WantedBy=multi-user.target

Aktifkan dan jalankan layanan:

sudo systemctl daemon-reload
sudo systemctl enable prometheus
sudo systemctl start prometheus

Langkah 2: Konfigurasi OpenTelemetry Collector

Instal OpenTelemetry Collector Contrib:

OTEL_VERSION="0.91.0"
curl -LO https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/v${OTEL_VERSION}/otelcol-contrib_${OTEL_VERSION}_linux_amd64.tar.gz
tar xvf otelcol-contrib_${OTEL_VERSION}_linux_amd64.tar.gz
sudo cp otelcol-contrib /usr/local/bin/otelcol-contrib
sudo chown root:root /usr/local/bin/otelcol-contrib

Buat file konfigurasi /etc/otelcol/config.yaml:

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

processors:
  batch:
    send_batch_size: 1024
    timeout: 1s
  memory_limiter:
    check_interval: 1s
    limit_percentage: 75
    spike_limit_percentage: 20

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]

Buat systemd service untuk OTel Collector di /etc/systemd/system/otelcol.service:

[Unit]
Description=OpenTelemetry Collector Contrib
After=network.target

[Service]
User=root
ExecStart=/usr/local/bin/otelcol-contrib --config=/etc/otelcol/config.yaml
Restart=always

[Install]
WantedBy=multi-user.target

Jalankan layanan:

sudo systemctl daemon-reload
sudo systemctl enable otelcol
sudo systemctl start otelcol

Langkah 3: Instalasi Grafana dan Provisioning

Tambahkan repository resmi Grafana dan instal:

sudo apt-get install -y apt-transport-https software-properties-common wget
sink="https://apt.grafana.com"
wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor | sudo tee /etc/apt/keyrings/grafana.gpg > /dev/null
echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | sudo tee /etc/sources.list.d/grafana.list
sudo apt-get update
sudo apt-get install -y grafana
sudo systemctl enable grafana-server
sudo systemctl start grafana-server

Konfigurasi otomatis data source Prometheus di /etc/grafana/provisioning/datasources/prometheus.yml:

apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://localhost:9090
    isDefault: true
    editable: false

6. Bedah Kode & Penjelasan Detail Baris Kunci

• --web.enable-lifecycle pada systemd Prometheus: Memungkinkan eksekusi hot reload konfigurasi melalui HTTP POST ke endpoint /-/reload tanpa harus melakukan restart proses Prometheus yang dapat menghentikan pengumpulan data sementara.
• memory_limiter pada konfigurasi OTel Collector: Pengaturan krusial untuk mencegah Out-Of-Memory (OOM) Killer sistem operasi mengambil alih saat terjadi lonjakan trafik traces yang masif. Parameter limit_percentage: 75 memastikan collector segera melakukan drop atau throttle jika penggunaan RAM melewati batas aman 75%.
• scrape_interval: 15s: Interval waktu standar industri untuk menarik metrik dari target. Nilai di bawah 10 detik dapat membebani CPU target dan meningkatkan ukuran TSDB secara drastis, sementara di atas 30 detik membuat deteksi anomali menjadi lambat.

7. Skenario Produksi & Studi Kasus Dunia Nyata

[!TIP] Pada lingkungan kluster produksi dengan lebih dari 50 microservices, hindari melakukan direct scraping dari satu instance Prometheus tunggal. Gunakan pola Prometheus Federation atau Thanos / Cortex untuk melakukan long-term storage dan desentralisasi scraping.

Studi Kasus: E-commerce Flash Sale dengan 50.000 Request Per Detik (RPS).

• Masalah: Terjadi lonjakan latensi pada backend Go yang terkoneksi ke Redis dan MySQL, namun tim SRE kesulitan menentukan apakah masalah berasal dari jaringan, lock contention di database, atau thread pool Redis.
• Solusi: Menggunakan OpenTelemetry SDK pada aplikasi Go untuk menyisipkan trace context ke setiap header HTTP. Saat request masuk, OTel Collector menangkap spans dari HTTP handler, panggilan Redis client, dan driver MySQL. Grafana menampilkan korelasi langsung antara latensi HTTP 99th percentile dengan tingginya queue time pada Redis.

8. Common Pitfalls, Anti-Patterns & Solusi

1. High Cardinality Trap: Menggunakan label Prometheus dengan nilai unik yang tak terbatas (seperti user_id, email, atau uuid dari request HTTP).
   • Solusi: Batasi penggunaan label hanya untuk dimensi dengan kardinalitas rendah seperti status_code, method, endpoint_group, atau region.
2. Kurangnya Retensi dan Ukuran Disk yang Tidak Terencana: TSDB Prometheus membengkak tanpa batas.
   • Solusi: Selalu tetapkan flag --storage.tsdb.retention.time=15d dan --storage.tsdb.retention.size=50GB pada systemd service.
3. Mengabaikan Health Check Collector: OTel collector mati tanpa ada metrik pemantau.
   • Solusi: Aktifkan internal telemetry pada OTel collector dengan mengekspor metrik internal ke port terpisah.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk menguji ketahanan stack observability yang dibangun, jalankan pengujian beban menggunakan perangkat k6 terhadap endpoint aplikasi web sambil memantau penggunaan sumber daya Prometheus dan OTel Collector.

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

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

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

Analisis hasil benchmark melalui Grafana untuk memastikan bahwa penambahan middleware OpenTelemetry tidak menambahkan latensi (overhead) lebih dari 2ms pada setiap siklus eksekusi request HTTP.

10. Checklist Penerapan Produksi & Kesimpulan

Gunakan checklist berikut sebelum merilis observability stack ke lingkungan produksi utama:

• Semua file konfigurasi systemd, Prometheus, dan OTel Collector memiliki hak akses (permission) yang ketat.
• Firewall (UFW/Firewalld) membatasi akses port 9090 dan 3000 hanya dari IP internal atau VPN bastion host.
• Retensi data TSDB Prometheus telah dikonfigurasi untuk mencegah kepenuhan disk.
• Alerting rules telah diuji secara fungsional melalui simulasi pemadaman layanan (Chaos Engineering).
• Dashboard Grafana telah di-backup menggunakan provisioning files berbasis Git version control.

Dengan menerapkan arsitektur observability terpadu menggunakan Prometheus, Grafana, dan OpenTelemetry secara disiplin, tim teknik Anda bertransformasi dari penanganan insiden yang reaktif menjadi pengelola infrastruktur web yang proaktif, tangguh, dan berbasis data.