Czy monitoring umarł? — Długie monitorowanie na żywo

Od 2008 roku nasza firma zajmuje się przede wszystkim zarządzaniem infrastrukturą i całodobowym wsparciem technicznym projektów webowych: mamy ponad 400 klientów, co stanowi około 15% rosyjskiego e-commerce. W związku z tym obsługiwana jest bardzo zróżnicowana architektura. Jeśli coś spadnie, jesteśmy zobowiązani naprawić to w ciągu 15 minut. Ale aby zrozumieć, że zdarzył się wypadek, musisz monitorować projekt i reagować na incydenty. Jak to zrobić?

Uważam, że jest problem w zorganizowaniu odpowiedniego systemu monitoringu. Gdyby nie było problemów, to moje wystąpienie składałoby się z jednej tezy: „Proszę zainstalować Prometheus + Grafana i wtyczki 1, 2, 3”. Niestety, to już tak nie działa. Głównym problemem jest to, że wszyscy nadal wierzą w coś, co istniało w 2008 roku, jeśli chodzi o komponenty oprogramowania.

Jeśli chodzi o organizację systemu monitoringu, zaryzykuję stwierdzenie, że... nie ma projektów z kompetentnym monitoringiem. A sytuacja jest na tyle zła, że ​​jeśli coś spadnie, istnieje ryzyko, że pozostanie niezauważone – w końcu wszyscy są pewni, że „wszystko jest monitorowane”.
Być może wszystko jest monitorowane. Ale jak?

Każdy z nas spotkał się z taką historią: pewien devops, pewien administrator pracuje, przychodzi do nich zespół programistów i mówi – „zostaliśmy zwolnieni, teraz monitorujemy”. Monitorować co? Jak to działa?

OK. Monitorujemy w staromodny sposób. I to już się zmienia i okazuje się, że monitorowałeś usługę A, która stała się usługą B, która wchodzi w interakcję z usługą C. Ale zespół programistów mówi ci: „Zainstaluj oprogramowanie, powinno wszystko monitorować!”

Co się zatem zmieniło? - Wszystko się zmieniło!

2008 Wszystko w porządku

Jest kilku programistów, jeden serwer, jeden serwer bazy danych. To wszystko idzie stąd. Mamy trochę informacji, instalujemy zabbix, Nagios, kaktusy. Następnie ustawiamy wyraźne alerty dotyczące procesora, działania dysku i miejsca na dysku. Przeprowadzamy również kilka ręcznych kontroli, aby upewnić się, że witryna odpowiada i zamówienia docierają do bazy danych. I tyle – jesteśmy mniej lub bardziej chronieni.

Jeśli porównamy ilość pracy, którą administrator wykonał wówczas, aby zapewnić monitorowanie, to w 98% wykonano ją automatycznie: osoba monitorująca musi wiedzieć, jak zainstalować Zabbix, jak go skonfigurować i skonfigurować alerty. I 2% - na kontrole zewnętrzne: czy strona odpowiada i wysyła żądanie do bazy danych, czy nadeszły nowe zamówienia.

2010 Obciążenie rośnie

Zaczynamy skalować sieć, dodając wyszukiwarkę. Chcemy mieć pewność, że katalog produktów zawiera wszystkie produkty. I to wyszukiwanie produktów działa. Czy baza danych działa, czy składane są zamówienia, czy witryna odpowiada zewnętrznie i z dwóch serwerów, a użytkownik nie zostaje wyrzucony z witryny podczas ponownego łączenia się z innym serwerem itp. Jest więcej podmiotów.

Co więcej, podmiot związany z infrastrukturą nadal pozostaje największym w głowie zarządcy. Wciąż chodzi mi po głowie pomysł, że osoba monitorująca to osoba, która zainstaluje Zabbix i będzie mogła go skonfigurować.

