L
Observability & Monitoring • Literally Web ID

Observability & Enterprise Monitoring: Prometheus, Grafana, & Distributed Tracing

⏱️ 18 menit baca • 📅 14 Oct 2026 • 👁️ 1 views
Observability & Enterprise Monitoring: Prometheus, Grafana, & Distributed Tracing

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern yang mendistribusikan beban kerja di atas ribuan microservices, container Kubernetes, dan edge CDN seperti Cloudflare, kompleksitas infrastruktur telah meningkat secara eksponensial. Ketika sebuah aplikasi web mengalami lonjakan latensi atau kegagalan transaksi (Error 5xx), para Site Reliability Engineer (SRE) sering kali terjebak dalam masalah debugging yang reaktif. Sebelum penerapan sistem observabilitas yang komprehensif, tim infrastruktur hanya mengandalkan pemantauan dasar seperti pemeriksaan ping, penggunaan CPU server, dan log teks mentah (raw log) yang terfragmentasi di berbagai node.

Kondisi "Sebelum" (tanpa observabilitas mendalam):

  • Blind Spots Tinggi: Kegagalan koneksi internal antara PHP-FPM, Nginx, Redis, dan database MySQL hanya terdeteksi setelah pengguna melaporkan gangguan.
  • Mean Time to Resolution (MTTR) Panjang: Membutuhkan waktu berjam-jam bahkan berhari-hari untuk menelusuri akar masalah (root cause) karena kurangnya korelasi antara metrik, log, dan traces.
  • Kapasitas Reaktif: Penambahan kapasitas server dilakukan berdasarkan tebakan (guesstimate) saat server sudah mengalami out-of-memory (OOM) atau CPU throttling.

Kondisi "Sesudah" (dengan Prometheus, Grafana, dan OpenTelemetry):

  • Proaktif & Real-time: Sistem otomatis mendeteksi degradasi performa sebelum berdampak masif ke pengguna melalui alerting rules berbasis metrik tingkat lanjut.
  • Korelasi Terpadu: Metrik dari Prometheus divisualisasikan secara real-time di Grafana, sementara jejak transaksi mikrolayanan dilacak secara presisi menggunakan OpenTelemetry distributed tracing.
  • Kapasitas Berbasis Data: Keputusan penskalaan infrastruktur diambil berdasarkan tren metrik performa historis yang akurat.

2. Konsep Inti & Deep Dive Arsitektur

Observabilitas bukanlah sekadar mengumpulkan log atau memantau penggunaan RAM. Observabilitas didefinisikan oleh tiga pilar utama: Metrics (Metrik), Logs (Log), dan Traces (Jejak). Dalam ekosistem yang dibahas, Prometheus bertindak sebagai pengumpul metrik berbasis pull, Grafana sebagai lapisan visualisasi dan analisis, serta OpenTelemetry sebagai standar industri untuk pengumpulan metrik, log, dan traces terdistribusi.

+---------------------------------------------------------------------------------------+
|                                 KLIEN / PENGGUNA                                      |
+---------------------------------------------------------------------------------------+
                                           |
                                           v
+---------------------------------------------------------------------------------------+
|                                CLOUDFLARE CDN / WAF                                   |
+---------------------------------------------------------------------------------------+
                                           |
                                           v
+---------------------------------------------------------------------------------------+
|                             NGINX / CADDY WEB SERVER                                  |
|               (Mengekspos /metrics via Prometheus Node & Nginx Exporter)              |
+---------------------------------------------------------------------------------------+
         |                                         |                                  |
         v                                         v                                  v
+------------------+                    +--------------------+              +-------------------+
|  PHP-FPM / GO    |                    |  REDIS CACHE       |              | MYSQL / MARIADB   |
|  APPLICATION     |                    |  (Redis Exporter)  |              | (MySQL Exporter)  |
+------------------+                    +--------------------+              +-------------------+
         |
         +--- (OpenTelemetry SDK) ---> [ OTel Collector ] ---> [ Jaeger / Tempo ]
                                              |
                                              v
+---------------------------------------------------------------------------------------+
|                                  PROMETHEUS SERVER                                    |
|                          (Scrape Targets setiap 15 detik)                             |
+---------------------------------------------------------------------------------------+
                                           |
                                           v
+---------------------------------------------------------------------------------------+
|                                   GRAFANA DASHBOARD                                   |
|                         (Visualisasi, Alarms, & Unified Query)                        |
+---------------------------------------------------------------------------------------+

Alur data bekerja dengan cara Prometheus melakukan scraping (pengambilan data secara periodik melalui protokol HTTP) ke berbagai exporter yang terpasang di Nginx, PHP-FPM, Redis, MySQL, serta aplikasi Go/Node.js Anda. Secara paralel, SDK OpenTelemetry menyematkan trace context ke dalam setiap HTTP request masuk, melacak perjalanan transaksi dari web server, melalui antrean queue (Supervisor/Worker), hingga penyimpanan database.

