🥇Monitoring martwy? — Niech żyje monitoring

Nasza firma od 2008 roku zajmuje się głównie zarządzaniem infrastrukturą oraz całodobowym wsparciem technicznym projektów internetowych: mamy ponad 400 klientów, co stanowi około 15% rynku e-commerce w Rosji. W związku z tym, wsparcie obejmuje bardzo zróżnicowaną architekturę. Jeśli coś się psuje, musimy to naprawić w ciągu 15 minut. Ale aby zrozumieć, że wystąpiła awaria, należy monitorować projekt i reagować na incydenty. A jak to zrobić?

Uważam, że w organizacji właściwego systemu monitorowania pojawia się problem. Gdyby nie było problemu, moje wystąpienie składałoby się z jednego punktu: „Proszę zainstalować Prometheus + Grafana i wtyczki 1, 2, 3”. Niestety, teraz tak to nie działa. Głównym problemem jest to, że wszyscy wciąż wierzą w coś, co istniało w 2008 roku, jeśli chodzi o komponenty oprogramowania.

Jeśli chodzi o organizację systemu monitorowania, ośmielę się powiedzieć, że… projektów z sensownym monitorowaniem nie ma. Sytuacja jest na tyle poważna, że jeśli coś upadnie, istnieje ryzyko, że pozostanie niezauważone — wszyscy są przekonani, że „wszystko jest monitorowane”.
Możliwe, że wszystko jest monitorowane. Ale jak?

Wszyscy spotkaliśmy się z historią podobną do poniższej: działa jakiś devops, jakiś admin, do nich przychodzi zespół deweloperów i mówi — „wypuściliśmy wersję, teraz zamonituj”. Co zamonituj? Jak to działa?

Dobrze. Monitorujemy po staremu. Ale to już się zmienia, i okazuje się, że monitorowałeś usługę A, która stała się usługą B, która współpracuje z usługą C. Ale zespół deweloperów mówi ci: „Zainstaluj oprogramowanie, ono powinno wszystko zamonitować!”

Więc co się zmieniło? — Wszystko się zmieniło!

Rok 2008. Wszystko jest w porządku

Mamy parę deweloperów, jeden serwer, jeden serwer bazy danych. Stąd wszystko się zaczyna. Mamy jakieś dane, instalujemy Zabbixa, Nagios, Cacti. Następnie wystawiamy zrozumiałe alerty na CPU, na działanie dysków, na miejsce na dyskach. Robimy też kilka ręcznych kontroli, że strona odpowiada, że zamówienia trafiają do bazy. I to wszystko – jesteśmy mniej więcej chronieni.

Porównując zakres pracy, który wtedy wykonował admin w celu zapewnienia monitoringu, to w 98% była ona automatyczna: osoba zajmująca się monitoringiem musi zrozumieć, jak zainstalować Zabbix, jak go skonfigurować i ustawić alerty. A 2% — to zewnętrzne kontrole: czy strona odpowiada i wysyła zapytania do bazy, czy nowe zamówienia napływają.

Rok 2010. Obciążenie rośnie.

Zaczynamy skalować weby, dodajemy silnik wyszukiwania. Chcemy mieć pewność, że katalog produktów zawiera wszystkie towary. I że wyszukiwanie produktów działa. Że baza działa, że zamówienia są realizowane, że strona odpowiada zewnętrznie i odpowiada z dwóch serwerów i nie wyrzuca użytkownika ze strony, podczas gdy przechodzi na inny serwer, itd. Liczba bytów rośnie.

Przy czym byt związany z infrastrukturą pozostaje wciąż największy w głowie menedżera. Nadal w głowie tkwi pomysł, że osoba zajmująca się monitoringiem to osoba, która postawi Zabbix i będzie w stanie go skonfigurować.

Jednak pojawiają się nowe zadania związane z przeprowadzaniem zewnętrznych kontroli, z tworzeniem zestawu skryptów zapytań dla indeksatora wyszukiwania, zestawu skryptów do sprawdzania, że wyszukiwanie zmienia się w trakcie indeksacji, zestawu skryptów, które sprawdzają, że do usługi dostawy przekazywane są towary, itd.

Zauważcie: napisałem 3 razy „zestaw skryptów”. To znaczy, że odpowiedzialny za monitoring to już nie tylko ktoś, kto po prostu instaluje Zabbix. To osoba, która zaczyna kodować. Ale w głowach zespołu na razie nic się nie zmienia.

