첫 번째 알림 만들기

먼저 Web transactions time 라벨이 붙은 차트로 이동하여 create an alert condition 클릭합니다.

공지 조건에 기술 이름을 부여하는 것이 중요합니다. 이 조건의 이름을 response time 으로 지정한 다음 완전히 다른 애플리케이션에 대한 또 다른 조건을 만들고 해당 조건에도 response time 라벨을 붙인다고 가정해 보겠습니다. 이런 일이 발생하면 어떤 조건이 어떤 것인지 구별할 수 없게 됩니다. 따라서 조건에 구체적이고 고유한 이름을 지정해야 합니다. 이 경우 이 조건의 이름을 Response time: Example-app 로 지정합니다.

조건의 이름을 지정한 후에는 원하는 경우 NRQL 쿼리를 변경할 수 있습니다. 첫 번째 알림의 경우 NRQL 쿼리를 조정하지 않고 이 섹션을 그대로 두는 것이 좋습니다. NRQL을 사용하여 쿼리를 사용자 지정하는 방법에 대해 자세히 알아보려면 문서 를 방문하십시오.

귀하의 팀에서는 이 공지 조건을 작성 중이므로 웹 프로세서 시간이 평소보다 오래 걸릴 경우 알림을 받게 됩니다. 그러나 웹 트랜잭션 시간이 얼마나 길어지는지는 신경 쓰지 않고 트랜잭션 시간이 비정상적으로 작동하는지 알고 싶다고 가정해 보겠습니다. 이 특정 사용 사례의 경우 anomaly threshold 사용하는 것이 좋습니다. 우리의 이상 감지 기능은 귀하의 데이터를 지속적으로 평가하여 시스템이 정상적으로 작동하는 방식을 이해합니다. 이상 실험 값을 설정하면 웹 프로세서 시간이 예상 성능에서 벗어나는 경우 이상 감지 기능을 사용하여 팀에 알릴 수 있습니다. 웹 프로세서 시간이 비정상적으로 작동하는지 여부만 알고 싶으므로 모든 공지를 원하므로 upper and lower 선택합니다. 그러나 웹 트랜잭션 시간이 평소보다 오래 걸릴 경우에만 알림을 받으려면 다음을 선택하세요. upper only.

다음으로 우선순위 수준을 설정해야 합니다. 우선순위 수준에 따라 공지 이벤트가 생성되는 항목이 결정됩니다. 첫 공지 시에는 우선순위 레벨을 critical 으로 설정하는 것을 권장합니다. 우선순위 수준에 대한 자세한 내용은 공지 조건 문서 에서 확인할 수 있습니다.

다음으로, critical anomaly threshold breach 을 정의하는 기준을 선택해야 합니다. 첫 번째 안내 사항으로는 기본 설정을 사용하시고 필요에 따라 조정하시는 것을 권장합니다. 따라서 설정에서 "쿼리가 예측값에서 for at least five minutes 3 standard deviations벗어난 값을 반환할 때 알림 이벤트가 열립니다"를 표시하도록 설정해 두세요.

이상 문서 에서 이상에 대해 자세히 알아보십시오.

/ <img title="Configure your anomaly thresholds" alt="A screenshot demonstrating how to configure custom anomalies" src="/images/alerts_screenshot-crop_configure-your-anomaly-thresholds.webp" /> /

이상 가리켜 값, 정적 레버 값과 달리, 기대감은 데이터 세트를 전체적으로 살펴보지 않고 시스템 기록을 기반으로 어떤 동작이 비정상적인지 결정합니다. 대신, 정적 레버 값은 시스템이 사용자가 설정한 기준과 다르게 동작할 때마다 공지 이벤트를 엽니다. 정적 알림, 임계값은 훨씬 더 사용자 정의가 가능하며, 데이터와 원하는 바를 명확하게 파악하고 있는 경우에 권장합니다.

NRQL 문서 에서 정적 경보 조건에 대해 자세히 알아보십시오.

