Belajar Linux - High Availability & Monitoring Stack

#Pendahuluan

Setelah di episode 28 sebelumnya kita membangun autentikasi terpusat dengan LDAP dan SSSD — satu direktori identitas yang melayani puluhan server — kalian kini punya kendali akses yang terpusat. Tapi ada pertanyaan yang sama pentingnya dengan "siapa yang boleh masuk": bagaimana kita tahu semua server ini masih hidup dan sehat? Server bisa mati tanpa mengirimkan pemberitahuan apa pun — power supply rusak, kernel panic, atau disk penuh — dan kalian baru menyadarinya saat user melapor "situs tidak bisa diakses".

Di episode 29 ini kita masuk ke dua pilar operasional yang membuat infrastruktur benar-benar profesional: High Availability (HA) dan Monitoring. Kita akan belajar bagaimana membuat layanan tetap hidup meskipun satu server mati (Keepalived + virtual IP), bagaimana mengukur kesehatan semua server secara terpusat (Prometheus + node_exporter + Grafana), serta bagaimana menerima peringatan otomatis sebelum masalah menjadi bencana (Alertmanager). Di akhir episode, kalian akan membangun monitoring stack nyata di dua VM — fondasi dari operasional yang bisa diandalkan.

#Pembahasan Utama

#Konsep High Availability: Redundancy dan Failover

Prinsip pertama yang harus dipahami: high availability bukan berarti "tidak pernah down" — berarti "dampak downtime diminimalkan dengan otomatisasi". Tidak ada sistem yang bebas kegagalan; yang ada adalah sistem yang merancang kegagalan dan menyediakan pengganti otomatis.

Bayangkan pesawat penumpang. Pesawat tidak dirancang agar mesinnya tidak pernah mati — dirancang agar satu mesin bisa mati tanpa menjatuhkan pesawat. Ada dua mesin (redundancy), dan jika satu mati, yang lain tetap membawa pesawat terbang (failover). Pilot tidak perlu panik; sistem mengkompensasi secara otomatis.

Dalam dunia server, redundansi berarti menjalankan dua atau lebih node yang menyediakan layanan yang sama. Failover berarti mekanisme otomatis yang memindahkan "kepemimpinan" dari node yang mati ke node yang sehat. Komponen yang paling penting dalam failover adalah deteksi: node pengganti harus tahu dengan cepat bahwa node utama sudah tidak sehat.

Tool yang paling populer untuk skenario two-node active/standby di Linux adalah Keepalived. Ia memakai protokol VRRP (Virtual Router Redundancy Protocol) untuk membuat sebuah Virtual IP (VIP) yang secara otomatis dipakai oleh node yang sehat. Dari luar, client hanya melihat satu IP — tidak pernah tahu bahwa di baliknya ada dua server. Ketika node utama mati, node standby mengambil alih VIP dalam hitungan detik tanpa intervensi manusia.

Untuk cluster yang lebih kompleks (multi-node, resource yang bisa berpindah seperti service, filesystem, dan IP), ada Pacemaker + Corosync — cluster resource manager yang jauh lebih kuat tapi juga jauh lebih kompleks. Keepalived cukup untuk kebanyakan kebutuhan active/standby; Pacemaker untuk cluster skala enterprise.

#Menyiapkan Keepalived dengan Virtual IP

Kita akan membuat dua node — web-01 (IP 192.168.1.11) dan web-02 (IP 192.168.1.12) — yang berbagi satu VIP 192.168.1.10. Kedua node menjalankan nginx. Saat web-01 sehat, ia yang memegang VIP; jika mati, web-02 mengambil alih.

apt install -y keepalived

Konfigurasi di node utama web-01:

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 200
    advert_int 1
    virtual_ipaddress {
        192.168.1.10/24 dev eth0
    }
    track_script {
        chk_nginx
    }
}

Dan di node standby web-02, hampir identik kecuali state BACKUP dan priority 150:

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    virtual_ipaddress {
        192.168.1.10/24 dev eth0
    }
    track_script {
        chk_nginx
    }
}

Agar failover benar-benar terjadi hanya jika layanan (bukan sekadar OS) bermasalah, kita definisikan track_script yang memeriksa nginx. Ini pola yang sangat penting: jika nginx mati tapi server tetap hidup, VIP seharusnya tetap berpindah ke node lain — karena user tetap tidak bisa mengakses layanan.

