Belajar Kubernetes Distributed Storage - Monitoring & Observability Ceph

#Pendahuluan

Upgrade sudah tertata (episode 17). Episode 18 membangun sistem mata: monitoring & observability untuk Ceph. Tanpa ini, OSD yang down, PG yang missing, atau kapasitas yang menipis baru terasa saat — sudah terlambat.

Mengapa penting? Ceph menampilkan sinyal sebelum masalah parah: health warning, saturasi OSD, PG backfill. Alat observability menangkap sinyal itu dan mengubahnya menjadi alert — bukan diagnosis setelah krisis.

#Ceph Dashboard

Dashboard Ceph (episode 6) adalah tempat pertama melihat kondisi:

Overview: health, mon/mgr/osd, warnings.
Cluster → OSD: per-OSD usage, I/O, PG.
Cluster → Hosts: lokasi daemon.
Performance: latency & throughput grafis (perf counters).

Cek segmented: Performance → Client melihat latency client. Ini cepat untuk gambaran umum.

#Prometheus Integration

#Metrik dari MGR Prometheus

Rook men-deploy rook-ceph-mgr-prometheus sebagai target scrape. Gunakan ServiceMonitor:

yaml

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: rook-ceph-mgr
  namespace: rook-ceph
spec:
  selector:
    matchLabels:
      app: rook-ceph-mgr
      rook_cluster: rook-ceph
  namespaceSelector:
    matchNames: [rook-ceph]
  endpoints:
    - port: http-metrics
      path: /metrics
      scheme: http

Metrik yang berguna:

Metrik	Arti
`ceph_health_status`	Health status cluster
`ceph_osd_up`	Status up/down tiap OSD
`ceph_pg_*`	PG states (active, degraded, stuck)
`ceph_osd_used_bytes` / `ceph_osd_total_bytes`	Kapasitas per OSD
`ceph_cluster_total_used_bytes`	Utilisasi total

#Grafana Dashboards

#Dashboard Resmi

Rook membawa dashboard resmi (di deploy mendokumentasikannya) — import JSON ke Grafana dengan datasource Prometheus. Panel: overview cluster, OSD utilization, PG states, latency graph.

#Panel yang Wajib Dipantau

Health status & warnings.
OSD utilization > 70%.
PG states abnormal (peering, degraded, stuck).
Latency OSd/client.

#Alerting

#Objek PrometheusRule

yaml

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: ceph-alerts
  namespace: monitoring
spec:
  groups:
    - name: ceph
      rules:
        - alert: CephOSDDown
          expr: ceph_osd_up == 0
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "OSD {{ $labels.osd }} down"
        - alert: CephCapacityHigh
          expr: ceph_osd_used_bytes / ceph_osd_total_bytes > 0.8
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "Kapasitas OSD > 80%"
        - alert: CephPGStuck
          expr: ceph_pg_stuck != 0
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "PG stuck (peering/backfill)"

#Notifikasi ke Slack/email

Alertmanager meneruskan ke channel:

yaml

receivers:
  - name: slack
    slack_configs:
      - channel: "#ceph-alerts"
        send_resolved: true

Alert penting yang harus dipasang sejak awal: OSD down, health warning, PG missing/backfill, kapasitas >80%.

#Distributed Tracing / Logs

#Log Daemon

Log MON/OSD/MDS/RGW per Pod:

Cek log OSD

kubectl -n rook-ceph logs rook-ceph-osd-0 | tail -50

#Sentralisasi ke Loki/EFK

Untuk forensik, kumpulkan log ke Loki atau EFK:

Logging agent (Promtail/Fluentd) me-scrape /var/log/ceph atau log Pod.
Simpan dan indeks; buat dashboard error.

Tujuan: ketika alert berbunyi, bisa menelusuri "kenapa OSD 2 crash" dari log — bukan sekadar tahu "OSD 2 crash".

Tip

Mulai dari satu set kecil PrometheusRule (OSD down + kapasitas + PG stuck). Tambahkan alert lain setelah nyaman. Alert yang terlalu banyak malah menimbulkan "alert fatigue" — bisa membuat yang kritis terlewat.

#Penutup

Inti yang harus dibawa pulang:

Dashboard Ceph = gambaran cepat health, OSD, PG, latency.
Prometheus + ServiceMonitor (~90-scrape MGR) memberi metrik lengkap.
Grafana dashboard resmi + PrometheusRule untuk alert OSD down, PG stuck, kapasitas.
Log daemon ke Loki/EFK untuk forensik dan diagnostik.

Di episode 19 selanjutnya kita akan membahas performance & failure domain — benchmark block dan object, memahami failureDomain host/rack/region, opsi NVMe-oF untuk low latency, serta tuning latency jaringan. Sampai jumpa di episode 19!