Rozszerzanie i badanie historii alarmów w Amazon CloudWatch – część 1

Dane historii alarmów mogą być nieocenione w diagnozowaniu trendów, wpływów i pierwotnych przyczyn problemów w Twojej aplikacji.

W tej dwuczęściowej serii wpisów zademonstrujemy, jak wyjść poza standardową 14-dniową historię alarmów i zamienić zmiany stanu alarmów Amazon CloudWatch w logi i metryki, które można wyświetlić na grafach w dashboardzie CloudWatch i zobaczyć obok innych danych dotyczących obserwowalności.

W tej części skupimy się na tworzeniu logów oraz danych metrycznych, a w drugiej przyjrzymy się kilku przydatnym sposobom uwzględniania tych danych w dashboardach CloudWatch.

Historia alarmów za pośrednictwem konsoli AWS Management Console

Alarmy CloudWatch mają 14-dniową historię. Historia jest dostępna w konsoli CloudWatch w zakładce Alarms po wybraniu dowolnego z alarmów. Rysunek 1 przedstawia przykładową historię z początkowym tworzeniem alarmu i zmianami stanu alarmu (np. ze stanu „In alarm” na „OK”). Ta historia pokazuje również wszelkie aktualizacje konfiguracji (np. zmiana okresu próbnego) i akcje (np. powiadomienie SNS).

Rysunek 1: Widżet historii alarmów CloudWatch pokazujący ostatnie zdarzenia.

Możesz chcieć sprawdzić trendy historii alarmów lub zobaczyć te dane razem z innymi danymi CloudWatch, aby móc diagnozować trendy, wpływy i przyczyny. Zazwyczaj tylko ci, którzy muszą podjąć natychmiastowe działania, otrzymują dane alarmowe, ale jest to również przydatne dla osób rozwiązujących problemy, planujących przyszłe zmiany lub rozumiejących tzw. user experience. Włączenie danych alarmowych do dashboardów otwiera dane dla szerszej publiczności i szerszego wykorzystania.

Co zrobimy?

Stworzymy:

• Alarm CloudWatch
• Regułę Amazon EventBridge do przechwytywania zmian stanu alarmu i tworzenia logów zdarzenia CloudWatch.
• Filtr metryk w grupie logów CloudWatch w celu utworzenia danych liczbowych metryk.
• Dashboard CloudWatch z wyświetlanymi żądanymi danymi (w części 2).

Utworzenie alarmu CloudWatch

Stworzymy alarm, który uruchamia się przy LOW CPU na instancji Amazon Elastic Compute Cloud (Amazon EC2). To sztuczny przykład, ale jest używany, ponieważ można go łatwo skonfigurować i uruchomić w celach eksploracyjnych.

1. Alarmy są tworzone z metryk, więc najpierw musimy wygenerować jakieś metryki. Utwórz instancję Amazon EC2 i ją uruchom. Zanotuj identyfikator instancji (instance ID), ponieważ użyjesz go w następnym kroku.

Aby uzyskać wskazówki, jak to zrobić, zobacz Krok 1: Uruchom instancję w Tutorial: Tutorial: Get started with Amazon EC2 Linux instances. Nie musisz mieć możliwości połączenia się ze swoją instancją, wystarczy, że będziesz w stanie zatrzymać i uruchomić swoje instancje, aby wywołać alarm CloudWatch.

2. W konsoli CloudWatch wybierz Alarms > “In alarm” lub “All alarms” z menu CloudWatch. Następnie wybierz Create alarm.

3. Wybierz opcję Select Metric > EC2 > Per-Instance Metrics. Wybierz CPUUtilization dla swojej instancji (z podanym powyżej ID instancji) i wybierz opcję Select Metric. Jeśli nie widzisz żadnych metryk w EC2 lub nie widzisz swojej instancji, wróć do konsoli Amazon EC2 i sprawdź, czy instancja jest uruchomiona. Wygenerowanie pierwszego punktu danych metryki może potrwać kilka minut.

4. Wypełnij pola, jak wyszczególniono poniżej i pokazano na rysunku 2.

• Metric (Metryka)
  • Domyślnie CPUUtilization zgłasza wartość co pięć minut
  • Threshold type (typ progu): Static (statyczny)
  • Whenever CPUUtilization is… (Zawsze, gdy wykorzystanie CPU jest…) Lower (niższe)
  • Than (niż) … 50
• Namespace, Metric name oraz InstanceId są wstępnie wypełniane na podstawie wybranych metryk
• Statistic (Statystyka): Average (średnia)
• Period (okres): 5 minutes (5 minut)
• Conditions (Warunki)
• Additional Configuration (Dodatkowa konfiguracja)
  • Dzięki temu alarm jest wyświetlany jako OK, gdy instancja jest zatrzymana.
• Datapoints to alarm (Punkty danych do alarmu): 1 out of 1 (1 z 1)
• Missing data treatment (Obróbka brakujących danych): Treat missing data as good (not breaching threshold)  (Traktuj brakujące dane jako dobre (nie przekraczające progu))

Rysunek 2: Alarm CloudWatch ze zdefiniowanymi metrykami i warunkami