#!/usr/bin/env bash
if ! pidof nginx > /dev/null; then
    exit 1
fi
exit 0

systemctl restart keepalived
ip addr show eth0 | grep 192.168.1.10   # di web-01: VIP tampil

#Monitoring Stack: node_exporter, Prometheus, dan Grafana

HA menjawab "bagaimana layanan tetap hidup"; monitoring menjawab "bagaimana kita tahu ia sehat". Stack yang paling populer di ekosistem Linux/DevOps modern adalah Prometheus + node_exporter + Grafana, dan arsitekturnya berbeda dari monitoring tradisional: pull model.

• node_exporter — agent ringan yang dipasang di setiap server untuk memaparkan metrik OS (CPU, RAM, disk, network) dalam format teks HTTP di port 9100.
• Prometheus — server metrik yang secara berkala menarik (pull) data dari exporter, menyimpan time-series, dan mengevaluasi aturan alert.
• Grafana — platform visualisasi yang membaca data dari Prometheus untuk membuat dashboard yang indah dan interaktif.
• Alertmanager — komponen Prometheus yang menerima alert dan meneruskannya ke channel (email, Slack, Telegram, webhook).

+-----------+   scrape /metrics   +---------------+   query    +----------+
| Server 1  | <-----------------> |  Prometheus   | <--------> | Grafana  |
| node_exp  |                     |  (time-series)|            | (visual) |
+-----------+                     +-------+-------+            +----------+
+-----------+   scrape /metrics   |       |
| Server 2  | <-----------------> |  Alertmanager  | --> email/Slack
| node_exp  |                     +----------------+
+-----------+

#Langkah 1: Pasang node_exporter di semua node

curl -LO https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz
tar xzf node_exporter-1.8.2.linux-amd64.tar.gz
install -m 755 node_exporter-1.8.2.linux-amd64/node_exporter /usr/local/bin/
useradd -rs /bin/false node_exporter
install -m 644 /dev/stdin /etc/systemd/system/node_exporter.service <<'EOF'
[Unit]
Description=Node Exporter
After=network.target
 
[Service]
User=node_exporter
ExecStart=/usr/local/bin/node_exporter
 
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload && systemctl enable --now node_exporter

Verifikasi metrik dengan curl http://localhost:9100/metrics | head — kalian akan melihat ribuan baris metrik seperti node_cpu_seconds_total, node_memory_MemAvailable_bytes, dan seterusnya.

#Langkah 2: Konfigurasi Prometheus

Prometheus dikonfigurasi lewat prometheus.yml. Bagian paling penting adalah scrape_configs — daftar target yang harus ditarik metriknya:

scrape_configs:
  - job_name: nodes
    static_configs:
      - targets:
          - web-01:9100
          - web-02:9100
    scrape_interval: 15s

Beri nama pada baris job_name sesuai peran node (misalnya web, db, monitoring) agar metrik mudah dikelompokkan di Grafana. Target down akan tampil di halaman Targets Prometheus dengan status merah.

#Langkah 3: Buat dashboard di Grafana

Grafana terhubung ke Prometheus sebagai data source, lalu dashboard bisa dibuat secara manual atau di-import dari komunitas. Dashboard node-exporter paling populer adalah ID 1860 di grafana.com:

# Buka http://<grafana-host>:3000 (login default admin/admin)
# Add data source → Prometheus → URL: http://<prometheus-host>:9090
# Dashboard → Import → ID 1860 → pilih data source Prometheus

#Langkah 4: Alertmanager — beri tahu sebelum bencana

Dashboard hanya berguna jika seseorang sedang melihatnya. Untuk operasional yang sehat, kalian butuh alert otomatis. Di Prometheus, alert didefinisikan dengan rule PromQL. Contoh: alert ketika CPU idle hampir habis atau disk penuh:

groups:
  - name: node-alerts
    rules:
      - alert: HighCPU
        expr: 100 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) > 90
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "CPU tinggi pada {{ $labels.instance }}"
      - alert: DiskSpaceLow
        expr: node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} < 0.1
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Disk / tinggal 10% di {{ $labels.instance }}"

Alertmanager menerima alert dari Prometheus dan mengelompokkannya sebelum dikirim ke channel. Konfigurasi penerima email/Slack ada di alertmanager.yml:

route:
  group_by: [alertname, instance]
  receiver: ops-team
