심층 알림 정책

이 페이지에서는 Stackdriver Monitoring 알림 정책에 대한 개념을 자세히 설명합니다. 이 자료를 이해하면 알림 정책을 효과적으로 사용하는 데 도움이 될 것입니다.

알림 정책 만들기 및 관리에 대한 자세한 내용은 다음을 참조하세요.

정책

알림 정책에서는 비정상 서비스로 간주되는 조건을 정의합니다. 조건이 충족되면 정책이 적용되고 새 이슈가 개설됩니다. 구성 시 적용된 정책에서도 알림을 전송합니다.

정책은 개별 작업공간에 속하며, 각 작업공간은 최대 500개의 정책을 포함할 수 있습니다.

조건

조건으로 알림 정책이 적용되는 시기가 결정됩니다. 조건을 설명하려면 다음 항목을 지정합니다.

  • 측정할 측정항목
  • 알림이 필요한 상태에 도달한 측정항목을 결정하는 테스트

모니터링 대상에 따라 다음을 참조하는 조건을 만들 수 있습니다.

조건 유형

조건은 측정항목을 기반으로 하며 일정 값에 도달하거나 급변하는 측정항목 등을 모니터링할 수 있습니다. 측정항목은 리소스와 연결되며 VM 그룹의 평균 CPU 사용률과 같은 리소스 특성을 측정합니다. 측정항목에 대한 자세한 내용은 측정항목, 시계열, 리소스를 참조하세요.

모든 조건은 어떤 측정항목이 어느 정도의 기간 어떤 방식으로 변화하는지를 감시합니다.

모든 조건은 일반적인 두 유형 중 하나로 구현됩니다.

  • 측정항목 부재 조건 - 특정 기간 측정항목의 시계열에 데이터가 없는 경우에 트리거됩니다.

    측정항목 부재 조건의 경우, 정책이 설치된 이후 또는 최대 기간(24시간) 내에 데이터가 검색된 성공적인 측정이 하나 이상 있어야 합니다.

    예를 들어 측정항목 부재 정책의 기간을 30분으로 설정했다고 가정하겠습니다. 측정항목 데이터가 기록되는 하위 시스템에서 데이터 포인트를 작성하지 않을 경우 조건이 충족되지 않습니다. 이 하위 시스템은 적어도 하나의 데이터 포인트를 출력한 후 30분 동안 추가 데이터 포인트를 출력하는 데 실패해야 합니다.

  • 측정항목 기준 조건 - 측정항목이 특정 기간 값을 초과하거나 미달하는 경우 트리거됩니다.

    측정항목 기준 조건의 클래스에는 일반적인 하위 카테고리에 해당하는 패턴이 있습니다.

    • 측정항목 변환율(백분율): 측정항목이 일정 기간 특정 백분율 값 이상 증가하거나 감소하는 경우 트리거됩니다.

      이 조건 유형에서는 기준과 비교하기에 앞서 변환율 계산을 시계열에 적용합니다.

      지난 10분간의 측정항목 값의 평균을 계산한 후 해당 기간 직전에 측정한 10분간의 평균 결과와 비교합니다. 측정항목 변환율 조건에서 사용하는 10분 전환 확인 기간은 고정 값으로서 변경할 수 없습니다. 하지만 조건을 만들 때 사용자가 기간을 지정할 수 있습니다.

    • 그룹 집계 기준: 리소스 그룹에서 측정한 측정항목이 기준을 초과하는 경우 트리거됩니다.

    • 업타임 체크 상태: 업타임 체크를 만들었으며 2개 이상의 지리적 위치에서 전송된 요청에 성공적으로 응답하는 데 실패한 경우 트리거됩니다.

      업타임 체크 결과는 Stackdriver Monitoring 콘솔의 업타임 체크 개요 페이지에만 표시됩니다. 업타임 체크에 대한 알림 정책을 만들면 간접적으로 이슈를 개설하고, 선택적으로 실패 시 알림을 전송하는 업타임 체크를 이용할 수 있습니다.

    • 프로세스 상태: (1) VM 인스턴스 또는 인스턴스 그룹에서 실행되며 (2) 일부 문자열과 일치하는 프로세스의 수가 일정 기간 특정 수치를 초과하거나 이에 미달하는 경우 트리거됩니다.

      이 조건 유형을 사용하려면 Monitoring 에이전트가 모니터링 소스에서 실행 중이어야 합니다.

