🥇Jak budowaliśmy monitoring na Prometheus, Clickhouse i ELK

Nazywam się Anton Baderin. Pracuję w Centrum Wysokich Technologii i zajmuję się administracją systemów. Miesiąc temu zakończyła się nasza konferencja korporacyjna, na której dzieliśmy się zgromadzonym doświadczeniem z społecznością IT w naszym mieście. Opowiadałem o monitorowaniu aplikacji internetowych. Materiał był przeznaczony dla osób na poziomie junior lub middle, które nie budowały tego procesu od podstaw.

Kamień węgielny każdej systemu monitorowania to rozwiązanie problemów biznesowych. Monitorowanie dla monitorowania nie interesuje nikogo. Czego chce biznes? Aby wszystko działało szybko i bez błędów. Biznes chce proaktywności, abyśmy sami identyfikowali problemy w pracy usług i jak najszybciej je rozwiązywali. To właśnie były zadania, które rozwiązywałem przez cały zeszły rok w projekcie jednego z naszych klientów.

O projekcie

Projekt to jeden z największych programów lojalnościowych w kraju. Pomagamy sieciom detalicznym zwiększać częstotliwość sprzedaży dzięki różnym narzędziom marketingowym takim jak karty lojalnościowe. W sumie w projekcie bierze udział 14 aplikacji, które działają na dziesięciu serwerach.

Podczas przeprowadzania rozmów kwalifikacyjnych wielokrotnie zauważyłem, że administratorzy nie zawsze podchodzą właściwie do monitorowania aplikacji internetowych: wciąż wielu poprzestaje na metrykach systemu operacyjnego, okazjonalnie monitorując usługi.

W moim przypadku system monitorowania klienta wcześniej opierał się na Icinga. Nie rozwiązywał on wskazanych wcześniej problemów. Często klient sam informował nas o problemach, a nie rzadko brakowało nam danych, aby dotrzeć do przyczyny.

Ponadto istniało jasne zrozumienie beznadziejności dalszego rozwoju. Myślę, że ci, którzy znają Icinga, mnie zrozumieją. Tak więc zdecydowaliśmy się całkowicie przebudować system monitorowania aplikacji internetowych w projekcie.

Prometheus

Wybraliśmy Prometheus, kierując się trzema głównymi wskaźnikami:

Ogromna ilość dostępnych metryk. W naszym przypadku jest ich 60 tysięcy. Oczywiście należy zauważyć, że przytłaczająca większość z nich nie jest używana (około 95%). Z drugiej strony, wszystkie są stosunkowo tanie. Dla nas to zupełnie inny skraj, w porównaniu do wcześniej używanego Icinga. W niej dodawanie metryk było szczególnie bolesne: posiadane były drogie (wystarczy spojrzeć na źródła dowolnego pluginu). Każdy plugin był skryptem w Bash lub Pythonie, których uruchamianie jest kosztowne z perspektywy zużywanych zasobów.
Ten system zużywa stosunkowo niewiele zasobów. Na wszystkie nasze metryki wystarcza 600 MB pamięci RAM, 15% jednego rdzenia i kilka dziesiątek IOPS. Oczywiście musimy uruchamiać exportery metryk, ale wszystkie są napisane w Go i także nie są zbyt wymagające. Nie sądzę, żeby w dzisiejszych czasach stanowiło to problem.
Daje możliwość przejścia na Kubernetes. Biorąc pod uwagę plany klienta – wybór jest oczywisty.

ELK

Wcześniej nie zbieraliśmy i nie przetwarzaliśmy logów. Niedogodności są jasne dla wszystkich. Wybraliśmy ELK, ponieważ mieliśmy już doświadczenie z tym systemem. Przechowujemy tam tylko logi aplikacji. Głównymi kryteriami wyboru były pełnotekstowe wyszukiwanie i jego szybkość.

Clickhouse

Początkowo wybraliśmy InfluxDB. Zdawaliśmy sobie sprawę z potrzeby zbierania logów Nginx, statystyki z pg_stat_statements, przechowywania danych historycznych Prometheusa. Influx nam się nie spodobał, ponieważ od czasu do czasu zaczynał zużywać dużą ilość pamięci i padał. Dodatkowo, chcieliśmy grupować zapytania według remote_addr, a grupowanie w tej bazie danych było tylko po tagach. Tagowanie jest kosztowne (pamięć), a ich liczba jest ograniczona.

