Lập kế hoạch dung lượng đĩa cho Whisper / Graphite


14

Có ai có bất kỳ công thức nào, hoặc có thể một số dữ liệu mẫu từ môi trường của họ có thể giúp tôi ước tính dung lượng đĩa sẽ được sử dụng bởi than chì trên mỗi datapoint không?


2
Hãy chắc chắn rằng bạn đang lập kế hoạch I / O đĩa chính xác, và không chỉ dung lượng đĩa của bạn. Trong những năm qua, rrdtool đã tích lũy rất nhiều tối ưu hóa vi mô giúp nó nhanh hơn rất nhiều (nhanh gấp 2 lần?) so với định dạng cơ sở dữ liệu Whisper của Graphite. Nếu bạn đang dự định lưu giữ tất cả dữ liệu của mình trên ổ SSD tốt, điều đó sẽ giúp bạn đạt được điều đó, nhưng tôi sẽ không có kế hoạch giữ cả tấn DB Whisper trên đĩa quay. Ở quy mô, sẽ không hiệu quả về mặt chi phí khi các mức I / O của đĩa mà Graphite ném ra.
jgoldschrafe

Câu trả lời:


7

whisper-info.py cung cấp cho bạn nhiều thông tin chuyên sâu về nội dung và cách thức mỗi tệp được tổng hợp, bao gồm kích thước của tệp.

Tuy nhiên, nó chỉ hữu ích cho các tập tin thì thầm hiện có.

Khi bạn muốn xem kích thước dự đoán của một lược đồ trước khi đặt nó vào vị trí, hãy thử Máy tính thì thầm, chẳng hạn như một lược đồ có sẵn tại https://gist.github.com/jjmaestro/5774063

BIÊN TẬP:

Khi được hỏi về một ví dụ ...

lưu trữ_schema:

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

Nhìn vào tập tin của tôi applied-in-last-hour.wsp, ls -lsản lượng

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

whisper-info.py ./applied-in-last-hour.wspsản lượng

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

Vì vậy, về cơ bản, bạn kết hợp các máy chủ của mình cho mỗi trận đấu duy trì cho mỗi phân đoạn thời gian duy trì trên mỗi chỉ số, nhân với một hệ số mà bạn dự định sẽ áp dụng điều này, tính đến số lượng thống kê mới mà bạn sẽ theo dõi. Sau đó, bạn lấy bất kỳ dung lượng lưu trữ nào và ít nhất là gấp đôi nó (vì chúng tôi đang mua dung lượng và chúng tôi biết chúng tôi sẽ sử dụng nó ...)


Bất kỳ cơ hội nào bạn có một số số mẫu từ đó (kết hợp với cài đặt duy trì). Ngay bây giờ tôi đang suy nghĩ về việc lưu trữ dữ liệu chuỗi thời gian khác nhau về việc sử dụng đĩa - vì vậy việc sử dụng than chì trực tiếp cho điều đó là một việc cần làm.
Kyle Brandt

@KyleBrandt Trả lời cập nhật.
gWaldo

Cảm ơn vì điều đó. Vì vậy, với kích thước tệp, đó là những gì sẽ có sau một giờ thu thập dữ liệu, hay đó là những gì kích thước tệp sẽ luôn luôn là nhiều? Vì vậy, 4415092 là đại diện cho dữ liệu lưu giữ 5 năm này, hay đó là đại diện của một giờ của dữ liệu 1 phút? Ngoài ra, đó là byte hoặc bit?
Kyle Brandt

