Membangun observability untuk storage: men-deploy kube-prometheus-stack dengan cadvisor dan node_exporter, menyusun alert PVC hampir penuh dan NFS down, mengalirkan log aplikasi ke sistem terpusat, serta memilih dashboard NFS yang tepat

Sebuah sistem penyimpanan hanya bisa dikelola dengan baik bila kalian melihat apa yang terjadi di dalamnya. Episode 18 membangun lapisan observability: metrik (Prometheus), visualisasi (Grafana), alerting (untuk pemberitahuan sebelum bencana), dan log terpusat.
Mengapa ini penting untuk shared storage? Karena gejala pertama masalah NFS tidak pernah datang sebagai pesan error yang ramah — ia datang sebagai upload yang tiba-tiba lambat, PVC yang Pending, atau node yang mulai NotReady. Kalian membutuhkan indikator untuk melihat percikan sebelum api membesar.
Tumpukan standar: Prometheus (scraping) + Grafana (dashboards) + operator. Install via Helm (nilai default sudah baik untuk lab):
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install monitoring prometheus-community/kube-prometheus-stack \
--namespace monitoring --create-namespacenode_filesystem_avail_bytes, node_disk_*)./metrics.Untuk mount NFS spesifik, node_exporter menyediakan metrik node_mountstats_* (mis. node_mountstats_nfs_events) yang menunjukkan health mount: retransmission, RPC errors, dll.
sum by (device) (rate(node_mountstats_nfs_events[5m]))Beberapa alert yang wajib dipasang lebih dulu:
| Alert | Ekspresi (contoh) | Makna |
|---|---|---|
| PVC hampir penuh | kubelet_volume_stats_used_bytes / kubelet_volume_stats_available_bytes > 0.85 | Kapasitas menipis |
| NFS down / mount error | node_mountstats_nfs_events{error} > 0 selama N menit | Server bermasalah |
| Pod Pending karena PVC | kube_pod_status_phase{phase="Pending"} > 0 | Volume tak bisa provision |
| Node disk penuh | node_filesystem_avail_bytes{fstype!~"tmpfs"} < 0.15 * node_filesystem_size_bytes | Disk host habis |
Alert penting yang tidak boleh dilewatkan: PersistentVolumeClaimPending — status Pending berkepanjangan biasanya berarti StorageClass salah atau NFS tidak dapat dijangkau.
groups:
- name: storage.rules
rules:
- alert: PersistentVolumeClaimPending
expr: kube_persistentvolumeclaim_status_phase{phase="Pending"} == 1
for: 10m
labels:
severity: warning
annotations:
summary: "PVC {{ $labels.persistentvolumeclaim }} pending lebih dari 10 menit"Note
Alerting harus disertai aksi yang jelas: ke mana notifikasi pergi (Slack/Telegram), siapa yang on-call, dan runbook apa yang dipakai (episode 24). Alert tanpa ownership adalah noise.
Metrik memberi tahu apa, log memberi tahu mengapa. Untuk storage:
kubectl get events --field-selector involvedObject.kind=PersistentVolumeClaim
kubectl get events --field-selector involvedObject.kind=PersistentVolumeEvent-container ini menjelaskan mengapa PVC Pending (mis. "no volume plugin matched") atau mengapa mount gagal.
Saat menata Grafana, kelompokkan menjadi beberapa fokus:
node_mountstats_nfs_* per node; terlihat mana worker yang memaksa server.node_filesystem_mountpoint naik-turun menandakan remount/lepas yang abnormal.kubelet_volume_stats_* per PVC: siapa yang hampir penuh, siapa yang harus di-expand (episode 16).Pada episode 18 ini, storage kalian kini terlihat, terukur, dan ter-alarm:
Inti yang harus dibawa pulang:
PersistentVolumeClaimPending, node disk penuh.kubectl get events untuk volume.Di episode 19 selanjutnya kita akan menskalakan aplikasi secara horizontal: menambah replica dengan kubectl scale dan HPA, mengenali tanda NFS sebagai bottleneck, memindahkan session/cache ke Redis, serta kapan harus pindah ke distributed storage. Sampai jumpa di episode 19!