CloudWatch 로그·메트릭·알람

요약: 로그·메트릭·알람으로 장애와 비용을 같은 날 알아채는 관측 기본선을 만든다.

---

1. 언제 CloudWatch를 먼저 다는가

CloudWatch는 AWS의 관측 서비스다. 메트릭을 모으고, 로그를 저장하고, 임계값을 넘으면 알린다. 모니터링 없이 인스턴스만 키우면 장애는 사용자 신고로 알고, 비용은 청구서에서 안다.

배포 완료 조건에 넣는다. “나중에 대시보드”는 보통 안 온다.

최소 세트:

신호	예
메트릭	CPU, 5xx, 지연, RDS 여유 스토리지
로그	앱, ALB, RDS 로그
알람	임계값 → SNS → 메일/슬랙
대시보드	한 화면 요약

분산 추적(X-Ray, OpenTelemetry)은 그다음이다. 메트릭+로그+알람이 없으면 추적만 화려하다.

---

2. 핵심 개념

네임스페이스·디멘션. 메트릭은 이름과 차원(인스턴스 id, 타깃 그룹 등)으로 구분된다. 잘못된 차원은 알람이 영원히 안 울린다.

로그 그룹 / 로그 스트림. 그룹에 보존 기간을 정한다. 무기한은 비용이다. 이름 규칙 예: /app/dev/api.

에이전트. EC2면 CloudWatch 에이전트 또는 시스템 로그 연동. 컨테이너면 사이드카·FireLens. 앱이 stdout으로만 찍고 수집이 없으면 운영 로그가 아니다.

알람. 통계(Average, Sum), 기간, 평가 횟수를 고른다. 한 번 튀고 끝나는 값에 과민하면 알람 피로가 온다. 반대로 15분 평균만 보면 장애를 놓친다.

SNS. Simple Notification Service. 알람이 주제를 발행하고 구독이 메일·챗으로 간다. 구독 확인을 안 하면 침묵이다.

비용. 커스텀 메트릭, 로그 수집량, Insights 쿼리가 요금이다. DEBUG를 프로덕션에 상시 켜 두지 않는다. 카드번호·토큰·비밀번호를 로그에 남기지 않는다.

---

3. 최소 예제 — 5xx와 디스크

ALB 5xx와 RDS 스토리지를 먼저 단다. 앱이 없어도 인프라는 말한다.

알람 개념(콘솔 또는 CLI). 계정·ARN은 플레이스홀더다.

aws cloudwatch put-metric-alarm \
  --alarm-name alb-5xx-dev \
  --alarm-description "ALB target 5xx" \
  --metric-name HTTPCode_Target_5XX_Count \
  --namespace AWS/ApplicationELB \
  --statistic Sum \
  --period 60 \
  --threshold 5 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 3 \
  --alarm-actions arn:aws:sns:REGION:YOUR_ACCOUNT_ID:ops-alerts

로그 그룹 보존:

aws logs put-retention-policy \
  --log-group-name /app/dev/api \
  --retention-in-days 14

앱 로그 한 줄은 검색 가능한 JSON이 유리하다. 비밀은 마스킹한다.

{"level":"info","msg":"order created","orderId":"ord_123","userId":"u_42"}

대시보드는 위젯 네 개면 시작이다. ALB 5xx, 타깃 응답 시간, EC2/ECS CPU, RDS FreeStorageSpace. 예쁜 그래프보다 알람 연동이 먼저다.

빌링 알람은 계정 글에서 켠 예산을 CloudWatch 결제 메트릭과 중복해도 된다. 겹치는 편이 안 울리는 것보다 낫다.

---

4. 운영 시 주의

노이즈. 개발 환경 알람을 프로덕션 채널에 섞지 않는다. 주제 이름에 dev/prod를 넣는다. 무시하는 알람은 지워거나 임계를 고친다. 죽은 알람이 진짜 장애를 가린다.

