이상치 감지

뉴렐릭의 이상치 감지 기능은 동료들과 현저하게 다른 행동을 보이는 개체를 자동으로 식별하도록 설계된 고급 기능입니다. 시간이 지남에 따라 비정상적인 패턴을 찾는 기존의 이상 작용 탐지와 달리 이상치 탐지는 특정 순간에 그룹 내의 유치원에 초점을 맞춥니다.

이 기능을 사용하면 다음과 같은 잠재적인 문제를 사전에 파악할 수 있습니다.

• 클러스터 내 다른 서버에 비해 CPU 사용률이 높은 단일 서버
• Kafka 브로커가 메시지를 올바르게 처리하지 못하고 있습니다.

이러한 "이상치"를 정확히 파악함으로써 관련 하위 시스템을 신속하게 찾아 장애 발생 가능성을 추론할 수 있으므로 평균감지시간(MTTD)(평균복구시간(MTTD)) 및 평균복구시간(MTTR)을 줄일 수 있습니다.

주요 컨셉

이러한 핵심 개념을 이해하면 이상치 탐지 기능을 효과적으로 구성하는 데 도움이 됩니다.

• DBSCAN: 밀집된 점들을 그룹으로 묶고, 어떤 그룹에도 속하지 않는 점들을 이상치로 식별하는 밀도 기반 클러스터 알고리즘.

• Epsilon (Eps): 두 점이 같은 이웃으로 간주되기 위한 두 점 사이의 최대 거리를 정의합니다. 값이 작을수록 클러스터가 더 촘촘해지고, 값이 클수록 클러스터가 더 느슨해집니다.

• 최소 점수(MinPts): 클러스터를 형성하는 데 필요한 최소 점수입니다. 대부분의 사용 사례에서는 3보다 큰 값을 권장합니다.

• 평가 그룹: 환경, 지역 또는 응용 분야와 같은 다양한 기준으로 이상치 분석을 분할하여 전체 데이터 세트가 아닌 각 그룹 내에서만 이상치를 개별적으로 감지할 수 있습니다. 이렇게 하면 각 그룹 내에서 이상치를 개별적으로 감지할 수 있으므로 여러 개의 공지 조건을 설정할 필요가 줄어듭니다.

자동 모드 vs. 수동 모드

핵심 매개변수 변수를 설정하는 두 가지 모드가 있으며, 이를 통해 데이터에 맞는 올바른 공지를 얻을 수 있습니다.

Auto mode [자동 모드는] 이상치 공지를 구성하는 가장 빠른 방법입니다. 이를 통해 알고리즘의 기술적인 세부 사항을 건너뛸 수 있으므로 복잡한 머신러닝 매개변수, 변수를 이해할 필요가 없습니다.

기술적인 데모를 설정하는 대신 간단한 민감도 슬라이더를 조정합니다. 이 시스템은 자동 추정 기능을 사용하여 사용자가 선택한 민감도 수준에 해당하는 최적의 엡실론(Eps) 및 최소 포인트(MinPts) 값을 즉시 계산합니다.

자동 추정치가 데이터에 적합한지 확인하려면 데이터 시각화를 살펴보세요. 차트에서 이상치로 표시된 신호가 상식적인 이상 징후에 대한 이해와 일치한다면 자동 모드가 효과적으로 작동하고 있는 것입니다.

Manual mode [수동 모드] 는 고급 사용자 또는 시스템의 자동 추정치가 데이터의 고유한 특성에 정확히 들어맞지 않는 상황에 사용됩니다. 수동 모드로 전환하면 DBSCAN 모델을 직접 제어할 수 있습니다.

자동 모드 결과가 정확하지 않으면 수동 모드로 전환해야 합니다.

• 이 시스템은 시각적으로는 여전히 클러스터의 일부인 신호를 이상치로 표시합니다.
• 해당 시스템은 주요 데이터 클러스터에서 분명히 멀리 떨어진 신호를 감지하지 못합니다.
• 민감도 슬라이더를 전체 범위에 걸쳐 움직여도 감지된 이상치에는 의미 있는 변화가 거의 또는 전혀 나타나지 않습니다.

