알림을 사용하면 문제가 심각해지기 전에 문제 감지를 시작할 수 있습니다. 뉴렐릭 쿼리 언어인 NRQL 사용하면 가장 관심 있는 내용에 초점을 맞춘 공지 조건을 만들고 맞춤 설정할 수 있습니다. 사용하면 데이터의 비정상적인 동작에 대한 업데이트를 받고, 이를 확인해야 하는 사람들에게 공지를 전달하고, 문제의 근본 원인을 파악하면서 효과적인 결정을 내릴 수 있습니다.
경고 응답, 유지 관리, 품질 및 고급 설정을 가장 잘 사용하는 방법에 대한 권장 사항을 사용하여 경고 적용 범위를 개선하세요. 알림 품질을 측정하고 개선하는 방법을 알아보려면 알림 품질 관리 가이드를 참조하세요.
이러한 권장 조치에 따라 경고 구성을 개선하고 최대한 활용할 수 있습니다.
팁
아직 첫 번째 경고를 만들었습니까? 그렇지 않은 경우 시작하는 데 필요한 모든 단계에 대한 자습서 시리즈를 확인하십시오.
경고 응답 개선
어떻게 해야 하나요 | 혜택 |
|---|---|
경고에 대한 설명 이름이 있어야 합니다. | 설명과 태그는 어떤 서비스가 잘못되었는지, 어떤 환경이 관련되어 있는지, 어떤 팀이 소유하고 있는지, 최종 사용자에게 영향을 주는지 알 수 있도록 자기 설명적인 경고를 제공해야 합니다. 그것은 당신이 더 빨리 대답하고 무엇을 해야할지 결정하는 데 도움이 됩니다. |
알림 조건에 태그 추가 | 문제 및 인시던트에는 메타데이터에 이러한 태그가 있습니다. 이를 사용하여 워크플로우에서 유연한 필터를 수행하거나 알림 페이로드에 추가하십시오. 문제에는 3가지 태그 소스가 있습니다.
|
경고 조건 분류 | 조직 전체에서 경고 범주, 알림 처리에 대한 기대치 및 고유한 대상을 정의합니다. 예를 들어 Slack에 능동적으로 대응하여 사건이 발생하기 전에 알립니다. PagerDuty에 반응하여 진행 중인 사건을 감지하고 통지합니다. 또는 Jira에 정보를 제공합니다. |
커뮤니케이션 및 에스컬레이션 방법 정의 | |
담당 팀 추가 | 이 팀은 첫 번째 알림 처리를 담당합니다. |
모든 경고 조건에 Runbook URL 추가 | Runbook은 따라야 할 수정 단계와 참여하거나 에스컬레이션할 사람을 설명해야 합니다. |
강화사용 | 문제에 특정한 추가 메트릭을 제공하여 경고 알림의 우선 순위를 지정하고 분류합니다. |
알림 유지 관리 개선
어떻게 해야 하나요 | 혜택 |
|---|---|
정책구성 | 별도의 대상 또는 대상에 대한 정책을 생성하여 알림을 받는 것이 좋습니다. 각 팀의 초점에 맞게 엔터티, 서비스 또는 기술별로 그룹화하는 것을 고려하십시오. |
모든 경고 조건에 소유 팀 추가 | 소유 팀은 경고가 관련성을 유지하도록 보장합니다. 그들은 조건에 대한 모든 변경 사항을 승인합니다. |
경고 조건의 주기적 검토 일정 잡기 | 알림 개요 페이지를 사용하여 생성된 인시던트를 확인하고 수행할 작업을 결정합니다. 오래된 알림을 식별할 수 있도록 마지막 검토 날짜로 조건에 태그를 지정하는 것이 좋습니다. |
Terraform을사용하여 알림 생성 자동화 | 문서화되지 않은 변경을 방지하고 추적 가능성을 제거합니다. |
경고 품질 향상
어떻게 해야 하나요 | 혜택 |
|---|---|
보고서에 SLI 및 SLO 포함 | SLI 및 SLO 위반이 항상 인시던트인 것은 아니며 이를 방지하기 위한 단계를 문서화하지 않는 한 공지가 필요하지 않습니다. SLI/SLO 는 팀이 이벤트에 대응하기보다는 개선을 위해 집중해야 하는 영역을 강조할 수 있습니다. |
유지 보수 중알림 음소거 | 시끄러운 알림을 억제합니다. |
서비스에 대한 알림을 정의할 때 체계적으로 접근합니다. | 일관된 방식으로 전체 스택을 처리할 수 있도록 도와줍니다. 기술, 관련된 팀 등으로 알림을 구성할 수 있습니다. |
제안된 결정검토 | 매일 우리는 귀하의 경고 데이터를 분석하고 제안된 결정과 기존 결정에 대한 피드백을 제공합니다. 이것은 소음 감소를 향상시킬 것입니다. |
플래핑 경고 식별 및 조정 | 이러한 경고는 노이즈를 생성하는 잘못된 경고 조건 구성을 나타냅니다. 그들은 여전히 시스템에서 오래 지속되는 문제를 나타낼 수 있지만 이것은 사고가 아닙니다. |
임계값 또는 창 기간을 늘리고 슬라이딩 창 집계 사용 | 팀이 조치를 취하기 전에 자동으로 해결되는 알림은 받은 편지함을 어지럽히고 소음을 유발할 수 있습니다. 일시적인 급증을 확인하고 일시적인 급증을 완화하려면 대시보드를 사용하십시오. 귀하는 이것이 귀하의 사건 종결 에 미칠 영향을 이해하게 될 것입니다. |
사용 결정 | 의사 결정에 사용자 정의 태그와 메타데이터를 활용하십시오. 관련 사건은 하나의 포괄적인 문제 로 연결됩니다. 처음 시작할 때 기본 결정을 활성화된 상태로 유지하십시오. 몇 주 안에 이러한 결정의 효율성을 평가할 수 있습니다. |
결정을사용하는 경우 알림 유예 기간을 늘립니다. | 문제와 관련된 인시던트를 더 많이 받게 됩니다. 첫 번째 알림에서 더 풍부하고 실행 가능한 컨텍스트를 얻을 수 있습니다. 유예 기간이 길수록 알림이 늦어집니다. |
이슈 피드를주기적으로 검토 | Notified 열을 스크롤하여 모든 문제가 하나 이상의 대상으로 라우팅되는지 확인하세요. 라우팅이 필요하지 않은 경우 노이즈가 발생할 수 있으므로 조건을 제거하는 것이 좋습니다. |
경고 조건 생성 및 고급 설정
경고를 처음 사용하거나 경고 적용 범위를 최적화하는 제안이 필요한 경우 다음 권장 사항에 주의하십시오.
신호 이해
조건에 패싯 절이 포함된 경우 모든 경고 조건은 신호 또는 여러 신호를 생성합니다. 가능한 각 패싯 값은 고유한 신호를 생성합니다.
NrAiSignal 의 모든 신호를 쿼리할 수 있습니다. 이를 통해 관찰된 값, 고려된 데이터 포인트 수, 이상 조건의 경우 예상 값 및 표준 편차에 대한 세부 정보를 얻을 수 있습니다. 또한 조건을 생성할 때 가장 정확한 지연 설정을 찾는 데 도움이 될 수 있는 New Relic 시간과 원시 데이터 시간(데이터에 타임스탬프가 있는 경우) 사이의 시간 차이에 대한 정보도 제공합니다.
엔터티 상태 유지
신호를 사용하여 엔터티의 상태 및 경고 적용 범위를 추론합니다. 경고 조건의 결과에 하나의 엔터티의 데이터만 포함된 경우 New Relic은 이를 해당 엔터티의 상태에 연결하고 이러한 이벤트는 New Relic UI의 컨텍스트에 표시됩니다.
대부분의 조건에서 신호의 존재를 유지하는 것이 좋습니다. 신호가 없으면 New Relic이 일부 개체에 대해 회색(알 수 없음) 상태를 표시하고 이러한 개체를 적용되지 않는 개체 목록에 추가할 수 있습니다.
조건의 where 절에서 모든 데이터를 제외하면 데이터가 남지 않습니다. 이것은 New Relic에 대한 신호 손실 이며 경고 조건은 어떤 임계값에 대해서도 평가할 수 없습니다. 이는 NRQL 쿼리의 결과에 데이터가 없다는 것을 의미하지만 New Relic이 데이터를 수신하지 않는다는 의미는 아닙니다. 알림을 받으려면 신호 손실 임계값을 추가해야 합니다.
where 섹션에서 가장 일반적인 필터를 사용하고 select 섹션에서 가장 구체적인 필터를 사용하십시오. 필터 기능을 사용하여 관심있는 것을 정확하게 측정하십시오. 예를 들어:
Select filter(count(*), where ErrorCode=123) from Transaction where AppName='Application1' and Environment='Production'경고 지연 또는 타이머 기간
데이터 동작에 따라 지연/시간을 조정하십시오. 지연 시간이 짧으면 불완전한 데이터로 인해 잘못된 경고가 트리거될 수 있으며 지연 시간이 길면 알림을 받는 시간이 늘어날 수 있습니다. New Relic은 얼마나 많은 데이터가 예상되는지, 해당 데이터가 New Relic의 끝점에 얼마나 늦게 도달할지 모릅니다. 로그 전달자 및 구성에 따라 로그 데이터를 일괄 처리할 수 있으며 적은 양의 로그에 대해 상당한 지연이 발생할 수 있습니다.
조건 임계값 설정
의미 있는 임계값 수준을 설정하여 비즈니스에 대한 알림을 최적화하십시오. 다음은 몇 가지 권장 지침입니다.
동작 | 권장 사항 |
|---|---|
임계값 수준 설정 | 레버 값을 너무 낮게 설정하지 마십시오. 예를 들어 프로덕션 서버에서 CPU 조건을 5분 동안 75%로 설정하고 정기적으로 해당 수준을 초과하는 경우 조치할 수 없는 알림 또는 오탐이 발생할 가능성이 높아집니다. |
설정 실험 | 파일을 편집하거나 소프트웨어를 다시 시작할 필요가 없으므로 자유롭게 레버 값, 레일 레벨을 빠르게 변경하고 필요에 따라 조정하세요. |
설정 조정 | 시간이 지남에 따라 조건을 조정하십시오.
|
설정 비활성화 | 필요한 경우 정책에서 disable any condition 할 수 있습니다. 예를 들어, 다른 지표나 청년 값을 실험하는 동안 정책의 다른 조건을 계속 사용하려는 경우에 유용합니다. |
New Relic UI의 색상으로 구분된 상태 표시기는 경고 임계값이 높아지거나 정상으로 돌아오면 변경됩니다. 이를 통해 특정 알림을 받을 필요 없이 중요 임계값을 갖기 전에 UI를 통해 상황을 모니터링할 수 있습니다. 중요(빨간색) 및 경고(노란색)의 두 가지 인시던트 임계값이 있습니다. 위에서 언급한 제안을 염두에 두고 다양한 기준으로 이러한 임계값을 정의합니다.
일일 배치 작업 실행 확인
일괄 작업 실행에 실패할 경우 알림을 받도록 경고 조건을 설정할 수 있습니다.
배치 작업의 일부로 이벤트를 New Relic에 보낸다고 가정하면 배치 작업이 실행되지 않을 경우 알려주는 경고 조건을 설정할 수 있습니다.
- 이벤트에 간단한 카운트 쿼리를 설정합니다.
SELECT count(*) FROM MyBatchEvent- 신호 손실을 설정하여 24시간 30분 후에 새 인시던트를 엽니다. 이를 조정할 수 있지만 늦게 실행되는 배치 작업을 허용하는 것이 좋습니다.
- 이벤트 타이머 스트리밍 집계 방법을 사용해야 합니다. 24시간마다 1개의 데이터 포인트만 가져오므로 타이머를 가장 낮은 설정인 5초로 설정할 수 있습니다.
신호가 없을 때 null이 아닌 값 사용
기본적으로 데이터 신호의 간격은 null 값으로 채워집니다. 이러한 데이터 간격을 기반으로 조건을 생성할 수 있어야 하는 경우 사용자 정의 값 또는 마지막으로 알려진 값으로 간격을 채울 수 있습니다. UI에서 조건으로 이 설정을 구성하거나 NerdGraph를 통해 간격 채우기 값을 구성할 수 있습니다.
중요
간격 채우기를 구성해도 '신호 손실'이 트리거되지 않습니다.
이슈 생성 기본 설정 정의
문제 알림을 받을 시기를 결정하여 문제가 발생할 때 대응할 수 있습니다.
알림을 처음 사용하는 경우 문제 기본 설정 옵션에대해 자세히 알아보세요.
기본 문제 기본 설정은 정책 내의 모든 조건을 하나의 문제로 결합합니다. 기본 문제 기본 설정을 변경하여 받는 문제 및 문제 알림의 수를 늘리거나 줄입니다.
조직 내의 각 팀에는 서로 다른 요구 사항이 있을 수 있습니다. 문제 기본 설정을 결정할 때 팀에 2가지 중요한 질문을 합니다.
- 문제가 발생할 때마다 알림을 받고 싶습니까?
- 유사한 알림을 모두 그룹화하고 한 번만 알림을 받고 싶습니까?
여러 엔터티의 성능 관리와 같이 정책 및 해당 조건의 범위가 더 넓은 경우 수신하는 문제의 수를 늘리십시오. 2개의 문제가 반드시 서로 연관될 수는 없기 때문에 더 많은 알림이 필요할 수 있습니다.
정책 및 해당 조건에 한 엔터티의 성능 관리와 같이 집중된 범위가 있는 경우 기본 문제 기본 설정을 선택합니다. 2개의 문제가 서로 관련되어 있거나 팀이 이미 알림을 받고 기존 문제를 수정하는 경우 알림이 더 적게 필요합니다.
다음은 뭐지?
경고 사용에 대해 자세히 알아보려면:
- 알림 개념 및 용어 에 대해 알아보세요.
- API 에 대해 알아보세요.
- 최소/최대 제한 및 규칙 에 대한 기술 세부정보를 읽어보세요.
- 신호 손실 및 간격 채우기 설정을 사용하려는 경우 에 대해 자세히 알아보세요.