경고 조건

NRQL 쿼리를 사용하여 경고 조건이 경고의 기초로 사용할 신호를 정의할 수 있습니다. 이 예에서는 다음 쿼리를 사용합니다.

SELECT average(duration)
FROM PageView
WHERE appName = 'WebPortal'

공지 조건에 이 쿼리를 사용하면 뉴렐릭에게 WebPortal 에서 페이지를 로드하는 데 필요한 평균 지연 시간 또는 지속 시간을 알고 싶다는 뜻이 됩니다. 골든의 핵심 신호인 지연시간에 대한 사전 경고는 잠재적 성능 저하에 대한 조기 경고를 제공합니다.

New Relic의 쿼리 언어인 NRQL 사용 방법에 대한 자세한 내용은 NRQL 문서를 참조하세요.

/ <img title="fine tune 공지 설정" alt="고급 신호 설정을 보여주는 스크린샷입니다." src="/images/alerts_screenshot-crop_fine-tune-공지-signals.webp" /> /

창 기간은 New Relic이 경고 조건에서 분석을 위해 데이터를 그룹화하는 방법을 정의합니다. 올바른 설정을 선택하는 것은 데이터의 빈도와 원하는 세부 정보 수준에 따라 다릅니다.

• High-frequency data (for example, pageviews every minute): 변동 및 추세에 대한 데이터 빈도(이 경우 1분)에 맞춰 기간을 설정합니다.

• Low-frequency data (for example, hourly signals): 패턴과 이상 징후를 드러내기에 충분한 데이터를 캡처하는 기간을 선택합니다(예: 시간별 신호의 경우 60분).

  필요와 경험에 따라 기간을 맞춤설정할 수 있다는 점을 기억하세요. 경고 조건 생성에 익숙해지면 시작하고 실험할 때 기본값을 사용하는 것이 좋습니다.

기존 집계 방법은 인구가 적거나 간격 간에 상당한 변동을 보이는 데이터를 처리할 때 부족할 수 있습니다. 슬라이딩 윈도우 집계를 사용하여 이러한 데이터를 분석하고 적시에 경고를 효과적으로 트리거하는 방법은 다음과 같습니다.

1. Smooth out the noise: 큰 집계 창을 만드는 것부터 시작하세요. 이 기간(예: 5분)은 버퍼 역할을 하여 데이터에 내재된 "노이즈" 또는 변동성을 완화합니다. 이는 격리된 스파이크 또는 딥으로 인해 트리거되는 허위 알림을 방지하는 데 도움이 됩니다.

2. Avoid lag with a sliding window: 큰 창이 데이터 분석에 도움이 되지만, 이전 값을 확인하기 전에 전체 간격이 경과할 때까지 기다리면 공지 공지에서 상당한 지연이 발생할 수 있습니다. 더 작은 슬라이딩 기간(예: 1분)을 권장합니다. 이 슬라이딩 윈도우를 더 큰 집계 창 내에서 데이터를 스캔하는 움직이는 프레임으로 상상해 보십시오. 프레임이 더 작은 간격으로 진행될 때마다 집계 값(예: 평균)이 계산됩니다.

3. Set your threshold duration: 이제 더 작은 슬라이딩 창의 컨텍스트 내에서 공지사항 값, 릴레이를 정의할 수 있습니다. 이를 통해 현재 프레임의 집계 값이 더 큰 창의 평활화 효과를 희생하지 않고 원하는 범위에서 크게 벗어날 때 알림을 신속하게 트리거할 수 있습니다.

   중요

   Advanced 및 Core 컴퓨팅 가격 계획을 사용하는 고객은 슬라이딩 윈도우 집계를 활용할 경우 추가 CCU 요금이 부과될 수 있습니다. 이 방법을 사용하면 변동을 완화하여 데이터 분석이 향상되지만, 다른 방법에 비해 비용이 증가할 수 있습니다. 자세한 내용은 슬라이딩 창문 가격 섹션을 참조하세요. 고급 또는 핵심 컴퓨터 가격 책정 플랜을 사용 중인지 확인하려면 주문을 참조하세요.

   이 NRQL 튜토리얼 에서 슬라이딩 윈도우 집계에 대해 자세히 알아볼 수 있습니다.

일반적으로 event flow 스트리밍 방법을 사용하는 것이 좋습니다. 이는 시스템에 자주 그리고 꾸준히 들어오는 데이터에 가장 적합합니다. event timer 선택하는 것이 더 나은 방법이 될 수 있는 특별한 경우가 있지만, 첫 번째 공지에는 기본값인 event flow 권장합니다. 이 간단한 비디오를 시청하는 것이 좋습니다(약 1시간). 5분 31초) 어떤 스트리밍 방법을 선택해야 할지 더 잘 이해할 수 있습니다.