이상치 탐지 생성 공지 조건

이상치 감지 기능을 사용하여 공지 조건을 생성하려면 다음 단계를 따르세요.

1. 뉴렐릭 계정에서 one.newrelic.com > All capabilities > Alerts > Alert Conditions 으로 이동하세요.

2. + New alert condition [+ 새 공지 조건]을 클릭하고 Use guided mode [안내 모드 사용] 또는 Query [쿼리] 모드**를 선택합니다. 어떤 모드를 선택하든 set thresholds [임계값 설정] 페이지에서 알림 조건에 대한 임계값을 설정합니다.

3. 설정 범위, 한계 페이지에 도달할 때까지 단계를 진행하십시오.

4. Outliers [이상치]를 선택합니다.

5. 알고리즘 모드를 선택하세요:

   • Auto [자동] 모드를 선택한 경우, 감도 슬라이더를 조정하여 감지 범위를 미세 조정하십시오. 이 모드에서 시스템은 이력 데이터를 기반으로 최적의 내부 트리거(예: Epsilon 및 DBSCAN에 대한 최소 포인트)를 자동으로 결정합니다.
   • Manual [수동] 모드를 선택하면 엡실론 값과 최소값(Minimum points)을 직접 지정할 수 있습니다.

6. 선택적으로 평가 그룹을 구성할 수 있습니다.

7. 나머지 공지조건 설정을 완료하세요.

모범적 등록

엡실론 값 선택

• 기본값으로 시작하여 데이터 특성에 따라 조정하십시오.
• 오탐률을 모니터링하고 그에 따라 조정하십시오.
• 더 작은 엡실론 값으로 더 민감한 감지가 가능합니다.
• 검출 감도가 낮을수록 엡실론 값이 커집니다.

최소 점수 설정

• 대부분의 경우 3보다 큰 값을 사용하십시오.
• 값이 높을수록 노이즈는 줄어들지만 미묘한 이상치를 놓칠 수 있습니다.
• 이 값을 설정할 때는 일반적인 그룹 규모를 고려하십시오.

평가 그룹을 효과적으로 활용하기

• 논리적 경계(환경, 지역, 서비스)별로 그룹화합니다.
• 과도한 세분화는 효과를 떨어뜨릴 수 있으므로 피해야 합니다.
• 그룹화할 때는 계절성과 사업 패턴을 고려하십시오.

지연된 데이터 및 이전 타임스탬프 처리

이상치 탐지는 동일한 시점에 여러 엔티티의 메트릭을 비교하여 작동합니다. 공정한 비교를 위해, 모든 엔티티는 동일한 시간 범위의 데이터를 보고해야 합니다.

지연된 타임스탬프의 문제점

오후 2시에 3대의 서버에서 CPU 사용량을 모니터링한다고 가정해 보겠습니다:

• 서버 A 는 타임스탬프와 함께 45% CPU를 보고합니다. 2:00 PM
• Server B 는 타임스탬프와 함께 50% CPU를 보고합니다. 2:00 PM
• Server C 는 타임스탬프와 함께 95% CPU를 보고합니다. 1:30 PM

서버 C의 데이터에는 더 오래된 타임스탬프(오후 2:00 대신 오후 1:30)가 있습니다. 시스템은 오후 1:30 데이터와 오후 2:00 데이터를 비교할 수 없습니다 ― 이는 사과와 오렌지를 비교하는 것과 같습니다. 그 결과, 서버 C는 이상치 분석에서 완전히 제외됩니다. 서버 C에 명백히 문제가 발생하고 있더라도, 한 번도 평가되지 않았기 때문에 공지를 받지 못할 것입니다.

이는 엔티티가 분석 중인 현재 시간 창보다 더 오래된 타임스탬프를 가진 데이터를 지속적으로 보고할 때 발생합니다.

일반적인 원인

