Państwa instancja EC2 przestała odpowiadać, a CloudWatch pokazuje, że wszystko jest w porządku? Klasyka. AWS „od ręki" udostępnia metryki CPU, sieci, wejścia-wyjścia dysku, ale nie pokazuje wykorzystania pamięci ani wolnego miejsca na dysku. Te dane są ukryte wewnątrz maszyny wirtualnej i dopóki ich Państwo nie wydobędą na zewnątrz, lecą Państwo na ślepo.

Kiedy kończy się pamięć, instancja nie ostrzega, po prostu pada. OOM Killer zabija procesy w losowej kolejności i zastanawiają się Państwo: wtyczka padła? baza siadła? A rzecz w tym, że skończyły się gigabajty RAM-u, których Państwo nie monitorowali. Z dyskiem jest ta sama historia: logi, backupy, pliki tymczasowe niepostrzeżenie zapychają przestrzeń dyskową i pewnego ranka pojawia się No space left on device.

Rozwiązaniem jest CloudWatch Agent, standardowy agent AWS, który zbiera metryki pamięci, dysku, swap oraz jeszcze dwa tuziny metryk systemowych i wysyła je do CloudWatch. Konfiguracja zajmuje 20 minut i mieści się w bezpłatnym limicie (10 niestandardowych metryk miesięcznie). Poniżej, krok po kroku, od IAM do gotowego dashboardu.

💡 Szybki przegląd:

• Utwórz politykę IAM z cloudwatch:PutMetricData i przypisz ją do użytkownika
• Pobierz i zainstaluj CloudWatch Agent na instancji Ubuntu
• Skonfiguruj plik JSON: pamięć, dysk, swap
• Uruchom agenta i sprawdź, czy metryki trafiają do CloudWatch
• Zbuduj niestandardowy dashboard z wykresami wykorzystania pamięci i dysku

Zarządzanie tożsamością i dostępem AWS

Agent potrzebuje uprawnień do wysyłania metryk do CloudWatch. W tym celu utworzymy politykę IAM i przypiszemy ją do użytkownika z dostępem programowym.

Polityka IAM

Proszę otworzyć konsolę IAM, przejść do Polityki → Utwórz politykę i przełączyć się na zakładkę JSON. Proszę wkleić ten dokument:

1
{
2
    "Version": "2012-10-17",
3
    "Statement": [
4
        {
5
            "Sid": "CloudWatchAgentMetrics",
6
            "Effect": "Allow",
7
            "Action": [
8
                "cloudwatch:PutMetricData",
9
                "ec2:DescribeTags",
10
                "cloudwatch:GetMetricStatistics",
11
                "cloudwatch:ListMetrics"
12
            ],
13
            "Resource": "*"
14
        }
15
    ]
16
}

Proszę kliknąć Sprawdź politykę, nadać nazwę (na przykład CloudWatchAgentPolicy) i kliknąć Utwórz politykę.

Użytkownik IAM

Proszę przejść do Użytkownicy → Dodaj użytkownika. Proszę nadać nazwę i koniecznie zaznaczyć checkbox „Dostęp programowy", który da Access Key ID i Secret Access Key, używane przez agenta do uwierzytelniania.

Na ekranie uprawnień proszę wybrać Dołącz istniejące polityki bezpośrednio. W filtrze typu polityki proszę wskazać Zarządzane przez klienta, dzięki czemu szybciej znajdą Państwo właśnie utworzoną CloudWatchAgentPolicy.

Proszę zaznaczyć politykę ptaszkiem i kliknąć Dalej → Utwórz użytkownika. AWS pokaże ekran z kluczami dostępu, proszę zapisać Access Key ID i Secret Access Key właśnie teraz. Jeśli zamkną Państwo stronę, klucze znikną na zawsze i trzeba będzie je utworzyć ponownie.

Instalacja CloudWatch Agent

Stare skrypty monitorujące w Perlu (CloudWatchMonitoringScripts-1.2.2.zip) od dawna są oznaczone jako przestarzałe. Aktualnym sposobem jest ujednolicony CloudWatch Agent, który zbiera nie tylko pamięć i dysk, ale także swap, obciążenie procesora, interfejsy sieciowe oraz jeszcze dwa tuziny metryk „od ręki".

Pobieranie i instalacja

Proszę połączyć się z instancją przez SSH i pobrać pakiet agenta dla Ubuntu:

1
wget https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb

Proszę zainstalować pakiet przez dpkg:

1
sudo dpkg -i amazon-cloudwatch-agent.deb

