DanzzaN

SOA-C03 02/16 — 수집·경보·대시보드·알림

이 구간은 SAA에서 익힌 CloudWatch로 모니터링한다를 CloudOps의 구체적인 운영 설계로 바꾼다. 공식 점수 보고서에서 Domain 1이 개선 요망으로 관찰됐으므로 관계와 문제 해결 경계를 촘촘히 다루지만, 이를 고정된 약점이나 미숙달 판정으로 해석하지 않는다.

workload
→ 신호 생성·수집
→ metric identity와 시간 의미 부여
→ alarm 조건 평가
→ dashboard로 상황 공유
→ SNS로 사람·시스템에 전달

각 화살표는 별도 실패 지점이다. Dashboard는 조건을 판정하지 않고, SNS는 장애 여부를 결정하지 않으며, alarm의 ALARM 상태는 근본 원인을 증명하지 않는다.

1. 먼저 신호가 존재하는가를 확인한다

필요한 관측값일반적인 수집 경계운영상 확인할 것
AWS 서비스가 기본 제공하는 지표서비스 → CloudWatch Metrics기본·상세 monitoring 수준, 게시 주기, Region·dimension
EC2 guest OS의 memory·disk 사용량인스턴스 내부 CloudWatch agent → CloudWatchagent 설정·실행 상태, IAM 권한, namespace·dimensions
EC2·on-premises의 application logCloudWatch agent → CloudWatch Logs파일 경로, log group·stream, 보존·권한
ECS·EKS의 container 성능과 logContainer Insights와 환경별 collectorcluster 설정, agent/add-on, task·pod 권한, 성능 log event
애플리케이션·업무 상태의 수치PutMetricData, EMF, StatsD·collectd 등 → custom metricmetric 의미, 단위, dimension cardinality, 게시 실패
log pattern의 발생 횟수·값CloudWatch Logs metric filter → custom metricfilter pattern, 새 log ingestion, default value, log class

EC2 관리 경계에서 보이는 CPU·network 신호와 guest OS 안에서만 알 수 있는 memory·filesystem 신호를 구분한다. Memory 압력이 필요한데 기본 EC2 metric만 보고 있다면 alarm 설정 문제가 아니라 수집 경계가 없는 것이다. CloudWatch agent의 기본 metric namespace는 CWAgent이며 변경할 수 있고, 이 추가 metric은 custom metric 과금 경계를 가진다.

ECS·EKS에서는 agent를 서버에 설치한다는 한 문장으로 단순화하지 않는다. Container Insights는 환경에 맞는 collector를 통해 성능 log event를 모으고 cluster·node·pod 또는 task·service 수준의 metric을 만든다. EKS의 Container Insights는 containerized CloudWatch agent 계열을 사용하며, 실제 배치는 add-on·collector 구성과 IAM 권한까지 함께 확인해야 한다.

값이 보이지 않을 때의 순서는 다음과 같다.

  1. 원천이 그 신호를 실제로 생성하는가?
  2. agent·add-on·서비스 옵션이 수집하도록 구성되고 실행 중인가?
  3. 수집 주체가 목적지에 쓸 IAM 권한을 갖는가?
  4. 올바른 account·Region·namespace·metric name·dimension 조합을 보고 있는가?
  5. 게시 주기와 조회 시간 범위가 맞는가?

0은 관찰된 값이고, 데이터 없음은 관찰 증거가 없다는 뜻이다. 둘을 같은 정상 상태로 취급하지 않는다.

2. Metric은 이름 하나가 아니라 정확한 시계열이다

전통적인 CloudWatch metric의 정체성은 다음 조합으로 결정된다.

Metric identity = Namespace + Metric name + 정확한 dimension 조합

예를 들어 아래 둘은 이름이 같아도 다른 metric이다.

Ops/Checkout · ErrorCount · Environment=prod
Ops/Checkout · ErrorCount · Environment=prod, AvailabilityZone=ap-northeast-2a
  • Namespace는 서로 다른 metric 집합이 실수로 합쳐지지 않게 격리한다.
  • Dimension은 단순 label이 아니라 metric identity의 일부다. 고유한 name/value 조합마다 별도 metric이 생긴다.
  • Custom metric은 게시하지 않은 dimension 조합으로 자동 집계되지 않는다. 조회와 alarm은 게시할 때 사용한 조합을 맞춰야 한다.
  • Dimension은 장애 때 실제로 나눠 볼 축을 선택한다. request ID나 user ID처럼 값이 끝없이 늘어나는 축을 무심코 넣으면 시계열 수와 비용이 커진다.
  • Unit은 identity 자체는 아니지만 의미가 일관돼야 한다. Count, Seconds, Percent를 섞으면 같은 수치도 운영 의미가 달라진다.

시간 의미를 나누기

설정뜻선택 질문
수집·게시 주기원천이 값을 얼마나 자주 보내는가급격한 변화를 포착할 만큼 자주 오는가?
Resolution저장되는 원자료의 시간 해상도1분 표준 해상도인가, 1초 고해상도 custom metric인가?
Period한 alarm data point를 만들 집계 구간몇 초·몇 분의 값을 한 점으로 볼 것인가?
Statisticperiod 안의 값을 줄이는 방법Average, Sum, Minimum, Maximum, percentile 중 무엇이 질문에 맞는가?
Evaluation periods (N)최근 몇 개 period를 판단 창으로 볼 것인가총 관찰 창이 얼마나 긴가?
Datapoints to alarm (M)그중 몇 개가 위반해야 하는가일시 spike와 지속 문제를 어떻게 구분할 것인가?

Period × N은 판단 창을 만들고, M out of N은 그 창 안에서 필요한 위반 횟수를 정한다. 위반 data point는 반드시 연속일 필요가 없다. 예를 들어 period 1분, 3 out of 5는 최근 5분 중 3개의 집계점이 임계값을 넘으면 ALARM으로 전환하는 구성이다.

Resolution과 period는 같은 말이 아니다. 1초 해상도로 보관한 metric을 1분 period의 Average로 평가할 수도 있다. 반대로 원천이 5분마다 한 번 게시하는 metric을 1분 period로 평가하면 빈 구간이 생겨 missing-data 판단이 개입한다. 고해상도는 더 빠른 관찰을 가능하게 하지만 게시·alarm 비용도 달라지므로, 반응 속도가 실제 운영 결정에 필요한 경우에 선택한다.

Statistic도 조건의 일부다.

  • Sum은 period 안의 요청·오류·throttle 횟수처럼 합계를 묻는 신호에 잘 맞는다.
  • Average는 지속적인 수준을 보지만 짧은 spike를 희석할 수 있다.
  • Maximum은 period 안에 한 번이라도 심한 압력이 있었는지 드러낸다.
  • Percentile은 지연 분포의 tail을 볼 때 유용하다. 평균만 보면 일부 사용자의 긴 지연이 가려질 수 있다.

3. Log를 재사용 가능한 수치로 바꾸는 metric filter

Metric filter의 흐름은 다음과 같다.

새 log event
→ filter pattern 일치
→ metric value 생성
→ custom metric에 게시
→ graph·dashboard·metric alarm에서 사용

예를 들어 checkout log group에서 구조화된 log의 level=ERROR와 service=checkout을 찾고, 일치할 때마다 Ops/Checkout · ErrorCount에 1을 게시한다. Alarm은 이 metric의 1분 Sum이 임계값을 넘는지 평가할 수 있다.

