알림 정책 문제 해결

이 페이지에서는 일부 알림 정책이 의도와 다르게 동작할 수 있는 이유를 설명하고 이러한 상황이 발생했을 때의 가능한 해결 방법을 제공합니다.

기간 선택에 따라 알림 정책에 영향을 미칠 수 있는 변수는 측정항목 기반 알림 정책의 동작을 참조하세요.

측정항목 라벨에 대한 변수가 null임

알림 정책을 만들고 문서 섹션에 측정항목 라벨에 대한 변수를 추가합니다. 알림에 변수 값이 표시될 것으로 예상합니다. 하지만 값은 null로 설정됩니다.

이 문제를 해결하려면 다음을 시도합니다.

  • 알림 정책에 대한 집계 설정에서 표시하려는 라벨을 보존해야 합니다.

    예를 들어 VM 인스턴스에서 작성한 디스크 바이트를 모니터링하는 알림 정책을 만든다고 가정해 보겠습니다. 문서에 알림을 발생시키는 기기를 나열되도록 하려면 문서 필드에 device: ${metric.label.device}를 추가합니다.

    또한 집계 설정이 device 라벨 값을 보존하는지 확인해야 합니다. 집계 함수를 none으로 설정하거나 그룹화 선택 항목에 device가 포함되어 있는지 확인하여 이 라벨을 보존할 수 있습니다.

  • 변수의 문법과 적용 가능성을 확인합니다. 문법 정보는 사용자 정의 문서로 알림에 주석 추가를 참조하세요.

    예를 들어 log.extracted_label.KEY 변수는 로그 기반 알림에서만 지원됩니다. 이 변수는 알림 정책이 로그 기반 측정항목을 모니터링할 때 항상 null로 렌더링됩니다.

디스크 사용률 정책이 예기치 않은 이슈 생성

알림 정책을 만들어 시스템에 있는 디스크의 '사용된' 용량을 모니터링했습니다. 이 정책은 agent.googleapis.com/disk/percent_used 측정항목을 모니터링합니다. 물리적 디스크의 사용률이 조건에서 설정한 기준점을 초과하면 알림을 받아야 합니다. 그러나 이 정책은 모든 물리적 디스크의 디스크 사용률이 기준점보다 낮을 때 이슈를 만듭니다.

정책에 대하여 이처럼 예기치 않은 이슈가 발생하는 알려진 원인 중 한 가지는 조건이 물리적 디스크 모니터링으로 제한되지 않았기 때문입니다. 그래서 이 정책은 루프백 기기 등의 가상 디스크를 포함한 모든 디스크를 모니터링합니다. 만일 사용률이 100%가 되도록 가상 디스크가 구성되었다면 해당 정책에 대해 이슈가 발생하게 될 것입니다.

예를 들어 시스템 하나에 마운트된 파일 시스템에서 사용 가능한 디스크 공간을 보여주는 Linux df 명령어의 다음 출력을 살펴봅시다.

$ df
/dev/root     9983232  2337708  7629140   24%  /
devtmpfs      2524080        0  2524080    0%  /dev
tmpfs         2528080        0  2528080    0%  /dev/shm
...
/dev/sda15     106858     3934   102924    4%  /boot/efi
/dev/loop0      56704    56704        0  100%  /snap/core18/1885
/dev/loop1     129536   129536        0  100%  /snap/google-cloud-sdk/150
...

이 시스템에서는 루프백 기기 /dev/loop0 및 /dev/loop1의 시계열을 필터링하도록 디스크 사용률 알림 정책을 구성해야 합니다. 예를 들어 device 라벨이 정규 표현식 ^/dev/loop.*와 일치하지 않는 모든 시계열을 제외하는 device !=~ ^/dev/loop.* 필터를 추가할 수 있습니다.

업타임 정책이 예상된 알림을 생성하지 않음

가상 머신(VM)이 재부팅되거나 다운되면 알림을 받고 싶기 때문에 측정항목 compute.googleapis.com/instance/uptime을 모니터링하는 알림 정책을 만드는 경우는 생각해 봅시다. 측정항목 데이터가 없으면 이슈를 생성하도록 조건을 만들고 구성했습니다. MQL(모니터링 쿼리 언어)1를 사용하여 조건을 정의하지는 않았습니다. 그런데 가상 머신(VM)이 재부팅되거나 다운되어도 알림이 표시되지 않습니다.

