{"id":52113,"date":"2019-11-01T00:00:00","date_gmt":"2019-10-31T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik"},"modified":"2020-02-18T13:59:47","modified_gmt":"2020-02-18T10:59:47","slug":"bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik","title":{"rendered":"Bioyino \u2014 rozproszony, skalowalny agregator metryk","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Wi\u0119c zbierasz metryki. Tak jak my. My te\u017c zbieramy metryki. Oczywi\u015bcie, te wa\u017cne dla biznesu. Dzi\u015b opowiemy o pierwszym ogniwie systemu naszego monitoringu \u2014 serwerze agregacji zgodnym z statsd. bioyino<\/a><\/noindex>, dlaczego go napisali\u015bmy i dlaczego zrezygnowali\u015bmy z brubeck. <\/p>\n

<\/p>\n

\"Bioyino<\/p>\n

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

Z naszych wcze\u015bniejszych artyku\u0142\u00f3w (1<\/a><\/noindex>, 2<\/a><\/noindex>) mo\u017cna dowiedzie\u0107 si\u0119, \u017ce przez pewien czas zbierali\u015bmy metryki za pomoc\u0105 brubeck<\/a><\/noindex>. Jest napisany w C. Z punktu widzenia kodu \u2014 prosty jak korek (co jest wa\u017cne, gdy chcesz wnosi\u0107 wk\u0142ad) i, co najwa\u017cniejsze, bez problemu radzi sobie z naszymi wolumenami wynosz\u0105cymi 2 miliony metryk na sekund\u0119 (MPS) w szczycie. Dokumentacja deklaruje wsparcie dla 4 milion\u00f3w MPS z gwiazdk\u0105. Oznacza to, \u017ce uzyskasz podan\u0105 liczb\u0119, je\u015bli poprawnie skonfigurujesz sie\u0107 na Linuxie. (Nie wiemy, ile MPS mo\u017cna uzyska\u0107, je\u015bli sie\u0107 zostanie pozostawiona bez zmian). Mimo tych zalet, mieli\u015bmy kilka powa\u017cnych zastrze\u017ce\u0144 do brubeck.<\/p>\n

<\/p>\n

Zastrze\u017cenie 1.<\/em> Github \u2014 tw\u00f3rca projektu \u2014 przesta\u0142 go wspiera\u0107: publikowa\u0107 poprawki i poprawki, akceptowa\u0107 nasze i (nie tylko nasze) PR. W ci\u0105gu ostatnich kilku miesi\u0119cy (gdzie\u015b od lutego-marca 2018) aktywno\u015b\u0107 wzros\u0142a, ale przed tym by\u0142a prawie 2-letnia ca\u0142kowita cisza. Ponadto projekt jest rozwijany dla wewn\u0119trznych potrzeb Gihub<\/a><\/noindex>, co mo\u017ce stanowi\u0107 powa\u017cn\u0105 przeszkod\u0119 dla wprowadzania nowych funkcji.<\/p>\n

<\/p>\n

Zastrze\u017cenie 2.<\/em> Dok\u0142adno\u015b\u0107 oblicze\u0144. Brubeck zbiera do agregacji tylko 65536 warto\u015bci. W naszym przypadku dla niekt\u00f3rych metryk w okresie agregacji (30 s) mo\u017ce przychodzi\u0107 znacznie wi\u0119cej warto\u015bci (1 527 392 w szczycie). W rezultacie takiego pr\u00f3bkowania warto\u015bci maksimum i minimum wydaj\u0105 si\u0119 bezu\u017cyteczne. Na przyk\u0142ad, wygl\u0105da to tak: <\/p>\n

<\/p>\n

\"Bioyino
\nJak by\u0142o<\/em><\/p>\n

<\/p>\n

\"Bioyino
\nJak powinno by\u0107<\/em><\/p>\n

<\/p>\n

Z tej samej przyczyny sumy s\u0105 og\u00f3lnie obliczane niepoprawnie. Dodaj do tego b\u0142\u0105d z przepe\u0142nieniem 32-bitowego float, kt\u00f3ry w og\u00f3le wysy\u0142a serwer w segfault przy otrzymaniu na poz\u00f3r nieszkodliwej metryki, i jest w og\u00f3le \u015bwietnie. B\u0142\u0105d, nota bene, nie zosta\u0142 poprawiony.<\/p>\n

<\/p>\n

I, w ko\u0144cu, Zastrze\u017cenie X<\/em>. W momencie pisania tego artyku\u0142u, jeste\u015bmy gotowi zaprezentowa\u0107 j\u0105 wszystkim 14 w miar\u0119 dzia\u0142aj\u0105cym implementacjom statsd, kt\u00f3re uda\u0142o nam si\u0119 znale\u017a\u0107. Wyobra\u017amy sobie, \u017ce pewna infrastruktura rozros\u0142a si\u0119 na tyle, \u017ce przyjmowanie 4 mln MPS ju\u017c nie wystarcza. Lub mo\u017ce jeszcze si\u0119 nie rozros\u0142a, ale metryki s\u0105 dla was ju\u017c na tyle wa\u017cne, \u017ce nawet kr\u00f3tkie, 2-3 minutowe przerwy na wykresach mog\u0105 sta\u0107 si\u0119 krytyczne i wywo\u0142a\u0107 ataki nieodpartych epizod\u00f3w depresji u mened\u017cer\u00f3w. Poniewa\u017c leczenie depresji jest wdzi\u0119cznym zadaniem, potrzebne s\u0105 rozwi\u0105zania techniczne.<\/p>\n

<\/p>\n

Po pierwsze, odporno\u015b\u0107 na awarie, aby nag\u0142y problem na serwerze nie wywo\u0142a\u0142 w biurze psychiatrycznego apokalipsy zombie. Po drugie, skalowalno\u015b\u0107, aby m\u00f3c przyjmowa\u0107 wi\u0119cej ni\u017c 4 mln MPS, jednocze\u015bnie nie zag\u0142\u0119biaj\u0105c si\u0119 w stos sieciowy Linuxa i spokojnie rosn\u0105\u0107 \u201ew bok\u201d do wymaganych rozmiar\u00f3w.<\/p>\n

<\/p>\n

Poniewa\u017c mieli\u015bmy zapas w zakresie skalowalno\u015bci, postanowili\u015bmy zacz\u0105\u0107 od odporno\u015bci na awarie. \u201eO! Odporno\u015b\u0107 na awarie! To proste, to potrafimy\u201d, pomy\u015bleli\u015bmy i uruchomili\u015bmy 2 serwery, uruchamiaj\u0105c na ka\u017cdym kopi\u0119 brubeck. W tym celu musieli\u015bmy skopiowa\u0107 ruch z metrykami na oba serwery i nawet napisa\u0107 do tego ma\u0142e narz\u0119dzie<\/a><\/noindex>. Problemu odporno\u015bci na awarie w ten spos\u00f3b rozwi\u0105zali\u015bmy, ale\u2026 nie zbyt dobrze. Na pocz\u0105tku wszystko wydawa\u0142o si\u0119 w porz\u0105dku: ka\u017cdy brubeck zbiera swoj\u0105 wersj\u0119 agregacji, zapisuje dane w Graphite co 30 sekund, nadpisuj\u0105c stary interwa\u0142 (to dzieje si\u0119 po stronie Graphite). Je\u015bli nagle jeden serwer zawiedzie, zawsze mamy drugi z w\u0142asn\u0105 kopi\u0105 zaggregowanych danych. Jednak pojawia si\u0119 problem: gdy serwer zawodzi, na wykresach pojawia si\u0119 \u201ez\u0105b\u201d. Jest to zwi\u0105zane z tym, \u017ce 30-sekundowe interwa\u0142y w brubeck nie s\u0105 zsynchronizowane, i w momencie awarii jeden z nich nie jest nadpisywany. W momencie uruchamiania drugiego serwera dzieje si\u0119 to samo. Ca\u0142kiem zno\u015bne, ale chcemy lepiej! Problem skalowalno\u015bci r\u00f3wnie\u017c si\u0119 nie znikn\u0105\u0142. Wszystkie metryki wci\u0105\u017c \u201elec\u0105\u201d na pojedynczy serwer, wi\u0119c jeste\u015bmy ograniczeni tymi samymi 2-4 mln MPS, w zale\u017cno\u015bci od wydajno\u015bci sieci.<\/p>\n

<\/p>\n

Je\u015bli troch\u0119 pomy\u015blisz o problemie i jednocze\u015bnie wykopiesz troch\u0119 \u015bniegu, mo\u017ce przyj\u015b\u0107 ci do g\u0142owy oczywisty pomys\u0142: potrzebny jest statsd, kt\u00f3ry potrafi dzia\u0142a\u0107 w trybie rozproszonym. To znaczy taki, w kt\u00f3rym zrealizowana jest synchronizacja mi\u0119dzy w\u0119z\u0142ami pod wzgl\u0119dem czasu i metryk. \u201eOczywi\u015bcie takie rozwi\u0105zanie pewnie ju\u017c istnieje\u201d \u2013 powiedzieli\u015bmy i zacz\u0119li\u015bmy googlowa\u0107... I nic nie znale\u017ali\u015bmy. Przeszukuj\u0105c dokumentacj\u0119 r\u00f3\u017cnych statsd (https:\/\/github.com\/etsy\/statsd\/wiki#server-implementations<\/a><\/noindex> na dzie\u0144 11.12.2017), nie znale\u017ali\u015bmy nic. Wida\u0107, ani programi\u015bci, ani u\u017cytkownicy tych rozwi\u0105za\u0144 nie mieli do czynienia z TAK\u0104 liczb\u0105 metryk, inaczej na pewno co\u015b by wymy\u015blili.<\/p>\n

<\/p>\n

I wtedy przypomnieli\u015bmy sobie o \u201ezabawkowym\u201d statsd \u2013 bioyino, kt\u00f3re napisali\u015bmy na hackathonie dla zabawy (nazwa projektu zosta\u0142a wygenerowana przez skrypt przed rozpocz\u0119ciem hackathonu) i zrozumieli\u015bmy, \u017ce pilnie potrzebujemy w\u0142asnego statsd. Po co?<\/p>\n

<\/p>\n