menghitung hari sampai disk penuh


9

Kami menggunakan grafit untuk melacak riwayat pemanfaatan disk dari waktu ke waktu. Sistem peringatan kami melihat data dari grafit untuk memberi tahu kami ketika ruang kosong berada di bawah sejumlah blok tertentu.

Saya ingin mendapatkan peringatan yang lebih cerdas - yang benar-benar saya pedulikan adalah "berapa lama saya sebelum saya harus melakukan sesuatu tentang ruang kosong?", Misalnya jika tren menunjukkan bahwa dalam 7 hari saya akan kehabisan disk space lalu naikkan Peringatan, jika kurang dari 2 hari maka naikkan Kesalahan.

Antarmuka dasbor standar Graphite bisa sangat pintar dengan turunan dan band-band Holt Winters Confidence, tetapi sejauh ini saya belum menemukan cara untuk mengubahnya menjadi metrik yang dapat ditindaklanjuti. Saya juga baik-baik saja dengan menghitung angka dengan cara lain (cukup ekstrak angka mentah dari grafit dan jalankan skrip untuk melakukan itu).

Salah satu komplikasi adalah grafiknya tidak mulus - file dapat ditambahkan dan dihapus tetapi tren umum dari waktu ke waktu adalah penggunaan ruang disk meningkat, jadi mungkin ada kebutuhan untuk melihat minimum lokal (jika melihat metrik "disk bebas" ) dan menggambar tren di antara palung.

Adakah yang melakukan ini?


apa infrastrukturmu? Sebagai contoh, jika Anda seorang vmware house, Anda dapat melihat produk mereka Operations Manager yang melakukan semacam ini pandangan prediktif pada ruang disk.
Chopper3

The volume of crap people have to store will expand to fill the disk available.- Old Sysadmin Axiom
voretaq7

Server kami terbagi antara VMware VM yang menggunakan IBM XIV untuk disk, dan KVM menggunakan SD lokal. Saya tidak yakin kami memiliki akses ke informasi semacam itu (tim saya tidak mengelola VMware atau XIV) dan akan lebih suka solusi independen-produk.
Amos Shapira

Jawaban:


8

Jujur "Hari Sampai Penuh" sebenarnya adalah metrik yang buruk - sistem file mendapatkan SANGAT BODOH ketika mereka mendekati pemanfaatan 100%.
Saya benar-benar merekomendasikan menggunakan batas tradisional 85%, 90%, 95% (peringatan, alarm, dan kritis Anda-benar-benar perlu memperbaiki-ini-SEKARANG, masing-masing) - ini akan memberi Anda banyak waktu peringatan pada disk modern (katakanlah drive 1TB: 85% dari terabyte masih menyisakan banyak ruang tetapi Anda menyadari masalah potensial, sebesar 90% Anda harus merencanakan perluasan disk atau mitigasi lainnya, dan pada 95% terabyte Anda memiliki 50GB tersisa dan harus benar-benar memperbaiki gerakan).

Ini juga memastikan bahwa sistem file Anda berfungsi lebih atau kurang optimal: ia memiliki banyak ruang kosong untuk berurusan dengan membuat / memodifikasi / memindahkan file besar.

Jika disk Anda tidak modern (atau pola penggunaan Anda melibatkan jumlah data yang lebih besar yang dilemparkan ke disk) Anda dapat dengan mudah menyesuaikan ambang batas.


Jika Anda masih menggunakan metrik "hari sampai penuh", Anda dapat mengekstrak data dari grafit dan menghitungnya. Alat pemantauan IBM menerapkan metrik beberapa hari-hingga-penuh yang dapat memberi Anda gagasan tentang bagaimana menerapkannya, tetapi pada dasarnya Anda mengambil tingkat perubahan antara dua poin dalam sejarah.

Demi kewarasan Anda, Anda dapat menggunakan turunan dari Graphite (yang akan memberi Anda tingkat perubahan dari waktu ke waktu) dan proyek menggunakan itu, tetapi jika Anda BENAR-BENAR ingin peringatan "lebih cerdas" Saya sarankan menggunakan tingkat perubahan harian dan mingguan (dihitung berdasarkan pemakaian puncak untuk hari / minggu).