이 알림 정책은 RUNNING 상태의 Compute Engine VM 인스턴스에 대해서만 시계열을 모니터링합니다. STOPPED, DELETED 등 다른 상태에 있는 VM의 시계열은 조건이 평가되기 전에 필터링됩니다. 이 동작으로 인해, VM 인스턴스가 실행 중인지 확인하기 위해 측정항목 부재 알림 조건이 있는 알림 정책을 사용할 수 없습니다. VM 인스턴스 상태에 대한 자세한 내용은 VM 인스턴스 수명 주기를 참조하세요.

이 문제를 해결하려면 업타임 체크를 모니터링하는 알림 정책을 만듭니다. 비공개 엔드포인트의 경우 비공개 업타임 체크를 사용하세요.

업타임 체크에 대한 알림 대신 사용할 수 있는 방법은 데이터 부재를 모니터링하는 알림 정책을 사용하는 것입니다. 데이터가 없는 대신 업타임 체크에 대한 알림을 사용하는 것이 좋습니다. Monitoring 데이터의 가용성에 일시적인 문제가 있는 경우 부재 알림이 거짓양성을 생성할 수 있습니다.

그러나 업타임 체크를 사용할 수 없는 경우 MQL을 사용하여 VM이 종료되었음을 알리는 알림 정책을 만들 수 있습니다. MQL 정의 조건은 VM 인스턴스 상태를 기준으로 시계열 데이터를 사전 필터링하지 않습니다. MQL은 VM 상태로 데이터를 필터링하지 않으므로 이를 사용하여 종료된 VM에 데이터가 없음을 감지할 수 있습니다.

다음 MQL 조건은 compute.googleapis.com/instance/cpu/utilization 측정항목을 모니터링합니다.

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
|absent_for 3m

이 조건으로 모니터링되는 VM이 종료되면 3분 후 이슈가 생성되고 알림이 전송됩니다. absent_for 값은 최소 3분 이상이어야 합니다.

MQL에 대한 상세 설명은 MQL을 사용한 알림 정책을 참조하세요.

1: MQL은 Cloud Monitoring API 호출 및 Google Cloud 콘솔에서 사용할 수 있는 표현적인 텍스트 기반 언어입니다. Google Cloud 콘솔을 사용할 때 MQL을 사용하여 조건을 구성하려면 코드 편집기를 사용해야 합니다.

요청 수 정책에서 예상 알림을 만들지 않음

완료된 요청 수를 모니터링하려고 합니다. serviceruntime.googleapis.com/api/request_count 측정항목을 모니터링하는 알림 정책을 만들었지만 요청 수가 구성된 기준점을 초과하면 알림이 전송되지 않습니다.

요청 수 측정항목의 최대 정렬 기간은 7시간 30분입니다.

이 문제를 해결하려면 알림 정책에서 정렬 기간의 값을 확인합니다. 값이 이 측정항목의 최댓값보다 크면 정렬 기간을 7시간 30분 이하로 줄입니다.

비정상적인 이슈의 흔한 원인

알림 정책을 만들었는데 정책이 이슈를 너무 이르게, 또는 부정확하게 일으키는 것으로 보인다고 생각해 봅시다.