Ale jednocześnie pojawiają się prace nad przeprowadzeniem kontroli zewnętrznych, nad stworzeniem zestawu skryptów zapytań indeksatora wyszukiwania, zestawu skryptów sprawdzających, czy wyszukiwanie zmienia się w trakcie indeksowania, zestawu skryptów sprawdzających, czy towar jest przekazywany do usługa dostawy itp. i tak dalej.

Uwaga: „zestaw skryptów” napisałem 3 razy. Oznacza to, że osoba odpowiedzialna za monitorowanie nie jest już tą, która po prostu instaluje Zabbix. To osoba, która zaczyna kodować. Jednak w świadomości zespołu nic się jeszcze nie zmieniło.

Ale świat się zmienia, staje się coraz bardziej złożony. Dodano warstwę wirtualizacji i kilka nowych systemów. Zaczynają ze sobą współdziałać. Kto powiedział, że „pachnie mikrousługami?” Ale każda usługa nadal wygląda jak osobna witryna internetowa. Możemy się do niego zwrócić i zrozumieć, że dostarcza niezbędnych informacji i działa samodzielnie. A jeśli jesteś administratorem stale zaangażowanym w projekt, który rozwija się od 5-7-10 lat, to ta wiedza się kumuluje: pojawia się nowy poziom – zdałeś sobie z tego sprawę, pojawia się kolejny poziom – zdałeś sobie z tego sprawę…

Rzadko jednak ktoś towarzyszy projektowi przez 10 lat.

Życiorys Monitoringmana

Załóżmy, że przyszedłeś do nowego startupu, który natychmiast zatrudnił 20 programistów, napisał 15 mikrousług i jesteś administratorem, któremu powiedziano: „Zbuduj CI/CD. Proszę." Zbudowałeś CI/CD i nagle słyszysz: „Trudno nam pracować z produkcją w „kostce”, nie rozumiejąc, jak aplikacja będzie w niej działać. Zrób nam piaskownicę w tej samej „sześcianie”.
W tej kostce tworzysz piaskownicę. Od razu mówią: „Chcemy bazę danych scenicznych, która będzie codziennie aktualizowana od momentu produkcji, abyśmy zrozumieli, że działa na bazie danych, ale jednocześnie nie psują bazy produkcyjnej”.

Żyjesz w tym wszystkim. Do premiery pozostały 2 tygodnie, mówią: „Teraz poobserwujmy to wszystko…” To znaczy. monitoruj infrastrukturę klastra, monitoruj architekturę mikroserwisów, monitoruj pracę z usługami zewnętrznymi...

A moi koledzy wybijają z głowy zwykły schemat i mówią: „No cóż, tutaj wszystko jest jasne! Zainstaluj program, który będzie to wszystko monitorował.” Tak, tak: Prometheus + Grafana + wtyczki.
I dodają: „Masz dwa tygodnie, upewnij się, że wszystko jest bezpieczne”.

W wielu projektach, które widzimy, do monitorowania przydzielana jest jedna osoba. Wyobraźmy sobie, że chcemy zatrudnić osobę do monitoringu na 2 tygodnie i piszemy dla niej CV. Jakie umiejętności powinna posiadać ta osoba, biorąc pod uwagę wszystko, co powiedzieliśmy do tej pory?

• Musi rozumieć monitoring i specyfikę działania infrastruktury żelaznej.
• Musi zrozumieć specyfikę monitorowania Kubernetesa (a każdy chce iść do „kostki”, bo można od wszystkiego się odczepić, ukryć, bo resztą zajmie się administrator) – siebie, jego infrastrukturę i zrozumieć, jak monitorować aplikacje wewnątrz.
• Musi zrozumieć, że usługi komunikują się ze sobą w szczególny sposób i znać specyfikę wzajemnego oddziaływania usług. Całkiem możliwe jest zobaczenie projektu, w którym niektóre usługi komunikują się synchronicznie, ponieważ nie ma innego sposobu. Przykładowo backend przechodzi przez REST, poprzez gRPC do usługi katalogowej, odbiera listę produktów i zwraca ją z powrotem. Nie możesz tu czekać. W przypadku innych usług działa asynchronicznie. Przekaż zamówienie firmie kurierskiej, wyślij list itp.
  Pewnie już z tego wszystkiego pływałeś? A administrator, który musi to monitorować, stał się jeszcze bardziej zdezorientowany.
