측정항목 기반 알림 정책 동작

이 문서에서는 정렬 기간 및 기간 설정이 조건이 트리거되는 시점, 알림 정책이 여러 조건을 결합하는 방법, 알림 정책이 누락된 데이터 포인트를 대체하는 방법을 설명합니다. 또한 정책의 최대 미해결 이슈 수, 이슈당 알림 수, 알림 지연의 원인을 설명합니다.

이 콘텐츠는 로그 기준 알림 정책에 적용되지 않습니다. 로그 기준 알림 정책에 대한 자세한 내용은 로그 모니터링을 참조하세요.

정렬 기간 및 기간 설정

정렬 기간 및 기간은 알림 정책 조건을 지정할 때 설정한 두 필드입니다. 이 섹션에서는 이러한 필드의 의미를 간략하게 설명합니다.

정렬 기간

정렬 기간은 특정 시점에서 되돌아보는 시간 간격입니다. 예를 들어 정렬 기간이 5분인 경우, 오후 1시에 정렬 기간에는 오후 12시 55분부터 1시 사이에 수신된 샘플이 포함됩니다. 오후 1:01에는 정렬 기간이 1분 이동하여 오후 12:56 ~ 오후 1:01 사이에 수신된 샘플이 포함됩니다.

알림 정책의 조건에 대한 정렬 기간의 효과를 설명하기 위해 샘플링 기간이 1분인 측정항목을 모니터링하는 조건을 상정해 보겠습니다. 정렬 기간이 5분으로 설정되어 있고 정렬기가 sum으로 설정되었다고 가정합시다. 시계열의 정렬된 값이 3분 이상 2보다 크면 조건이 충족 또는 활성 상태인 것으로 기술됩니다. 이번 예시에서는 조건이 1분마다 평가된다고 가정해보세요.

다음 그림은 조건의 순차적 평가를 보여줍니다.

정렬 기간의 효과를 보여주는 그림.

그림의 각 행은 조건에 대한 단일 평가를 보여줍니다. 시계열 데이터가 표시되었습니다. 정렬 기간의 점은 파란색 점으로 표시되며 더 이전의 점은 모두 검은색입니다. 각 행에는 정렬된 값과 이 값이 임곗값 2을 초과하는지 여부가 표시됩니다. start 라벨이 지정된 행의 경우 정렬된 값은 임곗값보다 작은 1로 계산됩니다. 다음 평가에서 정렬 기간의 샘플 합계는 2입니다. 세 번째 평가에서 합계는 3이며 이것은 임곗값보다 큽니다. 조건 평가자 역시 기간 타이머를 시작합니다.

기간

단일 측정으로 조건이 충족되지 않도록 하려면 기간 또는 구간을 사용합니다. Google Cloud Console에서 다음 필드를 사용하여 기간을 구성하세요.

기존 인터페이스

알림 정책 구성 창의 기간 필드를 사용하여 기간을 구성할 수 있습니다.

미리보기 인터페이스

트리거 구성 단계에서 재테스트 범위 필드를 사용하여 기간을 구성합니다.

API

MetricThresholdMetricAbsence 구조에서 duration 필드를 설정하여 기간을 구성합니다.

앞의 그림에서는 조건에 대한 3가지 평가를 보여주었습니다. start + 2 minutes 시점의 정렬된 값은 임곗값을 초과합니다. 그러나 기간이 3분으로 설정되어 있기 때문에 조건이 충족되지 않습니다. 다음 그림은 조건의 다음 평가에 대한 결과를 보여줍니다.

기간 효과를 보여주는 그림.

start + 2 minutes 시점에 정렬된 값이 임곗값을 초과하더라도 정렬된 값이 3분 동안 임곗값을 초과할 때까지는 조건이 충족되지 않습니다. 이는 start + 5 minutes 시점에 발생합니다.

명료한 설명을 위해, 이전 예시에서는 여러 시계열의 정렬된 데이터 요소를 단일 측정으로 결합하는 가능성을 생략했습니다. 측정값과 임곗값을 비교하여 조건 충족 여부를 확인합니다.

조건은 측정이 조건을 충족하지 않을 때마다 기간을 재설정합니다. 이 동작은 다음 예시에서 설명합니다.

예시: 이 정책은 5분 길이의 기간을 지정합니다.

