본문 바로가기
WIKI 기술 지식 베이스

Anomaly 모니터

원문 보기 위키 갱신

Anomaly 모니터 (Anomaly Monitor)

이상 탐지(anomaly detection)는 메트릭이 과거와 다르게 동작하고 있을 때 이를 식별하는 알고리즘 기능이에요. 추세, 계절별 요일(day-of-week), 시간대별(time-of-day) 패턴을 고려해요. 강한 추세와 반복 패턴이 있어 임계값 기반 경보로 모니터링하기 어려운 메트릭에 적합해요.

예를 들어 이상 탐지는 평일 오후에 웹 트래픽이 비정상적으로 낮은 경우를 발견하는 데 도움을 줄 수 있어요. 같은 수준의 트래픽이 저녁에는 정상이어도 말이죠. 또는 꾸준히 성장하는 사이트의 로그인 수를 측정하는 메트릭을 생각해 보세요. 숫자가 매일 증가하기 때문에 어떤 임계값이라도 곧 시대에 뒤떨어지게 되지만, 이상 탐지는 로그인 시스템의 문제를 나타낼 수 있는 예상치 못한 하락이 있으면 경보를 발생시킬 수 있어요.

출처: 문서

본문

모니터 생성 (Monitor creation)

Datadog에서 anomaly 모니터를 만들려면 기본 내비게이션 Monitors > New Monitor > Anomaly를 사용해요.

메트릭 정의 (Define the metric)

Datadog에 보고하는 모든 메트릭은 모니터에 사용할 수 있어요. 자세한 내용은 메트릭 모니터 (Metric Monitor) 페이지를 참고하세요. 참고: anomalies 함수는 과거를 사용해 미래에 기대되는 것을 예측하므로, 새 메트릭에 사용하면 결과가 좋지 않을 수 있어요.

메트릭을 정의한 후 이상 탐지 모니터는 편집기에서 두 개의 미리보기 그래프를 제공해요:

{% image source="https://docs.dd-static.net/images/monitors/monitor_types/anomaly/context.3928f33bab7607b6ad04a380808455bc.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/monitors/monitor_types/anomaly/context.3928f33bab7607b6ad04a380808455bc.png?auto=format&fit=max&w=850&dpr=2 2x" alt="historical context" /%}

  • Historical View를 사용하면 다양한 시간 척도로 모니터링되는 쿼리를 탐색해 데이터가 왜 이상(anomalous) 또는 비이상(non-anomalous)으로 간주되는지 더 잘 이해할 수 있어요.
  • Evaluation Preview는 경보 창보다 길며, 이상 알고리즘이 경계(bounds)를 계산할 때 고려하는 내용에 대한 통찰을 제공해요.

경보 조건 설정 (Set alert conditions)

지난 15 minutes, 1 hour 등, 또는 custom으로 15분에서 2주 사이의 값을 설정하는 동안 값이 경계를 기준으로 above or below, above, 또는 below이면 경보를 트리거해요. 값이 최소 15 minutes, 1 hour 등, 또는 custom으로 15분에서 2주 사이의 값을 설정하는 동안 경계 안에 있으면 복구돼요.

{% dl %}

{% dt %} 이상 탐지 (Anomaly detection) {% /dt %}

{% dd %} 기본 옵션(above or below)에서는 메트릭이 회색 이상 밴드(anomaly band) 밖에 있으면 이상으로 간주돼요. 선택적으로 밴드의 above 또는 below만 이상으로 간주할지 지정할 수 있어요. {% /dd %}

{% dt %} 트리거 창 (Trigger window) {% /dt %}

{% dd %} 경보가 트리거되기 전에 메트릭이 이상 상태여야 하는 시간. 참고: 경보 창이 너무 짧으면 우연한 노이즈로 인해 거짓 경보(false alarm)가 발생할 수 있어요. {% /dd %}

{% dt %} 복구 창 (Recovery window) {% /dt %}

{% dd %} 메트릭이 더 이상 이상으로 간주되지 않아 경보가 복구될 수 있게 하는 데 필요한 시간. 복구 창(Recovery Window)을 트리거 창(Trigger Window)과 같은 값으로 설정할 것을 권장해요. {% /dd %}

{% /dl %}

