MQL 알림 정책 권장사항

이 페이지에는 Monitoring Query Language(MQL) 기반 조건을 사용하는 알림 정책에 대한 권장사항 색인이 포함되어 있습니다. 여기에서 수집한 정보를 활용하여 MQL 기반 조건으로 알림 정책을 구성할 때 유의할 점을 빠르게 참조할 수 있습니다.

이 페이지에서는 알림 정책에서 MQL 쿼리를 사용하는 방법에 대한 기본 사항을 설명하지 않습니다. 신규 사용자인 경우 MQL을 사용한 알림 정책을 참조하세요.

알림 정책 평가에는 여러 내부 서비스가 포함됩니다. 이러한 서비스가 MQL과 상호작용하는 방식으로 인해 다른 작업 대신 특정 MQL 작업을 사용하는 것이 좋습니다. 예를 들어 delta_gauge 대신 delta를 사용하면 알림이 잘못된 시간에 트리거될 수 있습니다.

다음 표에서는 피해야 할 작업 목록과 대신 사용할 권장 작업을 보여줍니다.

피해야 할 일 권장
adjacent_rate rate
adjacent_delta delta_gauge
delta delta_gauge
window sliding

알림 정책에 every 30s 문 사용

알림 정책은 30초마다 조건을 평가합니다. 이 시간 범위를 출력 기간이라고 합니다. 이 기간을 시각적으로 알리도록 조건에 명시적인 every 30s 작업을 포함하는 것이 좋습니다.

예를 들어 다음 알림 정책 MQL 쿼리에는 명시적 every 30s 문이 포함되어 있습니다.

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by sliding(1h)
| every 30s

every 작업에 다른 값을 사용하는 MQL 쿼리로 알림 정책을 저장하면 Cloud Monitoring은 알림 정책이 활성 상태일 때 30초 값을 계속 사용합니다. 예를 들어 다음 쿼리를 사용하는 알림 정책의 출력 기간은 여전히 30초입니다.

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by sliding(1h)
| every 90s

쿼리 효율성 개선

대용량 데이터를 처리할 때는 쿼리가 느리게 실행됩니다. 쿼리 효율성을 개선하려면 쿼리에서 처리하는 데이터의 양을 줄일 수 있습니다. 다음 섹션에서는 쿼리가 평가하는 데이터 볼륨을 줄이기 위한 몇 가지 옵션을 제공합니다.

쿼리 앞부분에 필터 배치

쿼리 초기에 필터를 배치하면 쿼리가 데이터에 대한 작업을 실행하기 전에 불필요한 데이터를 필터링할 수 있습니다. 예를 들어, 다음 쿼리를 살펴보겠습니다.

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| group_by [resource.zone], .sum
| filter zone = 'us-west1-b'
| condition val() > 5'GBy'

filter 작업을 group_by 작업 앞으로 이동하면 쿼리가 더 빠르게 실행될 수 있습니다.

fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count
| filter zone = 'us-west1-b'
| group_by [resource.zone], .sum
| condition val() > 5'GBy'

쿼리 정렬 기간 줄이기

쿼리에 align 작업이 사용될 때 더 작은 정렬 기간은 Cloud Monitoring이 시계열의 각 지점에 대해 평가하는 더 작은 시간 범위를 나타냅니다. 따라서 align 작업의 값을 줄여 쿼리 효율성을 개선할 수 있습니다. 예를 들어 다음 쿼리의 정렬 기간은 2시간입니다.

fetch gce_instance :: compute.googleapis.com/instance/disk/read_bytes_count
| group_by window(1h), .sum
| align next_older(2h)
| every 30s
| condition val() > 2'GBy'

그러나 1시간 기간의 데이터만 확인해야 하는 경우 정렬 기간을 1시간으로 줄일 수 있습니다.

fetch gce_instance :: compute.googleapis.com/instance/disk/read_bytes_count
| group_by window(1h), .sum
| align next_older(1h)
| every 30s
| condition val() > 2'GBy'

자세한 내용은 정렬을 참조하세요.

알림 정책 기간 단축

알림 정책 기간은 알림이 전송되기 전에 각 측정이 조건을 위반해야 하는 기간을 나타냅니다. 쿼리 정렬 기간을 늘리지 않고 알림 정책의 기간을 줄이면 Cloud Monitoring에서 알림 정책 조건에 대해 평가할 지점이 줄어듭니다.

자세한 내용은 기간을 참조하세요.

null 메타데이터에 기본값 할당

메타데이터 값이 null이면 쿼리에서 예기치 않은 결과가 생성될 수 있습니다. or_else 함수를 사용하여 null 값이 있을 메타데이터에 기본값을 할당하면 예기치 않은 결과를 방지할 수 있습니다.

예를 들어 모든 데이터를 함께 집계하는 쿼리를 실행합니다.

fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count
| group_by [], 24h, sum(egress_bytes_count)
| condition val() > 10'MBy'

10MBy의 결과를 생성합니다. 다음으로 쿼리를 실행하여 10MBy가 노드 영역 간에 어떻게 분산되는지 확인합니다.

fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count
| group_by [metadata.system.node_zone], 24h, sum(egress_bytes_count)
| condition val() > 10'MBy'

분산 쿼리는 다음 결과를 반환합니다.

node_zone egress_byte_count
us-central1-f 7.3MBy
us-west1-b 2.5MBy

이러한 결과는 예상한 10MBy가 아닌 총 9.8MBy를 표시합니다. 이 불일치는 다음 데이터 세트와 같이 집계된 메타데이터 라벨 중 하나에 null 값이 포함된 경우에 발생할 수 있습니다.

값 메타데이터 값
7.3MBy us-central1-f
2.5MBy us-west1-b
0.2MBy

null 메타데이터 문제를 방지하려면 or_else 작업으로 메타데이터 참조를 래핑하면 됩니다. 그러면 메타데이터 열에 값이 없는 경우 기본값을 지정할 수 있습니다. 예를 들어 다음 쿼리는 or_else를 사용하여 값이 없는 메타데이터 열에 no zone의 메타데이터 값을 설정합니다.

fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count
| group_by [or_else(metadata.system.node_zone, 'no zone')], 24h, sum(egress_bytes_count)
| condition val() > 10'MBy'

이 새 쿼리는 합계가 10MBy인 다음 결과를 생성합니다.

node_zone egress_byte_count
us-central1-f 7.3MBy
us-west1-b 2.5MBy
영역 없음 0.2MBy