5. Wybierz Next, aby przejść do kroku Configure.

Możesz ustawić akcje powiadamiania, takie jak wysyłanie wiadomości e-mail za pośrednictwem tematu SNS, jednak tutaj wybierz Remove , aby nie uruchamiać powiadomień. Pozostaw wszystkie inne wartości domyślne i wybierz Next.

6. Nazwij swój alarm EC2-low_CPU i wybierz Review, a następnie Create alarm.

Gdy zatrzymasz swoją instancję, alarm nie będzie zawierał danych. W związku z tym będzie w stanie OK, a gdy instancja będzie uruchomiona, niskie użycie CPU spowoduje wywołanie stanu In Alarm. Przetestujemy to po utworzeniu reguły EventBridge.

Aby uzyskać więcej informacji na temat stanów alarmów i różnych właściwości ustawianych podczas tworzenia alarmu, zapoznaj się z dokumentacją dotyczącą używania alarmów CloudWatch i tworzenia alarmu na podstawie tzw. static threshold.

Tworzenie zasady EventBridge

Reguła EventBridge przechwyci zmiany stanu alarmów dla wszystkich alarmów CloudWatch. Ta reguła ma akcję, która utworzy odpowiednie zdarzenie logów CloudWatch.

1. W konsoli EventBridge wybierz Create rule i nadaj jej nazwę Alarm_History-multiple_alarms.

2. Wypełnij pola, jak wyszczególniono poniżej i pokazano na rysunku 3.

• Wybierz Event Pattern
• Event matching pattern (wzorzec dopasowania zdarzeń)
• Pre-defined pattern by service (wstępnie zdefiniowany wzór przez usługę)
• Service provider (dostawca usług): AWS
• Service name (nazwa usługi): CloudWatch
• Event type (typ zdarzenia): CloudWatch Alarm State Change

• Define pattern (zdefiniuj wzór)

• Select targets (Wybierz cele)
  • Podaj dowolną nazwę grupy logów, jaką chcesz
• Target (cel): CloudWatch log group  (grupa logów CloudWatch)
• Log group name (Nazwa grupy logów): /aws/events/alarms/

3. Pozostaw wszystkie inne ustawienia jako domyślne i utwórz regułę EventBridge klikając w Create.

Rysunek 3: Reguła EventBridge ze zdefiniowanym wzorcem i celami

Tworzenie filtrów danych

Od sposobu w jaki zdefiniujesz swoje metryki z logów, będzie zależało to co chcesz osiągnąć. W tym przypadku chcemy mieć jedną metrykę na alarm, która zawiera stan alarmu – 1, gdy przechodzi w stan ALARM, i 0, gdy przechodzi w stan OK.

Wymaga to dwóch filtrów – jednego do przechwytywania każdego stanu. Oba filtry zapisują dane w tej samej metryce.

1. W konsoli CloudWatch przejdź do Log Groups i wybierz /aws/events/alarms/

2. Wybierz zakładkę Metric filters i kliknij Create metric filter, aby utworzyć filtr dla stanu ALARM z wartościami wyszczególnionymi poniżej i pokazanymi na rysunku 4.

• Filter pattern (wzorzec filtra): {$.detail.alarmName=* && $.detail.state.value=”ALARM”}
• Filter name (nazwa filtra): Alarm-history-state-alarm
• Metric namespace (Obszar nazw danych): CWAlarms
• Metric name (nazwa metryki): state
• Metric value (wartość metryki): 1
• Dimensions (wymiary):
• Dimension Name (nazwa wymiaru): alarmName
• Dimension Value (nazwa wartości): $.detail.alarmName

3. Wybierz Next i kliknij w Create metric filter.

Więcej szczegółów i przykładów można znaleźć w dokumentacji AWS dotyczącej tworzenia filtrów metryk.

Rysunek 4: Filtr metryk ze zdefiniowanym wzorem, szczegółami metrycznymi i wymiarami

Ten wzorzec filtra będzie pasował do wszystkich zdarzeń stanu ALARM w tej grupie logów. Ustawienie wzoru filtra pozwala nam tworzyć wymiary. Wartości wymiaru alarmName ($.detail.alarmName) są wyodrębniane z każdego zdarzenia dzienników logów. Więcej informacji na temat wzorców filtrów można znaleźć w dokumentacji AWS dotyczącej składni filtrów i wzorców.

4. Utwórz drugi filtr metryki dla stanu OK w tej samej grupie logów (/aws/events/alarms/). Tym razem filtr metryki dotyczy stanu OK z wartością metryki równą 0.

Wybierz kartę Metric filters i następnie utwórz filtr danych z następującymi wartościami:

• Filter pattern (wzorzec filtra): {$.detail.alarmName=* && $.detail.state.value=”OK“}
• Filter name (nazwa filtra): Alarm-history-state-ok
• Metric namespace (obszar nazw danych): CWAlarms
• Metric name (nazwa metryki): state
• Metric value (wartość metryki): 0
•  Dimensions (wymiary):
• Dimension Name (nazwa wymiaru): alarmName
• Dimension Value (wartość wymiaru): $.detail.alarmName