• Musi umieć planować i planować poprawnie - w miarę jak pracy staje się coraz więcej.
• Musi zatem stworzyć strategię na podstawie stworzonej usługi, aby zrozumieć, jak ją konkretnie monitorować. Potrzebuje zrozumienia architektury projektu i jego rozwoju + zrozumienia technologii wykorzystywanych w rozwoju.

Przypomnijmy sobie zupełnie normalny przypadek: część usług jest w PHP, część w Go, część w JS. W jakiś sposób ze sobą współpracują. Stąd pochodzi określenie „mikroserwis”: poszczególnych systemów jest tak wiele, że programiści nie są w stanie zrozumieć projektu jako całości. Jedna część zespołu pisze usługi w JS, które działają samodzielnie i nie wiedzą, jak działa reszta systemu. Druga część pisze usługi w Pythonie i nie ingeruje w działanie innych usług; są one izolowane na swoim własnym obszarze. Trzecim jest pisanie usług w PHP lub czymś innym.
Wszystkie te 20 osób jest podzielonych na 15 usług i jest tylko jeden administrator, który musi to wszystko zrozumieć. Zatrzymywać się! po prostu podzieliliśmy system na 15 mikroserwisów, ponieważ 20 osób nie jest w stanie zrozumieć całego systemu.

Ale trzeba to jakoś monitorować...

Jaki jest wynik? W rezultacie jest jedna osoba, która wymyśla wszystko, czego cały zespół programistów nie jest w stanie zrozumieć, a jednocześnie musi też wiedzieć i umieć robić to, co wskazaliśmy powyżej – infrastrukturę sprzętową, infrastrukturę Kubernetes itp.

Cóż mogę powiedzieć... Houston, mamy problemy.

Monitorowanie nowoczesnego projektu oprogramowania jest projektem samym w sobie

Z fałszywego przekonania, że ​​monitoring to oprogramowanie, wyrasta nam wiara w cuda. Ale cuda, niestety, się nie zdarzają. Nie możesz zainstalować Zabbix i oczekiwać, że wszystko będzie działać. Nie ma sensu instalować Grafany i mieć nadzieję, że wszystko będzie dobrze. Najwięcej czasu zostanie poświęcone na organizowanie kontroli działania usług i ich wzajemnego oddziaływania, sprawdzanie jak działają systemy zewnętrzne. Tak naprawdę 90% czasu nie będzie poświęcone na pisanie skryptów, ale na tworzenie oprogramowania. I powinien się tym zająć zespół, który rozumie, na czym polega praca nad projektem.
Jeśli w tej sytuacji do monitoringu wrzucona zostanie jedna osoba, wówczas nastąpi katastrofa. To samo dzieje się wszędzie.

Na przykład istnieje kilka usług, które komunikują się ze sobą za pośrednictwem platformy Kafka. Zamówienie dotarło, wysłaliśmy wiadomość o zamówieniu do Kafki. Istnieje usługa, która nasłuchuje informacji o zamówieniu i wysyła towar. Istnieje usługa, która nasłuchuje informacji o zamówieniu i wysyła list do użytkownika. A potem pojawia się wiele innych usług i zaczynamy się mylić.

