Mengapa Sistem Pemantauan Menuntut Angka Byte Mentah
Sebuah exporter tidak punya pendapat soal awalan satuan. node_filesystem_avail_bytes, container_memory_usage_bytes, hitungan blok di balik kuota sistem berkas — semuanya bilangan bulat byte polos. Begitu kalimat "beri peringatan saat sisa ruang volume data turun di bawah 50 GB" harus berubah menjadi sesuatu yang bisa dievaluasi berkas aturan atau skrip kuota, kalimat itu perlu ditulis ulang sebagai deretan angka.
50 × 1.000.000.000 = 50.000.000.000, sehingga ekspresinya berbunyi node_filesystem_avail_bytes{mountpoint="/data"} < 50000000000.Metrik Dikirim dalam Satuan Dasar
_bytes berisi byte dan tidak lain. Dasbor menambahkan awalan yang nyaman dibaca manusia saat menampilkan; deret yang tersimpan tetap mentah.Kurang Satu Nol Berujung Insiden
Angka yang Sama Mendarat di Tiga Tempat
Menyiapkan Angka Siap Tempel untuk Berkas Aturan
Masukkan Ambang Seperti Diucapkan Manusia
Ketik angka gigabyte dari tiket kapasitas — 5, 20, 50, 250. Pecahan pun bisa: 2,5 GB terbaca baik dengan koma maupun titik.
Baca Jumlah Byte-nya
Sisi byte diperbarui seketika, dengan digit dikelompokkan spasi supaya besarannya terbaca sekilas. Mulai 10 GB ke atas tampilan beralih ke notasi ilmiah, yang diterima PromQL apa adanya sebagai 1e10.
Salin Bilangan Bulatnya, Bukan Formatnya
Tombol Salin mengembalikan angka telanjang tanpa satuan dan tanpa spasi pengelompok — persis yang diharapkan sebuah ekspresi YAML, nilai JSON, atau variabel shell.
Baca Mundur Metrik yang Sudah Berjalan
Gunakan Tukar satuan, atau cukup ketik di kolom byte, dan nilai yang Anda ambil dari endpoint metrik kembali dalam gigabyte yang layak ditulis di catatan insiden.
Dua arah, satu halaman: kedua kolom adalah masukan mandiri, jadi tidak ada yang melarang Anda menempelkan 17.179.869.184 dari dasbor ke sisi byte untuk menemukan bahwa itu sekitar 17,18 GB, lalu menyetel sisi gigabyte sampai ketemu ambang bulat yang ingin Anda bakukan.
Tabel Ambang untuk Aturan Peringatan dan Kuota
Inilah angka gigabyte bulat yang terus muncul di berkas aturan dan skrip kuota. Peringatan sisa ruang sering ditulis sebagai persentase, tetapi batas bawah byte yang absolutlah yang mencegah larik 20 TB baru memanggil piket ketika tersisa 200 GB — setara satu jam ingest.
| Ambang | Byte | Biasanya dipakai di mana |
|---|---|---|
| 1 GB | 1.000.000.000 | Panggilan kritis pilihan terakhir pada volume root kecil |
| 5 GB | 5.000.000.000 | Peringatan dini pada sistem berkas overlay host kontainer |
| 10 GB | 10.000.000.000 | Batas bawah sisa ruang di direktori data basis data |
| 20 GB | 20.000.000.000 | Batas keras untuk satu direktori home pengguna |
| 50 GB | 50.000.000.000 | Kuota per proyek di server build bersama |
| 100 GB | 100.000.000.000 | Pemeriksaan ruang lega sebelum pemulihan massal |
| 250 GB | 250.000.000.000 | Plafon perencanaan kapasitas pada volume artefak |
Keluaran yang Pas untuk Sebuah Ekspresi
Salin memberi digitnya saja — tidak ada yang perlu dipangkas, tidak ada akhiran yang membingungkan pengurai yang hanya mau angka di sisi kanan perbandingan.
Membaca Peringatan yang Sedang Berbunyi
Ketika notifikasi membawa nilai metrik mentah, masukkan ke kolom byte dan baca gigabyte-nya sebelum menulis entri linimasa insiden.
Satuan Biner Saat Perkakas Memaksa
Sebagian subsistem menghitung dengan basis 1.024. Kedua daftar satuan memuat GiB, MiB, dan KiB, jadi ketidakcocokan tinggal sekali pilih untuk selesai.
Sepasang Mata Kedua untuk Deretan Nol
Digit yang dikelompokkan membuat 50.000.000.000 tampak jelas berbeda dari 5.000.000.000 — pemeriksaan yang jarang tertangkap saat mengulas literal bilangan panjang.
Pertanyaan dari Buku Aturan Peringatan
Kenapa node_filesystem_avail_bytes tidak pernah melaporkan gigabyte?
Konvensi penamaan Prometheus meminta setiap metrik memakai satuan dasar dan menyebutkannya di akhiran nama, sehingga satu deret tetap sebanding antarmesin yang ukurannya jauh berbeda. Awalan satuan adalah urusan penyajian yang diterapkan saat render. Perhatikan juga bahwa metrik avail tidak menghitung blok yang dicadangkan untuk root, jadi metrik itulah yang sebaiknya dijadikan dasar peringatan, bukan node_filesystem_free_bytes.
Peringatan disk sebaiknya memakai batas byte tetap atau persentase?
Persentase mudah dipakai di seluruh armada — pasangan 80% untuk peringatan dini dan 90% untuk kritis adalah yang lazim — tetapi 10% dari volume 4 TB berarti 400 GB, entah terlalu boros atau justru jauh terlambat tergantung laju penulisan. Banyak tim memakai keduanya: aturan persentase untuk memantau tren, plus batas bawah absolut semisal 50.000.000.000 byte agar panggilan piket datang dengan sisa waktu yang bisa diperkirakan.
Kenapa df dan du berbeda pendapat pada sistem berkas yang sama?
du menyusuri entri direktori dan menjumlahkan apa yang terlihat; df bertanya kepada sistem berkas berapa blok yang teralokasi. Berkas yang dihapus selagi sebuah proses masih membukanya sudah lenyap dari pohon direktori tetapi tetap memakai blok, dan ruang cadangan plus metadata hanya tercatat oleh df. Selisih beberapa gigabyte biasanya berarti ada berkas yang masih dipegang terbuka, bukan bug.
Satuan apa yang diminta perkakas kuota saat saya menetapkan batas?
setquota klasik menerima hitungan blok, dan satu bloknya berukuran 1 KiB — jadi batas lunak 50 GB berarti 50.000.000.000 ÷ 1.024 = 48.828.125 blok. Perkakas lain justru menerima akhiran satuan. Mengonversi ke byte lebih dulu memberi Anda satu angka acuan yang tinggal dibagi sesuai perkakas yang sedang dipakai, alih-alih tiga hasil kira-kira.
Bisakah saya menulis "50GB" saja di YAML dan membiarkannya beres sendiri?
Hanya jika program yang membacanya memang mendokumentasikan pengurai akhiran, dan penguraian itu jarang seragam — ada yang membaca G sebagai satu miliar, ada yang membacanya sebagai 230, sedangkan perbandingan PromQL sama sekali tidak menerima akhiran. Di dalam nilai JSON atau YAML biasa, itu cuma teks, dan skema yang ketat akan menolaknya. Bilangan bulat eksplisit dengan komentar yang menyebut angka gigabyte-nya tidak pernah mengejutkan siapa pun.
Belum ada komentar. Jadilah yang pertama berkomentar!