O stworzeniu systemu monitorowania myśleliśmy już na etapie tworzenia zespołów produktowych. Stało się jasne, że nasza działalność – eksploatacja – nie należy do tych zespołów. Dlaczego?
Faktem jest, że wszystkie nasze zespoły zbudowane są wokół indywidualnych systemów informatycznych, mikroserwisów i frontów, więc zespoły nie widzą ogólnej kondycji całego systemu jako całości. Na przykład mogą nie wiedzieć, jak niewielka część głębokiego backendu wpływa na frontend. Ich zakres zainteresowań ogranicza się do systemów, z którymi ich system jest zintegrowany. Jeśli zespół i jego serwis A nie mają prawie żadnego związku z serwisem B, to taki serwis jest dla zespołu prawie niewidoczny.
Nasz zespół z kolei pracuje z systemami, które są ze sobą bardzo silnie zintegrowane: istnieje między nimi wiele połączeń, jest to bardzo duża infrastruktura. A działanie sklepu internetowego zależy od wszystkich tych systemów (których notabene mamy ogromną liczbę).
Okazuje się więc, że nasz dział nie należy do żadnego zespołu, ale jest położony nieco z boku. W całej tej historii naszym zadaniem jest kompleksowe zrozumienie działania systemów informatycznych, ich funkcjonalności, integracji, oprogramowania, sieci, sprzętu i tego, jak to wszystko jest ze sobą powiązane.
Platforma, na której działają nasze sklepy internetowe wygląda następująco:
- z przodu
- środkowe Biuro
- back office
Niezależnie od tego, jak bardzo byśmy tego chcieli, nie zdarza się, aby wszystkie systemy działały sprawnie i bezbłędnie. Rzecz znowu w ilości systemów i integracji – przy czymś takim jak nasz pewne incydenty są nieuniknione, pomimo jakości testów. Co więcej, zarówno w ramach odrębnego systemu, jak i pod kątem ich integracji. A trzeba kompleksowo monitorować stan całej platformy, a nie tylko jej pojedynczej części.
W idealnym przypadku monitorowanie stanu całej platformy powinno być zautomatyzowane. Doszliśmy do monitorowania jako nieuniknionej części tego procesu. Początkowo budowany był tylko dla części frontowej, natomiast specjaliści sieciowi, administratorzy oprogramowania i sprzętu mieli i nadal mają własne systemy monitorowania warstwa po warstwie. Wszystkie te osoby śledziły monitoring tylko na swoim poziomie, nikt też nie miał pełnego zrozumienia.
Na przykład, jeśli maszyna wirtualna ulegnie awarii, w większości przypadków wie o tym tylko administrator odpowiedzialny za sprzęt i maszynę wirtualną. W takich przypadkach zespół pierwszej linii widział sam fakt awarii aplikacji, ale nie posiadał danych o awarii maszyny wirtualnej. Administrator może wiedzieć, kim jest klient i mieć ogólne pojęcie o tym, co aktualnie działa na tej maszynie wirtualnej, pod warunkiem, że jest to jakiś duży projekt. Najprawdopodobniej nie ma pojęcia o najmłodszych. W każdym razie administrator musi udać się do właściciela i zapytać, co było na tym komputerze, co należy przywrócić, a co należy zmienić. A jeśli zepsuło się coś naprawdę poważnego, zaczęli kręcić się w kółko – bo nikt nie widział systemu jako całości.
Ostatecznie tak odmienne historie wpływają na cały frontend, użytkowników i naszą podstawową funkcję biznesową – sprzedaż online. Ponieważ nie jesteśmy częścią zespołu, ale zajmujemy się obsługą wszystkich aplikacji e-commerce w ramach sklepu internetowego, podjęliśmy się zadania stworzenia kompleksowego systemu monitorowania platformy e-commerce.
Struktura systemu i stos
Zaczęliśmy od zidentyfikowania kilku warstw monitorowania naszych systemów, w ramach których musielibyśmy zbierać metryki. I trzeba było to wszystko połączyć, co zrobiliśmy na pierwszym etapie. Teraz na tym etapie finalizujemy gromadzenie najwyższej jakości metryk we wszystkich naszych warstwach, aby zbudować korelację i zrozumieć, w jaki sposób systemy wpływają na siebie nawzajem.
Brak kompleksowego monitoringu na początkowych etapach uruchomienia aplikacji (od kiedy zaczęliśmy ją budować, gdy większość systemów była w fazie produkcyjnej) doprowadził do tego, że mieliśmy znaczny dług techniczny, aby założyć monitoring całej platformy. Nie mogliśmy sobie pozwolić na skupienie się na skonfigurowaniu monitoringu dla jednego IS i szczegółowym opracowaniu monitoringu dla niego, gdyż pozostałe systemy pozostałyby przez jakiś czas bez monitoringu. Aby rozwiązać ten problem, zidentyfikowaliśmy listę najbardziej niezbędnych wskaźników do oceny stanu systemu informacyjnego według warstw i zaczęliśmy ją wdrażać.
Dlatego postanowili zjeść słonia w częściach.
Nasz system składa się z:
- sprzęt komputerowy;
- system operacyjny;
- oprogramowanie;
- Części interfejsu użytkownika w aplikacji monitorującej;
- wskaźniki biznesowe;
- aplikacje integracyjne;
- bezpieczeństwo informacji;
- sieci;
- równoważenie ruchu.
W centrum tego systemu znajduje się samo monitorowanie. Aby ogólnie zrozumieć stan całego systemu, trzeba wiedzieć, co dzieje się z aplikacjami na wszystkich tych warstwach i w całym zestawie aplikacji.
A więc o stosie.
Korzystamy z oprogramowania typu open source. W centrum mamy Zabbix, którego używamy przede wszystkim jako systemu ostrzegania. Każdy wie, że idealnie nadaje się do monitorowania infrastruktury. Co to znaczy? Dokładnie te wskaźniki niskiego poziomu, które posiada każda firma posiadająca własne centrum danych (a Sportmaster ma własne centra danych) – temperatura serwera, stan pamięci, raid, wskaźniki urządzeń sieciowych.
Zintegrowaliśmy Zabbix z komunikatorem Telegram i Microsoft Teams, które są aktywnie wykorzystywane w zespołach. Zabbix obejmuje warstwę rzeczywistą sieci, sprzętu i części oprogramowania, ale nie jest to panaceum. Wzbogacamy te dane z niektórych innych usług. Przykładowo na poziomie sprzętowym łączymy się bezpośrednio poprzez API z naszym systemem wirtualizacji i zbieramy dane.
Co jeszcze. Oprócz Zabbix korzystamy z Prometheusa, który pozwala nam monitorować metryki w aplikacji działającej w środowisku dynamicznym. Oznacza to, że możemy odbierać metryki aplikacji za pośrednictwem punktu końcowego HTTP i nie martwić się, które metryki do niego załadować, a które nie. Na podstawie tych danych można opracować zapytania analityczne.
Źródła danych dla pozostałych warstw, np. metryk biznesowych, podzielone są na trzy komponenty.
Po pierwsze są to zewnętrzne systemy biznesowe, Google Analytics, zbieramy metryki z logów. Pozyskujemy od nich dane o aktywnych użytkownikach, konwersjach i wszystkim innym, co jest związane z biznesem. Po drugie, jest to system monitorowania interfejsu użytkownika. Należy to opisać bardziej szczegółowo.
Dawno, dawno temu zaczynaliśmy od testów ręcznych, które przekształciły się w automatyczne testy funkcjonalności i integracji. Na tej podstawie zrobiliśmy monitorowanie, pozostawiając tylko główną funkcjonalność i polegając na znacznikach, które są tak stabilne, jak to możliwe i nie zmieniają się często w czasie.
Nowa struktura zespołu oznacza, że wszystkie działania związane z aplikacjami są ograniczone do zespołów zajmujących się produktami, dlatego przestaliśmy przeprowadzać wyłącznie testy. Zamiast tego zrobiliśmy monitorowanie UI z testów, napisanych w Javie, Selenium i Jenkins (wykorzystywanych jako system do uruchamiania i generowania raportów).
Mieliśmy wiele testów, ale ostatecznie zdecydowaliśmy się pójść na główną, metrykę na najwyższym poziomie. A jeśli będziemy mieli dużo konkretnych testów, trudno będzie utrzymać aktualność danych. Każde kolejne wydanie znacząco zepsuje cały system, a my jedynie to naprawimy. Dlatego skupiliśmy się na bardzo fundamentalnych rzeczach, które rzadko się zmieniają i jedynie je monitorujemy.
Wreszcie, po trzecie, źródłem danych jest scentralizowany system rejestrowania. Do logów używamy Elastic Stack, a następnie możemy pobrać te dane do naszego systemu monitorowania w celu uzyskania wskaźników biznesowych. Oprócz tego posiadamy własną usługę Monitoring API napisaną w Pythonie, która odpytuje dowolne usługi poprzez API i zbiera z nich dane do Zabbix.
Kolejnym niezbędnym atrybutem monitoringu jest wizualizacja. Nasz bazuje na Grafanie. Wyróżnia się spośród innych systemów wizualizacji tym, że pozwala na wizualizację wskaźników z różnych źródeł danych na dashboardzie. Możemy zbierać metryki najwyższego poziomu dla sklepu internetowego, na przykład liczbę zamówień złożonych w ciągu ostatniej godziny z DBMS, metryki wydajności systemu operacyjnego, na którym działa ten sklep internetowy, z Zabbix oraz metryki instancji tej aplikacji od Prometeusza. A wszystko to będzie na jednym dashboardzie. Przejrzyste i dostępne.
Przypomnę jeszcze o bezpieczeństwie – obecnie finalizujemy system, który później zintegrujemy z globalnym systemem monitoringu. Moim zdaniem główne problemy, przed którymi stoi e-commerce w obszarze bezpieczeństwa informacji, są związane z botami, parserami i brutalną siłą. Musimy na to zwracać uwagę, ponieważ wszystko to może mieć krytyczny wpływ zarówno na działanie naszych aplikacji, jak i na naszą reputację z biznesowego punktu widzenia. I wybranym stosem z powodzeniem realizujemy te zadania.
Kolejną ważną kwestią jest to, że warstwę aplikacji montuje Prometheus. On sam jest również zintegrowany z Zabbixem. Mamy także sitespeed, usługę, która pozwala nam przeglądać parametry, takie jak prędkość ładowania naszej strony, wąskie gardła, renderowanie strony, ładowanie skryptów itp., Jest również zintegrowana z API. Zatem nasze metryki są gromadzone w Zabbix i odpowiednio stamtąd również wysyłamy powiadomienia. Wszystkie alerty są obecnie wysyłane na główne metody wysyłki (na razie jest to e-mail i telegram, od niedawna podłączony jest także MS Teams). W planach jest unowocześnienie alertowania do takiego stanu, aby inteligentne boty działały jako usługa i dostarczały informacje monitorujące wszystkim zainteresowanym zespołom produktowym.
Dla nas metryki są ważne nie tylko dla poszczególnych systemów informatycznych, ale także ogólne metryki dla całej infrastruktury, z której korzystają aplikacje: klastry serwerów fizycznych, na których działają maszyny wirtualne, równoważenie ruchu, równoważenie obciążenia sieciowego, sama sieć, wykorzystanie kanałów komunikacyjnych . Plus metryki za własne data center (mamy ich kilka i infrastruktura jest dość duża).
Zaletą naszego systemu monitorowania jest to, że za jego pomocą widzimy stan zdrowia wszystkich systemów i możemy ocenić ich wpływ na siebie nawzajem oraz na współdzielone zasoby. Ostatecznie pozwala nam to zaangażować się w planowanie zasobów, co jest również naszym obowiązkiem. Zarządzamy zasobami serwerowymi - pulą w ramach e-commerce, uruchamiamy i wycofujemy nowy sprzęt, dokupujemy dodatkowy nowy sprzęt, przeprowadzamy audyt wykorzystania zasobów itp. Co roku zespoły planują nowe projekty, rozwijają swoje systemy i ważne jest dla nas zapewnienie im zasobów.
Za pomocą wskaźników widzimy trend zużycia zasobów przez nasze systemy informacyjne. I na ich podstawie możemy coś zaplanować. Na poziomie wirtualizacji zbieramy dane i przeglądamy informację o dostępnej ilości zasobów według centrum danych. Już wewnątrz centrum danych można zobaczyć recykling, faktyczną dystrybucję i zużycie zasobów. Co więcej, zarówno z serwerami samodzielnymi, jak i maszynami wirtualnymi, jak i klastrami serwerów fizycznych, na których prężnie kręcą się wszystkie te maszyny wirtualne.
Perspektywy
Mamy już gotowy rdzeń systemu jako całości, ale nadal pozostaje wiele rzeczy, nad którymi należy popracować. Jest to co najmniej warstwa bezpieczeństwa informacji, ale ważne jest też dotarcie do sieci, opracowanie alertów i rozwiązanie problemu korelacji. Mamy wiele warstw i systemów, a na każdej warstwie znajduje się znacznie więcej wskaźników. Okazuje się, że jest to matrioszka w stopniu matrioszki.
Naszym zadaniem jest docelowo dokonać właściwych alertów. Na przykład, jeśli był problem ze sprzętem, to znowu z maszyną wirtualną, i była tam ważna aplikacja, a usługa nie została w żaden sposób zarchiwizowana. Dowiadujemy się, że maszyna wirtualna padła. Wtedy wskaźniki biznesowe powiadomią Cię: użytkownicy gdzieś zniknęli, nie ma konwersji, interfejs użytkownika w interfejsie jest niedostępny, oprogramowanie i usługi również padły.
W tej sytuacji będziemy otrzymywać spam z alertów, a to już nie mieści się w formacie prawidłowego systemu monitorowania. Powstaje pytanie o korelację. Dlatego w idealnym przypadku nasz system monitorowania powinien powiedzieć: „Chłopaki, wasza fizyczna maszyna padła, a wraz z nią ta aplikacja i te wskaźniki” za pomocą jednego alertu, zamiast wściekle bombardować nas setką alertów. Powinien zgłosić najważniejsze - przyczynę, która pomaga szybko wyeliminować problem ze względu na jego lokalizację.
Nasz system powiadomień i przetwarzania alertów opiera się na całodobowej infolinii. Wszystkie alerty, które są uważane za obowiązkowe i znajdują się na liście kontrolnej, są tam wysyłane. Każdy alert musi mieć opis: co się wydarzyło, co to właściwie oznacza, na co wpływa. A także link do dashboardu i instrukcji co zrobić w tym przypadku.
To wszystko dotyczy wymagań dotyczących budowania alertu. Wtedy sytuacja może rozwinąć się w dwojaki sposób – albo jest problem i trzeba go rozwiązać, albo nastąpiła awaria w systemie monitorowania. Ale w każdym razie musisz iść i to rozgryźć.
Średnio otrzymujemy obecnie około stu alertów dziennie, biorąc pod uwagę fakt, że korelacja alertów nie została jeszcze odpowiednio skonfigurowana. A jeśli musimy wykonać prace techniczne i na siłę coś wyłączymy, ich liczba znacznie wzrasta.
Oprócz monitorowania systemów, które obsługujemy i zbierania wskaźników, które uważamy za ważne z naszej strony, system monitorowania pozwala nam zbierać dane dla zespołów produktowych. Mogą wpływać na skład wskaźników w monitorowanych przez nas systemach informatycznych.
Nasz kolega może przyjść i poprosić o dodanie jakiegoś miernika, który będzie przydatny zarówno dla nas, jak i zespołu. Lub na przykład zespół może nie mieć wystarczającej liczby podstawowych wskaźników, którymi dysponujemy, i musi śledzić kilka konkretnych. W Grafanie tworzymy przestrzeń dla każdego zespołu i nadajemy uprawnienia administratora. Także jeśli zespół potrzebuje dashboardów, ale sam nie potrafi/nie wie jak to zrobić, pomagamy.
Ponieważ jesteśmy poza procesem tworzenia wartości zespołu, ich wydań i planowania, stopniowo dochodzimy do wniosku, że wydania wszystkich systemów przebiegają płynnie i można je wdrażać codziennie bez koordynacji z nami. Monitorowanie tych wydań jest dla nas ważne, ponieważ mogą one potencjalnie wpłynąć na działanie aplikacji i coś zepsuć, a to ma kluczowe znaczenie. Do zarządzania wydaniami używamy Bamboo, skąd otrzymujemy dane poprzez API i możemy zobaczyć, które wydania zostały wydane w jakich systemach informatycznych i ich status. A najważniejsze jest to, o której godzinie. Nakładamy znaczniki wydania na główne krytyczne wskaźniki, co wizualnie jest bardzo orientacyjne w przypadku problemów.
W ten sposób możemy zobaczyć korelację między nowościami a pojawiającymi się problemami. Główną ideą jest zrozumienie, jak system działa na wszystkich warstwach, szybkie zlokalizowanie problemu i równie szybkie jego naprawienie. Przecież często zdarza się, że najwięcej czasu zajmuje nie rozwiązanie problemu, ale szukanie przyczyny.
I w tym obszarze w przyszłości chcemy postawić na proaktywność. Idealnie byłoby, gdybym wiedział o zbliżającym się problemie z wyprzedzeniem, a nie po fakcie, aby móc mu zapobiec, a nie go rozwiązać. Czasami zdarzają się fałszywe alarmy systemu monitorowania, zarówno z powodu błędu ludzkiego, jak i ze względu na zmiany w aplikacji.I pracujemy nad tym, debugujemy to i staramy się ostrzegać o tym użytkowników, którzy go u nas używają, przed jakąkolwiek manipulacją systemem monitorowania lub wykonaj te czynności w oknie technicznym.
Tak więc system został uruchomiony i od początku wiosny działa pomyślnie... i wykazuje bardzo realne zyski. Nie jest to oczywiście jego ostateczna wersja, będziemy wprowadzać o wiele więcej przydatnych funkcji. Jednak obecnie, przy tak dużej liczbie integracji i aplikacji, automatyzacja monitorowania jest naprawdę nieunikniona.
Jeśli monitorujesz także duże projekty ze znaczną liczbą integracji, napisz w komentarzach, jaki złoty środek znalazłeś na ten temat.
Źródło: www.habr.com