HTTP 응답 지연 시간이 2초를 초과하고
지연 시간이 임곗값 5분을 초과하는 경우
이슈를 시작하고 지원팀에 이메일을 전송합니다.

다음 시퀀스에서는 기간이 조건 평가에 미치는 영향을 보여줍니다.

  1. HTTP 지연 시간이 2초 미만입니다.
  2. 그 다음 3분 연속으로 HTTP 지연 시간이 2초 이상입니다.
  3. 다음 번 측정에서 지연 시간이 2초 미만이므로 조건의 기간이 재설정됩니다.
  4. 다음 5분 연속으로 HTTP 지연 시간이 2초를 초과하면 조건이 충족되고 정책이 트리거됩니다.

기간을 설정할 때는 거짓양성을 최소화하기에 충분할 정도로 길게 설정하되, 이슈가 적절한 시기에 개설될 수 있도록 충분히 짧게 설정하세요.

정렬 기간 및 기간 선택

알림 정책 조건은 고정된 빈도로 평가됩니다. 정렬 기간 및 기간 선택이 조건 평가 빈도를 결정하지 않습니다.

앞선 그림에서는 정렬 기간이 정렬기와 결합되는 데이터 샘플 수를 결정함을 보여줍니다. 많은 샘플을 조합하려면 긴 기간을 선택합니다. 간격을 샘플 1개 정도로 제한하려면 짧은 기간을 선택합니다. 이와는 대조적으로, 기간은 조건이 충족될 때까지 정렬된 값이 임곗값을 초과해야 하는 기간을 지정합니다. 단일 정렬된 값이 임곗값보다 클 때 조건이 충족되도록 하려면 기간을 0으로 설정합니다.

여러 조건이 포함된 정책

알림 정책에는 최대 6개의 조건이 포함될 수 있습니다.

Cloud Monitoring API를 사용 중이거나 알림 정책에 여러 조건이 있는 경우 이슈가 열려 있는 시점을 지정해야 합니다. 여러 조건이 결합되는 방식을 구성하려면 다음 중 하나를 수행합니다.

기존 인터페이스

정책 트리거 필드에서 결합자 옵션을 구성합니다.

미리보기 인터페이스

다중 조건 트리거 단계에서 결합자 옵션을 구성합니다.

API

AlertPolicy 구조의 combiner 필드를 사용해서 결합자 옵션을 구성합니다.

이 표에는 Cloud Console의 설정, Cloud Monitoring API의 해당 값, 각 설정에 대한 설명이 나와 있습니다.

Cloud Console
정책 트리거 값
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에서 최근의 조건 기록 일부가 손실되었을 수 있습니다. 데이터가 도착한 후에는 지연되었다는 증거가 남지 않으므로 이후 시계열 데이터를 검사해도 이 문제가 드러나지 않을 수 있습니다.

기존 인터페이스

데이터 도착을 중지할 때 Monitoring에서 미해결 이슈를 종료할 때까지 기다리는 시간을 구성할 수 있습니다. 그러나 Monitoring에서 누락된 데이터의 대체 값을 선택하는 방법을 구성할 수 없습니다.

데이터 수신이 중지된 후 열린 이슈를 닫기 전에 Monitoring이 기다리는 시간을 구성하려면 이슈 자동 종료 기간 필드를 사용합니다. 자동 종료 기간은 알림 단계에서 설정합니다. 기본 자동 종료 기간은 7일입니다.

미리보기 인터페이스

데이터의 도착이 중지될 때 Monitoring에서 측정항목 임곗값 조건을 평가하는 방식을 구성할 수 있습니다. 예를 들어 이슈가 미해결이고 예상 측정값이 도착하지 않으면 Monitoring을 통해 이슈를 미해결 상태로 두거나 즉시 종료할까요? 마찬가지로 데이터 도착이 중지되고 미해결 이슈가 없는 경우 이슈를 열까요? 마지막으로, 데이터 도착이 중지된 후 이슈를 얼마나 미해결 상태로 유지할까요?

