이 문서에서는 정렬 기간과 재테스트 기간에 따라 조건이 충족되는 시기를 결정하고 알림 정책으로 여러 조건을 조합하는 방법, 알림 정책으로 누락된 데이터 포인트를 대체하는 방법을 설명합니다. 또한 정책의 미해결 이슈 최대 개수, 이슈별 알림 수, 알림 지연을 일으킨 원인에 대해서도 설명합니다.
이 콘텐츠는 로그 기준 알림 정책에 적용되지 않습니다. 로그 기준 알림 정책에 대한 자세한 내용은 로그 모니터링을 참조하세요.
정렬 기간 및 재테스트 기간
Cloud Monitoring은 알림 정책 조건이 충족되었는지 여부를 확인할 때 정렬 기간과 재테스트 기간을 평가합니다.
정렬 기간
알림 정책에서 시계열 데이터를 모니터링하기 전에 평가할 데이터가 정기적으로 알림 정책에 배치되도록 알림 정책을 정규화해야 합니다. 정규화 프로세스를 정렬이라고 합니다.
정렬에는 다음 두 단계가 포함됩니다.
시계열을 데이터 버케팅이라고 하는 일반 시간 간격으로 나눕니다. 간격은 정렬 기간입니다.
정렬 기간의 포인트에 대한 단일 값을 계산합니다. 단일 포인트 계산 방법, 즉 모든 값을 합산할지, 평균을 계산할지 또는 최댓값을 사용할지를 선택합니다. 데이터 포인트를 결합하는 함수를 정렬기라고 합니다. 조합 결과를 정렬된 값이라고 합니다.
정렬에 대한 자세한 내용은 정렬: 계열 내 정규화를 참조하세요.
예를 들어 정렬 기간이 5분인 경우, 오후 1시에 정렬 기간에는 오후 12시 55분부터 1시 사이에 수신된 샘플이 포함됩니다. 오후 1:01에는 정렬 기간이 1분 이동하여 오후 12:56 ~ 오후 1:01 사이에 수신된 샘플이 포함됩니다.
Monitoring은 정렬 기간을 다음과 같이 구성합니다.
Google Cloud 콘솔
알림 조건 페이지에서 다음 필드의 값을 선택하여 정렬 기간을 구성합니다.
- 순환 기간: 평가할 시간 범위를 지정합니다.
- 순환 기간 함수: 데이터 포인트 기간에서 수행할 수학 함수를 지정합니다.
사용 가능한 함수에 대한 자세한 내용은 API 참조의 Aligner를 참조하세요. 일부 정렬기 함수는 데이터를 정렬하고 다른 측정항목 종류 또는 유형으로 변환합니다. 자세한 내용은 종류, 유형, 전환을 참조하세요.
API
MetricThreshold 및 MetricAbsence 구조에서 aggregations.alignmentPeriod 및 aggregations.perSeriesAligner 필드를 설정하여 정렬 기간을 구성합니다.
사용 가능한 함수에 대한 자세한 내용은 API 참조의 Aligner를 참조하세요. 일부 정렬기 함수는 데이터를 정렬하고 다른 측정항목 종류 또는 유형으로 변환합니다. 자세한 내용은 종류, 유형, 전환을 참조하세요.
알림 정책의 조건에 대한 정렬 기간의 효과를 설명하기 위해 샘플링 기간이 1분인 측정항목을 모니터링하는 측정항목 기준점 조건을 상정해 보겠습니다. 정렬 기간이 5분으로 설정되어 있고 정렬기가 sum으로 설정되었다고 가정합니다. 또한 시계열의 정렬된 값이 최소 3분 동안 2보다 크고 조건이 1분마다 평가될 경우 조건이 충족된다고 가정합니다.
이 예시에서 정렬 기간은 2분이고 다음 섹션에서 설명하는 재테스트 기간은 3분입니다.
다음 그림은 조건의 순차적 평가를 보여줍니다.
그림의 각 행은 조건에 대한 단일 평가를 보여줍니다. 시계열 데이터가 표시되었습니다. 정렬 기간의 점은 파란색 점으로 표시되며 더 이전의 점은 검은색입니다. 각 행에는 정렬된 값과 이 값이 기준점 2을 초과하는지 여부가 표시됩니다. start 라벨이 지정된 행의 경우 정렬된 값은 기준점보다 작은 1로 계산됩니다.
다음 평가에서 정렬 기간의 샘플 합계는 2입니다.
세 번째 평가에서 합계는 3이며 이 값은 임곗값보다 크므로 재테스트 기간 타이머가 시작됩니다.
재테스트 기간
알림 정책의 조건에는 재테스트 기간이 있어 단일 측정이나 예측으로 인해 조건이 충족되지 않을 수 있습니다. 예를 들어 조건의 재테스트 기간이 15로 설정되었다고 가정해 보겠습니다. 다음에서는 유형에 따른 조건의 동작을 설명합니다.
- 측정항목 기준점 조건은 단일 시계열의 경우 15분 간격으로 정렬된 모든 측정이 기준점을 위반할 때 충족됩니다.
- 측정항목 부재 조건은 시계열 데이터가 15분 간격으로 도착하지 않을 때 충족됩니다.
- 예측 조건은 15분 동안 생성된 모든 예측이 시계열이 예측 기간 내의 기준점을 위반할 것이라고 예측할 때 충족됩니다.
조건이 하나 있는 정책의 경우 이슈가 열리고 조건이 충족되면 알림이 전송됩니다. 이러한 이슈는 조건이 계속 충족되는 동안 미해결 상태로 유지됩니다.
Google Cloud 콘솔
알림 트리거 구성 단계에서 재테스트 기간 필드를 사용하여 재테스트 기간을 구성합니다.
API
MetricThreshold 및 MetricAbsence 구조에서 duration 필드를 설정하여 재테스트 기간을 구성합니다.
앞의 그림에서는 측정항목 기준점 조건에 대한 3가지 평가를 보여주었습니다. start + 2 minutes 시점에서 정렬된 값이 임곗값보다 크지만 재테스트 기간이 3분으로 설정되어 있으므로 조건이 충족되지 않습니다. 다음 그림은 조건의 다음 평가에 대한 결과를 보여줍니다.
start + 2 minutes 시점에 정렬된 값이 기준점을 초과하더라도 정렬된 값이 3분 동안 임곗값을 초과할 때까지는 조건이 충족되지 않습니다. 이 이벤트는 start + 5 minutes 시점에 발생합니다.
조건은 측정이나 예측이 조건을 충족하지 않을 때마다 재테스트 기간을 재설정합니다. 이 동작은 다음 예시에서 설명합니다.
예시: 이 알림 정책에는 5분 재테스트 기간을 지정하는 측정항목 기준점 조건 하나가 포함되어 있습니다.
HTTP 응답 지연 시간이 2초를 초과하고
지연 시간이 기준점 5분을 초과하는 경우
이슈를 시작하고 지원팀에 이메일을 전송합니다.다음 시퀀스에서는 재테스트 기간이 조건 평가에 미치는 영향을 보여줍니다.
- HTTP 지연 시간이 2초 미만입니다.
- 그 다음 3분 연속으로 HTTP 지연 시간이 2초 이상입니다.
- 다음 측정에서 지연 시간이 2초 미만이므로 조건에서 재테스트 기간을 재설정합니다.
다음 5분 연속으로 HTTP 지연 시간이 2초를 초과하면 조건이 충족됩니다.
알림 정책에는 조건이 하나 있으므로 조건이 충족되면 Monitoring에서 알림을 전송합니다.
재테스트 기간을 거짓양성이 최소화되도록 충분히 길게 설정하되, 이슈가 적절한 시기에 열릴 수 있도록 충분히 짧게 설정합니다.
정렬 기간 및 재테스트 기간 설정 권장사항
정렬 기간은 정렬기와 결합되는 샘플 수를 결정합니다.
측정항목 유형에 대한 정렬 기간의 최솟값은 해당 측정항목 유형의 샘플링 기간입니다. 예를 들어 측정항목 유형이 300초마다 샘플링될 경우 정렬 기간은 최소 300초 이상이어야 합니다. 그러나 5개 샘플을 조합하려면 정렬 기간을 5 * 300초 즉, 1,500초로 설정합니다.
정렬 기간의 최댓값은 24시간에서 측정항목 유형의 처리 지연 시간을 뺀 값입니다. 예를 들어 측정항목의 처리 지연 시간이 6시간이면 정렬 기간의 최댓값은 18시간입니다.
재테스트 기간을 사용하여 알림의 신속한 대응을 지정합니다. 예를 들어 측정항목 부재 조건에서 재테스트 기간을 20분으로 설정하면 조건이 충족되기 전까지 20분 동안 데이터가 없어야 합니다. 응답성이 높은 알림 정책을 위해서는 재테스트 기간을 더 작은 값으로 설정합니다. 측정항목 기준점 조건의 경우 알림 정책이 가장 빠르게 반응하게 하려면 재테스트 기간을 0으로 설정합니다. 단일 정렬된 값으로 인해 이러한 유형의 조건이 충족됩니다.
알림 정책 조건은 고정된 빈도로 평가됩니다. 정렬 기간과 재테스트 기간에 대한 선택항목이 조건 평가 빈도를 결정하지 않습니다.
여러 조건이 포함된 정책
알림 정책에는 최대 6개의 조건이 포함될 수 있습니다.
Cloud Monitoring API를 사용 중이거나 알림 정책에 여러 조건이 있는 경우 이슈가 열려 있는 시점을 지정해야 합니다. 여러 조건이 결합되는 방식을 구성하려면 다음 중 하나를 수행합니다.
Google Cloud 콘솔
다중 조건 트리거 단계에서 결합자 옵션을 구성합니다.
API
AlertPolicy 구조의 combiner 필드를 사용해서 결합자 옵션을 구성합니다.
이 표에서는 Google Cloud 콘솔의 설정, Cloud Monitoring API의 상응 값, 각 설정에 대한 설명을 보여줍니다.
| Google Cloud 콘솔 정책 트리거 값 |
Cloud Monitoring API 컴바이너 값 |
의미 |
|---|---|---|
| 어떤 조건이든 충족할 경우 | OR |
어떤 리소스라도 어느 조건이든 충족되면 이슈가 열립니다. |
| 각 조건의 다른 리소스라도 모든 조건이 충족됨 (기본값) |
AND |
다른 리소스가 조건을 충족하는 경우에도 각 조건이 충족되면 이슈가 열립니다. |
| 모든 조건 충족 | AND_WITH_MATCHING_RESOURCE |
동일한 리소스가 각 조건을 충족할 경우 이슈가 열립니다. 이 설정은 가장 엄격한 조합 선택입니다. |
여기에서 충족이라는 용어는 조건의 구성이 true로 평가되는 것을 의미합니다. 예를 들어 구성이 Any time series is greater than 10 for 5 minutes인 경우 이 문이 true로 평가되면 조건이 충족됩니다.
예시
vm1 및 vm2라는 VM 인스턴스 두 개가 포함된 Google Cloud 프로젝트가 있다고 가정해 보겠습니다. 또한 두 가지 조건이 있는 알림 정책을 만든다고 가정해 보세요.
CPU usage is too high라는 조건은 인스턴스의 CPU 사용량을 모니터링합니다. 이 조건은 인스턴스의 CPU 사용량이 1분 동안 100ms/s를 초과할 때 충족됩니다.Excessive utilization라는 조건은 인스턴스의 CPU 사용률을 모니터링합니다. 이 조건은 인스턴스의 CPU 사용률이 1분 동안 60%를 초과하면 충족됩니다.
처음에는 두 조건이 모두 false로 평가된다고 가정합니다.
다음으로 vm1의 CPU 사용량이 1분 동안 100ms/s를 초과한다고 가정합니다. CPU 사용량이 1분 동안 기준점을 초과하므로 CPU usage is too high 조건이 충족됩니다. 조건이 어떤 조건이든 충족됨과 결합된 경우 조건이 충족되어 이슈가 생성됩니다. 조건이 모든 조건 충족 또는 각 조건의 서로 다른 리소스에 대해 모든 조건 충족됨과 결합된 경우 이슈는 생성되지 않습니다. 이러한 결합자를 선택하려면 두 조건을 모두 충족해야 합니다.
다음으로 vm1의 CPU 사용량이 100ms/s를 초과하고 vm2의 CPU 사용률이 1분 동안 60%를 초과한다고 가정합니다. 결과는 모든 조건이 충족하는 것입니다. 다음은 조건이 결합되는 방식에 따라 어떻게 되는지 설명합니다.
어떤 조건이든 충족됨: 리소스가 조건을 충족할 때 이슈가 생성됩니다. 이 예시에서는 vm2가 조건
Excessive utilization를 충족합니다.또한 vm2로 인해
CPU usage is too high조건이 충족될 경우 이슈가 생성됩니다.CPU usage is too high조건을 충족시키는 vm1 및 vm2가 서로 다른 이벤트이기 때문에 이슈가 생성됩니다.각 조건의 다른 리소스에 대해서도 모든 조건 충족: 두 조건이 모두 충족되므로 이슈가 생성됩니다.
모든 조건 충족: 이 결합자는 동일한 리소스가 모든 조건을 충족해야 하므로 이슈가 생성되지 않습니다. 이 예시에서는 vm1이
CPU usage is too high를 충족하면서 vm2가Excessive utilization를 충족하므로 이슈가 생성되지 않습니다.
부분적인 측정항목 데이터
시계열 데이터 도착이 중지되거나 데이터가 지연될 때 Monitoring에서 데이터를 누락으로 분류합니다. 데이터가 누락되면 이슈가 종료되지 않을 수 있습니다. 타사 클라우드 제공업체에서 전송하는 데이터의 경우 일반적으로 5~15분 지연되며 30분까지도 지연될 수 있습니다. 지연 시간이 재테스트 기간보다 길면 조건이 '알 수 없음' 상태로 전환될 수 있습니다. 데이터가 마침내 도착했을 때는 이미 Monitoring에서 최근의 조건 기록 일부가 손실되었을 수 있습니다. 데이터가 도착한 후에는 지연되었다는 증거가 남지 않으므로 이후 시계열 데이터를 검사해도 이 문제가 드러나지 않을 수 있습니다.
Google Cloud 콘솔
데이터의 도착이 중지될 때 Monitoring에서 측정항목 기준점 조건을 평가하는 방식을 구성할 수 있습니다. 예를 들어 이슈가 미해결이고 예상 측정값이 도착하지 않으면 Monitoring을 통해 이슈를 미해결 상태로 두거나 즉시 종료할까요? 마찬가지로 데이터 도착이 중지되고 미해결 이슈가 없는 경우 이슈를 열까요? 마지막으로, 데이터 도착이 중지된 후 이슈를 얼마나 미해결 상태로 유지할까요?
데이터 도착이 중지될 때 Monitoring에서 측정항목 기준점 조건을 평가하는 방법을 지정하는 구성 가능한 필드가 2개 있습니다.
Monitoring에서 누락된 데이터의 대체 값을 결정하는 방법을 구성하려면 조건 트리거 단계에서 설정한 누락 데이터 평가 필드를 사용합니다. 재테스트 범위가 재테스트 없음으로 설정된 경우 이 필드는 사용 중지됩니다.
재테스트 기간은 Cloud Monitoring API에서 기간이라고 하는 필드입니다.
데이터 수신이 중지된 후 미해결 이슈를 닫기 전에 Monitoring이 기다리는 시간을 구성하려면 이슈 자동 종료 기간 필드를 사용합니다. 자동 종료 기간은 알림 단계에서 설정합니다. 기본 자동 종료 기간은 7일입니다.
다음은 누락된 데이터 필드의 여러 옵션에 대한 설명입니다.
| Google Cloud 콘솔 '누락 데이터 평가' 필드 |
요약 | 세부정보 |
|---|---|---|
| 누락 데이터 비어 있음 | 미해결 이슈가 미해결 상태로 유지됩니다. 새 이슈가 열리지 않습니다. |
충족된 조건의 경우 데이터 수신이 중지될 때 조건이 계속 충족됩니다. 이 조건에 대해 이슈가 열려 있으면 이슈가 미해결 상태로 유지됩니다. 이슈가 미해결 상태이고 데이터가 수신되지 않으면 최소 15분의 지연 시간 이후에 자동 종료 타이머가 시작됩니다. 타이머가 만료되면 이슈가 종료됩니다. 충족되지 않은 조건의 경우 데이터 수신이 중지할 때 조건이 계속 충족되지 않습니다. |
| 정책 조건을 위반하는 값으로 취급되는 누락된 데이터 포인트 | 미해결 이슈가 미해결 상태로 유지됩니다. 새 이슈를 열 수 있습니다. |
충족된 조건의 경우 데이터 수신이 중지될 때 조건이 계속 충족됩니다. 이 조건에 대해 이슈가 열려 있으면 이슈가 미해결 상태로 유지됩니다. 이슈가 열려 있고 자동 종료 기간과 24시간 내에 데이터가 수신되지 않으면 이슈가 닫힙니다. 충족되지 않는 조건의 경우 이 설정으로 인해 측정항목 기준점 조건이 |
| 정책 조건을 위반하지 않는 값으로 취급되는 누락된 데이터 포인트 | 미해결 이슈가 닫힙니다. 새 이슈가 열리지 않습니다. |
충족된 조건의 경우 데이터 수신이 중지될 때 조건 충족이 중지됩니다. 이 조건에 대해 이슈가 열려 있으면 이슈가 닫힙니다. 충족되지 않은 조건의 경우 데이터 수신이 중지할 때 조건이 계속 충족되지 않습니다. |
API
데이터의 도착이 중지될 때 Monitoring에서 측정항목 기준점 조건을 평가하는 방식을 구성할 수 있습니다. 예를 들어 이슈가 미해결이고 예상 측정값이 도착하지 않으면 Monitoring을 통해 이슈를 미해결 상태로 두거나 즉시 종료할까요? 마찬가지로 데이터 도착이 중지되고 미해결 이슈가 없는 경우 이슈를 열까요? 마지막으로, 데이터 도착이 중지된 후 이슈를 얼마나 미해결 상태로 유지할까요?
데이터 도착이 중지될 때 Monitoring에서 측정항목 기준점 조건을 평가하는 방법을 지정하는 구성 가능한 필드가 2개 있습니다.
Monitoring에서 누락된 데이터의 대체 값을 결정하는 방법을 구성하려면
MetricThreshold구조의evaluationMissingData필드를 사용합니다.duration필드가 0이면 이 필드가 무시됩니다.데이터 수신이 중지된 후 미해결 이슈를 닫기 전에 Monitoring이 기다리는 시간을 구성하려면
AlertStrategy구조의autoClose필드를 사용합니다.
다음은 누락된 데이터 필드의 여러 옵션에 대한 설명입니다.
APIevaluationMissingData 필드 |
요약 | 세부정보 |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
미해결 이슈가 미해결 상태로 유지됩니다. 새 이슈가 열리지 않습니다. |
충족된 조건의 경우 데이터 수신이 중지될 때 조건이 계속 충족됩니다. 이 조건에 대해 이슈가 열려 있으면 이슈가 미해결 상태로 유지됩니다. 이슈가 미해결 상태이고 데이터가 수신되지 않으면 최소 15분의 지연 시간 이후에 자동 종료 타이머가 시작됩니다. 타이머가 만료되면 이슈가 종료됩니다. 충족되지 않은 조건의 경우 데이터 수신이 중지할 때 조건이 계속 충족되지 않습니다. |
EVALUATION_MISSING_DATA_ACTIVE |
미해결 이슈가 미해결 상태로 유지됩니다. 새 이슈를 열 수 있습니다. |
충족된 조건의 경우 데이터 수신이 중지될 때 조건이 계속 충족됩니다. 이 조건에 대해 이슈가 열려 있으면 이슈가 미해결 상태로 유지됩니다. 이슈가 열려 있고 자동 종료 기간과 24시간 내에 데이터가 수신되지 않으면 이슈가 닫힙니다. 충족되지 않는 조건의 경우 이 설정으로 인해 측정항목 기준점 조건이 |
EVALUATION_MISSING_DATA_INACTIVE |
미해결 이슈가 닫힙니다. 새 이슈가 열리지 않습니다. |
충족된 조건의 경우 데이터 수신이 중지될 때 조건 충족이 중지됩니다. 이 조건에 대해 이슈가 열려 있으면 이슈가 닫힙니다. 충족되지 않은 조건의 경우 데이터 수신이 중지할 때 조건이 계속 충족되지 않습니다. |
다음을 수행하여 누락된 데이터로 인한 문제를 최소화할 수 있습니다.
- 타사 클라우드 제공업체에 측정항목 수집 지연 시간을 줄일 방법이 있는지 문의합니다.
- 조건의 재테스트 기간을 늘립니다. 재테스트 기간이 길면 알림 정책의 응답성이 저하된다는 단점이 있습니다.
수집 지연이 적은 측정항목을 선택합니다.
- 특히 에이전트가 타사 클라우드의 VM 인스턴스에서 실행되는 Monitoring 에이전트 측정항목
- 사용자가 Monitoring에 데이터를 직접 작성하는 커스텀 측정항목
- 로그 항목 수집이 지연되지 않는 경우 로그 기반 측정항목
자세한 내용은 Monitoring 에이전트 개요, 사용자 정의 측정항목 개요, 로그 기반 측정항목을 참조하세요.
Monitoring이 알림을 전송하고 이슈를 만드는 경우
Cloud Monitoring은 시계열로 인해 조건이 충족되면 알림을 전송합니다. 모든 알림 채널로 알림이 전송됩니다. 특정 채널 또는 정책 채널의 하위 집합으로 알림을 제한할 수 없습니다.
반복 알림을 구성하면 동일한 알림이 알림 정책에 대한 특정 알림 채널로 다시 전송됩니다.
다음 중 하나라도 해당하는 경우 하나의 알림 정책과 관련된 여러 개의 고유한 알림을 받을 수 있습니다.
조건이 여러 시계열을 모니터링하고 있습니다.
정책에 여러 조건이 포함됩니다. 이 경우 수신하는 알림은 알림 정책의 다중 조건 트리거 값에 따라 다릅니다.
모든 조건이 충족됨: 모든 조건이 충족되면 정책은 조건이 충족되는 각 시계열에 대해 알림 정책을 전송하고 이슈를 생성합니다.
이슈를 하나만 만들고 알림 정책에 여러 조건이 포함된 경우 알림을 하나만 보내도록 Cloud Monitoring을 구성할 수 없습니다.
어떤 조건이든 충족됨: 시계열로 인해 조건이 충족되면 알림 정책이 알림을 전송합니다.
자세한 내용은 여러 조건이 포함된 정책을 참조하세요.
Cloud Monitoring API를 사용하여 생성된 알림 정책은 조건이 충족되고 조건 충족이 중지되는 순간에 알림을 표시합니다. Google Cloud 콘솔을 사용하여 만든 알림 정책은 해당 동작을 사용 설정하지 않는 한 조건이 충족되지 않을 때 알림을 전송하지 않습니다.
Monitoring에서 알림을 보내거나 이슈를 만들지 않는 경우
다음과 같은 상황에서는 Monitoring이 알림 정책의 조건이 충족될 때 이슈를 만들거나 알림을 전송하지 않습니다.
- 알림 정책이 사용 중지되었습니다.
- 알림 정책이 일시 중지되었습니다.
- Monitoring이 최대 미해결 이슈 수 한도에 도달했습니다.
사용 중지된 알림 정책
Monitoring은 사용 중지된 알림 정책에 대해 이슈를 만들거나 알림을 전송하지 않습니다. 하지만 Monitoring은 사용 중지된 알림 정책의 조건을 계속 평가합니다.
중지된 정책을 사용 설정하면 Monitoring에서 최근 재테스트 기간 동안 모든 조건 값을 평가합니다. 최근 재테스트 기간에는 정책이 사용 설정되기 이전, 중간, 이후에 사용된 데이터가 포함될 수 있습니다. 중지된 정책의 조건은 재테스트 기간이 길더라도 정책을 재개한 직후에 충족될 수 있습니다.
예를 들어 특정 프로세스를 모니터링하는 알림 정책이 있고 이 정책을 사용 중지한다고 가정해보세요. 그러면 다음 주 이 프로세스가 작동 중지하고, 알림 정책이 사용 중지되었기 때문에 알림이 표시되지 않습니다. 프로세스를 재개하는 즉시 알림 정책을 사용 설정하면 Monitoring은 지난 5분 동안 프로세스가 가동되지 않았다고 인식되어 이슈가 열립니다.
사용 중지된 알림 정책과 관련된 이슈는 정책의 자동 종료 기간이 만료될 때까지 미해결 상태로 유지됩니다.
일시 중지된 알림 정책
Monitoring은 일시 중지된 알림 정책에 대해 알림을 보내거나 이슈를 만들지 않습니다. 짧은 간격 동안만 알림 정책이 알림을 전송하지 못하도록 하려면 알림 정책을 일시중지하는 것이 좋습니다. 예를 들어 가상 머신(VM)에 대해 유지보수를 수행하기 전에 일시중지를 만들고 인스턴스를 모니터링하는 알림 정책을 일시중지 기준에 추가할 수 있습니다.
알림 정책을 일시중지하면 Monitoring이 해당 정책과 관련된 미해결 이슈를 모두 닫습니다. Monitoring은 일시중지가 만료된 후 새 이슈를 열 수 있습니다. 자세한 내용은 알림 일시중지를 참조하세요.
알림 및 미해결 이슈의 제한
알림 정책은 여러 리소스에 적용될 수 있으며, 모든 리소스에 영향을 주는 문제로 인해 정책이 유발되고 각 리소스의 이슈가 열릴 수 있습니다. 조건을 충족하는 각 시계열마다 이슈가 열립니다.
시스템에 과부하가 걸리지 않도록 단일 정책이 동시에 열 수 있는 이슈 수는 1,000개로 제한됩니다.
예를 들어 2,000개의 Compute Engine 인스턴스에 적용되는 정책이 있고 각 인스턴스에서 알림 조건이 충족된다고 가정해보세요. Monitoring은 미해결 이슈 수를 1,000개로 제한합니다. 미해결 이슈 중 일부가 종료될 때까지 충족된 나머지 조건은 무시됩니다.
이러한 제한으로 인해 단일 알림 채널이 한 번에 알림을 1,000개까지 수신할 수 있습니다. 알림 정책에 알림 채널이 여러 개 있는 경우 이 제한은 각 알림 채널에 독립적으로 적용됩니다.
지연 시간
지연 시간이란 Monitoring에서 측정항목을 샘플링한 후 측정항목 데이터 포인트가 시계열 데이터로 표시될 때까지의 지연을 의미합니다. 지연 시간은 알림 전송 시점에 영향을 줍니다. 예를 들어 모니터링되는 측정항목의 지연 시간이 최대 180초인 경우 Monitoring은 알림 정책 조건이 true로 평가된 후 최대 180초 동안 이슈를 생성하지 않습니다. 자세한 내용은 측정항목 데이터의 지연 시간을 참조하세요.
다음 이벤트와 설정이 지연 시간에 영향을 미칩니다.
측정항목 수집 지연: Monitoring에서 측정항목 값을 수집해야 하는 시간입니다. Google Cloud 값의 경우 대부분의 측정항목은 수집 후 60초 동안 표시되지 않습니다. 하지만 지연 시간은 측정항목에 따라 달라집니다. 알림 정책 계산에 따라 60~90초까지 추가로 시간이 지연될 수 있습니다. AWS CloudWatch 측정항목의 경우 몇 분까지 표시가 지연될 수 있습니다. 업타임 체크의 경우 지연 시간은 평균 기간은 2분입니다(재테스트 기간 종료 시점부터).
재테스트 기간: 조건에 구성된 기간입니다. 조건은 전체 재테스트 기간 동안 조건이 true인 경우에만 충족됩니다. 예를 들어 재테스트 기간을 5분으로 설정하면 알림은 이벤트가 처음 발생한 시점으로부터 최소 5분 이상 지연됩니다.
알림 도착 시간: 이메일 및 SMS 등의 알림 채널 자체적으로 네트워크 또는 기타 지연 시간이 발생할 수 있으며(전송 항목과 무관) 경우에 따라 수 분이 지연됩니다. SMS 및 Slack 등의 일부 채널에서는 메일이 전송된다는 보장도 없습니다.
다음 단계
알림 정책을 만드는 방법은 다음 문서를 참조하세요.
다양한 알림 정책 종류는 샘플 정책을 참조하세요.