알림 정책 문제 해결

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

기간 선택에 따라 알림 정책에 영향을 줄 수 있는 변수에 대한 자세한 내용은 알림 동작을 참조하세요.

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

알림 정책을 만들어 시스템에 있는 디스크의 '사용된' 용량을 모니터링했습니다. 이 정책은 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의 시계열을 필터링하도록 디스크 사용률 알림 정책을 구성해야 합니다.

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

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

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

이 문제를 해결하려면 업타임 체크를 모니터링하는 알림 정책을 만듭니다. 업타임 체크를 만들려면 VM에 외부 IP 주소가 있어야 합니다.

VM에 외부 IP 주소가 없으면 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에서 사용할 수 있는 표현적인 텍스트 기반 언어입니다. Cloud Console을 사용할 때 MQL을 사용하여 조건을 구성하려면 쿼리 편집기를 선택해야 합니다.

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

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

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

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

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

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

이슈가 생성되기 전에 여러 측정이 필요하도록 하려면 조건의 기간 필드가 측정항목의 샘플링 레이트의 두 배를 초과하는지 확인합니다. 예를 들어 측정항목이 60초마다 샘플링되는 경우 기간을 3분 이상으로 설정합니다. 기간 필드를 최근 값 또는 0초로 설정하면 단일 측정으로 이슈가 생성될 수 있습니다.

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

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

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

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

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

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

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

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

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

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

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

Unable to close incident with active conditions.

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

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

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

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

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

웹훅 알림 실패

웹훅 알림을 구성하여 이슈가 발생하면 알림을 받게 되지만, 알림이 수신되지 않습니다.

비공개 엔드포인트

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

이 문제를 해결하려면 해당 알림 주제에 대한 가져오기 구독과 함께 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"