Następna konferencja HighLoad++ odbędzie się 6 i 7 kwietnia 2020 roku w Sankt Petersburgu. Szczegóły i bilety . HighLoad++ Moskwa 2018. Sala „Moskwa”. 9 listopada, 15:00. Streszczenia i .
* Monitoring — online i analityka.
* Główne ograniczenia platformy ZABBIX.
* Rozwiązanie do skalowania magazynu analityki.
* Optymalizacja serwera ZABBIX.
* Optymalizacja UI.
* Doświadczenie w eksploatacji systemu przy obciążeniach powyżej 40k NVPS.
* Krótkie wnioski.
Michaił Makurow (dalej – MM): – Witajcie wszyscy!
Maksym Czerniecow (dalej – MC): – Dzień dobry!
MM: – Pozwólcie, że przedstawię Maksymilianowi. Maksymilian to utalentowany inżynier, najlepszy specjalista od sieci, jakiego znam. Maksymilian zajmuje się sieciami i usługami, ich rozwojem oraz eksploatacją.
MC: – A ja chciałbym opowiedzieć o Michale. Michał to programista w C. Napisał kilka wysokoobciążonych rozwiązań do przetwarzania ruchu dla naszej firmy. Żyjemy i pracujemy w Uralu, w mieście surowych mężczyzn, Czelabińsku, w firmie „Intersviaz”. Nasza firma to dostawca usług internetowych i telewizji kablowej dla miliona osób w 16 miastach.
MM: – I warto powiedzieć, że „Intersviaz” to znacznie więcej niż tylko dostawca, to firma IT. Większość naszych rozwiązań została stworzona przez nasz dział IT.
A: Od serwerów przetwarzających ruch, po call center i aplikację mobilną. W dziale IT pracuje obecnie około 80 osób o bardzo zróżnicowanych kompetencjach.
O Zabbixie i jego architekturze
MC: – A teraz spróbuję ustanowić osobisty rekord i w ciągu jednej minuty powiedzieć, czym jest Zabbix (dalej – „Zabbix”).
„Zabbix” pozycjonuje się jako system monitorowania „w pudełku” klasy przedsiębiorstw. Oferuje wiele funkcji ułatwiających życie: rozwinięte zasady eskalacji, API do integracji, grupowanie i automatyczne wykrywanie hostów i metryk. W „Zabbixie” znajdują się tzw. środki skalowania – proxy. „Zabbix” to system o otwartym kodzie źródłowym.
Krótkie o architekturze. Można powiedzieć, że składa się z trzech komponentów:
- Serwer. Napisany w C. Z dość skomplikowanym przetwarzaniem i przesyłaniem informacji między wątkami. Całe przetwarzanie odbywa się na nim: od odbioru po zapis do bazy.
- Wszystkie dane są przechowywane w bazie. „Zabbix” wspiera MySQL, PostgreSQL i Oracle.
- Interfejs webowy jest napisany w PHP. W większości systemów jest dostarczany z serwerem Apache, ale działa znacznie efektywniej w połączeniu nginx + php.
Dziś chcielibyśmy opowiedzieć historię z życia naszej firmy, związaną z 'Zabbix'...
Historia z życia firmy 'Intersвяз' - co mamy i czego potrzebujemy?
5 lub 6 miesięcy temu. Pewnego dnia po pracy...
MC: – Misza, cześć! Cieszę się, że zdążyłem cię złapać – muszę porozmawiać. Znowu mieliśmy problemy z monitoringiem. W czasie dużej awarii wszystko się zatrzymywało, a informacji o stanie sieci nie było. Niestety, to się powtarza po raz kolejny. Potrzebuję twojej pomocy. Zróbmy tak, aby nasz monitoring działał w każdych okolicznościach!
MM: – Ale najpierw zróbmy synchronizację. Nie zaglądałem tam od dwóch lat. O ile dobrze pamiętam, zrezygnowaliśmy z Nagiosa i przeszliśmy na 'Zabbix' jakieś 8 lat temu. A teraz mamy, zdaje się, 6 potężnych serwerów i około dziesięciu proxy. Niczego nie mylę?
MC: – Prawie. 15 serwerów, część z nich to wirtualne maszyny. Najważniejsze, że to nie ratuje nas w momencie, gdy jest to najbardziej potrzebne. Kiedy występuje awaria – serwery zwalniają i nic nie widać. Próbowaliśmy optymalizować konfigurację, ale to nie daje optymalnego wzrostu wydajności.
MM: – Rozumiem. Czy coś sprawdzaliście, coś już znaleźliście w diagnozie?
MC: – Pierwsze, z czym mamy do czynienia – to właśnie baza danych. MySQL ciągle jest obciążony, zapisując nowe metryki, a gdy 'Zabbix' zaczyna generować masę wydarzeń – baza zamyka się dosłownie na kilka godzin. O optymalizacji konfiguracji już ci mówiłem, a w tym roku zaktualizowaliśmy sprzęt: na serwerach jest więcej niż sto gigabajtów pamięci, a macierze dyskowe działają na RAID SSD – dalsze liniowe zwiększanie nie ma sensu. Co zamierzamy zrobić?
MM: – Rozumiem. W ogóle, MySQL to baza LTP. Wygląda na to, że już nie nadaje się do przechowywania archiwum metryk naszego rozmiaru. Zajmijmy się tym.
MC: – Zróbmy to!
Integracja Zabbix i Clickhouse jako rezultat hackathonu
Po pewnym czasie otrzymaliśmy interesujące dane:
Większość miejsca w naszej bazie była zajęta archiwum metryk, a mniej niż 1% wykorzystywane było na konfigurację, szablony i ustawienia. W tym czasie eksploatowaliśmy rozwiązanie Big Data oparte na Clickhouse przez ponad rok. Kierunek działania był dla nas oczywisty. Na naszym wiosennym 'Hackathonie' napisałem integrację Zabbixa z Clickhouse dla serwera i frontendu. W tamtym momencie Zabbix już wspierał ElasticSearch, więc postanowiliśmy je porównać.
Porównanie Clickhouse i Elasticsearch
MM: – Dla porównania generowaliśmy obciążenie takie samo, jakie dostarcza serwer Zabbixa i obserwowaliśmy, jak zachowują się systemy. Zapisaliśmy dane partiami po 1000 wierszy, używając CURL. Z góry zakładaliśmy, że Clickhouse będzie bardziej efektywny dla profilu obciążenia generowanego przez Zabbixa. Wyniki nawet przewyższyły nasze oczekiwania:
W identycznych warunkach testowych Clickhouse zapisał trzy razy więcej danych. Przy tym oba systemy bardzo efektywnie konsumowały zasoby (mała ilość używanych zasobów) podczas odczytu danych. Jednak ElasticSearch podczas zapisu wymagał dużej ilości procesora:
Łącznie Clickhouse znacznie przewyższał ElasticSearch pod względem zużycia procesora oraz prędkości. Dzięki kompresji danych Clickhouse zajmuje 11 razy mniej miejsca na dysku twardym i wykonuje około 30 razy mniej operacji dyskowych:
MC: – Tak, praca z podsystemem dyskowym w Clickhouse została zrealizowana bardzo efektywnie. Pod bazy można wykorzystać ogromne dyski SATA i uzyskać prędkość zapisu sięgającą setek tysięcy wierszy na sekundę. System 'z pudełka' wspiera sharding, replikację, jest bardzo łatwy w konfiguracji. Jesteśmy bardziej niż zadowoleni z jego eksploatacji przez rok.
Aby zoptymalizować zasoby, można zainstalować Clickhouse obok istniejącej głównej bazy, tym samym oszczędzając ogromne ilości czasu procesora i operacji dyskowych. Przenieśliśmy archiwum metryk na istniejące klastry Clickhouse:
Tak bardzo odciążyliliśmy główną bazę MySQL, że mogliśmy połączyć ją na jednej maszynie z serwerem Zabbixa i zrezygnować z wydzielonego serwera dla MySQL.
Jak działa polling w Zabbix?
4 miesiące temu
MM: – Cóż, o problemach z bazą można zapomnieć?
MC: – To prawda! Innym problemem, który musimy rozwiązać, jest wolne zbieranie danych. Teraz nasze 15 serwerów proxy jest przeciążonych procesami SNMP i pollingiem. Nie ma innego wyjścia, jak tylko instalować nowe serwery.
MM: – Świetnie. Ale najpierw powiedz mi, jak działa polling w „Zabbix”?
MC: – Mówiąc krótko, istnieje 20 typów metryk i kilka sposobów ich pozyskiwania. „Zabbix” może zbierać dane w trybie „żądanie – odpowiedź” lub oczekiwać na nowe dane przez „Interfejs Trapera”.
Warto zauważyć, że w oryginalnym „Zabbixie” ten sposób (Trapper) jest najszybszy.
Istnieją serwery proxy do rozkładu obciążenia:
Proxy mogą wykonywać te same funkcje zbierania, co serwer „Zabbix”, otrzymując od niego zadania i wysyłając zebrane metryki właśnie przez interfejs Trapera. To oficjalnie zalecany sposób rozkładu obciążenia. Proxy są również przydatne do monitorowania zdalnej infrastruktury, działającej przez NAT lub wolne łącze:
MM: – Z architekturą wszystko jasne. Muszę sprawdzić źródła...
Kilka dni później
Opowieść o tym, jak nmap i fping zwyciężyły
MM: – Wydaje mi się, że coś znalazłem.
MC: – Opowiadaj!
MM: – Odkryłem, że przy sprawdzaniu dostępności „Zabbix” wykonuje kontrolę maksymalnie do 128 hostów jednocześnie. Spróbowałem zwiększyć tę liczbę do 500 i usunąłem interwał między pakietami w ich pingach – to zwiększyło wydajność o dwukrotnie. Ale chciałbym jeszcze większych liczb.
MC: – W mojej praktyce czasami muszę sprawdzać dostępność tysięcy hostów i nic szybszego niż nmap nie spotkałem. Jestem pewny, że to najszybszy sposób. Spróbujmy go! Musimy znacząco zwiększyć liczbę hostów w jednej iteracji.
MM: – Sprawdzać więcej niż pięćset? 600?
MC: – Co najmniej kilka tysięcy.
MM: – Okej. Najważniejsze, co chciałem powiedzieć: odkryłem, że większość pollingu w „Zabbixie” jest realizowana synchronicznie. Musimy koniecznie przerobić to na tryb asynchroniczny. Wtedy będziemy mogli radykalnie zwiększyć liczbę metryk zbieranych przez pollery, zwłaszcza jeśli zwiększymy liczbę metryk w jednej iteracji.
MC: – Super! A kiedy?
MM: – Jak zwykle, wczoraj.
MC: – Porównaliśmy obie wersje fping i nmap:
Na dużej liczbie hostów nmap był przewidywalnie do pięciu razy skuteczniejszy. Ponieważ nmap sprawdza jedynie dostępność i czas reakcji, obliczanie strat przenieśliśmy do wyzwalaczy i znacznie skróciliśmy interwały sprawdzania dostępności. Optymalne dla nmap liczba hostów wynosi około 4000 w jednej iteracji. Nmap pozwolił nam trzykrotnie zmniejszyć zużycie CPU podczas sprawdzania dostępności i skrócić interwał z 120 sekund do 10.
Optymalizacja polling
MM: – Następnie zajęliśmy się pollerami. Głównie interesował nas zrzut SNMP i agenci. W "Zabbixie" polling jest realizowany synchronnie i podjęto specjalne działania, aby zwiększyć wydajność systemu. W trybie synchronnym niedostępność hostów powoduje znaczną degradację pollingu. Istnieje cała system stanów, są specjalne procesy – tak zwane unreachable-pollery, które pracują tylko z niedostępnymi hostami:
To jest komentarz, który demonstruje macierz stanów, całą złożoność systemu przejść, które są wymagane, aby system pozostał wydajny. Ponadto sam synchronny polling jest dość wolny:
Oto dlaczego tysiące wątków pollerów na dziesięciu proxy nie mogły zebrać dla nas potrzebnej ilości danych. Asynchroniczna realizacja rozwiązała nie tylko problemy z liczbą wątków, ale również znacząco uprościła system stanów niedostępnych hostów, ponieważ przy każdej liczbie sprawdzanej w jednej iteracji pollingu maksymalny czas oczekiwania wynosił 1 timeout:
Dodatkowo zmodyfikowaliśmy, dopracowaliśmy system pollingu dla zapytań SNMP. Faktem jest, że większość nie może odpowiadać na kilka zapytań SNMP jednocześnie. Dlatego stworzyliśmy tryb hybrydowy, w którym polling SNMP tego samego hosta odbywa się asynchronicznie:
Dzieje się to dla całej paczki hostów. Taki tryb w końcu nie jest wolniejszy niż całkowicie asynchroniczny, ponieważ zapytanie półtora setki wartości SNMP wciąż jest znacznie szybsze niż 1 timeout.
Nasze eksperymenty pokazały, że optymalna liczba zapytań w jednej iteracji wynosi około 8000 przy polling SNMP. Łącznie przejście na tryb asynchroniczny pozwoliło przyspieszyć wydajność pollingu 200 razy, w kilka set razy.
MC: Optymalizacje pollingowe wykazały, że możemy nie tylko pozbyć się wszystkich proxy, ale również skrócić interwały dla wielu sprawdzeń, a proxy przestaną być konieczne jako metoda rozdzielania obciążenia.
Około trzech miesięcy temu
Zmień architekturę – zwiększ obciążenie!
MM: Cóż, Max, czas na produkcję? Potrzebuję mocnego serwera i dobrego inżyniera.
MC: Dobrze, zaplanujmy to. Wysoka pora, żeby ruszyć z miejsca z 5000 metryk na sekundę.
Poranek po upgrade'cie
MC: Mikołaj, zaktualizowaliśmy, ale do rana wróciliśmy z powrotem… Zgadnij, jaką prędkość udało się osiągnąć?
MM: Maksymalnie 20 tysięcy.
MC: Aha, 25! Niestety, jesteśmy tam, gdzie zaczynaliśmy.
MM: A co się stało? Czy zrobiliście jakąś diagnostykę?
MC: Tak, oczywiście! Oto, na przykład, ciekawy top:
MM: Zobaczmy. Widzę, że próbowaliśmy ogromnej liczby wątków pollingowych:
Ale nie udało się nawet w połowie wykorzystać systemu:
A ogólna wydajność jest wystarczająco mała, około 4000 metryk na sekundę:
Czy jest coś jeszcze?
MC: Tak, strace jednego z polerów:
MM: Wyraźnie widać, że proces pollingowy czeka na ‘semafory’. To blokady:
MC: Nie rozumiem.
MM: Zobacz, to przypomina sytuację, kiedy wiele wątków próbuje pracować z zasobem, z którym jednocześnie można pracować tylko w jednym wątku. Wtedy wszystko, co mogą robić, to dzielić ten zasób w czasie:
I łączna wydajność pracy z takim zasobem ogranicza się do prędkości jednego rdzenia:
Można rozwiązać ten problem na dwa sposoby.
Zaktualizować sprzęt maszyny, przejść na szybsze rdzenie:
Lub zmienić architekturę i równocześnie – obciążenie:
MC: A propos, na maszynie testowej uruchomimy mniejszą liczbę rdzeni, niż na produkcyjnej, ale będą one o 1,5 razy szybsze pod względem częstotliwości rdzenia!
MM: Jasne? Trzeba spojrzeć na kod serwera.
Ścieżka danych w serwerze Zabbix
MC: Aby zrozumieć, zaczęliśmy analizować, jak dane są przesyłane wewnątrz serwera ‘Zabbix’:
Świetny obrazek, prawda? Przejdźmy przez niego krok po kroku, aby trochę wyjaśnić. Są wątki i usługi odpowiedzialne za zbieranie danych:
Zebrane metryki przesyłają przez socket do menedżera preprocesora, gdzie są przechowywane w kolejce:
Menedżer preprocesora przesyła dane do swoich pracowników, którzy wykonują instrukcje preprasy i zwracają je z powrotem przez ten sam socket:
Po tym menedżer preprocesora zapisuje je w pamięci podręcznej historii:
Stamtąd pobierają je synchronizatory historii, które wykonują wiele funkcji: na przykład obliczanie wyzwalaczy, wypełnianie pamięci podręcznej wartości i, co najważniejsze, zapisywanie metryk w magazynie historii. Proces jest skomplikowany i dość zawiły.
MM: – Pierwsze, co zauważyliśmy, to fakt, że większość wątków konkuruje o tzw. 'pamięć podręczną konfiguracji' (obszar pamięci, w którym przechowywane są wszystkie konfiguracje serwera). Szczególnie wiele blokad powodują wątki odpowiedzialne za pobieranie danych:
…ponieważ w konfiguracji przechowywane są nie tylko metryki z ich parametrami, ale także kolejki, z których pollery pobierają informacje o tym, co mają robić dalej. Kiedy jest dużo pollerów, a jeden z nich blokuje konfigurację, pozostałe czekają na zapytania:
Pollery nie powinny wchodzić w konflikt
Dlatego pierwsze, co zrobiliśmy, to podzieliliśmy kolejkę na 4 części i umożliwiliśmy pollerom w bezpiecznych warunkach blokowanie tych kolejek, tych części jednocześnie:
To wyeliminowało konkurencję o pamięć podręczną konfiguracji, a szybkość działania pollerów znacząco wzrosła. Ale potem napotkaliśmy problem, że menedżer preprocesora zaczął gromadzić kolejkę zadań:
Menedżer preprocesora musi umieć ustalać priorytety
Działo się tak w przypadkach, gdy brakowało mu wydajności. Wtedy wszystko, co mógł zrobić, to gromadzić zapytania od procesów zbierających dane i zapisywać je w buforze, aż pochłonął całą pamięć i się zawiesił:
Aby rozwiązać ten problem, dodaliśmy drugi gniazdo, które było wydzielone specjalnie dla workerów:
W ten sposób menedżer preprocesora zyskał możliwość nadawania priorytetów swojej pracy i w przypadku rozrostu bufora mógł opóźnić pobieranie danych, dając workerom możliwość odebrania tego bufora:
Następnie odkryliśmy, że jedną z przyczyn opóźnień były same workery, ponieważ konkurowały o zupełnie nieistotny dla ich pracy zasób. Problem ten rozwiązaliśmy w aktualizacji, a w nowych wersjach 'Zabbix' został już rozwiązany:
Zwiększamy liczbę gniazd – osiągamy wynik
Następnie sam menedżer preprocesora stał się wąskim gardłem, ponieważ to jeden wątek. Napotykał na prędkość jądra, osiągając maksymalną prędkość około 70 000 metryk na sekundę:
Dlatego stworzyliśmy cztery, z czterema zestawami procesorów, pracowników:
I to pozwoliło zwiększyć prędkość do około 130 tysięcy metryk:
Nieliniowość wzrostu wynika z pojawienia się konkurencji o pamięć podręczną historii. O jej pozyskanie rywalizowało czterech menedżerów wstępnych i synchronizatorzy historii. W tym momencie na maszynie testowej uzyskiwaliśmy około 130 tysięcy metryk na sekundę, wykorzystując ją w około 95% pod względem CPU:
Około 2,5 miesiąca temu
Rezygnacja z snmp-community zwiększyła NVPs o półtora razy
MM: – Max, potrzebuję nowej maszyny testowej! W tej już się nie mieszczymy.
MC: – A co jest teraz dostępne?
MM: – Teraz – 130k NVPs i CPU "w zasięgu".
MC: – Wow! Fajnie! Czeka, mam dwa pytania. Według moich obliczeń, nasze potrzeby wynoszą około 15-20 tysięcy metryk na sekundę. Po co nam więcej?
MM: – Chciałbym zakończyć tę sprawę do końca. Chcę zobaczyć, ile możemy wycisnąć z tego systemu.
MC: – Ale…
MM: – Ale dla biznesu to bez sensu.
MC: – Rozumiem. I drugie pytanie: to, co jest obecnie, będziemy mogli utrzymać samodzielnie, bez pomocy programisty?
MM: – Wątpię. Zmiana w obsłudze pamięci podręcznej konfiguracji to problem. Dotyczy to zmian w większości wątków i jest dość skomplikowane w utrzymaniu. Prawdopodobnie będzie to bardzo trudne do wsparcia.
MC: – W takim razie potrzebna jest jakaś alternatywa.
MM: – Jest taka opcja. Możemy przejść na szybkie rdzenie, rezygnując przy tym z nowego systemu blokowania. I tak uzyskamy wydajność na poziomie 60-80 tysięcy metryk. Ponadto pozostawimy cały resztę kodu. «ClickHouse», asynchroniczne polling będą działać. I to będzie łatwe do utrzymania.
MC: – Świetnie! Proponuję na tym zakończyć.
Po optymalizacji części serwera, w końcu udało nam się uruchomić nowy kod w produkcji. Zrezygnowaliśmy z części zmian na rzecz przejścia na maszynę z szybkimi rdzeniami i minimalizacji liczby zmian w kodzie. Uprościliśmy również konfigurację i tam, gdzie to możliwe, zrezygnowaliśmy z makr w elementach danych, ponieważ są one źródłem dodatkowych blokad.
Na przykład, rezygnacja z często spotykanego w dokumentacji i przykładach makra snmp-community w naszym przypadku pozwoliła dodatkowo przyspieszyć NVPs o około 1,5 razy.
Po dwóch dniach w produkcji
Usuwamy okna pop-up historii incydentów
MC: – Misha, korzystamy z systemu od dwóch dni i wszystko działa. Ale tylko wtedy, gdy wszystko działa! Mieliśmy zaplanowane prace związane z przeniesieniem dość dużego segmentu sieci i ponownie sprawdzaliśmy ręcznie, co się podniosło, a co nie.
MM: – Nie może być! Sprawdziliśmy wszystko 10 razy. Serwer przetwarza nawet całkowitą niedostępność sieci natychmiast.
MC: – Rozumiem wszystko: serwer, baza, top, austat, logi – wszystko szybko… Ale patrzymy na interfejs webowy, a tam – procesor «w polu» na serwerze i to:
MM: – Zrozumiałe. Spójrzmy na stronę. Odkryliśmy, że w sytuacji z dużą liczbą aktywnych incydentów, większość gadżetów operacyjnych zaczynała działać bardzo wolno:
Powodem tego była generacja okienek popup z historią incydentów, które są generowane dla każdego elementu na liście. Dlatego zrezygnowaliśmy z generacji tych okienek (skomentowaliśmy 5 linii w kodzie) i to rozwiązało nasze problemy.
Czas ładowania widżetów nawet przy całkowitej niedostępności skrócił się z kilku minut do akceptowalnych dla nas 10-15 sekund, a historię można nadal przeglądać klikając na czas:
Po pracy. 2 miesiące temu
MC: – Misha, wychodzisz? Musimy porozmawiać.
MM: – Nie planowałem. Znowu coś z «Zabbixem»?
MC: – Nie, zrelaksuj się! Chciałem tylko powiedzieć: wszystko działa, dziękuję! Ja stawiam piwo.
Zabbix jest efektywny
«Zabbix» to dość uniwersalny i bogaty system oraz funkcjonalność. Można go z powodzeniem używać do małych instalacji «z pudełka», ale wraz z rosnącymi potrzebami trzeba go optymalizować. Do przechowywania dużego archiwum metryk użyj odpowiedniego magazynu:
- można wykorzystać wbudowane środki w postaci integracji z «ElasticSearch» lub eksportu historii do plików tekstowych (dostępne od czwartej wersji);
- można skorzystać z naszego doświadczenia i integracji z «ClickHouse».
Aby drastycznie zwiększyć prędkość zbierania metryk, zbieraj je asynchronicznymi metodami i przesyłaj przez interfejs trappera do serwera «Zabbix»; lub można skorzystać z łatki do asynchroniczności pollerów samego «Zabbix».
Zabbix jest napisany w C i jest wystarczająco efektywny. Niektóre wąskie miejsca w architekturze pozwalają dodatkowo zwiększyć jego wydajność i, zgodnie z naszym doświadczeniem, uzyskiwać ponad 100 tysięcy metryk na jednoprokesorowej maszynie.
Ten konkretny patch Zabbix
MM: – Chcę dodać kilka uwag. Cała obecna prezentacja, wszystkie testy, liczby są przedstawione dla tej konfiguracji, która jest używana u nas. Z niej zbieramy teraz około 20 tysięcy metryk na sekundę. Jeśli próbujesz zrozumieć, czy to u Ciebie zadziała – możesz porównać. To, o czym dzisiaj mówiliśmy, zostało opublikowane na GitHubie w formie patcha:
Patch zawiera:
- pełną integrację z ClickHouse (zarówno z serwerem Zabbix, jak i frontendem);
- rozwiązanie problemów z menedżerem preprocesora;
- asynchroniczne polling.
Patch jest kompatybilny ze wszystkimi wersjami 4, w tym z LTS. Prawdopodobnie, przy minimalnych zmianach, będzie działał na wersji 3.4.
Dziękujemy za uwagę.
Pytania
Pytanie z publiczności (dalej A): – Dzień dobry! Czy macie plany intensywnej współpracy z zespołem Zabbix, aby to nie był patch, a normalne zachowanie Zabbixa?
MM: – Tak, część zmian na pewno dodamy do repozytorium. Coś jednak zostanie w patchu.
A: – Dziękuję bardzo za świetną prezentację! Czy po zastosowaniu patcha wsparcie ze strony Zabbix pozostanie i jak dalej aktualizować do wyższych wersji? Czy będzie możliwość aktualizacji Zabbixa po waszym patchu do 4.2, 5.0?
MM: – O wsparciu nie mogę nic powiedzieć. Gdybym był wsparciem technicznym Zabbixa, powiedziałbym raczej nie, ponieważ to cudzy kod. Jeśli chodzi o kod bazy 4.2, to nasza pozycja jest taka: "Będziemy iść z czasem i zaktualizujemy się do następnej wersji". Dlatego przez jakiś czas będziemy publikować patch do zaktualizowanych wersji. Już mówiłem w prezentacji: liczba zmian z wersjami jest na razie stosunkowo niewielka. Myślę, że przejście z 3.4 na 4 zajęło nam, wydaje się, około 15 minut. Coś się zmieniło, ale niezbyt ważnego.
A: – Czyli planujecie utrzymywać swój patch i można go bezpiecznie wdrożyć na produkcję, a potem w jakiś sposób otrzymać aktualizacje?
MM: – Zdecydowanie to rekomendujemy. Rozwiązuje to dla nas wiele problemów.
MC: – Jeszcze raz chciałbym zwrócić uwagę, że zmiany, które nie dotyczą architektury ani blokad, kolejek – są modułowe, w osobnych modułach. Nawet przy niewielkich zmianach można je utrzymywać stosunkowo łatwo.
MM: – Jeśli interesują szczegóły, to „ClickHouse” korzysta z tzw. biblioteki historii. Jest ona odseparowana – to kopia wsparcia „Elastics”, czyli można ją konfigurować. Polling zmienia tylko pollery. Uważamy, że to będzie działać długo.
A: – Dziękuję bardzo. A czy są jakieś dokumentacje wprowadzonych zmian?
MM: – Dokumentacja to patch. Oczywiście, w miarę wprowadzania „ClickHouse”, wraz z nowymi rodzajami pollerów pojawiają się nowe opcje konfiguracyjne. Pod linkiem z ostatniego slajdu znajduje się krótkiego opisu, jak tego używać.
O wymianie fping na nmap
A: – Jak to w końcu zrealizowaliście? Możecie na konkretnych przykładach: macie strappery i zewnętrzny skrypt? Co w końcu tak szybko sprawdza ogromną liczbę hostów? Jak zdobywacie te hosty? Czy trzeba jakoś podać je nmap, skądś wyciągnąć, umieścić, coś uruchomić?
MM: – Super. Bardzo trafne pytanie! Istota sprawy jest taka. Zmodyfikowaliśmy bibliotekę (ICMP ping, część „Zabbix”) do ICMP sprawdzeń, w których ustalone zostało liczba pakietów – jeden (1), a kod próbuje używać nmap. To znaczy, że to wewnętrzna praca „Zabbixa”, stała się wewnętrzną pracą pingera. W związku z tym nie jest potrzebna synchronizacja ani użycie trapera. Zrobiono to świadomie, aby zachować system w całości i nie zajmować się synchronizacją dwóch baz: co sprawdzać, wczytać przez poller, a czy nam wczytanie nie padło… To jest znacznie prostsze.
A: – Czy to też działa dla proxy?
MM: – Tak, ale nie sprawdzaliśmy. Kod pollingu i w „Zabbixie”, i na serwerze jest jedyny. Powinno działać. Jeszcze raz podkreślam: wydajność systemu jest taka, że proxy nie jest potrzebne.
MC: – Prawidłowa odpowiedź na pytanie brzmi: „A po co Wam przy takim systemie proxy?” Tylko przez NAT czy monitorować jakimś wolnym kanałem…
A: – A używacie „Zabbix” jako alertor, jeśli dobrze rozumiem. Czy wykresy (gdzie jest warstwa archiwalna) trafiły do innego systemu, typu Grafana? Czy nie korzystacie z tej funkcjonalności?
MM: – Podkreślę jeszcze raz: dokonaliśmy pełnej integracji. Przesyłamy historię do „ClickHouse”, ale zmieniliśmy php-frontend. Php-frontend korzysta z „ClickHouse” i wszystkie wykresy generuje stamtąd. Przy okazji, jeśli mam być szczery, mamy część, która buduje dane z tego samego „ClickHouse”, z tych samych danych „Zabbiksa” w innych systemach wizualizacji.
MC: – W „Grafanie” również.
Jak podejmowano decyzję o przydzieleniu zasobów?
A: – Podzielcie się trochę wewnętrzną kuchnią. Jak podejmowano decyzję o tym, że trzeba przeznaczyć zasoby na poważną przebudowę produktu? To w końcu są określone ryzyka. I powiedzcie proszę, w kontekście tego, że zamierzacie wspierać nowe wersje: jak to decyzja uzasadnia się z punktu widzenia zarządzania?
MM: – Wygląda na to, że dramę tej historii opowiedzieliśmy dość źle. Znaleźliśmy się w sytuacji, w której coś trzeba było zrobić, i poszliśmy w zasadzie dwiema równoległymi ścieżkami:
- Jedna zajmowała się uruchomieniem systemu monitorowania w nowych metodach: monitoring jako usługa, standardowy zestaw rozwiązań open source, które łączymy, a następnie staramy się zmienić proces biznesowy, aby móc pracować z nowym systemem monitorowania.
- Równolegle mieliśmy entuzjastę-programistę, który tym się zajmował (o sobie). Tak się złożyło, że on wygrał.
A: – Jaki jest rozmiar zespołu?
MC: – Jesteście przed nami.
A: – Czyli jak zwykle potrzebny jest pasjonat?
MM: – Nie wiem, co to jest pasjonat.
A: – W tym przypadku, najwyraźniej, to wy. Dziękuję bardzo, jesteście wspaniali.
MM: – Dziękuję.
O łatach dla Zabbiksa
A: – Dla systemu, który używa proxy (na przykład w jakichś rozproszonych systemach), czy można dostosować i załatkować wasze rozwiązanie, mówiąc, prosiaków, proxy, a częściowo także preprocesor samego „Zabbiksa”; i ich interakcję? Czy można optymalizować istniejące rozwiązania pod system z wieloma proxy?
MM: – Wiem, że serwer „Zabbiksa” jest kompilowany przy użyciu proxy (kompilowany i powstaje kod). Nie sprawdzaliśmy tego w produkcji. Nie jestem tego pewny, ale według mnie menedżer preprocesora nie jest używany w proxy. Zadaniem proxy jest pobranie zestawu metryk z „Zabbiksa”, ich spolszczenie (on też zapisuje konfigurację, lokalną bazę) i oddanie z powrotem serwerowi „Zabbiksa”. Preprocesing będzie później realizowany przez sam serwer, gdy go otrzyma.
Zainteresowanie proxy jest zrozumiałe. Sprawdzimy to. To interesujący temat.
A: – Taki był pomysł: jeśli można patchować pollery, można je patchować na proxy i patchować interakcję z serwerem, a preprocesor dostosować do tych celów tylko na serwerze.
MM: – Myślę, że wszystko jest nawet prostsze. Bierzecie kod, nakładacie patch, potem konfigurujecie tak, jak trzeba – budujecie serwery proxy (na przykład z ODBC) i rozprowadzacie patchowany kod po systemach. Gdzie trzeba – budujecie proxy, gdzie trzeba – serwer.
A: – Czy dodatkowo nie trzeba będzie patchować przesyłania proxy do serwera, prawda?
MC: – Nie, jest standardowe.
MM: – Tak naprawdę nie wybrzmiała jedna z idei. Zawsze staraliśmy się utrzymać równowagę między eksplozją pomysłów a ilością zmian, łatwością w utrzymaniu.
Trochę reklamy 🙂
Dziękujemy, że jesteś z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej interesujących materiałów? Wspieraj nas składając zamówienie lub polecając nas znajomym, , unikatowy odpowiednik serwerów entry-level, który został stworzony przez nas dla Ciebie: (dostępne opcje z RAID1 i RAID10, do 24 rdzeni i do 40GB DDR4).
Dell R730xd dwa razy tańszy w centrum danych Equinix Tier IV w Amsterdamie? Tylko u nas w Holandii! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 dolarów! Czytaj o tym
Źródło: habr.com
