알림 정책 문제 해결

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

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

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

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

알림 정책을 만들어 시스템에 있는 디스크의 '사용된' 용량을 모니터링했습니다. 이 정책은 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 Console에서 사용할 수 있는 표현적인 텍스트 기반 언어입니다. Google Cloud Console을 사용할 때 MQL을 사용하여 조건을 구성하려면 쿼리 편집기를 선택해야 합니다.

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

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

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

  • 특히 측정항목 부재 또는 '~미만' 임계치 조건의 알림 정책에서 데이터에 격차가 있는 경우 비정상적으로 보이는 이슈가 생성될 수 있습니다. 데이터에 격차가 있는지 확인하는 것이 쉽지 않을 수 있습니다. 격차가 모호할 때도 있고 때로는 자동으로 교정되기도 하기 때문입니다.

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

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

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

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

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

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

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

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

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

알림 정책에 논리 AND로 결합된 여러 조건이 포함된 경우 정책이 트리거되면 조건이 충족되는 각 시계열에 대해 정책이 알림을 전송하고 이슈를 생성합니다. 예를 들어 조건이 2개인 정책이 있고 각 조건이 하나의 시계열을 모니터링하는 경우 2개의 이슈가 열리고 2개의 알림이 수신됩니다.

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

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

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

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

이 문제를 해결하려면 Identity and Access Management(IAM) 역할이 roles/monitoring.viewer이거나 해당 역할의 모든 권한이 포함된 역할이어야 합니다. 예를 들어 roles/monitoring.editorroles/monitoring.admin에는 뷰어 역할의 모든 권한이 포함되어 있습니다.

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

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

알림이 수신되면 조건 요약에 알림이 생성된 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 Console에서 로그 탐색기 페이지로 이동합니다.

    로그 탐색기로 이동

  2. 적절한 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으로 전송되는 알림이 실패함

Cloud Monitoring에서 웹훅 알림 채널을 구성한 후 해당 웹훅으로 Google Chat을 구성합니다. 하지만 알림이 수신되지 않거나 400 Bad Request 오류가 발생합니다.

이 문제를 해결하려면 Cloud Monitoring에서 Pub/Sub 알림 채널을 구성한 후 Pub/Sub 메시지를 처리하고 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 Console에서 IAM 페이지로 이동합니다.

      IAM으로 이동

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

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

      이 서비스 계정이 나열되지 않았으면 다음 스크린샷에 표시된 것처럼 Google 제공 역할 부여 포함을 선택합니다.

      Google 제공 역할 부여 포함 옵션을 선택합니다.

    알림 서비스 계정을 만들려면 다음을 수행합니다.

    1. Google Cloud Console에서 Monitoring을 선택합니다.

      Monitoring으로 이동

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

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

      생성된 Pub/Sub 채널 대화상자에 Monitoring에서 만든 서비스 계정 이름이 표시됩니다.

    4. 취소를 클릭합니다.

    5. 서비스 계정 승인에 설명된 대로 Pub/Sub 주제를 게시하도록 서비스 계정에 권한을 부여합니다.

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

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

    • Google Cloud Console의 IAM 페이지에는 각 서비스 계정에 대한 역할이 표시됩니다.
    • Google Cloud Console의 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
      

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