공지의 지연 기능은 일관성 없는 데이터 수집으로 인해 발생하는 잠재적인 문제로부터 보호합니다. 이는 일종의 버퍼 역할을 하여 알림이 발생하기 전에 데이터가 도착하고 처리될 수 있도록 추가 시간을 제공합니다. 이를 통해 오탐을 방지하고 보다 정확한 공지 이벤트 생성이 가능해집니다.

작동 방식:

적절한 지연 설정은 수신 데이터의 일관성을 평가하여 결정됩니다.

• 일관된 데이터: 데이터 포인트가 1분 이내에 타임스탬프와 함께 일관되게 도착하는 경우 더 낮은 지연 설정으로 충분합니다.

• 일관성 없는 데이터: 과거 또는 미래의 몇 분에 걸친 타임스탬프와 함께 데이터 포인트가 도착하는 경우 불일치를 수용하기 위해 더 높은 지연 설정이 필요합니다.

  버퍼 생성:

• 선택한 지연 설정은 경고 조건이 정의된 임계값에 대해 데이터를 평가하기 전에 대기 기간을 도입합니다.

• 이 버퍼는 데이터 불일치가 해결될 시간을 허용하여 잘못된 경고가 발생할 가능성을 줄입니다.

WebPortal 애플리케이션의 지연 시간 문제를 팀에 알리기 위한 경고 조건을 생성 중입니다. 이 예에서 애플리케이션은 New Relic 데이터를 일관되게 보냅니다. 애플리케이션에서 New Relic으로 신호의 지속적인 스트림이 전송되고 신호에 예상되는 공백이 없으므로 공백 채우기 전략을 선택할 필요가 없습니다.

격차 채우기 전략은 데이터 수집이 간헐적이거나 불완전할 수 있는 시나리오를 다룹니다. 이는 누락된 데이터 포인트를 예상 값으로 대체하는 방법을 제공하여 데이터 스트림에 공백이 있는 경우에도 경고 조건이 여전히 효과적으로 작동할 수 있도록 보장합니다.

간격 채우기를 해제해야 하는 경우:

• Consistent data flow: WebPortal 제작의 경우처럼 예상되는 공백 없이 일관되게 뉴렐릭에 데이터를 보내는 경우 일반적으로 공백 채우기가 필요하지 않습니다. 이러한 경우 공백 메우기 전략을 없음으로 설정하는 것이 가장 적절한 접근 방식인 경우가 많습니다.

  주요 고려사항:

• Popular use case: 간격 채우기의 일반적인 용도는 수신된 데이터가 없는 창에 0 값을 삽입하는 것입니다.

• Anomaly thresholds: gap-filling 값은 이상 전동 값, 릴레이를 사용할 때 마지막 관측된 값으로부터 표준의 개수로 해석됩니다. 예를 들어, 간격을 0 값으로 채우면 변경 사항이 없다고 가정하여 마지막으로 표시된 값이 복제됩니다.

  손실된 신호 문서 에서 갭 채우기 전략에 대해 자세히 알아보세요.

쿠렐릭의 교차 계정 알림을 사용하면 공지가 구성된 계정과 다른 계정의 데이터를 모니터링하는 공지 조건을 설정할 수 있습니다. 이를 통해 뉴렐릭 내의 여러 계정에 걸쳐 의존성/종속 기능을 모니터링하고 관리하는 데 더 큰 유연성이 제공됩니다.

자세한 내용은 Cross-account 공지 를 참조하세요.

이상 임계값은 특정 숫자 값보다 예상 패턴과의 편차가 더 중요한 경우에 이상적입니다. 미리 정의된 제한을 설정할 필요 없이 비정상적인 활동을 모니터링할 수 있습니다. New Relic의 이상 탐지 기능은 시간이 지남에 따라 데이터를 동적으로 분석하여 진화하는 시스템 동작을 반영하도록 임계값을 조정합니다.

이상 탐지 설정:

1. 상위 또는 하위 선택:

   • 예상보다 높거나 낮은 편차에 대해 경고를 받으려면 상한 및 하한을 선택합니다.
   • 비정상적으로 높은 값에만 초점을 맞추려면 상한만을 선택합니다.

2. 우선순위 할당:

   • 잠재적인 문제에 대한 신속한 주의를 보장하려면 초기 경고의 우선순위 수준을 중요로 설정하세요.

3. 위반 기준을 정의합니다.

   • 기본 설정으로 시작합니다. 쿼리 결과가 예측값에서 최소 5분 동안 3 표준편차 이상 벗어나는 경우 알림 이벤트를 엽니다.
   • 특정 애플리케이션 및 경고 요구 사항에 맞게 필요에 따라 이러한 설정을 사용자 정의합니다.

   경고 조건 문서 에서 우선순위 수준에 대해 자세히 알아볼 수 있습니다.

   이상 문서 에서 이상 임계값과 모델 동작에 대해 자세히 알아보세요.

