Notatka. przeł.: Przedstawiamy Państwu szczegóły techniczne dotyczące przyczyn niedawnego przestoju w usłudze chmurowej prowadzonej przez twórców Grafany. To klasyczny przykład tego, jak nowa i z pozoru niezwykle przydatna funkcja mająca na celu poprawę jakości infrastruktury… może wyrządzić krzywdę, jeśli nie uwzględni się licznych niuansów jej zastosowania w realiach produkcyjnych. Świetnie, gdy pojawiają się takie materiały, które pozwalają uczyć się nie tylko na własnych błędach. Szczegóły znajdują się w tłumaczeniu tego tekstu od wiceprezesa ds. produktu z Grafana Labs.
W piątek 19 lipca usługa Hosted Prometheus w Grafana Cloud przestała działać na około 30 minut. Przepraszam wszystkich klientów dotkniętych awarią. Naszym zadaniem jest zapewnienie potrzebnych narzędzi monitorowania i rozumiemy, że ich brak może utrudnić Ci życie. Traktujemy to wydarzenie niezwykle poważnie. W tej notatce wyjaśniono, co się stało, jak zareagowaliśmy i co robimy, aby to się więcej nie powtórzyło.
prehistoria
Na czym opiera się usługa Grafana Cloud Hosted Prometheus — Projekt CNCF mający na celu stworzenie skalowalnej poziomo, wysokodostępnej usługi Prometheus dla wielu dzierżawców. Architektura Cortex składa się z zestawu pojedynczych mikrousług, z których każdy pełni swoją własną funkcję: replikację, przechowywanie, zapytania itp. Cortex jest w fazie aktywnego rozwoju i stale dodaje nowe funkcje i poprawia wydajność. Regularnie wdrażamy nowe wydania Cortex w klastrach, aby klienci mogli skorzystać z tych funkcji - na szczęście Cortex można aktualizować bez przestojów.
Aby aktualizacje przebiegały bezproblemowo, usługa Ingester Cortex wymaga dodatkowej repliki Ingester podczas procesu aktualizacji. (Notatka. przeł.: - podstawowy składnik kory mózgowej. Jego zadaniem jest zbieranie stałego strumienia próbek, grupowanie ich w porcje Prometheusa i przechowywanie ich w bazie danych takiej jak DynamoDB, BigTable lub Cassandra.) Umożliwia to starym podmiotom przetwarzającym przesyłanie bieżących danych nowym podmiotom przetwarzającym. Warto zauważyć, że Pochłaniacze wymagają zasobów. Aby zadziałały trzeba mieć 4 rdzenie i 15 GB pamięci na poda, czyli tzw. 25% mocy obliczeniowej i pamięci maszyny bazowej w przypadku naszych klastrów Kubernetes. Ogólnie rzecz biorąc, zwykle mamy dużo więcej niewykorzystanych zasobów w klastrze niż 4 rdzenie i 15 GB pamięci, więc możemy łatwo podkręcić te dodatkowe ingestery podczas aktualizacji.
Często jednak zdarza się, że podczas normalnej pracy żadna z maszyn nie ma tych 25% niewykorzystanych zasobów. Tak, nawet się nie staramy: procesor i pamięć zawsze będą przydatne dla innych procesów. Aby rozwiązać ten problem, postanowiliśmy użyć . Pomysł polega na tym, aby nadać podmiotom pobierającym wyższy priorytet niż innym (bezstanowym) mikrousługom. Kiedy musimy uruchomić dodatkowy (N+1) Ingester, tymczasowo wypieramy inne, mniejsze kapsuły. Te kapsuły są przenoszone do wolnych zasobów na innych maszynach, pozostawiając wystarczająco dużą „dziurę”, aby uruchomić dodatkowy Ingester.
W czwartek 18 lipca wprowadziliśmy w naszych klastrach cztery nowe poziomy priorytetów: krytyczny, wysoki, średnia и niski. Testowano je w klastrze wewnętrznym bez ruchu klienckiego przez około tydzień. Domyślnie odbierane są pody bez określonego priorytetu średnia priorytet, klasa została ustawiona dla osób pobierających z wysoki priorytet. Krytyczny był zarezerwowany do monitorowania (Prometheus, Alertmanager, eksporter węzłów, kube-state-metrics itp.). Nasza konfiguracja jest otwarta i możesz wyświetlić PR .
Crash
W piątek 19 lipca jeden z inżynierów uruchomił nowy, dedykowany klaster Cortex dla dużego klienta. Konfiguracja tego klastra nie obejmowała nowych priorytetów podów, więc wszystkim nowym podom przypisano priorytet domyślny — średnia.
Klaster Kubernetes nie miał wystarczających zasobów dla nowego klastra Cortex, a istniejący produkcyjny klaster Cortex nie został zaktualizowany (Ingesters pozostali bez wysoka priorytet). Ponieważ elementy pobierające nowego klastra domyślnie miały średnia priorytet, a istniejące kapsuły w produkcji działały w ogóle bez priorytetu, Pochłaniacze z nowego klastra zastąpili Pochłaniacze z istniejącego klastra produkcyjnego Cortex.
ReplicaSet dla wykluczonego modułu pobierającego w klastrze produkcyjnym wykrył eksmitowany pod i utworzył nowy, aby zachować określoną liczbę kopii. Nowy pod został przypisany domyślnie średnia priorytet, a inny „stary” Ingester w produkcji stracił swoje zasoby. Rezultat był proces lawinowy, co doprowadziło do przeniesienia wszystkich strąków z klastrów produkcyjnych Ingester na Cortex.
Elementy pobierające działają stanowo i przechowują dane z poprzednich 12 godzin. Dzięki temu możemy je efektywniej kompresować przed zapisaniem w pamięci długoterminowej. Aby to osiągnąć, Cortex dzieli dane na serie przy użyciu rozproszonej tabeli mieszającej (DHT) i replikuje każdą serię w trzech modułach pobierających, stosując spójność kworum w stylu dodatku Dynamo. Cortex nie zapisuje danych do wyłączonych elementów pobierających. Zatem, gdy duża liczba Pochłaniaczy opuszcza DHT, Cortex nie jest w stanie zapewnić wystarczającej replikacji wpisów i następuje awaria.
Wykrywanie i naprawa
Nowe powiadomienia Prometheusa oparte na „budżecie błędów” (oparte na budżecie błędów — szczegóły pojawią się w następnym artykule) zaczął bić na alarm 4 minuty po rozpoczęciu przestoju. W ciągu następnych pięciu minut przeprowadziliśmy diagnostykę i skalowaliśmy podstawowy klaster Kubernetes, aby obsługiwał zarówno nowe, jak i istniejące klastry produkcyjne.
Po kolejnych pięciu minutach starzy Pochłaniacze pomyślnie zapisali swoje dane, nowe uruchomiły się, a klastry Cortex ponownie stały się dostępne.
Kolejne 10 minut poświęcono na diagnozowanie i naprawianie błędów braku pamięci (OOM) z odwrotnych serwerów proxy uwierzytelniania znajdujących się przed Cortexem. Błędy OOM były spowodowane dziesięciokrotnym wzrostem QPS (uważamy, że z powodu zbyt agresywnych żądań z serwerów Prometheus klienta).
Następstwa
Całkowity czas przestoju wyniósł 26 minut. Żadne dane nie zostały utracone. Osoby pobierające pomyślnie załadowały wszystkie dane znajdujące się w pamięci do magazynu długoterminowego. Podczas zamykania bufory serwerów klienckich Prometheus zostały usunięte (zdalny) nagrania za pomocą na podstawie WAL (autor: z Grafana Labs) i powtórzył nieudane zapisy po awarii.
Operacje zapisu klastra produkcyjnego
odkrycia
Ważne jest, aby wyciągnąć wnioski z tego zdarzenia i podjąć niezbędne kroki, aby uniknąć jego ponownego wystąpienia.
Z perspektywy czasu nie powinniśmy byli ustawiać wartości domyślnej średnia priorytet do czasu otrzymania wszystkich osób spożywających w produkcji wysoki priorytet. Ponadto trzeba było się nimi wcześniej zająć wysoki priorytet. Wszystko jest teraz naprawione. Mamy nadzieję, że nasze doświadczenie pomoże innym organizacjom rozważającym wykorzystanie priorytetów podów w Kubernetesie.
Dodamy dodatkowy poziom kontroli nad wdrażaniem wszelkich dodatkowych obiektów, których konfiguracje są globalne dla klastra. Od teraz takie zmiany będą oceniane bоwięcej ludzi. Dodatkowo modyfikację, która spowodowała awarię, uznano za zbyt drobną, aby umieścić ją w osobnym dokumencie projektowym - została omówiona jedynie w numerze GitHub. Od teraz do wszelkich zmian w konfiguracjach będzie dołączona odpowiednia dokumentacja projektowa.
Na koniec zautomatyzujemy zmianę rozmiaru odwrotnego proxy uwierzytelniania, aby zapobiec przeciążeniu OOM, którego byliśmy świadkami, i sprawdzimy domyślne ustawienia Prometheusa związane z rezerwą i skalowaniem, aby zapobiec podobnym problemom w przyszłości.
Awaria miała również pewne pozytywne konsekwencje: po otrzymaniu niezbędnych zasobów Cortex automatycznie odzyskał siły bez dodatkowej interwencji. Zdobyliśmy także cenne doświadczenie współpracując z m.in - nasz nowy system agregacji logów - który pomógł zapewnić, że wszyscy osoby przetwarzające zachowywały się prawidłowo w trakcie i po awarii.
PS od tłumacza
Przeczytaj także na naszym blogu:
- «";
- «";
- «";
- «".
Źródło: www.habr.com