Nazywam się Anton Baderin. Pracuję w High Technology Center i zajmuję się administracją systemami. Miesiąc temu zakończyła się nasza konferencja firmowa, podczas której podzieliliśmy się zdobytymi doświadczeniami ze społecznością IT naszego miasta. Mówiłem o monitorowaniu aplikacji internetowych. Materiał był przeznaczony dla osób na poziomie młodszym lub średnim, które nie budowały tego procesu od zera.
Podstawą każdego systemu monitorowania jest rozwiązywanie problemów biznesowych. Monitoring dla samego monitorowania nikogo nie interesuje. Czego chce biznes? Aby wszystko działało szybko i bez błędów. Firmy chcą działać proaktywnie, abyśmy sami identyfikowali problemy w serwisie i naprawiali je tak szybko, jak to możliwe. To właściwie problemy, które rozwiązałem przez cały ubiegły rok w ramach projektu dla jednego z naszych klientów.
o
Projekt jest jednym z największych programów lojalnościowych w kraju. Pomagamy sieciom handlowym zwiększyć częstotliwość sprzedaży poprzez różne narzędzia marketingowe, takie jak karty bonusowe. W sumie projekt obejmuje 14 aplikacji, które działają na dziesięciu serwerach.
Podczas rozmowy kwalifikacyjnej wielokrotnie zauważyłem, że administratorzy nie zawsze prawidłowo podchodzą do monitorowania aplikacji internetowych: wielu nadal koncentruje się na metrykach systemu operacyjnego i okazjonalnie monitoruje usługi.
W moim przypadku system monitoringu klienta był wcześniej oparty o Icingę. W żaden sposób nie rozwiązało to powyższych problemów. Często klient sam informował nas o problemach, a najczęściej po prostu nie mieliśmy wystarczających danych, aby dojść do sedna przyczyny.
Ponadto było jasne zrozumienie daremności jego dalszego rozwoju. Myślę, że ci, którzy znają Icingę, zrozumieją mnie. Dlatego postanowiliśmy całkowicie przeprojektować system monitorowania aplikacji internetowych na potrzeby projektu.
Prometheus
Wybraliśmy Prometeusza na podstawie trzech głównych wskaźników:
- Ogromna ilość dostępnych metryk. W naszym przypadku jest ich 60 tysięcy. Oczywiście warto zaznaczyć, że zdecydowanej większości z nich nie używamy (prawdopodobnie około 95%). Z drugiej strony wszystkie są stosunkowo tanie. Dla nas to druga skrajność w porównaniu do wcześniej stosowanej Icingi. W tym przypadku dodawanie metryk było szczególnym problemem: istniejące były drogie (wystarczy spojrzeć na kod źródłowy dowolnej wtyczki). Dowolną wtyczką był skrypt w języku Bash lub Python, którego uruchomienie jest kosztowne pod względem zużywanych zasobów.
- System ten zużywa stosunkowo niewielką ilość zasobów. 600 MB RAM, 15% jednego rdzenia i kilkadziesiąt IOPS wystarczy na wszystkie nasze metryki. Oczywiście musisz uruchomić eksportery metryk, ale wszystkie są napisane w Go i również nie są bardzo energochłonne. Nie sądzę, żeby we współczesnych realiach był to problem.
- Zapewnia możliwość migracji do Kubernetes. Biorąc pod uwagę plany klienta, wybór jest oczywisty.
ŁOŚ
Wcześniej nie gromadziliśmy ani nie przetwarzaliśmy logów. Niedociągnięcia są oczywiste dla wszystkich. Wybraliśmy ELK, ponieważ mieliśmy już doświadczenie z tym systemem. Przechowujemy tam jedynie logi aplikacji. Głównymi kryteriami wyboru było wyszukiwanie pełnotekstowe i jego szybkość.
Kliknijhouse
Początkowo wybór padł na InfluxDB. Zdaliśmy sobie sprawę z konieczności gromadzenia logów Nginx, statystyk z pg_stat_statements i przechowywania danych historycznych Prometheusa. Nie podobał nam się Influx, ponieważ okresowo zaczynał zużywać dużą ilość pamięci i zawieszał się. Ponadto chciałem pogrupować zapytania według adresu zdalnego, ale grupowanie w tym systemie DBMS odbywa się tylko według tagów. Tagi są drogie (pamięć), ich liczba jest warunkowo ograniczona.
Zaczęliśmy poszukiwania od nowa. Potrzebna była analityczna baza danych o minimalnym zużyciu zasobów, najlepiej z kompresją danych na dysku.
Clickhouse spełnia wszystkie te kryteria i nigdy nie żałowaliśmy naszego wyboru. Nie zapisujemy w nim żadnych nadzwyczajnych ilości danych (liczba wpisów wynosi zaledwie około pięciu tysięcy na minutę).
NewRelic
NewRelic jest z nami od dawna, ponieważ był to wybór klienta. Używamy go jako APM.
Zabbix
Używamy Zabbix wyłącznie do monitorowania czarnej skrzynki różnych API.
Definiowanie podejścia do monitorowania
Chcieliśmy rozłożyć zadanie i tym samym usystematyzować podejście do monitoringu.
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.
Dlaczego to podejście jest wygodne:
- wiemy, kto jest odpowiedzialny za pracę poszczególnych poziomów i na tej podstawie możemy wysyłać alerty;
- możemy wykorzystać tę strukturę przy tłumieniu alertów - dziwne byłoby wysyłanie alertu o niedostępności bazy danych, gdy maszyna wirtualna jako całość jest niedostępna.
Ponieważ naszym zadaniem jest identyfikacja naruszeń w działaniu systemu, musimy na każdym poziomie wyróżnić pewien zestaw metryk, na które warto zwrócić uwagę pisząc reguły alertowania. Następnie przejdźmy przez poziomy „VMS”, „System operacyjny” i „Usługi systemowe, stos oprogramowania”.
Wirtualne maszyny
Hosting przydziela nam procesor, dysk, pamięć i sieć. A z dwoma pierwszymi mieliśmy problemy. Zatem metryki:
Skradziony czas procesora - kupując maszynę wirtualną na Amazon (na przykład t2.micro), powinieneś zrozumieć, że nie przydzielany jest cały rdzeń procesora, a jedynie część jego czasu. A kiedy go wyczerpiesz, procesor zostanie ci odebrany.
Metryka ta pozwala śledzić takie momenty i podejmować decyzje. Na przykład, czy konieczne jest przyjęcie wyższej taryfy lub rozdzielenie przetwarzania zadań w tle i żądań API na różne serwery?
IOPS + czas oczekiwania procesora – z jakiegoś powodu wiele hostingów w chmurze grzeszy, nie zapewniając wystarczającej liczby IOPS. Co więcej, harmonogram z niskim IOPS nie jest dla nich argumentem. Dlatego warto kolekcjonować procesor iowait. Dzięki tej parze wykresów – przy niskim IOPS i wysokim oczekiwaniu na wejścia/wyjścia – możesz już porozmawiać z hostingiem i rozwiązać problem.
System operacyjny
Wskaźniki systemu operacyjnego:
- ilość dostępnej pamięci w %;
- aktywność związana ze swapem: vmstat swapin, swapout;
- liczba dostępnych i-węzłów i wolnego miejsca w systemie plików w %
- średnie obciążenie;
- liczba połączeń w stanie tw;
- Conntrack zapełnienie tabeli;
- Jakość sieci można monitorować za pomocą narzędzia ss, pakietu iproute2 - uzyskaj wskaźnik połączeń RTT z jego wyjścia i pogrupuj go według portu docelowego.
Również na poziomie systemu operacyjnego mamy taki byt jak procesy. Ważne jest, aby zidentyfikować w systemie zbiór procesów, które odgrywają ważną rolę w jego działaniu. Jeśli na przykład masz kilka puli pg, musisz zebrać informacje o każdej z nich.
Zestaw metryk wygląda następująco:
- PROCESOR;
- pamięć jest przede wszystkim rezydentna;
- IO – najlepiej w IOPS;
- FileFd - otwieraj i ograniczaj;
- znaczące awarie strony - w ten sposób możesz zrozumieć, jaki proces jest zamieniany.
Całość monitoringu wdrażamy w Dockerze, a do zbierania danych metryk używamy Advisora. Na innych maszynach używamy Process-eksportera.
Usługi systemowe, stos oprogramowania
Każda aplikacja ma swoją specyfikę i trudno wyróżnić konkretny zestaw wskaźników.
Uniwersalny zestaw to:
- stawka żądań;
- liczba błędów;
- czas oczekiwania;
- nasycenie.
Naszymi najbardziej uderzającymi przykładami monitorowania na tym poziomie są Nginx i PostgreSQL.
Najbardziej obciążoną usługą w naszym systemie jest baza danych. W przeszłości często mieliśmy problemy ze zrozumieniem, co robi baza danych.
Zaobserwowaliśmy duże obciążenie dysków, ale powolne logi tak naprawdę nic nie wykazały. Rozwiązaliśmy ten problem za pomocą pg_stat_statements, widoku zbierającego statystyki zapytań.
To wszystko, czego potrzebuje administrator.
Budujemy wykresy aktywności żądań odczytu i zapisu:
Wszystko jest proste i przejrzyste, każde żądanie ma swój własny kolor.
Równie uderzającym przykładem są dzienniki Nginx. Nic więc dziwnego, że niewiele osób je analizuje lub wymienia na liście must-have. Standardowy format nie zawiera zbyt wielu informacji i wymaga rozszerzenia.
Osobiście dodałem request_time, upstream_response_time, body_bytes_sent, request_length, request_id.Wykreślamy czas odpowiedzi i liczbę błędów:
Budujemy wykresy czasu reakcji i ilości błędów. Pamiętać? Czy mówiłem o zadaniach biznesowych? Aby szybko i bez błędów? Omówiliśmy już te kwestie na dwóch wykresach. I już można za ich pomocą dzwonić do dyżurujących administratorów.
Pozostaje jednak jeszcze jeden problem - zapewnienie szybkiego wyeliminowania przyczyn zdarzenia.
Rozwiązanie incydentu
Cały proces, od zidentyfikowania problemu do rozwiązania, można podzielić na kilka etapów:
- identyfikacja problemu;
- powiadomienie administratora dyżurnego;
- reakcja na incydent;
- eliminacja przyczyn.
Ważne jest, abyśmy zrobili to jak najszybciej. A jeśli na etapach identyfikacji problemu i wysłania zgłoszenia nie uda nam się zyskać zbyt wiele czasu – i tak poświęcę na nie dwie minuty, to kolejne to po prostu niezaorane pole do usprawnień.
Wyobraźmy sobie, że zadzwonił telefon oficera dyżurnego. Co zrobi? Poszukaj odpowiedzi na pytania - co się zepsuło, gdzie się zepsuło, jak zareagować? Oto jak odpowiadamy na te pytania:
Po prostu umieszczamy wszystkie te informacje w tekście powiadomienia, podając link do strony wiki opisującej, jak zareagować na ten problem, jak go rozwiązać i eskalować.
O warstwie aplikacji i logice biznesowej jeszcze nie wspomniałem. Niestety nasze aplikacje nie obsługują jeszcze gromadzenia metryk. Jedynym źródłem informacji z tych poziomów są logi.
Kilka punktów.
Najpierw napisz uporządkowane logi. Nie ma potrzeby umieszczania kontekstu w tekście wiadomości. Utrudnia to ich grupowanie i analizę. Logstash zajmuje dużo czasu, aby to wszystko znormalizować.
Po drugie, prawidłowo używaj poziomów ważności. Każdy język ma swój własny standard. Osobiście wyróżniam cztery poziomy:
- żaden błąd;
- błąd po stronie klienta;
- błąd jest po naszej stronie, nie tracimy pieniędzy, nie ponosimy ryzyka;
- Błąd jest po naszej stronie, tracimy pieniądze.
Podsumuję. Trzeba spróbować zbudować monitoring w oparciu o logikę biznesową. Staraj się monitorować samą aplikację i operuj takimi metrykami jak liczba sprzedaży, liczba rejestracji nowych użytkowników, liczba aktualnie aktywnych użytkowników i tak dalej.
Jeśli cały Twój biznes to jeden przycisk w przeglądarce, musisz monitorować, czy klika i działa poprawnie. Cała reszta nie ma znaczenia.
Jeśli tego nie masz, możesz spróbować nadrobić zaległości w dziennikach aplikacji, dziennikach Nginx i tak dalej, tak jak my. Powinieneś być jak najbliżej aplikacji.
Metryki systemu operacyjnego są oczywiście ważne, ale biznes się nimi nie interesuje, nie płacimy za nie.
Źródło: www.habr.com