NRQL 알람 조건 생성

NRQL 알림 조건을 사용해 알림을 생성할 것을 권장합니다. 이 문서는 효율성을 극대화하고 알림 노이즈를 줄일 수 있도록 NRQL 알림 조건을 생성 및 구성하는 과정을 설명합니다. 막 뉴렐릭을 시작했거나, 아직 알림 조건을 생성하지 않았다면 알림 조건으로 시작하는 것이 좋습니다.

다음과 같은 방법으로 알림 조건을 생성할 수 있습니다.

• 차트
• 정책 페이지
• Alert coverage gaps 페이지

다음 알림 빌더 중 하나를 사용할 수도 있습니다.

• Write your own query(자체 쿼리)를 작성해 처음부터 알림을 구축합니다.
• Use Guided mode(안내 설치)에서 권장 옵션을 선택해 NRQL 쿼리를 작성합니다.

차트, 자체 쿼리, 어떤 것을 사용해 알림 조건을 생성하는지에 관계없이 NRQL은 신호를 정의하고 한도 값을 설정할 수 있는 기본 요소가 되어줍니다.

NRQL 알람 구문

다음은 모든 NRQL 알람 조건을 생성하기 위한 기본 구문입니다.

SELECT function(attribute)
FROM Event
WHERE attribute [comparison] [AND|OR ...]

호환되지 않는 NRQL 포맷

차트에 사용되는 NRQL의 일부 요소는 스트리밍 알림의 문맥에서 보면 아무런 의미가 없습니다. 다음은 동일한 효과를 얻기 위해 NRQL 알림 쿼리를 다시 포맷하기 위한 가장 일반적인 비호환 요소와 제안 목록입니다.

SELECT percentile(largestContentfulPaint, 75)
FROM PageViewTiming
WHERE (appId = 837807) SINCE yesterday

SELECT count(foo), average(bar), max(baz)
FROM Transaction

SELECT count(foo) FROM Transaction

SELECT average(bar) FROM Transaction

SELECT max(baz) FROM Transaction

SELECT count(*)
FROM Transaction
TIMESERIES 1 minute SLIDE BY 5 minutes

NRQL 알람 임계값 예

다음은 NRQL 조건에 대한 몇 가지 일반적인 사용 사례입니다. 이러한 쿼리는 정적 및 이상 조건 유형에서 작동합니다.

SELECT average(duration)
FROM Transaction
WHERE account_id IN (91290, 102021, 20230)

SELECT percentile(duration, 95)
FROM Transaction
WHERE name LIKE 'Controller/checkout/%'

SELECT percentile(duration, 95)
FROM Transaction

SELECT percentile(databaseDuration, 75)
FROM Transaction

SELECT max(duration)
FROM Transaction

SELECT min(duration)
FROM Transaction

SELECT average(duration)
FROM Transaction

SELECT percentage(count(*), WHERE duration > 2)
FROM Transaction

SELECT percentage(count(*), WHERE http.statusCode = '500')
FROM Transaction

SELECT apdex(duration, t:0.5)
FROM Transaction
WHERE appName LIKE '%prod%'

NRQL 조건 및 쿼리 작업 순서

기본적으로 집계 기간은 1분이지만 필요에 따라 기간을 변경할 수 있습니다. 집계 기간과 상관없이 뉴렐릭은 NRQL 조건 쿼리의 함수를 사용해 해당 기간에 대한 데이터를 수집합니다. 쿼리는 뉴렐릭 시스템에서 다음 순서로 구문 분석되고 실행됩니다.

1. FROM 절. 어떤 이벤트 유형을 가져와야 하는가?
2. WHERE 절. 무엇을 필터링할 수 있는가?
3. SELECT 절. 이제 필터링된 데이터 세트에서 어떤 정보를 반환해야 하는가?

예: null 값이 반환됨

이것이 알람 조건 쿼리라고 가정해 보겠습니다.

SELECT count(*)
FROM SyntheticCheck
WHERE monitorName = 'My Cool Monitor' AND result = 'FAILED'

집계 창에 오류가 없는 경우:

1. 시스템은 계정에서 모든 SyntheticCheck 이벤트를 가져와서 FROM 조항을 실행합니다.
2. 그런 다음 WHERE 조항을 실행하여 지정된 모니터 이름 및 결과와 일치하는 이벤트만 찾아 해당 이벤트를 필터링합니다.
3. FROM 및 WHERE 작업을 완료한 후에도 스캔할 이벤트가 남아 있으면 SELECT 절이 실행됩니다. 남은 이벤트가 없으면 SELECT 절이 실행되지 않습니다.

즉, count() 및 uniqueCount() 같은 집계자는 0 값을 반환하지 않습니다. 개수가 0이면 SELECT 조항이 무시되고 데이터가 반환되지 않으므로 NULL 값이 반환됩니다.

예: 0 값이 반환됨

합법적인 숫자 0을 제공하는 데이터 원본이 있는 경우 쿼리는 null 값이 아닌 0 값을 반환합니다.

이것이 알림 조건 쿼리이고 MyCoolEvent가 때때로 0 값을 반환할 수 있는 속성이라고 가정해 보겠습니다.

SELECT average(MyCoolAttribute)
FROM MyCoolEvent

평가 중인 집계 창에 MyCoolEvent 인스턴스가 하나 이상 있고 해당 창의 모든 MyCoolAttribute 속성 평균 값이 0이면 0 값이 반환됩니다. 해당 분 동안 MyCoolEvent 이벤트가 없으면 작업 순서로 인해 NULL이 반환됩니다.

예: null vs. 0 값이 반환됨

null 값을 처리하는 방법을 결정하려면 alerts 조건 UI에서 신호 손실 및 간격 채우기 설정을 조정합니다.

연산의 쿼리 순서 바로 가기를 이용하면 NULL 값을 완전히 피할 수 있습니다. 이렇게 하려면 filter 하위 절을 사용한 다음, 해당 하위 절 내의 모든 필터 요소를 포함시켜야 합니다. 쿼리의 본문에는 하나 이상의 엔터티를 정의하는 WHERE절이 포함되어야 하므로, 모니터가 검사를 수행하는 집계 창에서 신호가 해당 엔터티에 연결됩니다. 그런 다음 SELECT 절이 실행되고 필터 요소를 쿼리의 본문에서 반환된 데이터에 적용합니다. 필터 요소 결과 일치하는 데이터가 없으면 0 값을 반환합니다.

다음은 FAILED 결과에 대한 알림의 예입니다.

SELECT filter(count(*), WHERE result = 'FAILED')
FROM SyntheticCheck
WHERE monitorName = 'My Favorite Monitor'

이 예에서 성공적인 결과가 있는 창은 0을 반환하여 조건의 임계값이 자체적으로 해결되도록 합니다.

자세한 내용은 0 vs. null 값 문제 해결에 대한 블로그 게시물을 확인하십시오.

중첩 집계 NRQL 알람

중첩 집계 쿼리는 데이터를 쿼리하는 강력한 방법입니다. 그러나 주의해야 할 몇 가지 제한 사항이 있습니다.

SELECT max(cpu)
FROM
  (
    SELECT min(cpuPercent) AS 'cpu'
    FROM SystemSample
    FACET hostname
  )

SELECT max(cpu)
FROM
  (
    SELECT min(cpuTime) AS cpu TIMESERIES 30 seconds
    FROM Event
  )

NRQL 조건 생성 팁

다음은 NRQL 조건을 만들고 사용하기 위한 몇 가지 팁입니다.

조건에 대한 태그 관리

기존 NRQL 조건을 수정할 때 조건 엔터티와 연관된 태그를 추가하거나 제거할 수 있는 옵션이 있습니다. 이를 위해서는 조건 이름 아래에 있는 Manage tags 버튼을 클릭합니다. 팝업 메뉴에서 태그를 추가하거나 삭제합니다.

조건 편집은 조건 평가를 재설정할 수 있습니다.