여기서 중요한 경계는 다음과 같다.

  • Filter는 생성 이후 들어오는 log event에 적용되며 과거 log를 소급해 metric으로 만들지 않는다.
  • 현재 metric filter는 Standard log class의 log group에서 지원된다.
  • Default value 0을 두면 log는 들어왔지만 일치 항목이 없는 period에 0을 게시할 수 있다. 그 period에 log 자체가 하나도 들어오지 않았다면 값이 게시되지 않는다.
  • Metric filter 결과에 dimensions를 지정하면 default value를 함께 지정할 수 없다. 이때 sparse metric의 missing-data 의미를 alarm에서 명시해야 한다.
  • Filter의 metric 전달은 적어도 한 번이므로 드물게 중복될 수 있다. 엄밀한 결제·원장 수치와 운영 탐지용 count를 같은 보장으로 다루지 않는다.

Metric이 생기지 않을 때는 pattern이 맞는가만 보지 않는다. 새 log가 실제로 들어왔는지, filter 생성 시점 이후인지, log class가 맞는지, 목적 namespace·dimension 조합을 조회하는지까지 확인한다.

최신 CloudWatch에는 Logs Insights query 결과를 직접 평가하는 log alarm도 있다. Metric filter는 다른 graph·metric math·alarm에서 계속 재사용할 시계열을 만들 때 유리하고, log alarm은 scheduled query의 집계 결과를 직접 조건화할 때 유리하다. 이 구간의 중심은 시험 계획에 포함된 metric filter 파이프라인이다.

4. Alarm은 시간 조건을 평가하는 상태 기계다

metric 또는 metric math
→ statistic(period)
→ threshold 비교
→ M out of N과 missing-data 처리
→ OK | ALARM | INSUFFICIENT_DATA
→ 상태 전이에 연결된 action
  • OK: 현재 평가 결과가 임계 조건을 만족하지 않는다.
  • ALARM: 설정한 시간 조건을 만족한다.
  • INSUFFICIENT_DATA: 현재 설정으로 판단할 실제 data point가 충분하지 않다.

ALARM은 조건이 참이라는 뜻이지, dashboard에 적은 원인 가설이 참이라는 뜻이 아니다. CPU와 latency가 동시에 높아도 CPU가 latency의 근본 원인임을 alarm 자체가 증명하지 않는다.

Missing data는 metric의 의미에 맞춘다

처리평가 의미
notBreaching빠진 점을 정상 범위로 취급
breaching빠진 점을 위반으로 취급
ignore현재 alarm 상태 유지
missing실제 점이 전부 없으면 INSUFFICIENT_DATA로 전환하는 기본 방식

간헐적 오류가 생길 때만 게시되는 metric과 매분 heartbeat처럼 계속 와야 하는 metric은 결측의 뜻이 반대일 수 있다. 오류 없음을 표현하려면 metric filter default 0처럼 명시적인 data point를 만드는 방법이 있고, 수집기 단절을 탐지하려면 telemetry freshness를 별도 신호로 두는 방법이 있다. 메모리 값이 사라졌다고 메모리 사용률이 높다고 간주하는 식으로 서로 다른 상태를 합치지 않는다.

Metric alarm과 composite alarm

유형직접 평가하는 것적합한 역할
Metric alarmmetric 하나 또는 metric math 결과CPU·latency·error count 같은 개별 조건 탐지
Composite alarm다른 alarm들의 OK·ALARM·INSUFFICIENT_DATA 상태를 Boolean rule로 결합서비스 수준 health, dependency 관계, 배포·maintenance 중 noise 억제

예를 들면 다음 rule은 latency와 5xx 오류가 함께 높고 배포 중이 아닐 때만 상위 경보를 만든다.

ALARM(HighLatency)
AND ALARM(High5xx)
AND NOT ALARM(DeploymentInProgress)

하위 metric alarm에는 action을 두지 않고 composite alarm에만 알림을 연결하면 같은 incident의 중복 알림을 줄일 수 있다. Composite alarm이 직접 수행할 수 있는 action은 SNS notification, Lambda invocation, Systems Manager OpsItem·Incident 생성 등으로 제한되며 EC2·Auto Scaling action은 직접 수행하지 않는다. 일반적으로 하위 alarm들은 composite alarm과 같은 account·Region에 있어야 하고, cross-account observability monitoring account에는 source account metric을 보는 하위 alarm에 대한 예외가 있다.