이상 가리켜 값, 정적 레버 값과 달리, 기대감은 데이터 세트를 전체적으로 살펴보지 않고 시스템 기록을 기반으로 어떤 동작이 비정상적인지 결정합니다. 대신, 정적 레버 값은 시스템이 사용자가 설정한 기준과 다르게 동작할 때마다 공지 이벤트를 엽니다.

이상치와 정적 임계값 모두에 대한 우선순위 수준을 설정해야 합니다. 자세한 내용은 위 섹션을 참조하세요.

이상치 감지는 특정 시점에 동료들과 상당히 다르게 행동하는 것을 식별합니다. 이상치 탐지는 시간이 지남에 따라 특이한 패턴을 찾아내는 이상치 탐지와 달리 DBSCAN 클러스터를 사용하여 그룹 내에서 이상한 탐지에 중점을 둡니다.

이 레버 값, 릴레이 유형은 다음 용도에 이상적입니다.

• 클러스터에 비해 비정상적인 리소스 소비가 있는 서버 식별

• Kafka 브로커가 메시지를 올바르게 처리하지 못하는 문제 감지

• 다중 테넌트 환경에서 "시끄러운 이웃" 시나리오 찾기

  주요 설정 방법:

• Epsilon: 같은 클러스터 내 점 사이의 최대 거리

• 최소 포인트: 클러스터를 형성하는 데 필요한 최소 포인트(권장 > 3)

• 평가 그룹: 환경이나 지역과 같은 측면별 세그먼트 분석

  이상치 감지에 대한 자세한 내용은 이상치 감지 설명서를 참조하세요.

뉴렐릭에서는 분리가 색상으로 구분된 상태 와 연관되어 있습니다. 각 엔티티의 현재 상태는 해당 인덱스와 맵에서 확인할 수 있습니다. 공지조건이 부분과 연관되어 있는 경우, 부분의 상태는 공지조건에 따라 결정됩니다. 공지가 공지 이벤트를 발생시키는 경우, 공지 이벤트의 심각도 수준에 따라 변경의 상태가 변경됩니다.

공지 조건이 연관된 분할 상태에 영향을 주지 않도록 하려면 Do not report system health status 토글을 활성화하세요. 전체 상태에 영향을 주지 않고 패널을 확인하려는 경우에 유용합니다.

뉴렐릭의 Predictive Alerts 는 이력 데이터를 분석하여 미래 동향을 예측합니다. 예측 결과 정적, 경계가 곧 침해될 수 있는 것으로 나타나면 공지 알림을 받게 되며, 이를 통해 중단이 발생하기 전에 조치를 취할 수 있습니다.

자세한 내용은 예측 알림 설명서를 참조하세요.

공지사항에 대한 예측 알림을 활성화하려면 다음 단계를 수행하세요.

1. Set condition thresholds 섹션에서 레버 값, 릴레이 조건 유형을 Static 으로 선택합니다.

2. 예측 알림의 경우 Predict future behavior 토글을 활성화합니다.

3. 미리 볼 수 있는 시간을 설정합니다. 이는 예상되는 침해를 얼마나 먼 미래에 찾아야 하는지를 나타냅니다. 최대 예측 시간은 창 기간의 360배입니다.

4. 실제 신호가 레버 값을 교차할 때 예상되는 공지 이벤트 동작을 설정합니다.

   • 예측된 공지를 닫고 실제 공지를 엽니다.
   • 예상되는 공지를 열어두어 소음을 줄이세요.

신호 손실 시간은 신호가 끊긴 것으로 간주하기 전에 얼마나 기다려야 하는지를 결정합니다. 해당 시간 내에 신호가 반환되지 않으면 새 알림 이벤트를 열거나 관련 이벤트를 닫을 수 있습니다. 신호가 종료될 것으로 예상되는 경우 알림 이벤트를 열지 않도록 선택할 수도 있습니다. 시스템의 예상 동작 및 데이터 수집 빈도에 따라 임계값을 설정하십시오. 예를 들어, 웹 사이트에서 트래픽이 완전히 손실되거나 처리량이 발생하는 경우 뉴렐릭으로 전송된 해당 텔레메트리 데이터도 중단됩니다. 이러한 신호 손실을 모니터링하는 것은 정전 사태에 대한 조기 경보 시스템 역할을 할 수 있습니다.

조건 명명에 대한 모범 사례에는 필수 정보를 한눈에 전달하는 구조화된 형식이 포함됩니다. 조건 이름에 다음 요소를 포함합니다.

• 우선순위: P1, P2, P3와 같이 공지의 심각도나 긴급도를 나타냅니다.