참고: 복구 창의 허용 값 범위는 트리거 창과 경보 임계값에 따라 달라져 모니터가 동시에 복구 조건과 경보 조건을 충족하지 못하게 해요. 예시:

  • Threshold: 50%
  • Trigger window: 4h 복구 창의 허용 값 범위는 121분(4h*(1-0.5) +1 min = 121 minutes)과 4시간 사이예요. 복구 창을 121분 미만으로 설정하면 50%의 이상 포인트와 이상 포인트가 없는 마지막 120분이 함께 있는 4시간 시간대가 될 수 있어요.

또 다른 예시:

  • Threshold: 80%
  • Trigger window: 4h 복구 창의 허용 값 범위는 49분(4h*(1-0.8) +1 min = 49 minutes)과 4시간 사이예요.

고급 옵션 (Advanced options)

Datadog는 선택한 메트릭을 자동으로 분석하고 몇 가지 매개변수를 설정해줘요. 하지만 옵션은 Advanced Options 아래에서 편집할 수 있어요.

{% image source="https://docs.dd-static.net/images/monitors/monitor_types/anomaly/advanced_options.f2ed43d71d50032192207fb595d9387f.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/monitors/monitor_types/anomaly/advanced_options.f2ed43d71d50032192207fb595d9387f.png?auto=format&fit=max&w=850&dpr=2 2x" alt="The Advanced Options menu in the Anomaly monitor configuration page with the configuration set to detect anomalies 2 deviations from the predicted data using the agile algorithm with weekly seasonality, to take daylight savings into effect, and to use a rollup interval of 60 seconds" /%}

{% dl %}

{% dt %} 편차 (Deviations) {% /dt %}

{% dd %} 회색 밴드의 너비. anomalies 함수에 사용되는 bounds 매개변수와 동일해요. {% /dd %}

{% dt %} 알고리즘 (Algorithm) {% /dt %}

{% dd %} 이상 탐지 알고리즘(basic, agile, robust). {% /dd %}

{% dt %} 계절성 (Seasonality) {% /dt %}

{% dd %} agile 또는 robust 알고리즘이 메트릭을 분석하기 위한 주기의 계절성(hourly, daily, weekly). {% /dd %}

{% dt %} 일광 절약 시간 (Daylight savings) {% /dt %}

{% dd %} weekly 또는 daily 계절성을 가진 agile 또는 robust 이상 탐지에서 사용 가능. 자세한 내용은 이상 탐지와 시간대 (Anomaly Detection and Time Zones)를 참고하세요. {% /dd %}

{% dt %} 롤업 (Rollup) {% /dt %}

{% dd %} 롤업 간격 (rollup interval). {% /dd %}

{% dt %} 임계값 (Thresholds) {% /dt %}

{% dd %} 경보, 경고, 복구에 필요하도록 이상이어야 하는 포인트의 비율. {% /dd %}

{% /dl %}

계절성 (Seasonality)

{% dl %}

{% dt %} 시간별 (Hourly) {% /dt %}

{% dd %} 알고리즘은 정시 이후의 같은 분이 과거의 정시 이후의 분처럼 동작할 것으로 예상해요. 예: 5:15는 4:15, 3:15 등처럼 동작. {% /dd %}

{% dt %} 일별 (Daily) {% /dt %}

{% dd %} 알고리즘은 오늘의 같은 시간이 과거의 날처럼 동작할 것으로 예상해요. 예: 오늘 오후 5시는 어제 오후 5시처럼 동작. {% /dd %}

{% dt %} 주별 (Weekly) {% /dt %}

{% dd %} 알고리즘은 주어진 요일이 과거의 요일처럼 동작할 것으로 예상해요. 예: 이번 화요일은 과거의 화요일처럼 동작. {% /dd %}

{% /dl %}

Anomaly Detection 알고리즘에 필요한 데이터 이력: 머신러닝 알고리즘은 기준선(baseline)을 계산하기 위해 선택된 계절성 시간의 최소 3배 이상의 과거 데이터 시간이 필요해요. 예를 들어:

  • weekly 계절성은 최소 3주간의 데이터 필요
  • daily 계절성은 최소 3일간의 데이터 필요
  • hourly 계절성은 최소 3시간의 데이터 필요

모든 계절성 알고리즘은 메트릭의 예상 정상 동작 범위를 계산할 때 최대 6주간의 과거 데이터를 사용할 수 있어요. 상당한 양의 과거 데이터를 사용함으로써 알고리즘은 최근에 발생했을 수 있는 비정상 동작에 너무 큰 가중치를 두지 않아요.