Zaczęliśmy poszukiwania od nowa. Potrzebna była baza analityczna o minimalnym zużyciu zasobów, najlepiej z kompresją danych na dysku.

Clickhouse spełnia wszystkie te kryteria, i ani razu nie żałowaliśmy wyboru. Nie zapisujemy tam jakichś wyjątkowych obciążeń danych (liczba wstawek to około pięciu tysięcy na minutę).

NewRelic

NewRelic historycznie był z nami, ponieważ był wyborem klienta. Używamy go jako APM.

Zabbix

Używamy Zabbix tylko do monitorowania Black Box różnych API.

Określenie podejścia do monitorowania

Chcieliśmy rozłożyć zadanie na czynniki i w ten sposób zsystematyzować podejście do monitorowania.

W tym celu podzieliłem nasz system na następujące poziomy:

sprzęt i VMS;
system operacyjny;
usługi systemowe, stos oprogramowania;
aplikacja;
logika biznesowa.

Jakie są zalety takiego podejścia:

wiemy, kto odpowiada za działanie każdego z poziomów i na tej podstawie możemy wysyłać alerty;
możemy korzystać z tej struktury przy tłumieniu alertów - byłoby dziwnie wysyłać alert o niedostępności bazy danych, gdy cały wirtualny serwer jest niedostępny.

Ponieważ naszym zadaniem jest identyfikacja naruszeń w działaniu systemu, musimy na każdym poziomie выделить pewien zestaw metryk, na które warto zwrócić uwagę przy pisaniu reguł alertowania. Przejdziemy teraz przez poziomy „VMS”, „System operacyjny” i „Usługi systemowe, stos oprogramowania”.

Maszyny wirtualne

Hosting przydzielają nam procesor, dysk, pamięć i sieć. Mieliśmy problemy z dwoma pierwszymi, więc metryki:

Czas kradzieży CPU - gdy kupujesz wirtualną maszynę na Amazonie (na przykład t2.micro), należy rozumieć, że przypisane zostaje nie całe rdzenie CPU, a jedynie kwota jego czasu. A gdy ją wyczerpiesz, procesor zaczną ci zabierać.

Ta metryka pozwala monitorować takie sytuacje i podejmować decyzje. Na przykład, czy trzeba przejść na bardziej zasobny plan lub podzielić przetwarzanie zadań w tle i zapytań API na różne serwera.

IOPS + czas oczekiwania CPU iowait - wiele hostów w chmurze ma problem z niedostarczeniem IOPS. Co więcej, grafika z niskimi IOPS nie jest dla nich argumentem. Dlatego warto zbierać także czas oczekiwania CPU iowait. Z tymi dwoma zaletami - niskimi IOPS i wysokim oczekiwaniem na wejście/wyjście - można już rozmawiać z hostingiem i rozwiązywać problem.

System operacyjny

Metryki systemu operacyjnego:

ilość dostępnej pamięci w %;
aktywność wykorzystania swap: vmstat swapin, swapout;
ilość dostępnych inode i wolnego miejsca w systemie plików w %;
średnie obciążenie;
liczba połączeń w stanie tw;
wypełnienie tabeli conntrack;
jakość działania sieci można monitorować za pomocą narzędzia ss, pakietu iproute2 - uzyskiwać z jego wyników wskaźnik RTT połączeń i grupować według portu dest.

Również na poziomie systemu operacyjnego pojawia się nam taka jednostka, jak procesy. Ważne jest, aby выделить w systemie zestaw procesów, które odgrywają ważną rolę w jego działaniu. Na przykład, jeśli masz kilka pgpool, należy zbierać informacje o każdym z nich.

Zestaw metryk jest następujący:

CPU;
pamięć — przede wszystkim pamięć operacyjna;
IO — preferowane w IOPS;
FileFd — otwarte i limit;
istotne błędy stron — w ten sposób możesz zrozumieć, który proces przeprowadza swapping.

Całe monitorowanie jest u nas zainstalowane w Dockerze, do zbierania danych metryk używamy Cadvisor. Na innych maszynach stosujemy process-exporter.

Usługi systemowe, stos oprogramowania

Każda aplikacja ma swoją specyfikę, i trudno jest wyróżnić jakiś zestaw metryk.