잘못된 이슈 알림을 받을 수 있는 이유는 다양합니다.

  • 특히 측정항목 부재 또는 '~미만' 기준점 조건의 알림 정책에서 데이터에 격차가 있는 경우 비정상적으로 보이는 이슈가 생성될 수 있습니다. 이슈에 데이터 격차가 표시되지 않는 경우도 있고 데이터 격차가 자동으로 수정되는 경우도 있습니다.

    • 예를 들어 차트에서는 누락된 데이터의 값이 보간되어 공백이 나타나지 않을 수 있습니다. 몇 분의 데이터가 누락되더라도 차트에서는 시각적 연속성을 위해 누락된 지점을 연결합니다. 기본 데이터의 이러한 간격은 알림 정책이 이슈를 생성하기에 충분할 수 있습니다.

    • 로그 기반 측정항목의 경우 과거 10분까지는 늦게 도착한 요소를 다시 채울 수 있습니다. 백필 동작은 격차를 효과적으로 교정하며, 마침내 데이터가 도착했을 때 간격을 메웁니다. 따라서 더 이상 보이지 않는 로그 기반 측정항목의 격차 때문에 알림 정책이 이슈를 일으키는 원인이었을 가능성이 있습니다.

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

  • 단일 측정에서 이슈를 만들도록 구성된 조건으로 인해 이슈가 조기에 또는 잘못되어 표시될 수 있습니다. 이러한 상황을 방지하려면 조건의 기간 필드를 측정항목의 샘플링 레이트보다 두 배가 초과하도록 설정하여 이슈를 만들기 전에 여러 번 측정해야 합니다.

    예를 들어 측정항목이 60초마다 샘플링되는 경우 기간을 3분 이상으로 설정합니다. 기간 필드를 최근 값 또는 0초로 설정하면 단일 측정으로 이슈가 생성될 수 있습니다.

  • 알림 정책 조건을 수정하면 알림 인프라에 변경사항이 전파될 때까지 몇 분 정도 걸릴 수 있습니다. 이 기간 중에는 원래 알림 정책 조건을 충족한 이슈 알림이 수신될 수 있습니다.

  • 시계열 데이터가 도착할 때는 전체 알림 인프라에 데이터가 전파될 때까지 최대 1분이 소요될 수 있습니다. 정렬 기간이 1분 또는 최근 샘플로 설정되었으면 전파 지연 시간으로 인해 알림 정책이 잘못 트리거된 것으로 표시될 수 있습니다. 이러한 상황이 발생하지 않도록 하려면 정렬 기간을 최소 5분 이상으로 사용하세요.

데이터 수신이 중지될 때 이슈가 종료되지 않음

부분적인 측정항목 데이터의 안내를 따르고 데이터 수신이 중지될 때 이슈를 닫도록 알림 정책을 구성합니다. 경우에 따라 데이터 수신이 중지되지만 열린 이슈가 자동으로 닫히지 않습니다.

알림 정책에 의해 모니터링되는 기본 리소스에 metadata.system_labels.state 라벨이 포함되어 있고 해당 정책이 모니터링 쿼리 언어로 작성되지 않은 경우 Monitoring에서 리소스의 상태를 확인할 수 있습니다. 리소스 상태가 사용 중지된 것으로 알려져 있으면 Monitoring은 데이터 수신이 중지될 때 이슈를 자동으로 닫지 않습니다. 하지만 이러한 이슈를 수동으로 닫을 수 있습니다.

다중 조건 정책이 여러 개의 알림 생성

여러 조건이 포함된 알림 정책을 만들고 해당 조건을 논리적 AND와 결합했습니다. 모든 조건이 충족되면 알림 하나와 이슈 하나가 발생합니다. 그러나 여러 알림이 수신되고 여러 이슈가 생성되는 것을 확인할 수 있습니다.

Monitoring은 알림을 보내고 조건을 충족시키는 각 시계열에 대한 이슈를 만듭니다. 따라서 여러 조건이 포함된 알림 정책이 있는 경우 결합된 조건이 충족되는 각 시계열에 대해 잠재적으로 하나의 알림 및 이슈가 수신될 수 있습니다.

예를 들어 각 조건이 3개의 시계열을 모니터링하는 두 가지 조건을 가진 알림 정책이 있습니다. 정책에서는 두 조건이 모두 충족되는 경우에만 알림을 전송합니다. 정책의 조건이 충족되면 2개(각 조건에서 1개의 시계열이 충족됨)에서 6개(각 조건에서 모든 시계열이 충족됨) 사이의 알림 및 이슈를 수신할 수 있습니다.

단일 이슈를 만들고 단일 알림을 보내도록 Monitoring을 구성할 수 없습니다.

자세한 내용은 이슈별 알림을 참조하세요.

권한 오류로 인해 이슈 세부정보를 볼 수 없음

Google Cloud 콘솔의 이슈 페이지로 이동하여 보려는 이슈를 선택합니다. 그러면 세부정보 페이지가 열려야 합니다. 하지만 세부정보 페이지가 열리지 않고 '권한 거부됨' 메시지가 표시됩니다.

측정항목 데이터를 제외한 모든 이슈 세부정보를 보려면 Cloud 콘솔 이슈 모니터링 뷰어(roles/monitoring.cloudConsoleIncidentViewer)와 Stackdriver 계정 뷰어(roles/stackdriver.accounts.viewer)에 대한 Identity and Access Management(IAM) 역할이 있는지 확인하세요.

측정항목 데이터를 포함한 모든 이슈 세부정보를 보고 이슈를 확인하거나 종료할 수 있으려면 Monitorin모니터링 뷰어(roles/monitoring.viewer) 및 Cloud 콘솔 이슈 모니터링 편집자(roles/monitoring.cloudConsoleIncidentEditor)에 대한 IAM 역할이 있는지 확인합니다.

커스텀 역할은 이슈 세부정보를 보는 데 필요한 권한을 부여할 수 없습니다.

조건이 충족되면 이슈가 생성되지 않음

하나의 조건이 있는 알림 정책을 만들었습니다. 알림 차트에는 모니터링된 데이터가 조건을 위반하지만 알림을 받지 못했으며 이슈가 생성되지 않았다고 표시됩니다.

알림 정책 조건이 충족된 후 다음 기준 중 하나라도 참이면 Monitoring이 이슈를 열지 않습니다.

  • 알림 정책이 일시중지됩니다.
  • 알림 정책이 사용 중지되었습니다.
  • 알림 정책이 동시에 열 수 있는 최대 이슈 수에 도달했습니다.

  • 알림 정책에서 모니터링하는 리소스 상태는 사용 중지된 것으로 알려져 있습니다. Monitoring은 리소스에 metadata.system_labels.state 라벨이 포함되어 있고 알림 정책이 모니터링 쿼리 언어로 작성되지 않은 경우 리소스의 상태를 확인할 수 있습니다.

이슈 세부정보에 잘못된 프로젝트가 나열됨

알림이 수신되면 조건 요약에 이슈가 생성된 Google Cloud 프로젝트가 표시됩니다. 즉, 범위 지정 프로젝트가 나열됩니다. 하지만 이슈에는 모니터링이 이슈를 생성하는 시계열을 저장하는 Google Cloud 프로젝트의 이름이 나열될 것으로 예상합니다.

알림 정책 조건에 지정된 집계 옵션은 알림에서 참조되는 Google Cloud 프로젝트를 결정합니다.

  • 집계 옵션이 프로젝트 ID를 저장하는 라벨을 제거하면 이슈 정보에 범위 지정 프로젝트가 나열됩니다. 예를 들어 데이터를 영역별로 그룹화하면, 그 후 프로젝트 ID를 저장하는 라벨이 삭제됩니다.

  • 집계 옵션이 프로젝트 ID를 저장하는 라벨을 보존하면 이슈 알림에는 이슈를 발생시키는 시계열이 저장된 Google Cloud 프로젝트의 이름이 포함됩니다. 프로젝트 ID 라벨을 보존하려면 그룹화 필드에 project_id 라벨을 포함하거나 시계열을 그룹화하지 않습니다.

이슈를 수동으로 종료할 수 없음

시스템에서 이슈의 알림을 받았습니다. 이슈 세부정보 페이지로 이동하여 이슈 종료를 클릭합니다. 이슈가 종료될 것으로 예상하지만 다음과 같은 오류 메시지가 표시됩니다.

Unable to close incident with active conditions.

가장 최근의 알림 기간에 관측이 없는 경우에만 이슈를 종료할 수 있습니다. 일반적으로 기본값이 5분인 알림 기간은 알림 정책 조건의 일부로 정의되며 구성할 수 있습니다. 이전의 오류 메시지는 알림 기간 내에 데이터가 수신되었음을 나타냅니다.

내부 오류로 인해 이슈를 종료할 수 없으면 다음 오류가 발생합니다.

Unable to close incident. Please try again in a few minutes.

이전의 오류 메시지가 표시되면 종료 작업을 다시 시도할 수도 있고, Monitoring에서 이슈를 자동으로 종료하도록 둘 수도 있습니다.

자세한 내용은 이슈 관리를 참조하세요.

알림이 수신되지 않음

알림 채널을 구성하면 이슈가 발생할 때 알림을 받을 것으로 기대하지만, 알림을 받지 못한 경우입니다.

웹훅 및 Pub/Sub 알림 관련 문제를 해결하는 방법은 이 문서의 다음 섹션을 참조하세요.

실패의 원인에 대한 정보를 수집하려면 다음을 수행합니다.

  1. Google Cloud 콘솔의 탐색 패널에서 Logging을 선택한 후 로그 탐색기를 선택합니다.

    로그 탐색기로 이동

  2. 적합한 Google Cloud 프로젝트를 선택합니다.

  3. 알림 채널 이벤트의 로그를 쿼리합니다.

    1. 로그 이름 메뉴를 확장하고 notification_channel_events를 선택합니다.
    2. 심각도 메뉴를 확장하고 오류를 선택합니다.
    3. 선택사항: 커스텀 시간 범위를 선택하려면 시간 범위 선택기를 사용합니다.
    4. 쿼리 실행을 클릭합니다.

    이전 단계에서는 다음 쿼리를 만듭니다.

    logName="projects/PROJECT_ID/logs/monitoring.googleapis.com%2Fnotification_channel_events"
severity=ERROR

    실패 정보는 일반적으로 요약 줄 및 jsonPayload 필드에 포함됩니다.

    요약 줄과 jsonPayload 필드에는 일반적으로 실패 정보가 포함됩니다. 예를 들어 게이트웨이 오류가 발생하면 요약 줄에 '502 잘못된 게이트웨이로 인한 실패'가 포함됩니다.

측정항목 정의 변경 후 새 데이터 없음

예를 들어 로그 기반 측정항목에서 사용한 필터를 수정하여 사용자 정의 측정항목의 정의를 변경할 때 알림 정책에 측정항목 정의의 변경사항이 반영되지 않습니다.

이 문제를 해결하려면 정책의 표시 이름을 수정하여 알림 정책을 강제로 업데이트하세요.

Google Chat으로 전송된 웹훅 알림이 수신되지 않음

Monitoring에서 웹훅 알림 채널을 구성한 다음 Google Chat으로 전송하도록 웹훅을 구성합니다. 그러나 알림이 수신되지 않거나 400 Bad Request 오류가 발생합니다.

이 문제를 해결하려면 Monitoring에서 Pub/Sub 알림 채널을 구성한 다음 Pub/Sub 메시지를 Chat에서 예상하는 형식으로 변환한 후 알림을 Google Chat에 전송하도록 Cloud Run 서비스를 구성합니다. 이러한 구성의 예시는 Cloud Monitoring 및 Cloud Run을 사용하여 커스텀 알림 만들기를 참조하세요.

웹훅 알림이 수신되지 않음

웹훅 알림 채널을 구성하여 이슈가 발생하면 알림을 받게 되지만, 알림을 받지 못한 경우입니다.

비공개 엔드포인트

엔드포인트가 공개 상태가 아니면 알림용 웹훅을 사용할 수 없습니다.

이 문제를 해결하려면 해당 알림 주제에 대한 가져오기 구독과 함께 Pub/Sub 알림을 사용합니다.

Pub/Sub 알림 채널을 구성하면 Identity and Access Management가 포함된 Pub/Sub 큐로 이슈 알림이 전송됩니다. Pub/Sub 주제를 쿼리하거나 리슨할 수 있는 모든 서비스에서 이러한 알림을 사용할 수 있습니다. 예를 들어 App Engine, Cloud Run 또는 Compute Engine 가상 머신에서 실행되는 애플리케이션에서 이러한 알림을 사용할 수 있습니다.