A jeśli przekażesz to również administratorowi i programistom na etapie, gdy do wydania pozostało niewiele czasu, osoba ta będzie musiała zrozumieć cały ten protokół. Te. Projekt tej skali zajmuje znaczną ilość czasu i należy to uwzględnić w rozwoju systemu.
Ale bardzo często, zwłaszcza w startupach, widzimy, jak monitorowanie jest odkładane na później. „Teraz zrobimy dowód koncepcji, wystartujemy z nim, pozwolimy mu upaść – jesteśmy gotowi do poświęceń. A potem będziemy to wszystko monitorować.” Kiedy (lub jeśli) projekt zacznie przynosić zyski, firma chce dodać jeszcze więcej funkcji – ponieważ zaczął działać, więc trzeba go dalej rozwijać! I jesteś w punkcie, w którym musisz najpierw monitorować wszystko poprzednie, co zajmuje nie 1% czasu, ale znacznie więcej. A tak przy okazji, do monitorowania będą potrzebni programiści i łatwiej jest pozwolić im pracować nad nowymi funkcjami. W rezultacie powstają nowe funkcje, wszystko się psuje i znajdujesz się w niekończącym się impasie.

Jak zatem monitorować projekt od początku i co zrobić, jeśli trafisz na projekt, który wymaga monitorowania, ale nie wiesz od czego zacząć?

Po pierwsze, musisz zaplanować.

Dygresja liryczna: bardzo często zaczynają się od monitorowania infrastruktury. Na przykład mamy Kubernetes. Zacznijmy od zainstalowania Prometheusa z Grafaną, zainstalowania wtyczek do monitorowania „kostki”. Nie tylko programiści, ale także administratorzy mają niefortunną praktykę: „Zainstalujemy tę wtyczkę, ale wtyczka prawdopodobnie wie, jak to zrobić”. Ludzie lubią zaczynać od rzeczy prostych i bezpośrednich, a nie od ważnych działań. Monitorowanie infrastruktury jest łatwe.

Najpierw zdecyduj, co i jak chcesz monitorować, a następnie wybierz narzędzie, bo inni nie mogą myśleć za Ciebie. A powinni? Inni ludzie myśleli o uniwersalnym systemie - albo w ogóle nie myśleli, kiedy pisano tę wtyczkę. I to, że ta wtyczka ma 5 tysięcy użytkowników, nie oznacza, że ​​jest do czegokolwiek przydatna. Być może zostaniesz 5001. po prostu dlatego, że wcześniej było tam już 5000 osób.

Jeżeli zaczniesz monitorować infrastrukturę i backend Twojej aplikacji przestanie odpowiadać, wszyscy użytkownicy stracą połączenie z aplikacją mobilną. Pojawi się błąd. Przyjdą do Ciebie i powiedzą: „Aplikacja nie działa, co tu robisz?” – „Monitorujemy”. — „Jak monitorować, jeśli nie widzisz, że aplikacja nie działa?!”.

1. Uważam, że monitorowanie należy rozpocząć dokładnie od punktu wejścia użytkownika. Jeśli użytkownik nie widzi, że aplikacja działa, to koniec, awaria. I o tym najpierw powinien ostrzegać system monitoringu.
2. I dopiero wtedy będziemy mogli monitorować infrastrukturę. Lub zrób to równolegle. Z infrastrukturą jest łatwiej – tutaj w końcu możemy po prostu zainstalować Zabbix.
3. A teraz musisz udać się do korzeni aplikacji, aby zrozumieć, gdzie coś nie działa.

Moją główną ideą jest to, że monitorowanie powinno przebiegać równolegle z procesem rozwoju. Jeśli odwrócisz uwagę zespołu monitorującego od innych zadań (tworzenie CI/CD, piaskownica, reorganizacja infrastruktury), monitorowanie zacznie się opóźniać i być może nigdy nie nadążysz za rozwojem (lub prędzej czy później będziesz musiał go zatrzymać).

Wszystko według poziomów

Tak widzę organizację systemu monitoringu.

1) Poziom aplikacji:

• monitorowanie logiki biznesowej aplikacji;
• monitorowanie wskaźników kondycji usług;
• monitorowanie integracji.