연결. 에이전트가 IAM 역할 없이 메트릭을 못 보낸다. 역할에 cloudwatch:PutMetricData, 로그면 logs:PutLogEvents 등 최소 액션만. 인스턴스에 키를 두지 않는다.

보존. 규제 로그와 앱 디버그 로그의 기간을 나눈다. 개인정보(PII)는 수집 자체를 줄인다. 이미 남았으면 보존을 짧게.

비용. 고해상도 커스텀 메트릭을 남발하지 않는다. 로그 Insights를 넓은 시간 범위로 돌리면 스캔 요금이 난다. 필터를 먼저 좁힌다.

장애 훈련. 고의로 헬스체크를 실패시켜 알람이 오는지 본다. 안 오면 디멘션·통계·구독 확인이 잘못된 것이다.

X-Ray는 API가 여러 서비스로 갈 때 붙인다. 처음부터 샘플 100%는 비용이다. 샘플링을 정한다.

로그 메트릭 필터. “ERROR” 문자열이 분당 N회면 알람을 달 수 있다. 앱이 커스텀 메트릭을 안 보내도 시작 가능하다. 필터가 너무 넓으면 알람이 항상 켜진다. 스테이징에서 문장을 맞춘다.

합성(Canary). 1분마다 /health를 밖에서 때린다. 내부 메트릭은 멀쩡한데 DNS·인증서만 죽은 경우를 잡는다. 실행 횟수가 곧 요금이다. 프로덕션 URL만, 주기를 합의한다.

대시보드 피로. 위젯 30개는 안 본다. 서비스당 한 화면, 알람이 가리키는 메트릭만. 런북 링크를 알람 설명에 넣는다.

---

5. 정리

관측은 사후 도구가 아니다. 배포 완료 조건이다. 메트릭 세 개, 로그 보존, 알람 세 개, SNS 구독 확인이면 초반으로 충분하다.

체크리스트

• ALB 5xx 또는 앱 에러율 알람을 단다. 사용자보다 우리가 먼저 알아야 한다.
• RDS/디스크 여유 공간 알람을 단다. 스토리지 풀은 복구가 급하다.
• 로그 보존 일수를 정한다. 무기한 수집은 청구서다.
• SNS 구독을 확인한다. 미확인 메일은 알람이 없는 것과 같다.
• 토큰·PII가 로그에 없는지 샘플을 검사한다. 로그 유출은 데이터 유출이다.

연습

1. SNS 주제를 만들고 메일 구독을 확인한 뒤 테스트 알람을 보낸다.
2. 로그 그룹 보존을 14일로 설정하고 콘솔에 반영됐는지 본다.
3. ALB 또는 앱 메트릭 하나를 골라 디멘션이 맞는지 그래프로 확인한다.

결제 메트릭 알람은 계정 루트가 아니라 운영 메일로 보낸다. EstimatedCharges가 전날보다 급증하면 키 유출·리전 실수·NAT 트래픽일 수 있다. 인프라 5xx와 같은 채널에 섞어도 되고, billing-alerts 주제로 나눠도 된다. 안 오는 쪽이 문제다.

로그 그룹 생성은 Terraform/CDK에 넣는다. 콘솔에서만 만들면 앱 역할의 CreateLogGroup이 필요해지고, 권한이 넓어진다. 그룹을 미리 만들고 앱은 PutLogEvents만 하게 한다.

알람 설명에 “보면 되는 대시보드, 할 일”을 한 줄 넣는다. ALB 5xx — 타깃 헬스와 /health 확인이면 새벽 호출이 짧아진다. 이름만 alarm-1이면 아무도 못 움직인다.

개발 계정 알람은 슬랙 #dev-alerts, 프로덕션은 #prod-alerts로 나눈다. 한 채널에 둘 다 넣으면 결국 뮤트한다.

컨테이너면 태스크 정의에 awslogs 드라이버와 그룹 이름만 맞으면 된다. 그룹이 없고 생성 권한이 없으면 컨테이너는 떠도 로그가 안 보인다. 배포 체크에 “로그 스트림이 1분 안에 생기는지”를 넣는다.

---

---