이상 탐지 알고리즘 (Anomaly detection algorithms)

{% dl %}

{% dt %} Basic {% /dt %}

{% dd %} 메트릭에 반복되는 계절성 패턴이 없을 때 사용해요. Basic은 단순한 지연 롤링 분위수(lagging rolling quantile) 계산을 사용해 예상 값의 범위를 결정해요. 적은 데이터를 사용하고 변화하는 조건에 빠르게 적응하지만, 계절 동작이나 더 긴 추세에 대한 지식은 없어요. {% /dd %}

{% dt %} Agile {% /dt %}

{% dd %} 메트릭이 계절적이고 이동(shift)이 예상될 때 사용해요. 알고리즘은 메트릭 수준 이동에 빠르게 적응해요. SARIMA 알고리즘의 견고한(robust) 버전으로, 즉각적인 과거를 예측에 통합해 수준 이동에 대한 빠른 업데이트를 허용하지만, 최근의 오래 지속되는 이상에 대해 덜 견고하다는 단점이 있어요. {% /dd %}

{% dt %} Robust {% /dt %}

{% dd %} 계절 메트릭이 안정적일 것으로 예상되고, 느린 수준 이동이 이상으로 간주될 때 사용해요. 계절-추세 분해 (seasonal-trend decomposition) 알고리즘으로, 안정적이며 오래 지속되는 이상에도 예측이 일정하게 유지되지만, 의도된 수준 이동(예: 코드 변경으로 메트릭 수준이 이동하는 경우)에 응답하는 데 더 오래 걸려요. {% /dd %}

{% /dl %}

예시 (Examples)

아래 그래프는 이 세 알고리즘이 서로 다르게 동작하는 방식과 시점을 보여줘요.

시간별 계절성에 대한 이상 탐지 비교 (Anomaly detection comparison for hourly seasonality)

이 예시에서 basic은 정상 범위 밖으로 급증하는 이상을 성공적으로 식별하지만, 반복되는 계절 패턴을 예상 값 범위에 통합하지는 않아요. 반대로 robust와 agile은 둘 다 계절 패턴을 인식하고 더 미묘한 이상을 감지할 수 있어요. 예를 들어 메트릭이 최소값 근처에서 평탄해지는 경우처럼요. 추세도 시간별 패턴을 보이므로 이 경우 시간별 계절성이 가장 잘 작동해요.

{% image source="https://docs.dd-static.net/images/monitors/monitor_types/anomaly/alg_comparison_1.4880f1bd5edec262d75c5661be057017.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/monitors/monitor_types/anomaly/alg_comparison_1.4880f1bd5edec262d75c5661be057017.png?auto=format&fit=max&w=850&dpr=2 2x" alt="anomaly detection algorithm comparison with daily seasonality" /%}

주별 계절성에 대한 이상 탐지 비교 (Anomaly detection comparison for weekly seasonality)

이 예시에서 메트릭은 갑작스러운 수준 이동을 보여요. Agile은 robust보다 수준 이동에 더 빠르게 적응해요. 또한 robust의 경계 너비는 수준 이동 후 더 큰 불확실성을 반영해 증가하지만, agile의 경계 너비는 변하지 않아요. Basic은 메트릭이 강한 주별 계절 패턴을 보이는 이 시나리오에 분명히 부적합해요.

{% image source="https://docs.dd-static.net/images/monitors/monitor_types/anomaly/alg_comparison_2.4bc7b11f5c188914c3e479d64b2eb7f1.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/monitors/monitor_types/anomaly/alg_comparison_2.4bc7b11f5c188914c3e479d64b2eb7f1.png?auto=format&fit=max&w=850&dpr=2 2x" alt="anomaly detection algorithm comparison with weekly seasonality" /%}

변경에 대한 알고리즘 반응 비교 (Comparison of algorithm reactions to change)

이 예시는 알고리즘이 1시간짜리 이상에 어떻게 반응하는지 보여줘요. Robust는 갑작스러운 변경에 더 느리게 반응하므로 이 시나리오에서 이상에 대한 경계를 조정하지 않아요. 다른 알고리즘들은 이상이 새 정상인 것처럼 동작하기 시작해요. Agile은 심지어 메트릭이 원래 수준으로 돌아가는 것도 이상으로 식별해요.

{% image source="https://docs.dd-static.net/images/monitors/monitor_types/anomaly/alg_comparison_3.f2ae848ceea406b4cb737f49d3c9163d.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/monitors/monitor_types/anomaly/alg_comparison_3.f2ae848ceea406b4cb737f49d3c9163d.png?auto=format&fit=max&w=850&dpr=2 2x" alt="anomaly detection algorithm comparison with hourly seasonality" /%}

스케일에 대한 알고리즘 반응 비교 (Comparison of algorithm reactions to scale)

알고리즘은 스케일(scale)을 다르게 처리해요. Basic과 robust는 스케일 비민감(scale-insensitive)하지만 agile은 그렇지 않아요. 아래 왼쪽 그래프에서 agile과 robust가 수준 이동을 이상으로 표시하는 것을 볼 수 있어요. 오른쪽에서는 같은 메트릭에 1000이 더해졌고, agile은 더 이상 수준 이동을 이상으로 호출하지 않지만 robust는 계속 호출해요.

{% image source="https://docs.dd-static.net/images/monitors/monitor_types/anomaly/alg_comparison_scale.53687cd1dba0c7079864602e4132049e.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/monitors/monitor_types/anomaly/alg_comparison_scale.53687cd1dba0c7079864602e4132049e.png?auto=format&fit=max&w=850&dpr=2 2x" alt="algorithm comparison scale" /%}

새 메트릭에 대한 이상 탐지 비교 (Anomaly detection comparison for new metrics)

이 예시는 각 알고리즘이 새 메트릭을 어떻게 처리하는지 보여줘요. Robust와 agile은 처음 몇 시즌(주별) 동안 어떤 경계도 표시하지 않아요. Basic은 메트릭이 처음 나타난 직후 경계 표시를 시작해요.

{% image source="https://docs.dd-static.net/images/monitors/monitor_types/anomaly/alg_comparison_new_metric.e06d77a7e5dc254b891fe96a6e5602f9.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/monitors/monitor_types/anomaly/alg_comparison_new_metric.e06d77a7e5dc254b891fe96a6e5602f9.png?auto=format&fit=max&w=850&dpr=2 2x" alt="algorithm comparison new metric" /%}

고급 경보 조건 (Advanced alert conditions)

고급 경보 옵션(auto resolve, evaluation delay 등)에 대한 자세한 지침은 모니터 구성 (Monitor configuration) 페이지를 참고하세요. 메트릭별 옵션인 full data window는 메트릭 모니터 (Metric monitor) 페이지를 참고하세요.

알림 (Notifications)

Configure notifications and automations 섹션에 대한 자세한 지침은 알림 (Notifications) 페이지를 참고하세요.

API (API)

엔터프라이즈 플랜 고객은 create-monitor API 엔드포인트를 사용해 이상 탐지 모니터를 만들 수 있어요. Datadog는 API용 쿼리를 만들기 위해 모니터의 JSON을 내보내기를 강력히 권장해요. Datadog의 모니터 생성 페이지를 사용하면 고객은 미리보기 그래프와 자동 파라미터 튜닝의 이점을 얻어 잘못 구성된 모니터를 피할 수 있어요.

Anomaly 모니터는 다른 모니터와 같은 API로 관리돼요. 이 필드들은 anomaly 모니터에 고유해요:

query (query)

요청 본문의 query 속성은 다음 형식의 쿼리 문자열을 포함해야 해요:

avg(<query_window>):anomalies(<metric_query>, '<algorithm>', <deviations>, direction='<direction>', alert_window='<alert_window>', interval=<interval>, count_default_zero='<count_default_zero>' [, seasonality='<seasonality>']) >= <threshold>

{% dl %}

{% dt %} query_window {% /dt %}

{% dd %} last_4h 또는 last_7d 같은 시간대. 이 매개변수는 알림 그래프에 표시되는 데이터의 시간 범위를 제어해요. query_window는 시각화에 나타나는 과거 데이터의 양을 결정하지만 경보 평가에는 영향을 주지 않아요. Datadog는 추가 맥락을 제공하기 위해 query_window를 alert_window의 약 5배로 설정할 것을 권장해요. 참고: query_window는 alert_window 이상이어야 해요. {% /dd %}