가져오기 구독을 사용하는 경우 요청이 메시지가 도착하기를 기다리는 Google에 전송됩니다. 이러한 구독에는 Google에 대한 액세스 권한이 필요하지만 방화벽이나 인바운드 액세스에 대한 규칙은 필요하지 않습니다.

공개 엔드포인트

전송이 실패한 이유를 확인하려면 Cloud Logging 로그 항목을 검사하여 실패 정보를 확인합니다.

예를 들어 다음과 같이 필터와 함께 로그 탐색기를 사용해서 로그 항목에서 알림 채널 리소스를 검색할 수 있습니다.

resource.type="stackdriver_notification_channel"

Pub/Sub 알림이 수신되지 않음

Pub/Sub 알림 채널을 구성하지만 알림이 수신되지 않습니다.

이 조건을 해결하려면 다음을 시도해 보세요.

  • 알림 서비스 계정이 있는지 확인합니다. 서비스 계정이 삭제되었으면 알림이 전송되지 않습니다.

    서비스 계정이 있는지 확인하려면 다음을 수행합니다.

    1. Google Cloud 콘솔의 탐색 패널에서 IAM을 선택합니다.

      IAM으로 이동합니다.

    2. 다음 이름 지정 규칙이 사용된 서비스 계정을 검색합니다.

      service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com

      이 서비스 계정이 나열되지 않았으면 Google 제공 역할 부여 포함을 선택합니다.

    알림 서비스 계정이 없으면 Monitoring에서 서비스 계정을 만들기 위해 Pub/Sub 알림 채널 만들기 프로세스를 시작해야 합니다.

    1. Google Cloud 콘솔의 탐색 패널에서 Monitoring을 선택한 후  알림을 선택합니다.

      알림으로 이동

    2. 알림 채널 수정을 클릭합니다.

    3. Pub/Sub 섹션에서 새로 추가를 클릭합니다.

      Monitoring은 알림 서비스 계정이 없으면 알림 서비스 계정을 만듭니다. Pub/Sub 채널 만들기 대화상자에 알림 서비스 계정의 이름이 표시됩니다.

    4. 알림 채널을 추가하지 않으려면 취소를 클릭합니다. 그렇지 않으면 알림 채널 만들기를 완료하고 채널 추가를 클릭합니다.

    5. 서비스 계정에 Pub/Sub 주제를 게시하도록 권한을 부여합니다.

      1. 새 브라우저 탭에서 알림 채널 만들기 문서를 엽니다.
      2. Pub/Sub 탭을 선택한 후 페이지의 서비스 계정 승인 섹션의 단계를 따릅니다.

  • 알림 서비스 계정이 원하는 Pub/Sub 주제에 대해 알림을 전송하도록 승인되었는지 확인합니다.

    서비스 계정의 권한을 보려면 Google Cloud 콘솔 또는 Google Cloud CLI 명령어를 사용하면 됩니다.

    • Google Cloud 콘솔의 IAM 페이지에는 각 서비스 계정에 대한 역할이 표시됩니다.
    • Google Cloud 콘솔의 Pub/Sub 주제 페이지에는 각 주제가 표시됩니다. 주제를 선택하면 권한 탭에 서비스 계정에 부여된 역할이 표시됩니다.

    • 모든 서비스 계정과 해당 역할을 표시하려면 다음 Google Cloud CLI 명령어를 실행합니다.

      gcloud projects get-iam-policy PROJECT_ID

      다음은 이 명령어에 대한 부분 응답입니다.

          serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
       role: roles/monitoring.notificationServiceAgent
     - members:
       [...]
       role: roles/owner
     - members:
       - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
       role: roles/pubsub.publisher

      명령어 응답은 역할만 포함하고, 주제별 승인을 포함하지 않습니다.

    • 특정 주제에 대한 IAM binding을 나열하려면 다음 명령어를 실행합니다.

      gcloud pubsub topics get-iam-policy TOPIC

      다음은 이 명령어의 샘플 응답입니다.

          bindings:
    - members:
      - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
      role: roles/pubsub.publisher
    etag: BwXPRb5WDPI=
    version: 1

    알림 서비스 계정을 승인하는 방법은 서비스 계정 승인을 참조하세요.