NRQL 알림 조건을 사용해 알림을 생성할 것을 권장합니다. 이 문서는 효율성을 극대화하고 알림 노이즈를 줄일 수 있도록 NRQL 알림 조건을 생성 및 구성하는 과정을 설명합니다. 막 뉴렐릭을 시작했거나, 아직 알림 조건을 생성하지 않았다면 알림 조건으로 시작하는 것이 좋습니다.
다음과 같은 방법으로 알림 조건을 생성할 수 있습니다.
다음 알림 빌더 중 하나를 사용할 수도 있습니다.
- Write your own query(자체 쿼리)를 작성해 처음부터 알림을 구축합니다.
- Use Guided mode(안내 설치)에서 권장 옵션을 선택해 NRQL 쿼리를 작성합니다.
차트, 자체 쿼리, 어떤 것을 사용해 알림 조건을 생성하는지에 관계없이 NRQL은 신호를 정의하고 한도 값을 설정할 수 있는 기본 요소가 되어줍니다.
NRQL 알람 구문
다음은 모든 NRQL 알람 조건을 생성하기 위한 기본 구문입니다.
SELECT function(attribute) FROM Event WHERE attribute [comparison] [AND|OR ...]
Clause | Notes |
---|---|
Required | 다음과 같이 숫자를 반환하며 지원되는 함수가 포함됩니다.
|
Required | 여러 데이터 유형을 대상으로 할 수 있습니다. 지원되는 데이터 유형:
|
|
|
| 임계값 유형(정적 또는 이상)에 따라 NRQL 구문에 선택적으로
패싯 쿼리는 정적 및 이상 조건에 대해 최대 5,000개의 값을 반환할 수 있습니다. 중요쿼리가 최대 값보다 많은 값을 반환하면 알람 조건을 생성할 수 없습니다. 조건을 만들고 쿼리가 나중에 이 숫자보다 더 많이 반환하면 알람이 실패합니다. 더 적은 수의 값을 반환하도록 쿼리를 수정합니다. |
호환되지 않는 NRQL 포맷
차트에 사용되는 NRQL의 일부 요소는 스트리밍 알림의 문맥에서 보면 아무런 의미가 없습니다. 다음은 동일한 효과를 얻기 위해 NRQL 알림 쿼리를 다시 포맷하기 위한 가장 일반적인 비호환 요소와 제안 목록입니다.
Element | Notes |
---|---|
| 예:
NRQL 조건은 창 쿼리 결과의 끝없는 스트림을 생성하므로 쿼리 범위를 지정하는 |
| NRQL 쿼리에서 NRQL 조건의 경우 슬라이딩 윈도우 집계를 사용하지 않는 경우 |
|
|
| 이 기능은 NRQL 알림에 대해 아직 지원되지 않습니다. |
다중 집계 함수 | 각 조건은 집계된 단일 값만 타깃팅할 수 있습니다. 여러 값에 대해 동시에 알림을 보내려면 동일한 정책 내에서 개별 조건으로 분해해야 합니다. 기존 쿼리:
분해:
|
|
|
|
UI에서 슬라이딩 창을 활성화할 수 있습니다. 조건을 생성하거나 수정하려면, Adjust to signal behavior > Data aggregation settings > Use sliding window aggregation으로 이동합니다. 예를 들어 다음과 같은 알림 조건을 생성하려면
1분의 슬라이딩 윈도우 집계와 함께 5분의 데이터 집계 기간을 사용합니다. |
| NRQL 쿼리에서
|
하위 쿼리 | 하위 쿼리를 실행하려면 데이터를 여러 번 통과해야 하기 때문에, 하위 쿼리는 스트리밍과 함께 사용할 수 없습니다. |
하위 쿼리 JOIN | 하위 쿼리를 실행하려면 데이터를 여러 번 통과해야 하기 때문에 하위 쿼리 JOINS는 스트리밍 알림과 함께 사용할 수 없습니다. |
NRQL 알람 임계값 예
다음은 NRQL 조건에 대한 몇 가지 일반적인 사용 사례입니다. 이러한 쿼리는 정적 및 이상 조건 유형에서 작동합니다.
NRQL 조건 및 쿼리 작업 순서
기본적으로 집계 기간은 1분이지만 필요에 따라 기간을 변경할 수 있습니다. 집계 기간과 상관없이 뉴렐릭은 NRQL 조건 쿼리의 함수를 사용해 해당 기간에 대한 데이터를 수집합니다. 쿼리는 뉴렐릭 시스템에서 다음 순서로 구문 분석되고 실행됩니다.
FROM
절. 어떤 이벤트 유형을 가져와야 하는가?WHERE
절. 무엇을 필터링할 수 있는가?SELECT
절. 이제 필터링된 데이터 세트에서 어떤 정보를 반환해야 하는가?
예: null 값이 반환됨
이것이 알람 조건 쿼리라고 가정해 보겠습니다.
SELECT count(*) FROM SyntheticCheck WHERE monitorName = 'My Cool Monitor' AND result = 'FAILED'
집계 창에 오류가 없는 경우:
- 시스템은 계정에서 모든
SyntheticCheck
이벤트를 가져와서FROM
조항을 실행합니다. - 그런 다음
WHERE
조항을 실행하여 지정된 모니터 이름 및 결과와 일치하는 이벤트만 찾아 해당 이벤트를 필터링합니다. 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 알람
중첩 집계 쿼리는 데이터를 쿼리하는 강력한 방법입니다. 그러나 주의해야 할 몇 가지 제한 사항이 있습니다.
NRQL 조건 생성 팁
다음은 NRQL 조건을 만들고 사용하기 위한 몇 가지 팁입니다.
주제 | 팁 |
---|---|
조건 유형 | NRQL 조건 유형에는 정적 및 이상이 포함됩니다. |
설명 만들기 | NRQL 조건의 경우 각 인시던트에 추가할 커스텀 설명을 생성할 수 있습니다. 특정 인시던트의 메타데이터를 기반으로 하는 변수 대체를 통해 설명을 향상할 수 있습니다. |
쿼리 결과 | 쿼리는 숫자를 반환해야 합니다. 조건은 설정한 임계값에 대해 반환된 숫자를 평가합니다. |
기간 | NRQL 조건은 30초에서 120분까지 15초 단위로 집계 창을 사용하여 집계 방식에 따라 데이터를 평가합니다. 최상의 결과를 얻으려면 이벤트 흐름 또는 이벤트 타이머 집계 방법을 사용하는 것이 좋습니다. 케이던스 집계 방법의 경우, 평가할 분을 지정하는 암시적
|
신호 손실 임계값(신호 손실 감지) | 신호 손실 감지를 사용하면 데이터(텔레메트리 신호)가 손실된 것으로 간주되어야 하는 경우 알림을 전송할 수 있습니다. 신호 손실은 서비스 또는 엔터티가 더 이상 온라인 상태가 아니거나 정기적인 작업을 실행하는 데 실패했음을 의미할 수 있습니다. 또한 이를 사용해 신호가 수신되지 않을 때 오류 수 같은 산발적 데이터에 대한 인시던트가 닫히도록 할 수 있습니다. |
고급 신호 설정 | 이러한 설정은 때때로 누락될 수 있는 연속 스트리밍 데이터 신호를 보다 효과적으로 처리하기 위한 옵션을 제공합니다. 이러한 설정에는 집계 창 기간, 지연/타이머 및 데이터 간격 채우기 옵션이 포함됩니다. 사용에 대한 자세한 내용은 고급 신호 설정을 참조하십시오. |
조건 설정 | Condition settings를 사용해 다음을 설정합니다.
|
조건에 대한 한도 | 최대 값을 참조하십시오. |
상태 | NRQL 알림 상태 상태 표시가 제대로 작동하려면 쿼리 범위가 단일 엔터티로 지정되어야 합니다. 이렇게 하려면 WHERE 절(예: |
예 | 자세한 내용은 다음을 참조하십시오. |
조건에 대한 태그 관리
기존 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 alerts 조건 유형 | 설명 |
---|---|
Static(정적) | 이것은 NRQL 조건의 가장 간단한 유형입니다. 숫자 값을 반환하는 NRQL 쿼리를 기반으로 조건을 만들 수 있습니다. 선택 사항: |
Anomaly (Dynamic anomaly) | 모니터링된 값의 과거 동작을 기반으로 자체 조정 조건을 사용합니다. 선택적 |
신호 손실 임계값 설정
중요
신호 손실 기능은 신호 손실을 감지하기 전에 신호가 있어야 합니다. 신호가 없는 상태에서 조건을 활성화하면, 신호 손실이 감지되지 않고 신호 손실 기능이 활성화되지 않습니다.
신호 손실은 특정 기간 동안 NRQL 조건과 일치하는 데이터가 없을 때 발생합니다. 신호 손실 임계값 지속 시간과 임계값을 초과할 때 발생하는 작업을 설정할 수 있습니다.
one.newrelic.com > All capabilities > Alerts > Alert conditions (Policies)로 이동한 다음 + New alert condition으로 이동합니다. 신호 손실은 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’입니다.
- Open new incidents: 신호가 손실된 것으로 간주되면 새 인시던트를 엽니다. 이러한 인시던트는 신호 손실로 야기된 것이라고 표시됩니다. 인시던트 기본 설정에 따라 알림이 트리거됩니다. 이에 대한 GraphQL 노드 이름은 ‘openViolationOnExpiration’입니다.
- 위의 두 조치를 모두 활성화하면, 먼저 열려 있는 모든 인시던트를 닫은 다음 신호 손실에 대한 새 인시던트를 열어야 합니다.
- 예상된 종료인 경우에는 '신호 손실' 인시던트를 열면 안됩니다. 신호 종료가 예상되는 경우 새 인시던트를 열지 않도록 선택할 수 있습니다. 이 기능은 특정 시간에 신호가 손실될 것임을 알고 있고, 그 신호 손실에 대해 새로운 인시던트를 열고 싶지 않을 때 유용합니다. 이에 대한 GraphQL 노드 이름은
ignoreOnExpectedTermination
입니다.
중요
예상되는 종료 시 '신호 손실' 인시던트가 열리는 것을 방지하기 위해서는 엔터티에 태그 termination: expected
를 추가해야 합니다. 이 태그는 신호가 종료될 것으로 예상되었음을 알려줍니다. 태그를 엔터티에 직접 추가하는 방법을 확인하십시오.
UI에서 신호 손실 감지로 구성된 NRQL 알람을 생성하려면:
- 지침에 따라 NRQL 알림 조건을 생성합니다.
- Set thresholds 단계에서 Add lost signal threshold 옵션을 찾을 수 있습니다. 이 버튼을 클릭합니다.
- Consider the signal lost after 필드에서 신호 만료 기간을 분 또는 초 단위로 설정합니다.
- 신호가 손실되었을 때 수행할 작업을 선택합니다. 다음 옵션 중 하나 또는 전체를 선택할 수 있습니다: Close all current open incidents, Open new "lost signal" incident, Do not open "lost signal" incident on expected termination. 이를 통해 해당 조건에서 신호 인시던트의 손실이 처리되는 방법을 정할 수 있습니다.
- 선택적으로 정적/이상치의 한도를 추가하거나 제거할 수 있습니다. 신호 손실 한도만 있고 정적/이상치 한도가 없는 조건은 유효하며, '독립된' 신호 손실 조건으로 간주됩니다.
- 단계에 계속해 조건을 저장합니다.
- 'Do not open "lost signal" incident on expected termination'을 선택한 경우, 엔터티에
termination: expected
태그를 추가해야 신호 손실 인시던트가 열리는 것을 방지할 수 있습니다. 태그를 엔터티에 직접 추가하는 방법 확인하십시오.
팁
Open new "lost signal" incident와 Do not open "lost signal" incident on expected termination을 둘 다 true로 설정하는 경우가 있습니다. 예를 들면, 신호가 손실되면 항상 알림을 받고 싶지만 신호 손실이 예정된 경우에는 알림을 받고 싶지 않은 경우입니다. 이 경우, 두 가지 모두를 true로 설정하고, 신호가 손실될 것으로 예상되면 관련 엔터티에 termination: expected
태그를 추가합니다.
다음과 같은 경우 신호 손실이 닫히면 인시던트가 열립니다.
- 신호가 되돌아 온 경우. 새로 열린 신호 손실 인시던트는 새 데이터가 평가되는 즉시 닫힙니다.
- 그들이 속한 조건이 만료됩니다. 기본적으로 조건은 3일 후에 만료됩니다.
- Close all current open incidents 옵션을 사용하여 인시던트를 수동으로 종료합니다.
팁
신호 손실 감지는 중첩 집계 또는 하위 쿼리를 사용하는 NRQL 쿼리에서 작동하지 않습니다. 예:
고급 신호 설정
NRQL 알림 조건을 생성할 때, 고급 신호 설정을 사용하여 스트리밍 경보 데이터를 제어하고 잘못된 알림를 방지하십시오.
NRQL 조건을 만들 때 몇 가지 사용할 수 있는 고급 신호 설정이 있습니다.
- 집계 기간
- 슬라이딩 창 집계
- 스트리밍 방식
- 지연/타이머
- 데이터 공백 채우기
- 평가 지연
이러한 설정이 무엇이며 서로 어떻게 관련되는지에 대한 자세한 설명은 스트리밍 알림 개념을 참조하십시오. 다음은 구성 방법에 대한 지침과 팁입니다.
집계 기간
집계 창 기간을 설정하여 데이터가 집계되기 전에 스트리밍 시간 창에서 데이터가 누적되는 기간을 선택할 수 있습니다. 30초에서 120분 사이로 설정할 수 있으며, 기본값은 1분입니다.
슬라이딩 창 집계
슬라이딩 창을 사용하여 더 매끄러운 차트를 만들 수 있습니다. 이 작업은 겹치는 데이터 창을 만들어 수행됩니다.
이 짧은 비디오(2분 30분)에서 슬라이딩 창을 설정하는 방법을 알아보십시오.
활성화되면 "간격별 슬라이드"를 설정하여 집계된 창의 중첩 시간을 제어합니다. 간격은 집계 창보다 짧아야 하며 균등하게 분할되어야 합니다.
중요
새로운 슬라이딩 윈도우 알림 조건을 생성하거나 평가 재설정을 유발할 수 있는 작업을 수행한 직후, 조건은 첫 번째 집계 기간 동안 ‘집계 버퍼’를 구축할 시간이 필요합니다. 그 시간 동안에는 인시던트가 트리거되지 않습니다. 단일 집계 기간이 지나면 완전한 ‘버퍼’가 구축되고 조건이 정상적으로 작동합니다.
스트리밍 방식
세 가지 스트리밍 집계 방법 중에서 선택하여 각 조건에 대한 최상의 평가 결과를 얻을 수 있습니다.
지연/타이머
지연/타이머를 조정하여 스트리밍 알림 알고리즘을 데이터 동작과 조정할 수 있습니다. 데이터가 희박하거나 일관성이 없는 경우, 이벤트 타이머 집계 방법을 사용할 수 있습니다.
케이던스 방법의 경우 지원되는 총 레이턴시는 집계 창 지속 시간과 지연 시간의 합계입니다.
데이터 유형이 APM 언어 에이전트에서 제공되고 많은 앱 인스턴스(예: Transactions
, TransactionErrors
등)에서 집계되는 경우 기본 설정으로 이벤트 흐름 메서드를 사용하는 것이 좋습니다.
중요
AWS CloudWatch 또는 Azure 같은 인프라 클라우드 통합에서 수집한 데이터에 대한 NRQL 조건을 생성할 때는 이벤트 타이머 방식을 사용하는 것이 좋습니다.
데이터 공백 채우기
공백 채우기를 사용하면 신호에 데이터가 없을 때 사용할 값을 사용자 지정할 수 있습니다. 다음 설정 중 하나로 데이터 스트림의 공백을 채울 수 있습니다.
- None: (기본값) 빈 집계 기간에 어떤 작업도 수행하지 않으려면 선택합니다. 평가 후, 빈 집계 기간이 임계값 기간 타이머를 재설정합니다. 예를 들어 조건에 모든 집계 기간에 5분 동안 임계값 이상의 데이터 포인트가 있어야 하고 집계 기간 5개 중 1개가 비어 있는 경우 이 조건은 인시던트가 아닙니다.
- Custom static value: 평가되기 전에 빈 집계 기간에 맞춤 정적 값을 삽입하려면 이 옵션을 선택합니다. 이 옵션에는 사용해야 하는 정적 값을 지정하는 추가적인 필수 매개변수
fillValue
(API 에 명명)가 있습니다. 기본값은0
입니다. - Last known value: 이 옵션은 평가가 이뤄지기 전에 마지막으로 본 값을 삽입합니다. 뉴렐릭은 마지막으로 본 값의 상태를 최소 2시간 동안 유지합니다. 설정된 임계값 기간이 2시간을 넘어가는 경우 이 값이 해당 기간 동안 유지됩니다.
팁
알림 시스템은 능동적으로 보고되는 신호의 간극을 채웁니다. 이 신호 기록은 비활성 기간 후에 삭제되며 간극을 채울 수 있도록 비활성 기간 이후에 수신된 데이터 포인트는 새로운 신호로 처리됩니다. 비활성 기간은 2시간 또는 설정된 임계값 기간 중 더 긴 시간입니다.
신호 손실, 간극 채움에 대한 설명과 이 기능에 대한 액세스를 요청하는 방법은 이 Support Forum 게시물을 참조하십시오.
데이터 간격 설정 편집 옵션:
- 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' 조건을 생성하는 것보다 선호되는 방법입니다.