이 페이지에서는 모니터링 쿼리 언어(MQL) 기반 조건을 사용하는 알림 정책이 의도한 것과 다르게 동작하는 이유를 설명하고 이러한 상황에서 가능한 해결 방법을 알려줍니다.
데이터 격차
MQL 기반 조건을 사용하여 알림 정책을 만들었는데 MQL 쿼리 결과로 보고된 데이터에 예상치 않은 격차가 있다고 가정해 보세요.
정렬된 데이터에서 계산에 따라 특정 타임스탬프에 null 값이 산출될 때 이러한 격차가 발생할 수 있습니다. 예를 들어 다음 데이터 테이블은 30초 기간의 쿼리와 관련됩니다.
테이블 A1
| 타임스탬프 | 값 |
|---|---|
| 00:00:00 | 1 |
| 00:00:30 | 2 |
| 00:01:30 | 3 |
| 00:02:00 | 4 |
기간이 30초이므로 00:01:00의 타임스탬프가 표시될 것으로 예상할 수 있습니다. 이러한 격차는 여러 이유로 발생할 수 있습니다.
정렬로 인한 격차
정렬 기간이 너무 좁으면 데이터 격차가 발생할 수 있습니다. 예를 들어 다음과 같이 정렬되지 않은 원시 측정항목 데이터 테이블은 약 30초 간격으로 작성됩니다.
테이블 B1
| 타임스탬프 | 값 |
|---|---|
| 00:00:01 | 1 |
| 00:00:28 | 2 |
| 00:01:01 | 3 |
| 00:01:32 | 4 |
next_older(30s) 작업을 사용해서 데이터를 정렬하도록 00:02:00에 쿼리를 실행하면 00:01:00에 데이터 격차가 있는 다음 출력이 수신됩니다.
테이블 B2
| 타임스탬프 | 값 |
|---|---|
| 00:00:30 | 2 |
| 00:00:28 | 3 |
| 00:01:01 | 4 |
이러한 데이터 격차는 원시 데이터의 어떤 지점도 00:01:00에 종료되는 30초 기간에 포함되지 않기 때문에 발생합니다. 이러한 격차를 방지하려면 더 큰 기간을 사용합니다.
예를 들어 next_older(1m) 작업은 데이터 격차가 없는 테이블을 생성합니다.
테이블 B3
| 타임스탬프 | 값 |
|---|---|
| 00:00:01 | 1 |
| 00:00:28 | 2 |
| 00:01:01 | 3 |
| 00:01:32 | 4 |
일반적으로 데이터가 S초 간격으로 작성될 경우 S보다 긴 정렬 기간을 사용합니다. 이렇게 하면 시간 경과에 따라 균일하지 않은 데이터 포인트 분포를 처리할 수 있습니다.
테이블 작업으로 인한 격차
일부 테이블 작업은 예상치 않은 격차를 생성할 수 있습니다. 예를 들어 join 작업은 모든 입력 테이블에 값이 있는 타임스탬프에서만 출력을 생성합니다.
join과 같은 테이블 작업은 격차를 발생시킬 수 있습니다. 예를 들어 다음 2개의 정렬된 테이블을 조인합니다.
테이블 C1
| 타임스탬프 | 값 |
|---|---|
| 00:00:30 | 2 |
| 00:01:30 | 3 |
| 00:02:00 | 4 |
테이블 C2
| 타임스탬프 | 값 |
|---|---|
| 00:00:30 | 4 |
| 00:01:00 | 3 |
| 00:01:30 | 2 |
| 00:02:00 | 1 |
그러면 다음 출력이 수신됩니다.
테이블 C3
| 타임스탬프 | 값 A | 값 B |
|---|---|---|
| 00:00:30 | 1 | 4 |
| 00:01:30 | 2 | 2 |
| 00:02:00 | 3 | 1 |
테이블 C1의 00:01:00에 값이 없기 때문에 이 테이블에는 00:01:00에 값이 없습니다.
누락된 값으로 인한 격차
일부 함수는 출력을 전환할 수 없거나 출력이 정의되지 않은 경우에 격차를 발생시킵니다. 예를 들어 다음과 같은 문자열 값 테이블에 value.string_to_int64를 적용합니다.
테이블 D1
| 타임스탬프 | 값 |
|---|---|
| 00:00:30 | '4' |
| 00:01:00 | '3' |
| 00:01:30 | 'init' |
| 00:02:00 | '1' |
MQL이 'init'를 정수로 변환할 수 없기 때문에 결과 테이블에 00:01:30의 격차가 포함됩니다.
테이블 D2
| 타임스탬프 | 값 |
|---|---|
| 00:00:30 | 4 |
| 00:01:00 | 3 |
| 00:01:30 | null |
| 00:02:00 | 1 |
잘못되었거나 누락된 값으로 인한 데이터 격차를 방지하기 위해서는 이러한 값을 처리하기 위해 has_value 또는 or_else 함수를 사용합니다.
has_value는 인수가 null로 평가될 때 false를 반환합니다. 그렇지 않으면 true를 반환합니다. 예를 들어 테이블 D2에 value has_value(1 / val())을 적용할 경우에는 결과에 격차가 포함되지 않습니다.
테이블 D3
| 타임스탬프 | 값 |
|---|---|
| 00:00:30 | true |
| 00:01:00 | true |
| 00:01:30 | false |
| 00:02:00 | true |
기준점 알림은 MQL 차트에 기준점이 초과되지 않은 것으로 표시되었을 때 발생합니다.
가상 머신(VM)에서 CPU 사용률 변동폭이 큰 경우 알림을 받을 수 있도록 compute.googleapis.com/instance/cpu/utilization 측정항목을 모니터링하는 알림 정책을 만듭니다. 6시간마다 CPU 사용률이 기준점인 50%보다 높을 때 이슈를 생성하도록 조건을 만들고 구성합니다. 조건에서 다음 쿼리를 사용합니다.
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge(6h) | condition val() > 0.5
30초 후 알림이 수신됩니다. 하지만 MQL 차트에는 사용률 델타 값이 기준점보다 높지 않은 것으로 표시됩니다.
알림 정책의 출력 기간은 30초입니다. 기간을 정의하지 않거나 쿼리에 다른 기간을 정의해도 이 기간은 덮어쓰지 않습니다. 예를 들어 다음 쿼리에는 30초 출력 기간이 계속 사용됩니다.
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge(6h) # period not 30 seconds | condition val() > 0.5
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge() # undefined period | condition val() > 0.5
측정항목 기준점이 처음 30초 평가 시에 초과되었으므로 Cloud Monitoring에서 알림이 전송되었습니다. 이 문제를 방지하기 위해서는 쿼리 끝에 | every 30s를 추가하여 출력 기간에 의도한 결과가 생성되는지 확인합니다. 예를 들면 다음과 같습니다.
fetch gce_instance | metric 'compute.googleapis.com/instance/cpu/utilization' | group_by 5m, [value_utilization_mean: mean(value.utilization)] | align delta_gauge() | every 30s # explicit 30 second output window | condition val() > 0.5
오류: 알림 정책을 저장할 수 없습니다. 요청에 잘못된 인수가 포함되어 있습니다.
MQL 기반 조건으로 알림 정책을 만들었습니다. 알림 정책을 저장하면 다음 오류 메시지가 표시됩니다.
Error: Unable to save alerting policy. Request contains an invalid argument.
group_by와 같은 일부 MQL 테이블 작업은 입력이 정렬되어 있어야 합니다. 쿼리가 해당 입력을 정렬하지 않으면 MQL이 데이터를 자동으로 정렬합니다. 하지만 이러한 자동 정렬은 경우에 따라 잘못된 인수를 발생시킵니다.
이 문제를 방지하기 위해 쿼리에 테이블 작업이 사용될 경우 쿼리에 데이터 정렬이 포함되는지 확인합니다. 데이터 정렬 함수 목록은 MQL 참고 문서에서 정렬 섹션을 참조하세요.
기준점 선이 MQL 차트에 표시되지 않음
MQL 기반 조건을 사용하여 측정항목 기준점 알림 정책을 만들었습니다. 하지만 기준점 선이 MQL 차트에 표시되지 않습니다.
Cloud Monitoring은 하나는 열이고 다른 하나는 리터럴인 두 값을 비교하는 불리언 표현식이 쿼리에 포함된 경우에만 기준점 선을 표시합니다. 예를 들어 다음 표현식은 기준점 선을 차트로 표시합니다.
val() > 5'GBy'
하지만 다음 표현식은 기준점 선을 차트로 표시하지 않습니다.
val(0) > val(1) #one of the values must be a literal
5 > 4 #one of the values must be a column
val() #the expression must be a comparison