데이터 도착이 중지될 때 Monitoring에서 측정항목 임곗값 조건을 평가하는 방법을 지정하는 구성 가능한 필드가 2개 있습니다.

  • Monitoring에서 누락된 데이터의 대체 값을 결정하는 방법을 구성하려면 조건 트리거 단계에서 설정한 평가 누락 데이터 필드를 사용합니다. 재테스트 범위재테스트 없음으로 설정된 경우 이 필드는 사용 중지됩니다.

  • 데이터 수신이 중지된 후 열린 이슈를 닫기 전에 Monitoring이 기다리는 시간을 구성하려면 이슈 자동 종료 기간 필드를 사용합니다. 자동 종료 기간은 알림 단계에서 설정합니다. 기본 자동 종료 기간은 7일입니다.

다음은 누락된 데이터 필드의 여러 옵션에 대한 설명입니다.

Cloud Console
'평가 누락 데이터' 필드
요약 세부정보
누락 데이터 비어 있음 열린 이슈가 열린 상태로 유지됩니다.
새 이슈가 열리지 않습니다.

충족된 조건의 경우 데이터 수신이 중지될 때 조건이 계속 충족됩니다. 이 조건에 대해 이슈가 열려 있으면 이슈가 열린 상태로 유지됩니다. 이슈가 열려 있고 자동 종료 기간에 데이터가 수신되지 않으면 이슈가 닫힙니다.

충족되지 않은 조건의 경우 데이터 수신이 중지할 때 조건이 계속 충족되지 않습니다.

정책 조건을 위반하는 값으로 취급되는 누락된 데이터 포인트 열린 이슈가 열린 상태로 유지됩니다.
새 이슈를 개설할 수 있습니다.

충족된 조건의 경우 데이터 수신이 중지될 때 조건이 계속 충족됩니다. 이 조건에 대해 이슈가 열려 있으면 이슈가 열린 상태로 유지됩니다. 이슈가 열려 있고 자동 종료 기간과 24시간 내에 데이터가 수신되지 않으면 이슈가 닫힙니다.

충족되지 않은 조건의 경우 이 설정에 따라 측정항목 임곗값 조건이 측정항목 부재 조건과 같이 작동합니다. 다시 테스트 기간으로 지정된 시간에 데이터가 수신되지 않으면 조건이 충족된 것으로 평가됩니다. 조건이 하나 있는 알림 정책의 경우 충족된 조건에 따라 이슈가 열립니다.

정책 조건을 위반하지 않는 값으로 취급되는 누락된 데이터 포인트 열린 이슈가 닫힙니다.
새 이슈가 열리지 않습니다.

충족된 조건의 경우 데이터 수신이 중지될 때 조건 충족이 중지됩니다. 이 조건에 대해 이슈가 열려 있으면 이슈가 닫힙니다.

충족되지 않은 조건의 경우 데이터 수신이 중지할 때 조건이 계속 충족되지 않습니다.

API

데이터의 도착이 중지될 때 Monitoring에서 측정항목 임곗값 조건을 평가하는 방식을 구성할 수 있습니다. 예를 들어 이슈가 미해결이고 예상 측정값이 도착하지 않으면 Monitoring을 통해 이슈를 미해결 상태로 두거나 즉시 종료할까요? 마찬가지로 데이터 도착이 중지되고 미해결 이슈가 없는 경우 이슈를 열까요? 마지막으로, 데이터 도착이 중지된 후 이슈를 얼마나 미해결 상태로 유지할까요?

데이터 도착이 중지될 때 Monitoring에서 측정항목 임곗값 조건을 평가하는 방법을 지정하는 구성 가능한 필드가 2개 있습니다.

  • Monitoring에서 누락된 데이터의 대체 값을 결정하는 방법을 구성하려면 MetricThreshold 구조의 evaluationMissingData 필드를 사용합니다. 기간 필드가 0이면 이 필드가 무시됩니다.

  • 데이터 수신이 중지된 후 열린 이슈를 닫기 전에 Monitoring이 기다리는 시간을 구성하려면 AlertStrategy 구조의 autoClose 필드를 사용합니다.

다음은 누락된 데이터 필드의 여러 옵션에 대한 설명입니다.

API
evaluationMissingData 필드
요약 세부정보
EVALUATION_MISSING_DATA_UNSPECIFIED 열린 이슈가 열린 상태로 유지됩니다.
새 이슈가 열리지 않습니다.