Jeśli menedżer pakietów zgłosi brakujące zależności, proszę je doinstalować jedną komendą:

1
sudo apt-get install -f

Agent jest zainstalowany, ale jeszcze nie wie, jakie metryki zbierać i z jakimi kluczami komunikować się z CloudWatch. Skonfigurujemy to.

Proszę zwrócić uwagę: agent jest również dostępny przez AWS Systems Manager (SSM). Jeśli mają Państwo dziesiątki instancji, wygodniej jest wdrożyć go centralnie przez Run Command, bez SSH na każdą maszynę. Dla jednej-dwóch instancji ręczna instalacja jest prostsza i szybsza.

Konfiguracja agenta

Tworzenie pliku konfiguracyjnego

Konfiguracja CloudWatch Agent to dokument JSON, który opisuje, jakie metryki zbierać i z jaką częstotliwością. Proszę uruchomić wbudowany kreator:

1
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

Kreator zada kilka pytań w trybie interaktywnym: na którym serwerze (EC2/on-premises), gdzie wysyłać metryki (CloudWatch), jakie metryki zbierać. Do monitorowania pamięci i dysku proszę podać następujące odpowiedzi:

• Operating system: Linux
• Are you using Amazon EC2?: Yes
• Which metrics to collect: Custom metrics (mem oraz disk_used_percent)
• Resolution: 60 sekund (Standard)
• Log files: proszę pominąć, jeśli logi nie są potrzebne

Na wyjściu kreator wygeneruje plik config.json w katalogu /opt/aws/amazon-cloudwatch-agent/bin/. Oto minimalny działający przykład, memory used percent + disk used percent + swap:

1
{
2
    "agent": {
3
        "metrics_collection_interval": 60,
4
        "run_as_user": "root"
5
    },
6
    "metrics": {
7
        "metrics_collected": {
8
            "mem": {
9
                "measurement": [
10
                    "mem_used_percent"
11
                ]
12
            },
13
            "disk": {
14
                "measurement": [
15
                    "disk_used_percent"
16
                ],
17
                "resources": [
18
                    "/"
19
                ]
20
            },
21
            "swap": {
22
                "measurement": [
23
                    "swap_used_percent"
24
                ]
25
            }
26
        }
27
    }
28
}

Parametr resources dla disk wskazuje punkt montowania: "/", główny wolumin EBS NVMe SSD, podstawową pamięć masową instancji. Jeśli mają Państwo dodatkowe woluminy (na przykład /data), proszę dodać je do tablicy.

Poświadczenia agenta

Klucze dostępu zapisane na etapie IAM należy przekazać agentowi. Proszę utworzyć plik z poświadczeniami w katalogu domowym użytkownika:

1
sudo nano /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml

Proszę dodać sekcję:

1
[credentials]
2
    shared_credential_profile = "AmazonCloudWatchAgent"

I wpisać poświadczenia w standardowym pliku credentials AWS:

1
aws configure --profile AmazonCloudWatchAgent

System zapyta o Access Key ID, Secret Access Key i region. Po wypełnieniu agent będzie mógł wysyłać metryki w imieniu utworzonego użytkownika IAM.

Alternatywna ścieżka, rola IAM, dołączona do instancji. Jest to bezpieczniejsze (klucze nie leżą na dysku) i prostsze przy skalowaniu. Jeśli uruchamiają Państwo EC2 z rolą IAM, która ma uprawnienie cloudwatch:PutMetricData, agent automatycznie przejmie uprawnienia, krok z poświadczeniami można pominąć.

Testowanie

Proszę uruchomić agenta ręcznie i sprawdzić, czy metryki napływają:

1
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
2
  -a fetch-config \
3
  -m ec2 \
4
  -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json \
5
  -s

Flaga -s uruchamia agenta jako usługę. Po minucie lub dwóch pierwsze metryki pojawią się w CloudWatch. Aby upewnić się, że dane płyną, proszę otworzyć konsolę CloudWatch, przejść do sekcji Metrics → All metrics i znaleźć przestrzeń nazw CWAgent (agent domyślnie zapisuje dane właśnie tam).

Po rozwinięciu przestrzeni nazw zobaczą Państwo wymiary InstanceId, podzielone według metryk: mem_used_percent, disk_used_percent oraz swap_used_percent. Kliknięcie dowolnego wiersza buduje wykres, można od razu ocenić, że dane napływają i wyglądają sensownie.

