Awaria backendu rzadko zaczyna się od komunikatu „system nie działa”. Częściej najpierw rośnie opóźnienie, pojawiają się błędy 5xx albo kończy się pamięć na instancji. AWS CloudWatch pomaga zauważyć te sygnały, połączyć metryki z logami i automatycznie uruchomić reakcję, zanim problem dotknie użytkowników. Poniżej pokazuję, jak działa usługa, jak wykorzystać ją w aplikacjach Python oraz na co uważać przy konfiguracji i kosztach.
Monitoring AWS ma sens dopiero wtedy, gdy prowadzi do konkretnej reakcji
- Metryki pokazują stan usług, aplikacji i infrastruktury w czasie.
- Logi pozwalają wyszukiwać błędy, analizować zdarzenia i tworzyć alarmy na podstawie wpisów.
- Alarmy mogą wysyłać powiadomienia przez SNS albo uruchamiać autoskalowanie.
- Koszty zależą głównie od liczby metryk, ilości logów, retencji i zapytań analitycznych.
- Najlepsza praktyka to monitorowanie objawów ważnych dla użytkownika, a nie każdej dostępnej wartości.
Co naprawdę daje AWS CloudWatch w projekcie backendowym
Amazon CloudWatch to usługa obserwowalności dla zasobów AWS, aplikacji, sieci i środowisk hybrydowych. Zbiera przede wszystkim metryki, logi i zdarzenia, a potem pozwala prezentować je na dashboardach oraz reagować na przekroczenie ustalonych progów.
W praktyce oznacza to jedno miejsce do sprawdzania, czy aplikacja działa poprawnie. Dla backendu w Pythonie mogą to być błędy funkcji Lambda, czas odpowiedzi API Gateway, obciążenie instancji EC2, liczba wiadomości w kolejce SQS albo zużycie bazy RDS.
Usługa nie zastępuje jednak wszystkich narzędzi DevOps. CloudWatch odpowiada głównie za monitoring i reakcję operacyjną, natomiast AWS CloudTrail rejestruje aktywność API i działania użytkowników. Te produkty często współpracują, ale rozwiązują różne problemy.
| Narzędzie | Najważniejsze pytanie | Przykład użycia |
|---|---|---|
| CloudWatch | Jak działa system? | Wykrycie wzrostu błędów 5xx i wysłanie alarmu |
| CloudTrail | Kto wykonał operację? | Sprawdzenie, kto zmienił regułę security group |
| X-Ray | Gdzie powstaje opóźnienie? | Prześledzenie żądania przez API, Lambdę i bazę |
| Prometheus i Grafana | Jak zbudować własny stos obserwowalności? | Monitoring Kubernetes z własnym modelem metryk |
Metryki, logi i alarmy tworzą podstawowy system obserwowalności
Metryki pokazują trend, a nie pojedynczy incydent
Metryka to uporządkowany w czasie zbiór punktów danych. Może opisywać CPU, pamięć, liczbę żądań, opóźnienie, błędy lub wykorzystanie zasobu. Wiele usług AWS publikuje podstawowe metryki automatycznie, ale szczegółowe dane systemowe z EC2 wymagają zwykle agenta CloudWatch.
Własne metryki są szczególnie przydatne w backendzie. Sam poziom CPU niewiele mówi o jakości API, dlatego lepiej mierzyć także liczbę nieudanych płatności, czas obsługi endpointu czy liczbę zadań oczekujących w kolejce.
Trzeba pamiętać, że metryki są związane z regionem, w którym je utworzono. Klasyczne metryki CloudWatch mogą automatycznie wygasać po 15 miesiącach bez nowych danych, więc długoterminowe analizy biznesowe lepiej przechowywać w osobnym systemie.
Logi pozwalają znaleźć przyczynę problemu
CloudWatch Logs centralizuje wpisy z Lambdy, EC2, ECS, CloudTrail i własnych aplikacji. Logi są przechowywane w grupach logów, a każda grupa może mieć ustawioną własną retencję, na przykład 7, 30 albo 90 dni.
Do szybkiej analizy służy Logs Insights. Można filtrować wpisy po poziomie błędu, kodzie HTTP, identyfikatorze żądania lub czasie wykonania. Przy aplikacji Python zdecydowanie lepiej wysyłać logi w formacie JSON niż wielolinijkowe komunikaty tekstowe, ponieważ pola można później łatwo wyszukiwać i agregować.
Alarm powinien prowadzić do działania
Alarm obserwuje metrykę przez określony czas i zmienia stan po spełnieniu warunku. Może wysłać powiadomienie przez Amazon SNS, uruchomić politykę Auto Scaling albo rozpocząć inną automatyzację.
Nie ustawiam alarmu na każdy drobny skok wartości. Lepszy jest warunek typu „powyżej 2% błędów przez 5 minut” niż alert po jednym nieudanym żądaniu. Pomaga też alarm złożony, który łączy kilka sygnałów i ogranicza tak zwany alert fatigue, czyli zmęczenie nadmiarem powiadomień.
Jak skonfigurować monitoring backendu krok po kroku
Najpierw określam, co oznacza poprawne działanie aplikacji. Dla publicznego API mogą to być dostępność na poziomie 99,9%, mediana czasu odpowiedzi poniżej 300 ms i odsetek błędów poniżej 1%. Bez takich założeń dashboard szybko zamienia się w kolekcję przypadkowych wykresów.
- Wybierz sygnały użytkownika, takie jak dostępność, opóźnienie, liczba żądań i błędy.
- Dodaj metryki zasobów, na przykład CPU, pamięć, dysk, liczbę połączeń do bazy i długość kolejki.
- Ustandaryzuj logowanie i dodaj identyfikator korelacyjny żądania.
- Utwórz alarmy dla problemów wymagających reakcji, nie dla każdej anomalii.
- Zbuduj dashboard pokazujący stan całej usługi na jednym ekranie.
- Przetestuj alarmy, wywołując kontrolowany błąd lub obciążenie.
W aplikacji działającej na EC2 instaluję agenta, jeśli potrzebuję danych o pamięci, procesach, miejscu na dysku albo interfejsach sieciowych. Przy Lambdzie część metryk i logów pojawia się automatycznie, ale obserwowalność funkcji nadal wymaga sensownego formatowania logów i zdefiniowania własnych wskaźników.
Dla aplikacji kontenerowych przydatny jest Container Insights, który zbiera dane o klastrach, usługach, zadaniach i kontenerach. Trzeba jednak włączyć go świadomie, bo szczegółowość monitoringu może szybko zwiększyć liczbę metryk oraz objętość logów.
Przeczytaj również: Elastic Beanstalk - Kiedy wybrać i jak wdrożyć Python na AWS?
Przykładowy zestaw alarmów dla API
| Sygnał | Przykładowy warunek | Reakcja |
|---|---|---|
| Dostępność | Health check nie działa przez 2 kolejne okresy | Powiadomienie on-call |
| Błędy | HTTP 5xx powyżej 2% przez 5 minut | SNS i utworzenie incydentu |
| Opóźnienie | Percentyl p95 powyżej 800 ms przez 10 minut | Analiza zależności i skalowanie |
| Kolejka | Wiadomości oczekujące dłużej niż 300 sekund | Skalowanie workerów |
| Baza danych | Wykorzystanie CPU powyżej 80% przez 15 minut | Ocena zapytań i pojemności |
Podane wartości są punktem wyjścia, a nie uniwersalnym standardem. Dla endpointu płatniczego próg błędów powinien być znacznie bardziej restrykcyjny niż dla wewnętrznego panelu administracyjnego.
Python i CloudWatch w praktyce
Własną metrykę można wysłać z Pythona przez bibliotekę boto3. Poniższy przykład rejestruje czas obsługi operacji w milisekundach. Nazwa przestrzeni Backend/Orders porządkuje metryki aplikacyjne i oddziela je od danych publikowanych przez usługi AWS.
import time
import boto3
cloudwatch = boto3.client("cloudwatch", region_name="eu-central-1")
start = time.perf_counter()
try:
result = process_order()
status = "success"
finally:
elapsed_ms = (time.perf_counter() - start) * 1000
cloudwatch.put_metric_data(
Namespace="Backend/Orders",
MetricData=[
{
"MetricName": "ProcessingTime",
"Dimensions": [
{"Name": "Environment", "Value": "production"}
],
"Unit": "Milliseconds",
"Value": elapsed_ms
}
]
)W produkcji nie wysyłałbym pojedynczego punktu przy każdym żądaniu bez sprawdzenia skali. Przy dużym ruchu lepsze może być agregowanie danych, użycie Embedded Metric Format albo instrumentacja przez OpenTelemetry. Zmniejsza to liczbę wywołań API i ogranicza ryzyko nadmiernego wzrostu kosztów.
Logowanie powinno zawierać informacje potrzebne do diagnozy, ale nie hasła, tokeny ani pełne dane kart płatniczych. Przykładowy wpis może mieć pola takie jak request_id, route, status_code, duration_ms i error_type. Dzięki temu jedno zapytanie w Logs Insights pozwoli szybko znaleźć problematyczne żądania.
fields @timestamp, request_id, route, status_code, duration_ms
| filter status_code >= 500
| sort @timestamp desc
| limit 50Jeśli aplikacja korzysta z wielu usług, identyfikator korelacyjny powinien przechodzić przez cały łańcuch. To drobna decyzja projektowa, która często skraca diagnozę z kilkudziesięciu minut do kilku minut.
Ile kosztuje monitoring i gdzie najłatwiej stracić kontrolę
CloudWatch nie ma opłaty wstępnej ani obowiązkowego abonamentu. Rozliczenie zależy od używanych funkcji, a największy wpływ na rachunek mają zwykle logi, niestandardowe metryki, zapytania Logs Insights i monitoring kontenerów.
W bezpłatnym limicie znajdują się między innymi podstawowe metryki wielu usług AWS, 5 GB logów miesięcznie, 10 metryk niestandardowych lub szczegółowego monitoringu, 1 milion żądań API, 3 dashboardy z limitem 50 metryk każdy oraz 10 alarmów standardowej rozdzielczości. Limity i dostępność zależą od aktualnego modelu AWS Free Tier.
Dla orientacji, w przykładach cennika AWS dla regionu US East pierwsze 10 000 klasycznych metryk niestandardowych kosztuje 0,30 USD za metrykę miesięcznie, a ingestia logów standardowych jest pokazana jako 0,50 USD za GB. Nie traktowałbym tych wartości jako polskiej stawki końcowej, ponieważ ceny różnią się między regionami i zmieniają się wraz z ofertą.
| Źródło kosztu | Co go zwiększa | Jak ograniczyć wydatki |
|---|---|---|
| Metryki | Duża liczba wymiarów i serii czasowych | Ustal stały zestaw wymiarów i usuwaj zbędne metryki |
| Logi | Dużo danych debug oraz długa retencja | Poziom DEBUG tylko chwilowo, krótsza retencja, archiwizacja do S3 |
| Logs Insights | Skanowanie dużych grup logów | Ograniczaj zakres czasu i filtruj po konkretnej grupie |
| Container Insights | Monitoring każdego kontenera i zadania | Włącz szczegółowość tylko tam, gdzie pomaga operacyjnie |
| Alarmy wysokiej rozdzielczości | Okresy 10 lub 30 sekund | Stosuj je wyłącznie dla krytycznych procesów |
Najczęstszy błąd widzę przy retencji logów ustawionej bezterminowo. Jeśli logi są potrzebne przez 14 dni do bieżącego debugowania, nie ma powodu przechowywać ich w tej samej klasie przez kilka lat. Dane audytowe i analityczne można przenieść do tańszego magazynu, zachowując odpowiednią politykę dostępu.
CloudWatch, Prometheus i Grafana nie są tym samym wyborem
CloudWatch jest naturalnym punktem startowym, gdy infrastruktura działa głównie w AWS i zależy nam na szybkiej integracji z EC2, Lambdą, ECS, RDS czy API Gateway. Nie trzeba utrzymywać własnych serwerów monitoringu, a alarmy mogą od razu uruchamiać mechanizmy AWS.
Prometheus i Grafana dają większą kontrolę nad modelem metryk, wizualizacjami i środowiskiem wielochmurowym. Ceną jest dodatkowa administracja, zarządzanie retencją, wysoką dostępnością i integracjami. W Kubernetes często spotykam model mieszany, w którym Prometheus zbiera metryki klastra, a CloudWatch obsługuje logi, alarmy AWS i dane billingowe.
| Kryterium | CloudWatch | Prometheus i Grafana |
|---|---|---|
| Start w AWS | Szybki, integracje są gotowe | Wymaga konfiguracji i utrzymania |
| Koszt | Opłata za wykorzystane funkcje | Koszt infrastruktury i przechowywania |
| Elastyczność metryk | Dobra, ale zależna od modelu usługi | Bardzo duża kontrola i PromQL |
| Multi-cloud | Możliwy, lecz wymaga integracji | Naturalniejszy dla wielu środowisk |
| Automatyzacja AWS | Silna integracja z SNS, Auto Scaling i EventBridge | Potrzebne dodatkowe konektory |
Nie wybierałbym narzędzia wyłącznie na podstawie wyglądu dashboardu. Ważniejsze jest to, kto będzie reagował na alert, jak szybko trzeba wykryć problem i czy zespół chce utrzymywać własną platformę obserwowalności.
Błędy, które psują monitoring mimo poprawnej konfiguracji
Najbardziej zdradliwe są alarmy oparte na niewłaściwej agregacji. Średnia może wyglądać dobrze, gdy niewielka grupa użytkowników doświadcza bardzo dużych opóźnień. Dlatego dla czasu odpowiedzi analizuję również percentyle p95 lub p99, a nie tylko średnią.
Drugim problemem jest brak rozróżnienia środowisk. Metryka produkcji i testów powinna mieć osobny wymiar, konto albo region. W przeciwnym razie dashboard i alarm mogą mieszać dane, a zespół zacznie ignorować powiadomienia.
- Brak testu alarmu sprawia, że nie wiadomo, czy działa SNS, uprawnienia i eskalacja.
- Logi bez kontekstu utrudniają połączenie błędu z konkretnym żądaniem.
- Zbyt niski próg generuje hałas zamiast informacji.
- Brak retencji zwiększa rachunek i może naruszać zasady przechowywania danych.
- Monitorowanie tylko infrastruktury nie pokaże, że działający serwer zwraca błędne odpowiedzi.
W nowszych wdrożeniach warto rozważyć Application Signals i OpenTelemetry. Pierwsze rozwiązanie ułatwia obserwowanie wskaźników aplikacyjnych, takich jak ruch, błędy i opóźnienia, a drugie ogranicza przywiązanie instrumentacji do jednego dostawcy. Nadal trzeba jednak kontrolować koszty i jakość danych, bo automatyzacja nie zastępuje dobrych progów ani sensownego modelu SLO.
Dobry pierwszy dzień z monitoringiem AWS
Na początek utworzyłbym jeden dashboard dla najważniejszej usługi, grupę logów z krótką retencją oraz trzy alarmy: dostępność, błędy 5xx i opóźnienie p95. Taki mały zestaw daje więcej niż kilkadziesiąt wykresów, których nikt nie otwiera po wdrożeniu.
Po kilku dniach obserwacji można dopasować progi do rzeczywistego ruchu, dodać metryki biznesowe i połączyć alerty z procedurą obsługi incydentów. Największą wartość daje nie sama liczba zebranych danych, lecz szybka odpowiedź na pytanie, co się zepsuło i co należy zrobić dalej.
