{"id":94153,"date":"2020-09-13T19:42:30","date_gmt":"2020-09-13T17:42:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev"},"modified":"2020-09-13T19:42:30","modified_gmt":"2020-09-13T17:42:30","slug":"victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev","title":{"rendered":"VictoriaMetrics i monitorowanie prywatnych chmur. Pawe\u0142 Kolobaew","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"VictoriaMetrics<\/p>\n

<\/p>\n

VictoriaMetrics \u2014 szybka i skalowalna baza danych do przechowywania i przetwarzania danych w formie szereg\u00f3w czasowych (zapis tworzy czas oraz zbi\u00f3r odpowiadaj\u0105cych mu warto\u015bci, na przyk\u0142ad uzyskanych przez okresowe zapytanie stanu czujnik\u00f3w lub zbieranie metryk).<\/p>\n

<\/a><\/noindex>
\n

\r\n \"Odtwarzaj\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Nazywam si\u0119 Pawel Kolobaev. DevOps, SRE, LeroyMerlin, wszystko jako kod \u2014 to wszystko o nas: o mnie i o innych pracownikach LeroyMerlin.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

https:\/\/bit.ly\/3jf1fIK<\/a><\/noindex><\/p>\n

<\/p>\n

Mamy chmur\u0119 opart\u0105 na OpenStack. Jest tam niewielki link do radar\u00f3w technologicznych. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Zbudowane jest na bazie sprz\u0119tu Kubernetes oraz wszystkich towarzysz\u0105cych us\u0142ug OpenStack i logowania. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Schemat wygl\u0105da\u0142 tak podczas rozwoju. Kiedy to wszystko tworzyli\u015bmy, mieli\u015bmy operatora Prometheus, kt\u00f3ry przechowywa\u0142 dane wewn\u0105trz samego klastra K8s. Automatycznie znajduje to, co trzeba zeskrobi\u0107 i sk\u0142ada sobie pod nogi, m\u00f3wi\u0105c w przeno\u015bni. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Wszystkie dane musimy przenie\u015b\u0107 poza klaster Kubernetes, poniewa\u017c je\u015bli co\u015b si\u0119 wydarzy, musimy wiedzie\u0107, co i gdzie jest. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Pierwsze rozwi\u0105zanie \u2014 u\u017cywamy federacji, kiedy mamy zewn\u0119trzny serwer Prometheus, kiedy wchodzimy w klaster Kubernetes przez mechanizm federacji.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Ale pojawiaj\u0105 si\u0119 ma\u0142e problemy. W naszym przypadku problemy zacz\u0119\u0142y si\u0119, gdy mieli\u015bmy 250 000 metryk, a kiedy sta\u0142o si\u0119 400 000 metryk, zrozumieli\u015bmy, \u017ce nie mo\u017cemy tak dzia\u0142a\u0107. Zwi\u0119kszyli\u015bmy scrape_timeout do 25 sekund.<\/p>\n

<\/p>\n

Dlaczego musieli\u015bmy to zrobi\u0107? Prometheus zaczyna odlicza\u0107 czas wyga\u015bni\u0119cia od chwili pobrania danych. I nieistotne, \u017ce dane wci\u0105\u017c p\u0142yn\u0105. Je\u015bli w tym okre\u015blonym czasie dane nie zosta\u0142y przes\u0142ane, a sesja nie zostanie zamkni\u0119ta przez http, to uwa\u017ca si\u0119, \u017ce sesja jest nieudana i dane nie trafiaj\u0105 do samego Prometheusa.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Wszystkie znajome wykresy, kt\u00f3re otrzymujemy, gdy cz\u0119\u015b\u0107 danych brakuje. Wykresy s\u0105 porwane i nam to nie odpowiada. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Nast\u0119pn\u0105 opcj\u0105 jest szardowanie w oparciu o dwa r\u00f3\u017cne serwery Prometheus przez ten sam mechanizm federacji.<\/p>\n

<\/p>\n

Na przyk\u0142ad po prostu wzi\u0105\u0107 i rozdzieli\u0107 po nazwie. To mo\u017cna r\u00f3wnie\u017c wykorzysta\u0107, ale postanowili\u015bmy i\u015b\u0107 dalej. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

B\u0119dziemy teraz musieli jako\u015b przetwarza\u0107 te shard'y. Mo\u017cna wzi\u0105\u0107 promxy, kt\u00f3ry wejdzie w obszar sharda i zduplikuje dane. Dzia\u0142a z dwoma shardami jak z jednolitym punktem wej\u015bcia. Mo\u017cna to zrealizowa\u0107 przez promxy, ale jak na razie jest zbyt skomplikowane. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Pierwsza opcja \u2013 chcemy zrezygnowa\u0107 z mechanizmu federacji, poniewa\u017c jest bardzo wolny. <\/p>\n

<\/p>\n

Deweloperzy Prometheus wyra\u017anie m\u00f3wi\u0105: \u201eLudzie, u\u017cywajcie innych TimescaleDB, poniewa\u017c nie b\u0119dziemy d\u0142ugo wspiera\u0107 przechowywania metryk\u201d. To nie jest ich zadanie. \"VictoriaMetrics<\/p>\n

<\/p>\n

Zapisujemy sobie na kartce, \u017ce jednak potrzebujemy eksportu na zewn\u0105trz, aby nie przechowywa\u0107 wszystkiego w jednym miejscu. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Drug\u0105 wad\u0105 jest zu\u017cycie pami\u0119ci. Tak, rozumiem, \u017ce wielu powie, \u017ce w 2020 roku kilka gigabajt\u00f3w pami\u0119ci to kosztuje grosze, ale mimo to. <\/p>\n

<\/p>\n

Obecnie mamy \u015brodowisko dev i prod. W dev to oko\u0142o 9 gigabajt\u00f3w na 350 000 metryk. W prod \u2013 to nieco ponad 14 gigabajt\u00f3w na 780 000 metryk. Przy tym czas retencji wynosi zaledwie 30 minut. To \u017ale. I teraz wyt\u0142umacz\u0119 dlaczego.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Robimy obliczenia, tzn. przy p\u00f3\u0142tora miliona metryk, a ju\u017c si\u0119 do nich zbli\u017camy, na etapie projektowania otrzymujemy 35-37 gigabajt\u00f3w pami\u0119ci. Ale ju\u017c przy 4 milionach metryk potrzeba oko\u0142o 90 gigabajt\u00f3w pami\u0119ci. Tzn. to zosta\u0142o obliczone na podstawie formu\u0142y dostarczonej przez deweloper\u00f3w Prometheus. Zbadali\u015bmy korelacj\u0119 i zrozumieli\u015bmy, \u017ce nie chcemy p\u0142aci\u0107 kilku milion\u00f3w za serwer tylko do monitorowania. <\/p>\n

<\/p>\n

Nie tylko zwi\u0119kszy si\u0119 liczba maszyn, ale r\u00f3wnie\u017c monitorujemy same maszyny wirtualne. Dlatego im wi\u0119cej maszyn wirtualnych, tym wi\u0119cej r\u00f3\u017cnych metryk itd. B\u0119dzie to specjalny wzrost naszego klastra pod wzgl\u0119dem metryk.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Z przestrzeni\u0105 dyskow\u0105 nie jest a\u017c tak \u017ale, ale chcieliby\u015bmy poprawi\u0107 sytuacj\u0119. W ci\u0105gu 15 dni uzyskali\u015bmy \u0142\u0105cznie 120 gigabajt\u00f3w, z czego 100 \u2013 to dane skompresowane, 20 \u2013 to dane nieskompresowane, ale zawsze chcemy, aby by\u0142o ich mniej. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Odpowiednio, zapisujemy jeszcze jeden punkt \u2013 to du\u017ce zu\u017cycie zasob\u00f3w, kt\u00f3re chcieliby\u015bmy jednak oszcz\u0119dza\u0107, poniewa\u017c nie chcemy, aby nasz klaster monitorowania poch\u0142ania\u0142 wi\u0119cej zasob\u00f3w ni\u017c nasz klaster zajmuj\u0105cy si\u0119 zarz\u0105dzaniem OpenStack.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Jest jeszcze jedna wada Prometheus, kt\u00f3r\u0105 zidentyfikowali\u015bmy, to jakie\u015b ograniczenie dotycz\u0105ce pami\u0119ci. Z Prometheus jest tutaj znacznie gorzej, poniewa\u017c nie ma w og\u00f3le takich opcji. U\u017cywanie ogranicze\u0144 w Dockerze r\u00f3wnie\u017c nie jest rozwi\u0105zaniem. Je\u015bli nagle \u0443 was spad\u0142 RAF i tam jest 20-30 gigabajt\u00f3w, to jego uruchomienie zajmie bardzo du\u017co czasu. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

To jeszcze jedna przyczyna, dla kt\u00f3rej Prometheus nam nie odpowiada, tzn. nie mo\u017cna ograniczy\u0107 zu\u017cycia pami\u0119ci. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Mo\u017cna by by\u0142o opracowa\u0107 taki schemat. Ten schemat jest nam potrzebny, aby zorganizowa\u0107 klaster HA. Chcemy, aby nasze metryki by\u0142y zawsze i wsz\u0119dzie dost\u0119pne, nawet w przypadku awarii serwera przechowuj\u0105cego te metryki. W zwi\u0105zku z tym musimy stworzy\u0107 taki schemat. <\/p>\n

<\/p>\n

Ten schemat m\u00f3wi, \u017ce b\u0119dziemy mie\u0107 duplikacj\u0119 shard\u00f3w, a tym samym duplikacj\u0119 wydatk\u00f3w na zasoby. Mo\u017cna go prawie poziomo skalowa\u0107, jednak zu\u017cycie zasob\u00f3w b\u0119dzie ogromne. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Wady w kolejno\u015bci, w jakiej je wypisali\u015bmy:<\/p>\n

<\/p>\n