알림 동작

알림 정책은 동적 환경 및 복합 환경에 존재하므로 이를 효과적으로 사용하려면 동작에 영향을 줄 수 있는 몇몇 변수에 대해 이해해야 합니다. 조건에서 측정하는 측정항목 및 리소스, 조건의 기간, 알림 채널이 상호 간에 영향을 미칠 수 있습니다.

이 페이지에서는 알림 정책의 동작을 이해하는 데 유용한 추가 정보를 제공합니다.

정렬 기간 및 기간

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

정렬 기간

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

알림 정책의 조건에 대한 정렬 기간의 효과를 설명하기 위해 샘플링 기간이 1분인 측정항목을 모니터링하는 조건을 상정해 보겠습니다. 정렬 기간이 5분으로 설정되어 있고 정렬기가 sum으로 설정되었다고 가정합시다. 마지막으로 시계열의 정렬된 값이 3분 동안 2보다 크고 조건이 1분마다 평가될 경우 조건이 충족된 것으로 간주됩니다.

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

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

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

기간

단일 측정으로 조건이 충족되지 않도록 하려면 기간 또는 구간을 사용합니다. Google Cloud Console을 사용하는 경우 구성 창의 기간 필드가 기간에 해당합니다.

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

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

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

이 그림은 정렬기와 결합되는 데이터 샘플 수를 결정하는 것은 정렬 기간이라는 것을 보여줍니다. 장기간을 선택하면 많은 샘플이 결합됩니다. 짧은 기간을 선택하면 하나의 데이터 포인트만 간격 안에 들어갈 수 있습니다. 이와는 대조적으로, 기간은 조건이 충족될 때까지 정렬된 값이 임곗값을 초과해야 하는 기간을 지정합니다. 기간이 0으로 설정되면 기준을 초과하는 단일 정렬 값이 있으면 조건이 충족된다는 것을 의미합니다.

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

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

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

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

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

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

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

여러 조건이 포함된 정책

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

Cloud Monitoring API를 사용 중이거나 알림 정책에 여러 조건이 있는 경우 개별 조건이 충족되는 시점을 지정해야 합니다. 조건이 충족되면 이벤트가 생성되고 잠재적으로 이슈가 열릴 수 있습니다.

  • Google Cloud Console을 사용하는 경우 정책 트리거 필드를 사용하세요.
  • Cloud Monitoring API를 사용하는 경우 combiner 필드를 사용하세요.

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

Cloud Console
정책 트리거 값
Cloud Monitoring API
컴바이너 값
의미
어떤 조건이든 충족할 경우 OR 어떤 리소스라도 어느 조건이든 충족되면 이슈가 열립니다.
각 조건의 다른
리소스라도
모든 조건이 충족됨

(기본값)
AND 다른 리소스가 조건을 충족하는 경우에도 조건이 하나 이상의 리소스에 의해 충족되면 이슈가 열립니다.
모든 조건 충족 AND_WITH_MATCHING_RESOURCE 동일한 리소스가 조건을 충족할 경우 이슈가 개설됩니다. 이 설정은 가장 엄격한 조합 선택입니다.

여기에서 충족이라는 용어는 조건의 구성이 true로 평가되는 것을 의미합니다. 예를 들어 구성이 Any time series is above 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 usage is too high 조건이 충족됩니다. 조건이 어떤 조건이든 충족됨과 결합된 경우 조건이 충족되어 이슈가 생성됩니다. 조건이 모든 조건 충족 또는 각 조건의 다른 리소스에 대해서도 모든 조건 충족과 결합된 경우 이슈는 생성되지 않습니다. 이러한 결합기 선택에서는 모든 조건을 충족해야 합니다.

다음으로 vm1의 CPU 사용량이 100ms/s를 초과하고 vm2의 CPU 사용률이 1분 동안 60%를 초과한다고 가정합니다. 결과는 모든 조건이 충족하는 것입니다. 다음은 조건이 결합되는 방식에 따라 어떻게 되는지 설명합니다.

  • 어떤 조건이든 충족됨: 리소스로 조건이 충족될 때 이슈가 생성됩니다. 이 예시에서는 vm2가 조건 Excessive utilization를 충족합니다.

    참고로 vm2가 조건 CPU usage is too high를 충족한다면 이에 대한 결과 또한 이슈가 생성되는 것입니다. vm1이 CPU usage is too high 조건을 충족하고 vm2가 조건 CPU usage is too high를 충족하는 것은 서로 다른 이벤트이기 때문입니다.

  • 각 조건의 다른 리소스에 대해서도 모든 조건 충족: 두 조건이 모두 충족되므로 이슈가 생성됩니다.

  • 모든 조건 충족: 이 결합자는 동일한 리소스가 모든 조건을 충족해야 하므로 이슈가 생성되지 않습니다. 이 예시에서는 vm1이 CPU usage is too high를 충족하면서 vm2가 Excessive utilization를 충족하므로 이슈가 생성되지 않습니다.

알림 정책 사용 중지

사용 중지와 사용 설정을 통해 알림 정책을 임시로 일시중지하고 재개할 수 있습니다. 예를 들어 프로세스가 5분 이상 중지되면 알림을 제공하는 알림 정책의 경우 업그레이드 또는 기타 유지관리를 위해 프로세스를 중단시킬 때 알림 정책을 사용 중지하면 됩니다.