NRQL 알람 조건을 특정 방식으로 편집하면(아래에 자세히 설명됨) 해당 평가가 재설정됩니다. 즉, 해당 지점까지의 모든 평가가 손실되고 해당 지점부터 평가가 다시 시작됩니다. 이것이 영향을 미치는 두 가지 방법은 다음과 같습니다.

• ‘최소 x분 동안’ 임계값의 경우: 평가 기간이 재설정되었기 때문에 인시던트가 보고되기 전에 최소 x분의 지연이 있습니다.
• 이상 조건의 경우: 조건이 다시 시작되고 모든 학습된 이상이 손실됩니다.

다음 작업은 NRQL 조건에 대한 평가 재설정을 유발합니다.

• 쿼리 변경
• 집계 창, 집계 방법 또는 집계 지연/타이머 설정 변경
• ‘신호 손실 시 인시던트 닫기(close incidents on signal loss)’ 설정 변경
• 간격 채우기 설정 변경
• 이상 방향 변경(해당되는 경우)- higher, lower, 또는 higher/lower
• 임계값, 임계값 창 또는 임계값 연산자 변경
• 슬라이드 바이 간격 변경( 슬라이딩 창 집계 조건에서만)

다음 작업(위 목록에서 다루지 않은 다른 작업과 함께)은 평가를 재설정하지 않습니다.

• 신호 손실 기간 변경(만료 기간)
• 시간 기능 변경 ("for at least(최소)"에서 "at least once in(동안 최소 한 번)"으로 또는 그 반대로 전환)
• ‘신호 손실 시 인시던트 열기(open incident on signal loss)’ 설정 변경

alerts 조건 유형

NRQL 알림을 생성할 때 다양한 유형의 조건 중에서 선택할 수 있습니다.

신호 손실 임계값 설정

신호 손실은 특정 기간 동안 NRQL 조건과 일치하는 데이터가 없을 때 발생합니다. 신호 손실 임계값 지속 시간과 임계값을 초과할 때 발생하는 작업을 설정할 수 있습니다.

GraphQL API(권장) 또는 REST API를 사용하여 이러한 설정을 관리할 수도 있습니다. 특정 GraphQL API 예시를 보려면 여기로 이동하십시오.

Loss of signal settings:

신호 손실 설정에는 지속 시간과 몇 가지 가능한 조치가 포함됩니다.

• Signal loss expiration time

  • UI 라벨: Signal is lost after:
  • GraphQL 노드: expiration.expirationDuration
  • 만료 기간은 스트리밍 alerts 파이프라인에서 데이터 포인트를 수신할 때 시작되고 재설정되는 타이머입니다. '만료 시간'이 만료되기 전에 다른 데이터 포인트를 받지 못하면 해당 신호가 손실된 것으로 간주합니다. 이는 데이터가 뉴렐릭으로 전송되지 않거나 NRQL 쿼리의 WHERE 절이 alerts 파이프라인으로 스트리밍되기 전에 해당 데이터를 필터링하기 때문일 수 있습니다. 패싯 쿼리가 있는 경우 각 패싯은 신호입니다. 따라서 이러한 신호 중 하나가 지정된 기간 동안 종료되면 신호 손실로 간주됩니다.
  • 신호 손실 만료 시간은 임계값 지속 시간과는 무관하며 타이머가 만료되는 즉시 트리거됩니다.
  • 최대 만료 기간은 48시간입니다. 이는 간헐적 작업의 실행을 모니터링할 때 유용합니다. 최소 시간은 30초이지만 최소 3-5분을 사용하는 것을 권장합니다.

