이 페이지에서는 일부 알림 정책이 의도와 다르게 동작할 수 있는 이유를 설명하고 이러한 상황이 발생했을 때의 가능한 해결 방법을 제공합니다.
재테스트 기간 선택에 따라 알림 정책에 영향을 미칠 수 있는 변수는 측정항목 기반 알림 정책의 동작을 참조하세요.
디스크 사용률 정책이 예기치 않은 이슈 생성
알림 정책을 만들어 시스템에 있는 디스크의 '사용된' 용량을 모니터링했습니다. 이 정책은 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.* 필터를 추가할 수 있습니다.
비정상적인 이슈의 흔한 원인
알림 정책을 만들었는데 정책이 이슈를 너무 이르게, 또는 부정확하게 일으키는 것으로 보인다고 생각해 봅시다.
잘못된 이슈 알림을 받을 수 있는 이유는 다양합니다.
특히 측정항목 부재 또는 '~미만' 기준점 조건의 알림 정책에서 데이터에 격차가 있는 경우 비정상적으로 보이는 이슈가 생성될 수 있습니다. 사고에서 데이터 공백이 드러나지 않는 경우도 있고, 데이터 공백이 자동으로 수정되는 경우가 있습니다.
예를 들어 차트에서는 누락된 데이터의 값이 보간되어 공백이 가려질 수 있습니다. 몇 분의 데이터가 누락되더라도 차트에서는 시각적 연속성을 위해 누락된 지점을 연결합니다. 기본 데이터의 이러한 간격은 알림 정책이 이슈를 생성하기에 충분할 수 있습니다.
로그 기반 측정항목의 경우 과거 10분까지는 늦게 도착한 요소를 다시 채울 수 있습니다. 백필 동작은 격차를 효과적으로 교정하며, 마침내 데이터가 도착했을 때 간격을 메웁니다. 따라서 더 이상 보이지 않는 로그 기반 측정항목의 격차 때문에 알림 정책이 이슈를 일으키는 원인이었을 가능성이 있습니다.
측정항목 부재 및 '다음 미만' 기준점 조건은 실시간으로 평가되어 쿼리 지연이 적습니다. 평가 시점과 Monitoring 콘솔에 해당 이슈가 표시되는 시점 사이에 조건 상태가 변경될 수 있습니다.
단일 측정에서 이슈를 만들도록 구성된 조건으로 인해 이슈가 조기에 또는 잘못되어 표시될 수 있습니다. 이러한 상황을 방지하려면 조건의 재테스트 기간을 측정항목의 샘플링 레이트보다 두 배가 초과하도록 설정하여 이슈를 만들기 전에 여러 번 측정해야 합니다.
예를 들어 측정항목이 60초마다 샘플링되는 경우 재테스트 기간을 3분 이상으로 설정합니다. 재테스트 기간을 최근 값 또는 0초로 설정하면 단일 측정으로 이슈가 생성될 수 있습니다.
알림 정책 조건을 수정하면 알림 인프라에 변경사항이 전파될 때까지 몇 분 정도 걸릴 수 있습니다. 이 기간 중에는 원래 알림 정책 조건을 충족한 이슈 알림이 수신될 수 있습니다.
시계열 데이터가 도착할 때는 전체 알림 인프라에 데이터가 전파될 때까지 최대 1분이 소요될 수 있습니다. 이 과정에서 알림 정책은 시계열 데이터가 시계열 차트에 전파되지 않았더라도 조건을 충족하는 것으로 평가할 수 있습니다. 따라서 차트에 조건이 충족되었다고 표시되지 않더라도 알림이 수신될 수 있습니다. 이러한 상황이 발생하지 않도록 하려면 정렬 기간을 최소 5분 이상으로 사용하세요.
데이터 수신이 중지될 때 이슈가 닫히지 않음
부분 측정항목 데이터의 안내에 따라 데이터 수신이 중지되면 이슈를 종료하도록 알림 정책을 구성합니다. 경우에 따라 데이터 수신이 중지되지만 열린 이슈가 자동으로 닫히지 않습니다.
알림 정책에 의해 모니터링되는 기본 리소스에 metadata.system_labels.state 라벨이 포함되어 있고 해당 정책이 모니터링 쿼리 언어로 작성되지 않은 경우 Monitoring에서 리소스의 상태를 확인할 수 있습니다. 리소스 상태가 사용 중지된 것으로 알려져 있으면 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에서 이슈를 자동으로 종료하도록 둘 수도 있습니다.
자세한 내용은 이슈 관리를 참조하세요.
다중 조건 정책이 여러 개의 알림 생성
여러 조건이 포함된 알림 정책을 만들고 해당 조건을 논리적 AND와 결합했습니다. 모든 조건이 충족되면 알림 하나와 이슈 하나가 발생합니다. 그러나 여러 알림이 수신되고 여러 이슈가 생성되는 것을 확인할 수 있습니다.
Monitoring은 알림을 보내고 조건을 충족시키는 각 시계열에 대한 이슈를 만듭니다. 따라서 여러 조건이 포함된 알림 정책이 있는 경우 결합된 조건이 충족되는 각 시계열에 대해 잠재적으로 하나의 알림 및 이슈가 수신될 수 있습니다.
예를 들어 각 조건이 3개의 시계열을 모니터링하는 두 가지 조건을 가진 알림 정책이 있습니다. 정책은 두 조건이 모두 충족될 때만 알림을 전송합니다. 정책의 조건이 충족되면 2개(각 조건에서 1개의 시계열이 충족됨)에서 6개(각 조건에서 모든 시계열이 충족됨) 사이의 알림 및 이슈를 수신할 수 있습니다.
단일 이슈를 만들고 단일 알림을 보내도록 Monitoring을 구성할 수 없습니다.
자세한 내용은 이슈별 알림을 참조하세요.
측정항목 라벨에 대한 변수가 null임
알림 정책을 만들고 문서 섹션에 측정항목 라벨에 대한 변수를 추가합니다.
알림에 변수 값이 표시될 것으로 예상합니다. 하지만 값은 null로 설정됩니다.
이 문제를 해결하려면 다음을 시도합니다.
알림 정책에 대한 집계 설정에서 표시하려는 라벨을 보존해야 합니다.
예를 들어 VM 인스턴스에서 작성된 디스크 바이트를 모니터링하는 알림 정책을 만든다고 가정해 보겠습니다. 문서에 알림을 발생시키는 기기를 나열되도록 하려면 문서 필드에
device: ${metric.label.device}를 추가합니다.또한 집계 설정에서
device라벨의 값을 보존해야 합니다. 이 라벨을 유지하려면 집계 함수를none으로 설정하거나 그룹화 선택 항목에device가 포함되도록 합니다.변수의 문법과 적용 가능성을 확인합니다. 문법 정보는 사용자 정의 문서로 알림에 주석 추가를 참조하세요.
예를 들어
log.extracted_label.KEY변수는 로그 기반 알림 정책에만 지원됩니다. 이 변수는 알림 정책에서 측정항목(로그 기반 측정항목 포함)을 모니터링하는 경우 항상null로 렌더링됩니다.
측정항목 정의 변경 후 새 데이터 없음
예를 들어 로그 기반 측정항목에서 사용한 필터를 수정하여 사용자 정의 측정항목의 정의를 변경할 때 알림 정책에 측정항목 정의의 변경사항이 반영되지 않습니다.
이 문제를 해결하려면 정책의 표시 이름을 수정하여 알림 정책을 강제로 업데이트하세요.
측정항목 누락으로 인해 API에서 알림 정책 생성에 실패함
최근에 측정항목을 만든 후 Cloud Monitoring API에서 알림 정책을 만들려고 할 때 이 측정항목을 참조했습니다. 그러나 API 명령어가 실패하고 다음 오류가 표시됩니다.
Error 404: Cannot find metric(s) that match type = "METRIC_NAME". If a metric was created recently, it could take up to 10 minutes to become available. Please try again soon.
이 문제를 해결하려면 10분 이상 기다린 후 API 요청을 다시 제출하세요.