3. Perbandingan Komparatif / Analisis Pendekatan

Berikut adalah analisis perbandingan mendalam antara pendekatan pemantauan tradisional melawan arsitektur observabilitas modern berbasis Prometheus & OpenTelemetry.

Parameter Perbandingan Pemantauan Tradisional (Log Monolitik + Nagios) Observabilitas Modern (Prometheus + Grafana + OTel)
Model Pengumpulan Data Push-based (Agent mengirim log/data ke server) Pull-based (Prometheus menarik data dari target)
Penyimpanan Metrik File teks datar / Database relasional konvensional Time-Series Database (TSDB) yang dioptimalkan tinggi
Debugging Latency Sangat sulit melacak bottleneck lintas mikrolayanan Sangat presisi menggunakan Distributed Tracing
Penggunaan Sumber Daya Konsumsi I/O disk tinggi akibat penulisan log masif Konsumsi memori efisien, penyimpanan terkompresi di TSDB
Skalabilitas Sulit diskalakan pada arsitektur ribuan kontainer Dirancang khusus untuk lingkungan cloud-native & Kubernetes
Overhead Jaringan Rendah namun butuh manajemen log rotasi yang rumit Terkontrol dengan interval scrape yang dapat disesuaikan

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum memulai implementasi, pastikan infrastruktur Anda memenuhi spesifikasi minimum dan dependensi berikut:

  • Sistem Operasi: Ubuntu Server 22.04 LTS / Debian 12 / RHEL 9 (Minimum 2 vCPU, 4GB RAM untuk server monitoring).
  • Hak Akses: Akses root atau pengguna dengan hak sudo.
  • Software Pendukung:
    • Docker & Docker Compose (Direkomendasikan untuk kemudahan deployment).
    • Prometheus versi terkini (v2.45.x atau lebih baru).
    • Grafana versi terkini (v10.x atau lebih baru).
    • Node Exporter, MySQL Exporter, Redis Exporter.

Verifikasi awal konektivitas jaringan antar server dan pastikan port-port berikut terbuka pada firewall (ufw / iptables):

  • Port 9090: Prometheus
  • Port 3000: Grafana
  • Port 9100: Node Exporter
  • Port 9113: Nginx Prometheus Exporter
  • Port 4317 & 4318: OpenTelemetry Collector

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Struktur Direktori & Konfigurasi Docker Compose

Buat direktori kerja untuk infrastruktur monitoring Anda di /opt/observability.

sudo mkdir -p /opt/observability/prometheus
sudo mkdir -p /opt/observability/grafana/provisioning/datasources
sudo mkdir -p /opt/observability/grafana/provisioning/dashboards
cd /opt/observability

Buat file docker-compose.yml dengan konfigurasi lengkap berikut:

version: '3.8'

networks:
  observability-net:
    driver: bridge

volumes:
  prometheus-data:
  grafana-data:

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

  grafana:
    image: grafana/grafana:10.2.2
    container_name: grafana
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=SecureAdminPassword2024!
      - GF_USERS_ALLOW_SIGN_UP=false
    volumes:
      - grafana-data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning
    networks:
      - observability-net
    depends_on:
      - prometheus

  node-exporter:
    image: prom/node-exporter:v1.7.0
    container_name: node-exporter
    restart: unless-stopped
    ports:
      - "9100:9100"
    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)$$'
    networks:
      - observability-net

Langkah 2: Konfigurasi Prometheus Scrape Targets

Buat file konfigurasi Prometheus di /opt/observability/prometheus/prometheus.yml:

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: 'linux-server'
    static_configs:
      - targets: ['node-exporter:9100']

  - job_name: 'nginx-webserver'
    static_configs:
      - targets: ['nginx-exporter:9113']

  - job_name: 'mysql-database'
    static_configs:
      - targets: ['mysql-exporter:9104']

  - job_name: 'redis-cache'
    static_configs:
      - targets: ['redis-exporter:9121']

Langkah 3: Konfigurasi Otomatisasi Datasource Grafana

Buat file provisioning datasource di /opt/observability/grafana/provisioning/datasources/prometheus.yml agar Grafana langsung mengenali Prometheus tanpa konfigurasi manual:

apiVersion: 1

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

Langkah 4: Menjalankan Sistem Stack

Jalankan seluruh kontainer menggunakan Docker Compose dengan perintah terminal berikut:

sudo docker compose up -d

Verifikasi bahwa seluruh layanan berjalan normal:

sudo docker compose ps

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah beberapa parameter krusial dalam konfigurasi di atas:

  • scrape_interval: 15s: Menentukan seberapa sering Prometheus menarik metrik dari target. Nilai 15 detik adalah standar industri yang menyeimbangkan antara akurasi data real-time dan beban performa pada target server.
  • storage.tsdb.retention.time=30d: Mengatur masa penyimpanan data metrik di dalam TSDB selama 30 hari sebelum dihapus otomatis. Pastikan kapasitas disk mencukupi.
  • --path.procfs=/host/proc: Pada konfigurasi Node Exporter, baris ini mengarahkan collector membaca kernel metrics dari direktori sistem host fisik, bukan dari dalam kontainer Docker itu sendiri, sehingga data CPU, RAM, dan I/O disk yang terbaca adalah data riil server fisik.
  • GF_SECURITY_ADMIN_USER & GF_SECURITY_ADMIN_PASSWORD: Variabel lingkungan wajib untuk mengamankan panel admin Grafana pada akses pertama (first boot).

[!WARNING] Jangan pernah membiarkan kredensial bawaan Grafana (admin/admin) aktif di lingkungan produksi. Segera ganti melalui environment variable docker-compose atau ubah langsung melalui halaman pengaturan setelah login pertama.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Studi Kasus: Sebuah platform e-commerce dengan trafik tinggi mengalami lonjakan latency mendadak hingga 3.5 detik pada layanan pembayaran (checkout service) saat flash sale.

Langkah Investigasi:

  1. Grafana Dashboard: SRE membuka dashboard utama dan melihat lonjakan metrik http_request_duration_seconds_bucket pada endpoint /api/v1/checkout.
  2. Korelasi Prometheus & MySQL: Metrik MySQL Exporter menunjukkan tingginya mysql_global_status_threads_connected dan slow queries akibat kurangnya indeks pada tabel transaksi.
  3. Distributed Tracing (OpenTelemetry): Melalui penelusuran trace, teridentifikasi bahwa fungsi pembayaran melakukan pemanggilan berulang (N+1 query problem) ke Redis dan MySQL secara sinkronus.
  4. Solusi Cepat: Tim backend menerapkan query batching dan menambahkan index pada kolom user_id di database MySQL. Latensi kembali normal di bawah 120ms dalam kurun waktu 15 menit tanpa harus melakukan restart aplikasi.

8. Common Pitfalls, Anti-Patterns & Solusi

  • Anti-Pattern 1: High Cardinality Metrics. Kesalahan: Menyertakan parameter unik seperti User ID atau UUID transaksi sebagai label di Prometheus. Dampak: Ledakan kardinalitas yang mengakibatkan memori Prometheus habis (OOM Killer) dan server monitoring crash. Solusi: Batasi label hanya pada entitas ber-kardinalitas rendah seperti status_code, method, atau service_name.

  • Anti-Pattern 2: Scraping Terlalu Agresif. Kesalahan: Mengatur scrape_interval: 1s untuk seluruh target. Dampak: Beban jaringan meningkat drastis dan mengganggu kinerja aplikasi utama yang sedang dipantau. Solusi: Gunakan interval 15s hingga 60s untuk metrik standar. Gunakan interval lebih pendek hanya untuk metrik krusial tertentu.

[!TIP] Selalu gunakan Prometheus Recording Rules untuk menggabungkan metrik berat yang sering dihitung berulang kali di panel Grafana demi menghemat penggunaan CPU server monitoring.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk memastikan sistem monitoring Anda siap menanggung beban produksi berskala besar, lakukan pengujian performa (load testing) pada endpoint metrics aplikasi menggunakan tool k6 atau wrk.

Contoh skrip uji beban sederhana menggunakan wrk untuk menguji performa endpoint /metrics pada aplikasi web Go:

wrk -t12 -c400 -d30s http://localhost:8080/metrics

Parameter Tuning Lanjutan di Prometheus (prometheus.yml):

global:
  scrape_timeout: 10s
storage:
  tsdb:
    wal-compression: true

Mengaktifkan kompresi WAL (Write-Ahead Log) dapat menghemat ruang penyimpanan disk hingga 30-40% pada lingkungan dengan volume metrik tinggi.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum merilis sistem observabilitas ke lingkungan produksi, pastikan Anda telah mencentang seluruh daftar pemeriksaan berikut:

  • Seluruh password default telah diubah dan diamankan.
  • Konfigurasi penyimpanan TSDB memiliki kebijakan retensi (retention policy) dan cadangan (backup) otomatis.
  • Alertmanager telah terintegrasi dengan kanal komunikasi tim (Slack, PagerDuty, atau Telegram).
  • Firewall dikonfigurasi ketat; hanya IP internal yang diizinkan mengakses port Prometheus dan Exporter.
  • Dashboard Grafana telah diuji dan menampilkan data secara akurat tanpa missing panels.

Dengan menerapkan arsitektur observabilitas yang solid menggunakan Prometheus, Grafana, dan OpenTelemetry, organisasi Anda tidak hanya memantau infrastruktur secara pasif, tetapi membangun fondasi ketahanan sistem yang proaktif, transparan, dan sangat handal.

🏷️ Tags: #Devops #Sre #Opentelemetry #Prometheus #Grafana