O utworzeniu systemu monitorowania zaczęliśmy myśleć w momencie formowania zespołów produktowych. Zdało się jasne, że nasza robota — eksploatacja — w te zespoły w ogóle nie trafia. Dlaczego tak jest?
Chodzi o to, że wszystkie nasze zespoły są zbudowane wokół oddzielnych systemów informacyjnych, mikroserwisów i frontów, więc ogólny stan zdrowia całego systemu w całości nie jest dostrzegany przez zespoły. Na przykład, mogą nie wiedzieć, jak jakaś mała część w głębokim backendzie wpływa na część frontową. Ich zainteresowania ograniczają się do systemów, z którymi zintegrowany jest ich system. Jeśli zespół i jego usługa A prawie w ogóle nie mają związku z usługą B, to taka usługa jest dla zespołu prawie niewidoczna.
Nasz zespół z kolei pracuje z systemami, które są ze sobą znacznie zintegrowane: między nimi istnieje wiele powiązań, to dość duża infrastruktura. A od wszystkich tych systemów (których mamy zresztą ogromną ilość) zależy działanie sklepu internetowego.
I tak wychodzi na to, że nasz dział nie należy do żadnego zespołu, lecz znajduje się nieco na uboczu. W całej tej historii naszym zadaniem jest zrozumienie w całości, jak działają systemy informacyjne, ich funkcjonalność, integracje, oprogramowanie, sieć, sprzęt i jak wszystko to jest ze sobą powiązane.
Platforma, na której działają nasze sklepy internetowe, wygląda tak:
- front
- middle-office
- back-office
Jak byśmy nie chcieli, to nie ma tak, że wszystkie systemy działają płynnie i bezproblemowo. Chodzi, znowu, o ilość systemów i integracji - przy takim stanie, jak u nas, jakieś incydenty są nieuniknione, niezależnie od jakości testów. A to zarówno wewnątrz jakiegoś pojedynczego systemu, jak i w zakresie ich integracji. I trzeba monitorować stan całej platformy kompleksowo, a nie jakiejś jej pojedynczej części.
Ideą jest zautomatyzowanie monitorowania stanu zdrowia całej platformy. I doszliśmy do wniosku, że monitorowanie jest nieuniknioną częścią tego procesu. Na początku było ono zbudowane tylko dla części frontowej, przy tym poszczególne systemy monitorowania według warstw istniały i istnieją u sieciowców, administratorów oprogramowania i sprzętu. Wszyscy ci ludzie monitorowali stan tylko na swoim poziomie, nikt nie miał całościowego zrozumienia.
Na przykład, jeśli wirtualna maszyna przestanie działać, w większości przypadków wie o tym tylko administrator odpowiedzialny za sprzęt i wirtualną maszynę. Zespół front-end w takich okolicznościach widział jedynie sam fakt awarii aplikacji, ale nie miał danych o awarii wirtualnej maszyny. Administrator może wiedzieć, kto jest zleceniodawcą, i mniej więcej wyobrażać sobie, co aktualnie działa na tej wirtualnej maszynie, pod warunkiem, że jest to jakiś większy projekt. Na temat małych projektów raczej nie ma wiedzy. W każdym razie administrator musi udać się do właściciela i zapytać, co znajdowało się na tej maszynie, co należy przywrócić i co zmienić. A jeśli coś poważnego się zawaliło, zaczyna się bieg w kółko — ponieważ nikt nie miał widoku na cały system.
Ostatecznie takie rozproszone historie wpływają na cały front-end, na użytkowników i naszą podstawową funkcję biznesową — sprzedaż przez internet. Ponieważ nie wchodzimy w zespoły, a zajmujemy się eksploatacją wszystkich aplikacji e-commerce w ramach sklepu internetowego, podjęliśmy się stworzenia kompleksowego systemu monitorowania platformy e-commerce.
Struktura systemu i stos technologiczny
Zaczęliśmy od wyodrębnienia kilku warstw monitorowania dla naszych systemów, w zakresie których będziemy musieli gromadzić metryki. I wszystko to trzeba było połączyć, co zrealizowaliśmy w pierwszym etapie. Teraz w tym etapie udoskonalamy maksymalnie jakościowy zbiór metryk we wszystkich naszych warstwach, aby budować korelacje i rozumieć, jak systemy wpływają na siebie nawzajem.
Brak kompleksowego monitorowania na początkowych etapach uruchamiania aplikacji (ponieważ zaczęliśmy go budować, gdy większość systemów była w eksploatacji) doprowadził do tego, że pojawił się znaczny dług techniczny związany z konfiguracją monitorowania całej platformy. Nie mogliśmy sobie pozwolić na skoncentrowanie się na konfigurowaniu monitorowania konkretnego systemu informacyjnego i szczegółowym opracowywaniu monitorowania dla niego, ponieważ pozostałe systemy na jakiś czas pozostałyby bez monitorowania. Aby rozwiązać ten problem, określiliśmy listę najważniejszych metryk oceny stanu systemu informacyjnego według warstw i zaczęliśmy ją wdrażać.
Dlatego postanowiliśmy zjeść słonia kawałek po kawałku.
Nasz system składa się z:
- sprzętu;
- systemu operacyjnego;
- oprogramowania;
- Części UI w aplikacji monitorującej;
- metryki biznesowe;
- aplikacje integracyjne;
- bezpieczeństwo informacji;
- sieci;
- balansowanie ruchu.
W centrum tego systemu znajduje się monitorowanie. Aby zrozumieć stan całego systemu, trzeba wiedzieć, co dzieje się z aplikacjami na wszystkich tych warstwach i w kontekście całej gamy aplikacji.
A więc, o stosie.
Używamy oprogramowania z otwartym źródłem. W centrum mamy Zabbixa, którego używamy przede wszystkim jako systemu powiadamiania. Wszyscy wiedzą, że idealnie nadaje się do monitorowania infrastruktury. Co mamy na myśli? Te niskopoziomowe metryki, które posiada każda firma mająca swoje centra danych (a Sportmaster ma swoje centra danych) — temperatura serwera, stan pamięci, RAID, metryki urządzeń sieciowych.
Zintegrowaliśmy Zabbixa z komunikatorem Telegram i Microsoft Teams, które są aktywnie używane w zespołach. Zabbix pokrywa warstwę faktycznej sieci, sprzętu i częściowo oprogramowania, ale to nie jest panaceum. Wzbogacamy te dane z innych usług. Na przykład, w zakresie sprzętu łączymy się bezpośrednio przez API w naszym systemie wirtualizacji i pobieramy dane.
Co więcej. Oprócz Zabbixa używamy Prometheusa, który pozwala na monitorowanie metryk w aplikacji w dynamicznym środowisku. Oznacza to, że możemy uzyskiwać metryki aplikacji poprzez punkt końcowy HTTP i nie martwić się o to, które metryki załadować, a które nie. Na podstawie tych danych można opracowywać analityczne zapytania.
Źródła danych dla pozostałych warstw, na przykład business metrics, dzielą się na trzy części.
Po pierwsze, to zewnętrzne systemy biznesowe, Google Analytics, zbieramy metryki z logów. Otrzymujemy z nich dane o aktywnych użytkownikach, konwersji i wszystkim innym związanym z biznesem. Po drugie, to system monitorowania UI. O tym należy opowiedzieć bardziej szczegółowo.
Kiedyś zaczynaliśmy od testowania manualnego, które przekształciło się w automatyczne testy funkcjonalności i integracji. To z niego stworzyliśmy monitorowanie, pozostawiając tylko podstawową funkcjonalność i wiążąc się z markerami, które są maksymalnie stabilne i nie zmieniają się często w czasie.
Nowa struktura zespołów oznacza, że cała działalność związana z aplikacjami koncentruje się na zespołach produktowych, dlatego przestaliśmy zajmować się testowaniem w czystej formie. Zamiast tego przekształciliśmy testy w monitorowanie UI, napisane w Java, Selenium i Jenkins (używany jako system uruchamiania i generowania raportów).
Mieliśmy wiele testów, ale ostatecznie zdecydowaliśmy się wyjść na główną drogę — metrykę na wyższym poziomie. I jeśli będziemy mieć wiele specyficznych testów, trudno będzie utrzymać aktualność danych. Każde następne wydanie znacznie zepsuje cały system, a my będziemy tylko zajmować się jego naprawą. Dlatego skupiliśmy się na całkowicie podstawowych rzeczach, które rzadko się zmieniają, i monitorujemy tylko je.
W końcu, po trzecie, źródłem danych jest scentralizowany system logowania. Do logów używamy Elastic Stack, a następnie te dane możemy pobierać do naszego systemu monitorowania metrykami biznesowymi. Dodatkowo działa nasza własna usługa Monitoring API, napisana w Pythonie, która zapytuje przez API dowolne usługi i pobiera dane z nich do Zabbix.
Kolejnym niezbędnym atrybutem monitorowania jest wizualizacja. U nas opiera się ona na Grafanie. Wśród innych systemów wizualizacji wyróżnia się tym, że na pulpicie można wizualizować metryki z różnych źródeł danych. Możemy zebrać metryki na wyższym poziomie ze sklepu internetowego, na przykład liczbę zamówień złożonych w ciągu ostatniej godziny z bazy danych, metryki wydajności systemu operacyjnego, na którym działa ten sklep, z Zabbix, oraz metryki instancji tej aplikacji z Prometheusa. I wszystko to będzie na jednym pulpicie. Przejrzyste i dostępne.
Zaznaczę również kwestię bezpieczeństwa — obecnie dopracowujemy system, który później zintegrować będziemy z globalnym systemem monitorowania. Moim zdaniem, główne problemy, z którymi boryka się e-commerce w zakresie bezpieczeństwa informacji, związane są z botami, parserami i atakami brute force. Trzeba to monitorować, ponieważ wszystko to może mieć krytyczny wpływ na działanie naszych aplikacji oraz na reputację z punktu widzenia biznesu. Wybranym stosem skutecznie pokrywamy te zadania.
Kolejnym ważnym punktem jest to, że poziom aplikacji zbierany jest przez Prometheusa. Jest on również zintegrowany z Zabbixem. Dodatkowo mamy sitespeed, serwis, który pozwala nam monitorować takie parametry, jak czas ładowania naszej strony, wąskie gardła, renderowanie strony, ładowanie skryptów i inne, który także jest zintegrowany przez API. Tak więc metryki zbieramy w Zabbixie i z tego samego źródła wysyłamy alerty. Wszystkie alerty obecnie są wysyłane głównie za pośrednictwem e-maila i telegramu; niedawno podłączyliśmy również MS Teams. Planujemy rozbudować system powiadomień do takiego stanu, aby inteligentni boty działały jako serwis i dostarczały informacje o monitorowaniu wszystkim zainteresowanym zespołom produktowym.
Dla nas istotne są metryki nie tylko poszczególnych systemów informacyjnych, ale także ogólne metryki całej infrastruktury, z której korzystają aplikacje: klastry serwerów fizycznych, na których działają wirtualne maszyny, balancery obciążenia, Network Load Balancer-y, sama sieć, wykorzystanie kanałów komunikacyjnych. Dodatkowo metryki z naszych własnych centrów danych (mamy ich kilka i infrastruktura jest dość znacznych rozmiarów).
Zaletą naszego systemu monitorowania jest to, że dzięki niemu widzimy stan operacyjny wszystkich systemów, możemy ocenić ich wzajemny wpływ oraz wpływ na wspólne zasoby. Ostatecznie pozwala nam to zajmować się planowaniem zasobów, co również należy do naszego zakresu odpowiedzialności. Zarządzamy zasobami serwerowymi — pulami w ramach e-commerce, wprowadzamy i wyprowadzamy z eksploatacji nowe sprzęty, dokonujemy zakupu nowego sprzętu, przeprowadzamy audyt wykorzystania zasobów i inne. Każdego roku zespoły planują nowe projekty, rozwijają własne systemy, a dla nas istotne jest zapewnienie im zasobów.
Dzięki metrykom widzimy tendencję zużycia zasobów przez nasze systemy informacyjne. Na ich podstawie możemy coś zaplanować. Na poziomie wirtualizacji zbieramy dane i widzimy informacje o dostępnej ilości zasobów w kontekście centrów danych. A już wewnątrz centrum danych widzimy zarówno wykorzystanie, jak i faktyczne rozdzielenie oraz zużycie zasobów, zarówno dla serwerów standalone, jak i wirtualnych maszyn oraz klastrów fizycznych serwerów, na których wszystkie te wirtualki sprawnie działają.
Perspektywy
Obecnie mamy gotowe jądro systemu jako całość, ale pozostało jeszcze wiele kwestii, nad którymi musimy pracować. Przynajmniej warstwa bezpieczeństwa informacji, ale ważne jest również dotarcie do sieci, rozwinięcie systemu alertów i rozwiązanie problemu z korelacją. Mamy wiele warstw i systemów, a na każdej z warstw mnóstwo metryk. To jak matrioszka w stopniu matrioszki.
Naszym celem jest w końcu stworzenie odpowiednich alertów. Na przykład, jeśli wystąpił problem z częścią sprzętową, znowu z maszyną wirtualną, a tam było ważne aplikacji, a usługa nie była w żaden sposób zarezerwowana. Dowiemy się, że maszyna wirtualna uległa awarii. Następnie będą alarmować metryki biznesowe: użytkownicy gdzieś zniknęli, nie ma konwersji, interfejs UI jest niedostępny, oprogramowanie i usługi również przestały działać.
W takim przypadku otrzymamy spam z alertami, co już nie pasuje do formatu prawidłowego systemu monitorowania. Pojawia się kwestia korelacji. Dlatego w idealnym przypadku nasz system monitorowania powinien powiedzieć: „Chłopaki, wasza fizyczna maszyna uległa awarii, a razem z nią ta aplikacja i takie metryki”, za pomocą jednego alertu, zamiast zasypywać nas setką alertów. Powinien informować o głównym problemie — o przyczynie, co sprzyja szybkiemu rozwiązaniu problemu poprzez jego lokalizację.
Nasz system powiadomień i przetwarzania alertów jest zbudowany wokół całodobowej infolinii. Wszystkie alerty, które uznajemy za niezbędne i które znajdują się na naszej liście kontrolnej, są przekazywane tam. Każdy alert musi mieć opis: co się wydarzyło, co to oznacza i na co wpływa. A także link do pulpitu nawigacyjnego i instrukcję, co w takim przypadku należy zrobić.
To wszystko, co dotyczy wymagań dotyczących budowy systemu alertów. Następnie sytuacja może rozwijać się w dwóch kierunkach — albo problem istnieje i należy go rozwiązać, albo wystąpiła awaria w systemie monitorowania. W każdym przypadku trzeba działać i dowiedzieć się, co się dzieje.
Średnio obecnie otrzymujemy około stu alertów dziennie, biorąc pod uwagę, że korelacja alertów jeszcze nie została prawidłowo skonfigurowana. A jeśli potrzebujemy przeprowadzić prace techniczne i coś z powrotem wyłączamy, ich liczba wzrasta wielokrotnie.
Oprócz monitorowania systemów, które eksploatujemy, oraz zbierania metryk uznawanych przez nas za ważne, system monitorowania umożliwia zbieranie danych dla zespołów produktowych. Mogą one wpływać na skład metryk w ramach systemów informacyjnych, które są u nas monitorowane.
Nasz kolega może przyjść i poprosić o dodanie jakiejś metryki, która okaże się przydatna zarówno dla nas, jak i dla zespołu. Albo na przykład zespół może nie mieć wystarczających podstawowych metryk, które posiadamy, potrzebują oni śledzić coś specyficznego. W Grafanie tworzymy przestrzeń dla każdego zespołu i przydzielamy prawa administratora. Jeśli zespół potrzebuje pulpitów nawigacyjnych, a nie mogą sami tego zrobić lub nie wiedzą jak, pomagamy im.
Ponieważ jesteśmy poza strumieniem tworzenia wartości zespołu, ich wydań i planowania, stopniowo dochodzimy do punktu, w którym wydania wszystkich systemów są bezszwowe i mogą być wdrażane codziennie, bez konieczności uzgadniania z nami. A dla nas ważne jest, aby śledzić te wydania, ponieważ potencjalnie mogą one wpłynąć na działanie aplikacji i coś zepsuć, co jest krytyczne. Do zarządzania wydaniami używamy Bamboo, z którego za pomocą API uzyskujemy dane i możemy zobaczyć, jakie wydania w jakich systemach informacyjnych miały miejsce i ich status. I co najważniejsze — o której godzinie. Oznaczenia wydania nakładamy na główne krytyczne metryki, co wizualnie stanowi znaczący sygnał w przypadku problemów.
W ten sposób możemy zobaczyć korelację między nowymi wydaniami a pojawiającymi się problemami. Główna idea polega na tym, aby rozumieć, jak działa system na wszystkich poziomach, szybko lokalizować problem i równie szybko go naprawić. Często bowiem najwięcej czasu zajmuje nie rozwiązanie problemu, a znalezienie przyczyny.
W tej dziedzinie chcemy w przyszłości skupić się na proaktywności. Idealnie byłoby z wyprzedzeniem dowiadywać się o nadchodzących problemach, a nie post factum, aby móc im zapobiegać, a nie je rozwiązywać. Czasami zdarzają się fałszywe alarmy systemu monitorowania, zarówno z powodu błędów ludzkich, jak i zmian w aplikacji. Pracujemy nad tym, usprawniamy system i staramy się przed wszelkimi manipulacjami w systemie monitorowania ostrzegać użytkowników, którzy pracują z nami, lub przeprowadzać te działania w oknie technicznym.
System został uruchomiony i działa pomyślnie od początku wiosny… i pokazuje całkiem realne zyski. Oczywiście, to nie jest jego ostateczna wersja, zamierzamy wprowadzić jeszcze wiele przydatnych funkcji. Ale już teraz, przy tak dużej liczbie integracji i aplikacji, bez automatyzacji monitoringu naprawdę się nie obędzie.
Jeśli również monitorujesz duże projekty z poważną ilością integracji — napisz w komentarzach, jaką srebrną kulę znalazłeś do tego.
Źródło: habr.com