• Loss of signal actions

  신호가 손실된 것으로 간주되는 경우 몇 가지 옵션이 존재합니다.

  • 현재 열려 있는 모든 인시던트 닫기: 특정 신호와 관련된 모든 열려 있는 인시던트가 닫힙니다. 조건에 따라 다르며 모든 인시던트가 닫히지는 않습니다. 일시적인 서비스나 산발적인 신호에 대해 알림을 보내는 경우 인시던트가 제대로 닫히도록 이 조치를 선택하는 것이 좋습니다. 이에 대한 GraphQL 노드 이름은 closeViolationsOnExpiration 입니다.
  • 새로운 인지던트 열기: 신호가 끊어진 것으로 간주되면 새로운 인지던트가 열립니다. 이 인시던트는 신호 손실로 인해 발생했음을 나타냅니다. 인시던트 기본 설정에 따라 알림이 트리거됩니다. 이에 대한 graphQL 노드 이름은 openViolationOnExpiration 입니다.
  • 위의 두 조치를 모두 활성화하면, 먼저 열려 있는 모든 인시던트를 닫은 다음 신호 손실에 대한 새 인시던트를 열어야 합니다.
  • 예상된 종료인 경우에는 '신호 손실' 인시던트를 열면 안됩니다. 신호 종료가 예상되는 경우 새 인시던트를 열지 않도록 선택할 수 있습니다. 이 기능은 특정 시간에 신호가 손실될 것임을 알고 있고, 그 신호 손실에 대해 새로운 인시던트를 열고 싶지 않을 때 유용합니다. 이에 대한 GraphQL 노드 이름은 ignoreOnExpectedTermination입니다.

UI에서 신호 손실 감지로 구성된 NRQL 알람을 생성하려면:

1. 지침에 따라 NRQL 알림 조건을 생성합니다.
2. Set thresholds 단계에서 Add lost signal threshold 옵션을 찾을 수 있습니다. 이 버튼을 클릭합니다.
3. Consider the signal lost after 필드에서 신호 만료 기간을 분 또는 초 단위로 설정합니다.
4. 신호가 손실되었을 때 수행할 작업을 선택합니다. 다음 옵션 중 하나 또는 전체를 선택할 수 있습니다: Close all current open incidents, Open new "lost signal" incident, Do not open "lost signal" incident on expected termination. 이를 통해 해당 조건에서 신호 인시던트의 손실이 처리되는 방법을 정할 수 있습니다.
5. 선택적으로 정적/이상치의 한도를 추가하거나 제거할 수 있습니다. 신호 손실 한도만 있고 정적/이상치 한도가 없는 조건은 유효하며, '독립된' 신호 손실 조건으로 간주됩니다.

6. 단계에 계속해 조건을 저장합니다.
7. Do not open "lost signal" incident on expected termination을 선택한 경우, 엔터티에 termination: expected 태그를 추가해야 신호 손실 인시던트가 열리는 것을 방지할 수 있습니다. 태그를 엔터티에 직접 추가하는 방법을 확인하십시오.

다음과 같은 경우 신호 손실이 닫히면 인시던트가 열립니다.

• 신호가 되돌아 온 경우. 새로 열린 신호 손실 인시던트는 새 데이터가 평가되는 즉시 닫힙니다.
• 그들이 속한 조건이 만료됩니다. 기본적으로 조건은 3일 후에 만료됩니다.
• Close all current open incidents 옵션을 사용하여 인시던트를 수동으로 종료합니다.

고급 신호 설정

NRQL 조건을 만들 때 몇 가지 사용할 수 있는 고급 신호 설정이 있습니다.

• 집계 기간
• 슬라이딩 창 집계
• 스트리밍 방식
• 지연/타이머
• 데이터 공백 채우기
• 평가 지연

이러한 설정이 무엇이며 서로 어떻게 관련되는지에 대한 자세한 설명은 스트리밍 알림 개념을 참조하십시오. 다음은 구성 방법에 대한 지침과 팁입니다.

집계 기간

집계 창 기간을 설정하여 데이터가 집계되기 전에 스트리밍 시간 창에서 데이터가 누적되는 기간을 선택할 수 있습니다. 30초에서 120분 사이로 설정할 수 있으며, 기본값은 1분입니다.

슬라이딩 창 집계

슬라이딩 창을 사용하여 더 매끄러운 차트를 만들 수 있습니다. 이 작업은 겹치는 데이터 창을 만들어 수행됩니다.

이 짧은 비디오(2분 30분)에서 슬라이딩 창을 설정하는 방법을 알아보십시오.

활성화되면 "간격별 슬라이드"를 설정하여 집계된 창의 중첩 시간을 제어합니다. 간격은 집계 창보다 짧아야 하며 균등하게 분할되어야 합니다.

