Observability & Monitoring Enterprise: Prometheus, Grafana, dan OpenTelemetry di AWS
1. Konteks Industri & Analisis Akar Masalah
Dalam lanskap arsitektur web modern yang mendistribusikan beban kerja di atas infrastruktur cloud seperti Amazon Web Services (AWS), kompleksitas sistem meningkat secara eksponensial. Sebuah aplikasi web enterprise khas tidak lagi berdiri sendiri sebagai monolit tunggal. Ia merupakan ekosistem terdistribusi yang melibatkan edge caching di Cloudflare, reverse proxy Nginx, layanan backend berbasis Node.js, Go, atau PHP-FPM, sistem manajemen antrean (queue) menggunakan Redis, database relasional MySQL, hingga penyimpanan objek S3.
Ketika terjadi degradasi performa—seperti lonjakan latensi latency (p99 latency > 2 detik) atau HTTP 502 Bad Gateway secara sporadis—Tim Site Reliability Engineering (SRE) dan DevOps sering kali terjebak dalam "blame game". Apakah masalahnya berasal dari exhaustion connection Pool MySQL, memori terfragmentasi di PHP-FPM, penyumbatan antrean Redis, atau limitasi IOPS pada EBS volume AWS? Tanpa sistem observabilitas end-to-end yang solid, identifikasi akar masalah (root cause analysis) bisa memakan waktu berjam-jam.
Secara historis, monitoring tradisional hanya mengandalkan metrik infrastruktur dasar (CPU, RAM, Disk utilization) dan log teks mentah. Pendekatan ini memiliki kelemahan fatal: metrik tidak menceritakan konteks aplikasi, sementara log terlalu mahal dan lambat untuk di-query secara real-time saat terjadi lonjakan throughput.
Perbandingan Kondisi: Sebelum vs Sesudah Observabilitas End-to-End
| Parameter | Sebelum (Traditional Monitoring) | Sesudah (Prometheus, Grafana, & OpenTelemetry) |
|---|---|---|
| Mean Time to Detect (MTTD) | 15–45 menit (berdasarkan laporan klien) | < 30 detik (Alertmanager berbasis metrik & anomali) |
| Mean Time to Resolution (MTTR) | Berjam-jam (menelusuri ribuan baris log manual) | Menit (Korelasi Trace ID, Metrics, dan Logs di Grafana) |
| Root Cause Analysis | Spekulatif, berbasis tebakan konfigurasi | Presisi, menunjuk baris query SQL lambat atau fungsi backend |
| Overhead Sistem | Agen monitoring pihak ketiga yang berat & invasif | OpenTelemetry Collector ringan + Prometheus pull-based |
2. Konsep Inti & Deep Dive Arsitektur
Sistem observabilitas enterprise modern dibangun di atas tiga pilar utama (The Three Pillars of Observability): Metrics (angka agregat numerik), Logs (rekaman kejadian diskrit), dan Traces (jejak perjalanan request lintas layanan).
+-----------------------------------------------------------------------------------------+
| AWS INFRASTRUCTURE |
| |
| +--------------------+ +-----------------------+ +------------------------+ |
| | Nginx / Web Server | ---> | PHP-FPM / Go Backend | ---> | MySQL / Redis / S3 | |
| +--------------------+ +-----------------------+ +------------------------+ |
| | | | |
| v v v |
| +-----------------------------------------------------------------------------------+ |
| | OpenTelemetry (OTel) Collector | |
| +-----------------------------------------------------------------------------------+ |
| | | |
| v (Remote Write / OTLP) v (Metrics Push) |
| +---------------------------+ +-----------------------+ |
| | Grafana Tempo | | Prometheus | |
| | (Traces) | | (Metrics) | |
| +---------------------------+ +-----------------------+ |
| / |
| -------------------> +-----------------+ <-------------/ |
| | Grafana UI | |
| | (Visualization) | |
| +-----------------+ |
+-----------------------------------------------------------------------------------------+
Alur Data di Balik Layar (Under the Hood)
- Instrumentasi Aplikasi: Aplikasi web (misal: Go backend atau PHP dengan OpenTelemetry SDK) meng-instrumentasi kode untuk menghasilkan spans (jejak waktu eksekusi fungsi) dan mengekspos endpoint
/metricsuntuk Prometheus. - Pengumpulan oleh OpenTelemetry Collector: OTel Collector bertindak sebagai agen pemrosesan terpusat. Ia menerima data OTLP (OpenTelemetry Protocol) dari berbagai aplikasi, melakukan agregasi, penyaringan (sampling), dan meneruskannya ke backend penyimpanan.
- Scraping oleh Prometheus: Prometheus melakukan polling (tarik/pull) secara periodik terhadap endpoint metrik dari Nginx, Node Exporter, MySQL Exporter, dan OTel Collector.
- Visualisasi & Alerting: Grafana mengkueri Prometheus untuk metrik dan Grafana Tempo untuk traces, menyajikannya dalam satu pane of glass. Jika ambang batas terlampaui, Prometheus meneruskannya ke Alertmanager untuk dikirim via PagerDuty atau Slack.
3. Perbandingan Komparatif / Analisis Pendekatan
Dalam membangun pipeline observability di AWS, arsitek sering dihadapkan pada pilihan alat pengumpul dan penyimpanan data. Berikut adalah analisis mendalam:
| Komponen | Pilihan A: OpenTelemetry + Prometheus + Grafana | Pilihan B: AWS Managed Service for Prometheus (AMP) & Grafana (AMG) | Pilihan C: Datadog / New Relic (SaaS Komersial) |
|---|---|---|---|
| Kepemilikan Infrastruktur | Self-hosted (EC2 / EKS) | Fully Managed AWS | SaaS Pihak Ketiga |
| Biaya Operasional (OpEx) | Rendah (biaya server saja) | Sedang (berdasarkan data ingest/query) | Sangat Tinggi (per host/GB) |
| Kontrol & Kustomisasi | Mutlak (Full control) | Terbatas pada ekosistem AWS | Tergantung paket langganan |
| Lock-in Vendor | Rendah (Standar Open Source CNCF) | Sedang (Ekosistem AWS) | Sangat Tinggi |
| Konsumsi CPU & RAM | Membutuhkan resource server pemantauan | Dikelola AWS | Agen ringan di server |
| Rekomendasi Enterprise | Sangat Direkomendasikan untuk kontrol data | Bagus jika 100% serverless di AWS | Cocok untuk tim tanpa resource DevOps |
[!IMPORTANT] Pemilihan Pilihan A memberikan fleksibilitas penuh terhadap kepatuhan regulasi data (Data Sovereignty) yang sangat penting bagi industri perbankan dan kesehatan di Indonesia (UU PDP).
4. Prasyarat Sistem & Persiapan Lingkungan
Sebelum melakukan deploy stack observability, pastikan environment AWS dan instance target memenuhi spesifikasi minimum berikut:
Spesifikasi Minimum Instance (AWS EC2 / Ubuntu 22.04 LTS)
- Instance Type:
t3.medium(2 vCPU, 4 GB RAM) untuk server monitoring. - Storage: 50 GB EBS gp3 (IOPS: 3000, Throughput: 125 MB/s).
- Network: Security Group membuka port inbound:
9090(Prometheus),3000(Grafana),4317/4318(OTel Collector),9100(Node Exporter).
Dependensi Sistem
Pastikan curl, wget, jq, dan tar terinstal:
sudo apt update && sudo apt install -y curl wget jq tar
5. Panduan Implementasi Langkah demi Langkah
Langkah 1: Instalasi Node Exporter (Metrik Sistem OS)
# Buat user dedicated
sudo useradd --no-create-home --shell /bin/false node_exporter
# Unduh Node Exporter
VERSION="1.8.2"
wget https://github.com/prometheus/node_exporter/releases/download/v${VERSION}/node_exporter-${VERSION}.linux-amd64.tar.gz
tar xvf node_exporter-${VERSION}.linux-amd64.tar.gz
sudo cp node_exporter-${VERSION}.linux-amd64/node_exporter /usr/local/bin/
sudo chown node_exporter:node_exporter /usr/local/bin/node_exporter
# Buat systemd service
echo '[Unit]
Description=Node Exporter
After=network.target
[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter
[Install]
WantedBy=multi-user.target' | sudo tee /etc/systemd/system/node_exporter.service
sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter
Langkah 2: Konfigurasi Prometheus (/etc/prometheus/prometheus.yml)
Buat direktori dan file konfigurasi utama:
sudo mkdir -p /etc/prometheus /var/lib/prometheus
sudo useradd --no-create-home --shell /bin/false prometheus
Isi file /etc/prometheus/prometheus.yml dengan konfigurasi valid berikut:
global:
scrape_interval: 15s
evaluation_interval: 15s
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: 'otel_collector'
static_configs:
- targets: ['localhost:8889']
Langkah 3: Konfigurasi Rule Alerting (/etc/prometheus/alert_rules.yml)
groups:
- name: EnterpriseWebAlerts
rules:
- alert: InstanceDown
expr: up == 0
for: 1m
labels:
severity: critical
annotations:
summary: "Instance {{ $labels.instance }} down"
description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minute."
- alert: HighCPUUsage
expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle\