Belajar Database Administrator - Monitoring & Alerting

#Pendahuluan

Di episode 6 kita men-tuning query dengan bukti dari EXPLAIN. Tapi dari mana query itu ditemukan? Jawabannya: monitoring. DBA tanpa monitoring seperti pilot tanpa instrumen — bisa terbang, tapi tidak tahu kapan mesin mau rusak. Episode ini membangun dua hal: metrik yang benar-benar penting untuk dipantau, dan sistem alerting yang memberitahu kalian sebelum pengguna mengeluh.

Prinsip emasnya: you can't fix what you can't see. Semua keputusan tuning, capacity, dan incident di episode-episode berikutnya berangkat dari data yang dikumpulkan di episode ini.

#Metrik yang Wajib Dipantau

Dari sekian banyak metrik, empat keluarga ini yang menentukan kesehatan database:

Jangan jatuh ke perangkap metrik hujan-hujanan: pantau semua, alerting untuk yang sedikit. Aturan praktis: alert on symptoms users feel (latency p99, koneksi habis, disk penuh), bukan metrik internal yang kadang berisik.

#Slow Query Log & pg_stat_statements

Dua sumber data utama menemukan query bermasalah.

Slow query log di PostgreSQL mencatat query yang melewati ambang waktu:

log_min_duration_statement = 250
log_statement = 'none'
log_destination = 'stderr'

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
SELECT query, calls, mean_exec_time, total_exec_time
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 5;

pg_stat_statements adalah kamera yang merekam semua query — dengan itu kalian bisa melihat query dengan total waktu terbesar, bukan hanya yang terakhir lambat. Ini data mentah untuk episode 6 dan 21.

MySQL padanannya:

SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 0.25;
SHOW VARIABLES LIKE 'slow_query%';

#Menjalankan Server di Lab

Untuk melihat dashboard sungguhan, kita perlu stack monitoring. Bahan yang diperlukan:

• Prometheus — penarik & penyimpan metrik (pull model).
• postgres_exporter — menjembatani PostgreSQL ke Prometheus.
• Grafana — dashboard visual.
• Alertmanager — routing notifikasi (opsional, untuk alert).

Di lab kalian bisa menjalankan semuanya dengan Docker Compose — cara paling cepat dan tidak mengotori VM:

services:
  postgres-exporter:
    image: prometheuscommunity/postgres-exporter
    environment:
      DATA_SOURCE_NAME: "postgresql://monitor:secret@postgres:5432/appdb?sslmode=disable"
    ports: ["9187:9187"]
 
  prometheus:
    image: prom/prometheus
    volumes: ["./prometheus.yml:/etc/prometheus/prometheus.yml"]
    ports: ["9090:9090"]
 
  grafana:
    image: grafana/grafana
    ports: ["3000:3000"]

Config Prometheus memberitahu apa yang harus ditarik:

scrape_configs:
  - job_name: postgres
    static_configs:
      - targets: ["postgres-exporter:9187"]

postgres_exporter memerlukan role hanya-baca — buat role monitor dengan GRANT CONNECT, pg_monitor di PostgreSQL; jangan pernah memberinya kredensial superuser (pelajaran least privilege episode 3 dan 9).

#Membangun Alerting yang Efektif

Alerting yang buruk membuat semua orang matikan notifikasi. Aturannya: sedikit alert, tapi bermakna, dengan runbook. Contoh aturan Prometheus yang pantas:

groups:
  - name: postgres
    rules:
      - alert: PostgresDown
        expr: pg_up == 0
        for: 2m
        labels: { severity: critical }
 
      - alert: PostgresConnectionsHigh
        expr: pg_stat_database_numbackends > 0.8 * pg_settings_max_connections
        for: 5m
        labels: { severity: warning }
 
      - alert: PostgresDiskNearlyFull
        expr: disk_free < 20 * 1024 * 1024 * 1024
        for: 10m
        labels: { severity: critical }

Kriteria alert yang baik:

• for duration menghindari alert yang berkedip karena spike sesaat.
• Severity jelas — warning untuk degradasi, critical untuk yang harus dibangunkan tengah malam.
• Setiap alert punya runbook — tautan ke langkah diagnosis; tanpa ini, alert hanya menambah panik.

Layanan komersial seperti pganalyze dan Percona Monitoring and Management menyediakan hal yang sama plus rekomendasi tuning otomatis — pilihan bagus jika tim tidak ingin merawat stack sendiri.

#Memvalidasi Dashboard

Setelah semua menyala, lakukan uji: jalankan query berat buatan, dan lihat metrik berubah:

SELECT count(*) FROM generate_series(1, 10000000);

Saat query ini berjalan, perhatikan panel pg_stat_activity (backends aktif), CPU, dan I/O. Jika semuanya naik, pipeline observability kalian bekerja. Sekarang kalian punya mata untuk seluruh sisa series.

#Pitfall Umum

1. Alerting berlebihan: 50 aturan menghasilkan alert fatigue — orang mulai mengabaikannya. Mulai dengan 5 aturan terbaik.
2. Interval scrape terlalu rapat: postgres_exporter tiap 5 detik di 10 database = beban nyata. 15-30 detik sudah cukup.
3. Metrik tanpa konteks: pg_stat_activity tanpa tahu query apa yang jalan tidak membantu — selalu sertakan query/application di dashboard.
4. Dashboard tanpa data historis: Prometheus punya retensi terbatas; untuk tren bulanan pertimbangkan storage jangka panjang.
5. Slow query log nonaktif di produksi: tanpa itu, insiden query lambat (episode 20) kehilangan bukti terbaiknya.

#Penutup

Inti yang harus dibawa pulang:

• Pantau empat keluarga: latency, throughput, koneksi, I/O/disk; alert hanya untuk gejala yang dirasakan pengguna.
• pg_stat_statements + slow query log adalah sumber temuan query bermasalah.
• Stack: Prometheus + postgres_exporter + Grafana; role monitor hanya-baca.
• Sedikit alert yang bermakna, dengan for, severity, dan runbook — itu lebih baik dari 50 notifikasi yang diabaikan.

Di episode 8 selanjutnya kita membangun high availability & replication — setup primary/replica dengan streaming replication, failover manual dan otomatis, sampai pembagian beban baca lewat load balancer atau pgbouncer. Jika monitoring adalah mata, HA adalah sistem imun kalian. Sampai jumpa di episode 8!