# 개념 CloudWatch 경보는 지표를 모니터링하고 임계치 위반 시 작업을 트리거합니다. 효과적인 모니터링을 위해서는 경보가 데이터를 평가하고 조건에 대응하는 방법을 이해해야 합니다. **Topics** + [경보 데이터 쿼리](alarm-data-queries.md) + [경보 평가](alarm-evaluation.md) + [PromQL 경보](alarm-promql.md) + [복합 경보](alarm-combining.md) + [경보 작업](alarm-actions.md) + [경보 음소거 규칙](alarm-mute-rules.md) + [Limits](alarm-limits.md) # 경보 데이터 쿼리 CloudWatch 경보는 다양한 데이터 소스를 모니터링할 수 있습니다. 모니터링 요구 사항에 따라 적절한 쿼리 유형을 선택합니다. ## Metrics 단일 CloudWatch 지표를 모니터링합니다. 리소스 성능을 추적하기 위한 가장 일반적인 경보 유형입니다. 지표에 대한 자세한 내용은 [CloudWatch 지표 개념](cloudwatch_concepts.md)을 참조하세요. 자세한 내용은 [정적 임곗값을 기반으로 CloudWatch 경보 생성](ConsoleAlarms.md) 섹션을 참조하세요. ## 지표 수식 하나 이상의 CloudWatch 지표를 기반으로 하는 수학 표현식의 결과에 대한 경보를 설정할 수 있습니다. 경보에 사용되는 수학 표현식에는 지표를 10개까지 포함할 수 있습니다. 각 지표의 기간은 동일해야 합니다. 수학 표현식을 기반으로 하는 경보의 경우 누락된 데이터 포인트를 처리하는 방법을 CloudWatch에 지정할 수 있습니다. 이 경우 수학 표현식이 해당 데이터 포인트에 대한 값을 반환하지 않으면 데이터 포인트가 누락된 것으로 간주됩니다. 수학 표현식을 기반으로 하는 경보는 Amazon EC2 작업을 수행할 수 없습니다. 지표 수학 표현식 및 구문에 대한 자세한 내용은 [CloudWatch 지표에 수학 표현식 사용](using-metric-math.md) 단원을 참조하세요. 자세한 내용은 [지표 수학 표현식을 기반으로 CloudWatch 경보 생성](Create-alarm-on-metric-math-expression.md) 섹션을 참조하세요. ## 지표 인사이트 CloudWatch Metrics Insights 쿼리는 SQL과 유사한 구문을 사용하여 대규모로 지표를 쿼리하는 데 도움이 됩니다. 여러 시계열을 반환하는 Metrics Insights 쿼리에서 경보를 생성할 수 있습니다. 이 기능은 모니터링 옵션을 크게 확장합니다. Metrics Insights 쿼리를 기반으로 경보를 생성하면 모니터링되는 그룹에 리소스가 추가되거나 제거될 때 경보가 자동으로 조정됩니다. 경보를 한 번 생성합니다. 그러면 해당 지표를 사용할 수 있게 되면 쿼리 정의 및 필터와 일치하는 모든 리소스에서 경보 모니터링 범위를 조인합니다. 다중 시계열 쿼리의 경우 반환된 각 시계열이 경보의 기여자가 되어 보다 세분화된 동적 모니터링을 지원합니다. 다음은 CloudWatch Metrics Insights 경보의 두 가지 주요 사용 사례입니다. + 이상 탐지 및 집계 모니터링 단일 집계 시계열을 반환하는 Metrics Insights 쿼리에서 경보를 생성합니다. 이 접근 방식은 인프라 또는 애플리케이션 전반에서 집계된 지표를 모니터링하는 동적 경보에 적합합니다. 예를 들어 모든 인스턴스에서 최대 CPU 사용률을 모니터링할 수 있으며, 플릿 규모를 조정할 때 경보가 자동으로 조정됩니다. 집계 모니터링 경보를 생성하려면 다음 쿼리 구조를 사용합니다. ``` SELECT FUNCTION(metricName) FROM SCHEMA(...) WHERE condition; ``` + 리소스별 플릿 모니터링 여러 시계열을 모니터링하는 경보를 생성합니다. 이때 각 시계열은 자체 상태의 기여자 역할을 합니다. 기여자가 ALARM 상태가 되면 경보가 활성화되어 리소스별 작업이 트리거됩니다. 예를 들어 여러 RDS 인스턴스의 데이터베이스 연결을 모니터링하여 연결 거부를 방지합니다. 여러 시계열을 모니터링하려면 다음 쿼리 구조를 사용합니다. ``` SELECT AVG(DatabaseConnections) FROM AWS/RDS WHERE condition GROUP BY DBInstanceIdentifier ORDER BY AVG() DESC; ``` 다중 시계열 경보를 생성하는 경우 쿼리에 두 개의 중요한 절을 포함해야 합니다. + 시계열을 구성하는 방법을 정의하고 쿼리에서 생성할 시계열 수를 결정하는 `GROUP BY` 절. + 지표의 결정적 정렬을 설정하여 경보가 가장 중요한 신호를 먼저 평가할 수 있도록 하는 `ORDER BY` 절. 이러한 절은 적절한 경보 평가를 위해 필수적입니다. `GROUP BY` 절은 데이터를 별도의 시계열로 분할(예: 인스턴스 ID를 기준으로)하는 반면, `ORDER BY` 절은 경보 평가 중에 이러한 시계열의 일관되고 우선순위가 지정된 처리를 보장합니다. 다중 시계열 경보를 생성하는 방법에 대한 자세한 내용은 [다중 시계열 Metrics Insights 쿼리를 기반으로 경보 생성](multi-time-series-alarm.md) 섹션을 참조하세요. ## 로그 그룹 지표 필터 로그 그룹 지표 필터를 기반으로 경보를 생성할 수 있습니다. 지표 필터를 사용하면 데이터가 CloudWatch로 전송될 때 로그 데이터에서 용어와 패턴을 찾을 수 있습니다. 자세한 내용을 알아보려면 *Amazon CloudWatch Logs 사용 설명서*의 [필터를 사용하여 로그 이벤트에서 지표 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)을 참조하세요. 로그 그룹 지표 필터를 기반으로 경보를 생성하는 방법에 대한 자세한 내용은 [로그에 대한 경보](Alarm-On-Logs.md) 섹션을 참조하세요. ## PromQL PromQL(Prometheus Query Language) 인스턴트 쿼리를 사용하여 CloudWatch OTLP 엔드포인트를 통해 수집된 지표를 모니터링하는 경보를 생성할 수 있습니다. PromQL 경보의 작동 방식에 대한 자세한 내용은 [PromQL 경보](alarm-promql.md) 섹션을 참조하세요. PromQL 경보를 생성하는 방법에 대한 자세한 내용은 [PromQL 쿼리를 사용하여 경보 생성](Create_PromQL_Alarm.md) 섹션을 참조하세요. ## 외부 데이터 소스 CloudWatch에 없는 데이터 소스의 지표를 감시하는 경보를 생성할 수 있습니다. 이러한 다른 데이터 소스에 대한 연결을 생성하는 방법에 대한 자세한 내용은 [다른 데이터 소스의 쿼리 지표](MultiDataSourceQuerying.md) 섹션을 참조하세요. 연결된 데이터 소스를 기반으로 경보를 생성하는 방법에 대한 자세한 내용은 [연결된 데이터 소스를 기반으로 경보 생성](Create_MultiSource_Alarm.md) 섹션을 참조하세요. # 경보 평가 ## 지표 경보 상태 지표 경보에는 다음과 같은 상태가 있을 수 있습니다. + `OK` – 지표 또는 표현식이 정의된 임곗값 내에 있습니다. + `ALARM` – 지표 또는 표현식이 정의된 임곗값을 벗어났습니다. + `INSUFFICIENT_DATA` – 경보가 방금 시작되었거나 지표를 사용할 수 없거나 지표에서 경보 상태를 결정하는 데 사용할 수 있는 데이터가 충분하지 않습니다. ## 경보 평가 상태 경보 상태 외에도 각 경보에는 경보 평가 프로세스에 대한 정보를 제공하는 평가 상태가 있습니다. 다음 상태가 나타날 수 있습니다. + `PARTIAL_DATA` - 할당량 제한으로 인해 사용 가능한 모든 데이터를 검색할 수 없음을 나타냅니다. 자세한 내용은 [부분 데이터 처리 방법](cloudwatch-metrics-insights-alarms-partial-data.md) 섹션을 참조하세요. + `EVALUATION_ERROR` - 검토 및 수정이 필요한 경보 설정의 구성 오류를 나타냅니다. 자세한 내용은 경보의 StateReason 필드를 참조하세요. + `EVALUATION_FAILURE` - 임시 CloudWatch 문제를 나타냅니다. 문제가 해결될 때까지 수동 모니터링을 사용하는 것이 좋습니다. 콘솔의 경보 세부 정보에서 또는 `describe-alarms` CLI 명령이나 `DescribeAlarms` API를 사용하여 평가 상태를 볼 수 있습니다. ## 경보 평가 설정 경보를 생성할 때 다음과 같은 세 가지 설정을 지정하여 CloudWatch가 경보 상태를 변경할 시기를 평가할 수 있도록 합니다. + **기간**은 경보에 대해 개별 데이터 포인트를 생성하기 위해 지표 또는 표현식을 평가하는 기간입니다. 초로 표시됩니다. + [**평가 기간(Evaluation Periods)**]은 경보 상태를 결정할 때 평가할 가장 최근의 기간 또는 데이터 요소의 수입니다. + **경보에 대한 데이터 요소(Datapoints to Alarm)**는 평가 기간 내에 경보가 `ALARM` 상태에 도달하게 만드는 위반 데이터 요소의 수입니다. 위반 데이터 포인트가 연속적일 필요는 없지만, **평가 기간(Evaluation Period)**과 동일한 마지막 데이터 포인트 수 이내여야 합니다. 1분 이상인 기간의 경우 경보는 1분마다 평가되며 평가는 **기간** 및 **평가 기간**에 정의된 기간을 기준으로 합니다. 예를 들어 **기간**이 5분(300초)이고 **평가 기간**이 1인 경우 5분이 끝날 때 1분에서 5분까지의 데이터를 기반으로 경보가 평가됩니다. 그런 다음 6분이 끝나면 2분에서 6분까지의 데이터를 기반으로 경보를 평가합니다. 경보 기간이 10초, 20초 또는 30초인 경우 경보는 10초마다 평가됩니다. 자세한 내용은 [고분해능 경보](#high-resolution-alarms) 섹션을 참조하세요. 평가 기간 수에 각 평가 기간의 길이를 곱한 값이 1일을 초과하는 경우 경보는 1시간마다 평가됩니다. 이러한 다일 경보를 평가하는 방법에 대한 자세한 내용은 [다일 경보 평가 예제](#evaluate-multiday-alarm) 섹션을 참조하세요. 다음 그림에서 지표 경보에 대한 경보 임곗값은 3개 단위로 설정됩니다. [**평가 기간(Evaluation Period)**]과 [**경보에 대한 데이터 요소(Datapoints to Alarm)**]가 둘 다 3입니다. 즉, 가장 최근의 연속된 세 기간에서 기존 데이터 요소가 모두 임곗값을 초과하면 경보가 `ALARM` 상태가 됩니다. 그림에서는 기간 3에서 6 사이에 이러한 일이 발생합니다. 기간 6에서는 값이 임곗값 아래로 떨어지므로 평가 대상 기간 중 하나가 위반 상태가 아닙니다. 따라서 경보 상태가 다시 `OK`로 변경됩니다. 9번째 기간에 다시 한 번 임곗값이 위반되지만, 오직 하나의 기간 동안에만 그렇습니다. 결과적으로 경보 상태는 `OK`로 남아 있습니다. ![\[경보 임곗값이 경보 트리거\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/alarm_graph.png) [**평가 기간(Evaluation Period)**]과 [**경보에 대한 데이터 요소(Datapoints to Alarm)**]를 다른 값으로 구성하는 경우 이는 ‘M out of N(N 중 M)’ 경보를 설정한 것입니다. **경보에 대한 데이터 포인트**는 ('M')이고 **평가 기간**은 ('N')입니다. 평가 간격은 평가 기간 수에 기간 길이를 곱한 값입니다. 예를 들어, 1분 기간으로 5개의 데이터 포인트 중 4개를 구성하는 경우 평가 간격은 5분입니다. 10분의 기간으로 3개의 데이터 포인트 중 3개를 구성하는 경우 평가 간격은 30분입니다. **참고** 경보를 생성한 직후 데이터 요소가 누락되고 경보를 생성하기 전에 지표가 CloudWatch에 보고된 경우 CloudWatch는 경보를 평가할 때 경보가 생성되기 전부터 가장 최근의 데이터 요소를 검색합니다. ## 고분해능 경보 고분해능 지표에서 경보를 설정하는 경우 10초, 20초 또는 30초 기간의 고분해능 경보을 지정할 수 있습니다. 고분해능 경보는 요금이 더 비쌉니다. 고분해능 지표에 대한 자세한 내용은 [사용자 지정 지표 게시](publishingMetrics.md) 단원을 참조하세요. ## 다일 경보 평가 예제 각 평가 기간의 길이에 평가 기간 수를 곱한 값이 1일을 초과하는 경우 경보는 다일 경보입니다. 다일 경보는 시간당 한 번 평가됩니다. 다일 경보가 평가되면 CloudWatch는 평가 시 현재 시간의 :00분까지 지표만 고려합니다. 예를 들어 3일마다 10시에 실행되는 작업을 모니터링하는 경보를 가정합니다. 1. 10:02에 작업이 실패합니다. 1. 10:03에 경보가 평가되고 `OK` 상태를 유지합니다. 평가는 최대 10:00까지의 데이터만 고려하기 때문입니다. 1. 11:03에 경보는 11:00까지의 데이터를 고려하고 `ALARM` 상태로 전환합니다. 1. 11:43에 오류를 수정하고 이제 작업이 성공적으로 실행됩니다. 1. 12:03에 경보가 다시 평가되고 성공한 작업을 확인한 후 `OK` 상태로 돌아갑니다. # CloudWatch 경보가 누락 데이터를 처리하는 방법 구성 때로 지표에 대해 예상되는 데이터 요소의 일부가 CloudWatch에 보고되지 않는 경우도 있습니다. 연결이 끊기거나 서버가 정지할 때, 설계에 따라 지표 보고 데이터가 간헐적으로만 전송될 때 이런 일이 일어날 수 있습니다. CloudWatch를 사용하면 경보를 평가할 때 누락된 데이터 요소를 처리하는 방법을 지정할 수 있습니다. 이렇게 하면 모니터링 중인 데이터 유형에 적합한 경우에만 `ALARM` 상태가 되도록 경보를 구성할 수 있습니다. 누락된 데이터에 문제가 없는 경우의 거짓 긍정을 피할 수 있습니다. 각 경보가 항상 세 가지 상태 중 하나인 것과 마찬가지로 CloudWatch에 보고된 각각의 특정 데이터 요소는 다음과 같은 세 범주 중 하나에 속합니다. + 위반하지 않음(임곗값에서) + 위반(임곗값 위반) + 누락됨 각 경보에 대해 CloudWatch가 누락된 데이터 요소를 다음 중 하나로 처리하도록 지정할 수 있습니다. + `notBreaching` – 누락 데이터 요소를 ‘양호’하고 임곗값 내에 있는 것으로 처리합니다. + `breaching` - 누락 데이터 요소를 ‘불량’하고 임곗값을 위반한 것으로 처리합니다 + `ignore` - 현재 경보 상태를 유지합니다. + `missing` - 경보 평가 범위의 모든 데이터 요소가 누락된 경우 경보를 INSUFFICIENT\$1DATA 상태로 전환합니다. 가장 좋은 선택은 지표 유형과 경보 용도에 따라 다릅니다. 예를 들어 데이터를 지속적으로 보고하는 지표를 사용하여 애플리케이션 롤백 경보를 생성하는 경우 누락된 데이터 포인트는 문제를 나타낼 수 있으므로 위반으로 처리하는 것이 좋습니다. 그러나 Amazon DynamoDB의 `ThrottledRequests`와 같이 오류가 발생할 때만 데이터 요소를 생성하는 지표의 경우 누락 데이터를 `notBreaching`으로 처리할 수 있습니다. 기본값은 `missing`입니다. **중요** Amazon EC2 지표에 구성된 경보는 누락된 지표 데이터 포인트가 있는 경우 일시적으로 INSUFICITENT\$1DATA 상태로 전환될 수 있습니다. 드물기는 하지만, Amazon EC2 인스턴스가 정상인 경우에도 지표 보고가 중단되면 이 문제가 발생할 수 있습니다. 중지, 종료, 재부팅 또는 복구 작업을 수행하도록 구성된 Amazon EC2 지표에 대한 경보의 경우 누락된 데이터를 `missing`으로 처리하고 경보 상태일 때만 해당 경보를 트리거하도록 경보를 구성하는 것이 좋습니다. 경보에 대한 최상의 옵션을 선택하면 불필요하고 오해의 소지가 있는 경보 조건 변경을 막을 수 있으며, 시스템 상태를 보다 정확하게 나타낼 수 있습니다. **중요** `AWS/DynamoDB` 네임스페이스의 지표를 평가하는 경보는 기본적으로 누락 데이터를 무시합니다. 경보가 누락 데이터를 처리하는 방법에 대해 다른 옵션을 선택하는 경우 이 옵션을 재정의할 수 있습니다. `AWS/DynamoDB` 메트릭에 누락된 데이터가 있는 경우 해당 지표를 평가하는 경보는 현재 상태를 유지합니다. ## 데이터가 누락되었을 때 경보 상태 평가 방법 경보가 상태 변경 여부를 평가할 때마다 CloudWatch는 [**평가 기간(Evaluation Periods)**]으로 지정된 수보다 더 높은 수의 데이터 요소를 검색하려고 합니다. 검색을 시도하는 데이터 포인트의 정확한 수는 경보 기간의 길이, 표준 해상도 또는 고해상도 지표에 토대를 두고 있는지 여부에 따라 달라집니다. 검색을 시도하는 데이터 포인트의 기간이 *평가 범위*입니다. CloudWatch가 이러한 데이터 요소를 검색하면 다음과 같이 진행됩니다. + 평가 범위 내에 누락된 데이터 요소가 없다면 CloudWatch는 가장 최근에 수집된 데이터 요소를 기반으로 경보를 평가합니다. 평가된 데이터 요소의 수는 경보의 [**평가 기간(Evaluation Periods)**]과 같습니다. 평가 범위보다 훨씬 이전의 추가 데이터 요소는 필요하지 않으며 무시됩니다. + 평가 범위의 일부 데이터 요소가 누락되었지만 평가 범위에서 성공적으로 검색된 기존 데이터 요소의 총수가 경보의 [**평가 기간(Evaluation Periods)**] 이상인 경우 CloudWatch는 평가 범위보다 훨씬 이전의 필요한 추가 데이터 요소를 포함하여 성공적으로 검색된 가장 최근의 실제 데이터 요소를 기반으로 경보 상태를 평가합니다. 이 경우 누락 데이터 처리 방법에 대한 값이 필요 없으며, 이를 무시합니다. + 평가 범위의 일부 데이터 요소가 누락되었으며 검색된 실제 데이터 요소의 수가 경보의 [**평가 기간(Evaluation Periods)**] 수보다 적은 경우 CloudWatch는 누락 데이터 처리 방법에 대해 지정된 결과로 누락 데이터 요소를 채운 다음, 경보를 평가합니다. 그러나 평가 범위의 실제 데이터 요소는 모두 평가에 포함됩니다. CloudWatch는 되도록 몇 번만 누락 데이터 요소를 사용합니다. **참고** 이 동작의 특정 사례에서는 CloudWatch 경보가 지표 흐름이 중지된 후 일정 기간 동안 마지막 데이터 요소 집합을 반복적으로 재평가할 수 있습니다. 이 재평가를 통해 지표 스트림 중지 직전에 상태가 변한 경우 경보가 상태를 변경하고 작업을 다시 실행할 수 있습니다. 이 동작을 완화하려면 더 짧은 기간을 사용하세요. 다음은 경보 평가 동작에 대한 예를 설명한 테이블입니다. 첫 번째 표에서 [**경보에 대한 데이터 요소(Datapoints to Alarm)**]와 [**평가 기간(Evaluation Periods)**]은 둘 다 3입니다. CloudWatch는 가장 최근 3개의 데이터 요소 중 일부가 누락된 경우 경보를 평가할 때 가장 최근 데이터 요소 5개를 검색합니다. 5는 경보의 평가 범위입니다. 평가 범위가 5이므로 1열에는 가장 최근 데이터 요소 5개가 표시됩니다. 이러한 데이터 요소는 가장 최근 데이터 요소가 오른쪽에 표시됩니다. 0는 비위반 데이터 요소, X는 위반 데이터 요소, -는 누락 데이터 요소입니다. 2열은 필요한 데이터 요소 3개 중 누락된 개수를 표시합니다. 가장 최신 데이터 요소 5개가 평가되었더라도 경보 상태 평가를 위해 3개(**Evaluation Periods(평가 기간)**에 대한 설정)만 필요합니다. 2열의 데이터 요소 개수는 누락된 데이터 요소 처리 방법에 대한 설정을 사용하여 반드시 "채워야" 하는 데이터 요소의 수입니다. 3\$16열의 열 머리글은 누락 데이터를 처리하는 방법으로 가능한 값입니다. 이러한 열의 행에는 누락 데이터를 처리할 수 있는 이러한 각 방법에 대해 설정된 경보 상태가 표시됩니다. | 데이터 포인트 | 채워야 하는 데이터 요소 수 | MISSING | IGNORE | 위반 | 위반하지 않음 | | --- | --- | --- | --- | --- | --- | | 0 - X - X | 0 | `OK` | `OK` | `OK` | `OK` | | - - - - 0 | 2 | `OK` | `OK` | `OK` | `OK` | | - - - - - | 3 | `INSUFFICIENT_DATA` | 현재 상태 유지 | `ALARM` | `OK` | | 0 X X - X | 0 | `ALARM` | `ALARM` | `ALARM` | `ALARM` | | - - X - - | 2 | `ALARM` | 현재 상태 유지 | `ALARM` | `OK` | 앞 테이블의 2행에서는 누락 데이터를 위반으로 처리하는 경우에도 경보 상태는 `OK`로 유지됩니다. 기존 데이터 포인트 중 하나가 위반 상태가 아니며, 위반으로 처리되는 2개의 누락 데이터 포인트와 함께 이를 평가하기 때문입니다. 다음번에 이 경보를 평가할 때도 데이터가 여전히 누락된 경우 해당 비위반 데이터 요소가 더 이상 평가 범위에 있지 않기 때문에 경보는 `ALARM` 상태가 됩니다. 가장 최근의 데이터 요소 5개가 모두 누락된 세 번째 행은 누락 데이터 처리 방법에 대한 다양한 설정이 경보 상태에 어떻게 영향을 주는지를 보여 줍니다. 누락된 데이터 요소를 위반으로 간주하는 경우 경보는 ALARM 상태가 되지만, 비위반으로 간주하는 경우 경보는 OK 상태가 됩니다. 누락된 데이터 요소를 무시하면 경보는 누락 데이터 요소 이전의 현재 상태를 유지합니다. 그리고 누락된 데이터 요소를 단지 누락으로 간주한다면 경보에 평가를 수행하기에 충분한 최근 실제 데이터가 없으며 경보는 INSUFFICIENT\$1DATA 상태가 됩니다. 네 번째 행에서는 가장 최근의 데이터 요소 세 개가 위반이며 경보의 [**평가 기간(Evaluation Periods)**]과 [**경보에 대한 데이터 요소(Datapoints to Alarm)**]가 둘 다 3으로 설정되어 있으므로 경보가 모든 경우에 `ALARM` 상태가 됩니다. 이 경우 누락된 데이터 요소는 무시되며 누락 데이터 평가 방법에 대한 설정은 필요하지 않습니다. 평가할 실제 데이터 요소가 3개 있기 때문입니다. 5행은 **‘조기 경보 상태’라고 하는 특별한 경우의 경보 평가를 나타냅니다. 자세한 내용은 [경보 상태 조기 전환 방지](#CloudWatch-alarms-avoiding-premature-transition) 단원을 참조하세요. 다음 테이블의 경우 **기간**은 다시 5분이며, **Datapoints to Alarm(경보에 대한 데이터 포인트)**는 2, **Evaluation Periods(평가 기간)**는 3입니다. 'N 중 M' 경보는 '3 중 2'입니다. 평가 범위는 5입니다. 이것은 검색되는 최근 데이터 포인트의 최대 수이며 일부 데이터 포인트가 누락된 경우 사용할 수 있습니다. | 데이터 포인트 | 누락 데이터 포인트 가운데 수(\$1) | 누락 | IGNORE | 위반 | 위반하지 않음 | | --- | --- | --- | --- | --- | --- | | 0 - X - X | 0 | `ALARM` | `ALARM` | `ALARM` | `ALARM` | | 0 0 X 0 X | 0 | `ALARM` | `ALARM` | `ALARM` | `ALARM` | | 0 - X - - | 1 | `OK` | `OK` | `ALARM` | `OK` | | - - - - 0 | 2 | `OK` | `OK` | `ALARM` | `OK` | | - - - - X | 2 | `ALARM` | 현재 상태 유지 | `ALARM` | `OK` | 1행과 2행에서는 가장 최근의 데이터 요소 3개 중 2개가 위반이므로 경보는 항상 ALARM 상태가 됩니다. 2행에서는 가장 최근 데이터 요소 3개가 누락되지 않았기 때문에 평가 범위에서 가장 오래된 두 데이터 요소가 필요하지 않으므로 오래된 이 두 데이터 요소는 무시됩니다. 3행과 4행에서는 누락된 데이터를 위반으로 처리하는 경우에만 경보가 ALARM 상태가 됩니다(여기서는 가장 최근의 누락 데이터 요소 두 개가 모두 위반으로 처리됨). 4행에서 위반으로 처리되는 이 두 누락 데이터 요소는 ALARM 상태를 트리거하는 데 필요한 위반 데이터 요소 두 개를 제공합니다. 5행은 **‘조기 경보 상태’라고 하는 특별한 경우의 경보 평가를 나타냅니다. 자세한 내용은 다음 섹션을 참조하세요. ### 경보 상태 조기 전환 방지 CloudWatch 경보 평가에는 데이터가 간헐적일 때 조기에 경보가 ALARM 상태가 되는 거짓 경보를 방지하기 위한 로직이 포함됩니다. 이전 단원에 있는 표의 5행에 표시된 예가 이 로직을 보여 줍니다. 해당 행과 다음 예에서 [**평가 기간(Evaluation Periods)**]은 3이고 평가 범위는 데이터 요소 5개입니다. [**경보에 대한 데이터 요소(Datapoints to Alarm)**]는 3입니다. 단, [**경보에 대한 데이터 요소(Datapoints to Alarm)**]가 2인 ‘M out of N(N 중 M)’ 예는 예외입니다. 경보의 가장 최근 데이터가 `- - - - X`이며 누락 데이터 요소 4개가 있고 가장 최근 데이터 요소로 위반 데이터 요소가 있다고 가정합니다. 다음 데이터 요소는 비위반일 수 있으므로 데이터가 `- - - - X` 또는 `- - - X -`이고 [**경보에 대한 데이터 요소(Datapoints to Alarm)**]가 3일 경우 경보는 즉시 ALARM 상태가 되지 않습니다. 이렇게 하면 다음 데이터 요소가 비위반이고 데이터가 `- - - X O` 또는 `- - X - O`가 되도록 하는 경우 거짓 긍정이 방지됩니다. 그러나 마지막 몇 개의 데이터 요소가 `- - X - -`인 경우 누락된 데이터 요소를 누락으로 처리하더라도 경보는 ALARM 상태가 됩니다. 이는 [**평가 기간(Evaluation Periods)**] 동안 사용 가능한 가장 오래된 위반 데이터 요소 수가 최소한 [**경보에 대한 데이터 요소(Datapoints to Alarm)**]의 값만큼 오래되고 더 최근의 다른 모든 데이터 요소가 위반 또는 누락인 경우 경보가 항상 ALARM 상태가 되도록 설계되었기 때문입니다. 이 경우 사용 가능한 데이터 요소의 총수가 M([**경보에 대한 데이터 요소(Datapoints to Alarm)**])보다 적더라도 경보는 ALARM 상태가 됩니다. 이 경보 로직은 ‘M out of N(N 중 M)’ 경보에도 적용됩니다. 평가 범위 동안 가장 오래된 위반 데이터 요소가 최소한 [**경보에 대한 데이터 요소(Datapoints to Alarm)**]의 값만큼 오래되고 더 최근의 모든 데이터 요소가 위반 또는 누락인 경우 경보는 M([**경보에 대한 데이터 요소(Datapoints to Alarm)**]) 값에 상관없이 ALARM 상태가 됩니다. ## CloudWatch Metrics Insights 경보에서 누락 데이터 **단일 시계열로 집계되는 Metrics Insights 쿼리를 기반으로 하는 경보** 누락 데이터 시나리오와 경보 평가에 미치는 영향은 구성된 누락 데이터 처리 측면에서 표준 지표 경보와 동일합니다. [CloudWatch 경보가 누락 데이터를 처리하는 방법 구성](#alarms-and-missing-data) 섹션을 참조하세요. **여러 시계열을 생성하는 Metrics Insights 쿼리를 기반으로 하는 경보** Metrics Insights 경보에 대한 누락 데이터 시나리오는 다음과 같은 경우에 나타납니다. + 시계열 내 개별 데이터 포인트는 존재하지 않습니다. + 여러 시계열을 평가할 때 하나 이상의 시계열이 사라집니다. + 쿼리에서 시계열이 검색되지 않습니다. 누락 데이터 시나리오는 다음과 같은 방식으로 경보 평가에 영향을 미칩니다. + 시계열 평가를 위해 누락 데이터 처리 처리가 시계열 내 개별 데이터 포인트에 적용됩니다. 예를 들어 시계열에 대해 3개의 데이터 포인트를 쿼리했지만 1개만 수신된 경우 2개의 데이터 포인트는 구성된 누락 데이터 구성을 따릅니다. + 쿼리에서 시계열을 더 이상 검색하지 않으면 누락 데이터 처리에 상관없이 `OK`로 전환됩니다. 기고자 수준에서 `OK` 전환과 관련된 경보 작업이 실행되고 `StateReason`은 '이 기고자에 대한 데이터가 반환되지 않음" 메시지와 함께 앞서 언급한 기고자를 찾을 수 없음을 지정합니다. 경보의 상태는 쿼리에서 검색한 다른 기고자의 상태에 따라 달라집니다. + 경보 수준에서 쿼리가 빈 결과(시계열 없음)를 반환하면 경보는 설정된 누락 데이터 처리에 관계없이 `INSUFFICIENT_DATA`로 전환됩니다. # 부분 데이터 처리 방법 ## Metrics Insights 쿼리의 일부 데이터를 처리하는 방법 경보에 사용된 Metrics Insights 쿼리가 10,000여 개의 지표와 일치하는 경우 쿼리가 찾은 처음 10,000개의 지표를 기반으로 경보가 평가됩니다. 이는 부분 데이터에 대해 경보가 평가되고 있음을 의미합니다. 다음 방법을 사용하여 Metrics Insights 경보가 현재 부분 데이터를 기반으로 경보 상태를 평가하고 있는지 여부를 확인할 수 있습니다. + 콘솔에서 **Details**(세부 정보) 페이지를 보기 위해 경보를 선택하면 해당 페이지에 **Evaluation warning: Not evaluating all data**(평가 경고: 모든 데이터를 평가하지 않음) 메시지가 나타납니다. + [describe-alarms](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/describe-alarms.html?highlight=describe%20alarms) AWS CLI 명령 또는 [DescribeAlarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_DescribeAlarms.html) API를 사용하면 `EvaluationState` 필드에 `PARTIAL_DATA` 값이 표시됩니다. 경보는 부분 데이터 상태가 될 때 Amazon EventBridge에 이벤트를 게시하므로 EventBridge 규칙을 생성하여 이러한 이벤트를 관찰할 수 있습니다. 이러한 이벤트에서 `evaluationState` 필드의 값은 `PARTIAL_DATA`입니다. 다음은 예입니다. ``` { "version": "0", "id": "12345678-3bf9-6a09-dc46-12345EXAMPLE", "detail-type": "CloudWatch Alarm State Change", "source": "aws.cloudwatch", "account": "123456789012", "time": "2022-11-08T11:26:05Z", "region": "us-east-1", "resources": [ "arn:aws:cloudwatch:us-east-1:123456789012:alarm:my-alarm-name" ], "detail": { "alarmName": "my-alarm-name", "state": { "value": "ALARM", "reason": "Threshold Crossed: 3 out of the last 3 datapoints [20000.0 (08/11/22 11:25:00), 20000.0 (08/11/22 11:24:00), 20000.0 (08/11/22 11:23:00)] were greater than the threshold (0.0) (minimum 1 datapoint for OK -> ALARM transition).", "reasonData": "{\"version\":\"1.0\",\"queryDate\":\"2022-11-08T11:26:05.399+0000\",\"startDate\":\"2022-11-08T11:23:00.000+0000\",\"period\":60,\"recentDatapoints\":[20000.0,20000.0,20000.0],\"threshold\":0.0,\"evaluatedDatapoints\":[{\"timestamp\":\"2022-11-08T11:25:00.000+0000\",\"value\":20000.0}]}", "timestamp": "2022-11-08T11:26:05.401+0000", "evaluationState": "PARTIAL_DATA" }, "previousState": { "value": "INSUFFICIENT_DATA", "reason": "Unchecked: Initial alarm creation", "timestamp": "2022-11-08T11:25:51.227+0000" }, "configuration": { "metrics": [ { "id": "m2", "expression": "SELECT SUM(PartialDataTestMetric) FROM partial_data_test", "returnData": true, "period": 60 } ] } } } ``` 경보에 대한 쿼리에 초기에 500여 개의 시계열을 반환하는 GROUP BY 문이 포함된 경우 쿼리가 찾은 처음 500개의 시계열을 기준으로 경보가 평가됩니다. 그러나 ORDER BY 절을 사용하면 쿼리가 찾은 모든 시계열이 정렬되고 ORDER BY 절에 따라 가장 높거나 가장 낮은 값을 가진 500개를 사용하여 경보가 평가됩니다. ## 다중 데이터 소스 경보의 부분 데이터 평가 방법 Lambda 함수가 부분 데이터를 반환하는 경우: + 경보는 반환되는 데이터 포인트에서 계속 평가됩니다. + 다음 방법을 사용하여 Lambda 함수의 경보가 현재 부분 데이터를 기반으로 경보 상태를 평가하고 있는지 여부를 확인할 수 있습니다. + 콘솔에서 경보를 선택하고 **세부 정보** 페이지를 선택합니다. **Evaluation warning: Not evaluating all data appears on that page** 메시지가 표시되면 부분 데이터에서 평가 중인 것입니다. + `describe-alarms` AWS CLI 명령 또는 DescribeAlarms API를 사용할 때 `EvaluationState` 필드에 `PARTIAL_DATA` 값이 표시되면 부분 데이터에서 평가 중인 것입니다. + 또한 경보는 부분 데이터 상태가 될 때 Amazon EventBridge에 이벤트를 게시합니다. # 백분위수 기반 경보 및 데이터 샘플 부족 경보를 위한 통계로 백분위수를 설정하면 정확한 통계 평가를 위한 데이터가 충분하지 않을 때 어떻게 할 것인지 지정할 수 있습니다. 경보가 통계를 어떻게든 평가하도록 하고 가능하면 경보 상태를 변경하도록 선택할 수 있습니다. 또는 샘플 크기가 작을 때 경보가 지표를 무시하고 통계적으로 의미가 있을 정도로 충분한 데이터가 모일 때까지 기다렸다가 평가할 수 있습니다. 0.5(포함) \$1 1.00(제외) 범위 백분위수의 경우, 평가 기간 동안 10/(1-백분위수) 보다 적은 데이터 포인트가 있을 때 이 설정이 사용됩니다. 예를 들어 p99 백분위수에서 경보 샘플이 1,000개보다 적을 경우 이 설정이 사용됩니다. 0 \$1 0.5(제외) 범위 백분위수의 경우, 10/백분위수 보다 적은 백분위수가 있을 때 이 설정이 사용됩니다. # PromQL 경보 PromQL 경보는 PromQL(Prometheus Query Language) 인스턴트 쿼리를 사용하여 지표를 모니터링합니다. 쿼리는 CloudWatch OTLP 엔드포인트를 통해 수집된 지표를 선택하고, 쿼리에서 반환되는 일치하는 모든 시계열은 위반으로 간주됩니다. 경보는 정기적인 간격으로 쿼리를 평가하고 각 위반 시계열을 *기고자*로 독립적으로 추적합니다. OpenTelemetry를 사용하여 지표를 수집하는 방법에 대한 자세한 내용은 [OpenTelemetry](CloudWatch-OpenTelemetry-Sections.md) 섹션을 참조하세요. ## PromQL 경보 작동 방식 PromQL 경보는 `EvaluationInterval`에서 정의한 반복 일정에 따라 PromQL 인스턴트 쿼리를 평가합니다. 쿼리는 조건을 충족하는 시계열만 반환합니다. 반환된 각 시계열은 고유한 속성 집합으로 식별되는 *기고자*입니다. 경보는 기간 기반 상태 전환을 사용합니다. + 쿼리에 의해 기고자가 반환되면 *위반*으로 간주됩니다. 기고자가 `PendingPeriod`에 지정된 기간 동안 위반이 계속되면 기고자는 `ALARM` 상태로 전환됩니다. + 쿼리에 의한 기고자 반환이 중단되면 *복구*로 간주됩니다. 기고자가 `RecoveryPeriod`에 지정된 기간 동안 계속 부재하는 경우 기고자는 `OK` 상태로 전환됩니다. 하나 이상의 기고자가 보류 기간보다 오래 위반 상태가 되는 경우 경보는 `ALARM` 상태입니다. 모든 기고자가 복구되면 경보는 `OK` 상태로 돌아갑니다. ## PromQL 경보 구성 PromQL 경보는 다음 파라미터로 구성됩니다. + **PendingPeriod**는 기고자가 `ALARM` 상태로 전환되기 전에 기고자가 지속적으로 위반해야 하는 기간(초 단위)입니다. Prometheus 경보 규칙의 `for` 기간과 동일합니다. + **RecoveryPeriod**는 기고자가 `OK` 상태로 전환되기 전에 기고자가 위반을 중지해야 하는 기간(초 단위)입니다. Prometheus 경보 규칙의 `keep_firing_for` 기간과 동일합니다. + **EvaluationInterval**은 경보가 PromQL 쿼리를 평가하는 빈도(초 단위)입니다. PromQL 경보를 생성하려면 [PromQL 쿼리를 사용하여 경보 생성](Create_PromQL_Alarm.md) 섹션을 참조하세요. # 복합 경보 CloudWatch를 사용하면 여러 경보를 하나의 *복합 경보*로 결합하여 전체 애플리케이션 또는 리소스 그룹에 대해 요약되고 집계된 상태 지표를 생성할 수 있습니다. 복합 경보는 다른 경보의 상태를 모니터링하여 상태를 확인하는 경보입니다. 사용자는 Boolean 논리를 사용하여 모니터링되는 경보의 상태를 결합하는 규칙을 정의합니다. 복합 경보를 사용하면 집계된 수준에서만 조치를 실행하므로 경보 노이즈를 줄일 수 있습니다. 예를 들어, 웹 서버와 관련된 경보가 트리거되는 경우 복합 경보를 생성하어 웹 서버 팀에 알림을 보낼 수 있습니다. 이러한 경보 중 하나라도 ALARM 상태로 전환되면 복합 경보는 스스로 ALARM 상태가 되어 팀에 알림을 보냅니다. 웹 서버와 관련된 다른 경보가 ALARM 상태로 전환되더라도 복합 경보가 이미 기존 상황에 대해 알렸기 때문에 팀에 새 알림이 과도하게 오지 않습니다. 또한 복합 경보를 사용하여 복잡한 경보 조건을 생성하고 여러 조건이 충족될 때만 조치를 취할 수 있습니다. 예를 들어, CPU 경보와 메모리 경보를 결합하여 CPU와 메모리 경보가 모두 트리거된 경우에만 팀에 알리는 복합 경보를 생성하 수 있습니다. **복합 경보 사용** 복합 경보를 사용하는 경우 두 가지 옵션이 있습니다. + 복합 경보 수준에서만 수행할 작업을 구성하고, 조치가 없는 기본 모니터링 경보를 만듭니다 + 복합 경보 수준에서 다양한 작업의 조합을 구성합니다. 예를 들어, 복합 경보 작업에서는 문제가 광범위하게 발생하는 경우 다른 팀을 참여시킬 수 있습니다. 복합 경보는 다음과 같은 작업만 수행할 수 있습니다. + Amazon SNS 주제 알림 + Lambda 함수 간접 호출 + Systems Manager Ops Center에 OpsItem 생성 + Systems Manager Incident Manager에 인시던트 생성 **참고** 복합 경보의 모든 기본 경보는 복합 경보와 동일한 계정 및 동일한 리전에 있어야 합니다. 그러나 CloudWatch 크로스 계정 관측성 모니터링 계정에서 복합 경보를 설정하면 기본 경보가 다른 소스 계정과 모니터링 계정 자체에서 지표를 관찰할 수 있습니다. 자세한 내용은 [CloudWatch 크로스 계정 관측성](CloudWatch-Unified-Cross-Account.md) 섹션을 참조하세요. 단일 복합 경보로 100개의 기본 경보를 모니터링할 수 있고, 150개의 복합 경보로 단일 기본 경보를 모니터링할 수 있습니다. **규칙 표현식** 모든 복합 경보에는 규칙 표현식이 포함됩니다. 규칙 표현식은 모니터링하고 상태를 확인할 다른 경보를 복합 경보에 알려줍니다. 규칙 표현식은 지표 경보 및 복합 경보를 참조할 수 있습니다. 규칙 표현식에서 경보를 참조할 경우, 다음 세 가지 상태 중 경보가 어떤 상태로 전환될지를 결정하는 함수를 경보에 지정합니다. + 경보 경보가 ALARM 상태인 경우 ALARM ("alarm-name or alarm-ARN")이 TRUE입니다. + 정상 경보가 OK 상태인 경우 OK ("alarm-name or alarm-ARN")가 TRUE입니다. + INSUFFICIENT\$1DATA 명명된 경보가 INSUFFICIENT\$1DATA 상태인 경우 INSUFFICIENT\$1DATA ("alarm-name or alarm-ARN")가 TRUE입니다. **참고** TRUE는 항상 TRUE로 평가되고 FALSE는 항상 FALSE로 평가됩니다. **경보 참조** 경보 이름 또는 ARN을 사용하여 경보를 참조할 경우, 규칙 구문에서는 경보 이름 또는 ARN을 따옴표(")로 묶거나 묶지 않아도 경보를 참조하도록 지원할 수 있습니다. + 따옴표 없이 지정한 경우 경보 이름 또는 ARN에 공백, 둥근 괄호 또는 쉼표를 포함해서는 안 됩니다. + 따옴표 내에 지정한 경우, 참조가 올바르게 해석되려면 큰따옴표(")가 *포함된* 경보 이름 또는 ARN은 큰따옴표(")를 백슬래시 이스케이프(\$1) 문자로 묶어야 합니다. **구문** 여러 경보를 하나의 복합 경보로 결합하는 데 사용하는 표현식의 구문에서는 부울 로직과 함수를 사용합니다. 다음 표에서는 규칙 표현식에서 사용할 수 있는 연산자와 함수를 설명합니다. | 연산자/함수 | 설명 | | --- | --- | | AND | 논리적 AND 연산자. 지정된 모든 조건이 TRUE일 때 TRUE를 반환합니다. | | OR | 논리적 OR 연산자. 지정된 조건 중 하나 이상이 TRUE일 때 TRUE를 반환합니다. | | NOT | 논리적 NOT 연산자. 지정된 조건이 FALSE일 때 TRUE를 반환합니다. | | AT\$1LEAST | 지정된 경보의 최소 개수 또는 백분율이 원하는 상태일 때 TRUE를 반환하는 함수. 형식: AT\$1LEAST(M, STATE\$1CONDITION, (alarm1, alarm2, ...alarmN)) 여기서 M은 절대 수 또는 백분율(예: 50%)일 수 있으며 STATE\$1CONDITION은 ALARM, OK, INSUFFICIENT\$1DATA, NOT ALARM, NOT OK 또는 NOT INSUFFICIENT\$1DATA일 수 있습니다. | 괄호를 사용하여 조건을 그룹화하고 복잡한 표현식에서 평가 순서를 제어할 수 있습니다. **예제 표현식** 요청 파라미터 `AlarmRule`은 논리 연산자 `AND`, `OR`, `NOT`, `AT_LEAST` 함수를 지원하므로 작업자가 여러 함수를 단일 표현식으로 결합할 수 있습니다. 다음 예제 표현식은 복합 경보의 기본 경보를 구성하는 방법을 보여줍니다. + `ALARM(CPUUtilizationTooHigh) AND ALARM(DiskReadOpsTooHigh)` 이 표현식은 `CPUUtilizationTooHigh`와 `DiskReadOpsTooHigh`가 `ALARM` 상태인 경우에만 복합 경보를 `ALARM` 상태로 전환하도록 지정합니다. + `AT_LEAST(2, ALARM, (WebServer1CPU, WebServer2CPU, WebServer3CPU, WebServer4CPU))` 표현식은 웹 서버 CPU 경보 4개 중 2개 이상이 `ALARM` 상태일 때 복합 경보가 `ALARM`으로 전환되도록 지정합니다. 이렇게 하면 모든 리소스가 경보 상태에 있어야 하거나, 하나의 리소스만 경보 상태에 있어야 할 필요 없이 영향을 받은 리소스의 임곗값에 따라 알림을 트리거할 수 있습니다. + `AT_LEAST(50%, OK, (DatabaseConnection1, DatabaseConnection2, DatabaseConnection3, DatabaseConnection4))` 표현식은 데이터베이스 연결 경보의 50% 이상이 `OK` 상태일 때 복합 경보가 `ALARM`으로 전환되도록 지정합니다. 백분율을 사용하면 모니터링되는 경보를 추가하거나 제거할 때 규칙을 동적으로 조정할 수 있습니다. + `ALARM(CPUUtilizationTooHigh) AND NOT ALARM(DeploymentInProgress)` 이 표현식은 `CPUUtilizationTooHigh`가 `ALARM` 상태이고 `DeploymentInProgress`가 `ALARM` 상태인 경우에만 복합 경보를 `ALARM` 상태로 전환하도록 지정합니다. 배포 기간 동안 경보 노이즈를 줄이는 복합 경보의 예입니다. + `AT_LEAST(2, ALARM, (AZ1Health, AZ2Health, AZ3Health)) AND NOT ALARM(MaintenanceWindow)` 표현식은 가용 영역 상태 경보 3개 중 2개 이상이 `ALARM` 상태이고 유지 관리 기간 경보가 `ALARM` 상태가 아닐 경우 복합 경보가 `ALARM`으로 전환되도록 지정합니다. 이렇게 하면 더 복잡한 모니터링 시나리오를 위해 AT\$1LEAST 함수가 다른 논리 연산자와 결합됩니다. # 경보 억제 복합 경보 작업 억제를 사용하면 경보 구성을 삭제하거나 수정하지 않고도 경보 작업을 일시적으로 비활성화할 수 있습니다. 이는 계획된 유지 관리, 배포 또는 알려진 문제를 조사할 때 유용합니다. 복합 경보 작업 억제 기능을 사용하면 경보를 억제 경보로 정의할 수 있습니다. 억제 경보는 복합 경보가 작업을 수행하지 않도록 합니다. 예를 들어 지원 리소스의 상태를 나타내는 억제 경보를 지정할 수 있습니다. 지원 리소스가 다운된 경우 억제 경보는 복합 경보가 알림을 보내지 못하게 합니다. ## 경보 억제를 사용해야 하는 경우 경보 억제가 유용한 일반적인 상황: + 애플리케이션의 유지 관리 기간 + 애플리케이션 배포 + 지속적인 인시던트 조사 + 테스트 및 개발 활동 ## 억제 경고 작동 방식 억제 경보는 복합 경보를 구성할 때 지정합니다. 모든 경보는 억제 경보로 작동할 수 있습니다. 억제 경보의 상태가 `OK`에서 `ALARM`으로 변경되면 복합 경보가 더 이상 작업을 수행하지 않습니다. 억제 경보의 상태가 `ALARM`에서 `OK`로 변경되면 복합 경보가 작업을 재개합니다. 복합 경보를 사용하면 여러 경보의 상태를 종합적으로 볼 수 있으며, 경보가 트리거될 것으로 예상되는 일반적인 상황이 있습니다. 예를 들어, 애플리케이션의 유지 관리 기간 중이거나 진행 중인 사고를 조사하는 경우입니다. 이러한 상황에서는 복합 경보의 동작을 억제하여 원치 않는 알림이나 새로운 인시던트 티켓이 생성되는 것을 방지할 수 있습니다 복합 경보 작업 억제 기능을 사용하면 경보를 억제 경보로 정의할 수 있습니다. 억제 경보는 복합 경보가 작업을 수행하지 않도록 합니다. 예를 들어 지원 리소스의 상태를 나타내는 억제 경보를 지정할 수 있습니다. 지원 리소스가 다운된 경우 억제 경보는 복합 경보가 알림을 보내지 못하게 합니다. 복합 경보 작업 억제 기능은 경보 노이즈를 줄이는 데 도움이 되므로, 경보를 관리하는 데 허비하는 시간을 줄이고 운영에 더 많은 시간을 할애할 수 있습니다. 억제 경보는 복합 경보를 구성할 때 지정합니다. 모든 경보는 억제 경보로 작동할 수 있습니다. 억제 경보의 상태가 `OK`에서 `ALARM`으로 변경되면 복합 경보가 더 이상 작업을 수행하지 않습니다. 억제 경보의 상태가 `ALARM`에서 `OK`로 변경되면 복합 경보가 작업을 재개합니다. ### `WaitPeriod` 및 `ExtensionPeriod` 억제 경보를 지정할 때 `WaitPeriod` 및 `ExtensionPeriod` 파라미터를 설정합니다. 이들 파라미터는 억제 경보의 상태가 바뀌는 동안 복합 경보가 예기치 않게 작업을 수행하는 것을 방지합니다. `WaitPeriod`를 사용하여 억제 경보가 `OK` 상태에서 `ALARM` 상태로 변경될 때 발생할 수 있는 지연을 상쇄합니다. 예를 들어 억제 경보가 60초 이내에 `OK` 상태에서 `ALARM` 상태로 변경되는 경우 `WaitPeriod`를 60초로 설정합니다. ![\[WaitPeriod 내의 작업 억제\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/example1border.png) 이 이미지에서 복합 경보는 t2에 `OK` 상태에서 `ALARM` 상태로 변경됩니다. `WaitPeriod`가 t2에 시작되어 t8에 끝납니다. 이렇게 하면 t8에 `WaitPeriod`가 만료되어 복합 경보의 작업을 억제하기 전까지, 억제 경보가 t4에 상태를 `OK`에서 `ALARM`으로 변경할 시간을 확보할 수 있습니다. `ExtensionPeriod`를 사용하여, 억제 경보가 `OK` 상태로 변경된 후 복합 경보가 `OK` 상태로 변경될 때 발생할 수 있는 지연을 상쇄합니다. 예를 들어 억제 경보가 `OK` 상태로 변경되고 나서 60초 이내에 복합 경보가 `OK` 상태로 변경되는 경우 `ExtensionPeriod`를 60초 설정합니다. ![\[ExtensionPeriod 내의 작업 억제\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/example2border.png) 이 이미지에서 억제 경보는 t2에 `ALARM` 상태에서 `OK` 상태로 변경됩니다. `ExtensionPeriod`가 t2에 시작되어 t8에 끝납니다. 이렇게 하면 t8에 `ExtensionPeriod`가 만료되기 전에 복합 경보가 `ALARM` 상태에서 `OK` 상태로 변경할 시간을 확보할 수 있습니다. `WaitPeriod`와 `ExtensionPeriod`가 활성화되면 복합 경보가 작업을 수행하지 않습니다. `ExtensionPeriod`와 `WaitPeriod`가 비활성화되면 복합 경보가 현재 상태에 따라 작업을 수행합니다. 1분마다 지표 경보를 평가하므로 각 파라미터의 값을 60초로 설정하는 것이 좋습니다. 파라미터는 초 단위의 원하는 정수로 설정할 수 있습니다. 다음 예에서는`WaitPeriod`과 `ExtensionPeriod`를 사용하여 복합 경보가 예기치 않게 작업을 수행하지 않도록 방지하는 방법을 자세히 설명합니다. **참고** 다음 예에서 `WaitPeriod`는 두 시간 단위로 구성되고 `ExtensionPeriod`는 세 시간 단위로 구성됩니다. #### 예제 ** 예 1: `WaitPeriod` 후에 작업이 억제되지 않음 ** ![\[작업 억제의 첫 번째 예\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/example3border.png) 이 이미지에서 복합 경보는 t2에 `OK` 상태에서 `ALARM` 상태로 변경됩니다. `WaitPeriod`가 t2에 시작되어 t4에 끝나므로 복합 경보가 작업을 수행하지 못하게 할 수 있습니다. 억제 경보가 아직 `OK` 상태이므로, t4에 `WaitPeriod`가 만료되고 나면 복합 경보가 작업을 수행합니다. ** 예 2: `WaitPeriod`가 만료되기 전에 경보에 의해 동작이 억제됨 ** ![\[작업 억제의 두 번째 예\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/example4border.png) 이 이미지에서 복합 경보는 t2에 `OK` 상태에서 `ALARM` 상태로 변경됩니다. `WaitPeriod`가 t2에 시작되어 t4에 끝납니다. 따라서 억제 경보가 t3에 `OK` 상태에서 `ALARM` 상태로 변경할 시간을 확보할 수 있습니다. t3에 억제 경보의 상태가 `OK`에서 `ALARM`으로 변경되므로, t2에 시작되는 `WaitPeriod`가 폐기되고 억제 경보가 이제 복합 경보가 작업을 수행하지 못하게 합니다. ** 예 3: `WaitPeriod`에 의해 작업이 억제될 때의 상태 전환 ** ![\[작업 억제의 세 번째 예\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/example5border.png) 이 이미지에서 복합 경보는 t2에 `OK` 상태에서 `ALARM` 상태로 변경됩니다. `WaitPeriod`가 t2에 시작되어 t4에 끝납니다. 따라서 억제 경보가 상태를 변경할 시간을 확보할 수 있습니다. 복합 경보가 t3에 `OK` 상태로 다시 변경되므로, t2에 시작된 `WaitPeriod`가 폐기됩니다. 새 `WaitPeriod`는 t3에 시작되어 t5에 끝납니다. 새 `WaitPeriod`가 t5에 만료되면 복합 경보가 작업을 수행합니다. ** 예 4: 경보에 의해 작업이 억제될 때의 상태 전환 ** ![\[작업 억제의 네 번째 예\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/cwasexamplefourborder.png) 이 이미지에서 복합 경보는 t2에 `OK` 상태에서 `ALARM` 상태로 변경됩니다. 억제 경보가 이미 `ALARM` 상태입니다. 억제 경보는 복합 경보가 작업을 수행하는 것을 방지합니다. ** 예 5: `ExtensionPeriod` 후에 작업이 억제되지 않음 ** ![\[작업 억제의 다섯 번째 예\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/example7border.png) 이 이미지에서 복합 경보는 t2에 `OK` 상태에서 `ALARM` 상태로 변경됩니다. `WaitPeriod`가 t2에 시작되어 t4에 끝납니다. 따라서 t6에 복합 경보의 작업을 억제하기 전까지, 억제 경보가 t3에 상태를 `OK`에서 `ALARM`으로 변경할 시간을 확보할 수 있습니다. t3에 억제 경보의 상태가 `OK`에서 `ALARM`으로 변경되므로, t2에 시작된 `WaitPeriod`가 폐기됩니다. t6에 억제 경보가 `OK` 상태로 변경됩니다. `ExtensionPeriod`가 t6에 시작되어 t9에 끝납니다. `ExtensionPeriod`이(가) 만료되면 복합 경보가 작업을 수행합니다. ** 예 6: `ExtensionPeriod`에 의해 작업이 억제될 때의 상태 전환 ** ![\[작업 억제의 여섯 번째 예\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/cwasexamplesixrborder.png) 이 이미지에서 복합 경보는 t2에 `OK` 상태에서 `ALARM` 상태로 변경됩니다. `WaitPeriod`가 t2에 시작되어 t4에 끝납니다. 따라서 t6에 복합 경보의 작업을 억제하기 전까지, 억제 경보가 t3에 상태를 `OK`에서 `ALARM`으로 변경할 시간을 확보할 수 있습니다. t3에 억제 경보의 상태가 `OK`에서 `ALARM`으로 변경되므로, t2에 시작된 `WaitPeriod`가 폐기됩니다. t6에 억제 경보가 다시 `OK` 상태로 변경됩니다. `ExtensionPeriod`가 t6에 시작되어 t9에 끝납니다. t7에 복합 경보가 다시 `OK` 상태로 변경되면, `ExtensionPeriod`가 폐기되고 새 `WaitPeriod`가 t7에 시작되어 t9에 끝납니다. **작은 정보** 억제 경보를 바꾸면 모든 활성 `WaitPeriod` 또는 `ExtensionPeriod`가 폐기됩니다. ## 작업 억제 및 음소거 규칙 복합 경보에 대해 작업 억제 및 경보 음소거 규칙이 모두 활성화된 경우 음소거 규칙이 우선하고 모든 경보 작업을 억제합니다. 음소거 기간이 종료된 후 복합 경보의 작업 억제 구성은 억제 경보 상태와 구성된 대기 또는 연장 기간을 기반으로 작업이 실행되는지를 확인합니다. 경보 음소거 규칙에 대한 자세한 내용은 [경보 음소거 규칙](alarm-mute-rules.md) 섹션을 참조하세요. # 경보 작업 경보 상태가 OK, ALARM, INSUFFICIENT\$1DATA 간에 변경될 때 경보가 수행하는 작업을 지정할 수 있습니다. 세 가지 상태 각각으로 전환하기 위한 대부분의 작업을 설정할 수 있습니다. Auto Scaling 작업을 제외한 모든 작업은 상태 전환 시에만 수행되며 상태가 몇 시간 또는 며칠 동안 지속되는 경우 다시 수행되지 않습니다. 다음이 경보 작업으로 지원됩니다. + Amazon Simple Notification Service 주제를 사용하여 한 명 이상의 구독자에게 알립니다. 구독자는 개인일 뿐만 아니라 애플리케이션일 수도 있습니다. + Lambda 함수를 간접적으로 호출합니다. 이는 경보 상태 변경에 대한 사용자 지정 작업을 자동화하는 가장 쉬운 방법입니다. + EC2 지표를 기반으로 하는 경보는 EC2 인스턴스 중지, 종료, 재부팅 또는 복구와 같은 EC2 작업을 수행할 수도 있습니다. + 경보는 오토 스케일링의 규모를 조정하는 작업을 수행할 수 있습니다. + 경보는 Systems Manager Ops Center에서 OpsItems를 생성하거나 AWS Systems Manager Incident Manager에서 인시던트를 생성할 수 있습니다. 이러한 작업은 경보가 ALARM 상태가 될 때만 수행됩니다. + 경보는 ALARM 상태가 되었을 때 조사를 시작할 수 있습니다. 경보도 상태가 변경될 때 Amazon EventBridge로 이벤트를 내보내며, 이러한 상태 변경에 대해 다른 작업을 트리거하도록 Amazon EventBridge를 설정할 수 있습니다. ## 경보 작업 및 알림 다음 표에는 여러 시계열(또는 기고자) 경보에 대한 동작과 함께 경보에 대해 실행된 작업이 나와 있습니다. | 작업 유형 | Metrics Insights 다중 시계열 경보 지원 | PromQL 경보 지원 | 추가 정보 | | --- | --- | --- | --- | | SNS 알림 | 기고자 수준 | 기고자 수준 | [Amazon SNS event destinations](https://docs.aws.amazon.com/sns/latest/dg/sns-event-destinations.html) | | EC2 작업(중지, 종료, 재부팅, 복구) | 지원되지 않음 | 지원되지 않음 | [EC2 인스턴스 중지, 종료, 재부팅 또는 복구](UsingAlarmActions.md) | | 오토 스케일링 작업 | 지원되지 않음 | 지원되지 않음 | [Amazon EC2 Auto Scaling의 단계별 조정 및 단순 조정 정책](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html) | | Systems Manager OpsItem 생성 | 경보 수준 | 지원되지 않음 | [OpsItems를 생성하도록 CloudWatch 경보 구성](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) | | Systems Manager Incident Manager 인시던트 | 경보 수준 | 지원되지 않음 | [CloudWatch 경보를 사용하여 자동으로 인시던트 생성](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html#incident-tracking-auto-alarms) | | Lambda 함수 간접 호출 | 기고자 수준 | 기고자 수준 | [경보에서 Lambda 함수 간접 호출](alarms-and-actions-Lambda.md) | | CloudWatch 조사 | 경보 수준 | 지원되지 않음 | [경보에서 CloudWatch 조사를 시작](Start-Investigation-Alarm.md) | 경보 알림의 내용은 경보 유형에 따라 다릅니다. + 단일 지표 경보에는 상태 이유와 세부 상태 이유 데이터가 모두 포함되며 상태 변경의 원인이 된 특정 데이터 포인트를 표시합니다. + 다중 시계열 Metrics Insights 경보는 자세한 상태 이유 데이터 블록 없이 각 기고자에 대한 간소화된 상태 이유를 제공합니다. + PromQL 경보 알림에는 상태 이유 또는 상태 이유 데이터가 포함되지 않습니다. **Example 알림 콘텐츠 예제** 단일 지표 경보 알림에는 자세한 데이터가 포함됩니다. ``` { "stateReason": "Threshold Crossed: 3 out of the last 3 datapoints [32.6 (03/07/25 08:29:00), 33.8 (03/07/25 08:24:00), 41.0 (03/07/25 08:19:00)] were greater than the threshold (31.0)...", "stateReasonData": { "version": "1.0", "queryDate": "2025-07-03T08:34:06.300+0000", "startDate": "2025-07-03T08:19:00.000+0000", "statistic": "Average", "period": 300, "recentDatapoints": [41, 33.8, 32.6], "threshold": 31, "evaluatedDatapoints": [ { "timestamp": "2025-07-03T08:29:00.000+0000", "sampleCount": 5, "value": 32.6 } // Additional datapoints... ] } } ``` 기고자에 대한 여러 시계열 Metrics Insights 경보 SNS 알림 예제: ``` { "AlarmName": "DynamoDBInsightsAlarm", "NewStateValue": "ALARM", "NewStateReason": "Threshold Crossed: 1 datapoint was less than the threshold (1.0). The most recent datapoint which crossed the threshold: [0.0 (01/12/25 13:34:00)].", "StateChangeTime": "2025-12-01T13:42:04.919+0000", "OldStateValue": "OK", "AlarmContributorId": "6d442278dba546f6", "AlarmContributorAttributes": { "TableName": "example-dynamodb-table-name" } // Additional information... } ``` 기고자에 대한 PromQL 경보 SNS 알림 예제: ``` { "AlarmName": "HighCPUUsageAlarm", "NewStateValue": "ALARM", "StateChangeTime": "2025-12-01T13:42:04.919+0000", "OldStateValue": "OK", "AlarmContributorId": "1d502278dcd546a1", "AlarmContributorAttributes": { "team": "example-team-name" } // Additional information... } ``` ## 경보 작업 음소거 경보 음소거 규칙을 사용하면 유지 관리 기간 또는 운영 이벤트와 같은 사전 정의된 기간에 경보 작업을 자동으로 음소거할 수 있습니다. CloudWatch는 원치 않는 알림을 방지하면서 경보 상태를 계속 모니터링합니다. 자세한 내용은 [경보 음소거 규칙](alarm-mute-rules.md) 섹션을 참조하세요. **음소거 규칙 및 경보 작업 비활성화** 경보 음소거 규칙은 예약된 기간에 일시적으로 작업을 음소거하고 해당 기간이 종료되면 자동으로 음소거를 해제합니다. 반대로 `DisableAlarmActions` API는 사용자가 `EnableAlarmActions`를 수동으로 직접 호출할 때까지 경보 작업을 영구적으로 비활성화합니다. `EnableAlarmActions` API는 활성 음소거 규칙에 의해 음소거된 경보를 음소거 해제하지 않습니다. **참고** 경보를 음소거해도 CloudWatch가 경보의 생성, 업데이트, 삭제 및 상태 변경에 대한 경보 이벤트를 Amazon EventBridge로 전송하는 작업은 중지되지 않습니다. # 경보 음소거 규칙 경보 음소거 규칙은 사전 정의된 기간에 경보 작업을 자동으로 음소거하는 메커니즘을 제공하는 CloudWatch 기능입니다. 음소거 규칙을 생성할 때 작업이 음소거되는 특정 기간과 대상 경보를 정의합니다. CloudWatch는 예상되는 운영 이벤트 중에 원치 않는 알림 또는 자동화된 경보 작업을 방지하면서 경보 상태를 계속 모니터링하고 평가합니다. 경보 음소거 규칙은 경보 작업이 불필요하거나 운영을 중단시키는 중요한 운영 시나리오를 관리하는 데 도움이 됩니다. 예를 들어 계획된 유지 관리 기간에 시스템이 의도적으로 오프라인 상태가 되거나 시스템에서 예상되는 문제가 발생하는 동안 자동화된 경보 작업을 방지하여 중단 없이 유지 관리를 수행할 수 있습니다. 주말이나 공휴일과 같은 업무 외 시간에 수행되는 운영의 경우 즉각적인 대응이 필요하지 않을 때 중요하지 않은 경보 작업을 음소거하여 경보 노이즈를 줄이고 운영 팀에 전송되는 불필요한 알림을 줄일 수 있습니다. 테스트 환경에서 음소거 규칙을 사용하면 예상되는 리소스 사용량이나 오류율이 높고 즉각적인 주의가 필요하지 않은 부하 테스트와 같은 시나리오에서 경보 작업을 일시적으로 음소거할 수 있습니다. 팀이 문제를 적극적으로 해결하는 경우 음소거 규칙은 중복 경보 작업이 트리거되지 않도록 할 수 있으므로 중복 경보 알림으로 인한 방해 없이 문제 해결에 집중할 수 있습니다. ## 경보 음소거 규칙 정의 경보 음소거 규칙은 **규칙** 및 **대상**을 사용하여 정의할 수 있습니다. + **규칙** - 경보 작업을 음소거해야 하는 기간을 정의합니다. 규칙은 다음과 같은 세 가지 속성으로 구성됩니다. + **표현식** - 음소거 기간이 시작되는 시점과 반복되는 방식을 정의합니다. 다음과 같은 두 가지 유형의 표현식을 사용할 수 있습니다. + **Cron 표현식** - 표준 cron 구문을 사용하여 반복되는 음소거 기간을 생성합니다. 이 접근 방식은 주간 시스템 업데이트 또는 일일 백업 작업과 같은 정기 유지 관리 일정에 적합합니다. Cron 표현식을 사용하면 특정 요일, 월 또는 시간을 포함하여 복잡한 반복 패턴을 지정할 수 있습니다. *cron 표현식 구문* ``` ┌───────────── minute (0 - 59) │ ┌───────────── hour (0 - 23) │ │ ┌───────────── day of the month (1 - 31) │ │ │ ┌───────────── month (1 - 12) (or JAN-DEC) │ │ │ │ ┌───────────── day of the week (0 - 6) (0 or 7 is Sunday, or MON-SUN) │ │ │ │ │ │ │ │ │ │ * * * * * ``` + `*`, `,`, `-` 문자는 모든 필드에서 지원됩니다. + 영어 이름은 `month`(JAN-DEC) 및 `day of week`(SUN-SAT) 필드에 사용할 수 있습니다. + **표현식에서** - 일회성 음소거 기간에 표현식에서 사용합니다. 이 접근 방식은 알려진 시간에 한 번 수행되는 계획된 운영 이벤트에 적합합니다. ``` Syntax: `at(yyyy-MM-ddThh:mm)` ``` + **기간** - 음소거 규칙이 활성화된 후 지속되는 기간을 지정합니다. 기간은 ISO-8601 형식을 사용하여 최소 1분(PT1M)에서 최대 15일(P15D)로 지정해야 합니다. + **시간대** - 'America/Los\$1Angeles' 또는 'Europe/London'과 같은 표준 시간대 식별자를 사용하여 표현식에 따라 음소거 기간이 적용되는 시간대를 지정합니다. + **대상** - 정의된 기간에 작업이 음소거되는 경보 이름 목록을 지정합니다. 대상 목록에 지표 경보와 복합 경보를 모두 포함할 수 있습니다. 선택적으로 시작 및 종료 타임스탬프를 포함하여 음소거 기간에 대한 추가 경계를 제공할 수 있습니다. 시작 타임스탬프는 음소거 규칙이 특정 날짜 및 시간 이전에 활성화되지 않도록 하는 반면, 종료 타임스탬프는 지정된 날짜 및 시간 이후에 규칙이 적용되지 않도록 합니다. 프로그래밍 방식으로 경보 음소거 규칙을 생성하는 방법에 대한 자세한 내용은 [PutAlarmMuteRule](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutAlarmMuteRule.html)을 참조하세요. **참고** 대상 경보는 동일한 AWS 계정 및 동일한 AWS 리전(음소거 규칙이 생성됨)에 있어야 합니다. 단일 경보 음소거 규칙은 경보 이름별로 최대 100개의 경보를 대상으로 지정할 수 있습니다. CloudWatch 콘솔에는 전용 '경보 음소거 규칙' 탭이 있으며, 여기에서 AWS 계정 내 모든 음소거 규칙을 중앙에서 관리할 수 있습니다. 규칙 이름과 같은 음소거 규칙 속성을 사용하여 특정 음소거 규칙을 검색할 수 있습니다. ## 음소거 규칙 상태 경보 음소거 규칙이 생성되면 아래 세 가지 상태 중 하나일 수 있습니다. + **SCHEDULED** - 구성된 기간 표현식에 따라 향후 시점에 음소거 규칙이 활성화됩니다. + **ACTIVE** - 음소거 규칙은 구성된 기간 표현식에 따라 현재 활성 상태이며 대상 경보 작업을 능동적으로 음소거합니다. + **EXPIRED** - 음소거 규칙은 향후 더 이상 SCHEDULED/ACTIVE 상태가 아닙니다. 일회성 음소거 규칙의 경우 음소거 기간이 종료된 후 또는 반복 음소거 규칙의 경우 종료 타임스탬프가 구성되고 해당 시간이 경과한 경우에 나타납니다. ## 경보에서 음소거 규칙의 영향 활성 음소거 기간에 대상 경보에서 상태가 변경되고 작업이 구성된 경우 CloudWatch는 해당 작업을 실행하지 않도록 음소거합니다. 음소거는 경보 작업에만 적용됩니다. 즉, 경보가 계속 평가되고 상태 변경이 CloudWatch 콘솔에 표시되지만 Amazon Simple Notification Service 알림, Amazon Elastic Compute Cloud Auto Scaling 작업 또는 Amazon EC2 작업과 같이 구성된 작업은 실행되지 않습니다. CloudWatch는 음소거 기간에 경보 상태를 정상적으로 계속 평가하며, 사용자는 경보 기록을 통해 이 정보를 볼 수 있습니다. 음소거 기간이 종료되면 대상 경보가 경보 상태(OK/ALARM/INSUFFICIENT\$1DATA)로 유지되는 경우 CloudWatch는 해당 기간에 음소거된 경보 작업을 자동으로 다시 트리거합니다. 그러면 계획된 음소거 기간이 끝날 때 진행 중인 문제에 대해 경보 작업이 실행되어 모니터링 시스템의 무결성을 유지할 수 있습니다. **참고** 경보를 음소거하는 경우: 대상 경보와 연결된 모든 작업이 음소거됨 모든 경보 상태(OK, ALARM 및 INSUFFICIENT\$1DATA)와 연결된 작업이 음소거됨 ## 음소거된 경보 보기 및 관리 음소거된 경보 보기 및 관리에 대한 자세한 내용은 [음소거된 경보 보기 및 관리](viewing-managing-muted-alarms.md) 섹션을 참조하세요. # 경보 음소거 규칙 작동 방식 다음 시나리오에서는 경보 음소거 규칙이 대상 경보에 미치는 영향과 경보 작업이 음소거되거나 실행되는 방법을 보여줍니다. **참고** 경보를 음소거하면 OK, ALARM 및 INSUFFICIENT\$1DATA를 포함한 모든 경보 상태에 연결된 작업이 음소거됩니다. 아래 나온 동작은 모든 경보 상태에 연결된 작업에 적용됩니다. Metrics Insights 경보를 음소거하면 해당 경보에 대한 모든 기고자 지표 시리즈도 자동으로 음소거됩니다. ## 시나리오: 음소거 규칙이 활성화되면 경보 작업이 음소거됨 다음을 고려합니다. + 경보에는 ALARM 상태에 대해 구성된 작업이 있음 + 경보 음소거 규칙이 해당 경보를 대상으로 하는 t1부터 t5까지 활성화되도록 예약됨 ![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-1.png) + **t0**에서 - 경보가 OK 상태이고 음소거 규칙은 SCHEDULED 상태임 + **t1**에서 - 음소거 규칙 상태가 ACTIVE 상태가 됨 + **t2**에서 - 경보가 ALARM 상태로 전환되고 음소거 규칙에 의해 경보가 효과적으로 음소거되므로 작업이 음소거됨 + **t4**에서 - 음소거 규칙이 여전히 활성 상태인 동안 경보가 OK 상태로 돌아감 + **t5**에서 - 음소거 규칙이 비활성화되지만 경보가 이제 OK 상태이므로 ALARM 작업이 실행되지 않음 ## 시나리오: 음소거 규칙이 활성 상태일 때 음소거되고 음소거 기간 이후 다시 트리거되는 경보 작업 다음을 고려합니다. + 경보에는 ALARM 상태에 대해 구성된 작업이 있음 + 경보 음소거 규칙이 해당 경보를 대상으로 하는 t1부터 t5까지 활성화되도록 예약됨 ![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-2.png) + **t0**에서 - 경보가 OK 상태이고 음소거 규칙은 SCHEDULED 상태임 + **t1**에서 - 음소거 규칙 상태가 ACTIVE 상태가 됨 + **t2**에서 - 경보가 ALARM 상태로 전환되고 음소거 규칙에 의해 경보가 효과적으로 음소거되므로 작업이 음소거됨 + **t4**에서 - 음소거 기간이 비활성화되고 경보가 여전히 ALARM 상태임 + **t5**에서 - 음소거 기간이 종료되고 경보가 원래 음소거되는 동일한 상태(ALARM)로 유지되므로 경보 작업이 실행됨 ## 시나리오: 여러 중첩 경보 음소거 규칙 다음을 고려합니다. + 경보에는 ALARM 상태에 대해 구성된 작업이 있음 2개의 음소거 규칙이 있다고 간주합니다. + 경보 음소거 규칙 1 - t1에서 t5까지 경보 음소거 + 경보 음소거 규칙 2 - t3에서 t9까지 경보 음소거 ![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-3.png) + **t0**에서 - 경보가 OK 상태이고 두 음소거 규칙 모두 SCHEDULED 상태임 + **t1**에서 - 첫 번째 음소거 규칙이 ACTIVE 상태가 됨 + **t2**에서 - 경보가 ALARM 상태로 전환되고 작업이 음소거됨 + **t3**에서 - 두 번째 음소거 규칙이 ACTIVE 상태가 됨 + **t5**에서 - 첫 번째 음소거 규칙이 비활성화되지만 두 번째 음소거 규칙이 여전히 활성 상태이므로 경보 작업은 음소거 상태로 유지됨 + **t8**에서 - 두 번째 음소거 기간이 종료되고 경보가 원래 음소거되는 동일한 상태(ALARM)로 유지되므로 경보 작업이 실행됨 ## 시나리오: 음소거 규칙 업데이트로 음소거 기간이 종료되면 음소거 경보 작업이 실행됨 다음을 고려합니다. + 경보에는 ALARM 상태에 대해 구성된 작업이 있음 + 경보 음소거 규칙이 해당 경보를 대상으로 하는 t1부터 t8까지 활성화되도록 예약됨 ![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-4.png) + **t0**에서 - 경보가 OK 상태이고 음소거 규칙은 SCHEDULED 상태임 + **t1**에서 - 음소거 규칙이 ACTIVE 상태가 됨 + **t2**에서 - 경보가 ALARM 상태로 전환되고 작업이 음소거됨 + **t6**에서 - 음소거 규칙 구성이 업데이트되어 기간이 t6에 끝납니다. 음소거 규칙이 더 이상 활성화되지 않으므로 경보 작업은 t6에서 즉시 실행됩니다. **참고** 동일한 동작이 적용됩니다. 음소거 규칙이 t6에서 삭제되는 경우 음소거 규칙을 삭제하면 즉시 경보를 음소거 해제합니다. 경보가 음소거 규칙 대상(t6에서)으로부터 제거되면 경보가 즉시 음소거 해제됩니다. ## 시나리오: 음소거 기간에 경보 작업이 업데이트되면 새 작업이 실행됨 다음을 고려합니다. + 경보에는 ALARM 상태에 대해 구성된 작업이 있음 + 경보 음소거 규칙이 해당 경보를 대상으로 하는 t1부터 t8까지 활성화되도록 예약됨 ![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/images/alarm_mute_rules_scenario-5.png) + **t0**에서 - 경보가 OK 상태이고 음소거 규칙은 SCHEDULED 상태입니다. SNS 작업은 경보 상태 ALARM으로 구성됩니다. + **t1**에서 - 음소거 규칙이 ACTIVE 상태가 됨 + **t2**에서 - 경보가 ALARM 상태로 전환되고 구성된 SNS 작업이 음소거됨 + **t6**에서 - SNS 작업을 제거하고 Lambda 작업을 추가하도록 경보 구성이 업데이트됨 + **t8**에서 - 음소거 기간이 종료되고 경보가 원래 음소거되는 동일한 상태(ALARM)로 유지되므로 경보에 구성된 Lambda 작업이 실행됨 **참고** 음소거 기간(위 예제의 경우 t6에서)에 모든 경보 작업이 제거되면 음소거 기간 종료 시(위 예제의 경우 t8에서) 작업이 실행되지 않음 ## 일반적인 사용 사례에 대한 일정 예제 다음 예제에서는 일반적인 사용 사례에서 기간 표현식 구성 방법을 보여줍니다. **시나리오 1: 예약된 유지 관리 기간에 경보 작업 음소거** - 서비스가 의도적으로 사용 불가능한 상태이거나 성능이 저하된 모드에서 작동하는 경우 시스템 또는 데이터베이스 업데이트와 같이 예측 가능한 일정에 따라 수행되는 정기 유지 관리 활동. + 기간이 `PT4H`인 Cron 표현식 `0 2 * * SUN` - 주간 시스템 유지 관리를 위해 매주 일요일 오전 2시부터 오전 6시까지 경보를 음소거합니다. + 기간이 `PT6H`인 Cron 표현식 `0 1 1 * *` - 월간 데이터베이스 유지 관리를 위해 매월 1일 오전 1시부터 오전 7시까지 경보를 음소거합니다. **시나리오 2: 업무 외 시간에 중요하지 않은 경보 음소거** - 즉각적인 주의가 필요하지 않은 주말 또는 휴일에 알림 피로를 줄입니다. + 기간이 `P2DT12H`인 Cron 표현식 `0 18 * * FRI` - 매주 주말 금요일 오후 6시부터 월요일 오전 6시까지 경보를 음소거합니다. **시나리오 3: 일일 백업 작업 중 성능 경보 음소거** - 리소스 사용률을 일시적으로 높이고 예측 가능한 기간에 성능 관련 경보를 트리거할 수 있는 일일 자동 백업 프로세스. + 기간이 `PT2H`인 Cron 표현식 `0 23 * * *` - 디스크 I/O 및 CPU 사용률을 일시적으로 높이는 야간 백업 작업 중에 매일 오후 11시부터 오전 1시까지 경보를 음소거합니다. **시나리오 4: 활성 문제 해결 세션 중에 중복 경보 음소거** - 팀이 문제를 적극적으로 조사하고 해결하는 동안 경보 작업을 일시적으로 음소거하여 알림 노이즈를 방지하고 문제 해결을 집중할 수 있게 합니다. + 기간이 `PT4H`인 표현식 `at(2024-05-10T14:00)`에서 - 활성 인시던트 대응 세션 중에 2024년 5월 10일 오후 2시부터 오후 6시까지 경보를 음소거합니다. **시나리오 5: 계획된 회사 운영 차단 중 경보 작업 음소거** - 모든 시스템이 의도적으로 장기간 오프라인 상태가 되는 일회성의 연장된 유지 관리 기간 또는 회사 전체의 운영 차단. + 기간이 `P7D`인 표현식 `at(2024-12-23T00:00)`에서 - 연례 회사 운영 차단 중 2024년 12월 23일\$129일의 전체 주간에 경보를 음소거합니다. # Limits ## 일반적인 CloudWatch 할당량 경보에 적용되는 일반적인 CloudWatch 서비스 할당량에 대한 자세한 내용은 [CloudWatch 서비스 할당량](cloudwatch_limits.md) 섹션을 참조하세요. ## Metrics Insights 쿼리를 기반으로 경보에 적용되는 제한 CloudWatch Metrics Insights 경보를 사용하는 경우 다음과 같은 기능적 제한에 유의합니다. + 리전별 계정당 Metrics Insights 쿼리를 사용하는 기본 경보 200개 + 경보 상태를 평가하는 데 최근 3시간의 데이터만 사용할 수 있습니다. 그러나 경보 세부 정보 페이지 그래프에서는 최대 2주의 데이터를 시각화할 수 있습니다. + 여러 시계열을 평가하는 경보는 ALARM 상태의 기고자 수를 100개로 제한합니다. + 쿼리가 150개의 시계열을 검색한다고 가정하는 경우: + ALARM 상태의 기고자가 100개 미만인 경우(예: 95) `StateReason`은 '150개 시계열 중 95개가 ALARM으로 평가됨'이 됩니다. + 예를 들어 ALARM 상태의 기고자가 100개를 초과하는 경우(예: 105) `StateReason`은 '100개 이상의 시계열이 ALARM으로 평가됨'이 됩니다. + 또한 속성 볼륨이 너무 크면 ALARM의 기고자 수를 100개 미만으로 제한할 수 있습니다. + 분석되거나 반환된 최대 시계열 수에 대한 Metrics Insights 제한 + 경보 평가 중에 `EvaluationState`는 다음 제한에 대해 `PARTIAL_DATA`로 설정됩니다. + Metrics Insights 쿼리가 500개가 넘는 시계열을 반환하는 경우. + Metrics Insights 쿼리가 10,000개가 넘는 지표와 일치하는 경우. CloudWatch 서비스 할당량 및 제한에 대한 자세한 내용은 [CloudWatch Metrics Insights 서비스 할당량](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-limits.html)을 참조하세요. ## PromQL 쿼리를 기반으로 경보에 적용되는 제한 CloudWatch PromQL 경보를 사용하는 경우 유의해야 할 기능적 제한: + 여러 시계열을 평가하는 경보는 ALARM 상태의 기고자 수를 100개로 제한합니다. + ALARM 상태의 기고자가 100개 미만인 경우(예: 95) `StateReason`은 '95개 시계열이 ALARM으로 평가됨'이 됩니다. + 예를 들어 ALARM 상태의 기고자가 100개를 초과하는 경우(예: 105) `StateReason`은 '100개 이상의 시계열이 ALARM으로 평가됨'이 됩니다. + 또한 속성 볼륨이 너무 크면 ALARM의 기고자 수를 100개 미만으로 제한할 수 있습니다. + 분석되거나 반환된 최대 시계열 수에 대한 PromQL 제한 + 경보 평가 중에 PromQL 쿼리가 500개를 초과하는 시계열을 반환하면 `EvaluationState`가 `PARTIAL_DATA`로 설정됩니다. ## 연결된 데이터 소스를 기반으로 경보에 적용되는 제한 + CloudWatch는 경보를 평가할 때 경보 기간이 1분 이상이더라도 1분마다 평가를 수행합니다. 경보가 작동하려면 Lambda 함수가 기간 길이의 배수뿐만 아니라 임의의 분에 시작하는 타임스탬프 목록을 반환할 수 있어야 합니다. 이러한 타임스탬프는 한 기간 길이 간격으로 떨어져 있어야 합니다. 따라서 Lambda에서 쿼리한 데이터 소스가 기간 길이의 배수인 타임스탬프만 반환할 수 있는 경우 함수는 `GetMetricData` 요청에서 예상하는 타임스탬프와 일치하도록 가져온 데이터를 '다시 샘플링'해야 합니다. 예를 들어, 기간이 5분인 경보는 매번 1분씩 이동하는 5분 기간을 사용하여 1분마다 평가됩니다. 이 경우 + 12:15:00의 경보 평가에 대해 CloudWatch는 타임스탬프가 `12:00:00`, `12:05:00` 및 `12:10:00`인 데이터 포인트를 예상합니다. + 그런 다음 12:16:00의 경보 평가에 대해 CloudWatch는 타임스탬프가 `12:01:00`, `12:06:00` 및 `12:11:00`인 데이터 포인트를 예상합니다. + CloudWatch가 경보를 평가할 때 Lambda 함수에서 반환한 데이터 포인트 중 예상 타임스탬프와 일치하지 않는 모든 데이터 포인트는 삭제되고 나머지 예상 데이터 포인트를 사용하여 경보가 평가됩니다. 예를 들어, 경보가 `12:15:00`에 평가되면 CloudWatch는 타임스탬프가 `12:00:00`, `12:05:00` 및 `12:10:00`인 데이터를 예상합니다. 타임스탬프가 `12:00:00`, `12:05:00`, `12:06:00` 및 `12:10:00`인 데이터를 수신하면 `12:06:00`의 데이터가 삭제되고 CloudWatch는 다른 타임스탬프를 사용하여 경보를 평가합니다. 그런 다음 `12:16:00`의 다음 평가에 대해 CloudWatch는 타임스탬프가 `12:01:00`, `12:06:00` 및 `12:11:00`인 데이터를 예상합니다. 타임스탬프가 `12:00:00`, `12:05:00` 및 `12:10:00`인 데이터만 있는 경우 12:16:00에 이러한 데이터 포인트가 모두 무시되고 누락된 데이터를 처리하기 위해 경보를 지정한 방법에 따라 알람이 해당 상태로 전환됩니다. 자세한 내용은 [경보 평가](alarm-evaluation.md) 섹션을 참조하세요. + `INSUFFICIENT_DATA` 상태로 전환될 때 조치를 취하도록 이러한 경보를 생성하는 것이 좋습니다. 여러 Lambda 함수 실패 사용 사례에서는 누락된 데이터를 처리하기 위해 경보를 설정한 방식에 관계없이 경보가 `INSUFFICIENT_DATA`로 전환되기 때문입니다. + Lambda 함수가 오류를 반환하는 경우: + Lambda 함수를 호출하는 데 권한 문제가 있는 경우, 생성 시 누락된 데이터를 처리하도록 경보를 지정한 방법에 따라 경보에서 누락된 데이터 전환이 발생하기 시작합니다. + Lambda 함수에서 발생하는 다른 오류로 인해 경보가 `INSUFFICIENT_DATA`로 전환됩니다. + Lambda 함수에서 요청한 지표에 약간의 지연이 발생하여 마지막 데이터 포인트가 항상 누락되는 경우 해결 방법을 사용해야 합니다. N개 중 M개의 경보를 생성하거나 경보 평가 기간을 늘릴 수 있습니다. M개 중 N개의 경보에 대한 자세한 내용은 [경보 평가](alarm-evaluation.md) 섹션을 참조하세요.