Belajar MicroCloud - Monitoring & Observability

#Pendahuluan

Episode 19 menautkan MicroCloud ke ekosistem otomasi. Tapi otomasi tanpa visibilitas adalah penerbangan buta — episode 20 membangun monitoring & observability. Kalian akan melihat apa yang terjadi di cluster dari satu layar: node yang sehat, OSD yang hampir penuh, atau jaringan yang bermasalah. Episode 12 sempat menyentuh Cluster Manager; episode ini membahas lapisan observability standar yang bisa dipakai di produksi.

Analogi: pilot tidak bisa terbang tanpa instrumen — altimeter, indikator bahan bakar, dan warning light adalah sistem saraf yang membuat keputusan di kokpit terinformasi. Monitoring MicroCloud adalah panel instrumen kalian; episode ini memasangnya.

#Lapisan Observability MicroCloud

Arsitektur monitoring yang umum:

Arsitektur monitoring

MicroCloud node ──► exporter (metrik) ──► Prometheus (scrape)
                                              │
                                              ▼
                                    Alertmanager ──► alert channel
                                    Grafana ──► dashboard

#Dashboard LXD Grafana

#Dashboard Resmi

Dashboard LXD Grafana adalah dashboard resmi proyek LXD — menampilkan metrik cluster secara visual:

Jumlah instance per node, status container/VM.
Penggunaan storage pool dan volume.
Aktivitas network dan throughput.

Dashboard ini bekerja dengan data dari LXD Prometheus exporter (terbuka otomatis via API LXD) — tersedia lewat MicroCloud Cluster Manager (episode 12) maupun deployment mandiri.

#Setup Mandiri

Untuk observability mandiri di produksi, deploy Prometheus dan Grafana di node admin atau VM terpisah, lalu daftarkan scrape target tiap layanan:

Deploy Prometheus dan Grafana (contoh)

snap install prometheus grafana

#Prometheus Exporters

LXD, Ceph, dan OVN masing-masing mengekspos metrik di endpointnya — scrape semuanya dari satu file konfigurasi:

Scrape targets: LXD, Ceph, OVN

scrape_configs:
  - job_name: lxd
    metrics_path: /1.0/metrics
    static_configs:
      - targets: ["10.0.0.11:8443", "10.0.0.12:8443", "10.0.0.13:8443"]
  - job_name: ceph
    static_configs:
      - targets: ["10.0.0.11:9283", "10.0.0.12:9283", "10.0.0.13:9283"]
  - job_name: microovn
    static_configs:
      - targets: ["10.0.0.11:9473", "10.0.0.12:9473", "10.0.0.13:9473"]

Metrik kunci per lapisan:

LXD (port 8443): instance count, CPU/memory, storage pool usage.
Ceph (port 9283): ceph_osd_up, ceph_pool_percent_used, status cluster.
OVN (port 9473): state logical switch/router, tunnel health.

#Zabbix

Zabbix adalah alternatif monitoring klasik yang banyak dipakai tim infra lama — mendukung MicroCloud lewat template LXD dan agent di host:

Template LXD: status instance, disk, dan CPU dari API LXD.
Agent di node: metrik sistem (CPU, RAM, disk, jaringan) dari tiap host.
Alert native: item dan trigger Zabbix untuk kondisi down.

Jika tim kalian sudah berbasis Zabbix, gunakan sebagai lapisan yang ada; Prometheus/Grafana tetap bagus untuk ekosistem modern. Pilih yang paling cocok dengan skill set tim — bukan yang paling populer.

Tip

Tidak perlu memilih antara Prometheus dan Zabbix secara eksklusif — keduanya bisa berjalan paralel. Yang penting satu sumber kebenaran untuk alerting, agar tidak ada alarm yang saling bertentangan.

#Alerting yang Kritis

Tiga alarm yang wajib ada di MicroCloud:

#1. Node Down

Deteksi: metrik up Prometheus untuk target LXD/Ceph/OVN; atau heartbeat member LXD.
Dampak: instance di node tersebut di-reschedule (episode 9); data tetap aman berkat replikasi.
Aksi: tim on-call masuk, node diperiksa, evakuasi/restore sesuai runbook (episode 16).

#2. OSD Down

Deteksi: ceph_osd_up == 0; Ceph akan masuk HEALTH_WARN/DEGRADED.
Dampak: data masih tersedia jika di atas min_size, tapi faktor redundansi turun.
Aksi: cek disk (lsblk, log), tambahkan OSD pengganti bila rusak permanen (episode 6, 11).

#3. Cluster Degraded

Deteksi: status Ceph tidak HEALTH_OK; PG degraded/stuck; member OVN offline.
Dampak: capacity menurun, risiko data loss naik.
Aksi: baca ceph -s, identifikasi PG bermasalah, biarkan recovery selesai (episode 16).

Contoh aturan alert untuk ketiganya:

Aturan alert MicroCloud

groups:
  - name: microcloud
    rules:
      - alert: NodeDown
        expr: up{job="lxd"} == 0
      - alert: OsdDown
        expr: ceph_osd_up == 0
      - alert: ClusterDegraded
        expr: ceph_cluster_health != 1

Warning

Alert tanpa runbook hanya menghasilkan kebisingan. Setiap alarm kritis harus punya siapa yang di-page, langkah diagnosa pertama, dan jalur eskalasi. Alerting dimulai dari dokumen, bukan dari konfigurasi YAML.

#Pitfall Umum

Monitoring hanya node, tidak storage: OSD down tak terlihat sampai data bermasalah — selalu scrape Ceph.
Alert tanpa eksportir: metrik tidak muncul sebelum endpoint ter-scrape — verifikasi targets di Prometheus.
Thunderstorm alert: terlalu banyak alert membuat tim mati rasa — batasi pada kondisi yang benar-benar kritis.
Lupa eksportir di node baru: saat menambah node (episode 11), tambahkan juga scrape target-nya.
Alert tanpa runbook: alarm tanpa prosedur hanya menambah noise — tulis runbook sebelum alarm menyala.

#Penutup

Inti yang harus dibawa pulang:

Observability MicroCloud = exporter → Prometheus → Grafana/Alertmanager.
LXD, Ceph, dan OVN masing-masing punya exporter dan metrik kuncinya.
Dashboard LXD Grafana tersedia via Cluster Manager maupun deployment mandiri.
Zabbix adalah alternatif yang matang untuk tim yang sudah memakainya.
Tiga alert wajib: node down, OSD down, dan cluster degraded.
Setiap alert butuh runbook — alert tanpa runbook adalah kebisingan.

Di episode 21 selanjutnya kita membahas roadmap & community — ke mana arah MicroCloud (Cluster Manager yang matang, MicroOVN 26.03 LTS, dan 3.x LTS yang ditunggu) serta tempat berkumpul komunitas: dokumentasi Canonical, GitHub canonical/microcloud, discourse.ubuntu.com, dan ubuntu.com/blog. Kalian akan tahu dari mana kabar terbaru!