W międzyczasie jednak świat się zmienia, stając się coraz bardziej skomplikowany. Pojawiają się warstwy wirtualizacji, kilka nowych systemów. Zaczynają współdziałać ze sobą. Kto powiedział „pachnie mikroserwisami”? Ale każdy serwis wciąż wygląda jak osobna strona. Możemy się do niego odwołać i zrozumieć, że wydaje potrzebne informacje i działa samodzielnie. A jeśli jesteś adminem, który nieprzerwanie zajmuje się projektem rozwijającym się przez 5-7-10 lat, wiedza ta się kumuluje: pojawia się nowy poziom — zdajesz go sobie sprawę, pojawia się kolejny poziom — zdajesz go sobie sprawę…

Ale rzadko kto towarzyszy projektowi przez 10 lat.

Podsumowanie monitorowania

Załóżmy, że dołączyłeś do nowego startupu, który od razu zatrudnił 20 programistów, napisał 15 mikroserwisów, a Ty jesteś administratorem, któremu mówią: „Zbuduj CI/CD. Proszęee.” Zbudowałeś CI/CD i nagle słyszysz: „Z trudem pracujemy z produkcją w 'kube’, nie rozumiejąc, jak aplikacja będzie w nim działać. Zrób nam piaskownicę w tym samym 'kube’.”
Tworzysz piaskownicę w tym kube. Od razu mówią: „Chcemy, żeby baza danych stage była aktualizowana codziennie z produkcji, żeby móc zrozumieć, jak to działa na bazie danych, ale jednocześnie nie psuć bazy danych produkcyjnej.”

Żyjesz w tym wszystkim. Zostały 2 tygodnie do wydania, a oni mówią: „Teraz musimy to wszystko monitorować…” Tzn. monitorować infrastrukturę klastra, monitorować architekturę mikroserwisów, monitorować pracę z zewnętrznymi usługami…

A koledzy wyciągają z głowy znaną schemat i mówią: „To wszystko jest jasne! Zainstaluj program, który to wszystko zamonituruje.” Tak, tak: Prometheus + Grafana + wtyczki.
I dodają przy tym: „Masz jakieś dwie tygodnie, zrób tak, żeby wszystko było niezawodne.”

W wielu projektach, które widzimy, na monitoring przeznaczają jedną osobę. Wyobraź sobie, że chcemy zatrudnić kogoś na 2 tygodnie, kto zajmie się monitoringiem, i przygotowujemy dla niego CV. Jakie umiejętności powinien posiadać ten człowiek, biorąc pod uwagę wszystko, co wcześniej powiedzieliśmy?