때때로 수신 신호가 손실될 수 있는데, 이것이 단순한 지연인지 아니면 더 큰 문제의 징후인지 파악하는 것이 중요합니다. 우리의 lost signal threshold 시스템이 마지막 데이터 포인트가 감지된 시점부터 신호가 손실된 것으로 간주하기 전에 몇 초 동안 기다려야 하는지를 알려줍니다. 설정한 시간 제한 내에 신호가 반환되지 않으면 다음과 같은 몇 가지 옵션이 있습니다. 새 알림 이벤트를 열거나, 열려 있는 모든 알림 이벤트를 닫거나, 신호가 종료될 것으로 예상되는 시점에 알림 이벤트를 열지 않도록 설정할 수 있습니다. 여기를 클릭하여 신호 끊김, 변경 옵션에 대해 자세히 알아보세요.

분실된 신호 레버 값을 설정하려면 시스템에 대한 지식과 이해하려는 내용이 필요합니다. 웹 프로세서 시간의 경우, 뉴렐릭이 1분마다 신호를 수집한다고 가정해 보겠습니다. 신호 손실은 훨씬 더 큰 지연 시간 문제를 나타낼 수 있습니다. 따라서 편안한 수준으로 시간을 설정한 다음 open a new lost signal alert event 확인란을 선택하는 것이 좋습니다.

/ <img title="" alt="" src="/images/alerts_screenshot-crop_lost-signal-threshold.webp"/> /

/ <img title="Window duration" alt="A screenshot depicting advanced custom settings for an alert condition." src="/images/alerts_screenshot-crop_window-duration.webp" /> /

알림 조건에 대한 기간을 설정하면 New Relic이 데이터를 그룹화하는 방법을 알 수 있습니다. 1시간에 한 번씩 New Relic에 신호를 보내는 데이터 세트에 대한 경고 조건을 생성하는 경우 패턴과 비정상적인 동작을 발견하는 데 도움이 되므로 기간을 60분에 가깝게 설정하는 것이 좋습니다. 그러나 웹 트랜잭션 시간에 대한 경고 조건을 만들고 New Relic이 해당 데이터에 대한 신호를 매분 수집하는 경우 기간을 1분으로 설정하는 것이 좋습니다.

첫 번째 알림의 경우 기본 설정을 그대로 사용하는 것이 좋지만 알림 조건 생성에 익숙해질수록 자신의 경험에 따라 이러한 필드를 사용자 지정하는 것이 좋습니다.

하루 종일 데이터가 특수에서 뉴렐릭으로 스트리밍됩니다. 공지 이벤트에 대해 해당 데이터를 즉시 평가하는 대신 공지 조건은 aggregation window 이라는 기간 동안 데이터를 수집합니다. 추가적인 지연 시간을 통해 데이터 수집 윈도우가 적용되기 전에 더 느린 데이터 포인트가 도착할 수 있습니다.

슬라이딩 윈도우는 "뾰족한" 차트를 매끄럽게 만들어야 할 때 유용합니다. 일반적인 사용 사례 중 하나는 슬라이딩 윈도우를 사용하여 좁은 기간의 집계보다 롤링 집계가 더 중요한 경우 짧은 시간 동안 많은 변동이 있는 선 그래프를 매끄럽게 만드는 것입니다.

꾸준하고 일관된 데이터 스트림을 기대하지 않지만 데이터의 급감과 급증이 예상되는 경우 슬라이딩 윈도우 집계를 사용하는 것이 좋습니다.

이 NRQL 자습서 또는 이 비디오를 시청하여 슬라이딩 윈도우 집계에 대해 자세히 알아볼 수 있습니다.

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

지연 기능은 일관성 없는 데이터 수집으로부터 사용자를 보호합니다. 이는 공지 이벤트 생성을 결정하기 전에 공지 조건에 약간의 흔들림 공간을 제공합니다. 만약 특정 시점에 데이터가 단 1분 동안만 뉴렐릭에 타임스탬프와 함께 도착한다면, 낮은 지연 설정으로도 충분합니다. 반면에, 해당 1분 동안 뉴렐릭이 몇 분 전이나 몇 분 후의 타임스탬프 데이터 포인트를 수신하는 경우 신호가 더 불안정해지므로 더 높은 지연 설정이 필요합니다.

