Perencanaan Kapasitas Disk untuk Bisikan / Grafit

14

Apakah ada yang punya rumus, atau mungkin beberapa sampel data dari lingkungan mereka yang dapat membantu saya memperkirakan berapa banyak ruang disk yang akan digunakan oleh grafit per titik data?

monitoring graphite

— Kyle Brandt
sumber

2

Pastikan Anda merencanakan I / O disk Anda dengan benar juga, dan bukan hanya kapasitas disk Anda. rrdtool telah, selama bertahun-tahun, mengumpulkan banyak optimasi mikro yang membuatnya jauh lebih cepat (2x lebih cepat?) pada penulisan daripada format basis data Whisper Graphite. Jika Anda berencana untuk menyimpan semua data Anda pada SSD yang layak, itu akan membuat Anda mendapatkan sebagian besar perjalanan ke sana, tapi saya tidak akan berencana untuk menyimpan seluruh ton Whisper DB pada disk pemintalan. Pada skala, itu tidak efektif biaya bahwa tingkat I / O disk yang melempar Graphite.

— jgoldschrafe

7

whisper-info.py memberi Anda banyak wawasan tentang apa dan bagaimana setiap file digabungkan, termasuk ukuran file.

Namun itu hanya berguna untuk file bisikan yang ada.

Ketika Anda ingin melihat ukuran prediksi suatu skema sebelum menerapkannya, coba Kalkulator Bisikan, seperti yang tersedia di https://gist.github.com/jjmaestro/5774063

EDIT:

Saat ditanya contoh ...

storage_schema:

{
    :catchall => {
      :priority   => "100",
      :pattern    => "^\.*",
      :retentions => "1m:31d,15m:1y,1h:5y"
    }
}

Melihat file saya applied-in-last-hour.wsp, ls -lhasil

-rwxr-xr-x 1 root root 4415092 Sep 16 08:26 applied-in-last-hour.wsp

dan whisper-info.py ./applied-in-last-hour.wsphasil

maxRetention: 157680000
xFilesFactor: 0.300000011921
aggregationMethod: average
fileSize: 4415092

Archive 0
retention: 604800
secondsPerPoint: 10
points: 60480
size: 725760
offset: 52

Archive 1
retention: 2678400
secondsPerPoint: 60
points: 44640
size: 535680
offset: 725812

Archive 2
retention: 157680000
secondsPerPoint: 600
points: 262800
size: 3153600
offset: 1261492

Jadi, pada dasarnya Anda menggabungkan host Anda per pertandingan-retensi per segmen-retensi-periode per stat, kalikan dengan faktor sistem yang ingin Anda terapkan juga, faktor dalam jumlah statistik baru yang akan Anda lacak. Kemudian Anda mengambil jumlah penyimpanan berapa pun dan setidaknya menggandakannya (karena kami membeli penyimpanan, dan kami tahu kami akan menggunakannya ...)

— gWaldo
sumber

Setiap kesempatan Anda memiliki beberapa nomor sampel dari itu (dipasangkan dengan pengaturan retensi). Saat ini saya sedang berpikir tentang penyimpanan data deret waktu yang berbeda dalam hal penggunaan disk - jadi dapatkan grafit langsung untuk itu sedikit berlebihan.

— Kyle Brandt

Jawaban @KyleBrandt diperbarui.

— gWaldo

Terima kasih untuk ini. Jadi dengan filesize, apakah itu setelah satu jam pengumpulan data, atau apakah filesize itu akan selalu seperti itu? Jadi, apakah 4415092 mewakili data retensi 5 tahun ini, atau apakah representatif data 1 jam itu 1 jam? Juga, apakah itu byte atau bit?

— Kyle Brandt