Powinien rozumieć monitoring i specyfikę działania infrastruktury sprzętowej.
Powinien rozumieć specyfikę monitorowania Kubernetes (wszyscy chcą w 'kube’, ponieważ można abstrahować od wszystkiego, schować się, a administrator zajmie się resztą) – samego siebie, jego infrastruktury oraz rozumieć, jak monitorować aplikacje wewnątrz.
Powinien wiedzieć, że serwisy komunikują się ze sobą w szczególnych sposób i znać specyfikę interakcji serwisów między sobą. Całkiem możliwe jest, że zobaczysz projekt, w którym część serwisów komunikuje się synchronicznie, ponieważ nie ma innego sposobu. Na przykład backend idzie przez REST, przez gRPC do serwisu katalogu, pobiera listę produktów i zwraca ją z powrotem. Tutaj nie można czekać. A z innymi serwisami działa asynchronicznie. Przekazać zamówienie do firmy dostawczej, wysłać wiadomość itd.
Prawdopodobnie już się zgubiłeś w tym wszystkim? A administrator, który musi to monitorować, jest jeszcze bardziej zagubiony.
Musisz umieć planować i robić to dobrze – ponieważ pracy przybywa.
W związku z tym powinien opracować strategię dla stworzonej usługi, aby zrozumieć, jak konkretnie ją monitorować. Potrzebuje wiedzy na temat architektury projektu i jego rozwoju, a także technologii używanych w jego tworzeniu.

Przypomnijmy sobie całkowicie normalny przypadek: część usług na PHP, część na Go, część na JS. Jakoś ze sobą współpracują. Stąd wzięło się pojęcie "mikroserwis": systemów stało się tak wiele, że programiści nie są w stanie zrozumieć projektu jako całości. Jedna część zespołu pisze usługi na JS, które działają samodzielnie i nie wiedzą, jak działa reszta systemu. Druga część pisze usługi na Pythonie i nie wnika w to, jak działają inne usługi, są izolowane w swojej dziedzinie. Trzecia pisze usługi na PHP lub czymkolwiek innym.
Wszyscy ci 20 ludzie są podzieleni na 15 usług, a jest tylko jeden administrator, który musi to wszystko zrozumieć. Stop! Właśnie podzieliliśmy system na 15 mikroserwisów, ponieważ 20 osób nie może zrozumieć całego systemu.

A jednak trzeba to jakoś monitorować…

Co z tego wynikło? W rezultacie jest jedna osoba, która rozumie wszystko, co nie może zrozumieć cały zespół programistów, a jednocześnie musi znać i umieć wszystko, co wyżej wskazano – infrastrukturę sprzętową, infrastrukturę Kubernetes itd.

Co tu powiedzieć… Houston, mamy problem.

Monitorowanie nowoczesnego projektu programistycznego to samodzielny projekt programistyczny.

Z fałszywego przekonania, że monitorowanie to oprogramowanie, rodzi się wiara w cuda. A cudów, niestety, nie ma. Nie można postawić Zabbixa i czekać, że wszystko zadziała. Nie ma sensu stawiać Grafany i mieć nadzieję, że wszystko będzie dobrze. Większość czasu spędzisz na organizacji sprawdzania działania usług i ich wzajemnych interakcji, a także sprawdzania, jak działają systemy zewnętrzne. W rzeczywistości 90% czasu spędzisz nie na pisaniu skryptów, lecz na rozwoju oprogramowania. I powinna się tym zajmować drużyna, która rozumie działanie projektu.
Jeśli w tej sytuacji jedną osobę rzuci się na monitorowanie, to wydarzy się katastrofa. Co dzieje się powszechnie.

Na przykład istnieje kilka usług, które komunikują się ze sobą za pośrednictwem Kafka. Przyszło zamówienie, wysłaliśmy wiadomość o zamówieniu do Kafka. Jest usługa, która nasłuchuje informacji o zamówieniu i przeprowadza wysyłkę towaru. Jest usługa, która nasłuchuje informacji o zamówieniu i wysyła e-mail do użytkownika. A potem pojawia się jeszcze wiele usług i zaczynamy się gubić.

A jeśli oddacie to administracji i programistom na etapie, kiedy do premiery zostało niewiele czasu, człowiek będzie musiał zrozumieć cały ten protokół. To znaczy, projekt tego rzędu zajmuje znaczną ilość czasu, i w rozwoju systemu to powinno być uwzględnione.
Jednak bardzo często, zwłaszcza w startupach, widzimy, jak monitorowanie odkłada się na później. 'Teraz zrobimy Proof of Concept, z nim uruchomimy, niech pada – jesteśmy gotowi na poświęcenia. A potem wszystko zamonitujemy.' Kiedy (lub jeśli) projekt zaczyna przynosić zyski, biznes chce wprowadzać jeszcze więcej funkcji — bo zaczęło działać, więc trzeba to rozwijać! A wy jesteście w punkcie, gdzie najpierw trzeba zamonitować wszystko, co się wydarzyło wcześniej, co zajmuje nie 1% czasu, a znacznie więcej. I zresztą do monitorowania będą potrzebni programiści, a ich łatwiej puścić na nowe funkcje. W efekcie piszą nowe funkcje, wszystko się rozwija i jesteście w wiecznym deadlocku.

Jak więc zamonitować projekt, zaczynając od początku, i co zrobić, jeśli dostaniecie projekt, który trzeba zamonitować, a nie wiecie, od czego zacząć?

Przede wszystkim trzeba planować.

Liryczne dygresja: bardzo często zaczyna się od monitorowania infrastruktury. Na przykład mamy Kubernetes. Zacznijmy od tego, że zainstalujemy Prometheusa z Grafaną, zainstalujemy wtyczki do monitorowania 'kube'. Nie tylko programiści, ale i administratorzy mają przykrości: 'Zainstalujemy tę wtyczkę, a wtyczka prawdopodobnie wie, jak to zrobić'. Ludzie lubią zaczynać od prostych i zrozumiałych rzeczy, a nie od ważnych działań. A monitorowanie infrastruktury — to po prostu.

Na początku zdecyduj, co i jak chcesz monitorować, a potem dobierz odpowiednie narzędzie, ponieważ inni ludzie nie mogą myśleć za ciebie. I czy powinni? Inni ludzie myśleli o sobie, o uniwersalnym systemie — lub w ogóle nie myśleli, kiedy pisali tę wtyczkę. A to, że ta wtyczka ma 5 tysięcy użytkowników, nie oznacza, że przynosi jakieś korzyści. Może staniesz się 5001. użytkownikiem tylko dlatego, że wcześniej było 5000 osób.

Jeśli zacząłeś monitorować infrastrukturę, a backend twojej aplikacji przestał odpowiadać, wszyscy użytkownicy stracą połączenie z aplikacją mobilną. Pojawi się błąd. Podejdą do ciebie i powiedzą „Aplikacja nie działa, co wy tutaj robicie?” — „Monitorujemy”. — „Jak monitorujecie, skoro nie widzicie, że aplikacja nie działa?!”,

Uważam, że monitorowanie należy rozpocząć od punktu wejścia użytkownika. Jeśli użytkownik nie widzi, że aplikacja działa — wszystko, to jest porażka. System monitorowania powinien najpierw ostrzec o tym.
Tylko potem możemy monitorować infrastrukturę. Możemy zrobić to równolegle. Z infrastrukturą jest łatwiej — tutaj w końcu możemy po prostu zainstalować Zabbixa.
A teraz trzeba iść w głąb aplikacji, aby zrozumieć, gdzie coś nie działa.

Moja główna myśl to, że monitorowanie powinno odbywać się równolegle z procesem rozwoju. Jeśli oderwiesz zespół monitorujący do innych zadań (tworzenie CI/CD, piaskownice, reorganizacja infrastruktury), monitorowanie zacznie zostawać w tyle, a może z czasem już nigdy nie dogonisz rozwoju (lub prędzej czy później będziesz musiał go wstrzymać).

Wszystko na poziomach

Oto jak widzę organizację systemu monitorowania.

1) Poziom aplikacji:

monitorowanie logiki biznesowej aplikacji;
monitorowanie metryk zdrowia usług;
monitorowanie integracyjne.

2) Poziom infrastruktury:

monitorowanie poziomu orkiestracji;
monitorowanie oprogramowania systemowego;
monitorowanie poziomu „sprzętu”.

3) Ponownie poziom aplikacji — ale już jako produkt inżynieryjny:

zbieranie i obserwacja logów aplikacji;
APM;
śledzenie.

4) Alerting:

organizacja systemu powiadamiania;
organizacja systemu dyżurów;
organizacja „bazy wiedzy” oraz workflow przetwarzania incydentów.

Ważne: dochodzimy do alerting nie po, a od razu! Nie należy uruchamiać monitorowania i „jakoś później” wymyślać, do kogo będą przychodzić alerty. W końcu to, o co chodzi w monitorowaniu: zrozumieć, gdzie w systemie coś nie działa prawidłowo i powiadomić o tym odpowiednie osoby. Jeśli zostawisz to na koniec, odpowiednie osoby dowiedzą się, że coś idzie nie tak, tylko po telefonie „u nas nic nie działa”.

Poziom aplikacji — monitorowanie logiki biznesowej

Tutaj chodzi o sprawdzenie samego faktu, że aplikacja działa dla użytkownika.

Ten poziom powinien być realizowany na etapie rozwoju. Na przykład, mamy hipotetycznego Prometheusa: łączy się z serwerem, który przeprowadza kontrole, wywołuje endpoint, a endpoint sprawdza API.

Gdy często proszą o monitorowanie strony głównej, aby upewnić się, że strona działa, programiści dostarczają endpoint, który można wywoływać, gdy trzeba upewnić się, że API działa. A programiści jednocześnie piszą /api/test/helloworld.
Jedyny sposób, aby upewnić się, że wszystko działa? — Nie!