Uniwersalny zestaw to:

wskaźnik żądań;
liczba błędów;
latencja;
saturacja.

Najbardziej wyraziste przykłady monitorowania tego poziomu to Nginx i PostgreSQL.

Najbardziej obciążoną usługą w naszym systemie jest baza danych. Wcześniej mieliśmy dość często problemy z ustaleniem, czym zajmuje się baza danych.

Widząc wysokie obciążenie dysków, ale logi slow nie pokazywały nic sensownego. Ten problem rozwiązaliśmy za pomocą pg_stat_statements, widoku, w którym gromadzone są statystyki dotyczące zapytań.

To wszystko, czego potrzebuje administrator.

Budujemy wykresy aktywności zapytań do odczytu i zapisu:

Wszystko jest proste i czytelne, każde zapytanie ma swój kolor.

Nie mniej wyrazisty przykład to logi Nginx. Nic dziwnego, że mało kto je parsuje lub wspomina o nich w liście obowiązkowych. Standardowy format nie jest zbyt informacyjny i należy go rozszerzać.

Osobiście dodałem request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Budujemy wykresy czasu odpowiedzi i liczby błędów:

Budujemy wykresy czasu odpowiedzi i liczby błędów. Pamiętasz? mówiłem o zadaniach biznesowych? Żeby szybko i bezbłędnie? Już dwoma wykresami rozwiązaliśmy te kwestie. I na ich podstawie już można dzwonić do dyżurnych administratorów.

Jednak pozostał jeszcze jeden problem — zapewnić szybkie usunięcie przyczyn incydentu.

Usuwanie incydentów

Cały proces od wykrycia do rozwiązania problemu można podzielić na szereg kroków:

wykrycie problemu;
powiadomienie dyżurnego administratora;
reakcja na incydent;
usunięcie przyczyn.

Ważne, abyśmy robili to maksymalnie szybko. A jeśli na etapach wykrywania problemu i wysyłania powiadomienia nie możemy zaoszczędzić szczególnie dużo czasu — w każdym razie zajmie to dwie minuty, to kolejne etapy — to po prostu nieprzekształcone pole do udoskonaleń.

Wyobraźmy sobie, że telefon dyżurnego zadzwonił. Co on zrobi? Będzie szukał odpowiedzi na pytania — co się zepsuło, gdzie się zepsuło, jak zareagować? W ten sposób odpowiadamy na te pytania:

Po prostu włączamy wszystkie te informacje do treści powiadomienia, dając w nim link do strony w wiki, gdzie opisano, jak reagować na ten problem, jak go rozwiązywać i eskalować.

Wciąż nie wspomniałem o poziomie aplikacji i logice biznesowej. Niestety w naszych aplikacjach wciąż nie jest wdrożone zbieranie metryk. Jedynym źródłem jakiejkolwiek informacji z tych poziomów są logi.

Kilka punktów.

Po pierwsze, piszcie uporządkowane logi. Nie dołączajcie kontekstu do treści wiadomości. Utrudnia to ich grupowanie i analizę. Logstash wymaga dużo czasu na normalizację tego.

Po drugie, prawidłowo używajcie poziomów severity. Każdy język ma swój standard. Osobiście wyróżniam cztery poziomy:

brak błędów;
błąd po stronie klienta;
błąd po naszej stronie, nie tracimy pieniędzy, nie ponosimy ryzyka;
błąd po naszej stronie, tracimy pieniądze.

Podsumowując. Należy dążyć do monitorowania od logiki biznesowej. Starać się monitorować samą aplikację oraz operować takimi metrykami, jak liczba sprzedaży, liczba nowych rejestracji użytkowników, liczba aktywnych użytkowników w danym momencie i tak dalej.

Jeśli całe Twoje przedsiębiorstwo to jeden przycisk w przeglądarce, konieczne jest monitorowanie, czy jest on naciskany, czy działa prawidłowo. Wszystko inne nie ma znaczenia.

Jeśli tego nie macie, możecie spróbować nadrobić to w logach aplikacji, logach Nginx i tak dalej, jak to zrobiliśmy my. Powinniście być jak najbliżej aplikacji.

Metryki systemu operacyjnego są oczywiście ważne, ale nie interesują biznesu, nie płacą nam za nie.

Źródło: habr.com