Proyeksi spesifik yang Anda gunakan (laju perubahan terkecil, laju perubahan terbesar, laju perubahan rata-rata, rata-rata tertimbang, dll.) Tergantung pada lingkungan Anda. Alat-alat IBM menawarkan begitu banyak pandangan berbeda karena sangat sulit untuk menemukan pola satu ukuran untuk semua.


Pada akhirnya tidak ada algoritma yang akan sangat baik dalam melakukan perhitungan seperti yang Anda inginkan. Pemanfaatan disk didorong oleh pengguna, dan pengguna adalah antitesis dari model Aktor Rasional: Semua prediksi Anda dapat keluar dari jendela dengan satu orang gila yang memutuskan bahwa hari ini adalah hari mereka akan melakukan dump memori sistem lengkap ke sistem mereka. direktori rumah. Hanya karena.


Terima kasih atas wawasan Anda. Saya melihat poin Anda. Saya masih berpikir bahwa ambang konstan hanya mencoba untuk mencerminkan "berapa lama saya harus memulihkan?" dan merasa agak dibenarkan oleh komentar "sesuaikan ambang Anda". Turunan grafit sederhana tidak berfungsi karena grafik aslinya tidak mulus. Terima kasih atas penunjuk ke alat IBM, apa yang Anda gambarkan terdengar seperti apa yang saya mulai pikirkan (ekstrak dua minimum terakhir dan hitung kemiringan darinya).
Amos Shapira

Tentunya titik metrik 'hari ke penuh' adalah bahwa, dengan ambang 85/90/95 statis, Anda tidak tahu seberapa cepat disk mengisi? Tentu, Anda mengetahui adanya masalah potensial, tetapi bagaimana Anda bisa tahu apakah Anda punya hari untuk mengatasinya, atau minggu / bulan?

Saya merasa sangat menarik bahwa Anda akan memiliki pendapat ini. Biarkan saya membingkai seperti ini: Perusahaan Anda memiliki proses pengadaan yang membutuhkan waktu sekitar 6 minggu antara permintaan awal untuk lebih banyak hard drive hingga hari ketika hard drive tersebut sebenarnya dipasang di dalam kotak dan memuat redistribusi mulai terjadi. Mengingat bahwa jangka waktu 6 minggu pada disk% apa yang perlu Anda beri tahu agar disk dapat dipasang pada waktunya? 80%? 75%? Faktanya adalah bahwa Anda tidak tahu kecuali Anda berupaya menghitung tingkat pertumbuhan.
JHixson

2

Kami baru-baru ini meluncurkan solusi khusus untuk ini menggunakan regresi linier.

Dalam sistem kami, sumber utama kelelahan disk adalah file-file log liar yang tidak diputar.

Karena ini tumbuh sangat dapat diprediksi, kita dapat melakukan regresi linier pada pemanfaatan disk (misalnya, z = numpy.polyfit(times, utilization, 1)) kemudian menghitung tanda 100% yang diberikan model linier (misalnya, (100 - z[1]) / z[0])

Implementasi yang dikerahkan terlihat seperti ini menggunakan ruby ​​dan GSL, meskipun numpy bekerja dengan sangat baik.

Memberi makan ini data rata-rata pemanfaatan seminggu dengan interval 90 menit (112 poin) telah mampu memilih kandidat yang mungkin mengalami kelelahan disk tanpa terlalu banyak kebisingan sejauh ini.

Kelas dalam inti dibungkus dalam kelas yang menarik data dari pengintai, peringatan untuk mengendur dan mengirimkan beberapa telemetri runtime ke statsd. Saya akan meninggalkan sedikit karena itu khusus untuk infrastruktur kami.


Saya telah memperbarui jawabannya dengan beberapa info sekarang setelah kami meluncurkannya.
matschaffer

1
Baru saja menemukan gotcha lucu dengan pendekatan ini. Kami juga memiliki 90% alarm. Salah satu host kami tumbuh secara bertahap hingga mencapai 90% dan memicu alarm itu meskipun masih lebih dari seminggu sebelum mencapai 100% sehingga peringatan prediktif tidak pernah menyala;) Tebak saya harus menggunakan (90 - z[1]) / z[0]sebagai gantinya.
matschaffer
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.