Tworzenie takich kontroli to zasadniczo zadanie dla programistów. Testy jednostkowe powinny pisać programiści, którzy piszą kod. Bo jeśli powiesz administratorowi „Człowieku, oto lista protokołów API wszystkich 25 funkcji, proszę, monitoruj wszystko!” — nic z tego nie wyjdzie.
Jeśli zrobisz print „hello world”, nikt nigdy nie dowie się, że API powinno i faktycznie działa. Każda zmiana API powinna pociągać za sobą zmianę kontroli.
Jeśli masz już taki problem – wstrzymaj funkcje i przydziel programistów, którzy napiszą te kontrole, albo pogódź się z stratami, pogódź się z tym, że nic nie jest monitorowane i będzie zawodzić.

Wskazówki techniczne:

Obowiązkowo zorganizuj zewnętrzny serwer do przeprowadzania kontroli — musisz być pewien, że twój projekt jest dostępny dla zewnętrznego świata.
Zorganizuj kontrole na całym protokole API, a nie tylko na pojedynczych endpointach.
Utwórz endpoint Prometheusa z wynikami kontroli.

Poziom aplikacji — monitorowanie metryk zdrowotnych

Teraz chodzi o zewnętrzne metryki zdrowotne usług.

Postanowiliśmy, że wszystkie „endpointy” aplikacji będą monitorowane za pomocą zewnętrznych sprawdzeń, które wywołujemy z zewnętrznego systemu monitorowania. Ale to właśnie te „endpointy”, które „widzi” użytkownik. Chcemy mieć pewność, że nasze usługi działają. W tym przypadku sytuacja jest lepsza: w K8s są health-checki, które przynajmniej upewniają się, że „kube” sprawdza, czy usługa działa. Jednak połowa checków, które widziałem, to ten sam print „hello world”. Tzn. wywołuje je raz po wdrożeniu, on odpowiada, że wszystko jest dobrze — i to wszystko. A w przypadku usługi, jeśli zwraca swój API przez REST, istnieje ogromna liczba punktów wejścia do tego API, które również trzeba monitorować, ponieważ chcemy wiedzieć, że działa. I monitorujemy go już wewnątrz.

Jak to poprawnie zrealizować technicznie: każda usługa wystawia endpoint dotyczący swojej aktualnej sprawności, a w wykresach Grafana (lub innej aplikacji) widzimy status wszystkich usług.

Każda zmiana w API powinna wiązać się ze zmianą w sprawdzaniach.
Tworząc nową usługę, od razu dodawaj health-metryki.
Administrator może podejść do programistów i poprosić „dodajcie mi kilka funkcji, żebym wszystko rozumiał i mógł dodać informacje o tym do swojego systemu monitorowania”. Ale programiści zwykle odpowiadają: „Nie będziemy nic dodawać na dwa tygodnie przed wydaniem”.
Niech menedżerowie rozwoju wiedzą, że będą takie straty, niech również władze menedżerów rozwoju o tym wiedzą. Ponieważ, gdy wszystko padnie, ktoś i tak zadzwoni i zażąda monitorowania „ciągle padającej usługi”.
Zresztą, przydzielcie programistów do pisania wtyczek do Grafana — to będzie dobra pomoc dla administratorów.

Poziom aplikacji — Monitorowanie integracyjne.

Monitorowanie integracyjne koncentruje się na monitorowaniu komunikacji między krytycznymi systemami dla biznesu.

Na przykład, istnieje 15 usług, które komunikują się ze sobą. To już nie są oddzielne strony. Tzn. nie możemy po prostu wywołać usługi, uzyskać /helloworld i zrozumieć, że usługa działa. Ponieważ serwis do składania zamówień musi przesłać informacje o zamówieniu do magistrali — z magistrali usługa zarządzająca magazynem musi otrzymać tę wiadomość i dalej z nią pracować. A usługa wysyłania e-maili musi w jakiś sposób dalej to przetwarzać, itd.

W związku z tym nie możemy zrozumieć, próbując skontaktować się z każdym pojedynczym serwisem, jak to wszystko działa. Ponieważ mamy pewną magistralę, przez którą wszystko się komunikacje i współdziała.
Dlatego ten etap powinien oznaczać etap testowania usług pod kątem interakcji z innymi usługami. Nie można, monitorując broker wiadomości, zorganizować monitorowania komunikacji. Jeśli jest usługa, która wydaje dane, oraz usługa, która je przyjmuje, podczas monitorowania brokera zobaczymy tylko dane, które poruszają się z jednej strony na drugą. Nawet jeśli uda nam się jakoś monitorować interakcję tych danych wewnątrz — że jakiś producent wysyła dane, a ktoś je czyta, a ten strumień nadal napotyka w Kafka — to i tak nie dostarczy nam informacji, jeśli jedna usługa wysłała wiadomość w jednej wersji, a inna usługa nie oczekiwała tej wersji i ją przeoczyła. Nie dowiemy się o tym, ponieważ usługi powiedzą nam, że wszystko działa.