{% dt %} metric_query {% /dt %}

{% dd %} 표준 Datadog 메트릭 쿼리(예: sum:trace.flask.request.hits{service:web-app}.as_count()). {% /dd %}

{% dt %} algorithm {% /dt %}

{% dd %} basic, agile, 또는 robust. {% /dd %}

{% dt %} deviations {% /dt %}

{% dd %} 양수. 이상 탐지의 민감도를 제어해요. {% /dd %}

{% dt %} direction {% /dt %}

{% dd %} 경보를 트리거해야 하는 이상의 방향성: above, below, 또는 both. {% /dd %}

{% dt %} alert_window {% /dt %}

{% dd %} 이상을 확인할 시간대(예: last_5m, last_1h). {% /dd %}

{% dt %} interval {% /dt %}

{% dd %} 롤업 간격의 초 수를 나타내는 양의 정수. alert_window 기간의 5분의 1보다 작거나 같아야 해요. {% /dd %}

{% dt %} count_default_zero {% /dt %}

{% dd %} 대부분의 모니터에는 true를 사용해요. 값의 부재를 0으로 해석하면 안 되는 카운트 메트릭을 제출하는 경우에만 false로 설정해요. {% /dd %}

{% dt %} seasonality {% /dt %}

{% dd %} hourly, daily, 또는 weekly. basic 알고리즘을 사용할 때는 이 매개변수를 제외해요. {% /dd %}

{% dt %} threshold {% /dt %}

{% dd %} 1을 넘지 않는 양수. critical 경보가 트리거되기 위해 alert_window에서 이상이어야 하는 포인트의 비율. {% /dd %}

{% /dl %}

아래는 이상 탐지 모니터의 예시 쿼리로, 평균 Cassandra 노드의 CPU가 지난 5분 동안 일반 값에서 3표준편차 위일 때 경보를 발생시켜요:

avg(last_1h):anomalies(avg:system.cpu.system{name:cassandra}, 'basic', 3, direction='above', alert_window='last_5m', interval=20, count_default_zero='true') >= 1

이 쿼리는 두 곳에서 avg를 사용해요:

  • avg(last_1h) - 알림 그래프를 위해 쿼리 창에 걸쳐 이상 데이터 포인트를 집계
  • avg:system.cpu.system{name:cassandra} - 이상 탐지 전에 Cassandra 노드에 걸쳐 CPU 메트릭을 집계

options (options)

요청 본문의 options 아래 대부분의 속성은 thresholds와 threshold_windows를 제외하고 다른 쿼리 경보와 동일해요.

{% dl %}

{% dt %} thresholds {% /dt %}

{% dd %} Anomaly 모니터는 critical, critical_recovery, warning, warning_recovery 임계값을 지원해요. 임계값은 0~1의 숫자로 표현되며, 연결된 창에서 이상인 비율로 해석돼요. 예를 들어 critical 임계값 0.9는 아래 설명하는 trigger_window의 포인트 중 최소 90%가 이상일 때 critical 경보가 트리거됨을 의미해요. 또는 warning_recovery 값 0은 recovery_window의 포인트 0%가 이상일 때만 모니터가 warning 상태에서 복구됨을 의미해요. {% /dd %}

{% dd %} critical threshold는 query에 사용된 threshold와 일치해야 해요. {% /dd %}

{% dt %} threshold_windows {% /dt %}

{% dd %} Anomaly 모니터는 options에 threshold_windows 속성이 있어요. threshold_windows는 trigger_window와 recovery_window 두 속성을 모두 포함해야 해요. 이 창들은 last_10m 또는 last_1h 같은 시간대 문자열로 표현돼요. trigger_window는 query의 alert_window와 일치해야 해요. trigger_window는 모니터가 트리거되어야 하는지 평가할 때 이상을 분석하는 시간 범위예요. recovery_window는 트리거된 모니터가 복구되어야 하는지 평가할 때 이상을 분석하는 시간 범위예요. {% /dd %}

{% /dl %}

표준적인 thresholds와 threshold window 구성은 다음과 같아요:

"options": {
  ...
  "thresholds": {
    "critical": 1,
    "critical_recovery": 0
  },
  "threshold_windows": {
    "trigger_window": "last_30m",
    "recovery_window": "last_30m"
  }
}

문제 해결 (Troubleshooting)

더 알아보기 (Learn more)