SRE (Site Reliability Engineering) to podejście do udostępniania projektów internetowych. Jest uważany za ramy dla DevOps i mówi, jak odnieść sukces w stosowaniu praktyk DevOps. Ten artykuł jest tłumaczony książki od Google'a. Tłumaczenie to przygotowałem sam i oparłem się na własnym doświadczeniu w zrozumieniu procesów monitoringu. W kanale telegramu и Zamieściłem również link do tłumaczenia rozdziału 4 tej samej książki na temat celów dotyczących poziomu usług.
Tłumaczenie przez kota. Miłego czytania!
Zespoły Google SRE dysponują podstawowymi zasadami i sprawdzonymi metodami tworzenia skutecznych systemów monitorowania i powiadomień. Ten rozdział zawiera zalecenia dotyczące problemów, jakie może napotkać odwiedzający stronę internetową oraz sposobów rozwiązywania problemów utrudniających wyświetlanie stron internetowych.
określić
Nie ma jednego słownictwa używanego do omawiania tematów związanych z monitoringiem. Nawet w Google poniższe terminy nie są powszechnie używane, ale wymienimy najczęstsze interpretacje.
Monitorowanie
Zbieranie, przetwarzanie, agregacja i wyświetlanie w czasie rzeczywistym danych ilościowych o systemie: liczba żądań i rodzaje żądań, liczba i rodzaje błędów, czas przetwarzania żądania i czas pracy serwera.
Monitorowanie białej skrzynki
Monitorowanie na podstawie metryk wyświetlanych przez elementy wewnętrzne systemu, w tym dzienników, metryk profilowania maszyny JVM lub procedury obsługi HTTP, które generują statystyki wewnętrzne.
Monitorowanie czarnej skrzynki
Testowanie zachowania aplikacji z punktu widzenia użytkownika.
Pulpit nawigacyjny (pulpity nawigacyjne)
Interfejs (zwykle interfejs internetowy), który zapewnia przegląd kluczowych wskaźników kondycji usług. Dashboard może mieć filtry, możliwość wyboru, które metryki mają być wyświetlane, itp. Interfejs ma za zadanie identyfikować najważniejsze metryki dla użytkowników. Pulpit nawigacyjny może również wyświetlać informacje dla personelu wsparcia technicznego: kolejkę zgłoszeń, listę błędów o wysokim priorytecie, przydzielonego inżyniera do danego obszaru odpowiedzialności.
Alert (powiadomienie)
Powiadomienia przeznaczone do otrzymywania przez osobę pocztą elektroniczną lub w inny sposób, które mogą zostać uruchomione w wyniku błędów lub zwiększenia kolejki żądań. Powiadomienia są podzielone na kategorie: bilety, alerty e-mail i wiadomości komunikatora.
Pierwotna przyczyna (pierwotna przyczyna)
Wada oprogramowania lub błąd ludzki, który po naprawieniu nie powinien już się powtórzyć. Problem może mieć kilka głównych przyczyn: niedostateczna automatyzacja procesów, defekt oprogramowania, niedostateczne przestudiowanie logiki aplikacji. Każdy z tych czynników może być pierwotną przyczyną i każdy z nich musi zostać wyeliminowany.
Węzeł i maszyna (węzeł i maszyna)
Wymienne terminy odnoszące się do pojedynczego wystąpienia działającej aplikacji na serwerze fizycznym, maszynie wirtualnej lub kontenerze. Na jednej maszynie może znajdować się kilka usług. Usługi mogą być:
- powiązane ze sobą: na przykład serwer pamięci podręcznej i serwer WWW;
- niepowiązane usługi na tym samym sprzęcie: na przykład repozytorium kodu i kreator systemu konfiguracji, np lub .
Naciskać
Wszelkie zmiany w konfiguracji oprogramowania.
Dlaczego monitorowanie jest potrzebne
Istnieje kilka powodów, dla których aplikacje powinny być monitorowane:
Analiza długoterminowych trendów
Jak duża jest baza danych i jak szybko rośnie? Jak zmienia się dzienna liczba użytkowników?
Porównanie wydajności
Czy zapytania są szybsze w Acme Bucket of Bytes 2.72 niż Ajax DB 3.14? O ile lepiej buforowane są żądania po pojawieniu się dodatkowego węzła? Czy strona działa wolniej niż w zeszłym tygodniu?
Alerty (powiadomienia)
Coś się zepsuło i ktoś to musi naprawić. Albo coś się zaraz zepsuje i ktoś będzie musiał to szybko sprawdzić.
Tworzenie dashboardów
Pulpity nawigacyjne powinny odpowiadać na podstawowe pytania i zawierać coś z - opóźnienia (latencja), ruch (ruch), błędy (błędy) i wartość obciążenia (nasycenie).
Przeprowadzenie analizy retrospektywnej (debugowanie)
Wzrosło opóźnienie przetwarzania żądania, co jeszcze wydarzyło się mniej więcej w tym samym czasie?
Systemy monitorowania są przydatne jako źródło danych dla systemów Business Intelligence oraz ułatwiają analizę incydentów bezpieczeństwa. Ponieważ ta książka koncentruje się na obszarach inżynierii, w których SRE mają doświadczenie, nie będziemy omawiać tutaj technik monitorowania.
Monitorowanie i alerty pozwalają systemowi stwierdzić, kiedy się zepsuł lub wkrótce się zepsuje. Kiedy system nie może się automatycznie naprawić, chcemy, aby człowiek przeanalizował alert, ustalił, czy problem nadal występuje, naprawił go i ustalił jego pierwotną przyczynę. Jeśli nie przeprowadzasz audytu komponentów systemu, nigdy nie otrzymasz alertu tylko dlatego, że „coś wydaje się trochę dziwne”.
Wczytywanie alertów ludzkich jest dość kosztownym sposobem wykorzystania czasu pracownika. Jeśli pracownik pracuje, alert przerywa przepływ pracy. Jeśli pracownik jest w domu, alert przerywa czas osobisty i ewentualnie sen. Gdy alerty pojawiają się zbyt często, pracownicy przeglądają, opóźniają lub ignorują przychodzące alerty. Od czasu do czasu ignorują prawdziwy alarm, który jest maskowany przez zdarzenia akustyczne. Przerwy w świadczeniu usług mogą trwać długo, ponieważ zakłócenia uniemożliwiają szybką diagnozę i rozwiązanie problemu. Skuteczne systemy nagłośnieniowe mają dobry stosunek sygnału do szumu.
Określenie uzasadnionych oczekiwań wobec systemu monitoringu
Konfigurowanie monitorowania dla złożonej aplikacji jest samo w sobie złożonym zadaniem inżynierskim. Nawet przy znacznej infrastrukturze narzędzi do gromadzenia, wyświetlania i ostrzegania, zespół Google SRE składający się z 10-12 członków zazwyczaj składa się z jednej lub dwóch osób, których głównym celem jest budowanie i utrzymywanie systemów monitorowania. Liczba ta zmalała z czasem, ponieważ uogólniliśmy i scentralizowaliśmy infrastrukturę monitorowania, ale każdy zespół SRE zazwyczaj ma co najmniej jednego członka personelu zajmującego się wyłącznie monitorowaniem. Trzeba powiedzieć, że chociaż oglądanie pulpitów nawigacyjnych systemu monitorowania jest dość interesujące, zespoły SRE ostrożnie unikają sytuacji, które wymagają, aby ktoś patrzył na ekran w celu monitorowania problemów.
Ogólnie rzecz biorąc, Google przeszło na proste i szybkie systemy monitorowania z optymalnymi narzędziami do analizy po fakcie. Unikamy „magicznych” systemów, które próbują przewidzieć progi lub automatycznie odkryć pierwotną przyczynę. Jedynym kontrprzykładem są czujniki, które wykrywają niezamierzone treści w żądaniach użytkowników końcowych; dopóki czujniki te pozostają proste, mogą szybko wykrywać przyczyny poważnych anomalii. Inne formaty wykorzystania danych monitorowania, takie jak planowanie przepustowości lub prognozowanie ruchu, stanowią większe wyzwanie. Obserwacja przez bardzo długi czas (miesiące lub lata) przy niskiej częstotliwości próbkowania (godziny lub dni) ujawni długoterminowy trend.
Zespół Google SRE pracował z różnym powodzeniem nad złożonymi hierarchiami zależności. Rzadko używamy reguł, takich jak „jeśli dowiem się, że baza danych stała się wolna, otrzymuję alert o spowolnieniu bazy danych, w przeciwnym razie otrzymuję alert o powolnej stronie”. Reguły oparte na zależnościach zwykle odnoszą się do niezmiennych części naszego systemu, takich jak system filtrowania ruchu użytkowników do centrum danych. Na przykład „jeśli skonfigurowano filtrowanie ruchu w centrum danych, nie powiadamiaj mnie o opóźnieniach w przetwarzaniu żądań użytkowników” to jedna z powszechnych reguł dla alertów w centrum danych. Niewiele zespołów w Google obsługuje złożone hierarchie zależności, ponieważ nasza infrastruktura ma stałe tempo ciągłej refaktoryzacji.
Niektóre z pomysłów przedstawionych w tym rozdziale nadal są aktualne: zawsze istnieje sposób na szybsze przejście od symptomu do pierwotnej przyczyny, zwłaszcza w ciągle zmieniających się systemach. Dlatego chociaż w tym rozdziale opisano niektóre cele systemów monitorowania i sposoby ich osiągnięcia, ważne jest, aby systemy monitorowania były proste i zrozumiałe dla wszystkich członków zespołu.
Podobnie, aby utrzymać niski poziom hałasu i wysoki poziom sygnału, podejścia do monitorowania obiektów, które są ostrzegane, muszą być bardzo proste i niezawodne. Reguły generujące ostrzeżenia dla ludzi powinny być łatwe do zrozumienia i przedstawiać jasny problem.
Objawy kontra przyczyny
Twój system monitoringu powinien odpowiedzieć na dwa pytania: „co jest zepsute” i „dlaczego jest zepsute”.
„Co się zepsuło” odnosi się do symptomu, a „dlaczego się zepsuło” odnosi się do przyczyny. Poniższa tabela pokazuje przykłady takich linków.
Objaw
powód
Odbieranie błędu HTTP 500 lub 404
Serwery baz danych odrzucają połączenia
Powolne odpowiedzi serwera
Wysokie obciążenie procesora lub uszkodzony kabel Ethernet
Użytkownicy na Antarktydzie nie otrzymują GIF-ów z kotami
Twój CDN nienawidzi naukowców i kotów, więc niektóre adresy IP są na czarnej liście
Prywatne treści są dostępne wszędzie
Wprowadzenie nowej wersji oprogramowania sprawiło, że zapora sieciowa zapomniała o wszystkich listach ACL i wpuściła wszystkich
„Co” i „dlaczego” to jedne z najważniejszych elementów składowych do stworzenia dobrego systemu monitoringu z maksymalnym sygnałem i minimalnym szumem.
Czarna skrzynka kontra biała skrzynka
Łączymy szeroko zakrojone monitorowanie białoskrzynkowe ze skromnym monitorowaniem czarnoskrzynkowym w celu uzyskania krytycznych wskaźników. Najłatwiejszym sposobem porównania Black-box z White-box jest to, że Black-box koncentruje się na objawach i jest reaktywnym, a nie proaktywnym monitorowaniem: „system nie działa teraz poprawnie”. White-box zależy od wewnętrznych możliwości sprawdzania systemów: dzienników zdarzeń lub serwerów WWW. W ten sposób White-box pozwala wykrywać nadchodzące problemy, awarie, które wyglądają jak retransmisja żądania itp.
Należy pamiętać, że w systemie wielowarstwowym objaw w obszarze odpowiedzialności jednego inżyniera jest objawem w obszarze odpowiedzialności innego inżyniera. Na przykład wydajność bazy danych spadła. Powolne odczyty bazy danych są symptomem wykrywającego je SRE bazy danych. Jednak w przypadku frontowego SRE obserwującego wolno działającą witrynę internetową przyczyną tego samego powolnego odczytu bazy danych jest to, że baza danych jest wolna. Dlatego monitorowanie białoskrzynkowe czasami koncentruje się na objawach, a czasami na przyczynach, w zależności od tego, jak rozległe jest.
Podczas zbierania danych telemetrycznych do debugowania wymagane jest monitorowanie białej skrzynki. Jeśli serwery WWW wolno odpowiadają na zapytania do bazy danych, należy wiedzieć, jak szybko serwer WWW komunikuje się z bazą danych i jak szybko odpowiada. W przeciwnym razie nie będziesz w stanie odróżnić powolnego serwera bazy danych od problemu z siecią między serwerem WWW a bazą danych.
Monitorowanie czarnej skrzynki ma kluczową zaletę podczas wysyłania alertów: wysyłasz powiadomienie do odbiorcy, gdy problem spowodował już rzeczywiste objawy. Z drugiej strony, dla problemu czarnej skrzynki, który jeszcze się nie pojawił, ale nadchodzi, monitorowanie jest bezużyteczne.
Cztery złote sygnały
Cztery złote sygnały monitorowania to opóźnienie, ruch, błędy i nasycenie. Jeśli możesz zmierzyć tylko cztery wskaźniki systemu użytkownika, skup się na tych czterech.
Opóźnienie
Czas potrzebny do przetworzenia żądania. Ważne jest, aby rozróżnić opóźnienie pomyślnych i nieudanych żądań. Na przykład błąd HTTP 500 spowodowany utratą połączenia z bazą danych lub innym backendem można bardzo szybko zdiagnozować, jednak błąd HTTP 500 może wskazywać na nieudane żądanie. Znalezienie wpływu błędu 500 na ogólne opóźnienie może prowadzić do błędnych wniosków. Z drugiej strony powolny błąd to nawet szybki błąd! Dlatego ważne jest, aby śledzić opóźnienie błędów, a nie tylko odfiltrowywać błędy.
ruch
Liczba żądań kierowanych do Twojego systemu, mierzona za pomocą ogólnych wskaźników systemowych. W przypadku usługi internetowej pomiar ten zwykle reprezentuje liczbę żądań HTTP na sekundę podzieloną przez charakter żądań (na przykład zawartość statyczna lub dynamiczna). W przypadku systemu przesyłania strumieniowego audio pomiar ten może być wyśrodkowany na szybkości we/wy sieci lub liczbie jednoczesnych sesji. W przypadku systemu przechowywania klucz-wartość pomiarem mogą być transakcje lub wyszukiwania na sekundę.
Błędy
Jest to odsetek nieudanych żądań jawnie (na przykład HTTP 500), niejawnie (na przykład HTTP 200, ale w połączeniu ze złą treścią) lub według zasad (na przykład „Jeśli przechwycisz odpowiedź w ciągu jednej sekundy, każda jedna sekunda to błąd”). Jeśli nie ma wystarczającej liczby kodów odpowiedzi HTTP, aby wyrazić wszystkie warunki awarii, do wykrycia częściowej awarii mogą być wymagane dodatkowe (wewnętrzne) protokoły. Monitorowanie wszystkich takich błędnych żądań może być pozbawione informacji, a kompleksowe testy systemu mogą pomóc wykryć, że przetwarzasz niewłaściwą treść.
Nasycenie
Metryka pokazuje, jak intensywnie korzystasz z usługi. Jest to środek monitorowania systemu, który identyfikuje zasoby, które są najbardziej ograniczone (na przykład w systemie z ograniczoną pamięcią pokazuje pamięć, w systemie z ograniczonymi wejściami/wyjściami pokazuje liczbę wejść/wyjść). Należy pamiętać, że wiele systemów ulega degradacji, zanim osiągną 100% wykorzystania, dlatego posiadanie docelowego wykorzystania jest niezbędne.
W złożonych systemach nasycenie można uzupełnić pomiarem obciążenia wyższego poziomu: czy Twoja usługa może prawidłowo obsłużyć podwójny ruch, obsłużyć tylko o 10% większy ruch lub obsłużyć jeszcze mniejszy ruch niż obecnie? W przypadku prostych usług, które nie mają parametrów zmieniających złożoność żądania (np. „Nie daj mi nic” lub „Potrzebuję unikalnej, monotonicznej liczby całkowitej”), które rzadko zmieniają konfigurację, wartość testu obciążenia statycznego może być odpowiednia. jak omówiono w poprzednim akapicie, większość usług powinna wykorzystywać sygnały pośrednie, takie jak wykorzystanie procesora lub przepustowość sieci, które mają znaną górną granicę. Rosnące opóźnienie jest często głównym wskaźnikiem nasycenia. Pomiar czasu odpowiedzi 99 percentyla w małym oknie (np. jedna minuta) może dać bardzo wczesny sygnał nasycenia.
Na koniec, nasycenie jest również związane z przewidywaniami zbliżającego się nasycenia, takimi jak: „Wygląda na to, że twoja baza danych zapełni twój dysk twardy w ciągu 4 godzin”.
Jeśli mierzysz wszystkie cztery złote sygnały i gdy pojawi się problem z jednym z mierników (lub w przypadku nasycenia prawie problem), powiadomisz tę osobę, Twoja usługa będzie mniej więcej objęta monitoringiem.
Martw się o ogon (lub oprzyrządowanie i wydajność)
Budując system monitorowania od podstaw, kuszące jest stworzenie systemu opartego na średnich: średnich opóźnieniach, średnim wykorzystaniu procesora węzła lub średnim zajętości bazy danych. Niebezpieczeństwo związane z dwoma ostatnimi przykładami jest oczywiste: procesory i bazy danych są utylizowane w bardzo nieprzewidywalny sposób. To samo dotyczy opóźnienia. Jeśli prowadzisz usługę internetową ze średnim opóźnieniem 100 ms przy 1000 żądań na sekundę, 1% żądań może zająć 5 sekund. Jeśli użytkownicy polegają na wielu takich usługach sieciowych, 99. percentyl pojedynczego zaplecza może łatwo stać się medianą czasu odpowiedzi interfejsu.
Najprostszym sposobem na rozróżnienie powolnej średniej i bardzo powolnego ogona żądań jest zebranie pomiarów żądań wyrażonych w statystykach (odpowiednim narzędziem do wyświetlania są histogramy), a nie rzeczywistych opóźnień: ile żądań obsłużyła usługa, która zajęła między 0 ms a 10 ms, między 10 ms a 30 ms, między 30 ms a 100 ms, między 100 ms a 300 ms itd. Rozszerzanie granic histogramu w przybliżeniu wykładniczo (o współczynnik około 3) jest często łatwym sposobem wizualizacji rozkładu zapytań.
Dobór odpowiedniej ziarnistości do pomiarów
Różne elementy systemu powinny być mierzone z różnymi poziomami szczegółowości. Na przykład:
- Obserwowanie wykorzystania procesora przez pewien okres czasu nie pokaże długich skoków, które skutkują dużymi opóźnieniami.
- Z drugiej strony w przypadku usługi sieciowej, której celem jest nie więcej niż 9 godzin przestojów rocznie (99,9% rocznej sprawności), sprawdzanie odpowiedzi HTTP 200 częściej niż raz lub dwa razy na minutę byłoby prawdopodobnie niepotrzebnie częste.
- Podobnie sprawdzanie wolnego miejsca na dysku twardym pod kątem dostępności na poziomie 99,9% częściej niż raz na 1-2 minuty jest prawdopodobnie niepotrzebne.
Uważaj na strukturę ziarnistości wymiarów. Współczynnik wykorzystania procesora wynoszący 1 na sekundę może dostarczyć interesujących danych, ale takie częste pomiary mogą być bardzo kosztowne w gromadzeniu, przechowywaniu i analizie. Jeśli cel monitorowania wymaga dużej szczegółowości i nie wymaga dużej szybkości reakcji, możesz obniżyć te koszty, konfigurując zbieranie metryk na serwerze, a następnie konfigurując system zewnętrzny do zbierania i agregowania tych metryk. Mógłbyś:
- Mierz użycie procesora co sekundę.
- Zmniejsz szczegóły do 5%.
- Agreguj dane co minutę.
Ta strategia pozwoli Ci zbierać bardzo szczegółowe dane bez wysokich kosztów ogólnych związanych z analizą i przechowywaniem.
Tak proste, jak to możliwe, ale nie łatwiejsze
Nakładanie na siebie różnych wymagań może prowadzić do powstania bardzo złożonego systemu monitorowania. Na przykład Twój system może zawierać następujące elementy komplikujące:
- Alerty według różnych progów opóźnienia żądań, w różnych percentylach, we wszystkich rodzajach różnych metryk.
- Pisanie dodatkowego kodu w celu wykrycia i zidentyfikowania możliwych przyczyn.
- Twórz powiązane pulpity nawigacyjne dla każdej z możliwych przyczyn problemów.
Źródła potencjalnych komplikacji nigdy się nie kończą. Podobnie jak wszystkie systemy oprogramowania, monitorowanie może stać się tak złożone, że staje się kruche, trudne do zmiany i utrzymania.
Dlatego zaprojektuj swój system monitoringu tak, aby maksymalnie go uprościć. Wybierając, co chcesz śledzić, pamiętaj o następujących kwestiach:
- Reguły, które najczęściej wychwytują prawdziwe incydenty, powinny być możliwie proste, przewidywalne i niezawodne.
- Należy usunąć konfigurację zbierania danych, agregacji i alertów, która jest wykonywana rzadko (na przykład rzadziej niż raz na kwartał w przypadku niektórych zespołów SRE).
- Metryki, które są zbierane, ale nie są wyświetlane w żadnym panelu podglądu ani używane przez żaden alert, są kandydatami do usunięcia.
W Google podstawowe gromadzenie i agregacja metryk w połączeniu z alertami i pulpitami nawigacyjnymi działa dobrze jako stosunkowo samodzielny system (system monitorowania Google jest w rzeczywistości podzielony na kilka podsystemów, ale zwykle ludzie są świadomi wszystkich aspektów tych podsystemów). Kuszące może być połączenie monitorowania z innymi metodami testowania złożonych systemów: szczegółowym profilowaniem systemu, debugowaniem procesów, śledzeniem szczegółów wyjątków lub awarii, testowaniem obciążenia, gromadzeniem i analizą dzienników lub inspekcją ruchu. Podczas gdy większość z tych rzeczy ma wspólne cechy z podstawowym monitorowaniem, pomieszanie ich spowoduje zbyt wiele wyników i stworzy złożony i kruchy system. Podobnie jak w przypadku wielu innych aspektów tworzenia oprogramowania, najlepszą strategią jest wspieranie różnych systemów za pomocą jasnych, prostych, luźno powiązanych punktów integracji (na przykład użycie internetowego interfejsu API do pobierania danych podsumowujących w formacie, który może pozostać niezmienny przez długi czas ).
Łączenie zasad razem
Zasady omówione w tym rozdziale można połączyć w filozofię monitorowania i ostrzegania, która jest popierana i stosowana przez zespoły Google SRE. Stosowanie się do tej filozofii monitorowania jest pożądane, stanowi dobry punkt wyjścia do tworzenia lub rewizji metodologii alertów i może pomóc w zadawaniu właściwych pytań operacjom niezależnie od wielkości organizacji lub złożoności usługi lub systemu.
Podczas tworzenia reguł monitorowania i alertów zadawanie następujących pytań może pomóc w uniknięciu fałszywych alarmów i niepotrzebnych alertów:
- Czy ta reguła wykrywa niewykrywalny stan systemu, który jest pilny, wzywa do działania i nieuchronnie wpływa na użytkownika?
- Czy mogę zignorować to ostrzeżenie, wiedząc, że jest łagodne? Kiedy i dlaczego mogę zignorować to ostrzeżenie i jak mogę uniknąć tego scenariusza?
- Czy ten alert oznacza, że ma to negatywny wpływ na użytkowników? Czy istnieją sytuacje, w których użytkownicy nie odczuwają negatywnego wpływu, na przykład z powodu filtrowania ruchu lub korzystania z systemów testowych, których alerty należy filtrować?
- Czy mogę podjąć działania w odpowiedzi na to ostrzeżenie? Czy te środki są pilne, czy mogą poczekać do rana? Czy automatyzacja działań jest bezpieczna? Czy to działanie będzie długoterminowym rozwiązaniem, czy krótkoterminowym obejściem?
- Niektóre osoby otrzymują wiele alertów dotyczących tego problemu, więc czy można zmniejszyć ich liczbę?
Te pytania odzwierciedlają fundamentalną filozofię dotyczącą alertów i systemów ostrzegania:
- Za każdym razem, gdy pojawia się alarm, muszę szybko reagować. Potrafię biec kilka razy dziennie, zanim się zmęczę.
- Każdy alert musi być aktualny.
- Każda reakcja na alert musi wymagać interwencji człowieka. Jeśli powiadomienie może zostać przetworzone automatycznie, nie powinno przyjść.
- Alerty powinny dotyczyć nowego problemu lub zdarzenia, które nie miało miejsca wcześniej.
Takie podejście zaciera pewne rozróżnienia: jeśli alert spełnia cztery poprzednie warunki, nie ma znaczenia, czy alert jest wysyłany z systemu monitorowania białej skrzynki, czy z czarnej skrzynki. Takie podejście wzmacnia również pewne różnice: lepiej jest poświęcić znacznie więcej wysiłku na identyfikację objawów niż na przyczyny; jeśli chodzi o przyczyny, musisz martwić się tylko przyczynami nieuniknionymi.
Monitorowanie długoterminowe
W dzisiejszych środowiskach produkcyjnych systemy monitorowania monitorują stale ewoluujący system produkcyjny ze zmieniającą się architekturą oprogramowania, charakterystyką obciążenia i docelowymi parametrami wydajności. Alerty, które obecnie trudno zautomatyzować, mogą stać się powszechne, być może nawet zasługujące na uwzględnienie. W tym momencie ktoś musi znaleźć i naprawić podstawowe przyczyny problemu; jeśli takie rozwiązanie nie jest możliwe, reakcja na alert wymaga pełnej automatyzacji.
Ważne jest, aby decyzje dotyczące monitorowania były podejmowane z myślą o długoterminowych celach. Każdy uruchomiony dziś alert odciąga człowieka od jutrzejszego ulepszania systemu, dlatego często występuje spadek dostępności lub wydajności systemu produkcyjnego na czas potrzebny do ulepszenia systemu monitorowania w dłuższej perspektywie. Przyjrzyjmy się dwóm przykładom ilustrującym to zjawisko.
Bigtable SRE: Opowieść o nadmiernej czujności
Wewnętrzna infrastruktura Google jest zazwyczaj udostępniana i mierzona pod względem poziomu usług (SLO). Lata temu SLO usługi Bigtable opierał się na średniej wydajności syntetycznej transakcji symulującej działającego klienta. Ze względu na problemy z Bigtable i niższymi poziomami stosu pamięci, średnia wydajność była napędzana przez „duży” ogon: najgorsze 5% zapytań było często znacznie wolniejszych niż pozostałe.
Powiadomienia e-mail były wysyłane, gdy zbliżał się próg SLO, a alerty komunikatora były wysyłane, gdy SLO został przekroczony. Oba rodzaje alertów były wysyłane dość często, co pochłaniało niedopuszczalną ilość czasu inżynierów: zespół spędził znaczną ilość czasu na analizowaniu alertów, aby znaleźć kilka, które były rzeczywiście istotne. Często pomijaliśmy problem, który faktycznie dotyczył użytkowników, ponieważ tylko kilka alertów dotyczyło tego konkretnego problemu. Wiele alertów nie było pilnych ze względu na zrozumiałe problemy z infrastrukturą i były obsługiwane w standardowy sposób lub nie były obsługiwane wcale.
Aby zaradzić tej sytuacji, zespół zastosował trzyetapowe podejście: ciężko pracując nad poprawą wydajności Bigtable, tymczasowo ustawiliśmy 75. percentyl opóźnienia odpowiedzi na zapytanie jako nasz docelowy docelowy poziom usług. Wyłączyliśmy również alerty e-mailowe, ponieważ było ich tak dużo, że nie można było tracić czasu na ich diagnozowanie.
Ta strategia pozwoliła nam odpocząć i zająć się naprawianiem długoterminowych problemów w Bigtable i niższych warstwach stosu pamięci, zamiast ciągłego naprawiania problemów taktycznych. Inżynierowie mogli właściwie wykonać zadanie, gdy nie byli cały czas bombardowani alertami. Ostatecznie chwilowe opóźnienie w przetwarzaniu alertów pozwoliło nam poprawić jakość obsługi.
Gmail: przewidywalne, algorytmiczne reakcje ludzi
Na samym początku Gmail był zbudowany na zmodyfikowanym systemie kontroli procesów Workqueue, który został stworzony do przetwarzania wsadowego fragmentów indeksu wyszukiwania procesów. Workqueue została dostosowana do długotrwałych procesów, a następnie zastosowana w Gmailu, ale niektóre błędy w nieprzejrzystym kodzie harmonogramu okazały się bardzo trudne do naprawienia.
W tamtym czasie monitorowanie Gmaila było zorganizowane w taki sposób, że alerty uruchamiały się, gdy poszczególne zadania zostały anulowane za pomocą Workqueue. Takie podejście nie było idealne, bo już wtedy Gmail wykonywał wiele tysięcy zadań, z których każde przydzielane było ułamkowi procenta naszych użytkowników. Dołożyliśmy wszelkich starań, aby użytkownicy Gmaila byli zadowoleni, ale obsługa tak wielu alertów nie wchodziła w rachubę.
Aby rozwiązać ten problem, Gmail SRE stworzył narzędzie pomagające jak najlepiej debugować program planujący, aby zminimalizować wpływ na użytkowników. Zespół przeprowadził kilka dyskusji na temat tego, czy po prostu zautomatyzować cały cykl od znalezienia problemu do jego naprawy, aż do znalezienia długoterminowego rozwiązania, ale niektórzy obawiali się, że takie rozwiązanie opóźni faktyczne rozwiązanie problemu.
Takie napięcie było powszechne w zespole i często odzwierciedlało brak zaufania do samodyscypliny: podczas gdy niektórzy członkowie zespołu chcą dać czas na właściwą naprawę, inni martwią się, że ostateczna naprawa zostanie zapomniana, a tymczasowa naprawa będzie trwała wiecznie. Ten problem zasługuje na uwagę, ponieważ zbyt łatwo jest naprawić problemy tymczasowo, zamiast dokonać trwałej naprawy. Menedżerowie i personel techniczny odgrywają kluczową rolę we wdrażaniu długoterminowych rozwiązań poprzez wspieranie i ustalanie priorytetów potencjalnie długoterminowych rozwiązań długoterminowych, nawet gdy początkowy ból ustąpi.
Regularne powtarzające się alerty i reakcje algorytmiczne powinny być sygnałem ostrzegawczym. Niechęć Twojego zespołu do automatyzacji tych alertów oznacza, że zespół nie ma pewności, że może ufać algorytmom. Jest to poważny problem, którym należy się zająć.
Długoterminowy
Wspólny temat łączy przykłady z Bigtable i Gmaila: rywalizacja między krótko- i długoterminową dostępnością. Często duży wysiłek może pomóc delikatnemu systemowi osiągnąć wysoką dostępność, ale ta ścieżka jest zwykle krótkotrwała, obarczona wypaleniem zespołu i zależnością od niewielkiej liczby członków tego samego bohaterskiego zespołu.
Kontrolowany, krótkotrwały spadek dostępności jest często bolesny, ale strategicznie ważny dla długoterminowej stabilności systemu. Ważne jest, aby nie rozważać każdego alertu z osobna, ale rozważyć, czy ogólna liczba alertów prowadzi do zdrowego, odpowiednio dostępnego systemu z realnym zespołem i korzystnymi prognozami. Analizujemy statystyki wskaźnika alertów (zwykle wyrażone jako incydenty na zmianę, gdzie incydent może składać się z wielu powiązanych incydentów) w kwartalnych raportach z kierownictwem, umożliwiając decydentom ciągłe przedstawianie obciążenia systemu alertów i ogólnego stanu zespołu.
wniosek
Ścieżka do zdrowego monitorowania i alertów jest prosta i jednoznaczna. Koncentruje się na objawach problemu, dla którego generowane są alerty, a monitorowanie przyczyny służy jako pomoc w debugowaniu problemów. Monitorowanie symptomów jest łatwiejsze, im wyżej znajdujesz się na stosie, który kontrolujesz, chociaż monitorowanie obciążenia bazy danych i wydajności powinno odbywać się bezpośrednio w samej bazie danych. Powiadomienia e-mail mają bardzo ograniczone zastosowanie i łatwo przeradzają się w szum; zamiast tego powinieneś użyć pulpitu nawigacyjnego, który monitoruje wszystkie bieżące problemy, które są powiadamiane przez e-mail. Pulpit nawigacyjny można również sparować z dziennikiem zdarzeń w celu analizy historycznych korelacji.
W dłuższej perspektywie należy osiągnąć udaną zmianę między ostrzeganiem o objawach a nieuchronnymi rzeczywistymi problemami oraz dostosować cele, aby zapewnić, że monitorowanie wspiera szybką diagnozę.
Dziękuję za przeczytanie tłumaczenia do końca. Subskrybuj mój kanał telegramu o monitorowaniu и .
Źródło: www.habr.com