Jak zalecam to robić:

Dla synchronizowanej komunikacji: endpoint wykonuje zapytania do powiązanych usług. Tzn. bierzemy ten endpoint, uruchamiamy skrypt wewnątrz usługi, który przechodzi przez wszystkie punkty i mówi: „mogę tu dzwonić, a tam dzwonić, mogę tam dzwonić…”
Dla asynchronicznej komunikacji: wiadomości przychodzące — endpoint sprawdza magistralę pod kątem obecności testowych wiadomości i wydaje status przetwarzania.
Dla asynchronicznej komunikacji: wiadomości wychodzące — endpoint wysyła testowe wiadomości na magistralę.

Jak to zwykle bywa: mamy usługę, która przesyła dane do magistrali. Przychodzimy do tej usługi i prosimy o informacje na temat jej zdrowia integracyjnego. Jeśli usługa ma przesłać jakąś wiadomość dalej (WebApp), to przesyła tę testową wiadomość. A jeśli sięgamy po usługę po stronie OrderProcessing, to najpierw publikuje to, co może przesłać samodzielnie, a jeśli są jakieś zależne rzeczy — to odczytuje z magistrali zestaw testowych wiadomości, rozumie, że może je przetworzyć, informuje o tym i, jeśli to konieczne, publikuje je dalej, a o tym mówi — wszystko w porządku, żyję.

Bardzo często słyszymy pytanie „jak możemy to testować na prawdziwych danych?” Na przykład mówimy o tej samej usłudze zamówień. Zamówienie wysyła wiadomości do magazynu, gdzie produkty są odejmowane: nie możemy tego testować na prawdziwych danych, ponieważ „moje produkty będą odejmowane!” Rozwiązanie: na etapie początkowym zaplanujcie całe to testowanie. Macie unit testy, które wykonują mocki. Więc zróbcie to na głębszym poziomie, gdzie będziecie mieli kanał komunikacji, który nie zaszkodzi działalności biznesowej.

Poziom infrastruktury

Monitorowanie infrastruktury – to, co od dawna uważane jest za sam monitoring.

Monitorowanie infrastruktury można oraz należy uruchomić jako osobny proces.
Nie należy zaczynać od monitorowania infrastruktury w działającym projekcie, nawet jeśli bardzo się chce. To problem dla wszystkich DevOpsów. „Najpierw zamonituję klaster, zamonituję infrastrukturę” – tzn. najpierw zamonituję to, co leży na dole, a do aplikacji nie zajrzy. Ponieważ aplikacja jest niejasną sprawą dla DevOpsa. Otrzymał to i nie rozumie, jak to działa. Ale infrastrukturę rozumie i zaczyna od niej. Ale nie – zawsze na początku należy monitorować aplikację.
Nie przesadzajcie z liczbą powiadomień. Biorąc pod uwagę złożoność nowoczesnych systemów, alerty przychodzą nieustannie, a z tą kupą alertów trzeba jakoś żyć. A człowiek on-call, patrząc na setkę kolejnych alertów, postanowi „nie chcę o tym myśleć”. Alerty powinny informować tylko o krytycznych sprawach.

Poziom aplikacji jako jednostki biznesowej

Kluczowe punkty:

ELK. To standard przemysłowy. Jeśli z jakiegoś powodu nie agregujecie logów, pilnie zacznijcie to robić.
APM. Zewnętrzne APM jako sposób na szybkie zamknięcie monitoringu aplikacji (NewRelic, BlackFire, Datadog). Możecie tymczasowo zainstalować tę rzecz, aby jakoś zrozumieć, co się u was dzieje.
Śledzenie. W dziesiątkach mikroserwisów musicie śledzić wszystko, ponieważ zapytanie nie żyje już samo w sobie. Bardzo trudno jest później to dodać, dlatego lepiej od razu zaplanować śledzenie w rozwoju – to zadanie i narzędzie dla programistów. Jeśli jeszcze nie wdrożyliście – wdrażajcie! Zobacz Jaeger/Zipkin.

Alertowanie

