Planowanie pojemności dysku dla Whisper / Graphite

Czy ktoś ma jakieś formuły, a może jakieś przykładowe dane ze swojego środowiska, które mogą pomóc mi oszacować, ile miejsca na dysku zajmie grafit na punkt danych?

whisper-info.py daje dużo wglądu w to, co i jak agregowany jest każdy plik, w tym jego rozmiar.

Jest to jednak przydatne tylko w przypadku istniejących plików szeptanych.

Jeśli chcesz zobaczyć predykcyjną wielkość schematu przed jego wdrożeniem, wypróbuj kalkulator szeptany, taki jak ten dostępny pod adresem https://gist.github.com/jjmaestro/5774063

EDYTOWAĆ:

Zapytany o przykład ...

schemat_pamięci:

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

Patrząc na mój plik applied-in-last-hour.wsp, ls -ldaje

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

i whisper-info.py ./applied-in-last-hour.wspdaje

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

Zasadniczo więc łączysz swoich hostów na mecz retencji na segment okresu retencji na statystykę, mnożąc przez współczynnik systemów, które również zamierzasz zastosować, i licz liczbę nowych statystyk, które zamierzasz śledzić. Następnie bierzesz dowolną ilość miejsca i co najmniej podwajasz (ponieważ kupujemy miejsce i wiemy, że z niego skorzystamy ...)

W dokumentacji statsd podają przykład zasady przechowywania danych.

Wartości retencji wynoszą 10s:6h,1min:7d,10min:5y2160 + 10080 + 262800 = 275040 punktów danych i dają rozmiar archiwum 3,2 MiB .

Zakładając liniową zależność, będzie to około 12,2 Bajtów na punkt danych .

Nie ma bezpośredniego doświadczenia z grafitem, ale wyobrażam sobie taką samą logikę, jak w przypadku kaktusów, czy cokolwiek innego, zastosowanie miałoby RRD lub rolowanie czasu (grafit nie używa już RRD wewnętrznie, ale logika przechowywania wydaje się porównywalna.)

Szybka odpowiedź brzmi: „Prawdopodobnie nie tyle miejsca, ile myślisz, że będziesz potrzebować”.

Długa odpowiedź dotyczy matematyki specyficznej dla witryny. W naszym systemie monitorowania (InterMapper) obliczam okresy przechowywania, rozdzielczości i rozmiar punktów danych, dokonuję mnożenia i dodajemy narzut.

Jako przykład wykorzystam miejsce na dysku - przechowujemy dane z dokładnością 5 minut przez 30 dni, 15 minut z dokładnością do kolejnych 60 dni, a następnie z dokładnością co godzinę przez kolejne 300 dni i używamy 64 -bit (8 bajtów) liczba całkowita do przechowywania:

• Łącznie 21600 próbek, w podziale na:
  • 8640 próbek dla 30-dniowej 5-minutowej precyzji
  • 5760 próbek dla 60-dniowej 15-minutowej precyzji
  • 7200 próbek dla 300-dniowej dokładności 1-godzinnej

Przy 8 bajtach na próbkę, co stanowi około 173 KB, plus zdrowy narzut na potrzeby indeksowania pamięci i tym podobne, co daje około 200 KB na dane o użytkowaniu dysku jednej partycji (każdy błąd zmierza w kierunku przeszacowania).

Na podstawie podstawowych wskaźników mogę obliczyć średni rozmiar „na maszynę” (10 partycji dysku, przestrzeń wymiany, pamięć RAM, średnie obciążenie, transfer sieciowy i kilka innych rzeczy) - wynosi około 5 MB na maszynę.

Dodaję też zdrowe 10% na końcu i zaokrąglam w górę, więc zmieniam rozmiar na 6 MB na maszynę.

Następnie patrzę na 1 TB miejsca, które mam do przechowywania danych metryk do tworzenia wykresów, i mówię: „Tak, prawdopodobnie nie zabraknie mi miejsca w moim życiu, chyba że dużo dorośniemy!” :-)

Mam 70 węzłów, które generują dużo danych. Za pomocą Carbon / Whisper jeden węzeł sam utworzył 91k plików (węzeł generuje wiele schematów, z których każdy ma wiele liczników i pól zmiennych, które należy wybrać, np. (Nazwa_węzła). (Schemat). (Licznik). (Podlicznik). Itp. )....i tak dalej).

Zapewniło to szczegółowość potrzebną do wykreślenia dowolnego wykresu, jaki chcę. Po uruchomieniu skryptu w celu wypełnienia pozostałych 69 węzłów miałem 1,3 TB danych na dysku. A to tylko 6 godzin danych / węzła. Co mnie dostaje to faktyczny płaski plik csv dla danych o wartości 6 godzin to około 230 Mb / węzeł. 70 węzłów to ~ 16 Gb danych. Mój schemat przechowywania wynosił 120s: 365d.

Jestem stosunkowo nowy w bazach danych, więc może robię coś złego, ale przypuszczam, że to wszystko narzut dla każdej próbki.

Był to więc zabawny eksperyment, ale nie sądzę, aby szept był uzasadniony dla danych, które przechowuję. MongoDB wydaje się lepszym rozwiązaniem, ale muszę wymyślić, jak używać go jako backendu do Grafany.