각 유형의 예는 다음과 같습니다.

조건 유형 JSON 예
측정항목 기준
변환율
그룹 집계
가동시간 확인
프로세스 상태

조건 결합

한 정책에는 최대 6개의 조건이 포함될 수 있습니다. 여러 개의 조건을 사용하는 경우 3가지 방법을 통해 정책을 위반하는 조합을 지정할 수 있습니다.

  • OR: 어떤 조건이든 충족할 경우
  • AND: 하나 이상의 리소스에서 조건을 위반한 경우(서로 다른 리소스가 각 조건을 위반해도 해당)
  • AND_WITH_RESOURCES: 동일한 리소스가 모든 조건을 위반한 경우. (Monitoring API를 사용하여 만든 조건에만 사용 가능한 옵션입니다.)

기간

조건에는 트리거 전에 조건이 참으로 평가되어야 하는 기간이 포함되어 있습니다. 조건의 기간을 통해 알림 정책의 과도한 트리거를 방지합니다. 궁극적으로 알림을 계속하여 전송하는 알림 정책이 무시되므로 오탐률을 줄일 수 있습니다.

대체적으로 가용성이 높은 서비스거나 문제를 감지하지 못할 경우의 불이익이 클수록 짧은 기간을 지정하는 것이 좋습니다.

성능이 정상적으로 변동되는 경우도 있으므로 단일 측정으로 조건과 일치하는 결과를 얻었다고 해서 정책이 트리거되는 것은 바람직하지 않습니다. 따라서 보통은 조건을 충족하는 여러 번의 연속 측정 결과를 얻은 후 애플리케이션 상태가 비정상적이라고 판단합니다.

조건에서는 측정으로 조건이 충족되지 않을 때마다 기간을 재설정됩니다.

다음 조건에서는 5분을 기간으로 지정합니다.
- 5분 연속으로 HTTP 지연 시간이 2초 이상 발생하는 경우

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

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

거짓양성을 줄이기에 충분할 정도로 기간이 길어야 하지만 이슈가 적절한 시기에 개설될 수 있도록 너무 길어서도 안 됩니다.

정책 행동

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

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

알림 정책 사용 중지

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

알림 정책을 사용 중지하면 정책이 트리거(또는 확인)되지 못하지만 Stackdriver가 정책 조건을 평가하고 결과를 기록하지 못하는 것은 아닙니다.

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

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

비정상적인 이슈

특히 측정항목 부재 또는 '다음 미만' 기준 조건의 알림 정책은 알림 > 이슈 페이지에 표시되어 이른 시기에 트리거되거나 잘못 트리거될 수 있습니다.

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

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

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

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

부분적인 측정항목 데이터

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

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

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

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

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

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

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

정책당 이슈

알림 정책은 여러 리소스에 적용될 수 있으며, 모든 리소스에 영향을 주는 문제로 인해 정책이 트리거되고 각 리소스의 이슈가 개설될 수 있습니다. 시스템에 과부하가 걸리지 않도록 단일 정책이 동시에 열 수 있는 이슈 수는 5,000개로 제한됩니다.

예를 들어 정책이 Compute Engine 인스턴스 2,000개(또는 20,000개)에 적용되고 어떤 문제로 인해 알림 조건을 위반하면 이슈가 5,000개만 개설됩니다. 나머지 위반사항은 해당 정책의 개설된 이슈 중 일부가 해결될 때까지 무시됩니다.

이슈별 알림

이슈별로 전송되는 알림의 수는 정책 조건에 따라 다릅니다.

정책에 조건이 하나 밖에 없을 경우 이슈가 처음 개설되면 이후 측정에서 계속 조건을 충족하더라도 알림이 한 번만 전송됩니다.

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

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

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

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

알림 지연 시간

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

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

  • 측정항목 수집 지연: Stackdriver Monitoring에서 측정항목 값을 수집해야 하는 시간입니다. GCP 값인 경우 보통은 무시해도 상관없습니다. AWS CloudWatch 측정항목에서는 이 시간이 수 분이 될 수 있습니다. 업타임 체크에서는 지연 시간이 (기간 종료 시점으로부터) 평균 4분이며 최대 지연은 5분 30초입니다.

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

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

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

Stackdriver Monitoring
도움이 필요하시나요? 지원 페이지를 방문하세요.