이 문서에서는 정렬 기간 및 기간 설정에 따라 조건이 충족되는 시기를 결정하고, 알림 정책으로 여러 조건을 조합하는 방법, 알림 정책으로 누락된 데이터 포인트를 대체하는 방법을 설명합니다. 또한 정책의 미해결 이슈 최대 개수, 이슈별 알림 수, 알림 지연을 일으킨 원인에 대해서도 설명합니다.
이 콘텐츠는 로그 기준 알림 정책에 적용되지 않습니다. 로그 기준 알림 정책에 대한 자세한 내용은 로그 모니터링을 참조하세요.
정렬 기간 및 기간 설정
정렬 기간 및 기간은 알림 정책 조건을 지정할 때 설정한 두 필드입니다. 이 섹션에서는 이러한 필드의 의미를 간략하게 설명합니다.
정렬 기간
정렬 기간은 특정 시점에서 되돌아보는 시간 간격입니다. 정렬기(aligner)는 시점을 되돌아보는 시간 간격에 조합하여 정렬된 값으로 만드는 함수입니다. 예를 들어 정렬 기간이 5분인 경우, 오후 1시에 정렬 기간에는 오후 12시 55분부터 1시 사이에 수신된 샘플이 포함됩니다. 오후 1:01에는 정렬 기간이 1분 이동하여 오후 12:56 ~ 오후 1:01 사이에 수신된 샘플이 포함됩니다.
Google Cloud 콘솔
새 조건 대화상자에 포함되는 순환 범위 및 순환 범위 함수 메뉴를 사용하여 정렬 필드를 구성합니다.
사용 가능한 함수에 대한 자세한 내용은 API 참조의 Aligner를 참조하세요. 일부 정렬기 함수는 데이터를 정렬하고 다른 측정항목 종류 또는 유형으로 변환합니다. 자세한 내용은 종류, 유형, 전환을 참조하세요.
API
MetricThreshold 및 MetricAbsence 구조에서 aggregations.alignmentPeriod 및 aggregations.perSeriesAligner 필드를 설정하여 정렬 필드를 구성합니다.
사용 가능한 함수에 대한 자세한 내용은 API 참조의 Aligner를 참조하세요. 일부 정렬기 함수는 데이터를 정렬하고 다른 측정항목 종류 또는 유형으로 변환합니다. 자세한 내용은 종류, 유형, 전환을 참조하세요.
알림 정책의 조건에 대한 정렬 기간의 효과를 설명하기 위해 샘플링 기간이 1분인 측정항목을 모니터링하는 측정항목 기준점 조건을 상정해 보겠습니다. 정렬 기간이 5분으로 설정되어 있고 정렬기가 sum으로 설정되었다고 가정합니다. 또한 시계열의 정렬된 값이 최소 3분 동안 2보다 크고 조건이 1분마다 평가될 경우 조건이 충족된다고 가정합니다.
다음 그림은 조건의 순차적 평가를 보여줍니다.
그림의 각 행은 조건에 대한 단일 평가를 보여줍니다. 시계열 데이터가 표시되었습니다. 정렬 기간의 점은 파란색 점으로 표시되며 더 이전의 점은 검은색입니다. 각 행에는 정렬된 값과 이 값이 기준점 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에서 누락된 데이터의 대체 값을 결정하는 방법을 구성하려면 조건 트리거 단계에서 설정한 누락 데이터 평가 필드를 사용합니다. 재테스트 범위가 재테스트 없음으로 설정된 경우 이 필드는 사용 중지됩니다.
데이터 수신이 중지된 후 미해결 이슈를 닫기 전에 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이 알림 정책에 대해 이슈를 만들고 알림을 전송하지 못하도록 방지하려면 일시중지를 만들고 일시중지 기준에 알림 정책을 포함합니다. 일시중지가 활성화되면 알림 정책이 이슈를 만들거나 알림을 전송하지 않습니다.
정책이 사용 설정되었고 활성 일시중지 기준과 일치하지 않으면 이슈를 만들고 알림을 전송할 수 있습니다. 이 섹션에서는 정책당 미해결 이슈 수에 대한 한도와 동일한 이슈에 대해 여러 알림을 볼 수 있는 경우에 대해 설명합니다.
정책당 미해결 이슈 수
알림 정책은 여러 리소스에 적용될 수 있으며, 모든 리소스에 영향을 주는 문제로 인해 정책이 유발되고 각 리소스의 이슈가 열릴 수 있습니다. 조건을 충족하는 각 시계열마다 이슈가 열립니다.
시스템에 과부하가 걸리지 않도록 단일 정책이 동시에 열 수 있는 이슈 수는 1,000개로 제한됩니다.
예를 들어 2,000개의 Compute Engine 인스턴스에 적용되는 정책이 있고 각 인스턴스에서 알림 조건이 충족된다고 가정해보세요. Monitoring은 미해결 이슈 수를 1,000개로 제한합니다. 미해결 이슈 중 일부가 종료될 때까지 충족된 나머지 조건은 무시됩니다.
정책당 알림 수
기본적으로 시계열로 인해 조건이 충족되면 알림이 전송됩니다. 다음 중 하나라도 해당하는 경우 알림을 여러 개 받을 수 있습니다.
조건이 여러 시계열을 모니터링하고 있습니다.
정책에는 여러 조건이 포함됩니다.
모든 조건이 충족됨: 모든 조건이 충족되면 Monitoring은 조건이 충족되는 각 시계열에 대해 알림을 전송하고 이슈를 생성합니다. 예를 들어 조건이 2개 있고 각 조건이 하나의 시계열을 모니터링하는 정책이 있다고 가정해보세요. 모든 조건이 충족되면 2개의 알림이 수신되고 2개의 이슈가 표시됩니다.
어떤 조건이든 충족됨: 조건이 충족될 때마다 알림 정책에서 알림을 전송합니다. 예를 들어 조건이 2개 있고 각 조건이 하나의 시계열을 모니터링하는 정책이 있다고 가정해보세요. 첫 번째 조건이 충족되었다고 가정해 보겠습니다. 그러면 이슈가 열리고 알림이 전송됩니다. 이후 측정에서 두 번째 조건이 충족될 때 이슈가 아직 열려 있는 경우 다른 알림이 전송됩니다.
Cloud Monitoring API를 사용하여 생성된 알림 정책은 조건이 충족되고 조건 충족이 중지되는 순간에 알림을 표시합니다. 기본적으로 Google Cloud Console을 사용하여 생성된 알림 정책은 이슈가 열릴 때 알림을 표시합니다. 이슈가 닫힐 때는 알림을 표시하지 않습니다. 이슈 종료 시 알림을 사용 설정할 수 있습니다.
사용 중지된 알림 정책의 알림
알림 정책을 사용 중지해도 알림 정책은 해당 조건을 계속 평가합니다. 하지만 이슈가 생성되지 않고 알림도 전송되지 않습니다.
사용 중지된 정책을 사용 설정하면 Monitoring이 최근 기간 범위 동안 모든 조건의 값을 검사합니다. 최근 기간에는 정책이 사용 설정되기 이전, 중간, 이후에 사용된 데이터가 포함될 수 있습니다. 사용 중지된 정책의 조건은 장기간이더라도 정책을 재개한 직후에 충족할 수 있습니다.
예를 들어 특정 프로세스를 모니터링하는 알림 정책이 있고 이 정책을 사용 중지한다고 가정해보세요. 그러면 다음 주 이 프로세스가 작동 중지하고, 알림 정책이 사용 중지되었기 때문에 알림이 표시되지 않습니다. 프로세스를 재개하는 즉시 알림 정책을 사용 설정하면 Monitoring은 지난 5분 동안 프로세스가 가동되지 않았다고 인식되어 이슈가 열립니다.
알림 정책을 사용 중지하면 자동 종료 기간이 만료될 때까지 미해결 이슈가 열린 상태로 유지됩니다. 알림 정책을 일시중지하면 해당 정책과 관련된 모든 미해결 이슈가 종료됩니다. 일시중지가 종료되면 새 이슈가 개설될 수 있습니다. 자세한 내용은 알림 일시중지를 참조하세요.
활성 일시중지 기준과 일치하는 정책에 대한 알림
짧은 간격 동안 알림 정책이 알림을 전송하지 못하도록 방지하려면 알림 정책을 사용 중지하는 대신 일시중지를 만드는 것이 좋습니다. 예를 들어 가상 머신(VM)에 대해 유지보수를 수행하기 전에 일시중지를 만들고 인스턴스를 모니터링하는 알림 정책을 일시중지 기준에 추가할 수 있습니다.
알림 정책 조건이 충족되고 이 정책이 활성 일시중지 기준을 충족하면 이슈가 생성되지 않고 알림이 전송되지 않습니다. 일시중지가 만료되면 알림 정책이 이슈를 만들고 알림을 전송할 수 있습니다.
반복 알림 보내기
미해결 이슈 및 확인된 이슈의 알림 수신자에게 알리려면 반복 알림을 설정하세요. 이 기능은 소진되면 서비스 장애가 발생할 수 있는 중요한 리소스를 모니터링하는 알림 정책에 유용합니다. 예를 들어 여유 디스크 공간을 모니터링하는 알림 정책에 대해 반복 알림을 설정할 수 있습니다.
기본적으로 알림 정책은 이슈가 열릴 때 각 알림 채널에 하나의 알림을 보냅니다. 그러나 기본 동작을 변경하고 알림 정책을 구성하여 알림 정책 알림 채널 전체 또는 일부에 알림을 다시 전송할 수 있습니다. 이러한 반복 알림은 미해결 또는 확인 상태인 이슈에 대해 전송됩니다. 이러한 알림의 간격은 최소 30분에서 24시간 사이여야 하며 초 단위로 표시됩니다.
Google Cloud 콘솔
Google Cloud 콘솔에서는 반복 알림을 구성할 수 없습니다. 대신 Google Cloud CLI 또는 API를 사용하세요.
API
AlertStrategy 객체에 하나 이상의 NotificationChannelStrategy 객체를 추가합니다.
NotificationChannelStrategy 객체에는 두 필드가 있습니다.
renotifyInterval: 반복 알림 사이의 시간(초)입니다.renotifyInterval필드의 값은 언제든지 변경할 수 있습니다. 간격을 변경할 때 알림 정책과 관련된 이슈가 열리면 알림 정책은 해당 이슈에 대한 또 다른 알림을 전송한 다음 간격 기간을 다시 시작합니다.notificationChannelNames:projects/PROJECT_ID/notificationChannels/CHANNEL_ID형식의 문자열인 알림 채널 리소스 이름의 배열입니다. 이러한 알림 채널은renotifyInterval값에 의해 정의된 간격으로 반복 알림을 수신합니다.리소스 이름 채널 ID는 숫자 값입니다. 채널 ID를 검색하는 방법에 대한 자세한 내용은 프로젝트의 알림 채널 나열을 참조하세요.
예를 들어 다음 JSON 샘플은 1800초(30분)마다 반복되는 알림을 나열된 알림 채널로 전송하도록 구성된 알림 전략을 보여줍니다.
"alertStrategy": {
"notificationChannelStrategy": [
{
"notificationChannelNames": [
"projects/PROJECT_ID/notificationChannels/CHANNEL_ID"
],
"renotifyInterval": "1800s"
}
]
}
API로 알림 정책 만들기에 대한 자세한 내용은 API를 통해 알림 정책 만들기를 참조하세요.
일정 기간 동안 반복되는 알림을 중지하려면 알림 정책을 사용 중지하거나 일시중지를 만듭니다. 반복되는 알림을 완전히 중지하려면 API를 사용하여 알림 정책을 수정하고 NotificationChannelStrategy 객체를 삭제합니다.
지연 시간
지연 시간이란 Monitoring에서 측정항목을 샘플링한 후 측정항목 데이터 포인트가 시계열 데이터로 표시될 때까지의 지연을 의미합니다. 지연 시간은 알림 전송 시점에 영향을 줍니다. 예를 들어 모니터링되는 측정항목의 지연 시간이 최대 180초인 경우 Monitoring은 알림 정책 조건이 true로 평가된 후 최대 180초 동안 이슈를 만들지 않습니다. 자세한 내용은 측정항목 데이터의 지연 시간을 참조하세요.
다음 이벤트 및 설정이 지연 시간에 영향을 미칩니다.
측정항목 수집 지연: Monitoring에서 측정항목 값을 수집해야 하는 시간입니다. Google Cloud 값의 경우 대부분의 측정항목은 수집 후 60초 동안 표시되지 않습니다. 하지만 지연 시간은 측정항목에 따라 달라집니다. 알림 정책 계산에 따라 60~90초까지 추가로 시간이 지연될 수 있습니다. AWS CloudWatch 측정항목의 경우 몇 분까지 표시가 지연될 수 있습니다. 업타임 체크의 경우 지연 시간은 평균 기간은 2분입니다(기간 종료 시점으로부터).
기간: 조건에 구성되는 기간입니다. 조건은 전체 기간 동안 조건이 true인 경우에만 충족됩니다. 예를 들어 기간을 5분으로 설정하면 알림이 이벤트가 처음 발생한 시점으로부터 5분 이상 지연됩니다.
알림 도착 시간: 이메일 및 SMS 등의 알림 채널 자체적으로 네트워크 또는 기타 지연 시간이 발생할 수 있으며(전송 항목과 무관) 경우에 따라 수 분이 지연됩니다. SMS 및 Slack 등의 일부 채널에서는 메일이 전송된다는 보장도 없습니다.
다음 단계
알림 정책을 만드는 방법은 다음 문서를 참조하세요.
다양한 알림 정책 종류는 샘플 정책을 참조하세요.