Observability Skala Enterprise: Integrasi Prometheus, Grafana, dan OpenTelemetry

1. Konteks Industri & Analisis Akar Masalah

Di era infrastruktur modern berbasis microservices dan arsitektur cloud-native, kompleksitas sistem web telah melonjak secara eksponensial. Sebuah permintaan (request) HTTP tunggal yang masuk ke edge caching Cloudflare dapat melewati WAF, memicu DNS lookup, diteruskan ke reverse proxy Nginx, mengantre di Redis queue, dieksekusi oleh PHP-FPM atau Go backend, dan akhirnya membaca/menulis ke kluster MySQL atau MinIO object storage. Ketika terjadi degradasi performa atau outage, mengandalkan log tradisional yang tersebar (scattered logs) adalah resep kegagalan.

Bottleneck Performa dan Keamanan Umum

1. Blind Spots di Layer Aplikasi: Backend merespons dalam 3ms, namun database query memakan waktu 400ms tanpa ada jejak distributed tracing yang mengaitkan keduanya.
2. Keterbatasan Prometheus Polling: Metrik berbasis pull standar sering kali gagal menangkap lonjakan trafik mikro (spikes) berdurasi di bawah interval scrape (biasanya 15 detik).
3. Isolasi Telemetri: Metrik, log, dan trace dikelola dalam sistem terpisah yang tidak saling terhubung, memaksa SRE melakukan context switching manual saat investigasi insiden.

Sebelum vs Sesudah Penerapan Observability Terpusat

• Sebelum: Deteksi masalah bergantung pada laporan pengguna akhir (customer complaints). Proses debugging membutuhkan waktu berjam-jam untuk grep ribuan baris file log Nginx, PHP, dan MySQL secara manual.
• Sesudah: Sistem memberikan peringatan dini (early warning alerts) otomatis ke kanal PagerDuty/Slack dalam hitungan detik sebelum pengguna merasakan dampak. Drill-down dari metrik anomali ke trace spesifik dan log baris kode terkait dapat dilakukan secara instan melalui satu kaca mata tunggal (single pane of glass) di Grafana.

2. Konsep Inti & Deep Dive Arsitektur

Untuk membangun ekosistem observability skala enterprise, kita membutuhkan tiga pilar utama: Metrics (Prometheus), Logs (Loki/Elastic), dan Traces (OpenTelemetry Collector).

Alur Eksekusi Telemetri Under the Hood

OpenTelemetry (OTel) bertindak sebagai agen pemersatu standar industri. Aplikasi backend (Go/Node/PHP) menghasilkan traces dan metrics menggunakan OTel SDK. Data ini dikirim ke OpenTelemetry Collector menggunakan protokol OTLP (gRPC/HTTP). Di dalam OTel Collector, data melewati tiga fase utama: Receivers (menerima data), Processors (melakukan batching, filtering, memory limiting), dan Exporters (meneruskan ke Prometheus, Jaeger, atau Loki).

[ Aplikasi (Go/PHP/Node) ] 
         │ (OTLP gRPC)
         ▼
┌─────────────────────────────────────────┐
│       OpenTelemetry Collector           │
│  [Receivers] ──> [Processors] ──> [Exporters] │
└────────────┬────────────────────────────┘
             │ (Prometheus Remote Write / OTLP)
             ▼
    ┌─────────────────┐         ┌─────────────────┐
    │   Prometheus    │         │     Grafana     │
    │ (Time-Series DB)│◄────────│ (Visualization) │
    └─────────────────┘         └─────────────────┘

3. Perbandingan Komparatif / Analisis Pendekatan

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melakukan instalasi, pastikan spesifikasi server minimal memenuhi standar production:

• OS: Ubuntu 22.04 LTS / Debian 12 Bookworm
• CPU/RAM: Minimal 4 vCPU, 8 GB RAM (untuk node collector dan database)
• Port yang Harus Dibuka:
  • 9090 (Prometheus)
  • 3000 (Grafana)
  • 4317 (OTLP gRPC)
  • 4318 (OTLP HTTP)

Persiapan Direktori dan Hak Akses

Jalankan perintah berikut di terminal untuk menyiapkan struktur direktori:

sudo mkdir -p /etc/otelcol /etc/prometheus /var/lib/prometheus
sudo useradd --no-create-home --shell /bin/false prometheus
sudo useradd --no-create-home --shell /bin/false otelcol

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Konfigurasi OpenTelemetry Collector (/etc/otelcol/config.yaml)

Buat file konfigurasi OTel Collector dengan isi lengkap berikut:

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

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

exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
    namespace: "enterprise"

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

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

global:
  scrape_interval: 15s
  evaluation_interval: 15s

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

rule_files:
  - "/etc/prometheus/alert.rules.yml"

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

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

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

Langkah 3: Aturan Peringatan Dini (/etc/prometheus/alert.rules.yml)

groups:
  - name: EnterpriseInfrastructureAlerts
    rules:
      - alert: HighCPUUsage
        expr: 100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle\