이상 징후 모니터

모든 것에 이상 징후 탐지를 사용해야 하나요?

아니요. 이상 징후 탐지는 예측 가능한 패턴을 가진 메트릭을 시각화하고 모니터링하는 데 도움이 됩니다. 예를 들어, my_site.page_views{*}는 사용자 트래픽에 의해 구동되며 시간과 요일에 따라 예측 가능하게 변화하므로 이상 징후 탐지에 매우 적합합니다.

참고: 이상 징후 탐지가 정확한 예측을 하려면 과거 데이터가 필요합니다. 몇 시간 또는 며칠 동안만 메트릭을 수집했다면 이상 징후 탐지는 유용하지 않습니다.

대시보드의 그룹에서 이상 징후 탐지를 사용할 수 없는 이유는 무엇인가요?

단일 그래프에 여러 개의 개별 시계열을 추가하면 스파게티화(Spaghettification)가 발생할 수 있으며 이상 징후 탐지 시각화를 추가하면 문제가 더 악화됩니다:

스파게티화

그러나 단일 그래프에 여러 계열을 한 번에 하나씩 추가하는 것은 가능합니다. 회색 밴드는 마우스 오버 시에만 표시됩니다.

이상 징후 다중 라인

과거의 이상 징후가 현재 예측에 영향을 미치나요?

basic을 제외한 모든 알고리즘은 광범위한 양의 과거 데이터를 사용하므로 대부분의 이상 징후에 강력합니다. 첫 번째 그래프에서 회색 밴드는 메트릭이 0으로 떨어진 후에도 약 400K를 유지합니다.

anomalous_history

두 번째 그래프는 하루 후의 동일한 메트릭을 보여줍니다. 밴드 계산에 전날을 사용하지만 이전에 발생한 이상 현상의 영향을 받지 않습니다.

no effect

확대하면 이상 징후가 “사라지는’” 이유는 무엇인가요?

다른 확대/축소 수준에서는 동일한 쿼리에 대해 다른 특성을 가진 시계열이 생성될 수 있습니다. 더 긴 시간 주기를 볼 때 각 점은 더 세분화된 여러 점의 집합을 나타냅니다. 따라서 이러한 집합적인 점은 더 세분화된 점에서 관찰되는 노이즈를 숨길 수 있습니다. 예를 들어, 한 주를 표시하는 차트는 10분만 표시하는 차트보다 더 매끄럽게(노이즈가 덜) 보입니다.

회색 밴드의 폭은 정확한 이상 징후 모니터링의 핵심입니다. 밴드는 일반적인 노이즈가 대부분 밴드 내부에 있고 비정상적으로 나타나지 않을 만큼 충분히 넓어야 합니다. 그러나 밴드가 일반 노이즈를 포함할 만큼 넓으면 특히 짧은 시간 창을 볼 때 일부 이상 현상을 숨길 만큼 넓을 수도 있습니다.

예를 들어, 메트릭 app.requests에 노이즈가 있지만 평균 값은 8로 일정합니다. 어느 날 9시부터 시작하여 10분간의 비정상적인 기간이 있으며, 이 기간 동안 메트릭의 평균 값은 10입니다. 아래 그래프는 하루를 기간으로 하는 계열을 보여 주며, 그래프의 각 점은 5분을 요약한 것입니다.

disappearing day

여기서 회색 밴드는 의미가 있습니다. 시계열의 노이즈를 포착할 수 있을 만큼 충분히 넓으면서도 9시의 이상값이 선명하게 드러날 만큼 좁습니다. 다음 차트는 10분의 이상값이 포함된 30분 시간대의 확대 보기를 보여 주며, 그래프의 각 점은 10초를 요약합니다.

disappearing half hour

8:50 - 9:00 및 9:10 - 9:20의 비정상 데이터가 밴드 안에 있기 때문에 밴드의 크기가 적당해 보입니다. 밴드가 더 좁아지면 정상 데이터가 비정상 데이터로 강조되기 시작합니다. 이 그래프의 밴드가 이전 그래프의 밴드보다 약 8배 더 넓다는 것을 알 수 있습니다. 9:000 - 9:10의 비정상적 기간은 나머지 시리즈와 다르게 보이지만 밴드를 벗어날 만큼 극단적이지는 않습니다.

일반적으로 확대할 때 이상 징후가 사라진다고 해서 이상 징후가 아닌 것은 아닙니다. 확대된 보기의 개별 지점이 단독으로 이상 징후는 아니지만, 함께 발생하는 약간 특이한 점이 여러 개 함께 발생하는 것은 비정상입니다.

일부 함수를 이상 징후 탐지와 결합하려고 할 때 쿼리 구문 분석 오류가 발생하는 이유는 무엇인가요?

일부 함수는 anomalies() 함수에 대한 호출 내부에 내포되지 않을 수 있습니다. 특히, 이상 징후 탐지 모니터 또는 대시보드 쿼리에 다음 함수를 포함하지 않을 수 있습니다.: cumsum(), integral(), outliers(), piecewise_constant(), robust_trend() 또는 trend_line()

이상 징후 탐지는 기록 데이터를 사용하여 시리즈의 정상적인 동작에 대한 기준을 설정합니다. 위의 함수는 쿼리 창의 위치에 민감합니다. 단일 타임스탬프의 계열 값은 쿼리 창 내의 위치에 따라 크게 변경될 수 있습니다. 이러한 민감도는 이상 징후 탐지가 계열에 대한 일관된 기준선을 결정하는 것을 방지합니다.

적응형 알고리즘은 어떻게 되었나요?

Datadog은 더 이상 적응형 알고리즘을 사용하지 않도록 알고리즘을 발전시켰습니다. adaptive 알고리즘을 사용하는 기존 모니터는 그대로 유지되며 계속 작동합니다.

count_default_zero 인수란 무엇인가요?

이전에는 Datadog이 카운트 메트릭을 게이지로 처리하여 보고된 포인트 사이에 보간되었습니다. 이상 징후는 더 이상 개수 사이에 보간되지 않지만 레거시 모니터의 경우 count_default_zero 인수를 사용하여 이전 동작이 유지됩니다.

카운트 메트릭을 게이지로 처리하려면 어떻게 해야 하나요?

카운트 메트릭이 오류와 같은 경우 개수 사이를 보간하지 않는 것이 좋습니다. 그러나 매시간 발생하는 정기적으로 예약된 작업이 있는 경우 메트릭이 실행 사이에 0.0 값을 보고하지 않는 것이 더 의미가 있을 수 있습니다. 이를 수행하는 방법에는 두 가지가 있습니다.

  1. 롤업(고급 옵션 섹션에 있음)을 1시간으로 설정합니다.
  2. API를 사용하여 count_default_zero='false'를 명시적으로 설정합니다.

““고급 옵션"“에서 롤업 간격을 설정하는 것은 .rollup()을 사용하여 쿼리에서 설정하는 것과 어떻게 다르나요?

쿼리에 롤업이 명시적으로 설정된 경우 이상 모니터에 대한 롤업 간격 옵션이 무시됩니다.

메트릭 값이 X보다 작으면 메트릭이 비정상인지 여부는 상관하지 않습니다. 이러한 이상 현상을 어떻게든 무시해도 될까요?

A: 경계를 초과하는 값에 대해 경고하는 이상 징후 모니터; B: X보다 큰 값에 대해 트리거하는 임계값 경고가 있는 별도의 메트릭 모니터, 먼저 이 두 모니터를 생성합니다. 그런 다음 A && B컴포지트 모니터를 만듭니다.

“경고 및 경고 복구 기준은 모니터가 경고 및 경고 복구 상태에 동시에 있을 수 있는 것과 같습니다.“라는 메시지와 함께 모니터를 저장할 수 없는 이유는 무엇인가요?

경고 및 경고 복구 기간에 대해 서로 다른 창을 설정하면 상태가 모호해질 수 있습니다. 경고 및 경고 복구 창 크기는 두 가지를 동시에 충족할 수 없도록 설정해야 합니다. 예를 들어, 2시간 동안 경고 임계값을 50%로 설정하고(즉, 경고를 트리거하려면 1시간이 비정상적이어야 함), 10분 동안 복구 임계값을 50%로 설정하면(즉, 5분이 비정상적이어야 복구됨) 경고 및 경고 복구 상태가 동시에 트리거될 수 있습니다. 최근 5분은 비정상적이지 않지만 1시간 전이 비정상적이었다면 경고와 경고 복구 모두가 트리거됩니다.

서머타임은 이상 징후 탐지 모니터에 어떤 영향을 미치나요?

Datadog 모니터는 UTC 시간을 사용하며 기본적으로 현지 시간대에 구애받지 않습니다. 일반적으로 활동은 사용자의 현지 시간 동안 동일하게 유지되므로 사용자 활동은 UTC 시간을 기준으로 이동됩니다. 이는 예상치 못한 이상 현상으로 감지될 수 있습니다.

Datadog을 사용하면 각 이상 징후 탐지 모니터의 시간대를 설정하여 자동으로 시간 이동을 수정할 수 있습니다. 자세한 내용은 현지 표준 시간대를 고려하여 이상 징후 탐지 모니터를 업데이트하는 방법을 참조하세요.

PREVIEWING: may/unit-testing