Cztery podstawowe metryki (pamięć, dysk, swap, CPU) na dwóch instancjach, to 8 metryk. Bezpłatny limit CloudWatch, 10 niestandardowych metryk miesięcznie, opisano na stronie z cenami. Mieszczą się w nim Państwo. Jeśli instancji jest więcej niż trzy, część metryk przekroczy limit, ale cena jest skromna: 0,30 USD za metrykę miesięcznie (dane AWS na rok 2026).

Konfiguracja harmonogramu

Agent domyślnie działa jako usługa systemd i wysyła metryki z interwałem określonym w metrics_collection_interval (60 sekund w naszym konfigu). Dodatkowe wpisy cron nie są potrzebne, systemd sam pilnuje, aby agent był aktywny i restartował się w razie awarii.

Proszę sprawdzić status:

1
sudo systemctl status amazon-cloudwatch-agent

Proszę upewnić się, że usługa jest active (running) i włączona do automatycznego uruchamiania (enabled). Jeśli nie, proszę ją uruchomić i włączyć:

1
sudo systemctl enable amazon-cloudwatch-agent
2
sudo systemctl start amazon-cloudwatch-agent

Po ponownym uruchomieniu instancji agent uruchomi się automatycznie.

Poglądowa demonstracja całego procesu, od IAM po dashboard, w tym filmie:

Tworzenie niestandardowego dashboardu

Metryki napływają, teraz trzeba je ładnie opakować. Pokażę, jak zbudować dashboard do monitorowania instancji produkcyjnej: pamięć, dysk, obciążenie CPU oraz saldo kredytowe (dla serii T) na jednym ekranie.

Tworzenie dashboardu

W konsoli CloudWatch przejdź Pan/Pani do Dashboards → Create dashboard. Proszę nadać nazwę (na przykład Production-EC2) i wybrać typ widżetu.

Proszę wybrać Line dla pierwszego wykresu, ten typ najlepiej nadaje się do wyświetlania metryk w danym okresie.

Widżet wykresu

Proszę kliknąć Add widget i wybrać typ Line, prosty wykres liniowy, najlepsza opcja dla większości metryk. W oknie dialogowym proszę kliknąć Configure i przejść do przestrzeni nazw CWAgent.

Proszę znaleźć metrykę mem_used_percent dla swojej instancji (po InstanceId) i kliknąć wiersz, CloudWatch natychmiast pokaże wykres.

Wskazówka: typ Stacked area sprawdza się, gdy na jednym widżecie jest kilka metryk (na przykład pamięć + swap); Number służy do natychmiastowego odczytu bieżącej wartości (wygodnie umieścić go w rogu dashboardu); Text jest przeznaczony do nagłówków i notatek między wykresami.

Dostrajanie wykresu

Kilka ustawień, które czynią wykres czytelnym:

• Okres: jeśli agent wysyła metryki co minutę, proszę wybrać okres 1 minuta, aby widzieć pełną rozdzielczość danych.

• Nazwa: proszę zmienić nazwę legendy wykresu na coś zrozumiałego dla człowieka, „RAM used%", a nie mem_used_percent / i-1234567890abcdef0.

• Maksimum osi Y (Graph options): proszę ustalić limit (na przykład 100 dla wartości procentowych lub 16 dla 16 GB RAM). Bez tego CloudWatch automatycznie skaluje oś i niewielki skok wygląda równie groźnie jak sytuacja krytyczna. Ze stałym limitem od razu widać, jak blisko jest do krawędzi.

Proszę kliknąć Create widget, pierwszy blok dashboardu jest gotowy. Proszę powtórzyć dla każdej metryki: disk_used_percent, potem swap_used_percent, potem cpu_usage (wbudowana metryka EC2, nie z CWAgent) i CPUCreditBalance dla serii T. Widżety można przeciągać, zmieniać ich rozmiar, edytować. Gdy wszystko wygląda jak trzeba, proszę kliknąć Save dashboard.

Dashboard jest gotowy. Proszę dodać go do ulubionych (gwiazdka w górnym menu) i wracać jednym kliknięciem, gdy trzeba sprawdzić stan instancji przed wdrożeniem lub po skoku ruchu.

⁉️🤔 Często zadawane pytania

Dlaczego standardowe metryki EC2 nie obejmują pamięci i dysku?