대부분의 alarm action은 상태가 바뀔 때 한 번 실행되고, 조건이 계속 유지된다는 이유만으로 반복되지 않는다. Auto Scaling action은 예외적으로 새 상태가 유지되는 동안 반복 실행될 수 있다. 따라서 여전히 ALARM인데 SNS 메일이 또 오지 않는다는 사실만으로 SNS 실패라고 결론 내리지 않는다. CloudWatch는 지정한 action 대상의 존재를 미리 검증하지 않으므로 alarm history와 action 대상도 함께 점검한다.

5. Dashboard, alarm, SNS의 책임을 분리한다

구성요소책임책임이 아닌 것
Dashboardmetric·alarm·text 등을 한 시간축과 운영 맥락으로 시각화·공유임계 조건 판정, 데이터 생성, notification delivery
Alarm시간 창과 임계 조건을 평가해 상태를 만든다근본 원인 확정, 사람이 볼 운영 화면 전체 구성
SNSpublisher가 topic에 보낸 message를 구독 endpoint로 fan-out한다metric 평가, ALARM 여부 결정

좋은 운영 dashboard는 장식용 차트 모음이 아니라 질문 순서를 담는다. 상단에는 사용자 영향 지표, 중간에는 service·dependency health, 하단에는 resource saturation과 최근 변경 맥락을 둔다. Text widget에 owner·runbook·확인 순서를 넣으면 incident 중 공통 playbook 역할도 할 수 있다.

Cross-account·cross-Region dashboard widget은 accountId와 region으로 metric 원천을 가리킬 수 있다. Monitoring account에서 여러 source account의 metric을 한 graph에 놓고 Region별 상태를 한 화면에 비교할 수 있다. 그러나 한 화면에서 본다와 데이터를 목적지 account로 복제·소유한다는 다르다. Cross-account observability·cross-account cross-Region console·metrics centralization은 서로 다른 기능이며, dashboard를 만들었다고 데이터가 자동 중앙 저장되는 것은 아니다.

또한 cross-Region dashboard가 된다고 cross-Region alarm이 되는 것은 아니다. Cross-account observability는 같은 Region의 source account metric을 monitoring account의 alarm이 볼 수 있지만, 한 Region의 alarm이 다른 Region의 metric을 직접 감시하는 구성은 지원되지 않는다. 다중 Region 운영에서는 Region별 alarm 상태를 dashboard에 모아 보는 구조를 우선 떠올린다.

Dashboard는 AWS 계정에 직접 접근하지 않는 사람에게도 공유할 수 있지만 공개 link는 인증 없이 접근될 수 있다. 공유 dashboard의 권한은 개별 metric까지 완전히 좁혀지지 않는 항목이 있으므로 민감한 resource 이름·tag·운영 정보를 넣기 전에 공개 범위와 생성되는 권한을 검토한다.

6. SNS는 판정기가 아니라 전달 계층이다

alarm state transition
→ SNS topic에 message publish
→ confirmed subscription
→ email | SMS | HTTP(S) | SQS | Lambda 등 endpoint

한 topic을 사람과 애플리케이션 endpoint에 fan-out할 수 있다. Alarm은 어느 상태 전이에서 어느 topic으로 보낼지를 정하고, SNS는 topic의 구독자에게 전달한다. Email 구독은 확인되기 전 PendingConfirmation이며 실제 알림을 받지 못한다.

ALARM인데 알림이 안 왔다면 다음 경계를 순서대로 확인한다.

  1. Alarm history에 실제 상태 전이가 있었는가?
  2. 해당 상태의 action이 활성화돼 있고 mute window에 걸리지 않았는가?
  3. 지정한 SNS topic이 존재하고 publisher를 허용하는가?
  4. Subscription이 확인됐고 endpoint가 정상인가?
  5. SNS topic에 test message를 직접 publish했을 때는 전달되는가?

