Menghitung Kecepatan Disk dari node_exporter

Momen yang Salah Paham

Saya ingat betul momen saat menjalankan playbook Ansible ke beberapa server produksi. Dashboard yang saya harapkan menampilkan kecepatan baca/tulis disk dalam KB/s, tapi yang muncul malah angka raksasa. Tebakan awal saya? Ada bug di skrip Python atau konfigurasi node_exporter yang rusak. Ternyata, saya salah total. Angka itu bukan error, melainkan cumulative counter — total byte sejak server dinyalakan — dari metrik node_disk_read_bytes_total (sumber). Metrik dari node_exporter memang dirancang sebagai data mentah dalam bentuk counter dan durasi terakumulasi. Di sinilah saya sadar bahwa mengambil data mentah tanpa pemrosesan tambahan tidak akan pernah memberikan laju yang bisa dibaca manusia.

Counter Kumulatif dan Rumus Dua Sampel

Ketika Anda membaca node_disk_read_bytes_total, Anda tidak sedang melihat kecepatan saat ini. Anda sedang melihat total akumulasi byte yang pernah dibaca kernel sejak booting — mirip odometer di mobil yang kasih tahu total jarak tempuh, bukan kecepatan dalam km/jam. Prometheus memang punya fungsi rate() yang otomatis menangani perhitungan ini, lengkap dengan penanganan reset counter. Tapi kalau Anda mengumpulkan metrik secara manual lewat Ansible untuk konsistensi di seluruh fleet (sumber), Anda harus membangun logika itu sendiri.

Solusinya sederhana. Ambil sampel pertama, tunggu selama interval 2 detik, lalu ambil sampel kedua. Rumusnya cuma (bytes_akhir - bytes_awal) / delta_detik. Saya menerapkan pola ini untuk empat metrik sekaligus: disk read bytes, disk written bytes, network receive bytes, dan network transmit bytes — semuanya dari node_exporter. Hasilnya? Dashboard langsung menampilkan angka realistis dalam KB/s untuk disk dan jaringan, bukan angka astronomis.

Kuncinya ada di dua hal. Pertama, pastikan Anda membaca counter yang benar — di Linux, kernel menyediakan data disk I/O melalui /proc/diskstats dalam format field yang masing-masing mapper ke metrik Prometheus secara langsung (sumber). Kedua, interval 2 detik sudah cukup untuk dashboard monitoring operational; lebih pendek membebani SSH, lebih panjang data terasa telat.

Dari 9 server di fleet, 8 belum terpasang node_exporter. Daripada play Ansible gagal di semua server yang belum siap, saya menambahkan penanganan elegan: jika probe tidak tersedia, kembalikan absent sebagai nilai. Tidak error, tidak warning, tidak ganggu skor kesehatan. Server yang sudah terpasang melaporkan 14 metrik termasuk disk r/w KB/s, net rx/tx KB/s, swap%, dan load1 — server yang belum? Cukup dilewati.

Saya juga menemui varian satu sampel untuk metrik yang sifatnya bukan kumulatif. Swap usage dan load average bisa dibaca langsung karena nilainya sudah merupakan snapshot saat ini — tidak perlu dikurangi dengan sampel sebelumnya. Ini kontras penting: developer yang terbiasa dengan counter Prometheus sering menganggap semua metrik butuh rate(), padahal gauge tidak butuh.

Pelajaran dari seluruh proses ini: jangan pernah percaya angka mentah dari exporter tanpa memahami konteks sumber datanya. Kernel Linux menyediakan data yang sangat kaya, tapi interpretasinya sepenuhnya ada di tangan Anda (sumber). Pola delta dua sampel adalah fungsi rate() versi sederhana yang andal untuk pipeline observabilitas kustom. Kecepatan disk dan jaringan yang berguna bagi tim operasional adalah laju perubahan, bukan total seumur hidup server.

Sumber

1. Brian Candler, "Interpreting Prometheus metrics for Linux disk I/O utilization", Medium (diakses 2026-09-16).
2. prometheus/node_exporter, "Exporter for machine metrics", GitHub (diakses 2026-09-16).
3. OpsTree, "Automating Node Exporter and VMagent Deployment with Ansible", opstree.com (diakses 2026-09-16).