• 클라우드 제공업체 폴링: AWS CloudWatch 및 유사 서비스는 일정에 따라 메트릭을 수집하며, 이후 뉴렐릭이 이를 폴링합니다. 예를 들어, 오후 2:00를 나타내는 메트릭이 오후 2:05까지 뉴렐릭에 도착하지 않아 5분 지연이 발생할 수 있습니다.

• 장기 실행 트랜잭션: 백그라운드 작업은 완료될 때가 아니라 시작될 때 타임스탬프가 기록됩니다. 오후 1:30에 시작하여 30분 동안 실행되는 작업은 데이터가 오후 2:00에 도착할 때 오후 1:30 타임스탬프를 갖습니다.

• 버퍼링된 데이터: 네트워크 문제 또는 에이전트 설정으로 인해 데이터가 로컬 대기열에 쌓일 수 있습니다. 연결이 복구되면, 버퍼링된 모든 데이터는 원래 타임스탬프와 함께 도착합니다.

제외된 엔티티 식별

어떤 엔티티가 제외되고 있는지와 그 이유를 확인하려면 NrAiSignal 이벤트를 쿼리하십시오:

FROM NrAiSignal
SELECT *
WHERE conditionId = 1234
  AND outlierProcessingSkippedReason IS NOT NULL

1234 를 귀하의 공지 조건 ID로 대체합니다. 검토할 주요 필드:

• outlierProcessingSkippedReason: 신호가 제외된 이유(일반적으로 지연된 데이터의 경우 LATE 표시)
• outlierProcessingSkippedTimeDelta: 데이터의 타임스탬프와 현재 평가 창 간의 초 단위 시간 차이

문제 해결

조건 편집기에서 신호가 제외되고 있다는 경고가 표시되는 경우:

옵션 1: 조건 분할(권장)

보고 동작이 다른 엔티티에 대해 별도의 공지 조건을 생성하십시오:

• 실시간 애플리케이션 서버를 위한 하나의 조건
• 클라우드 폴링 리소스(AWS CloudWatch 지표 등)에 대한 또 다른 조건

이를 통해 각 조건의 집계 창이 해당 엔티티가 실제로 데이터를 보고하는 방식과 일치하도록 합니다.

옵션 2: 집계 창 늘리기

지연을 수용할 수 있도록 집계 창을 확장하십시오. 예를 들어, 데이터가 지속적으로 3-5분 지연되는 경우 1분 대신 5분 집계 창을 사용하십시오.

트레이드오프: 더 큰 윈도우는 단기적인 스파이크를 완화하고 공지가 트리거되기 전의 시간을 늘립니다. 오후 2:00에 스파이크가 발생하는 서버는 오후 2:05 또는 그 이후까지 공지를 트리거하지 않을 수 있습니다.

사용 사례 및 예시

• 불균형한 Kafka 브로커: CPU I/O 대기 시간이 비정상적인 브로커를 신속하게 식별하여 관리자가 성능 저하가 발생하기 전에 워크로드를 사전에 재조정할 수 있도록 지원합니다.
• 자원 활용 이상치: 지속적으로 활용도가 낮거나 높은 자원을 정확히 파악합니다. 이를 통해 더 나은 용량 계획을 수립하고 낭비나 잠재적인 병목현상, 병목지점을 방지할 수 있습니다.
• "시끄러운 이웃" 식별: 공유 리소스를 과도하게 소비하는 리소스 독차지 개체를 감지합니다. 이를 통해 자원 배분의 균형을 맞추기 위한 시정 조치를 취할 수 있습니다.
• 특이한 메모리 문제: 비정상적인 OOM(Out of Memory)이 있는 JVM(썸머신)을 조기에 감지하여 적시에 개입하여 광범위한 오류를 방지할 수 있습니다.
• 환경별 모니터링: 평가 그룹을 사용하여 안정성 및 운영 환경을 별도로 모니터링하여 한 환경의 이상치가 다른 환경의 감지를 방해하지 않도록 합니다.