서버가 죽은 걸 사용자 항의로 처음 알게 되면 이미 늦습니다. AWS CloudWatch는 메트릭·로그·알람 세 가지로 "문제를 먼저 알아채는" 체계를 만듭니다. 셋을 구분해서 이해하면 무엇을 어디에 설정할지가 명확해집니다.
세 가지 축
| 축 | 무엇 | 예시 |
|---|---|---|
| 메트릭(Metric) | 시간에 따른 수치 | CPU 사용률, 요청 수, 지연시간 |
| 로그(Logs) | 텍스트 이벤트 기록 | 애플리케이션 로그, 에러 스택 |
| 알람(Alarm) | 조건 충족 시 알림 | "CPU > 80% 5분 지속 시" |
메트릭은 "얼마나"를, 로그는 "무슨 일이"를 답합니다. 알람은 둘 중 어느 쪽에든 걸 수 있어서, 수치가 임계치를 넘거나 로그에 특정 패턴이 나타나면 알려줍니다.
메트릭 기반 알람 만들기
가장 기본은 지표가 임계치를 넘으면 알리는 알람입니다.
로컬 터미널
aws cloudwatch put-metric-alarm \
--alarm-name high-cpu \
--namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-0abc123 \
--statistic Average --period 300 \
--threshold 80 --comparison-operator GreaterThanThreshold \
--evaluation-periods 2 \
--alarm-actions arn:aws:sns:ap-northeast-2:111122223333:ops-alert
evaluation-periods 2는 5분 구간이 연속 2번 임계치를 넘어야 발동한다는 뜻입니다. 일시적 스파이크에 알람이 울리는 걸 막습니다. alarm-actions에는 SNS 토픽을 연결해 이메일·Slack으로 알림을 보냅니다.
로그에서 에러를 잡아내기
CPU는 멀쩡한데 애플리케이션이 에러를 쏟는 경우는 메트릭으로 안 보입니다. 이때 메트릭 필터로 로그의 특정 패턴을 수치 메트릭으로 바꿔 알람을 겁니다.
- 애플리케이션 로그를 CloudWatch Logs 로그 그룹으로 보냅니다(EC2면 CloudWatch Agent).
- 로그 그룹에 메트릭 필터를 만들어
ERROR같은 패턴이 나올 때마다 카운트를 올립니다.
로컬 터미널
aws logs put-metric-filter \
--log-group-name /app/web \
--filter-name error-count \
--filter-pattern "ERROR" \
--metric-transformations \
metricName=AppErrorCount,metricNamespace=App,metricValue=1
- 그
AppErrorCount메트릭에 알람을 걸면, "1분에 에러 10건 초과 시" 같은 조건으로 알림을 받습니다.
탐색적으로 로그를 뒤질 때는 Logs Insights 쿼리가 유용합니다. fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc처럼 즉석에서 필터링합니다.
요점 정리
- 메트릭=수치, 로그=이벤트 기록, 알람=조건 알림. 셋을 구분하면 설계가 쉬워진다.
- 지표 알람은
evaluation-periods로 일시적 스파이크 오탐을 막는다. - 로그의 에러 패턴은 메트릭 필터로 수치화해 알람을 건다.
- 알람은 SNS로 이메일·Slack에 연결해 즉시 통보받는다.
CloudWatch로 메트릭 알람과 로그 기반 알람을 직접 걸어보는 실습은 클라우드 트랙에서 회원가입 없이 무료로 할 수 있습니다.