• 신호: 높은 평균 지연 시간 또는 낮은 처리량과 같은 지표 또는 조건을 모니터로 지정합니다.

• 엔터티: WebPortal 앱 또는 데이터베이스 서버와 같은 영향을 받는 시스템, 애플리케이션 또는 구성 요소를 식별합니다.

  이 구조를 따르는 올바른 형식의 조건 이름의 예는 P2 | High Avg Latency | WebPortal App 입니다.

경고 조건에 연결할 정책이 이미 있는 경우 기존 정책을 선택합니다.

정책 생성에 대한 자세한 내용은 여기에서 확인하세요.

알림 전략에서 반응성과 피로도의 균형을 맞추는 것이 중요하며 WebPortal 애플리케이션에 대한 pageview 모니터링과 관련된 주요 고려 사항을 제시했습니다. 정책 옵션을 살펴보겠습니다.

1. 정책당 하나의 문제(기본값):

   • 장점: 소음을 줄이고 즉각적인 조치를 보장합니다.
   • 단점: 발생 조건이 다르더라도 모든 공지 이벤트를 하나의 이슈로 묶습니다. 여러 페이지를 동시에 보는 문제를 해결하기에는 이상적이지 않습니다.

2. 조건당 하나의 문제:

   • 장점: 각 조건에 대해 별도의 문제를 생성하므로 특정 대기 시간 문제를 격리하고 해결하는 데 이상적입니다.
   • 단점: 더 많은 경고를 생성하여 잠재적으로 피로를 유발할 수 있습니다.

3. 모든 공지 이벤트에 대한 문제:

   • 장점: 외부 시스템에 대한 세부적인 세부 정보를 제공하지만 잠재적인 과부하로 인해 내부 소비에는 적합하지 않습니다.
   • 단점: 가장 시끄러운 옵션이며 더 넓은 추세를 추적하고 효과적으로 우선순위를 지정하는 것이 어렵습니다.

   정책 생성에 대한 자세한 내용은 여기에서 확인하세요.

공지 이벤트는 트리거, 목표 신호가 해당 조건의 레버 값, 경계에 표시된 기간 동안 위반하지 않은 상태로 돌아오면 자동으로 종료됩니다. 이 대기 시간을 복구 기간이라고 합니다.

예를 들어, 지연시간을 측정하고 있고 위반 행위가 WebPortal 애플리케이션의 페이지 로드 시간duration 이 3초를 초과하는 경우, 공지 이벤트는 duration 5분 연속으로 3초 이하일 때 자동으로 종료됩니다.

공지 이벤트가 자동으로 종료되는 경우:

1. 마감 타임스탬프는 복구 기간 시작으로 소급됩니다.

2. 평가는 이전 공지 이벤트가 종료된 시점부터 재설정되어 다시 시작됩니다.

   모든 조건에는 오래 지속되는 공지 이벤트를 자동으로 강제 종료하는 공지 이벤트 시간 제한 설정이 있습니다.

   New Relic은 자동으로 기본값을 3일로 설정하고 첫 번째 알림에 대해 기본 설정을 사용할 것을 권장합니다.

   신호가 데이터를 반환하지 않을 때 열려 있는 공지 이벤트를 닫는 또 다른 방법은 loss of signal 레버 값, 릴레이를 구성하는 것입니다. 자세한 내용은 위의 '신호 끊김, 그 이유' 섹션을 참조하십시오.

귀하는 WebPortal 의 지연 시간 문제가 있는지 알려주는 공지 조건을 작성하고 있으므로 개발자가 이 공지 이벤트에 대한 알림을 받을 때 필요한 모든 정보를 갖고 있는지 확인하고 싶습니다. 공지 이벤트가 생성되면 팀 Slack 채널에 공지하기 위해 워크플로우를 사용하게 됩니다.

우리 문서 에서 사용자 정의 공지 이벤트 설명에 대해 자세히 알아보세요.

/ <img title="공지 세부사항 페이지" alt="공지 조건 생성의 마지막 단계를 묘사한 스크린샷 공지 세부사항 페이지" src="/images/alerts_screenshot-crop_adding-공지-details-to-an-공지 조건.webp" /> /

제목 템플릿 사용은 선택 사항이지만 사용을 권장합니다. 공지 조건은 귀하가 감시하고자 하는 오래된 값, 릴레이의 집합을 정의합니다. 해당 레버 값 중 하나라도 위반되면 공지 이벤트가 생성됩니다. 의미 있는 제목 템플릿을 사용하면 문제를 정확히 파악하고 장애를 더 빠르게 해결할 수 있습니다.

문서 에서 제목 템플릿에 대해 자세히 알아보세요.

조사, 분류 또는 수정 단계를 자세히 설명하는 운영 런북이 이 필드에 연결되어 있는 경우가 많습니다.