Monitoring na AWS - CloudWatch, X-Ray i alarmy które działają

Dlaczego monitoring to nie opcja, a konieczność?

Wrzuciłeś aplikację na AWS, działa, klient zadowolony. Trzy tygodnie później dostajesz telefon o 3 w nocy: "strona nie działa". Wchodzisz na konsolę, a tam 100% CPU na EC2, pełny dysk, baza danych w timeout. Bez monitoringu to nie jest pytanie czy się zdarzy, ale kiedy.

Dobrze skonfigurowany monitoring robi trzy rzeczy:

• Wykrywa problemy zanim użytkownicy je zauważą - alarm o 80% CPU jest lepszy niż telefon o 100%
• Daje dane do optymalizacji kosztów - jeśli EC2 używa średnio 15% CPU, przepłacasz za instancję
• Skraca czas diagnozowania - zamiast zgadywać, widzisz dokładnie co się stało i kiedy

Na AWS głównym narzędziem monitoringu jest Amazon CloudWatch (dokumentacja). Uzupełniają go AWS X-Ray do tracingu i Amazon SNS do powiadomień. Razem tworzą kompletny system obserwacyjności (observability).

CloudWatch - centrum dowodzenia monitoringiem

Metryki (Metrics) - co AWS mierzy automatycznie

CloudWatch automatycznie zbiera metryki z większości serwisów AWS. Nie musisz nic konfigurować - wystarczy uruchomić usługę, a metryki pojawiają się same:

Instalacja CloudWatch Agent na EC2

CloudWatch Agent to lekki daemon, który wysyła metryki pamięci, dysku i logi systemowe do CloudWatch. Bez niego widzisz tylko to, co hypervisor reportuje z zewnątrz instancji.

# Połącz się z instancją EC2 przez SSH
ssh ec2-user@your-instance-ip

# Zainstaluj agenta (Amazon Linux 2023)
sudo yum install amazon-cloudwatch-agent -y

# Utwórz konfigurację
sudo tee /opt/aws/amazon-cloudwatch-agent/etc/config.json <<'AGENT'
{
  "metrics": {
    "append_dimensions": {"InstanceId": "${aws:InstanceId}"},
    "metrics_collected": {
      "mem": {
        "measurement": ["mem_used_percent"],
        "metrics_collection_interval": 60
      },
      "disk": {
        "measurement": ["disk_used_percent"],
        "resources": ["/"],
        "metrics_collection_interval": 60
      }
    }
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/messages",
            "log_group_name": "/ec2/system-logs",
            "log_stream_name": "{instance_id}"
          },
          {
            "file_path": "/var/log/httpd/access_log",
            "log_group_name": "/ec2/apache-access",
            "log_stream_name": "{instance_id}"
          }
        ]
      }
    }
  }
}
AGENT

# Uruchom agenta
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config -m ec2 \
  -c file:/opt/aws/amazon-cloudwatch-agent/etc/config.json -s

# Sprawdź status
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a status

Custom Metrics - twoje własne metryki

Poza metrykami systemowymi, możesz wysyłać do CloudWatch dowolne metryki biznesowe: liczbę zamówień na minutę, czas odpowiedzi API, ilość elementów w kolejce. To daje prawdziwy obraz zdrowia aplikacji.

# Wyślij pojedynczą metrykę
aws cloudwatch put-metric-data \
  --namespace "MojaAplikacja" \
  --metric-name "AktywniUzytkownicy" \
  --value 42 \
  --unit Count

# Wyślij metrykę z wymiarami (dimensions)
aws cloudwatch put-metric-data \
  --namespace "MojaAplikacja" \
  --metric-name "CzasOdpowiedzi" \
  --value 230 \
  --unit Milliseconds \
  --dimensions Endpoint=/api/orders,Method=GET

# Wyślij wiele metryk naraz (batch)
aws cloudwatch put-metric-data \
  --namespace "MojaAplikacja" \
  --metric-data '[
    {"MetricName":"Zamowienia","Value":15,"Unit":"Count"},
    {"MetricName":"Przychod","Value":4500,"Unit":"None"}
  ]'

W kodzie Python (np. w Lambdzie) wysyłanie custom metrics wygląda tak:

import boto3
from datetime import datetime

cloudwatch = boto3.client('cloudwatch')

