Belajar Infrastructure Engineer - Monitoring & Observability

#Pendahuluan

Setelah di episode 8 kita mengotomasi infrastruktur, kini saatnya membangun penglihatan: monitoring & observability. Infrastruktur yang dibangun tapi tidak dipantau adalah seperti mengemudikan pesawat tanpa instrumen — terbang boleh, tapi tidak tahu ketinggian, arah, atau bahan bakar.

Mengapa topik ini penting? Karena di produksi, kalian tidak akan menyadari banyak masalah sebelum user mengeluh — kecuali kalian punya sistem yang melihat lebih dulu. Episode ini membangun tumpukan observability standar industri: metrics (Prometheus), visualisasi (Grafana), logs terpusat, dan alerting yang tidak membuat kalian mati rasa karena terlalu banyak notifikasi.

#Monitoring vs Observability

Sering dianggap sama, padahal bedanya fundamental:

Praktiknya keduanya saling melengkapi: monitoring menjawab "kapan", observability menjawab "mengapa". Dasbor monitoring memberi tahu ada yang aneh; log dan trace terdistribusi menjelaskan penyebabnya.

#Tiga Pilar Observability

• Metrics: angka numerik — CPU, memory, request rate, latency, error rate. Murah, disimpan lama, bagus untuk alerting.
• Logs: catatan kejadian dengan timestamp — apa yang terjadi, kapan, pada apa. Detail, mahal, bagus untuk debugging.
• Traces: perjalanan satu request melewati banyak service — di mana waktu hilang. Esensial di arsitektur microservice (episode 14).

#Prometheus: Mengumpulkan Metrics

Prometheus menarik metrics dari target melalui exporters dan menyimpannya sebagai time series. Pola pull-nya memudahkan penemuan target secara otomatis (service discovery).

global:
  scrape_interval: 15s
 
scrape_configs:
  - job_name: node
    static_configs:
      - targets:
          - web-01.lab.local:9100
          - web-02.lab.local:9100
 
  - job_name: apache
    static_configs:
      - targets:
          - web-01.lab.local:9117

Target :9100 adalah node_exporter — exporter standar untuk metrics sistem (CPU, memory, disk, network). Setiap host Linux yang dimonitoring wajib menjalankannya.

wget https://github.com/prometheus/node_exporter/releases/latest/download/node_exporter-*-linux-amd64.tar.gz
tar xvf node_exporter-*.tar.gz
./node_exporter &
curl -s localhost:9100/metrics | head

Untuk menyimpan metrics dari banyak target, gunakan prometheus.yml di atas lalu jalankan Prometheus:

docker run -d --name prometheus -p 9090:9090 \
  -v "$PWD/prometheus.yml":/etc/prometheus/prometheus.yml \
  prom/prometheus

PromQL adalah bahasa query Prometheus. Contoh yang wajib dikuasai:

# Rata-rata pemakaian CPU host
100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100
 
# Rata-rata memory terpakai
100 * (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)
 
# Request rate per detik
sum(rate(http_requests_total[5m])) by (service)

#Grafana: Visualisasi

Grafana menampilkan data Prometheus dalam dasbor. Komponen dasbor yang baik:

Praktik dasbor yang benar: jangan membuat satu dasbor raksasa. Buat dasbor berlapis — satu per layanan, satu untuk infrastruktur, satu untuk business metrics — dan setiap dasbor punya judul jelas serta annotasi saat deploy terjadi (agar spike bisa dikorelasikan dengan perubahan).

docker run -d --name grafana -p 3000:3000 \
  -e GF_SECURITY_ADMIN_PASSWORD=admin123 \
  grafana/grafana

Buka http://localhost:3000, tambahkan data source Prometheus, dan mulai buat dasbor pertama kalian.

#Logging Terpusat

journalctl per host tidak cukup untuk produksi — kalian butuh satu tempat untuk semua log. Tumpukan standar (misal ELK: Elasticsearch + Logstash + Kibana, atau alternatif modern Loki + Grafana):

scrape_configs:
  - job_name: system
    static_configs:
      - targets: [localhost]
        labels:
          job: syslog
          __path__: /var/log/*.log

Dengan logging terpusat, pencarian lintas host menjadi satu query:

{job="syslog"} |= "ERROR"
{app="api"} |= "timeout" | json

#Alerting yang Efektif

Alerting adalah bagian yang paling sering gagal — bukan karena teknis, tapi karena desain. Dua kegagalan klasik: alert terlalu banyak (alert fatigue, semua diabaikan) dan alert terlalu sedikit (masalah ditemukan oleh user).

Prinsip alerting yang benar:

1. Alert = butuh tindakan manusia. Jika tidak ada yang perlu dilakukan, jangan alert — cukup grafik.
2. Setiap alert punya runbook. Alert tanpa instruksi tindakan adalah kebisingan.
3. Page lebih penting daripada alert di dasbor. Level: dasbor (info) → email/Slack (warning) → pager (critical).
4. Tinjau alert secara rutin. Alert yang tidak pernah ditindaklanjuti selama 30 hari dihapus atau diperbaiki.

Contoh aturan alert yang baik di Prometheus:

groups:
  - name: node.rules
    rules:
      - alert: HostDown
        expr: up == 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Host {{ $labels.instance }} mati"
 
      - alert: HighDiskUsage
        expr: (1 - node_filesystem_free_bytes / node_filesystem_size_bytes) * 100 > 90
        for: 30m
        labels:
          severity: warning
        annotations:
          summary: "Disk {{ $labels.mountpoint }} di {{ $labels.instance }} di atas 90%"

Perhatikan for: 30m — alert tidak langsung berbunyi; ia menunggu kondisi bertahan 30 menit untuk menghindari false positive dari spike sementara.

#Common Pitfalls Monitoring

• Dashboards tanpa alert: semua terlihat, tidak ada yang diperingatkan.
• Alert fatigue: 200 alert per hari = semuanya diabaikan.
• Monitoring server tapi bukan aplikasi: server hidup, aplikasi hang, tidak ada yang tahu.
• Retensi terlalu pendek: data 7 hari tidak cukup untuk membandingkan "kenapa bulan lalu lebih cepat".
• Tanpa on-call yang jelas: alert berbunyi tapi tidak ada yang tahu siapa yang menangani.

#Penutup

Pada episode 9 ini kalian telah membangun tumpukan observability:

• Monitoring menjawab "sehat atau tidak", observability menjawab "mengapa tidak sehat".
• Metrics (Prometheus/Node exporter), logs terpusat, dan traces adalah tiga pilar.
• Grafana mengubah angka menjadi dasbor yang bisa dibaca manusia.
• Alerting yang baik jarang, punya runbook, dan butuh tindakan — bukan kebisingan.

Di episode 10 selanjutnya kita memastikan infrastruktur bisa selamat dari bencana: backup & disaster recovery — strategi backup, RPO/RTO, DR site, dan DR drill yang benar-benar diuji. Sampai jumpa di episode 10!