알림 정책을 사용 중지하면 정책이 이슈를 트리거 또는 해결할 수 없지만 Cloud Monitoring은 여전히 정책 조건을 평가하고 결과를 기록합니다. 알림 정책을 사용 중지하고 미해결 문제가 해결된 상태로 되게 하려면 해당 이슈를 수동으로 해결해야 합니다. 이 절차에 대한 자세한 내용은 종료된 이슈를 참조하세요.

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

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

비정상적인 이슈

특히 측정항목 부재 또는 '다음 미만' 임곗값 조건의 알림 정책은 알림 창의 이슈 창에 표시되어 이른 시기에 트리거되었거나 잘못된 트리거로 보일 수 있습니다.

데이터가 격차가 있을 때 이러한 현상이 발생하지만 이러한 격차를 파악하는 것이 항상 쉬운 것은 아닙니다. 격차가 모호할 때도 있고 수정될 때도 있기 때문입니다.

예를 들어 차트에서는 데이터에 간격이 있으면 중간 값이 채워집니다. 수 분간 데이터가 누락될 수 있지만 차트에서는 시각적 연속성을 위해 누락된 요소를 연결합니다. 기본 데이터에서 이러한 간격이 발생할 경우 알림 정책이 충분히 트리거될 수 있습니다.

로그 기반 측정항목의 경우 과거 10분까지는 늦게 도착한 요소를 다시 채울 수 있습니다. 마침내 도착한 데이터로 간격을 채워 간격이 효과적으로 수정됩니다. 이 경우 더 이상은 확인이 불가능한 로그 기반 측정항목의 간격으로 인해 알림 정책이 트리거될 수 있습니다.

측정항목 부재 및 '다음 미만' 기존 조건은 실시간으로 평가되어 쿼리 지연이 적습니다. 평가 시점과 Monitoring 콘솔에 해당 이슈가 표시되는 시점 사이에 조건 상태가 변경될 수 있습니다.

부분적인 측정항목 데이터

측정이 누락된 경우(예: 수 분간 HTTP 요청이 없는 경우) 정책에서는 마지막으로 기록된 값을 사용해 조건을 평가합니다.

예시

  1. 5분 연속으로 HTTP 지연 시간이 2초 이상 발생하는 경우를 조건으로 지정합니다.
  2. 3분 연속으로 HTTP 지연 시간이 3초를 기록합니다.
  3. 2분 연속 HTTP 요청이 없습니다. 이 경우 조건에서 해당하는 2분에 마지막 측정값(3초)을 이월합니다.
  4. 마지막 2분간은 데이터가 없었더라도 총 5분 후 정책이 트리거됩니다.

측정항목 데이터의 누락 또는 지연으로 인해 정책에서 알림이 제공되지 않고 이슈가 종료되지 않을 수 있습니다. 타사 클라우드 제공업체에서 전송하는 데이터의 경우 일반적으로 5-15분 지연되며 30분까지도 지연될 수 있습니다. 지연 시간이 기간보다 길면 조건이 '알 수 없음' 상태로 전환될 수 있습니다. 데이터가 마침내 도착했을 때는 이미 Cloud Monitoring에서 최근의 조건 기록 일부가 손실되었을 수 있습니다. 데이터가 도착한 후에는 지연되었다는 증거가 남지 않으므로 이후 시계열 데이터를 검사해도 이 문제가 드러나지 않을 수 있습니다.

다음 중 하나를 수행하면 이러한 문제를 최소화할 수 있습니다.

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

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

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

정책당 이슈

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

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

예를 들어 정책이 2,000개(또는 20,000개)의 Compute Engine 인스턴스에 적용되고 각 인스턴스가 알림 조건을 충족하는 경우 5,000개의 이슈만 열립니다. 열린 이슈 중 일부가 해결될 때까지 충족된 나머지 조건은 무시됩니다.

이슈별 알림

조건을 충족하는 각 시계열에 알림이 전송됩니다. 시계열이 더 이상 조건을 충족하지 않으면 또 다른 알림이 전송됩니다. 조건이 더 이상 충족되지 않으면 이슈가 해결됩니다.

정책에 조건이 다수 포함된 경우 정책 설정 방식에 따라 알림이 여러 번 전송될 수 있습니다.

  • 모든 조건이 충족되어야 정책이 트리거되는 경우 이슈가 처음 개설될 때만 정책에서 알림을 전송합니다.

  • 어떤 조건이든 충족되면 정책이 트리거되는 경우 새로운 조건 조합이 충족될 때마다 정책에서 알림을 전송합니다. 예를 들면 다음과 같습니다.

    1. 조건 A가 충족되어 이슈가 개설되고 알림이 전송됩니다.
    2. 이후 측정에서 조건 A 및 조건 B를 모두 충족하는데 이슈가 아직 종료되지 않은 상태입니다. 이 경우 이슈가 개설된 상태로 유지되고 또 다른 알림이 전송됩니다.

알림 지연 시간

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

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

  • 측정항목 수집 지연: Cloud Monitoring에서 측정항목 값을 수집해야 하는 시간입니다. Google Cloud 값의 경우 일반적으로는 무시해도 상관없습니다. AWS CloudWatch 측정항목에서는 이 시간이 수 분이 될 수 있습니다. 업타임 체크의 경우 지연 시간은 평균 기간은 2분입니다(기간 종료 시점으로부터).

  • 기간: 조건에 구성되는 기간입니다. 해당 기간 내내 조건이 참인 경우에만 조건이 충족됩니다. 예를 들어 기간을 5분으로 지정하면 이벤트가 처음 발생한 후 5분 이상 지연됩니다.

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

다음 단계

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