AWS wirtualizuje CPU i sieć na poziomie hypervisora, te metryki są dostępne z zewnątrz, bez wchodzenia do systemu gościa. Pamięć i dysk to wewnętrzne zasoby maszyny wirtualnej, hypervisor o nich nie wie. Aby je zobaczyć, potrzebny jest agent wewnątrz systemu operacyjnego, który odczytuje /proc/meminfo i df oraz wysyła dane do CloudWatch. CloudWatch Agent robi dokładnie to: co minutę odpytuje liczniki systemowe i wysyła je do przestrzeni nazw CWAgent. Pełna lista, obejmująca dwadzieścia kilka metryk, znajduje się w oficjalnej dokumentacji AWS.

Ile to kosztuje?

Dla typowego scenariusza „1-2 instancje, po 4 metryki na każdą" nic. Bezpłatny limit CloudWatch obejmuje 10 metryk niestandardowych, 10 alarmów i 3 dashboardy na konto miesięcznie, zgodnie ze stroną z cennikiem CloudWatch. Dwie instancje po 4 metryki = 8 z 10 bezpłatnych. Jeśli instancji jest więcej niż trzy, przekroczenie limitu kosztuje 0,30 USD za metrykę miesięcznie. Dla kilkunastu serwerów to 6-9 USD miesięcznie, cena za brak niespodzianek o trzeciej w nocy.

Czym CloudWatch Agent jest lepszy od starych skryptów Perla?

Skrypty Perla (mon-put-instance-data.pl) są oficjalnie przestarzałe (deprecated) od 2023 roku i nie otrzymują aktualizacji. CloudWatch Agent to standardowe, wspierane narzędzie, które zapisuje dane nie tylko do CloudWatch, ale i do Amazon Managed Prometheus; zbiera metryki przez StatsD i collectd; potrafi wysyłać logi i ślady (traces). Co najważniejsze, integruje się z Systems Manager, co oznacza, że na 50 instancji wdraża się go jedną komendą z konsoli, bez SSH. Jeśli wciąż działają u Pana/Pani skrypty Perla, proszę migrować: stary format awscreds.conf z kluczami jawnie na dysku to dziura w bezpieczeństwie. CloudWatch Agent współpracuje z rolami IAM i nie wymaga przechowywania sekretów w pliku tekstowym.

Co zrobić, jeśli metryki nie pojawiają się w CloudWatch?

Proszę sprawdzić po kolei: (1) status usługi przez systemctl status amazon-cloudwatch-agent, powinien być active; (2) logi agenta w /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log, tam będzie konkretny błąd; (3) uprawnienia IAM, użytkownik lub rola musi mieć zezwolenie cloudwatch:PutMetricData; (4) region, agent i konsola muszą wskazywać ten sam region AWS. Z mojego doświadczenia wynika, że w zdecydowanej większości przypadków problem leży albo w uprawnieniach, albo w niezgodności regionu.

Czy można monitorować instancje Windows?

Tak, CloudWatch Agent wspiera Windows Server na równi z Linuxem. Instalacja odbywa się przez instalator MSI z tego samego zasobnika S3 (amazon-cloudwatch-agent.s3.amazonaws.com/windows/amd64/latest/). Konfiguracja to ten sam JSON, ale nazwy metryk są inne: zamiast mem_used_percent jest Memory % Committed Bytes In Use. Kreator konfiguracji w Windows sam podstawi poprawne nazwy.

Co daje monitorowanie pamięci i dysku w praktyce

Uruchomił Pan/Pani CloudWatch Agent na instancji Ubuntu, skonfigurował zbieranie danych o pamięci, dysku i swapie, podpiął dashboard z wykresami. Co się zmieniło? Dokładnie jedna rzecz: zniknął martwy punkt. Widzi Pan/Pani nie tylko CPU i sieć, ale także dwóch głównych zabójców instancji: wyciek pamięci i zapchany dysk.

W praktyce oznacza to: zauważa Pan/Pani, że zużycie pamięci pełznie w górę na trzy dni ZANIM OOM Killer ubije PHP-FPM. Widzi Pan/Pani, że dysk zapełnił się prawie całkowicie po aktualizacji motywów i czyści logi ZANIM padnie baza danych. Bez tych metryk każdy incydent to dochodzenie post mortem. Z nimi jest alert na kanale na pół godziny przed awarią.

Jeśli ma Pan/Pani więcej niż trzy instancje, proszę skonfigurować CloudWatch Alarms na wartości progowe (powiedzmy mem_used_percent > 90 przez 5 minut) i podłączyć powiadomienia przez SNS do Slacka lub Telegrama. Agent + alarmy = dowiaduje się Pan/Pani o problemie nie od klienta, a od AWS.

Konfiguracja agenta to jednorazowa inwestycja 20 minut na instancję. Potem działa on sam.