cloudwatch.put_metric_data(
    Namespace='MojaAplikacja',
    MetricData=[
        {
            'MetricName': 'CzasOdpowiedzi',
            'Timestamp': datetime.utcnow(),
            'Value': 230.5,
            'Unit': 'Milliseconds',
            'Dimensions': [
                {'Name': 'Endpoint', 'Value': '/api/orders'},
                {'Name': 'Environment', 'Value': 'production'}
            ]
        }
    ]
)

Alarmy CloudWatch - bądź pierwszy, który wie o problemie

Metryki bez alarmów to jak kamera monitoringu, której nikt nie ogląda. Alarm CloudWatch automatycznie reaguje, gdy metryka przekroczy ustaloną wartość.

Tworzenie alarmu krok po kroku

# 1. Utwórz temat SNS do powiadomień
aws sns create-topic --name prod-alerts
# Zanotuj TopicArn z odpowiedzi

# 2. Dodaj subskrypcję email
aws sns subscribe \
  --topic-arn arn:aws:sns:eu-central-1:123456789:prod-alerts \
  --protocol email \
  --notification-endpoint [email protected]

# 3. Utwórz alarm na CPU > 80% przez 3 z 5 okresów
aws cloudwatch put-metric-alarm \
  --alarm-name "prod-web-high-cpu" \
  --alarm-description "CPU powyzej 80% na produkcji" \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abc123def456 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 5 \
  --datapoints-to-alarm 3 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:eu-central-1:123456789:prod-alerts \
  --ok-actions arn:aws:sns:eu-central-1:123456789:prod-alerts

# 4. Alarm na niski wolny RAM (z CloudWatch Agent)
aws cloudwatch put-metric-alarm \
  --alarm-name "prod-web-low-memory" \
  --namespace CWAgent \
  --metric-name mem_used_percent \
  --dimensions Name=InstanceId,Value=i-0abc123def456 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 3 \
  --datapoints-to-alarm 2 \
  --threshold 90 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:eu-central-1:123456789:prod-alerts

Zestaw alarmów, który powinieneś mieć zawsze

Poniżej minimum viable monitoring dla typowej aplikacji webowej na AWS:

CloudWatch Logs - szukaj igły w stogu siana

Logi to drugie oko monitoringu. Metryki mówią "coś jest źle", logi mówią "dlaczego".

Struktura logów w CloudWatch

CloudWatch Logs organizuje dane w hierarchii:

• Log Group - kontener na logi z jednego źródła (np. /aws/lambda/my-function)
• Log Stream - strumień logów z jednej instancji/invocation
• Log Event - pojedynczy wpis (linia logu)

Lambda automatycznie wysyła logi do CloudWatch (grupa /aws/lambda/nazwa-funkcji). Dla EC2 potrzebujesz CloudWatch Agent (zainstalowany wcześniej). Dla ECS/Fargate - wystarczy skonfigurować log driver awslogs.

Logs Insights - zapytania do logów

CloudWatch Logs Insights to język zapytań do przeszukiwania logów. Zamiast przewijać tysiące linii, piszesz zapytanie:

# Top 10 najwolniejszych requestów w ostatniej godzinie
fields @timestamp, @message
| filter @message like /duration/
| parse @message "duration: * ms" as duration
| sort duration desc
| limit 10

# Liczba błędów 500 per endpoint
fields @timestamp, @message
| filter @message like /HTTP 500/
| parse @message "\"* *\"" as method, endpoint
| stats count() as cnt by endpoint
| sort cnt desc

# Błędy Lambda pogrupowane po funkcji
fields @timestamp, @message
| filter @message like /ERROR/
| stats count() as errors by @log
| sort errors desc

# Wyszukaj konkretny request ID
fields @timestamp, @message
| filter @message like /abc-123-request-id/
| sort @timestamp asc

Metric Filters - twórz metryki z logów

Metric Filter to mechanizm, który skanuje logi w czasie rzeczywistym i tworzy metrykę na podstawie dopasowań. Przykład: zlicz wystąpienia słowa "ERROR" i utwórz alarm gdy jest ich za dużo.

# Utwórz metric filter zliczający błędy
aws logs put-metric-filter \
  --log-group-name "/aws/lambda/moja-funkcja" \
  --filter-name "LambdaErrors" \
  --filter-pattern "ERROR" \
  --metric-transformations metricName=LambdaErrorCount,metricNamespace=MojaAplikacja,metricValue=1,defaultValue=0