Đây là một triển khai mới tại công ty này và tôi không có quyền truy cập vào công cụ cũ của mình. Vì kết quả kích thước tệp cấp cao nhất khớp với ls -lkết quả, tôi coi đó là byte. Khi tôi thêm kích thước của kho lưu trữ trong tệp .wsp (như được báo cáo bởi whisper-info.py), chúng sẽ gần với kích thước tệp .wsp tổng thể (phần còn lại tôi giả sử là siêu dữ liệu và như vậy. Đây phải là kích thước của tệp cho tất cả thời gian, khi dữ liệu rơi xuống độ phân giải dữ liệu thấp hơn và các điểm dữ liệu cũ bị loại bỏ.
gWaldo

Được rồi, vì vậy với các thiết lập duy trì này. Roughly:ServerCount * MetricCount * 4.5MBytes
Kyle Brandt

2

Trong tài liệu về thống kê, họ đưa ra một ví dụ cho chính sách lưu giữ dữ liệu.

Các mức lưu giữ 10s:6h,1min:7d,10min:5ylà 2160 + 10080 + 262800 = 275040 điểm dữ liệu và chúng cho kích thước lưu trữ là 3,2 MiB .

Giả sử mối quan hệ tuyến tính, con số này sẽ xấp xỉ 12,2 byte trên mỗi điểm dữ liệu .


Các cặp ops-school.readthedocs.org/en/latest/monitoring_201.html (dấu thời gian, giá trị) được lưu trữ dưới dạng dài và giá trị gấp đôi tiêu thụ 12 byte mỗi cặp. Khác biệt 0,2 có lẽ là do thông tin siêu dữ liệu tập tin?!
dùng2745

1

Không có kinh nghiệm trực tiếp với Graphite, nhưng tôi tưởng tượng logic tương tự như chúng tôi đã sử dụng cho Cacti hoặc bất cứ điều gì khác RRD hoặc điều khiển theo thời gian sẽ được áp dụng (Graphite không sử dụng RRD trong nội bộ nữa nhưng logic lưu trữ có vẻ tương đương.)

Câu trả lời nhanh là "Có thể không có nhiều không gian như bạn nghĩ bạn sẽ cần."


Câu trả lời dài liên quan đến một số toán học cụ thể trang web. Đối với hệ thống giám sát của chúng tôi (InterMapper) tôi tìm ra các khoảng thời gian lưu, độ phân giải và kích thước điểm dữ liệu, thực hiện một số phép nhân và thêm chi phí.

Ví dụ: tôi sẽ sử dụng dung lượng ổ đĩa - chúng tôi lưu trữ các số liệu với độ chính xác 5 phút trong 30 ngày, độ chính xác 15 phút trong 60 ngày nữa và sau đó là độ chính xác hàng giờ trong 300 ngày nữa và chúng tôi đang sử dụng 64 -bit (8 byte) số nguyên để lưu trữ nó:

  • Tổng số 21600 mẫu, được chia thành:
    • 8640 mẫu cho độ chính xác 30 ngày 5 phút
    • 5760 mẫu cho độ chính xác 60 ngày 15 phút
    • 7200 mẫu cho độ chính xác 300 ngày 1 giờ

Với 8 byte cho mỗi mẫu khoảng 173KB, cộng với chi phí hoạt động tốt cho việc lập chỉ mục lưu trữ và tương tự mang lại khoảng 200KB cho dữ liệu sử dụng đĩa của một phân vùng (bất kỳ lỗi nào có xu hướng đánh giá quá cao).

Từ các số liệu cơ bản, tôi có thể tính ra kích thước "trung bình cho mỗi máy" (10 phân vùng đĩa, dung lượng trao đổi, RAM, tải trung bình, truyền mạng và một vài thứ khác) - hoạt động với khoảng 5 MB cho mỗi máy.

Tôi cũng thêm 10% khỏe mạnh vào đầu số cuối cùng và làm tròn số, vì vậy tôi kích thước mọi thứ ở mức 6MB cho mỗi máy.

Sau đó, tôi nhìn vào 1TB dung lượng mà tôi đã đặt xung quanh để lưu trữ dữ liệu số liệu để lập biểu đồ và nói "Vâng, có lẽ tôi sẽ không hết dung lượng trong đời trừ khi chúng tôi phát triển rất nhiều!" :-)


1
Để đưa ra một con số từ thực tế thực tế ngoài kia, với các chính sách duy trì sản xuất của tôi (9 tháng lúc 5 phút; 1 năm mỗi giờ; 5 năm mỗi ngày) và khoảng 20 máy với mỗi số liệu ~ 20 byte, cộng với cảnh báo / báo động / lịch sử sự kiện quan trọng / ngừng hoạt động trong 5 năm Tôi đang sử dụng 1,5G dung lượng đĩa. Đó là với InterMapper chèn mọi thứ vào cơ sở dữ liệu Postgres. Vì vậy, một lần nữa - câu trả lời nhanh là "Có thể không có nhiều không gian như bạn nghĩ bạn sẽ cần" :-)
voretaq7

Ya, toán học đó rất đơn giản, tôi thực sự chỉ đang tìm hiểu thêm về cách Graphite lưu trữ dữ liệu - có thể tạo ra sự khác biệt lớn ở quy mô. Điều duy nhất tôi đã tìm thấy là theo các tài liệu, nó không hiệu quả về mặt không gian (Có lẽ vì nó dựa vào các cuộn phim khá tích cực).
Kyle Brandt

Whisper (sử dụng Graphite back-end lưu trữ) có một số mục nhai không gian tích hợp sẵn - bạn có thể đã thấy trang đó. Phần về "Lưu trữ thời gian chồng lấp" nổi bật với tôi vì điều đó có nghĩa là tài liệu lưu trữ lớn hơn ví dụ của tôi ở trên vì tất cả đều quay về thời gian bắt đầu (kho lưu trữ 60 ngày thực sự dài 90 ngày; lưu trữ 300 ngày Dài 390 ngày). Whisper cũng giữ dấu thời gian (4 hoặc 8 byte) cùng với mỗi điểm dữ liệu cũng cần được thêm vào. Mặc dù trông không có gì khó khăn, chỉ là
bồng bềnh

0

Tôi có 70 nút tạo ra rất nhiều dữ liệu. Sử dụng Carbon / Whisper, một nút đã tạo ra 91k tệp một mình (nút tạo ra nhiều lược đồ, mỗi nút có nhiều bộ đếm và trường biến cần chọn, ví dụ: (nút tên). (Lược đồ). (Bộ đếm). )....và như thế).

Điều này cung cấp mức độ chi tiết tôi cần để vẽ bất kỳ biểu đồ nào tôi muốn. Sau khi chạy tập lệnh để điền vào 69 nút còn lại, tôi có 1,3Tb dữ liệu trên đĩa. Và đó chỉ là giá trị 6 giờ của dữ liệu / nút. Điều làm cho tôi là tệp csv phẳng thực tế cho dữ liệu có giá trị 6 giờ là khoảng 230Mb / nút. 70 nút là ~ 16Gb dữ liệu. Lược đồ lưu trữ của tôi là 120 giây: 365d.

Tôi còn khá mới đối với cơ sở dữ liệu, vì vậy tôi có thể đang làm gì đó sai, nhưng tôi đoán đó là tất cả chi phí cho mỗi mẫu.

Vì vậy, đây là một thử nghiệm thú vị, nhưng tôi không nghĩ việc sử dụng thì thầm cho loại dữ liệu tôi đang lưu trữ là điều hợp lý. MongoDB có vẻ như là một soluton tốt hơn, nhưng tôi cần tìm ra cách sử dụng nó như một phần phụ trợ cho Grafana.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.