충족된 조건의 경우 데이터 수신이 중지될 때 조건이 계속 충족됩니다. 이 조건에 대해 이슈가 열려 있으면 이슈가 열린 상태로 유지됩니다. 이슈가 열려 있고 자동 종료 기간에 데이터가 수신되지 않으면 이슈가 닫힙니다.

충족되지 않은 조건의 경우 데이터 수신이 중지할 때 조건이 계속 충족되지 않습니다.

EVALUATION_MISSING_DATA_ACTIVE 열린 이슈가 열린 상태로 유지됩니다.
새 이슈를 개설할 수 있습니다.

충족된 조건의 경우 데이터 수신이 중지될 때 조건이 계속 충족됩니다. 이 조건에 대해 이슈가 열려 있으면 이슈가 열린 상태로 유지됩니다. 이슈가 열려 있고 자동 종료 기간과 24시간 내에 데이터가 수신되지 않으면 이슈가 닫힙니다.

충족되지 않은 조건의 경우 이 설정에 따라 측정항목 임곗값 조건이 측정항목 부재 조건과 같이 작동합니다. 다시 테스트 기간으로 지정된 시간에 데이터가 수신되지 않으면 조건이 충족된 것으로 평가됩니다. 조건이 하나 있는 알림 정책의 경우 충족된 조건에 따라 이슈가 열립니다.

EVALUATION_MISSING_DATA_INACTIVE 열린 이슈가 닫힙니다.
새 이슈가 열리지 않습니다.

충족된 조건의 경우 데이터 수신이 중지될 때 조건 충족이 중지됩니다. 이 조건에 대해 이슈가 열려 있으면 이슈가 닫힙니다.

충족되지 않은 조건의 경우 데이터 수신이 중지할 때 조건이 계속 충족되지 않습니다.

다음을 수행하여 누락된 데이터로 인한 문제를 최소화할 수 있습니다.

  • 타사 클라우드 제공업체에 측정항목 수집 지연 시간을 줄일 방법이 있는지 문의합니다.
  • 조건의 기간을 늘립니다. 기간이 길면 알림 정책의 응답성이 떨어진다는 단점이 있습니다.
  • 수집 지연이 적은 측정항목을 선택합니다.

    • 특히 에이전트가 타사 클라우드의 VM 인스턴스에서 실행되는 Monitoring 에이전트 측정항목
    • 사용자가 Cloud Monitoring에 데이터를 직접 작성하는 커스텀 측정항목
    • 로그 수집이 지연되지 않는 경우 로그 기반 측정항목

자세한 내용은 Monitoring 에이전트 개요, 커스텀 측정항목 사용, 로그 기반 측정항목을 참조하세요.

정책당 알림 및 이슈

알림 정책이 사용 중지된 경우 정책에 대한 이슈가 생성되지 않고 알림이 전송되지 않습니다.

알림 정책이 사용 설정되면 이슈를 만들고 알림을 보낼 수 있습니다. 이 섹션에서는 정책당 미해결 이슈 수의 한도와 동일한 이슈에 대한 알림이 여러 번 표시될 수 있는 경우를 설명합니다.

정책당 미해결 이슈 수

알림 정책은 여러 리소스에 적용될 수 있으며, 모든 리소스에 영향을 주는 문제로 인해 정책이 트리거되고 각 리소스의 이슈가 개설될 수 있습니다. 조건을 충족하는 각 시계열마다 이슈가 개설됩니다.

시스템에 과부하가 걸리지 않도록 단일 정책이 동시에 열 수 있는 이슈 수는 5,000개로 제한됩니다.

예를 들어 2,000(또는 20,000)개의 Compute Engine 인스턴스에 적용되는 정책이 있고 각 인스턴스에서 알림 조건이 충족된다고 가정해보세요. Monitoring은 열린 이슈 수를 5,000개로 제한합니다. 열린 이슈 중 일부가 종료될 때까지 충족된 나머지 조건은 무시됩니다.

이슈당 알림 수