# Metric filter na timeout bazodanowy
aws logs put-metric-filter \
  --log-group-name "/ec2/app-logs" \
  --filter-name "DBTimeouts" \
  --filter-pattern "\"Connection timed out\"" \
  --metric-transformations metricName=DBTimeoutCount,metricNamespace=MojaAplikacja,metricValue=1

CloudWatch Dashboards - wszystko na jednym ekranie

Dashboard to zbiór widgetów wyświetlających metryki w czasie rzeczywistym. Zamiast skakać między serwisami, masz jeden ekran z pełnym obrazem systemu.

Dobrze zaprojektowany dashboard zawiera:

• Górny rząd: kluczowe wskaźniki biznesowe (requesty/s, błędy, czas odpowiedzi)
• Środek: metryki infrastrukturalne (CPU, RAM, dysk, sieć)
• Dół: szczegóły per-serwis (Lambda, RDS, ALB)

# Utwórz dashboard z CLI (definicja JSON)
aws cloudwatch put-dashboard \
  --dashboard-name "Produkcja" \
  --dashboard-body '{
    "widgets": [
      {
        "type": "metric",
        "x": 0, "y": 0, "width": 12, "height": 6,
        "properties": {
          "title": "Requesty i błędy ALB",
          "metrics": [
            ["AWS/ApplicationELB", "RequestCount", "LoadBalancer", "app/prod-alb/abc123"],
            ["AWS/ApplicationELB", "HTTPCode_Target_5XX", "LoadBalancer", "app/prod-alb/abc123"]
          ],
          "period": 300,
          "stat": "Sum",
          "region": "eu-central-1"
        }
      },
      {
        "type": "metric",
        "x": 12, "y": 0, "width": 12, "height": 6,
        "properties": {
          "title": "CPU instancji EC2",
          "metrics": [
            ["AWS/EC2", "CPUUtilization", "InstanceId", "i-0abc123"]
          ],
          "period": 300,
          "stat": "Average"
        }
      }
    ]
  }'

AWS X-Ray - tracing rozproszonej aplikacji

Gdy Twoja aplikacja to API Gateway → Lambda → DynamoDB → SNS → kolejna Lambda, znalezienie wąskiego gardła bez tracingu jest jak szukanie igły w stogu siana. X-Ray śledzi każdy request od wejścia do wyjścia i pokazuje, ile czasu spędził w każdym serwisie.

Jak działa X-Ray

X-Ray operuje trzema konceptami:

• Trace - pełna ścieżka jednego requestu przez system (od ALB do odpowiedzi)
• Segment - czas spędzony w jednym serwisie (np. Lambda function execution)
• Subsegment - czas spędzony na konkretnej operacji wewnątrz serwisu (np. DynamoDB query)

Włączanie X-Ray w Lambda

# Włącz X-Ray tracing na istniejącej funkcji Lambda
aws lambda update-function-configuration \
  --function-name moja-funkcja \
  --tracing-config Mode=Active

# Dodaj politykę X-Ray do roli Lambda
aws iam attach-role-policy \
  --role-name moja-lambda-role \
  --policy-arn arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess

# Włącz tracing na API Gateway (stage level)
aws apigateway update-stage \
  --rest-api-id abc123 \
  --stage-name prod \
  --patch-operations op=replace,path=/tracingEnabled,value=true

Aby X-Ray śledził wywołania do DynamoDB, S3 czy zewnętrznych API w kodzie Python, użyj biblioteki aws-xray-sdk:

# pip install aws-xray-sdk
from aws_xray_sdk.core import xray_recorder
from aws_xray_sdk.core import patch_all

# Automatycznie instrumentuje boto3, requests, sqlite3
patch_all()

import boto3

def handler(event, context):
    # Każde wywołanie DynamoDB/S3 będzie widoczne w X-Ray
    dynamodb = boto3.resource('dynamodb')
    table = dynamodb.Table('Orders')

    # Własny subsegment na logikę biznesową
    with xray_recorder.in_subsegment('process_order') as subsegment:
        subsegment.put_annotation('order_id', event['order_id'])
        # ... logika przetwarzania ...
        result = table.get_item(Key={'id': event['order_id']})

    return result

Service Map - wizualna mapa systemu

Najlepsza funkcja X-Ray to Service Map - automatycznie generowana mapa połączeń między serwisami z czasami odpowiedzi i procentem błędów. Wchodzisz w X-Ray → Service Map i widzisz np.:

• API Gateway → Lambda (avg 45ms, 0.1% errors)
• Lambda → DynamoDB (avg 12ms, 0% errors)
• Lambda → S3 (avg 180ms, 0.5% errors) ← tu jest problem!

Bez X-Ray zgadywałbyś, który serwis spowalnia. Z X-Ray widzisz to na jednym ekranie.

Anomaly Detection - niech AI monitoruje za Ciebie

Ręczne ustawianie progów alarmów ma poważną wadę: ruch o 8 rano jest inny niż o 3 w nocy. Anomaly Detection w CloudWatch automatycznie uczy się wzorców Twoich metryk i alarmuje, gdy zachowanie odbiega od normy.

# Utwórz alarm z anomaly detection zamiast statycznego progu
aws cloudwatch put-metric-alarm \
  --alarm-name "prod-anomaly-requests" \
  --comparison-operator GreaterThanUpperThreshold \
  --evaluation-periods 3 \
  --datapoints-to-alarm 2 \
  --threshold-metric-id ad1 \
  --metrics '[
    {"Id":"m1","MetricStat":{"Metric":{"Namespace":"AWS/ApplicationELB","MetricName":"RequestCount","Dimensions":[{"Name":"LoadBalancer","Value":"app/prod-alb/abc123"}]},"Period":300,"Stat":"Sum"}},
    {"Id":"ad1","Expression":"ANOMALY_DETECTION_BAND(m1, 2)"}
  ]' \
  --alarm-actions arn:aws:sns:eu-central-1:123456789:prod-alerts

Koszty monitoringu - ile to kosztuje?

Gotowy stack monitoringowy - Infrastructure as Code

Jeśli używasz Terraform, cały monitoring możesz zdefiniować jako kod:

# monitoring.tf
resource "aws_sns_topic" "alerts" {
  name = "prod-alerts"
}

resource "aws_sns_topic_subscription" "email" {
  topic_arn = aws_sns_topic.alerts.arn
  protocol  = "email"
  endpoint  = "[email protected]"
}

resource "aws_cloudwatch_metric_alarm" "high_cpu" {
  alarm_name          = "prod-high-cpu"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 5
  datapoints_to_alarm = 3
  metric_name         = "CPUUtilization"
  namespace           = "AWS/EC2"
  period              = 300
  statistic           = "Average"
  threshold           = 80

  dimensions = {
    InstanceId = aws_instance.web.id
  }

  alarm_actions = [aws_sns_topic.alerts.arn]
  ok_actions    = [aws_sns_topic.alerts.arn]
}

resource "aws_cloudwatch_log_group" "app" {
  name              = "/ec2/app-logs"
  retention_in_days = 30
}

resource "aws_cloudwatch_dashboard" "main" {
  dashboard_name = "Produkcja"
  dashboard_body = jsonencode({
    widgets = [
      {
        type   = "metric"
        x      = 0
        y      = 0
        width  = 12
        height = 6
        properties = {
          title   = "CPU i Pamięć"
          metrics = [
            ["AWS/EC2", "CPUUtilization", "InstanceId", aws_instance.web.id],
            ["CWAgent", "mem_used_percent", "InstanceId", aws_instance.web.id]
          ]
          period = 300
          stat   = "Average"
        }
      }
    ]
  })
}

FAQ - najczęstsze pytania o monitoring AWS

Co dalej?

1. Zainstaluj CloudWatch Agent na wszystkich instancjach EC2 i skonfiguruj metryki RAM/dysk.
2. Utwórz 10 alarmów z tabeli wyżej - to Twoje minimum viable monitoring.
3. Włącz X-Ray na Lambda i API Gateway i przeanalizuj Service Map.
4. Zbuduj jeden dashboard "Produkcja" z najważniejszymi metrykami.
5. Ustaw retention na log grupach (30 dni dev, 90 dni prod).

Monitoring to fundament, na którym opiera się niezawodność aplikacji. Bez niego reagujesz na problemy. Z nim - zapobiegasz im. Jeśli chcesz zobaczyć monitoring w kontekście pełnej architektury, sprawdź architekturę aplikacji webowej na AWS, a jeśli potrzebujesz automatyzacji deploymentu z wbudowanym monitoringiem, przeczytaj o CI/CD na AWS.