모니터 산술 연산과 희소 메트릭
모니터 산술 연산과 희소 메트릭 (Monitor Arithmetic and Sparse Metrics)
산술 연산이 포함된 쿼리를 기반으로 경보를 만드는 것은 흔한 관행이에요. 의도한 대로 이러한 쿼리를 평가하기 위해 모니터 설정이 적절한지 확인하려면 고려해야 할 몇 가지 도구와 동작이 있어요.
출처: 문서
본문
희소 메트릭 (Sparse metrics)
분모에 희소(sparse) 메트릭이나 0 메트릭이 있는 경우 일부 결과가 거부될 수 있어요.
다음 메트릭 값을 고려해볼게요:
A = (10, 10, 10)B = (0, 1, -)
a/b 공식에 대해 모니터는 다음과 같이 평가해요:
10/0 + 10/1 + 10/NaN = 10
평가 창에 "null" 버킷이 많이 포함되면(10/NaN + 10/Nan + … + 10/Nan) 평가가 "건너뛰어지므로(skipped)", 메트릭을 조정하거나 아래 해결 방법 중 하나를 사용해야 할 수 있어요.
희소 및 정렬이 안 된 메트릭을 위한 해결 방법 (Workarounds for sparse and misaligned metrics)
.fill()
모든 시간 버킷에 유효한 값이 있도록 .fill() 함수를 적용할 수 있어요. gauge 메트릭 유형의 경우 기본 보간(interpolation)은 5분 동안 선형(linear), 즉 .fill(linear)이에요. count 및 rate 유형 메트릭의 경우 기본값은 .fill(null)이며, 이는 보간을 비활성화해요. Datadog는 일반적으로 모니터에서 count/rate 메트릭에 보간을 사용하는 것을 권장하지 않아요.
원본(Original): sum:my_metric.has_gaps.gauge{env:a} by {timer,env}
| Timestamp | timer:norm,env:a | timer:offset,env:a |
|:--------------------|:-----------------|:-------------------|
| 2019-03-29 12:00:00 | 1 | |
| 2019-03-29 12:05:00 | | 1 |
| 2019-03-29 12:10:00 | 0 | |
| 2019-03-29 12:15:00 | | 1 |
| 2019-03-29 12:20:00 | 1 | |
| 2019-03-29 12:25:00 | | 1 |
| 2019-03-29 12:30:00 | 1 | |
my_metric.has_gaps.gauge가 메트릭 유형 gauge라고 가정하면 기본적으로 5분 동안 선형 보간이 적용되지만, 메트릭은 10분마다 한 번씩 보고돼요. 이 쿼리를 생각해볼게요:
sum(last_30m):sum:my_metric.has_gaps.gauge{timer:norm,env:a} / sum:my_metric.has_gaps.gauge{timer:offset,env:a}
주로 "건너뛰어진(skipped)" 평가를 보게 될 거예요.
| 경로 (Path) | 평가 (Evaluation) | 결과 (Result) |
|---|---|---|
classic_eval_path |
1/Nan + Nan/1 + … + 1/Nan + Nan/1 | N/A |
보간을 조정하면 모든 시간 간격에 메트릭이 있도록 보장할 수 있어요.
수정됨(Modified): sum:my_metric.has_gaps.gauge{env:a} by {timer,env}.fill(last,900)
| Timestamp | timer:norm,env:a | timer:offset,env:a |
|:--------------------|:-----------------|:-------------------|
| 2019-03-29 12:00:00 | 1 | (1) |
| 2019-03-29 12:05:00 | 1 | 1 |
| 2019-03-29 12:10:00 | 0 | 1 |
| 2019-03-29 12:15:00 | 0 | 1 |
| 2019-03-29 12:20:00 | 1 | 1 |
| 2019-03-29 12:25:00 | 1 | 1 |
| 2019-03-29 12:30:00 | 1 | 1 |
수정된 쿼리:
sum(last_30m):sum:my_metric.has_gaps.gauge{timer:norm,env:a}.fill(last,900) / sum:my_metric.has_gaps.gauge{timer:offset,env:a}.fill(last,900)
.fill(last,900)을 사용하면 새 결과는:
| 경로 (Path) | 평가 (Evaluation) | 결과 (Result) |
|---|---|---|
classic_eval_path |
(1)/1 + 1/1 + 0/1 + 0/1 + 1/1 + 1/1 + 1/1 | 5 |
짧은 평가 창 (Short evaluation windows)
짧은 평가 창에서 나눗셈이 있는 모니터는 타이밍 문제가 발생할 수 있어요. 모니터 쿼리가 1분 평가 창에서 나눗셈을 필요로 한다면, 분자와 분모는 몇 초 단위의 시간 버킷을 나타내요. 쿼리 시점에 분자와 분모 메트릭이 모두 없으면 원하지 않는 평가 값이 나올 수 있어요.
| Timestamp | sum:my_num{*} | sum:my_denom{*} |
| :-------------------- | :------------------ | :------------------ |
| ... | ... | ... |
| 2019-03-29 13:30:50 | 900 | 1000 |
| 2019-03-29 13:30:52 | 900 | 1000 |
| 2019-03-29 13:30:54 | 900 | 1000 |
| 2019-03-29 13:30:56 | 120 (inc) | 850 (inc) |
min(last_1m):sum:my_num{*}/sum:my_denom{*} 같은 쿼리의 경우 최소값이 왜곡될 수 있고 모니터가 의도치 않게 트리거될 수 있어요.
따라서 짧은 평가 창에서 나눗셈이 있는 쿼리에는 타이밍 문제를 조정하기 위해 30~60초의 짧은 평가 지연(evaluation delay)을 추가하는 것을 고려해야 해요. 또는 5분 평가 창으로 바꾸는 것도 도움이 될 수 있어요.
이 로직에 대해 궁금한 점이 있다면 Datadog 지원 팀에 문의해요.