2) Poziom infrastruktury:

• monitorowanie poziomu orkiestracji;
• monitorowanie oprogramowania systemowego;
• monitorowanie poziomu żelaza.

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

• zbieranie i monitorowanie logów aplikacji;
• APM;
• rysunek kalkowy.

4) Alarmowanie:

• organizacja systemu ostrzegania;
• organizacja systemu dyżurów;
• organizacja „bazy wiedzy” i przepływu pracy w celu przetwarzania incydentów.

To jest ważne: do alarmu dochodzimy nie później, ale od razu! Nie ma potrzeby uruchamiać monitoringu i „jakoś później” dowiedzieć się, kto otrzyma alerty. W końcu jakie jest zadanie monitorowania: zrozumieć, gdzie w systemie coś działa nie tak i powiadomić o tym odpowiednie osoby. Jeśli zostawisz to na koniec, właściwi ludzie będą wiedzieć, że coś jest nie tak, tylko po stwierdzeniu, że „nic nam nie działa”.

Warstwa aplikacji - Monitorowanie logiki biznesowej

Mówimy tutaj o sprawdzeniu samego faktu, że aplikacja działa dla użytkownika.

Poziom ten należy wykonać w fazie rozwoju. Na przykład mamy warunkowy Prometheus: trafia do serwera, który sprawdza, pobiera punkt końcowy, a punkt końcowy przechodzi i sprawdza API.

Programiści często proszeni o monitorowanie strony głównej, aby upewnić się, że witryna działa, podają uchwyt, z którego można skorzystać za każdym razem, gdy chcą się upewnić, że interfejs API działa. A programiści w tej chwili nadal pobierają i piszą /api/test/helloworld
Jedyny sposób, aby upewnić się, że wszystko działa? - NIE!

• Tworzenie takich kontroli jest zasadniczo zadaniem programistów. Testy jednostkowe powinni pisać programiści piszący kod. Ponieważ jeśli ujawnisz to administratorowi, „Koleś, oto lista protokołów API dla wszystkich 25 funkcji, monitoruj wszystko!” - nic nie wyjdzie.
• Jeśli wydrukujesz „witaj świecie”, nikt nigdy nie będzie wiedział, że interfejs API powinien i działa. Każda zmiana API musi prowadzić do zmiany kontroli.
• Jeśli masz już taki problem, zatrzymaj funkcje i przydziel programistów, którzy napiszą te kontrole, lub zaakceptuj straty, zaakceptuj fakt, że nic nie jest sprawdzane i zakończy się niepowodzeniem.

Wskazówki techniczne:

• Koniecznie zorganizuj zewnętrzny serwer do organizowania kontroli – musisz mieć pewność, że Twój projekt będzie dostępny dla świata zewnętrznego.
• Organizuj kontrole całego protokołu API, a nie tylko poszczególnych punktów końcowych.
• Utwórz punkt końcowy Prometheus z wynikami testu.

Warstwa aplikacji – monitorowanie wskaźników kondycji

Teraz mówimy o zewnętrznych wskaźnikach zdrowia usług.

Zdecydowaliśmy, że wszystkie „chwyty” aplikacji monitorujemy za pomocą zewnętrznych kontroli, które wywołujemy z zewnętrznego systemu monitorującego. Ale to są „uchwyty”, które „widzi” użytkownik. Chcemy mieć pewność, że nasze usługi same w sobie działają. Tutaj jest lepsza historia: K8s ma kontrole stanu, dzięki czemu chociaż sama „kostka” może być przekonana, że ​​usługa działa. Ale połowa czeków, które widziałem, to ten sam nadruk „witaj, świecie”. Te. Więc ciągnie raz po rozmieszczeniu, odpowiedział, że wszystko w porządku - to wszystko. A usługa, jeśli udostępnia własne API, ma ogromną liczbę punktów wejścia dla tego samego API, co również trzeba monitorować, bo chcemy wiedzieć, czy to działa. I już to monitorujemy w środku.