Uruchomianie alarmu CloudWatch i reguły EventBridge

Zmień stan alarmu CloudWatch, zatrzymując i uruchamiając instancję. Gdy instancja jest zatrzymana, stan alarmu powinien być OK i znajdować się w stanie ALARM, gdy instancja jest uruchomiona.

Uwaga: dane metryczne Amazon EC2 są domyślnie raportowane co pięć minut, więc może być konieczne odczekanie do pięciu minut, aż punkt danych zostanie wygenerowany przez instancję.

Sprawdź stan alarmu CloudWatch w konsoli CloudWatch, wybierając Alarms > All Alarms i wybierając EC2-low_CPU. Rysunek 5 przedstawia ekran przeglądu alarmów z wykresem czasowym metryki alarmu i progu. Czerwony/zielony pasek na dole pokazuje stan alarmu w czasie. Bieżący stan jest wyświetlany w prawym górnym rogu wykresu. Odśwież ten ekran, aż zobaczysz stan zmiany alarmu.

Rysunek 5: Alarm CloudWatch przedstawiający wykres czasu stanu alarmu

Sprawdź swoje logi

Za każdym razem, gdy alarm CloudWatch zmieni stan, reguła EventBridge przechwyci to i utworzy zdarzenie w logach CloudWatch w grupie logów /aws/events/alarms/.

Sprawdź, czy zdarzenia logów są tworzone w konsoli CloudWatch, Logs > Log groups > /aws/events/alarms/. Wybierz najnowszy strumień logów, aby wyświetlić wydarzenie.

Zobaczysz wiele strumieni logów utworzonych w czasie zmiany stanu alarmu. Jednym ze sposobów przeglądania danych z tych strumieni jest wykorzystanie CloudWatch Logs Insights. W konsoli CloudWatch wybierz Logs Insights. Z listy rozwijanej Select log group(s) wybierz grupę logów /aws/events/alarms/ i zastąp zapytanie następującym:

fields @timestamp, detail.alarmName, detail.state.value, @message

Następnie wybierz Run query.

Rysunek 6 przedstawia zapytanie i zwrócone wyniki. Jeśli wyszukiwanie nie przyniesie żadnych wyników, zmień okres czasu, aby zmienić okres wyszukiwania i ponownie wybierz Run query.

Rysunek 6: Wyniki zapytania o statystyki logów.

Sprawdzanie metryk

W konsoli CloudWatch przejdź do opcji Metrics > All Metrics i wybierz przestrzeń nazw metryki Namespace (CWAlarms) oraz wymiar (alarmName). Zobaczysz metrykę dla każdego alarmName. Zaznacz pole wyboru obok każdej metryki, aby wykreślić wyniki.

Rysunek 7: Konsola metryk CloudWatch pokazująca wykres czasu utworzony z filtra metryk

Koszty

Ten przykład wykorzystuje logi i metryki Amazon EC2, EventBridge i CloudWatch.

Korzystanie z EventBridge jest bezpłatne, ponieważ wszystkie zdarzenia odbywają się pomiędzy usługami AWS. Instancja t2.micro Amazon EC2 może należeć do Free tier, wraz z wykorzystaniem CloudWatch (logi, metryki i alarmy) (Free tier: https://aws.amazon.com/free/ )

Aby uzyskać więcej informacji, zobacz strony z cenami dla każdej usługi:

• Amazon EC2 on demand: https://aws.amazon.com/ec2/pricing/on-demand/
• CloudWatch: https://aws.amazon.com/cloudwatch/pricing/
• EventBridge: https://aws.amazon.com/eventbridge/pricing/

Czynności końcowe

Aby uniknąć opłat na koncie, usuń utworzone zasoby.

• Instancja Amazon EC2: zapoznaj się z dokumentacją dotyczącą usuwania instancji.
• Reguła EventBridge: zobacz dokumentację dotyczącą wyłączania lub usuwania reguły Amazon EventBridge.

W części 2 wykorzystamy dane z logów i metryk CloudWatch w celu stworzenia dashboardów, więc możesz chcieć zachować te dane do późniejszego wykorzystania.

Aby usunąć grupy logów CloudWatch, przejdź do Logs > Log groups i wybierz odpowiednią grupę. Z listy rozwijanej Actions wybierz opcję Delete log group(s).

Metryki nie mogą być usunięte, ale wygasną zgodnie z harmonogramem przechowywania, jak wyjaśniono w FAQ Jaki jest okres przechowywania wszystkich metryk.

Podsumowanie

W tym poście pokazaliśmy jak wykorzystać regułę EventBridge do tworzenia logów i metryk CloudWatch na podstawie zmian stanu alarmów CloudWatch.

W części 2 wykorzystamy te dane i pokażemy kilka sposobów włączenia ich do dashboardów CloudWatch za pomocą widżetów alarmów, zapytań do logów i wyrażeń matematycznych metryk. Zbadamy widżety, które pomogłyby zrozumieć wpływ różnych alarmów i korelację z innymi danymi CloudWatch.

źródło: AWS