스트리밍 방식

세 가지 스트리밍 집계 방법 중에서 선택하여 각 조건에 대한 최상의 평가 결과를 얻을 수 있습니다.

지연/타이머

지연/타이머를 조정하여 스트리밍 알림 알고리즘을 데이터 동작과 조정할 수 있습니다. 데이터가 희박하거나 일관성이 없는 경우, 이벤트 타이머 집계 방법을 사용할 수 있습니다.

케이던스 방법의 경우 지원되는 총 레이턴시는 집계 창 지속 시간과 지연 시간의 합계입니다.

데이터 유형이 APM 언어 에이전트에서 제공되고 많은 앱 인스턴스(예: Transaction, TransactionError 등)에서 집계되는 경우 기본 설정으로 이벤트 흐름 메서드를 사용하는 것이 좋습니다.

데이터 공백 채우기

공백 채우기를 사용하면 신호에 데이터가 없을 때 사용할 값을 사용자 지정할 수 있습니다. 다음 설정 중 하나로 데이터 스트림의 공백을 채울 수 있습니다.

• None: (기본값) 빈 집계 기간에 어떤 작업도 수행하지 않으려면 선택합니다. 평가 후, 빈 집계 기간이 임계값 기간 타이머를 재설정합니다. 예를 들어 조건에 모든 집계 기간에 5분 동안 임계값 이상의 데이터 포인트가 있어야 하고 집계 기간 5개 중 1개가 비어 있는 경우 이 조건은 인시던트가 아닙니다.
• Custom static value: 평가되기 전에 빈 집계 기간에 맞춤 정적 값을 삽입하려면 이 옵션을 선택합니다. 이 옵션에는 사용해야 하는 정적 값을 지정하는 추가적인 필수 매개변수 fillValue(API 에 명명)가 있습니다. 기본값은 0 입니다.
• Last known value: 이 옵션은 평가가 이뤄지기 전에 마지막으로 본 값을 삽입합니다. 뉴렐릭은 마지막으로 본 값의 상태를 최소 2시간 동안 유지합니다. 설정된 임계값 기간이 2시간을 넘어가는 경우 이 값이 해당 기간 동안 유지됩니다.

데이터 간격 설정 편집 옵션:

• NRQL 조건 UI에서 Condition settings > Advanced signal settings > fill data gaps with로 이동하여 옵션을 선택합니다.
• Nerdgraph API(선호)를 사용하는 경우 이 노드는 다음 위치에 있습니다. actor : account : alerts : nrqlCondition : signal : fillOption | fillValue
• NerdGraph는 이에 대한 권장 API이지만 REST API를 사용하는 경우, REST 탐색기의"signal" Alert NRQL conditions API 섹션 아래에서 이 설정을 찾을 수 있습니다.

평가 지연

Use evaluation delay 플래그를 활성화하고 최대 120분을 설정하여 유입되는 신호에 대한 평가를 지연시킬 수 있습니다.

새 엔터티가 처음 배포되면 엔터티의 리소스 사용률이 비정상적으로 높은 경우가 많습니다. 자동으로 규모가 조정되는 오토스케일 환경에서는 이로 인해 많은 잘못된 알림이 생성될 수 있습니다. 새 엔터티에서 내보낸 신호에 대한 알림 검색 시작을 지연하면 오케스트레이션 또는 오토스케일 환경에서 배포와 관련된 잘못된 알림의 수를 크게 줄일 수 있습니다.

평가 지연 활성화를 위한 옵션:

• NRQL 조건 UI에서 Adjust to signal behavior > Use evaluation delay로 이동합니다.
• Nerdgraph API를 사용하는 경우 이 노드는 다음 위치에 있습니다. actor : account : alerts : nrqlCondition : signal : evaluationDelay

안내 모드의 HNR NRQL 조건

NRQL 조건 안내 모드는 보다 쉽게 인프라 'host not reporting'(HNR) NRQL 조건을 생성하는 방법을 제공합니다. 이는 인프라 'host no reporting' 조건을 생성하는 것보다 선호되는 방법입니다.