Jak to poprawnie technicznie zaimplementować: każda usługa udostępnia punktowi końcowemu informacje o swojej aktualnej wydajności, a na wykresach Grafany (lub dowolnej innej aplikacji) widzimy status wszystkich usług.

• Każda zmiana API musi prowadzić do zmiany kontroli.
• Utwórz od razu nową usługę, korzystając ze wskaźników kondycji.
• Administrator może przyjść do programistów i zapytać „dodaj mi kilka funkcji, abym wszystko zrozumiał, i dodaj informacje na ten temat do mojego systemu monitorowania”. Ale programiści zwykle odpowiadają: „Nie będziemy dodawać niczego na dwa tygodnie przed premierą”.
  Poinformuj menedżerów ds. rozwoju, że wystąpią takie straty, powiadom także kierownictwo menedżerów ds. rozwoju. Bo gdy wszystko spadnie, ktoś i tak będzie dzwonił i żądał monitorowania „ciągle spadającej usługi” (c)
• Przy okazji, przydziel programistów do pisania wtyczek do Grafany - będzie to dobra pomoc dla administratorów.

Warstwa aplikacji – monitorowanie integracji

Monitorowanie integracji koncentruje się na monitorowaniu komunikacji pomiędzy systemami o znaczeniu krytycznym dla biznesu.

Na przykład istnieje 15 usług, które komunikują się ze sobą. To już nie są osobne strony. Te. nie możemy samodzielnie uruchomić usługi, uzyskać /helloworld i zrozumieć, że usługa działa. Ponieważ serwis internetowy zamówień musi wysłać informację o zamówieniu do autobusu - z autobusu obsługa magazynu musi otrzymać tę wiadomość i dalej z nią pracować. A usługa dystrybucji poczty e-mail musi to jakoś dalej przetworzyć itp.

W związku z tym nie możemy zrozumieć, szturchając każdą usługę z osobna, że ​​to wszystko działa. Ponieważ mamy pewien autobus, poprzez który wszystko się komunikuje i wchodzi w interakcję.
Dlatego ten etap powinien oznaczać etap testowania usług pod kątem interakcji z innymi usługami. Nie da się zorganizować monitorowania komunikacji poprzez monitorowanie brokera komunikatów. Jeśli istnieje usługa wysyłająca dane i usługa je odbierająca, monitorując brokera zobaczymy jedynie dane, które lecą z boku na bok. Nawet jeśli udałoby nam się w jakiś sposób wewnętrznie monitorować interakcję tych danych – że dany producent publikuje dane, ktoś je czyta, ten przepływ dalej trafia do Kafki – to i tak nie da nam informacji, czy jeden serwis wysłał wiadomość w jednej wersji , ale druga usługa nie spodziewała się tej wersji i ją pominęła. Nie dowiemy się o tym, bo służby powiedzą nam, że wszystko działa.

Co polecam zrobić:

• W przypadku komunikacji synchronicznej: punkt końcowy wysyła żądania do powiązanych usług. Te. bierzemy ten punkt końcowy, wyciągamy skrypt wewnątrz usługi, który przechodzi do wszystkich punktów i mówi: „Mogę ciągnąć tam i ciągnąć tam, mogę ciągnąć tam…”
• W przypadku komunikacji asynchronicznej: komunikaty przychodzące – punkt końcowy sprawdza magistralę pod kątem komunikatów testowych i wyświetla status przetwarzania.
• Dla komunikacji asynchronicznej: komunikaty wychodzące – punkt końcowy wysyła komunikaty testowe na magistralę.

