Najbliższa konferencja HighLoad++ odbędzie się 6 i 7 kwietnia 2020 w St. Petersburgu. Szczegóły i bilety . HighLoad++ Moskwa 2018. Hala „Moskwa”. 9 listopada, 15:00. Tezy i .
* Monitoring - online i analityczny.
* Podstawowe ograniczenia platformy ZABBIX.
* Rozwiązanie do skalowania magazynu danych analitycznych.
* Optymalizacja serwera ZABBIX.
* Optymalizacja interfejsu użytkownika.
* Doświadczenie w obsłudze systemu pod obciążeniem przekraczającym 40 tys. NVPS.
* Krótkie wnioski.
Michaił Makurow (dalej – MM): - Cześć wszystkim!
Maksym Czerniecow (dalej – MCH): - Dzień dobry!
MM: – Pozwólcie, że przedstawię Maxima. Max jest utalentowanym inżynierem, najlepszym networkerem, jakiego znam. Maxim zajmuje się sieciami i usługami, ich rozwojem i obsługą.
MCH: – A ja chciałbym ci opowiedzieć o Michaiłu. Michaił jest programistą C. Napisał dla naszej firmy kilka rozwiązań do przetwarzania ruchu o dużym obciążeniu. Mieszkamy i pracujemy na Uralu, w mieście twardych ludzi Czelabińsku, w firmie Intersvyaz. Nasza firma jest dostawcą usług Internetu i telewizji kablowej dla miliona osób w 16 miastach.
MM: – I warto powiedzieć, że Intersvyaz to znacznie więcej niż tylko dostawca, to firma informatyczna. Większość naszych rozwiązań jest tworzona przez nasz dział IT.
A: od serwerów przetwarzających ruch po call center i aplikację mobilną. Dział IT liczy obecnie około 80 osób o bardzo, bardzo zróżnicowanych kompetencjach.
O Zabbixie i jego architekturze
MCH: – A teraz spróbuję pobić rekord życiowy i w ciągu minuty powiedzieć, czym jest Zabbix (zwany dalej „Zabbix”).
Zabbix pozycjonuje się jako gotowy do użycia system monitorowania na poziomie przedsiębiorstwa. Posiada wiele funkcji ułatwiających życie: zaawansowane reguły eskalacji, API do integracji, grupowania i automatycznego wykrywania hostów i metryk. Zabbix posiada tak zwane narzędzia skalujące – proxy. Zabbix jest systemem typu open source.
Krótko o architekturze. Można powiedzieć, że składa się z trzech elementów:
- Serwer. Napisane w C. Przy dość złożonym przetwarzaniu i przesyłaniu informacji między wątkami. Odbywa się w nim cała obróbka: od otrzymania po zapis do bazy danych.
- Wszystkie dane są przechowywane w bazie danych. Zabbix obsługuje MySQL, PostreSQL i Oracle.
- Interfejs sieciowy napisany jest w języku PHP. W większości systemów jest wyposażony w serwer Apache, ale działa wydajniej w połączeniu z nginx + php.
Dziś chcielibyśmy opowiedzieć jedną historię z życia naszej firmy związaną z Zabbixem...
Historia z życia firmy Intersvyaz. Co mamy i czego potrzebujemy?
5 lub 6 miesięcy temu. Pewnego dnia po pracy...
MCH: - Misza, cześć! Cieszę się, że udało mi się Cię złapać - trwa rozmowa. Znów mieliśmy problemy z monitoringiem. Podczas poważnej awarii wszystko działało wolno i nie było informacji o stanie sieci. Niestety, nie jest to pierwszy taki przypadek. Potrzebuję twojej pomocy. Sprawmy, aby nasz monitoring działał w każdych okolicznościach!
MM: - Ale najpierw zsynchronizujmy się. Nie zaglądałem tam od kilku lat. O ile pamiętam, około 8 lat temu porzuciliśmy Nagios i przeszliśmy na Zabbix. A teraz wydaje się, że mamy 6 potężnych serwerów i kilkanaście serwerów proxy. Czy coś mylę?
MCH: - Prawie. 15 serwerów, z czego część to maszyny wirtualne. Najważniejsze, że nie ratuje nas w momencie, kiedy najbardziej tego potrzebujemy. Jak wypadek - serwery zwalniają i nic nie widać. Próbowaliśmy zoptymalizować konfigurację, ale nie zapewniło to optymalnego wzrostu wydajności.
MM: - Jest jasne. Przeglądałeś coś, wygrzebałeś już coś z diagnostyki?
MCH: – Pierwszą rzeczą, z którą musisz się uporać, jest baza danych. MySQL jest stale ładowany, przechowując nowe metryki, a kiedy Zabbix zaczyna generować serię zdarzeń, baza danych działa przeciążona dosłownie na kilka godzin. O optymalizacji konfiguracji już mówiłem, ale dosłownie w tym roku zaktualizowali sprzęt: serwery mają ponad sto gigabajtów pamięci i macierze dyskowe na dyskach SSD RAID – nie ma sensu tego liniowo zwiększać w dłuższej perspektywie. Co robimy?
MM: - Jest jasne. Ogólnie rzecz biorąc, MySQL jest bazą danych LTP. Najwyraźniej nie nadaje się już do przechowywania archiwum metryk naszej wielkości. Rozwiążmy to.
MCH: - Zróbmy!
Integracja Zabbix i Clickhouse w wyniku hackathonu
Po pewnym czasie otrzymaliśmy ciekawe dane:
Większość miejsca w naszej bazie zajmowało archiwum metryk, a niecałe 1% zostało wykorzystane na konfigurację, szablony i ustawienia. W tym czasie już od ponad roku korzystaliśmy z rozwiązania Big Data opartego na Clickhouse. Kierunek ruchu był dla nas oczywisty. Na naszym wiosennym Hackathonie pisałem integrację Zabbix z Clickhouse dla serwera i frontendu. W tamtym czasie Zabbix obsługiwał już ElasticSearch i postanowiliśmy je porównać.
Porównanie Clickhouse i Elasticsearch
MM: – Dla porównania wygenerowaliśmy takie samo obciążenie, jakie zapewnia serwer Zabbix i sprawdziliśmy, jak zachowają się systemy. Zapisaliśmy dane w partiach po 1000 linii, używając CURL. Z góry założyliśmy, że Clickhouse będzie bardziej wydajny dla profilu obciążenia niż Zabbix. Wyniki przerosły nawet nasze oczekiwania:
W tych samych warunkach testowych Clickhouse zapisał trzy razy więcej danych. Jednocześnie oba systemy zużywały bardzo efektywnie (niewielką ilość zasobów) podczas odczytu danych. Ale Elastics wymagał dużej ilości procesora podczas nagrywania:
W sumie Clickhouse był znacznie lepszy od Elastix pod względem zużycia procesora i szybkości. Jednocześnie, dzięki kompresji danych, Clickhouse zużywa 11 razy mniej danych na dysku twardym i wykonuje około 30 razy mniej operacji dyskowych:
MCH: – Tak, praca Clickhouse z podsystemem dyskowym jest realizowana bardzo sprawnie. Możesz używać ogromnych dysków SATA do baz danych i uzyskać prędkość zapisu setek tysięcy linii na sekundę. Gotowy do użycia system obsługuje sharding i replikację i jest bardzo łatwy w konfiguracji. Jesteśmy więcej niż zadowoleni z jego stosowania przez cały rok.
Aby zoptymalizować zasoby, możesz zainstalować Clickhouse obok istniejącej głównej bazy danych, oszczędzając w ten sposób dużo czasu procesora i operacji dyskowych. Przenieśliśmy archiwum metryk do istniejących klastrów Clickhouse:
Odciążyliśmy główną bazę danych MySQL na tyle, że mogliśmy połączyć ją na jednej maszynie z serwerem Zabbix i zrezygnować z serwera dedykowanego na rzecz MySQL.
Jak działa odpytywanie w Zabbix?
4 miesięcy temu
MM: – No cóż, czy możemy zapomnieć o problemach z bazą?
MCH: - Na pewno! Kolejnym problemem, który musimy rozwiązać, jest powolne gromadzenie danych. Teraz wszystkie nasze 15 serwerów proxy jest przeciążonych procesami SNMP i odpytywania. I nie ma innego wyjścia, jak tylko instalować coraz to nowe serwery.
MM: - Świetnie. Ale najpierw powiedz nam, jak działa odpytywanie w Zabbix?
MCH: – Krótko mówiąc, istnieje 20 rodzajów metryk i kilkanaście sposobów ich uzyskania. Zabbix może zbierać dane albo w trybie „żądanie-odpowiedź”, albo czekać na nowe dane poprzez „Interfejs Trapera”.
Warto zaznaczyć, że w oryginalnym Zabbixie ta metoda (Trapper) jest najszybsza.
Istnieją serwery proxy do dystrybucji obciążenia:
Serwery proxy mogą wykonywać te same funkcje gromadzenia danych, co serwer Zabbix, odbierać od niego zadania i wysyłać zebrane metryki poprzez interfejs Trapper. Jest to oficjalnie zalecany sposób rozłożenia obciążenia. Serwery proxy są również przydatne do monitorowania zdalnej infrastruktury działającej poprzez NAT lub wolny kanał:
MM: – Z architekturą wszystko jest jasne. Trzeba sięgnąć do źródeł...
Kilka dni później
Historia wygranej nmap fping
MM: – Chyba coś wykopałem.
MCH: - Powiedz mi!
MM: – Odkryłem, że podczas sprawdzania dostępności Zabbix sprawdza jednocześnie maksymalnie 128 hostów. Próbowałem zwiększyć tę liczbę do 500 i usunąć interwał między pakietami w ich pingach (ping) - to podwoiło wydajność. Ale chciałbym większe liczby.
MCH: – W mojej praktyce czasami muszę sprawdzić dostępność tysięcy hostów i nigdy nie widziałem do tego niczego szybszego niż nmap. Jestem pewien, że to najszybszy sposób. Spróbujmy! Musimy znacznie zwiększyć liczbę hostów na iterację.
MM: – Sprawdź więcej niż pięćset? 600?
MCH: - Co najmniej kilka tysięcy.
MM: - OK. Najważniejszą rzeczą, którą chciałem powiedzieć, jest to, że odkryłem, że większość odpytywania w Zabbix odbywa się synchronicznie. Zdecydowanie musimy go zmienić na tryb asynchroniczny. Wtedy możemy radykalnie zwiększyć liczbę metryk zbieranych przez ankietery, szczególnie jeśli zwiększymy liczbę metryk na iterację.
MCH: - Świetnie! I kiedy?
MM: – Jak zwykle wczoraj.
MCH: – Porównaliśmy obie wersje fping i nmap:
Oczekiwano, że na dużej liczbie hostów nmap będzie nawet pięciokrotnie skuteczniejszy. Ponieważ nmap sprawdza tylko dostępność i czas reakcji, przenieśliśmy kalkulację strat do wyzwalaczy i znacznie skróciliśmy interwały sprawdzania dostępności. Ustaliliśmy, że optymalna liczba hostów dla nmap wynosi około 4 tysiące na iterację. Nmap pozwolił nam trzykrotnie zmniejszyć koszt procesora związany z sprawdzaniem dostępności i skrócić interwał ze 120 sekund do 10.
Optymalizacja odpytywania
MM: „Potem zaczęliśmy robić ankiety. Nas interesowało głównie wykrywanie i agenty SNMP. W Zabbix odpytywanie odbywa się synchronicznie i podjęto specjalne środki w celu zwiększenia wydajności systemu. W trybie synchronicznym niedostępność hosta powoduje znaczne pogorszenie odpytywania. Istnieje cały system stanów, istnieją specjalne procesy - tzw. nieosiągalne ankietery, które działają tylko z nieosiągalnymi hostami:
Jest to komentarz pokazujący macierz stanu, całą złożoność systemu przejść, które są wymagane, aby system pozostał skuteczny. Ponadto samo odpytywanie synchroniczne jest dość powolne:
Dlatego tysiące strumieni ankiet na dziesiątkach serwerów proxy nie było w stanie zebrać dla nas wymaganej ilości danych. Implementacja asynchroniczna rozwiązała nie tylko problemy z liczbą wątków, ale także znacznie uprościła system stanu niedostępnych hostów, gdyż dla dowolnej liczby sprawdzanej w jednej iteracji odpytywania maksymalny czas oczekiwania wynosił 1 timeout:
Dodatkowo zmodyfikowaliśmy i ulepszyliśmy system odpytywania żądań SNMP. Faktem jest, że większość ludzi nie jest w stanie odpowiedzieć na wiele żądań SNMP jednocześnie. Dlatego stworzyliśmy tryb hybrydowy, w którym odpytywanie SNMP tego samego hosta odbywa się asynchronicznie:
Odbywa się to dla całej grupy gospodarzy. Ten tryb ostatecznie nie jest wolniejszy niż tryb całkowicie asynchroniczny, ponieważ odpytywanie półtora setki wartości SNMP jest nadal znacznie szybsze niż 1 limit czasu.
Nasze eksperymenty wykazały, że optymalna liczba żądań w jednej iteracji przy odpytywaniu SNMP wynosi około 8 tysięcy. Łącznie przejście na tryb asynchroniczny pozwoliło nam przyspieszyć działanie odpytywania 200-krotnie, kilkaset razy.
MCH: – Wynikowe optymalizacje odpytywania pokazały, że możemy nie tylko pozbyć się wszystkich serwerów proxy, ale także zmniejszyć interwały wielu kontroli, a serwery proxy nie będą już potrzebne jako sposób na dzielenie obciążenia.
Jakieś trzy miesiące temu
Zmień architekturę - zwiększ obciążenie!
MM: - Cóż, Max, czy nadszedł czas, aby stać się produktywnym? Potrzebuję wydajnego serwera i dobrego inżyniera.
MCH: - OK, zaplanujmy to. Najwyższy czas wyjść z martwego punktu wynoszącego 5 tysięcy metryk na sekundę.
Rano po aktualizacji
MCH: - Misza, zaktualizowaliśmy się, ale rano wycofaliśmy się... Zgadnij, jaką prędkość udało nam się osiągnąć?
MM: – maksymalnie 20 tys.
MCH: - Tak, 25! Niestety jesteśmy dokładnie tam, gdzie zaczęliśmy.
MM: - Dlaczego? Robiłeś jakąś diagnostykę?
MCH: - Tak, oczywiście! Tutaj na przykład ciekawy top:
MM: - Obejrzyjmy. Widzę, że wypróbowaliśmy ogromną liczbę wątków ankiety:
Ale jednocześnie nie mogli poddać systemu recyklingowi nawet o połowę:
Ogólna wydajność jest dość mała, około 4 tysięcy metryk na sekundę:
Czy jest coś jeszcze?
MCH: – Tak, ślad jednego z ankieterów:
MM: – Tutaj wyraźnie widać, że proces odpytywania oczekuje na „semafory”. Oto zamki:
MCH: - Niejasne.
MM: – Słuchaj, jest to podobne do sytuacji, w której kilka wątków próbuje pracować z zasobami, z którymi w danym momencie może pracować tylko jeden. Wtedy jedyne, co mogą zrobić, to udostępnić ten zasób w miarę upływu czasu:
Całkowita wydajność pracy z takim zasobem jest ograniczona szybkością jednego rdzenia:
Istnieją dwa sposoby rozwiązania tego problemu.
Uaktualnij sprzęt maszyny, przełącz się na szybsze rdzenie:
Lub zmień architekturę i jednocześnie zmień obciążenie:
MCH: – Nawiasem mówiąc, na maszynie testowej użyjemy mniej rdzeni niż na bojowej, ale są one 1,5 razy szybsze pod względem częstotliwości na rdzeń!
MM: - Jasne? Musisz spojrzeć na kod serwera.
Ścieżka danych na serwerze Zabbix
MCH: – Aby to zrozumieć, zaczęliśmy analizować sposób przesyłania danych wewnątrz serwera Zabbix:
Fajne zdjęcie, prawda? Przeanalizujmy to krok po kroku, żeby było mniej więcej jasne. Za zbieranie danych odpowiedzialne są wątki i usługi:
Przesyłają zebrane metryki poprzez gniazdo do menedżera preprocesora, gdzie są zapisywane w kolejce:
„Menedżer preprocesora” przesyła dane do swoich pracowników, którzy wykonują instrukcje przetwarzania wstępnego i zwracają je z powrotem przez to samo gniazdo:
Następnie menedżer preprocesora przechowuje je w pamięci podręcznej historii:
Stamtąd pobierane są przez obciążniki historii, które wykonują całkiem sporo funkcji: na przykład obliczają wyzwalacze, wypełniają pamięć podręczną wartości i, co najważniejsze, zapisują metryki w magazynie historii. Ogólnie proces jest złożony i bardzo zagmatwany.
MM: – Pierwszą rzeczą, którą zauważyliśmy, było to, że większość wątków konkuruje o tak zwaną „pamięć podręczną konfiguracji” (obszar pamięci, w którym przechowywane są wszystkie konfiguracje serwera). Szczególnie dużo blokują wątki odpowiedzialne za zbieranie danych:
...ponieważ konfiguracja przechowuje nie tylko metryki z ich parametrami, ale także kolejki, z których ankieterzy pobierają informacje o tym, co dalej robić. Gdy jest wiele pollerów i jeden blokuje konfigurację, pozostali czekają na żądania:
Osoby przeprowadzające ankietę nie powinny się kłócić
Dlatego pierwszą rzeczą, którą zrobiliśmy, było podzielenie kolejki na 4 części i umożliwienie ankieterom blokowania tych kolejek, tych części jednocześnie, w bezpiecznych warunkach:
Usunęło to konkurencję o pamięć podręczną konfiguracji, a szybkość odpytywania znacznie wzrosła. Ale potem napotkaliśmy fakt, ż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 jedyne, co mógł zrobić, to gromadzić żądania z procesów gromadzenia danych i dodawać ich bufor, aż zużyje całą pamięć i ulegnie awarii:
Aby rozwiązać ten problem, dodaliśmy drugie gniazdo dedykowane specjalnie dla pracowników:
Tym samym menadżer preprocesora miał możliwość ustalenia priorytetów swojej pracy i w przypadku wzrostu bufora zadaniem jest spowolnienie usuwania, dając pracownikom możliwość wykorzystania tego bufora:
Następnie odkryliśmy, że jedną z przyczyn spowolnienia byli sami pracownicy, ponieważ konkurowali o zasób, który był zupełnie nieistotny dla ich pracy. Udokumentowaliśmy ten problem jako naprawę błędu i został on już rozwiązany w nowych wersjach Zabbix:
Zwiększamy liczbę gniazd - otrzymujemy wynik
Co więcej, sam menedżer preprocesora stał się wąskim gardłem, ponieważ jest to jeden wątek. Opierał się na szybkości rdzenia, dając maksymalną prędkość około 70 tysięcy metrów na sekundę:
Dlatego zrobiliśmy czterech, z czterema zestawami gniazd, robotników:
A to pozwoliło nam zwiększyć prędkość do około 130 tysięcy metryk:
Nieliniowość wzrostu tłumaczy się pojawieniem się konkurencji o pamięć podręczną historii. Rywalizowało o nią 4 menedżerów preprocesorów i pogrążonych w historii. W tym momencie na maszynie testowej otrzymywaliśmy około 130 tysięcy metryk na sekundę, wykorzystując je w około 95% procesora:
Około 2,5 miesiąca temu
Odmowa ze strony snmp-community zwiększyła liczbę NVP półtorakrotnie
MM: – Max, potrzebuję nowego samochodu testowego! Nie pasujemy już do obecnego.
MCH: - Co masz teraz?
MM: – Teraz – 130 tys. NVP i procesor gotowy na półkę.
MCH: - Wow! Fajny! Czekaj, mam dwa pytania. Według moich obliczeń nasze zapotrzebowanie wynosi około 15-20 tysięcy metrów na sekundę. Dlaczego potrzebujemy więcej?
MM: „Chcę dokończyć tę pracę”. Chciałbym zobaczyć, ile możemy wycisnąć z tego systemu.
MCH: - Ale…
MM: „Ale to jest bezużyteczne w interesach”.
MCH: - Jest jasne. I drugie pytanie: czy jesteśmy w stanie wspomóc to, co mamy obecnie, sami, bez pomocy dewelopera?
MM: - Nie sądzę. Zmiana sposobu działania pamięci podręcznej konfiguracji stanowi problem. Wpływa na zmiany w większości wątków i jest dość trudny w utrzymaniu. Najprawdopodobniej bardzo trudno będzie go utrzymać.
MCH: – W takim razie potrzebujemy jakiejś alternatywy.
MM: - Jest taka opcja. Możemy przejść na szybkie rdzenie, rezygnując przy tym z nowego systemu blokowania. Nadal uzyskamy wydajność na poziomie 60-80 tys. metryk. Jednocześnie możemy zostawić całą resztę kodu. Clickhouse i odpytywanie asynchroniczne będą działać. I będzie łatwy w utrzymaniu.
MCH: - Niesamowity! Sugeruję, żebyśmy się tutaj zatrzymali.
Po optymalizacji po stronie serwera w końcu udało nam się uruchomić nowy kod w środowisku produkcyjnym. Z części zmian zrezygnowaliśmy na rzecz przejścia na maszynę z szybkimi rdzeniami i zminimalizowania ilości zmian w kodzie. Uprościliśmy także konfigurację i tam, gdzie było to możliwe, wyeliminowaliśmy makra w elementach danych, ponieważ wprowadzają one dodatkowe blokowanie.
Przykładowo rezygnacja z makra snmp-community, które często można znaleźć w dokumentacji i przykładach, w naszym przypadku umożliwiło dalsze przyspieszenie NVP o około 1,5 razy.
Po dwóch dniach produkcji
Usuwanie wyskakujących okienek z historią zdarzeń
MCH: – Misza, używamy systemu od dwóch dni i wszystko działa. Ale tylko wtedy, gdy wszystko działa! Zaplanowaliśmy prace nad przeniesieniem dość dużego segmentu sieci i ponownie sprawdzaliśmy na rękach, co poszło, a co nie.
MM: - Nie może być! Wszystko sprawdziliśmy 10 razy. Serwer błyskawicznie radzi sobie nawet z całkowitą niedostępnością sieci.
MCH: - Tak, wszystko rozumiem: serwer, baza danych, top, austat, logi - wszystko jest szybkie... Ale patrzymy na interfejs sieciowy, a na serwerze jest procesor "na półce" i to:
MM: - Jest jasne. Popatrzmy na internet. Odkryliśmy, że w sytuacji, gdy występowała duża liczba aktywnych incydentów, większość aktywnych widżetów zaczynała działać bardzo wolno:
Powodem tego było wygenerowanie wyskakujących okienek z historią zdarzeń, które są generowane dla każdej pozycji na liście. Dlatego porzuciliśmy generowanie tych okien (komentowaliśmy 5 linii kodu), co rozwiązało nasze problemy.
Czas ładowania widżetów, nawet gdy są całkowicie niedostępne, został skrócony z kilku minut do akceptowalnych dla nas 10-15 sekund, a historię nadal można przeglądać klikając na godzinę:
Po pracy. 2 miesiące temu
MCH: - Misza, wychodzisz? Musimy porozmawiać.
MM: - Nie miałem takiego zamiaru. Znowu coś z Zabbixem?
MCH: - Nie, uspokój się! Chciałem tylko powiedzieć: wszystko działa, dziękuję! Mam piwo.
Zabbix jest wydajny
Zabbix to dość uniwersalny i bogaty system i funkcjonalność. Może być stosowany w małych instalacjach od razu po wyjęciu z pudełka, ale w miarę wzrostu potrzeb należy go optymalizować. Aby przechowywać duże archiwum metryk, użyj odpowiedniego magazynu:
- możesz skorzystać z wbudowanych narzędzi w postaci integracji z Elasticsearch lub wgrania historii do plików tekstowych (dostępne od wersji XNUMX);
- Możesz skorzystać z naszego doświadczenia i integracji z Clickhouse.
Aby radykalnie zwiększyć szybkość zbierania metryk, należy je zbierać metodami asynchronicznymi i przesyłać poprzez interfejs trappera do serwera Zabbix; lub możesz użyć łatki, aby uczynić pollery Zabbix asynchronicznymi.
Zabbix jest napisany w C i jest dość wydajny. Rozwiązanie kilku wąskich gardeł architektonicznych pozwala na dalsze zwiększenie jego wydajności i, z naszego doświadczenia, uzyskanie ponad 100 tysięcy metryk na maszynie jednoprocesorowej.
Ta sama łatka Zabbix
MM: – Chcę dodać kilka punktów. Cały raport bieżący, wszystkie testy, numery podane są dla konfiguracji z której korzystamy. Obecnie pobieramy z niego około 20 tysięcy metryk na sekundę. Jeśli próbujesz zrozumieć, czy to zadziała dla Ciebie, możesz porównać. To, co zostało dzisiaj omówione, zostało opublikowane na GitHubie w formie łatki:
Łatka zawiera:
- pełna integracja z Clickhouse (zarówno serwerem Zabbix, jak i frontendem);
- rozwiązywanie problemów z menedżerem preprocesora;
- odpytywanie asynchroniczne.
Łatka jest kompatybilna ze wszystkimi wersjami 4, w tym lts. Najprawdopodobniej przy minimalnych zmianach będzie działać na wersji 3.4.
Dziękuję za uwagę.
pytania
Pytanie od publiczności (dalej – A): – Dzień dobry! Proszę, powiedz mi, czy masz plany intensywnej interakcji z zespołem Zabbix lub z nimi, aby nie była to łatka, ale normalne zachowanie Zabbix?
MM: – Tak, na pewno wprowadzimy część zmian. Coś się stanie, coś pozostanie w patchu.
A: – Dziękuję bardzo za wspaniały raport! Proszę powiedz mi, po zastosowaniu łatki wsparcie ze strony Zabbix pozostanie i jak kontynuować aktualizację do wyższych wersji? Czy będzie możliwa aktualizacja Zabbixa po aktualizacji do wersji 4.2, 5.0?
MM: – Nie mogę nic powiedzieć o wsparciu. Gdybym był wsparciem technicznym Zabbix, prawdopodobnie powiedziałbym nie, ponieważ jest to kod kogoś innego. Jeśli chodzi o bazę kodu 4.2, nasze stanowisko jest następujące: „Będziemy działać z czasem i będziemy aktualizować się w następnej wersji”. Dlatego przez jakiś czas będziemy publikować łatkę do zaktualizowanych wersji. Mówiłem już w raporcie: liczba zmian w wersjach jest nadal dość mała. Myślę, że przejście z 3.4 na 4 zajęło nam około 15 minut.Coś tam się zmieniło, ale niezbyt istotne.
A: – Czyli planujesz wspierać swoją łatkę i móc bezpiecznie zainstalować ją na produkcji oraz w jakiś sposób otrzymywać aktualizacje w przyszłości?
MM: – Gorąco polecamy. To rozwiązuje dla nas wiele problemów.
MCH: – Jeszcze raz chcę zwrócić uwagę na to, że zmiany, które nie dotyczą architektury i nie dotyczą blokowania czy kolejek, mają charakter modułowy, są w osobnych modułach. Nawet przy niewielkich zmianach można je dość łatwo utrzymać.
MM: – Jeśli interesują Cię szczegóły, „Clickhouse” korzysta z tzw. biblioteki historii. Jest rozwiązany - jest kopią obsługi Elastics, czyli jest konfigurowalny. Odpytywanie zmienia tylko ankieterów. Wierzymy, że to będzie działać przez długi czas.
A: - Wielkie dzięki. Powiedz mi, czy jest jakaś dokumentacja dokonanych zmian?
MM: – Dokumentacja to łatka. Oczywiście wraz z wprowadzeniem Clickhouse, wraz z wprowadzeniem nowych typów pollerów, pojawiają się nowe możliwości konfiguracji. Link z ostatniego slajdu zawiera krótki opis sposobu korzystania z niego.
O zastąpieniu fping przez nmap
A: – Jak w końcu to zaimplementowałeś? Czy możesz podać konkretne przykłady: czy masz strippery i zewnętrzny skrypt? Co powoduje tak szybkie sprawdzenie tak ogromnej liczby hostów? Jak wydobywasz te hosty? Czy musimy je jakoś zasilić nmap, pobrać skądś, umieścić, uruchomić coś?..
MM: - Fajny. Bardzo trafne pytanie! Rzecz w tym, że. Zmodyfikowaliśmy bibliotekę (ICMP ping, część Zabbix) pod kątem kontroli ICMP, które wskazują liczbę pakietów - jeden (1), a kod próbuje użyć nmap. Oznacza to, że jest to wewnętrzna praca Zabbixa, która stała się wewnętrzną pracą pingera. W związku z tym nie jest wymagana żadna synchronizacja ani użycie trapera. Zrobiono to celowo, aby pozostawić system w stanie nienaruszonym i nie zajmować się synchronizacją dwóch systemów baz danych: co sprawdzić, wgrać przez poller i czy nasze przesyłanie jest zepsute?.. To jest dużo prostsze.
A: – Czy to działa również dla proxy?
MM: – Tak, ale nie sprawdzaliśmy. Kod odpytywania jest taki sam zarówno w Zabbixie, jak i na serwerze. Powinno działać. Jeszcze raz podkreślę: wydajność systemu jest taka, że nie potrzebujemy proxy.
MCH: – Prawidłowa odpowiedź na pytanie brzmi: „Po co Ci serwer proxy z takim systemem?” Tylko ze względu na NAT lub monitorowanie przez jakiś wolny kanał...
A: – A ty używasz Zabbixa jako alertora, jeśli dobrze rozumiem. A może przeniosłeś swoją grafikę (w której znajduje się warstwa archiwalna) do innego systemu, np. Grafana? A może nie korzystasz z tej funkcjonalności?
MM: – Jeszcze raz podkreślę: osiągnęliśmy pełną integrację. Wlewamy historię do Clickhouse, ale jednocześnie zmieniamy frontend php. Nakładka PHP trafia do Clickhouse i stamtąd wykonuje całą grafikę. Jednocześnie, szczerze mówiąc, mamy część, która buduje dane w innych systemach graficznych z tego samego Clickhouse, z tych samych danych Zabbix.
MCH: – W „Grafanie” także.
W jaki sposób podejmowano decyzje dotyczące alokacji zasobów?
A: – Podziel się kawałkiem swojej wewnętrznej kuchni. Jak zapadła decyzja o konieczności przeznaczenia zasobów na poważne przetworzenie produktu? Są to, ogólnie rzecz biorąc, pewne zagrożenia. I powiedzcie mi, w kontekście tego, że będziecie wspierać nowe wersje: jak uzasadnia się tę decyzję z punktu widzenia zarządzania?
MM: – Najwyraźniej niezbyt dobrze opowiedzieliśmy dramat historii. Znaleźliśmy się w sytuacji, w której trzeba było coś zrobić i zasadniczo graliśmy dwoma równoległymi zespołami:
- Jednym z nich było uruchomienie systemu monitorowania z wykorzystaniem nowych metod: monitoring jako usługa, standardowy zestaw rozwiązań open source, które łączymy, a następnie staramy się zmienić proces biznesowy, aby współpracował z nowym systemem monitorowania.
- W tym samym czasie mieliśmy entuzjastycznego programistę, który się tym zajmował (o sobie). Tak się złożyło, że wygrał.
A: – A jaka jest wielkość zespołu?
MCH: - Ona jest przed tobą.
A: – Czyli jak zawsze potrzebny jest pasjonat?
MM: – Nie wiem, co to jest pasjonat.
A: - W tym przypadku najwyraźniej ty. Dziękuję bardzo, jesteś niesamowity.
MM: - Dziękuję.
Informacje o łatkach dla Zabbix
A: – Czy w przypadku systemu korzystającego z serwerów proxy (na przykład w niektórych systemach rozproszonych) można dostosować i załatać, powiedzmy, pollery, proxy i częściowo preprocesor samego Zabbixa; i ich interakcja? Czy możliwa jest optymalizacja istniejących rozwiązań dla systemu z wieloma serwerami proxy?
MM: – Wiem, że serwer Zabbix jest montowany przy użyciu proxy (kod jest kompilowany i pobierany). Nie testowaliśmy tego w produkcji. Nie jestem tego pewien, ale myślę, że menedżer preprocesora nie jest używany w proxy. Zadaniem proxy jest pobranie zestawu metryk z Zabbix, połączenie ich (zapisuje również konfigurację, lokalną bazę danych) i przekazanie go z powrotem do serwera Zabbix. Serwer sam wykona wstępne przetwarzanie po otrzymaniu wiadomości.
Zainteresowanie proxy jest zrozumiałe. Sprawdzimy to. To jest ciekawy temat.
A: – Pomysł był taki: jeśli można załatać ankietery, można załatać je na proxy i załatać interakcję z serwerem, a preprocesor przystosować do tych celów tylko na serwerze.
MM: – Myślę, że to jeszcze prostsze. Bierzesz kod, instalujesz łatkę, a następnie konfigurujesz tak, jak potrzebujesz - zbierasz serwery proxy (na przykład z ODBC) i rozpowszechniasz poprawiony kod w systemach. W razie potrzeby - zbierz serwer proxy, w razie potrzeby - serwer.
A: – Najprawdopodobniej nie będziesz musiał dodatkowo patchować transmisji proxy do serwera?
MCH: - Nie, to standard.
MM: – Faktycznie, jeden z pomysłów nie brzmiał. Zawsze zachowywaliśmy równowagę pomiędzy eksplozją pomysłów, a ilością zmian i łatwością wsparcia.
Kilka reklam 🙂
Dziękujemy za pobyt z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej ciekawych treści? Wesprzyj nas składając zamówienie lub polecając znajomym, , unikalny odpowiednik serwerów klasy podstawowej, który został przez nas wymyślony dla Ciebie: (dostępne z RAID1 i RAID10, do 24 rdzeni i do 40 GB DDR4).
Dell R730xd 2 razy taniej w centrum danych Equinix Tier IV w Amsterdamie? Tylko tutaj w Holandii! Dell R420 — 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gb/s 100 TB — od 99 USD! Czytać o
Źródło: www.habr.com