Vì sao hệ giám sát chỉ chịu nhận số byte thô
Bộ thu thập số liệu không quan tâm tới tiền tố đơn vị. node_filesystem_avail_bytes, container_memory_usage_bytes, số khối phía sau một hạn mức ổ đĩa — tất cả đều là số nguyên byte. Ngay khi câu "cảnh báo khi ổ dữ liệu còn trống dưới 50 GB" phải biến thành thứ mà tệp quy tắc hay một đoạn kịch bản quota tính được, câu đó buộc phải viết lại bằng chữ số.
50 × 1.000.000.000 = 50.000.000.000, nên biểu thức viết thành node_filesystem_avail_bytes{mountpoint="/data"} < 50000000000.Đồng hồ luôn xuất theo đơn vị nền
_bytes chứa byte và chỉ byte. Bảng điều khiển mới gắn tiền tố dễ đọc lúc hiển thị; chuỗi dữ liệu lưu lại vẫn là số thô.Thiếu một số 0 là thành sự cố
Một con số rơi vào ba chỗ
Lấy con số dán thẳng được vào tệp quy tắc
Nhập ngưỡng theo cách người ta hay nói
Gõ con số gigabyte lấy từ phiếu yêu cầu dung lượng — 5, 20, 50, 250. Số lẻ cũng được: 2,5 GB nhận cả dấu phẩy lẫn dấu chấm.
Đọc số byte tương ứng
Bên byte cập nhật ngay, chữ số được tách nhóm bằng khoảng trắng để bạn liếc qua là biết độ lớn. Từ 10 GB trở lên phần hiển thị chuyển sang dạng lũy thừa, và PromQL nhận dạng 1e10 không vấn đề gì.
Sao chép con số, không kèm định dạng
Nút Sao chép trả về số trần, không đơn vị và không khoảng trắng phân nhóm — đúng thứ một biểu thức YAML, một giá trị JSON hay một biến trong shell đang cần.
Đọc ngược một đồng hồ có sẵn
Bấm Đảo đơn vị, hoặc đơn giản là gõ thẳng vào ô byte, và một giá trị lấy về từ điểm cuối metrics sẽ quay lại thành gigabyte để bạn ghi vào biên bản sự cố.
Hai chiều trên cùng một trang: hai ô đều là ô nhập độc lập, nên bạn hoàn toàn có thể dán 17 179 869 184 từ bảng điều khiển vào bên byte để thấy nó xấp xỉ 17,18 GB, rồi chỉnh bên gigabyte cho tới khi ra con số ngưỡng tròn trịa mà bạn muốn dùng làm chuẩn.
Bảng ngưỡng cho quy tắc cảnh báo và hạn mức
Đây là những con số gigabyte tròn cứ lặp đi lặp lại trong tệp quy tắc và kịch bản quota. Cảnh báo dung lượng trống hay được viết theo phần trăm, nhưng chính mức sàn tuyệt đối tính bằng byte mới ngăn được cảnh một mảng 20 TB chỉ báo động khi còn 200 GB — tức là còn đúng một giờ ghi dữ liệu.
| Ngưỡng | Byte | Thường dùng ở đâu |
|---|---|---|
| 1 GB | 1.000.000.000 | Cảnh báo tối khẩn cuối cùng trên phân vùng gốc nhỏ |
| 5 GB | 5.000.000.000 | Cảnh báo trên hệ tệp overlay của máy chủ chạy container |
| 10 GB | 10.000.000.000 | Mức sàn dung lượng trống dưới thư mục dữ liệu cơ sở dữ liệu |
| 20 GB | 20.000.000.000 | Giới hạn cứng cho một thư mục cá nhân |
| 50 GB | 50.000.000.000 | Hạn mức từng dự án trên máy chủ dựng dùng chung |
| 100 GB | 100.000.000.000 | Kiểm tra dư địa trước khi phục hồi dữ liệu hàng loạt |
| 250 GB | 250.000.000.000 | Trần hoạch định dung lượng cho ổ chứa gói dựng |
Kết quả đúng dạng một biểu thức cần
Sao chép chỉ cho chữ số — không phải cắt gọt gì, không có hậu tố nào làm rối bộ phân tích vốn chỉ muốn một con số ở vế phải phép so sánh.
Giải mã một cảnh báo đang bắn
Khi thông báo mang theo giá trị đồng hồ thô, đưa nó vào ô byte và đọc lại số gigabyte trước khi viết dòng diễn biến sự cố.
Đơn vị nhị phân khi công cụ đòi hỏi
Một số hệ thống con đếm theo bội số 1 024. Cả hai danh sách đơn vị đều có GiB, MiB và KiB, nên chuyện lệch đơn vị chỉ cách một lần chọn.
Một lần soi lại dãy số 0
Chữ số tách nhóm khiến 50 000 000 000 nhìn khác hẳn 5 000 000 000 — đúng cái mà một lượt duyệt mã hiếm khi bắt được ở dãy số nguyên dài.
Câu hỏi từ sổ tay cảnh báo
Vì sao node_filesystem_avail_bytes không bao giờ báo theo gigabyte?
Quy ước đặt tên của Prometheus yêu cầu mọi chỉ số dùng đơn vị nền và nêu đơn vị đó ngay ở hậu tố, nhờ vậy một chuỗi dữ liệu vẫn so sánh được giữa những máy có kích cỡ rất khác nhau. Tiền tố chỉ là chuyện trình bày lúc vẽ đồ thị. Cũng lưu ý rằng đồng hồ avail đã trừ phần khối dành riêng cho root, nên đây mới là chỉ số nên cảnh báo chứ không phải node_filesystem_free_bytes.
Cảnh báo ổ đĩa nên đặt mức sàn byte cố định hay theo phần trăm?
Phần trăm dùng chung cho cả đội máy rất tiện — cặp 80% cảnh báo, 90% nghiêm trọng là phổ biến — nhưng 10% của một ổ 4 TB là 400 GB, hoặc quá lãng phí hoặc quá muộn tùy tốc độ ghi. Nhiều đội chạy song song cả hai: một quy tắc phần trăm để bắt xu hướng, và một mức sàn tuyệt đối chẳng hạn 50.000.000.000 byte để khi báo động vẫn còn quỹ thời gian dự đoán được.
Vì sao df và du lại lệch nhau trên cùng một hệ tệp?
du duyệt các mục trong thư mục rồi cộng lại những gì nó thấy; df hỏi thẳng hệ tệp xem đang cấp phát bao nhiêu khối. Một tệp đã bị xóa trong khi tiến trình vẫn giữ nó mở thì đã rời khỏi cây thư mục nhưng vẫn chiếm khối, còn phần dành riêng cùng siêu dữ liệu thì chỉ mình df tính. Chênh nhau vài gigabyte thường là do tệp còn bị giữ mở, không phải lỗi.
Công cụ đặt hạn mức muốn nhận đơn vị nào khi tôi đặt giới hạn?
setquota cổ điển nhận số khối, và khối của nó là 1 KiB — nên giới hạn mềm 50 GB tương đương 50.000.000.000 ÷ 1.024 = 48.828.125 khối. Một số nền tảng khác lại nhận hậu tố. Quy đổi ra byte trước cho bạn một con số gốc duy nhất để chia xuống cho bất kỳ công cụ nào đang dùng, thay vì ba con số xấp xỉ khác nhau.
Tôi ghi thẳng "50GB" vào YAML rồi để nó tự hiểu có được không?
Chỉ được ở nơi chương trình đọc tệp có tài liệu ghi rõ nó phân tích hậu tố, mà những chỗ đó hiếm khi thống nhất — nơi hiểu G là một tỷ, nơi hiểu là 230, còn phép so sánh trong PromQL thì không nhận hậu tố nào cả. Trong một giá trị JSON hay YAML thuần, nó chỉ là chuỗi ký tự, và lược đồ chặt sẽ từ chối. Một số nguyên tường minh kèm chú thích ghi rõ con số gigabyte thì không bao giờ làm ai bất ngờ.
Chưa có bình luận nào. Hãy là người đầu tiên!