Organizacja systemu powiadomień: w warunkach monitorowania wielu rzeczy musi istnieć jednolity system wysyłania powiadomień. Można to zrobić w Grafanie. Na Zachodzie wszyscy korzystają z PagerDuty. Powiadomienia powinny być zrozumiałe (na przykład, skąd pochodzą…). I dobrze by było kontrolować, czy powiadomienia w ogóle docierają.
Organizacja systemu dyżurów: alerty nie powinny docierać do wszystkich (inaczej wszyscy będą reagować naraz, lub nikt nie zareaguje). Osoby na dyżurze powinny być też programistami: należy jednoznacznie określić obszary odpowiedzialności, przygotować jasną instrukcję, w której określi się, do kogo konkretnie dzwonić w poniedziałki i środy, a do kogo w wtorki i piątki (w przeciwnym razie nikt nie zadzwoni nawet w sytuacji wielkiego zagrożenia — będą się obawiać obudzić lub zakłócić spokój: ludzie w ogóle nie lubią dzwonić i budzić innych, zwłaszcza w nocy). I wyjaśnij, że proszenie o pomoc nie oznacza niekompetencji („proszę o pomoc — więc jestem złym pracownikiem”), zachęcaj do prośby o pomoc.
Organizacja „bazy wiedzy” i workflow przetwarzania incydentów: dla każdego poważnego incydentu powinna być zaplanowana analiza powyższa, jako tymczasowe rozwiązanie należy zarejestrować działania, które rozwiązują incydent. I wprowadź praktykę, że powtarzające się alerty to grzech; należy je naprawić w kodzie lub pracach infrastrukturalnych.

Stos technologiczny

Załóżmy, że nasza technologia wygląda następująco:

zbieranie danych — Prometheus + Grafana;
analiza logów — ELK;
dla APM lub śledzenia — Jaeger (Zipkin).

Wybór opcji nie jest krytyczny. Ponieważ, jeśli na początku zrozumiesz, jak monitorować system i stworzysz plan, to następnie zaczynasz dobierać narzędzia do swoich wymagań. Ważne jest to, co wybrałeś do monitorowania na początku. Ponieważ być może narzędzie, które wybrałeś na początku — w ogóle nie odpowiada twoim wymaganiom.

Kilka technicznych kwestii, które ostatnio widzę wszędzie:

Prometheus jest wpychany do wewnątrz Kubernetes — kto to wymyślił?! Co zrobisz, jeśli twój klaster upadnie? Jeśli masz złożony klaster wewnątrz, powinna działać pewna system monitoringu wewnątrz klastra, a inny — na zewnątrz, który będzie zbierał dane z wnętrza klastra.

Wewnątrz klastra zbieramy logi i wszystko inne. Systemy monitoringu powinny być na zewnątrz. Bardzo często w klastrze, gdzie znajduje się Prometheus, który został umieszczony wewnątrz, są także systemy, które wykonują zewnętrzne kontrole działania strony. A co jeśli połączenia ze światem zewnętrznym znikną i aplikacja nie będzie działać? Wewnątrz wszystko jest w porządku, ale użytkownikom to na nic się nie zdaje.

Wnioski

Rozwój monitoringu to nie tylko instalacja narzędzi, ale tworzenie produktu programowego. 98% współczesnego monitoringu to kodowanie. Kodowanie w usługach, kodowanie zewnętrznych kontrol, kontrola zewnętrznych usług i całej masy innych rzeczy.
Nie oszczędzajcie czasu programistów na monitoring: może to zająć do 30% ich pracy, ale warto.
DevOps, nie martwcie się, że nie potraficie czegoś monitorować, ponieważ niektóre rzeczy wymagają zupełnie innego myślenia. Nie byliście programistami, a praca w monitoringu to właśnie ich zadanie.
Jeśli projekt już działa i nie jest monitorowany (a ty jesteś menedżerem) — przydziel zasoby na monitoring.
Jeśli produkt jest już w produkcji, a ty jesteś devopsem, któremu powiedziano, żeby ‘ustawić monitoring’ — postaraj się wyjaśnić kierownictwu to, o czym mówiłem przez cały czas.

To rozszerzona wersja wykładu na konferencji Saint Highload++.

Jeśli interesują cię moje pomysły i przemyślenia na temat IT i pokrewnych tematów, to tutaj można przeczytać kanał 🙂

Źródło: habr.com