기본적으로 시계열로 인해 조건이 충족되면 알림이 전송됩니다. 다음 중 하나라도 해당하는 경우 알림을 여러 개 받을 수 있습니다.

  • 조건이 여러 시계열을 모니터링하고 있습니다.

  • 정책에는 여러 조건이 포함됩니다.

    • 모든 조건이 충족됨: 모든 조건이 충족되면 정책은 조건이 충족되는 각 시계열에 대해 알림을 전송하고 이슈를 생성합니다. 예를 들어 조건이 2개 있고 각 조건이 하나의 시계열을 모니터링하는 정책이 있다고 가정해보세요. 이 정책이 트리거되면 2개의 알림이 수신되고 2개의 이슈가 표시됩니다.

    • 어떤 조건이든 충족됨: 새로운 조건 조합이 충족될 때마다 정책에서 알림을 전송합니다. 예를 들어 조건 A가 충족되어 이슈가 열리고 알림이 전송되었다고 가정해 보겠습니다. 이후 측정에서 조건 A와 조건 B를 모두 충족하는데 이 이슈가 아직 종료되지 않은 상태인 경우 다른 알림이 전송됩니다.

Cloud Monitoring API를 사용하여 생성된 알림 정책은 조건이 충족되고 조건 충족이 중지되는 순간에 알림을 표시합니다. 기본적으로 Google Cloud Console을 사용하여 생성된 알림 정책은 이슈가 열릴 때 알림을 표시합니다. 이슈가 닫힐 때는 알림을 표시하지 않습니다. 이슈 종료 시 알림을 사용 설정할 수 있습니다.

사용 중지된 알림 정책 알림

사용 중지와 사용 설정을 통해 알림 정책을 임시로 일시중지하고 재개할 수 있습니다. 예를 들어 가상 머신(VM)에서 유지보수를 수행하기 전에 해당 인스턴스를 모니터링하는 알림 정책을 사용 중지할 수 있습니다.

알림 정책을 사용 중지하면 정책이 이슈를 트리거 또는 종료할 수 없지만 Cloud Monitoring은 여전히 정책 조건을 평가하고 결과를 기록합니다. 알림 정책을 사용 중지한 후 열린 이슈를 닫으려면 해당 이슈를 무음 처리합니다. 이 절차에 대한 자세한 내용은 이슈 무음 처리를 참조하세요.

사용 중지된 정책을 다시 사용 설정하면 Monitoring에서 일시중지된 간격 동안 및 그 전후에 가져온 데이터가 포함될 수 있는 가장 최근에 해당하는 기간의 모든 조건 값을 조사합니다. 장기간이더라도 다시 시작한 직후에 정책이 트리거될 수 있습니다.

예를 들어, 유지관리를 위해 20분간 모니터링 중인 프로세스를 중지한다고 가정해 보겠습니다. 프로세스를 재개하는 즉시 알림 정책을 다시 사용 설정하면 Monitoring은 지난 5분 동안 프로세스가 가동되지 않았다고 인식되어 이슈가 개설됩니다.

알림 지연 시간

알림 지연 시간이란 문제가 처음 시작된 시점부터 정책이 트리거된 시점까지 지연된 시간을 의미합니다.

다음 이벤트 및 설정이 전체적인 알림 지연 시간에 영향을 미칩니다.

  • 측정항목 수집 지연: Cloud Monitoring에서 측정항목 값을 수집해야 하는 시간입니다. Google Cloud 값의 경우 대부분의 측정항목은 수집 후 60초 동안 표시되지 않습니다. 하지만 지연 시간은 측정항목에 따라 달라집니다. 알림 정책 계산에 따라 60~90초까지 추가로 시간이 지연될 수 있습니다. AWS CloudWatch 측정항목의 경우 몇 분까지 표시가 지연될 수 있습니다. 업타임 체크의 경우 지연 시간은 평균 기간은 2분입니다(기간 종료 시점으로부터).

  • 기간: 조건에 구성되는 기간입니다. 조건은 전체 기간 동안 조건이 true인 경우에만 충족됩니다. 예를 들어 기간을 5분으로 설정하면 알림이 이벤트가 처음 발생한 시점으로부터 5분 이상 지연됩니다.

  • 알림 도착 시간: 이메일 및 SMS 등의 알림 채널 자체적으로 네트워크 또는 기타 지연 시간이 발생할 수 있으며(전송 항목과 무관) 경우에 따라 수 분이 지연됩니다. SMS 및 Slack 등의 일부 채널에서는 메일이 전송된다는 보장도 없습니다.

다음 단계

  • 다양한 유형의 알림 정책에 대한 상세 설명은 알림 정책 유형을 참조하세요.
  • 다양한 알림 정책 종류는 샘플 정책을 참조하세요.