직접 test message는 alarm → SNS publish 문제와 SNS → subscriber delivery 문제를 분리한다.

7. 네 가지 운영 적용

사례 A — EC2 memory 압력

  1. 기본 EC2 metric에 memory가 있을 것이라고 가정하지 않고 CloudWatch agent로 guest OS metric을 수집한다.
  2. CWAgent · mem_used_percent · InstanceId=...처럼 대상이 분명한 시계열을 확인한다.
  3. 지속 압력이 목적이면 1분 Average, 짧은 위험 spike가 목적이면 Maximum 등 운영 질문에 맞는 statistic을 고른다.
  4. 일시 spike를 거르도록 M out of N을 정하고, agent 단절은 memory alarm의 값으로 변조하지 않고 freshness 신호로 따로 탐지한다.
  5. Dashboard에 memory·CPU·swap·application latency·error를 같은 시간축에 놓고, alarm의 ALARM 전이를 SNS로 전달한다.

사례 B — Application error log

  1. 구조화된 error pattern을 metric filter로 잡아 ErrorCount=1을 게시한다.
  2. Log가 계속 들어오는 구조라면 no-match period에 default 0을 고려한다.
  3. 1분 Sum과 M out of N으로 burst와 지속 오류를 구분한다.
  4. Alarm notification의 시각과 원본 log query의 시간 범위를 맞춰 상세 오류를 확인한다.

여기서 metric은 오류가 얼마나 발생했는가, log는 무슨 오류였는가를 맡는다.

사례 C — 중복 alert 줄이기

Instance별 CPU·memory alarm이 모두 paging action을 가지면 한 서비스 장애가 수십 건으로 번질 수 있다. 하위 alarm은 진단 상태로 유지하고, HighLatency AND High5xx AND NOT DeploymentInProgress 같은 composite alarm에만 paging topic을 연결한다. Dashboard에는 하위 alarm들을 그대로 보여 원인 범위 축소에 사용한다.

사례 D — 다중 account·Region 운영 화면

Monitoring account dashboard에 production account들의 사용자 영향 metric과 Region별 alarm을 모은다. Widget의 account·Region 원천을 명시하고, 운영자가 원천을 구분할 수 있게 label을 붙인다. Region별 alarm이 각자의 조건을 평가하고 SNS route로 알림을 보내며, dashboard는 그 상태를 한 화면에 묶는다. 화면 통합을 데이터 복제나 cross-Region alarm으로 오해하지 않는다.

8. 긍정형 연결 요약

  • 기본 AWS metric에 없는 guest OS·application 신호 → CloudWatch agent 또는 환경별 collector
  • log pattern을 graph와 metric alarm에서 재사용 → CloudWatch Logs metric filter → custom metric
  • 시계열 정체성 → namespace + metric name + 정확한 dimensions
  • 원자료의 촘촘함 → resolution
  • 한 data point의 집계 폭과 방식 → period + statistic
  • 지속 조건 → Datapoints to alarm (M) out of Evaluation periods (N)
  • 개별 수치 조건 → metric alarm
  • 여러 alarm 상태의 운영 관계 → composite alarm
  • 공통 상황판·playbook → CloudWatch dashboard
  • 상태 전이 message의 fan-out → SNS topic + confirmed subscriptions
  • ALARM → 설정한 조건이 참이라는 증거
  • 근본 원인 → log·trace·변경 이력 등 추가 증거로 검증할 가설

이 구간의 종료선은 수집 → 시계열 식별 → 시간 조건 평가 → 시각화 → notification이다. EventBridge routing, 실행 권한, Lambda·Systems Manager runbook을 통한 자동 복구와 그 결과 검증은 다음 의존 구간의 범위다.

9. 공식 원천

그래프 뷰

백링크