Jak to zwykle bywa: mamy usługę wrzucającą dane do magistrali. Przychodzimy do tej usługi i prosimy o opowiedzenie nam o jej kondycji integracji. A jeśli usługa będzie musiała wygenerować wiadomość gdzieś dalej (WebApp), wówczas wygeneruje tę wiadomość testową. A jeśli uruchomimy usługę po stronie OrderProcessing, to najpierw wrzuca to, co może opublikować samodzielnie, a jeśli są jakieś rzeczy zależne, to czyta z magistrali zestaw komunikatów testowych, rozumie, że może je przetworzyć, zgłosić i , jeśli trzeba, wrzuć je dalej i o tym mówi - wszystko w porządku, żyję.

Bardzo często słyszymy pytanie „jak możemy to przetestować na danych bojowych?” Na przykład mówimy o tej samej usłudze zamawiania. Zamówienie wysyła wiadomości do magazynu, w którym towar jest odpisany: nie możemy tego przetestować na danych bojowych, ponieważ „moje towary zostaną odpisane!” Rozwiązanie: Zaplanuj cały test na początku. Masz także testy jednostkowe, które robią drwiny. Zrób to więc na głębszym poziomie, gdzie masz kanał komunikacji, który nie szkodzi funkcjonowaniu firmy.

Warstwa infrastruktury

Monitorowanie infrastruktury jest czymś, co od dawna uważane jest za monitorowanie samo w sobie.

• Monitoring infrastruktury może i powinien zostać uruchomiony jako odrębny proces.
• Nie powinieneś zaczynać od monitorowania infrastruktury w działającym projekcie, nawet jeśli naprawdę chcesz. Jest to ból dla wszystkich devopsów. „Najpierw będę monitorować klaster, będę monitorować infrastrukturę” – tj. Najpierw będzie monitorował to, co znajduje się poniżej, ale nie przejdzie do aplikacji. Ponieważ aplikacja jest rzeczą niezrozumiałą dla devopsów. Do niego wyciekło, a on nie rozumie, jak to działa. Ale rozumie infrastrukturę i zaczyna od niej. Ale nie - zawsze musisz najpierw monitorować aplikację.
• Nie przesadzaj z liczbą alertów. Biorąc pod uwagę złożoność nowoczesnych systemów, alerty nieustannie się pojawiają i trzeba jakoś żyć z tą masą alertów. A dyżurny po obejrzeniu setki kolejnych alertów zdecyduje: „Nie chcę o tym myśleć”. Alerty powinny powiadamiać tylko o krytycznych sytuacjach.

Poziom aplikacji jako jednostka biznesowa

Kluczowe punkty:

• JELEŃ KANADYJSKI. Jest to standard branżowy. Jeśli z jakiegoś powodu nie agregujesz logów, zacznij to robić natychmiast.
• APM. Zewnętrzne APM-y jako sposób na szybkie zamknięcie monitoringu aplikacji (NewRelic, BlackFire, Datadog). Możesz zainstalować tę rzecz tymczasowo, aby przynajmniej w jakiś sposób zrozumieć, co się z tobą dzieje.
• Rysunek kalkowy. W dziesiątkach mikroserwisów trzeba wszystko prześledzić, bo żądanie nie żyje już samo. Bardzo trudno jest dodać później, dlatego lepiej od razu zaplanować śledzenie w fazie rozwoju - jest to praca i użyteczność programistów. Jeśli jeszcze tego nie wdrożyłeś, zrealizuj to! Zobacz Jaegera/Zipkina

Alarmowanie

