# 사고 탐지 및 대응에서 비즈니스 요구 사항에 맞는 CloudWatch 경보 생성
Amazon CloudWatch 경보를 생성할 때 경보가 비즈니스 요구 사항에 가장 적합하도록 하기 위해 취할 수 있는 몇 가지 단계가 있습니다.
**참고**
사고 탐지 및 대응에 온보딩하기 위해 AWS 서비스에 권장되는 CloudWatch 경보의 예는 [AWS re:Post의 사고 탐지 및 대응 경보 모범 사례](https://repost.aws/selections/KP6FA7iQgVSVeSNq1jAcjwxg/incident-detection-and-response-idr)를 참조하세요.
## 제안된 CloudWatch 경보 검토
제안된 경보를 검토하여 모니터링되는 워크로드에 중요한 영향(수익 손실 또는 성능이 크게 저하되는 고객 경험 저하)이 있을 때만 ‘경보’ 상태가 되는지 확인합니다. 예를 들어 이 경보가 ‘경보’ 상태가 되면 즉시 대응해야 할 만큼 중요한 경보라고 생각하나요?
다음은 애플리케이션에 대한 최종 사용자의 경험에 영향을 미치는 등 중요한 비즈니스 영향을 나타낼 수 있는 권장 지표입니다.
+ **CloudFront:** 자세한 내용은 [CloudFront 및 엣지 함수 지표 보기](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/viewing-cloudfront-metrics.html)를 참조하세요.
+ **Application Load Balancer:** 가능하면 Application Load Balancer에 대해 다음 경보를 생성하는 것이 좋습니다.
+ HTTPCode\$1ELB\$15XX\$1Count
+ HTTPCode\$1Target\$15XX\$1Count
위의 경보를 통해 Application Load Balancer 또는 다른 리소스를 사용하는 대상의 응답을 모니터링할 수 있습니다. 이렇게 하면 5XX 오류의 원인을 더 쉽게 식별할 수 있습니다. 자세한 내용은 [Application Load Balancer의 CloudWatch 지표](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)를 참조하세요.
+ **Amazon API Gateway:** Elastic Beanstalk에서 WebSocket API를 사용하는 경우 다음 지표를 사용하는 것이 좋습니다.
+ 통합 오류율(5XX 오류로 필터링됨)
+ 통합 지연 시간
+ 실행 오류
자세한 내용은 [CloudWatch 지표를 사용한 WebSocket API 모니터링](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-logging.html)을 참조하세요.
+ **Amazon Route 53:** **EndPointUnhealthyENICount** 지표를 모니터링합니다. 이 지표는 **자동 복구** 상태의 탄력적 네트워크 인터페이스 수입니다. 이 상태는 해석기가 엔드포인트와 연결된 하나 이상의 Amazon Virtual Private Cloud 네트워크 인터페이스를 복구하려는 시도(**EndpointId**로 지정)를 나타냅니다. 복구 프로세스에서 엔드포인트는 제한된 용량으로 작동합니다. 엔드포인트는 완전히 복구될 때까지 DNS 쿼리를 처리할 수 없습니다. 자세한 내용은 [Amazon CloudWatch를 사용하여 Amazon Route 53 Resolver 엔드포인트 모니터링](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-resolver-with-cloudwatch.html)을 참조하세요.
## 경보 구성 검증
제안된 경보가 비즈니스 요구 사항에 맞는지 확인한 후 경보의 구성 및 기록을 확인합니다.
+ 지표의 **임곗값**을 검증하여 지표의 그래프 추세와 비교하여 ‘경보’ 상태로 전환합니다.
+ 데이터 포인트를 폴링하는 데 사용되는 **기간**을 검증합니다. 60초에 데이터 포인트를 폴링하면 인시던트를 조기에 감지하는 데 도움이 됩니다.
+ **DatapointToAlarm** 구성을 검증합니다. 대부분의 경우 이 값을 3/3 또는 5/5로 설정하는 것이 가장 좋습니다. 인시던트에서 경보는 [3 DatapointToAlarm 중 3개가 포함된 60초 지표]로 설정된 경우 3분 후, [5 DatapointToAlarm 중 5개가 포함된 60초 지표]로 설정된 경우 5분 후에 트리거됩니다. 이 조합을 사용하여 노이즈 경보를 제거합니다.
**참고**
위의 권장 사항은 서비스 사용 방식에 따라 달라질 수 있습니다. 각 AWS 서비스는 워크로드 내에서 다르게 작동합니다. 또한 여러 위치에서 사용할 때 동일한 서비스가 다르게 작동할 수 있습니다. 워크로드가 경보를 제공하는 리소스와 업스트림 및 다운스트림 효과를 어떻게 활용하는지 이해해야 합니다.
## 경보가 누락된 데이터를 처리하는 방법 검증
일부 지표 소스는 정기적으로 CloudWatch로 데이터를 전송하지 않습니다. 이러한 지표의 경우 누락된 데이터를 **notBreaching**으로 처리하는 것이 가장 좋습니다. 자세한 내용은 [CloudWatch 경보가 누락된 데이터를 처리하는 방법 구성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data) 및 [경보 상태 조기 전환 방지](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#CloudWatch-alarms-avoiding-premature-transition)를 참조하세요.
예를 들어 지표가 오류율을 모니터링하고 오류가 없는 경우 지표는 데이터 없음(nil) 데이터 포인트를 보고합니다. 누락된 데이터를 **누락**으로 처리하도록 경보를 구성할 경우 위반 데이터 포인트 1개와 데이터 없음(nil) 데이터 포인트 2개가 있으면 지표가 ‘경보’ 상태가 됩니다(데이터 포인트 3개 중 3개). 이는 누락된 데이터 구성이 평가 기간의 마지막으로 알려진 데이터 포인트를 평가하기 때문입니다.
지표가 오류율을 모니터링하는 경우 서비스 성능 저하가 없으면 좋은 데이터가 없다고 가정할 수 있습니다. 누락된 데이터가 ‘정상'으로 처리되고 지표가 단일 데이터 포인트에서 ‘경보’ 상태가 되지 않도록 누락 데이터를 **notBreaching**으로 처리하는 것이 모범 사례입니다.
## 각 경보의 기록 검토
경보 기록에 ‘경보’ 상태로 자주 전환되었다가 빠르게 복구되는 것으로 표시되면 경보가 문제가 될 수 있습니다. 경보를 조정하여 노이즈 또는 거짓 경보를 방지해야 합니다.
## 기본 리소스에 대한 지표 검증
지표가 유효한 기본 리소스를 살펴보고 올바른 통계를 사용해야 합니다. 경보가 잘못된 리소스 이름을 검토하도록 구성된 경우 경보가 기본 데이터를 추적하지 못할 수 있습니다. 이로 인해 경보가 ‘경보’ 상태가 될 수 있습니다.
## 복합 경보 생성
온보딩을 위해 인시던트 감지 및 대응 작업에 많은 수의 경보를 제공하는 경우 복합 경보를 생성하라는 메시지가 표시될 수 있습니다. 복합 경보는 온보딩해야 하는 총 경보 수를 줄입니다.