우리는 웹 프로세서 시간과 관련된 지연시간 문제를 우리 팀에 알리기 위해 공지 조건을 만들고 있습니다. 이 경우 우리의 계약은 지속적으로 뉴렐릭 데이터를 전송합니다. 우리의 특수에서 뉴렐릭으로 지속적인 신호 흐름이 전송되고 있으며 신호에 예상되는 공백이 없으므로 공백 채우기 전략을 선택할 필요가 없습니다. 이 사용 사례와 첫 번째 공지의 경우 gap-filling strategy 를 none 로 설정된 상태로 두는 것이 좋습니다.

24시간마다 한 번씩 New Relic에 신호를 보내는 일관되지 않은 데이터 세트가 있는 경우 팀의 특정 요구 사항에 따라 이 기능을 사용자 지정하는 것이 좋습니다.

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

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

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

이 공지 조건에 대한 새로운 정책을 만들고 싶다면 지금이 기회입니다. 정책은 코어플로우와 연결되어 공지 이벤트에 대한 알림 빈도를 제어한다는 점을 기억하세요. 웹과 관련된 문제를 최대한 빨리 파악하는 것과 개발자가 정보 과부하로 인해 피로감을 느끼고 중요한 정보를 놓치기 시작하지 않도록 너무 많은 알림을 받지 않도록 하는 것 사이에는 미묘한 균형이 필요합니다.

정책은 하나 이상의 조건을 보유할 수 있습니다. 웹 트랜잭션 대기 시간을 모니터링하려는 경우 몇 가지 옵션이 있습니다.

첫째, 정책당 하나의 이슈만 연결하는 정책을 생성할 수 있습니다(기본 옵션). 정책당 하나의 이슈만 다루면 혼란을 줄일 수 있을 뿐 아니라 즉각적인 조치가 필요합니다. 하지만 이는 Response time: Example app 뿐만 아니라 이 정책에 여러 조건을 연결한 경우, 어떤 경우에도 이 정책의 모든 공지 이벤트가 하나의 이슈로 그룹화된다는 것을 의미합니다.

또는 각 조건별로 이슈를 하나씩 생성할 수도 있습니다. 즉, Response time: Example app 조건이 공지 이벤트를 열 때마다 해당 모든 공지 이벤트가 우리 조건과 연결된 하나의 이슈로 통합됩니다. 이 특정 사용 사례의 경우 웹 프로세서 시간으로 지연시간 문제를 모니터링하는 주요 목표를 충족하기 때문에 이 옵션을 선택해야 합니다.

아니면 모든 공지 이벤트에 대해 이슈를 생성할 수도 있습니다. 이 옵션은 가장 시끄럽지만 외부 시스템으로 정보를 전송하려는 경우에 효과적일 수 있습니다.

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

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

예를 들어, 위반 행위가 "웹 프로세서 시간이 .50보다 길다"인 경우 5분에 한 번씩 초"라는 메시지가 표시되면 웹 프로세서 시간이 .50 이하일 때 공지 이벤트가 자동으로 종료됩니다. 5분 동안 연속으로.

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

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

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

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

   자동으로 기본값은 3일이며 첫 번째 알림에는 기본 설정을 사용하는 것이 좋습니다.

우리는 웹 프로세서 시간에 지연 시간 문제가 있는지 알려주는 공지 조건을 만들고 있으므로 개발자가 이 공지 이벤트에 대한 알림을 받을 때 필요한 모든 정보를 갖고 있는지 확인하고 싶습니다. 공지 이벤트가 생성되면 팀 Slack 채널에 공지하기 위해 플로우플로우를 사용해보겠습니다.

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

Runbook에 연결하려는 경우 Runbook URL 필드에 URL을 입력할 수 있습니다.