receivers:
  - name: ops-team
    email_configs:
      - to: ops@example.com
        from: alerts@example.com
        smarthost: smtp.example.com:587

#Uptime dan Health Check: systemd, monit, nagios

Selain stack Prometheus, ada beberapa lapisan health check yang melengkapi pengawasan:

• systemd — selain mengelola service, systemd juga memonitor service. Restart=on-failure membuat service restart otomatis saat crash, dan WatchdogSec memberitahu jika service berhenti merespons. Ini adalah lini pertahanan pertama yang gratis.
• monit — tool monitoring ringan berbasis config untuk proses, filesystem, dan host; cocok untuk setup kecil dan sederhana.
• Nagios/Icinga — monitoring tradisional berbasis agent + active check yang masih banyak dipakai organisasi legacy.

Pola yang sehat menggabungkan ketiganya: systemd untuk pemulihan otomatis (restart), Prometheus untuk metrik historis & alerting, dan check eksternal (seperti UptimeRobot atau monit) untuk memastikan layanan bisa dijangkau dari luar — karena Prometheus yang mati tidak bisa memberi tahu bahwa dirinya mati.

[Service]
ExecStart=/usr/local/bin/myapp
Restart=on-failure
RestartSec=5
WatchdogSec=30
StartLimitIntervalSec=60
StartLimitBurst=5

#Praktik: Monitoring Stack di Dua VM

Saatnya menggabungkan semuanya. Skenario: dua VM web-01 dan web-02 (sekaligus node HA dari bagian sebelumnya), plus satu VM mon-01 yang menjalankan Prometheus, Grafana, dan Alertmanager.

web-01 (nginx + node_exporter)  ----+----> mon-01 (Prometheus + Grafana + Alertmanager)
web-02 (nginx + node_exporter)  ----+---->         scrapes port 9100 tiap 15s
web-01 & web-02 = Keepalived VIP 192.168.1.10 (failover)

Alur kerjanya:

1. Pasang node_exporter di web-01 dan web-02 (lihat Langkah 1 di atas).
2. Pasang Prometheus di mon-01 dengan scrape_configs menunjuk ke kedua node.
3. Pasang Grafana di mon-01, tambahkan Prometheus sebagai data source, import dashboard 1860.
4. Pasang Alertmanager dan tambahkan alert.rules.yml ke Prometheus.
5. Matikan salah satu node dan amati: Prometheus akan menandai target down, Grafana menunjukkan data yang kosong, dan Alertmanager mengirim alert.

curl http://mon-01:9090/api/v1/targets | head -20

{
  "status": "success",
  "data": {
    "activeTargets": [
      {"labels": {"instance": "web-01:9100"}, "health": "up"},
      {"labels": {"instance": "web-02:9100"}, "health": "up"}
    ]
  }
}

#Common Pitfalls

Berikut pola kegagalan yang paling sering ditemukan saat membangun HA & monitoring:

Kasus firewall pantas dijadikan contoh. Ini adalah penyebab paling umum target Prometheus down — bukan karena node mati, tapi karena port 9100 tidak diizinkan masuk dari server Prometheus:

# target down terus, padahal curl localhost:9100 jalan
ufw allow from 192.168.1.20 to any port 9100 proto tcp
systemctl reload ufw

#Penutup

Di episode ini kita telah membangun dua pilar operasional yang membuat infrastruktur benar-benar siap produksi: High Availability dengan Keepalived dan virtual IP — layanan tetap hidup saat satu node mati; dan monitoring stack dengan node_exporter, Prometheus, Grafana, serta Alertmanager — semua server terukur dan masalah terdeteksi sebelum menjadi bencana. Kalian juga memahami pola health check berlapis (systemd untuk pemulihan otomatis, Prometheus untuk observability, check eksternal untuk ketersediaan) dan kesalahan-kesalahan umum yang harus dihindari.

Hampir selesai. Kalian sudah memiliki: server yang terhardening, backup yang teruji, container dan virtualisasi yang berjalan, autentikasi terpusat, serta HA dan monitoring. Semua komponen itu kini siap dirakit menjadi satu sistem utuh. Di episode 30 — episode pamungkas dari seri Belajar Linux — kita akan membangun complete production-grade Linux server setup: merangkai seluruh pelajaran dari episode 0 hingga 29 menjadi satu case study menyeluruh, dilengkapi production readiness checklist dan rangkuman perjalanan panjang ini. Sampai jumpa di episode terakhir!