Logi są ważną częścią systemu, pozwalającą zrozumieć, że działa (lub nie działa) zgodnie z oczekiwaniami. W warunkach architektury mikroserwisowej praca z logami staje się odrębną dyscypliną Olimpiady Specjalnej. Jest wiele kwestii, które należy rozwiązać:
- jak pisać logi z aplikacji;
- gdzie zapisywać logi;
- jak dostarczać kłody do przechowywania i przetwarzania;
- jak przetwarzać i przechowywać logi.
Wykorzystanie popularnych obecnie technologii konteneryzacji dodaje piasku do góry w zakresie możliwości rozwiązywania problemów.
Mniej więcej o tym jest transkrypcja raportu Jurija Bushmeleva „Mapa prowizji w zakresie zbierania i dostarczania kłód”
Kogo to obchodzi, proszę pod kotem.
Nazywam się Jurij Buszmelew. Pracuję dla Lazady. Dzisiaj opowiem o tym, jak zrobiliśmy nasze logi, jak je zebraliśmy i co tam piszemy.
Skąd jesteśmy? Kim jesteśmy? Lazada jest internetowym sprzedawcą detalicznym nr 1 w sześciu krajach Azji Południowo-Wschodniej. Wszystkie te kraje są rozproszone po centrach danych. Obecnie są łącznie 4 centra danych. Dlaczego jest to ważne? Bo niektóre decyzje wynikały z faktu, że istnieje bardzo słabe powiązanie między ośrodkami. Mamy architekturę mikroserwisową. Zaskoczyło mnie, że mamy już 80 mikroserwisów. Kiedy zaczynałem zadanie z dziennikami, było ich tylko 20. Ponadto istnieje dość duża część dziedzictwa PHP, z którą również muszę żyć i znosić. Wszystko to generuje dla nas w tej chwili ponad 6 milionów komunikatów na minutę dla całego systemu. Dalej pokażę, jak próbujemy z tym żyć i dlaczego tak jest.
Z tymi 6 milionami wiadomości trzeba jakoś żyć. Co powinniśmy z nimi zrobić? Potrzebne 6 milionów wiadomości:
- wyślij z aplikacji
- przyjąć do dostawy
- dostarczyć do analizy i przechowywania.
- analizować
- przechowywać jakoś.
Kiedy były trzy miliony wiadomości, wyglądałem mniej więcej tak samo. Ponieważ zaczynaliśmy od kilku groszy. Oczywiste jest, że są tam zapisywane logi aplikacji. Na przykład nie mógł połączyć się z bazą danych, mógł połączyć się z bazą danych, ale nie mógł czegoś odczytać. Ale poza tym każda z naszych mikroserwisów zapisuje również dziennik dostępu. Każde żądanie, które dociera do mikrousługi, trafia do dziennika. Dlaczego to robimy? Deweloperzy chcą mieć możliwość śledzenia. Każdy log dostępu zawiera pole traceid, zgodnie z którym specjalny interfejs rozwija następnie cały łańcuch i pięknie wyświetla ślad. Śledzenie pokazuje przebieg żądania, co pomaga naszym programistom szybciej radzić sobie z nieznanymi śmieciami.
Jak z tym żyć? Teraz pokrótce opiszę pole opcji - jak ogólnie rozwiązuje się ten problem. Jak rozwiązać problem zbierania, przesyłania i przechowywania logów.
Jak pisać z aplikacji? Oczywiste jest, że istnieją różne sposoby. W szczególności istnieje najlepsza praktyka, jak mówią nam modni towarzysze. Jak mawiali dziadkowie, są dwa rodzaje starej szkoły. Istnieją inne sposoby.
W przypadku zbierania dzienników sytuacja jest w przybliżeniu taka sama. Nie ma tak wielu opcji rozwiązania tej konkretnej części. Jest ich więcej, ale jeszcze nie tak dużo.
Ale wraz z dostawą i późniejszą analizą liczba odmian zaczyna eksplodować. Nie będę teraz opisywał każdej opcji. Myślę, że główne opcje są dobrze znane każdemu, kto był zainteresowany tematem.
Pokażę Ci, jak to zrobiliśmy w Lazadzie i jak to się wszystko zaczęło.
Rok temu przyjechałem do Lazady i zostałem wysłany do projektu dziennika. Tam było tak. Log z aplikacji został zapisany na stdout i stderr. Wszystko zostało zrobione w modny sposób. Ale potem programiści wyrzucili to ze standardowych strumieni, a wtedy specjaliści od infrastruktury jakoś to rozwiążą. Pomiędzy specjalistami od infrastruktury a programistami są też wydawcy, którzy powiedzieli: „hm… cóż, po prostu zawińmy ich w plik z powłoką i to wszystko”. A ponieważ wszystko to znajduje się w kontenerze, zawinęli to bezpośrednio w sam kontener, zmapowali katalog w środku i umieścili go tam. Myślę, że dla każdego jest dość oczywiste, co się stało.
Spójrzmy trochę dalej. Jak dostarczyliśmy te dzienniki. Ktoś wybrał td-agent, który w rzeczywistości jest płynny, ale nie całkiem płynny. Nadal nie rozumiem związku tych dwóch projektów, ale wydaje mi się, że chodzi o to samo. I ten biegły, napisany w Ruby, odczytał pliki dziennika, przetworzył je na JSON przy użyciu pewnego rodzaju wyrażeń regularnych. Następnie wysłano ich do Kafki. Ponadto w Kafce mieliśmy 4 osobne tematy dla każdego API. Dlaczego 4? Ponieważ jest live, jest inscenizacja, a ponieważ jest stdout i stderr. Tworzą je programiści, a pracownicy infrastruktury muszą je tworzyć w Kafce. Co więcej, Kafka był kontrolowany przez inny dział. W związku z tym konieczne było utworzenie ticketu, aby utworzyli tam 4 tematy dla każdego api. Wszyscy o tym zapomnieli. Generalnie były to śmieci i odpady.
Co dalej z tym zrobiliśmy? Wysłaliśmy to do kafki. Dalej od Kafki połowa kłód poleciała do Logstash. Druga połowa dzienników została udostępniona. Niektórzy polecieli do jednego Grayloga, inni do innego Grayloga. W efekcie wszystko to zmieściło się w jednym klastrze Elasticsearch. Oznacza to, że cały ten bałagan spadł w końcu tam. Nie musisz tego robić!
Tak to wygląda patrząc z góry. Nie musisz tego robić! Tutaj problematyczne obszary są natychmiast oznaczane numerami. W rzeczywistości jest ich więcej, ale 6 jest naprawdę problematycznych, z którymi trzeba coś zrobić. Opowiem o nich teraz osobno.
Tutaj (1,2,3) piszemy pliki, a zatem są tu jednocześnie trzy grabie.
Pierwszy (1) polega na tym, że musimy je gdzieś zapisać. Nie zawsze jest pożądane, aby interfejs API mógł zapisywać bezpośrednio do pliku. Pożądane jest, aby interfejs API był izolowany w kontenerze, a jeszcze lepiej, aby był tylko do odczytu. Jestem administratorem systemu, więc mam trochę inne spojrzenie na te sprawy.
Drugi punkt (2,3) dotyczy tego, że mamy wiele żądań przychodzących do API. API zapisuje dużo danych do pliku. Pliki rosną. Musimy je obrócić. Ponieważ w przeciwnym razie nie będziesz mógł tam zapisać żadnych dysków. Obracanie ich jest złe, ponieważ są one przekierowywane przez powłokę do katalogu. W żaden sposób nie możemy go obrócić. Nie możesz nakazać aplikacji ponownego otwarcia uchwytów. Ponieważ programiści spojrzą na ciebie jak na głupca: „Jakie deskryptory? Zwykle piszemy na stdout. Frameworki utworzone przez copytruncate do logrotate, który po prostu tworzy kopię pliku i łączy oryginał. W związku z tym między tymi procesami kopiowania zwykle kończy się miejsce na dysku.
(4) Mieliśmy różne formaty w różnych interfejsach API. Były nieco inne, ale wyrażenie regularne musiało być napisane inaczej. Ponieważ wszystkim zarządzał Puppet, była duża grupa klas z własnymi karaluchami. Poza tym td-agent przez większość czasu mógł zjadać pamięć, być głupim, mógł po prostu udawać, że pracuje i nic nie robić. Na zewnątrz nie można było zrozumieć, że nic nie robi. W najlepszym razie upadnie, a ktoś go później podniesie. Mówiąc dokładniej, nadleci alarm i ktoś pójdzie i podniesie go rękami.
(6) A najwięcej śmieci i marnotrawstwa - to było elasticsearch. Bo to była stara wersja. Ponieważ nie mieliśmy wtedy oddanych mistrzów. Mieliśmy heterogeniczne dzienniki, których pola mogły się nakładać. Różne logi różnych aplikacji mogą być zapisywane z tymi samymi nazwami pól, ale jednocześnie mogą znajdować się w nich różne dane. Oznacza to, że jeden dziennik zawiera liczbę całkowitą w polu, na przykład poziom. Kolejny dziennik zawiera ciąg znaków w polu poziomu. W przypadku braku mapowania statycznego okazuje się taka cudowna rzecz. Jeśli po rotacji indeksu wiadomość z napisem dotarła jako pierwsza do elasticsearch, to żyjemy normalnie. A jeśli pierwszy przybył z liczbą całkowitą, wszystkie kolejne komunikaty, które dotarły z łańcuchem, są po prostu odrzucane. Ponieważ typ pola nie pasuje.
Zaczęliśmy zadawać te pytania. Postanowiliśmy nie szukać winnych.
Ale coś trzeba zrobić! Rzecz oczywista jest taka, że musimy ustanowić standardy. Mieliśmy już pewne standardy. Niektóre przywieźliśmy trochę później. Na szczęście w tamtym czasie zatwierdzono już jeden format dziennika dla wszystkich interfejsów API. Jest to wpisane bezpośrednio w standardy interakcji usług. W związku z tym ci, którzy chcą otrzymywać logi, powinni zapisywać je w tym formacie. Jeśli ktoś nie zapisuje logów w tym formacie, to nic nie gwarantujemy.
Ponadto chciałbym mieć jeden standard dotyczący metod rejestrowania, dostarczania i zbierania dzienników. Właściwie, gdzie je napisać i jak je dostarczyć. Idealną sytuacją jest sytuacja, gdy projekty korzystają z tej samej biblioteki. Istnieje oddzielna biblioteka logowania dla Go, istnieje oddzielna biblioteka dla PHP. Każdy, kogo mamy, każdy powinien z nich korzystać. W tej chwili powiedziałbym, że udaje nam się to w 80 procentach. Ale niektórzy nadal jedzą kaktusy.
A tam (na slajdzie) ledwo zaczyna się pojawiać „SLA dla dostarczania logów”. Jeszcze go nie ma, ale pracujemy nad tym. Bo to bardzo wygodne, gdy infra mówi, że jeśli napiszesz w takim a takim formacie do takiego a takiego miejsca i nie więcej niż N wiadomości na sekundę, to najprawdopodobniej tam to dostarczymy. Usuwa wiele bólów głowy. Jeśli istnieje umowa SLA, to po prostu świetnie!
Jak zaczęliśmy rozwiązywać problem? Główna prowizja była z td-agent. Nie było jasne, gdzie trafiają nasze dzienniki. Czy są dostarczane? Czy idą? Gdzie oni w ogóle są? Dlatego zdecydowano się zastąpić td-agent pierwszą pozycją. Opcje tego, czym go zastąpić, krótko opisałem tutaj.
biegły Po pierwsze, natknąłem się na niego w poprzedniej pracy i on też okresowo tam wpadał. Po drugie, to jest to samo, tylko z profilu.
bicie pliku. Jak to było dla nas dobre? Fakt, że jest w Go, a my mamy duże doświadczenie w Go. W związku z tym, jeśli już, moglibyśmy w jakiś sposób dodać to do siebie. Dlatego go nie wzięliśmy. Tak, żeby nie było nawet pokusy, by zacząć przepisywać to dla siebie.
Oczywistym rozwiązaniem dla sysadmina są wszelkiego rodzaju dzienniki systemowe w takiej ilości (syslog-ng/rsyslog/nxlog).
Lub napisz coś własnego, ale odrzuciliśmy to, podobnie jak filebeat. Jeśli coś piszesz, lepiej napisać coś przydatnego dla biznesu. Aby dostarczyć kłody, lepiej wziąć coś gotowego.
Dlatego wybór właściwie sprowadził się do wyboru między syslog-ng a rsyslog. Skłoniłem się ku rsyslog po prostu dlatego, że mieliśmy już klasy dla rsyslog w Puppet i nie znalazłem między nimi oczywistej różnicy. Co to jest syslog, co to jest syslog. Tak, niektóre dokumenty są gorsze, niektóre lepsze. Zna ten sposób i robi to inaczej.
I trochę o rsyslogu. Po pierwsze, jest fajny, bo ma dużo modułów. Ma czytelny dla człowieka RainerScript (nowoczesny język konfiguracji). Niesamowitą zaletą jest to, że mogliśmy naśladować zachowanie agenta td za pomocą jego standardowych narzędzi i nic się nie zmieniło w przypadku aplikacji. Oznacza to, że zmieniamy td-agent na rsyslog i nie dotykamy jeszcze wszystkiego innego. I od razu otrzymujemy działającą dostawę. Kolejną fajną rzeczą w rsyslog jest mmnormalize. Pozwala analizować logi, ale nie za pomocą Grok i regexp. Tworzy abstrakcyjne drzewo składniowe. Analizuje dzienniki w podobny sposób, w jaki kompilator analizuje kod źródłowy. Pozwala to pracować bardzo szybko, zużywać mało procesora i ogólnie jest to po prostu bardzo fajna rzecz. Jest jeszcze kilka innych bonusów. Nie będę się nad nimi rozwodzić.
rsyslog ma znacznie więcej wad. Są mniej więcej takie same jak bonusy. Główne problemy polegają na tym, że musisz umieć go ugotować i musisz wybrać wersję.
Zdecydowaliśmy, że będziemy pisać logi w gnieździe uniksowym. I nie w /dev/log, bo tam mamy bałagan w logach systemowych, jest zapisany w tym potoku. Napiszmy więc do niestandardowego gniazda. Dołączymy go do osobnego zestawu reguł. Nie ingerujmy w nic. Wszystko będzie przejrzyste i zrozumiałe. Więc faktycznie to zrobiliśmy. Katalog z tymi gniazdami jest ustandaryzowany i przekazywany do wszystkich kontenerów. Kontenery widzą potrzebne gniazdo, otwierają je i zapisują w nim.
Dlaczego nie plik? Bo wszyscy przeczytali , który próbował przekazać plik do dokera i stwierdził, że po ponownym uruchomieniu rsyslog deskryptor pliku zmienia się, a doker traci ten plik. Trzyma otwarte coś innego, ale nie to samo gniazdo, w którym piszą. Zdecydowaliśmy, że ominiemy ten problem, a jednocześnie ominiemy problem blokowania.
Rsyslog wykonuje czynności wskazane na slajdzie i wysyła logi do przekaźnika lub Kafki. Kafka podąża starą drogą. Rayleigh — próbowałem używać czystego rsyslog do dostarczania logów. Bez kolejki wiadomości, przy użyciu standardowych narzędzi rsyslog. Zasadniczo to działa.
Ale są niuanse, jak je później upchnąć w tej części (Logstash/Graylog/ES). Ta część (rsyslog-rsyslog) jest używana między centrami danych. Oto skompresowane łącze tcp, które pozwala zaoszczędzić przepustowość, a tym samym w jakiś sposób zwiększyć prawdopodobieństwo, że otrzymamy jakieś logi z innego centrum danych, gdy kanał jest pełny. Bo mamy Indonezję, gdzie wszystko jest złe. Na tym polega stały problem.
Zastanawialiśmy się, jak właściwie monitorujemy, z jakim prawdopodobieństwem logi, które zarejestrowaliśmy z aplikacji, dotrą do tego celu? Zdecydowaliśmy się rozpocząć pomiary. Rsyslog posiada własny moduł zbierania statystyk, który posiada swego rodzaju liczniki. Na przykład może pokazać rozmiar kolejki lub ile wiadomości przyszło do takiej a takiej akcji. Możesz już coś od nich wziąć. Ponadto ma niestandardowe liczniki, które możesz skonfigurować i pokaże Ci na przykład liczbę wiadomości zarejestrowanych przez niektóre API. Następnie napisałem rsyslog_exporter w Pythonie i wysłaliśmy to wszystko do Prometheusa i wykreśliliśmy. Bardzo chcieliśmy mieć metryki Grayloga, ale jak dotąd nie mieliśmy czasu ich skonfigurować.
Jakie są problemy? Problem pojawił się w momencie, gdy dowiedzieliśmy się (NAGLE!), że nasze Live API piszą 50k wiadomości na sekundę. To jest tylko Live API bez postoju. A Graylog pokazuje nam tylko 12 tysięcy wiadomości na sekundę. I pojawiło się rozsądne pytanie, gdzie są resztki? Z czego wywnioskowaliśmy, że Graylog po prostu sobie nie poradzi. Sprawdziliśmy i rzeczywiście Graylog z Elasticsearch nie opanował tego przepływu.
Następnie inne odkrycia, których dokonaliśmy po drodze.
Zapisy do gniazda są blokowane. Jak to się stało? Kiedy używałem rsyslog do dostarczania, w pewnym momencie zepsuliśmy kanał między centrami danych. Dostawa wstała w jednym miejscu, dostawa wstała w innym miejscu. Wszystko to sprowadza się do maszyny z interfejsami API, które zapisują do gniazda rsyslog. Była kolejka. Następnie zapełniła się kolejka do zapisu do gniazda uniksowego, która domyślnie wynosi 128 pakietów. I następny write() w blokach aplikacji. Gdy przyjrzeliśmy się bibliotece, której używamy w aplikacjach Go, było tam napisane, że zapis do gniazda odbywa się w trybie nieblokującym. Byliśmy pewni, że nic nie jest zablokowane. Bo przeczytaliśmy kto o tym pisał. Ale jest chwila. Wokół tego wywołania istniała również nieskończona pętla, w której następowała ciągła próba wepchnięcia wiadomości do gniazda. Nie zauważyliśmy go. Musiałem przepisać bibliotekę. Od tego czasu zmieniało się to kilka razy, ale teraz pozbyliśmy się blokad we wszystkich podsystemach. Dlatego możesz zatrzymać rsyslog i nic nie spadnie.
Konieczne jest monitorowanie wielkości kolejek, co pomaga nie nadepnąć na tę prowizję. Po pierwsze, możemy monitorować, kiedy zaczynamy tracić wiadomości. Po drugie, możemy monitorować, że w zasadzie mamy problemy z dostawą.
I jeszcze jeden nieprzyjemny moment - 10-krotne wzmocnienie w architekturze mikroserwisowej jest bardzo łatwe. Nie mamy tak wielu przychodzących żądań, ale ze względu na wykres, wzdłuż którego te komunikaty przebiegają dalej, ze względu na dzienniki dostępu, faktycznie zwiększamy obciążenie dzienników około dziesięciokrotnie. Niestety nie miałem czasu policzyć dokładnych liczb, ale mikroserwisy są jakie są. Należy o tym pamiętać. Okazuje się, że w tej chwili podsystem zbierania logów jest najbardziej obciążony w Lazadzie.
Jak rozwiązać problem z Elasticsearch? Jeśli potrzebujesz szybko zebrać logi w jednym miejscu, aby nie biegać po wszystkich maszynach i tam je gromadzić, skorzystaj z przechowywania plików. To gwarantuje, że zadziała. Odbywa się to z dowolnego serwera. Wystarczy włożyć tam dyski i umieścić syslog. Po tym masz gwarancję, że wszystkie dzienniki będą w jednym miejscu. Wtedy będzie można powoli konfigurować elasticsearch, graylog lub coś innego. Ale będziesz mieć już wszystkie logi, a ponadto możesz je przechowywać, o ile jest wystarczająca liczba macierzy dyskowych.
W momencie mojego raportu schemat zaczął wyglądać tak. Praktycznie przestaliśmy pisać do pliku. Teraz najprawdopodobniej wyłączymy pozostałości. Na lokalnych maszynach z uruchomionym API przestaniemy zapisywać do plików. Po pierwsze, jest przechowywanie plików, które działa bardzo dobrze. Po drugie, tym maszynom ciągle brakuje miejsca, trzeba to stale monitorować.
Ta część z Logstash i Graylog naprawdę szybuje. Dlatego musisz się go pozbyć. Musisz wybrać jeden.
Postanowiliśmy zrezygnować z Logstasha i Kibany. Ponieważ mamy dział bezpieczeństwa. Jakie jest połączenie? Połączenie jest takie, że Kibana bez X-Pack i bez Shield nie pozwala na różnicowanie praw dostępu do logów. Dlatego zabrali Grayloga. Ma to wszystko. Nie lubię tego, ale działa. Kupiliśmy nowy sprzęt, zainstalowaliśmy tam świeżego Grayloga i przenieśliśmy wszystkie logi ze ścisłymi formatami do osobnego Grayloga. Rozwiązaliśmy organizacyjnie problem z różnymi typami tych samych pól.
Co dokładnie zawiera nowy Graylog. Po prostu napisaliśmy wszystko w oknie dokowanym. Wzięliśmy kilka serwerów, wdrożyliśmy trzy instancje Kafki, 7 serwerów Graylog w wersji 2.3 (ponieważ chciałem Elasticsearch w wersji 5). Wszystko to zostało podniesione podczas nalotów z dysku twardego. Widzieliśmy szybkość indeksowania do 100 tysięcy wiadomości na sekundę. Widzieliśmy liczbę 140 terabajtów danych tygodniowo.
I znowu grabie! Przed nami dwie wyprzedaże. Przekroczyliśmy liczbę 6 milionów postów. My Graylog nie mamy czasu na żucie. Jakoś trzeba znowu przeżyć.
W ten sposób przetrwaliśmy. Dodano kilka dodatkowych serwerów i dysków SSD. W tej chwili żyjemy tak. Teraz przeżuwamy już 160 XNUMX wiadomości na sekundę. Nie osiągnęliśmy jeszcze limitu, więc nie jest jasne, ile realnie możemy z niego wyciągnąć.
To są nasze plany na przyszłość. Spośród nich tak naprawdę najważniejsza jest prawdopodobnie wysoka dostępność. Jeszcze go nie mamy. Kilka samochodów jest ustawionych w ten sam sposób, ale jak dotąd wszystko przechodzi przez jeden samochód. Konieczne jest poświęcenie czasu na skonfigurowanie przełączania awaryjnego między nimi.
Zbieraj dane z Grayloga.
Ustaw limit szybkości, abyśmy mieli jeden szalony interfejs API, który nie zabija nam przepustowości i wszystkiego innego.
I wreszcie, podpisz jakąś umowę SLA z programistami, abyśmy mogli tyle obsłużyć. Jeśli napiszesz więcej, to przepraszam.
I napisz dokumentację.
Krótko mówiąc, wyniki wszystkiego, czego doświadczyliśmy. Po pierwsze standardy. Po drugie, syslog to ciasto. Po trzecie, rsyslog działa dokładnie tak, jak jest napisane na slajdzie. I przejdźmy do pytań.
pytania.
pytanie: Dlaczego zdecydowali się nie brać… (filebeat?)
odpowiedź: Trzeba zapisać do pliku. Naprawdę nie chciałem. Kiedy twój interfejs API pisze tysiące wiadomości na sekundę, nawet jeśli obracasz się raz na godzinę, nadal nie jest to możliwe. Możesz pisać do potoku. Na co twórcy zapytali mnie: „Co się stanie, jeśli proces, w którym piszemy, upadnie”? Po prostu nie znalazłem, co im odpowiedzieć, i powiedziałem: „No dobrze, nie róbmy tego”.
pytanie: Dlaczego po prostu nie zapiszesz logów w HDFS?
odpowiedźO: To jest następny etap. Myśleliśmy o tym na samym początku, ale ponieważ w tej chwili nie ma środków, aby sobie z tym poradzić, wisi to w naszym długoterminowym rozwiązaniu.
pytanie: Bardziej odpowiedni byłby format kolumnowy.
odpowiedź: Rozumiem. Jesteśmy „za” obiema rękami.
pytanie: Piszesz do rsyslog. Dostępne są tam zarówno TCP, jak i UDP. Ale jeśli UDP, to w jaki sposób gwarantujesz dostawę?
odpowiedźO: Są dwa punkty. Po pierwsze, od razu wszystkim mówię, że nie gwarantujemy dostarczenia logów. Bo kiedy przychodzą programiści i mówią: „Zacznijmy tam pisać dane finansowe, a ty je gdzieś dla nas umieścisz na wypadek, gdyby coś się działo”, odpowiadamy im: „Świetnie! Zacznijmy blokować pisanie do gniazda i róbmy to w transakcjach, tak abyś miał gwarancję włożenia go do gniazda za nas i upewnienia się, że otrzymaliśmy go z drugiej strony. I w tym momencie wszyscy natychmiast stają się niepotrzebni. A jeśli nie, to jakie mamy pytania? Jeśli nie chcesz gwarantować zapisu do gniazda, to dlaczego mielibyśmy gwarantować dostawę? Dokładamy wszelkich starań. Naprawdę staramy się dostarczać jak najwięcej i jak najlepiej, ale nie dajemy 100% gwarancji. Dlatego nie trzeba tam zapisywać danych finansowych. Istnieją do tego transakcyjne bazy danych.
pytanie: Kiedy interfejs API generuje jakiś komunikat w dzienniku i przekazuje kontrolę do mikroserwisów, czy napotkałeś problem polegający na tym, że komunikaty z różnych mikroserwisów docierają w niewłaściwej kolejności? Z tego powodu powstaje zamieszanie.
odpowiedźO: To normalne, że pojawiają się w innej kolejności. Musisz być na to gotowy. Ponieważ żadna dostawa sieciowa nie gwarantuje ci zamówienia lub musisz wydać na to specjalne środki. Jeśli weźmiemy magazyny plików, to każdy interfejs API zapisuje logi do własnego pliku. Zamiast tego rsyslog rozkłada je na katalogi. Każdy interfejs API ma tam swoje własne dzienniki, do których można przejść i zajrzeć, a następnie porównać je za pomocą znacznika czasu w tym dzienniku. Jeśli pójdą szukać w Graylog, tam zostaną posortowane według znacznika czasu. Tam wszystko będzie dobrze.
pytanie: Sygnatura czasowa może różnić się o milisekundy.
odpowiedź: Sygnatura czasowa jest generowana przez sam interfejs API. W rzeczywistości to jest cały punkt. Mamy NTP. API generuje znacznik czasu już w samej wiadomości. Nie jest dodawany przez rsyslog.
pytanie: Interakcja między centrami danych nie jest bardzo jasna. W ramach centrum danych jasne jest, w jaki sposób logi były gromadzone i przetwarzane. Jak wygląda interakcja między centrami danych? A może każde centrum danych żyje własnym życiem?
odpowiedź: Prawie. Mamy każdy kraj zlokalizowany w jednym centrum danych. Obecnie nie mamy rozproszenia, więc jeden kraj jest umieszczony w różnych centrach danych. Dlatego nie ma potrzeby ich łączenia. Wewnątrz każdego centrum znajduje się Log Relay. To jest serwer Rsyslog. W rzeczywistości dwie maszyny zarządzające. Są ustawione w ten sam sposób. Ale na razie ruch odbywa się tylko przez jedną z nich. Rejestruje wszystko, co się sumuje. Na wszelki wypadek ma kolejkę dysku. Naciska logi i wysyła je do centralnego data center (Singapur), gdzie dalej są już zatrute w Graylog. Każde centrum danych ma własny magazyn plików. W przypadku utraty połączenia mamy tam wszystkie logi. Tam zostaną. Tam będą przechowywane.
pytanie: Czy dostajesz stamtąd logi w nietypowych sytuacjach?
odpowiedź: Możesz tam iść (do magazynu plików) i spojrzeć.
pytanie: Jak monitorujesz, czy nie tracisz logów?
odpowiedź: W rzeczywistości je tracimy i monitorujemy to. Monitoring rozpoczął się miesiąc temu. Biblioteka, z której korzystają interfejsy API Go, zawiera metryki. Potrafi policzyć, ile razy nie udało jej się napisać do gniazda. W tej chwili istnieje trudna heurystyka. Tam jest bufor. Próbuje napisać z niego wiadomość do gniazda. Jeśli bufor się przepełni, zaczyna je upuszczać. I liczy, ile ich upuścił. Jeśli liczniki zaczną się tam przelewać, będziemy o tym wiedzieć. Teraz pojawiają się również w Prometeuszu, a wykresy można zobaczyć w Grafanie. Możesz ustawić alerty. Ale nie jest jeszcze jasne, do kogo je wysłać.
pytanie: W Elasticsearch przechowujesz dzienniki z redundancją. Ile masz replik?
odpowiedź: Jedna replika.
pytanie: Czy to tylko jedna linia?
odpowiedź: To jest wzorzec i replika. Dane są przechowywane w dwóch egzemplarzach.
pytanie: Czy w jakiś sposób poprawiłeś rozmiar bufora rsyslog?
odpowiedź: Piszemy datagramy do niestandardowego gniazda uniksowego. To natychmiast nakłada na nas ograniczenie do 128 kilobajtów. Nie możemy napisać więcej. Wpisaliśmy to do normy. Kto chce dostać się do pamięci, pisze 128 kilobajtów. Biblioteki zresztą ucinają i stawiają flagę, że wiadomość jest obcięta. W standardzie samej wiadomości mamy specjalne pole, które pokazuje, czy została ona ucięta podczas nagrywania, czy nie. Mamy więc możliwość śledzenia tego momentu.
Pytanie: Czy piszesz zepsuty JSON?
odpowiedź: Zepsuty kod JSON zostanie odrzucony podczas przekazywania, ponieważ pakiet jest za duży. Lub Graylog zostanie usunięty, ponieważ nie będzie w stanie przeanalizować JSON. Ale są tutaj niuanse, które należy naprawić, i są one w większości powiązane z rsyslog. Wypełniłem już tam kilka kwestii, nad którymi trzeba jeszcze popracować.
Pytanie: Dlaczego Kafka? Czy próbowałeś RabbitMQ? Graylog nie sumuje się przy takich obciążeniach?
odpowiedź: To nie działa z Graylog. A Graylog nabiera kształtu. To dla niego naprawdę problematyczne. On jest czymś w rodzaju. I właściwie nie jest to potrzebne. Wolę pisać z rsyslog bezpośrednio do elasticsearch, a potem oglądać Kibanę. Ale musimy załatwić sprawę z ochroniarzami. Jest to możliwy wariant naszego rozwoju, gdy wyrzucimy Grayloga i użyjemy Kibany. Logstash nie będzie miał sensu. Ponieważ mogę zrobić to samo z rsyslog. I ma moduł do pisania do elasticsearch. Z Graylog próbujemy jakoś żyć. Nawet trochę go zmodyfikowaliśmy. Ale wciąż jest miejsce na poprawę.
O Kafce. Tak to się działo historycznie. Kiedy przyjechałem, już tam był i logi były już do niego zapisywane. Właśnie podnieśliśmy nasz klaster i przenieśliśmy do niego logi. Zarządzamy nim, wiemy, jak się czuje. Jeśli chodzi o RabbitMQ... mamy problem z RabbitMQ. A RabbitMQ rozwija się dla nas. Mamy go w produkcji i były z nim problemy. Teraz, przed sprzedażą, zostałby szamanizowany i zacząłby normalnie pracować. Ale wcześniej nie byłem gotowy, aby wypuścić go do produkcji. Jest jeszcze jeden punkt. Graylog może odczytywać wersję AMQP 0.9, a rsyslog może zapisywać wersję AMQP 1.0. I nie ma jednego rozwiązania, które może zrobić oba w środku. Jest albo jedno albo drugie. Więc na razie tylko Kafka. Ale są też niuanse. Ponieważ omkafka wersji rsyslog, której używamy, może stracić cały bufor wiadomości, który pobrał z rsyslog. O ile to zniesiemy.
Pytanie: Czy używasz Kafki, bo ją miałeś? Nie używany do innych celów?
odpowiedź: Kafka, z którego korzystał zespół Data Science. To zupełnie osobny projekt, o którym niestety nie mogę nic powiedzieć. Nie wiem. Prowadził ją zespół Data Science. Kiedy zaczęły się logi, postanowili to wykorzystać, żeby nie stawiać własnych. Teraz zaktualizowaliśmy Grayloga i straciliśmy kompatybilność, ponieważ istnieje stara wersja Kafki. Musieliśmy zrobić własne. Jednocześnie pozbyliśmy się tych czterech tematów dla każdego API. Zrobiliśmy jeden szeroki top dla wszystkich na żywo, jeden szeroki top dla wszystkich inscenizacji i po prostu kręcimy tam wszystko. Graylog zbiera to wszystko równolegle.
Pytanie: Po co nam ten szamanizm z gniazdkami? Czy próbowałeś użyć sterownika dziennika syslog dla kontenerów.
odpowiedź: W momencie, kiedy zadawaliśmy to pytanie, mieliśmy napięte relacje z dokerem. To był docker 1.0 lub 0.9. Sam Docker był dziwny. Po drugie, jeśli dodatkowo wepchniesz do niego logi... Mam niezweryfikowane podejrzenie, że wszystkie logi przepuszcza przez siebie, przez demona dokera. Jeśli mamy szalone API, reszta API napotka fakt, że nie mogą wysyłać stdout i stderr. Nie wiem, dokąd to doprowadzi. Mam podejrzenie na poziomie przeczucia, że nie ma potrzeby używania w tym miejscu sterownika docker syslog. Nasz dział testów funkcjonalnych posiada własny klaster Graylog z logami. Używają sterowników docker log i wydaje się, że wszystko jest w porządku. Ale natychmiast piszą GELF do Grayloga. W momencie, kiedy to wszystko zaczynaliśmy, potrzebowaliśmy tego, żeby po prostu działało. Może później, jak ktoś przyjdzie i powie, że od stu lat normalnie pracuje, to spróbujemy.
Pytanie: Dostarczasz dane między centrami danych za pomocą rsyslog. Dlaczego nie na Kafce?
odpowiedź: Robimy to i tak jest naprawdę. Z dwóch powodów. Jeśli kanał jest całkowicie martwy, wszystkie nasze logi, nawet w skompresowanej formie, nie będą przez niego przechodzić. A kafka pozwala im po prostu przegrać w tym procesie. W ten sposób pozbywamy się sklejania tych bali. W tym przypadku po prostu używamy Kafki bezpośrednio. Jeśli mamy dobry kanał i chcemy go zwolnić, używamy ich rsyslog. Ale w rzeczywistości możesz go skonfigurować tak, aby upuszczał to, przez co nie przeszedł. W tej chwili po prostu używamy dostarczania rsyslog bezpośrednio gdzieś, gdzieś Kafka.
Źródło: www.habr.com