# 사고 탐지 및 대응의 CloudWatch 경보 예제 사용 사례
<a name="idr-ex-alarm-use-cases"></a>

다음 사용 사례는 사고 탐지 및 대응에서 Amazon CloudWatch 경보를 사용하는 방법의 예를 제공합니다. 이 예제는 다양한 AWS 서비스에서 주요 지표와 임곗값을 모니터링하도록 CloudWatch 경보를 구성하여 애플리케이션 및 워크로드의 가용성과 성능에 영향을 미칠 수 있는 잠재적 문제를 식별하고 대응할 수 있는 방법을 보여줍니다.

## 예제 사용 사례 A: Application Load Balancer
<a name="use-case-alb"></a>

잠재적인 워크로드 영향을 나타내는 다음과 같은 CloudWatch 경보를 생성할 수 있습니다. 이렇게 하려면 연결 성공이 특정 임곗값 아래로 떨어질 때 경보를 생성하는 지표 수학을 생성합니다. 사용 가능한 CloudWatch 지표는 [Application Load Balancer에 대한 CloudWatch 지표](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)를 참조하세요.

**지표:**`HTTPCode_Target_3XX_Count;HTTPCode_Target_4XX_Count;HTTPCode_Target_5XX_Count. (m1+m2)/(m1+m2+m3+m4)*100 m1 = HTTP Code 2xx || m2 = HTTP Code 3xx || m3 = HTTP Code 4xx || m4 = HTTP Code 5xx`

**네임스페이스:** AWS/ApplicationELB

**ComparisonOperator(임곗값):** x 미만(x = 고객의 임곗값).

**기간:** 60초

**DatapointsToAlarm:** 3/3

**누락 데이터 처리** 누락 데이터를 [위반](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)으로 처리합니다.

**통계: **Sum

다음 다이어그램은 사용 사례 A의 흐름을 보여줍니다.

![\[Application Load Balancer의 예제 사용 사례\]](http://docs.aws.amazon.com/ko_kr/IDR/latest/userguide/images/UseCaseAALB.png)


## 예제 사용 사례 B: Amazon API Gateway
<a name="use-case-apigateway"></a>

잠재적인 워크로드 영향을 나타내는 다음과 같은 CloudWatch 경보를 생성할 수 있습니다. 이렇게 하려면 API Gateway에서 지연 시간이 높거나 평균 4XX 오류 수가 많을 때 경보를 생성하는 복합 지표를 생성합니다. 사용 가능한 지표는 [Amazon API Gateway 차원 및 지표](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html)를 참조하세요.

**지표:**`compositeAlarmAPI Gateway (ALARM(error4XXMetricApiGatewayAlarm)) OR (AALARM(latencyMetricApiGatewayAlarm))`

**네임스페이스:** AWS/API Gateway

**ComparisonOperator(임곗값):** 보다 큼(x 또는 y 고객의 임곗값)

**기간:** 60초

**DatapointsToAlarm:** 1/1

**누락 데이터 처리** 누락 데이터를 [위반하지 않음](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)으로 처리합니다.

**통계 **– .

다음 다이어그램은 사용 사례 B의 흐름을 보여줍니다.

![\[API Gateway의 예제 사용 사례\]](http://docs.aws.amazon.com/ko_kr/IDR/latest/userguide/images/UseCaseBAPIGW.png)


## 예제 사용 사례 C: Amazon Route 53
<a name="use-case-apigateway"></a>

CloudWatch를 사용하여 원시 데이터를 수집하고 읽기 가능하며 실시간에 가까운 지표로 처리하는 Route 53 상태 확인을 만들어 리소스를 모니터링할 수 있습니다. 잠재적인 워크로드 영향을 나타내는 다음과 같은 CloudWatch 경보를 생성할 수 있습니다. CloudWatch 지표를 사용하여 설정된 임곗값을 위반할 때 트리거되는 경보를 생성할 수 있습니다. 사용 가능한 CloudWatch 지표는 [Route 53 상태 확인을 위한 CloudWatch 지표](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-cloudwatch.html#cloudwatch-metrics)를 참조하세요.

**지표:**`R53-HC-Success`

**네임스페이스:** AWS/Route 53

**임곗값 HealthCheckStatus:** 3분 이내에 3개의 데이터 포인트에 대한 HealthCheckStatus < x(x 고객의 임곗값)

**기간:** 1분

**DatapointsToAlarm:** 3/3

**누락 데이터 처리** 누락 데이터를 [위반](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)으로 처리합니다.

**통계: **Minimum

다음 다이어그램은 사용 사례 C의 흐름을 보여줍니다.

![\[Route 53 예제 사용 사례\]](http://docs.aws.amazon.com/ko_kr/IDR/latest/userguide/images/UseCaseCR53.png)


## 예제 사용 사례 D: 사용자 지정 앱을 사용하여 워크로드 모니터링
<a name="use-case-apigateway"></a>

이 시나리오에서는 시간을 내어 적절한 상태 확인을 정의하는 것이 중요합니다. 애플리케이션의 포트만 열려 있는지 확인하는 경우 애플리케이션이 작동하는지는 확인하지 않은 것입니다. 또한 애플리케이션의 홈 페이지를 직접 호출하는 것이 앱이 작동하는지 확인하는 올바른 방법은 아닙니다. 예를 들어 애플리케이션이 데이터베이스와 Amazon Simple Storage Service(Amazon S3)에 모두 의존하는 경우 상태 확인은 모든 요소를 검증해야 합니다. 이를 수행하는 한 가지 방법은 **/monitor**와 같은 모니터링 웹 페이지를 생성하는 것입니다. 모니터링 웹 페이지는 데이터베이스를 직접 호출하여 데이터를 연결하고 가져올 수 있는지 확인합니다. 또한 모니터링 웹 페이지는 Amazon S3를 직접 호출합니다. 그런 다음 로드 밸런서의 상태 확인을 **/monitor** 페이지로 가리킵니다.

다음 다이어그램은 사용 사례 D의 흐름을 보여줍니다.

![\[사용자 지정 앱을 사용한 모니터링 예제 사용 사례\]](http://docs.aws.amazon.com/ko_kr/IDR/latest/userguide/images/CustomAlarm.png)