다음 권장 사항을 구현하여 경고 범위를 개선하고 경고 구성을 최대한 활용하십시오.
경고의 근본 원인을 찾는 방법에 대한 이 비디오를 확인하십시오(5분 1초).
다음에 대한 모범 사례를 읽으려면 계속 읽으십시오.
- 정책
- 알림 채널
- 인시던트 기본 설정
- 임계값 및 위반
- 음소거 규칙
권장 알림
경고를 처음 접하거나 경고 범위를 최적화하는 제안을 원하는 경우 권장 경고 조건 조건을 사용하십시오.
정책 구성
정책은 유사한 조건 에 대한 컨테이너입니다.
알림을 처음 사용하는 경우 정책을 생성, 수정 또는 찾는 방법을 알아보세요.
가능한 경우 정책 범위를 단일 엔터티 로 구성합니다. 사고 발생 시 알림을 받아야 하는 필수 팀에 정책을 할당합니다. 이러한 방식으로 정책을 중앙 집중식으로 유지할 수 있습니다.
팀이 동일한 엔터티 유형의 여러 그룹을 모니터링하는 경우 해당 엔터티 클러스터(예: 서버)를 하나의 정책으로 결합합니다. 이러한 방식으로 팀은 한 번에 여러 정책을 탐색하는 대신 하나의 정책에서 알림을 받을 수 있습니다.
경고를 사용하여 모든 엔터티를 모니터링할 수 있습니다. 정책에 자신을 할당할 때 역할과 우선 순위를 고려하십시오.
예를 들어:
- 소프트웨어 개발자 는 웹 페이지 응답 시간 및 페이지 로드 JavaScript 오류와 같은 프런트 엔드 및 백 엔드 성능에 대한 알림 이 필요할 수 있습니다.
- 운영 담당자 는 서버 메모리 및 로드 평균과 같은 열악한 백엔드 성능에 대한 알림이 필요할 수 있습니다.
- 제품 소유자 는 개선된 최종 사용자 Apdex 점수 또는대시보드 에서 모니터링되는 판매와 같은 긍정적인 프런트 엔드 성능에 대한 알림이 필요할 수 있습니다.
조건 임계값 및 위반 설정
의미 있는 임계값 수준을 설정하여 비즈니스에 대한 알림을 최적화합니다. 다음은 몇 가지 제안된 지침입니다.
동작 | 권장 사항 |
|---|---|
임계값 수준 설정 | 임계값을 너무 낮게 설정하지 마십시오. 예를 들어, 프로덕션 서버에서 5분 동안 CPU 조건 임계값을 75%로 설정하고 이 임계값이 일상적으로 해당 수준을 초과하면 실행 불가능한 경고 또는 오탐 가능성이 높아집니다. |
설정 실험 | 파일을 편집하거나 소프트웨어를 다시 시작할 필요가 없으므로 임계값 수준을 빠르게 변경하고 필요에 따라 조정하십시오. |
설정 조정 | 시간이 지남에 따라 조건을 조정하십시오.
|
설정 비활성화 | 정책의 모든 조건을 비활성화할 수 있습니다. 예를 들어, 다른 메트릭이나 임계값을 실험하는 동안 정책의 다른 조건을 계속 사용하려는 경우에 유용합니다. |
대부분의 제품(인프라 제외)에서 경고 임계값이 상승하거나 정상으로 돌아오면 사용자 인터페이스의 색상으로 구분된 상태 표시기 가 변경됩니다. 이를 통해 특정 알림을 받을 필요 없이 중요한 임계값이 통과하기 전에 UI를 통해 상황을 모니터링할 수 있습니다.
위험(빨간색) 및 경고(노란색)의 두 가지 위반 임계값이 있습니다. 위의 제안을 염두에 두고 다양한 기준으로 이러한 임계값을 정의하십시오.
중요
경고 위반은 인시던트를 열지 않습니다. 중대한 위반으로 인해 사고가 발생할 수 있지만 사고 기본 설정 을 통해 해당 결정을 정의해야 합니다.
신호가 없을 때 어떻게 되는지 결정
New Relic이 잠시 동안 데이터 수신을 중단하면 신호 손실이 발생합니다. 기술적으로 우리는 데이터가 시계열에서 마지막으로 수신된 이후 상당한 시간이 경과한 후에 신호 손실을 감지합니다. 신호 손실은 경고를 설정하는 데 사용할 수 있는 위반을 트리거하거나 해결하는 데 사용할 수 있습니다.
UI에서 조건별로 신호 손실 설정을 구성하거나 NerdGraph API를 통해 신호 손실을 구성할 수 있습니다.
일일 배치 작업이 실행되도록 경고 조건 설정
배치 작업의 일부로 이벤트를 New Relic에 보낸다고 가정하면 배치 작업이 실행되지 않을 경우 알려주는 경고 조건을 설정할 수 있습니다.
- 이벤트(
SELECT count(*) FROM MyBatchEvent)에 대한 간단한 카운트 쿼리 설정 - 24시간 30분 후에 새로운 위반을 열도록 신호 손실을 설정합니다(이를 조정할 수 있지만 늦게 실행되는 일괄 작업을 허용하는 것이 좋습니다).
- 이벤트 타이머 스트리밍 집계 방식을 사용해야 합니다. 24시간마다 1개의 데이터 포인트만 얻을 수 있으므로 타이머를 가장 낮은 설정인 5초로 설정할 수 있습니다.
신호가 없을 때 null이 아닌 값 사용
기본적으로 데이터 신호의 간격은 null 값으로 채워집니다. 이러한 데이터 격차를 기반으로 조건을 생성할 수 있어야 하는 경우 사용자 지정 값 또는 마지막으로 알려진 값으로 격차를 채울 수 있습니다. UI의 조건에 따라 이 설정을 구성하거나 NerdGraph를 통해 간격 채우기 값을 구성 할 수 있습니다.
인시던트 기본 설정 정의
인시던트 알림을 받는 시기를 결정하여 인시던트가 발생했을 때 대응할 수 있습니다.
알림을 처음 사용하는 경우 사고 기본 설정 옵션 에 대해 자세히 알아보세요.
기본 인시던트 기본 설정은 정책 내의 모든 조건을 하나의 인시던트로 결합합니다. 기본 인시던트 기본 설정을 변경하여 수신하는 인시던트 및 인시던트 알림 수를 늘리거나 줄이십시오.
조직 내 팀마다 요구 사항이 다릅니다. 사고 선호도를 결정할 때 팀에 두 가지 중요한 질문을 하십시오.
- 문제가 발생할 때마다 알림을 받고 싶습니까?
- 유사한 알림을 모두 그룹화하고 한 번만 알림을 받고 싶습니까?
정책 및 해당 조건의 범위가 더 넓은 경우(예: 여러 엔터티의 성능 관리) 수신하는 인시던트의 양을 늘립니다. 두 인시던트가 반드시 서로 관련이 있는 것은 아니므로 더 많은 알림이 필요합니다.
정책 및 해당 조건에 집중된 범위가 있는 경우(예: 한 엔터티의 성능 관리) 기본 인시던트 기본 설정을 선택합니다. 두 인시던트가 서로 관련되어 있거나 팀이 이미 알림을 받고 기존 문제를 수정하는 경우 알림이 덜 필요합니다.
알림 채널 모범 사례 를 사용하여 사고 알림을 받는 방법을 결정합니다.
알림 채널 선택
가장 유용한 채널 및 정책에 맞게 알림을 조정하여 알림 피로를 방지하고 적절한 직원이 관심 있는 사고를 체계적으로 수신하고 대응할 수 있도록 돕습니다.
알림을 처음 사용하는 경우 알림 채널을 설정 하는 방법을 알아보세요.
인시던트가 발생했을 때 최신 정보를 유지하거나 문제를 해결해야 하는 팀과 개인에게 알립니다.
최신 정보를 유지하려면 이메일과 같이 덜 방해가 되는 알림 채널을 선택하십시오.
중요한 알림 및 인시던트 대응의 경우 PagerDuty 또는 Slack과 같이 더 방해가 되는 알림 채널을 선택하십시오.
지연되는 경우 빠른 알림을 이메일에 의존하지 마십시오.
음소거 규칙 이해
유지 관리 또는 계획된 다운타임과 같은 일상적인 이벤트 동안 경고를 음소거합니다.
필요한 경우 정책, 특정 엔터티 및 조건을 침묵시킬 수도 있습니다. 인시던트를 계속 열 수 있지만 알림을 받지는 않습니다.
알림을 처음 사용하는 경우 음소거 규칙을 만들고 관리 하는 방법을 알아보세요.
다음은 뭐지?
경고 사용에 대해 자세히 알아보려면:
- API 에 대해 알아보세요.
- 최소/최대 제한 및 규칙 에 대한 기술 세부정보를 읽어보세요.
- 신호 손실 및 간격 채우기 설정을 사용하려는 경우 에 대해 자세히 알아보세요.