Zyski:
- Umiejętność zrozumienia trzech filarów obserwowalności (metryka, log, śledzenie) i czterech złotych sygnałów oraz wykorzystanie sztucznej inteligencji do generowania zapytań PromQL, reguł alarmów i pulpitów nawigacyjnych
- Możliwość zapobiegania zmęczeniu alarmami poprzez utrzymywanie alarmów zorientowanych na działanie i o odpowiedniej pilności oraz testowanie progów na podstawie danych historycznych własnego systemu
- Możliwość zapobiegania wyciekom prywatności i tajemnic poprzez maskowanie wrażliwych obszarów przed przekazaniem dzienników sztucznej inteligencji
Choć może wydawać się, że system działa, może umierać w środku: pamięć powoli się zapełnia, wydłużają się czasy odpowiedzi, rośnie poziom błędów. Jedynym sposobem, aby to zauważyć, jest ciągłe monitorowanie systemu. Bardziej zaawansowaną koncepcją jest obserwowalność: zdolność zrozumienia tego, co dzieje się wewnątrz systemu, poprzez przyglądanie się jego zewnętrznym oznakom. Istnieją trzy filary obserwowalności, a profesjonalista DevOps wykorzystuje wszystkie trzy:
- Metryka: Wartości liczbowe mierzone w czasie — użycie procesora, liczba żądań, czas odpowiedzi, stopa błędów. "Ile?" odpowiada na pytanie.
- Log: Tekstowe zapisy zdarzeń generowane przez system – „użytkownik zalogowany”, „utracono połączenie z bazą danych”. – Co dokładnie się stało? odpowiada na pytanie.
- Śledzenie: Ścieżka, którą podąża żądanie podczas przejścia z usługi do usługi w systemie oraz czas trwania każdego kroku. „Gdzie jest powolność?” odpowiada na pytanie.
Najpopularniejsze narzędzia: Prometheus do metryk, Grafana do wizualizacji, Loki/ELK do logów, Jaeger/OpenTelemetry do śledzenia. Sztuczna inteligencja jest bardzo biegła w pisaniu języków zapytań (zwłaszcza PromQL firmy Prometheus), reguł alarmów i konfiguracji pulpitów nawigacyjnych dla tych narzędzi. To także obszar, w którym sztuczna inteligencja jest najmocniejsza: podsumowuje duże fragmenty dzienników i wskaźników oraz sygnalizuje anomalie.
Wyjaśnijmy różnicę między monitorowaniem a obserwowalnością w jednym zdaniu: monitorowanie polega na zadawaniu pytań, które już znasz („Czy procesor przekroczył 90%?”); obserwowalność to możliwość zadawania pytań, których jeszcze nie znasz („dlaczego to dziwne spowolnienie występuje tylko u określonego klienta w określonym czasie?”). Nowoczesne systemy są tak złożone, że nie można przewidzieć wszystkich rodzajów awarii; Dlatego możliwość gromadzenia rozbudowanych metryk, dzienników i śladów, a następnie szczegółowego sprawdzania ich, czyli obserwowalności, staje się krytyczna. W tym miejscu wkracza sztuczna inteligencja, odpowiadając na „wcześniej nieznane pytanie”: szybko skanuje posiadane surowe dane, sugeruje wzorce i anomalie, a Ty docierasz do pierwotnej przyczyny, weryfikując te wskazówki.
Krok po kroku: co i jak monitorować?
- Wybierz odpowiednie wskaźniki. W branży za podstawę przyjmuje się „cztery złote sygnały”: opóźnienie, ruch, błędy, nasycenie – czyli stopień zapełnienia zasobu. Podsumowują one stan większości usług.
- Zbieraj metryki. Niech aplikacja przedstawi punkt końcowy, który Prometheus może odczytać.
- Skonfiguruj dashboardy. Wizualizuj te wskaźniki w Grafanie.
- Napisz zasady alarmowania. Kto i w jaki sposób zostanie ostrzeżony w przypadku przekroczenia progu?
- Scentralizuj logi. Możliwość przeszukiwania wszystkich dzienników usług w jednym miejscu.
- Zmniejsz hałas. Zbyt dużo alarmów powoduje „zmęczenie czujnością”; Ważny alarm znika.
Wskazówka: dobry alarm spełnia dwie funkcje: jest wykonalny i ma odpowiednią pilność. Alarm, który budzi kogoś o 3 w nocy, musi być czymś, co faktycznie wymaga interwencji w nocy. Nie budź nikogo czymś, co samo w sobie nie wymaga działania, np. „CPU 70%”; pokaż to na tablicy.
Jak napisać regułę alarmową?
Alert składa się z trzech elementów: warunku (który wskaźnik przekracza który próg i na jak długo), czasu trwania („przez 5 minut”, aby uniknąć chwilowych wahań) oraz ważności/działania (dla kogo, jakim kanałem). Sztuczna inteligencja po mistrzowsku zestawia te trzy elementy we właściwym kontekście. Na przykład przetłumaczenie reguły takiej jak „alarm krytyczny, jeśli poziom błędów przekracza 5% przez 5 minut” na PromQL to zadanie dla sztucznej inteligencji, które zajmuje ułamek sekundy — ale to Ty decydujesz, czy próg jest odpowiedni dla Twojego systemu.
Uwaga: Progi alarmowe sugerowane przez sztuczną inteligencję są założeniami ogólnymi. Normalne obciążenie, tolerancja i wpływ pracy Twojego systemu są różne. Zanim ustawisz próg bezpośrednio w prod, przeglądasz dane historyczne i zadajesz sobie pytanie: „ile razy ten próg był uruchamiany w przeszłości i ile z nich było prawdziwymi problemami?” Odpowiedz na pytanie.
Prywatność dziennika: krytyczne ostrzeżenie
Dzienniki są najczęściej pomijanym źródłem wycieków. Wiersz dziennika może przypadkowo zawierać hasło, numer karty kredytowej lub dane osobowe (zgodnie z KVKK/RODO). Podczas wklejania logów do AI w celu analizy:
- Zamaskuj wrażliwe obszary. Zamień wartości takie jak token, hasło, adres e-mail, numer identyfikacyjny na <ZMIENIONO>.
- Podaj przykłady, nie wszystkie. Zamiast miliona linii często wystarczy kilkaset reprezentatywnych linii.
- Wybierz pojazd zatwierdzony przez instytucję. Szczególnie w przypadku logów produkcyjnych warto zastosować narzędzie, którego dane nie trafiają na szkolenie.
Cztery złote sygnały i stoły alarmowe
sygnał
mierzone przez
Przykładowy próg alarmowy
pilność
opóźnienie
czas reakcji
p95 > 800 ms, 5 min
wysoki
ruch
Żądanie/sek
Nagły wzrost/spadek o 300%.
średni
Błąd
Wskaźnik nieudanych żądań
> 5%, 5 min
krytyczny
Nasycenie
zajętość zasobów
Dysk > 85%
wysoki
trzy mini etui
Przypadek 1 — 400 wierszy logu podsumowane w 30 sekund. Usługa uległa spowolnieniu. Inżynier przekazał AI zamaskowane 400 wierszy dziennika i powiedział: „podsumuj powtarzające się wzorce błędów i intensywność czasu”. Sztuczna inteligencja pokazała, że limit czasu określonego zewnętrznego wywołania API upływa co 30 sekund. Pierwotna przyczyna znaleziona w 30 sekund; Ręczne skanowanie dzienników zajęłoby pół godziny.
Przypadek 2 — zmęczenie alarmami rozwiązane. Jeden zespół otrzymywał 200 alarmów dziennie i ignorował je wszystkie — aż do momentu, w którym przeoczono także prawdziwy alarm o awarii. Podaj AI wszystkie reguły alertów i zapytaj „które z nich nie podlegają działaniu, a które można połączyć?” zapytali. Liczba alarmów spadła do 12 dziennie; Każdy alarm był teraz traktowany poważnie.
Przypadek 3 – wcześnie wykryty błędny próg. YZ zasugerował opcję „Ostrzegaj, gdy zapełniony jest w 95%” dla dysku. Inżynier przejrzał dane historyczne: gdy dysk osiągnął 95%, nie było już czasu na interwencję. Obniżono próg do 80% i dodano drugi alarm oparty na „tempie wzrostu”. Weryfikacja zapobiegła rzeczywistej przerwie w działaniu o północy.
Cztery szablony do kopiowania
1) Podsumowanie dziennika (maskowane):
Przeanalizuj poniższy przykład dziennika (zamaskowałem wrażliwe wartości za pomocą <ZMIENIONO>). Podaj mi: (1) powtarzające się wzorce błędów, (2) koncentrację w czasie, (3) najbardziej prawdopodobną przyczynę pierwotną oraz (4) 3 wskaźniki, które sprawdzę, aby zweryfikować. Dziennik: [LINIE]
2) Generowanie reguły alarmowej:
Napisz regułę alarmową dla Prometheus/Alertmanager: Wygeneruj alarm [WAŻNOŚĆ], jeśli [PRÓG] przekracza [METRYCZNY] CZAS TRWANIA. Reguła powinna być zorientowana na działanie i zawierać adnotację oraz pole łącza elementu Runbook. Wyjaśnij PromQL i napisz, dlaczego ten próg jest rozsądny.
3) Napisanie/deklarowanie zapytania PromQL:
Napisz zapytanie PromQL, które mierzy: [EX. 5xxprocentowy współczynnik błędów w ciągu ostatnich 5 minut]. Wyjaśnij zapytanie krok po kroku. Następnie powiedz mi, jaki powinien być zdrowy zakres tej wartości.
4) Projekt deski rozdzielczej:
Zaprojektuj dashboard Grafana dla [SERVICE]: za pomocą których paneli powinienem wyświetlać cztery złote sygnały (opóźnienie, ruch, błąd, nasycenie)? Zaproponuj metrykę, typ wizualizacji i rozsądny próg dla każdego panelu. Cel: sprawdzenie stanu zdrowia strażnika w 10 sekund.
Słaba zachęta/silna zachęta
Słaby: „Co jest w tym dzienniku?” (po których następuje 5000 linii surowego dziennika, w nim żetony)
Wynik: ujawniasz tajemnice, a sztuczna inteligencja podaje nieukierunkowane, powierzchowne podsumowanie.
Strong: „Znajdź powtarzające się wzorce błędów i intensywność czasu w poniższym przykładzie dziennika z maską zawierającą 300 wierszy; podaj najbardziej prawdopodobną przyczynę źródłową i metryki, które będę sprawdzał. Utworzyłem tokeny <ZMIENIONO>”.
Różnica: drugi monit podaje zamaskowany i skupiony przykład, prosząc o przejrzysty wynik analizy; Jest to bezpieczne i przydatne.
Typowe błędy
- Wklejenie logu do AI bez jego maskowania. Najczęstszy wyciek danych tajnych/osobistych.
- Ustawianie alarmów na wszystko. Zmęczenie alarmem ukrywa prawdziwy alarm.
- Alarm, którego nie można podjąć. Jest to hałas ostrzegawczy, z którym nikt nie może nic zrobić.
- Akceptacja progu AI bez dwóch zdań. Próg należy ustawić zgodnie z historią systemu.
- Patrzę tylko na metrykę. Bez dziennika i śledzenia w większości przypadków nie można znaleźć pierwotnej przyczyny.
- Brak ustawienia czasu alarmu (dla). Chwilowe wahania powodują fałszywe alarmy.
Podsumowując
Obserwowalność; Jest to umiejętność zrozumienia wnętrza systemu z zewnątrz za pomocą metryk, logów i śladów. Cztery złote sygnały (opóźnienie, ruch, błąd, nasycenie) podsumowują stan większości usług. Sztuczna inteligencja jest bardzo wydajna w pisaniu zapytań PromQL, reguł alarmów i pulpitów nawigacyjnych, a także w podsumowywaniu dużych fragmentów dzienników i znajdowaniu anomalii. Jednak Twoim obowiązkiem jest weryfikowanie progów alarmowych w oparciu o historię własnego systemu, utrzymywanie alarmów w zorientowaniu na działanie i nigdy nie udostępnianie dzienników bez ich maskowania.
Zadanie aplikacji
Dla usługi (lub przykładowej usługi): (1) Wygeneruj regułę alarmową dla poziomu błędów za pomocą szablonu „Generowanie reguły alarmowej” i ustaw sugerowany próg na „ile razy była ona wyzwalana w przeszłości?” Przetestuj to za pomocą pytania; (2) zamaskować posiadaną próbkę dziennika i zlecić jej analizę za pomocą szablonu „Podsumowanie dziennika”; (3) zanotuj, jakie dane będziesz brać pod uwagę, aby potwierdzić najbardziej prawdopodobną pierwotną przyczynę.
lista kontrolna
- [ ] Wybrałem metryki do śledzenia w oparciu o cztery złote sygnały.
- [ ] Zamaskowałem wszystkie logi, które przekazałem AI pod kątem wrażliwych obszarów.
- [ ] Sprawdziłem, czy każdy alarm był zorientowany na działanie i miał odpowiednią pilność.
- [ ] Przetestowałem progi alarmowe na podstawie danych historycznych mojego systemu.
- [ ] Odfiltrowałem chwilowe wahania, dodając czas trwania do alarmów.
- [ ] Użyłem razem metryki + logu + śledzenia w celu ustalenia pierwotnej przyczyny.