• Organizacja systemu powiadomień: w warunkach monitorowania wielu rzeczy powinien istnieć ujednolicony system wysyłania powiadomień. Można w Grafanie. Na Zachodzie wszyscy korzystają z PagerDuty. Alerty powinny być jasne (np. skąd pochodzą...). Wskazane jest kontrolowanie, czy powiadomienia są w ogóle odbierane
• Organizacja systemu dyżurów: nie należy wysyłać ostrzeżeń do wszystkich (albo wszyscy zareagują w tłumie, albo nikt nie zareaguje). Deweloperzy też muszą być dyspozycyjni: pamiętajcie o określeniu obszarów odpowiedzialności, sporządzeniu jasnych instrukcji i zapisaniu w nich, do kogo dokładnie dzwonić w poniedziałek i środę, a do kogo we wtorek i piątek (w przeciwnym razie nie zadzwonią do nikogo nawet w godzinach w przypadku dużego problemu - będą się bać Cię obudzić lub przeszkodzić: ludzie generalnie nie lubią dzwonić i budzić innych, zwłaszcza w nocy). I wyjaśnij, że proszenie o pomoc nie jest oznaką niekompetencji („Proszę o pomoc, to znaczy, że jestem złym pracownikiem”), zachęcaj do proszenia o pomoc.
• Organizacja „bazy wiedzy” i przepływu pracy w zakresie przetwarzania incydentów: w przypadku każdego poważnego zdarzenia należy zaplanować sekcję zwłok i, jako środek tymczasowy, zapisać działania, które rozwiążą incydent. I niech stanie się praktyką, że powtarzające się ostrzeżenia są grzechem; należy je naprawić w kodzie lub infrastrukturze.

Stos technologii

Wyobraźmy sobie, że nasz stos wygląda następująco:

• zbieranie danych - Prometheus + Grafana;
• analiza logów - ELK;
• dla APM lub Tracing - Jaeger (Zipkin).

Wybór opcji nie jest krytyczny. Bo jeśli na początku zrozumiałeś jak monitorować system i spisałeś plan, to zaczynasz dobierać narzędzia pod swoje wymagania. Pytanie brzmi, co zdecydowałeś się monitorować w pierwszej kolejności. Być może narzędzie, które wybrałeś na początku, w ogóle nie odpowiada Twoim wymaganiom.

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

Prometeusz zostaje wepchnięty do Kubernetesa – kto na to wpadł?! Co zrobisz, jeśli klaster ulegnie awarii? Jeżeli wewnątrz klastra znajduje się złożony klaster, to wewnątrz klastra powinien znajdować się jakiś system monitorowania, a na zewnątrz jakiś system, który będzie zbierał dane z wnętrza klastra.

Wewnątrz klastra zbieramy logi i wszystko inne. Ale system monitorowania musi znajdować się na zewnątrz. Bardzo często w klastrze, w którym wewnętrznie zainstalowany jest Promtheus, znajdują się także systemy, które dokonują zewnętrznej kontroli działania obiektu. A co jeśli zerwą się Twoje połączenia ze światem zewnętrznym i aplikacja nie będzie działać? Okazuje się, że w środku wszystko jest w porządku, ale użytkownikom nie ułatwia to życia.

odkrycia

• Monitorowanie rozwoju nie polega na instalowaniu narzędzi, ale na opracowywaniu oprogramowania. 98% dzisiejszego monitorowania to kodowanie. Kodowanie w usługach, kodowanie kontroli zewnętrznych, sprawdzanie usług zewnętrznych i to wszystko.
• Nie marnuj czasu programistów na monitorowanie: może to zająć do 30% ich pracy, ale warto.
• Devops, nie martw się, że nie możesz czegoś monitorować, ponieważ niektóre rzeczy mają zupełnie inny sposób myślenia. Nie byłeś programistą, a monitorowanie pracy to właśnie ich praca.
• Jeśli projekt już trwa i nie jest monitorowany (a jesteś menadżerem), przydziel zasoby do monitorowania.
• Jeśli produkt jest już w produkcji, a Ty jesteś devopsem, któremu kazano „ustawić monitoring” – spróbuj wyjaśnić kierownictwu, o czym to wszystko pisałem.

To jest rozszerzona wersja raportu z konferencji Saint Highload++.

Jeśli interesują Cię moje pomysły i przemyślenia na ten temat oraz tematy pokrewne, tutaj możesz to zrobić czytaj kanał 🙂

Źródło: www.habr.com