Ini adalah implementasi baru di perusahaan ini, dan saya tidak memiliki akses ke yang lama. Karena hasil fileSize tingkat atas cocok dengan ls -lhasilnya, saya menganggapnya sebagai byte. Ketika saya menjumlahkan ukuran arsip dalam file .wsp (seperti yang dilaporkan oleh whisper-info.py), mereka mendekati ukuran file .wsp keseluruhan (sisanya saya anggap sebagai metadata dan semacamnya. Ini harus menjadi ukuran file untuk semua waktu, saat data jatuh ke resolusi data yang lebih rendah, dan titik data lama dibuang

— gWaldo

Oke, begitu dengan pengaturan retensi ini. Secara kasar:ServerCount * MetricCount * 4.5MBytes

— Kyle Brandt

2

Dalam dokumentasi untuk statsd mereka memberikan contoh untuk kebijakan penyimpanan data.

Retensi adalah 10s:6h,1min:7d,10min:5yyang 2160 + 10080 + 262800 = 275040 poin data dan mereka memberikan ukuran arsip 3,2 MiB .

Dengan asumsi hubungan linier, ini akan menjadi sekitar 12,2 Bytes per titik data .

— AndreKR
sumber

ops-school.readthedocs.org/en/latest/monitoring_201.html (timestamp, value) pasangan disimpan sebagai nilai panjang dan ganda yang menghabiskan 12 byte per pasangan. Perbedaan 0,2 mungkin karena informasi metadata file overhead ?!

— user27465

1

Tidak ada pengalaman langsung dengan Graphite, tapi saya membayangkan logika yang sama seperti yang kami gunakan untuk Cacti atau apa pun RRD atau time-rollover driven akan berlaku (Graphite tidak menggunakan RRD secara internal lagi tetapi logika penyimpanan tampaknya sebanding.)

Jawaban singkatnya adalah, "Mungkin tidak banyak ruang yang Anda pikir Anda perlukan."

Jawaban panjangnya melibatkan beberapa matematika khusus situs. Untuk sistem pemantauan kami (InterMapper) saya mencari tahu periode retensi, resolusi, dan ukuran titik data, melakukan beberapa perkalian, dan menambahkan overhead.

Sebagai contoh, saya akan menggunakan ruang disk - kami menyimpan angka dengan presisi 5 menit selama 30 hari, presisi 15 menit selama 60 hari, dan kemudian presisi per jam selama 300 hari berikutnya, dan kami menggunakan 64 integer-bit (8 byte) untuk menyimpannya:

Total 21600 sampel, dipecah menjadi:
- 8640 sampel untuk presisi 5 hari 30 hari
- 5760 sampel untuk presisi 60 hari 15 menit
- 7200 sampel untuk 300 hari presisi 1 jam

Pada 8 byte per sampel yang sekitar 173KB, ditambah overhead yang sehat untuk pengindeksan penyimpanan dan sejenisnya membawanya ke sekitar 200KB untuk data penggunaan disk satu partisi (setiap kesalahan cenderung berlebihan).

Dari metrik dasar saya dapat menghitung ukuran rata-rata "per mesin" (10 partisi disk, ruang swap, RAM, rata-rata beban, transfer jaringan, dan beberapa hal lainnya) - berhasil sekitar 5MB per mesin.

Saya juga menambahkan 10% sehat di atas angka akhir dan mengumpulkan, jadi saya ukuran barang di 6MB per mesin.

Lalu saya melihat ruang 1TB yang telah saya tempatkan untuk menyimpan data metrik untuk pembuatan bagan dan berkata, "Ya, saya mungkin tidak kehabisan penyimpanan dalam hidup saya kecuali kita tumbuh banyak!" :-)

— voretaq7
sumber

1

Untuk melempar nomor dari praktik sebenarnya di luar sana, dengan kebijakan retensi produksi saya (9 bulan pada 5 menit; 1 tahun setiap jam; 5 tahun setiap hari) dan sekitar 20 mesin dengan ~ 20 masing-masing metrik 8-byte, ditambah peringatan / alarm / histori / pemadaman acara selama 5 tahun saya menggunakan ruang disk 1,5G. Itu dengan InterMapper memasukkan semuanya ke dalam database Postgres. Jadi sekali lagi - jawaban cepatnya adalah "Mungkin tidak banyak ruang yang Anda pikir Anda perlukan" :-)

— voretaq7

Ya, matematika itu mudah, saya benar-benar hanya melihat lebih banyak tentang bagaimana Graphite menyimpan data itu - dapat membuat perbedaan besar pada skala. Satu-satunya hal yang saya temukan adalah bahwa menurut dokumen itu tidak sangat efisien ruang (Mungkin karena mengandalkan rollup yang cukup agresif).

— Kyle Brandt

Bisikan (Graphite back-end storage menggunakan) memiliki beberapa item ruang-mengunyah built-in - Anda mungkin sudah melihat halaman itu. Bagian tentang "Arsip periode waktu tumpang tindih" menonjol bagi saya karena itu berarti arsip lebih besar dari contoh saya di atas karena mereka semua kembali ke awal waktu (arsip 60 hari sebenarnya 90 hari panjang; arsip 300 hari adalah Panjang 390 hari). Whisper juga menyimpan stempel waktu (4 atau 8 byte) bersama dengan setiap titik data yang perlu ditambahkan juga. Tidak terlihat rumit, hanya membengkak :)

— voretaq7

0

Saya memiliki 70 node yang menghasilkan banyak data. Menggunakan Carbon / Whisper, satu node membuat 91k file saja (node menghasilkan beberapa skema masing-masing memiliki beberapa penghitung dan bidang variabel yang perlu dipilih. Misalnya: (nodename). (Skema). (Skema). (Penghitung). (Subkounter). (Dll )....dan seterusnya).

Ini memberikan rincian yang saya butuhkan untuk merencanakan grafik apa pun yang saya inginkan. Setelah menjalankan skrip untuk mengisi 69 node yang tersisa, saya memiliki 1,3Tb data pada disk. Dan itu hanya bernilai 6 jam data / node. Apa yang membuat saya adalah file csv flat sebenarnya untuk data 6hrs adalah sekitar 230Mb / node. 70 node adalah ~ 16Gb data. Skema penyimpanan saya adalah 120-an: 365d.

Saya relatif baru di database, jadi saya mungkin melakukan sesuatu yang salah, tapi saya kira itu semua overhead untuk setiap sampel.

Jadi itu adalah eksperimen yang menyenangkan, tapi saya pikir tidak masuk akal untuk menggunakan bisikan untuk jenis data yang saya simpan. MongoDB sepertinya solusi yang lebih baik, tapi saya perlu mencari cara menggunakannya sebagai backend ke Grafana.

— musca999
sumber