이것은 구현 가이드 의 네 번째이자 마지막 부분입니다.
이전 구현 단계에서 스택을 계측 하고 New Relic 플랫폼에 익숙해졌습니다 . 지금은 문제를 조기에 알리고 최악의 시나리오를 피하는 데 도움이 되는 사전 예방적 솔루션에 대해 생각할 때입니다. 이 단계에서는 다음을 포함하여 이 영역의 몇 가지 중요한 솔루션에 대해 배웁니다.
- 경고
- 합성 모니터
- 오류 받은편지함
알림 전략에 대해 생각해 보세요.
New Relic UI는 계정의 경고 조건 상태를 보여줍니다.
알림을 설정하기 전에 알림 목표와 전략에 대해 생각하는 것이 좋습니다. 조직이 클수록 더 중요합니다.
경고 전략이 없는 대신 일회성 문제를 해결하기 위해 빠르고 무작정 경고를 설정하면 너무 많은 경고 알림이 발송될 수 있습니다. 그런 일이 발생하면 팀은 경보 피로로 고통 받고 경보를 무시하기 시작합니다. 알림 전략에 대해 생각하는 데 시간을 할애하면 조직이 성장하거나 New Relic에 더 많은 데이터를 추가할 때 확장할 수 있는 현명한 방법으로 알림을 설정할 수 있습니다.
경고 알림 메시지를 사용자에게 라우팅하기 위해 워크플로 (사고가 알림을 생성하는 방법 및 전송되는 데이터에 대한 규칙) 및 알림 대상 (알림이 전송되는 위치)을 사용합니다. 조직 전체에서 일관되고 유지 관리가 가능하도록 설정하는 방법을 계획하는 것이 좋습니다. Slack 또는 PagerDuty와 같은 다른 서비스와 통합하는 경우 장기적으로 이러한 통합을 제어하고 유지하는 방법을 고려하십시오.
경고 피로를 피하는 것이 경고 전략의 중심 목표가 되어야 합니다. 적용할 수 있는 한 가지 전략은 비즈니스 영향의 심각도에 따라 경고를 분류하는 것입니다. 더 심각하거나 비판적인 것은 가장 큰 소리를 내서 대응할 수 있는 위치에 있는 이해 관계자에게 전달해야 하며, 비즈니스에 영향을 덜 미치는 것은 더 작은 "폭발 반경"으로 더 조용하게 전달해야 합니다.
예를 들어 조직 전체에 적용할 수 있는 몇 가지 경고 심각도 프로토콜을 정의하고 워크플로를 사용하여 경고가 올바르게 라우팅되도록 할 수 있습니다. 팀은 각 심각도에 대해 약간 다른 라우팅을 적용할 수 있지만 공통 언어를 도입하고 조직 전체에 미치는 영향을 이해하면 경고 노력이 확장됨에 따라 이익을 얻을 수 있습니다.
심각성 | 타격 | 청중 | 통합 |
|---|---|---|---|
세브 1 / P1 | 비판적인 | 통화 중 SRE, C-레벨 관리자/사고 사령관/, 관련 제품 소유자 및 DevOps 팀 | Pagerduty, Slack, 이메일 |
세브 2 / P2 | 높은 | 관련 제품 소유자 및 DevOps 팀 | 페이저듀티, 슬랙 |
세브 3 / P3 | 중간 | DevOps 팀 | 느슨하게 |
샌드박스 / Sev 4 / P4 | 낮음 / 없음 | DevOps 팀 | 샌드박스 슬랙 |
조직에서 몇 가지 경고 보안 프로토콜을 정의하는 방법의 예.
경고의 장기적인 품질을 보장하기 위해 경고 피로가 해결되고 경고가 올바르게 분류되는지 확인하기 위해 경고 조건에 대한 정기적인 검토를 계획하는 것을 고려할 수 있습니다. 여기에는 경고가 발생하는 빈도와 응답 및 해결 시간을 분석하는 작업이 포함됩니다.
알림을 시작하는 방법:
- 알림 조건 및 알림 대상 설정을 빠르게 시작하려면 첫 번째 알림 생성에 대한 문서를 참조하세요.
- 알림 전략 계획 및 구현에 대한 자세한 지침은 알림 품질 관리 가이드 를 참조하세요.
다음은 알림 자동화에 대한 몇 가지 문서입니다.
합성 모니터링
당사의 종합 모니터링은 웹사이트, 중요한 비즈니스 트랜잭션 및 API 엔드포인트를 모니터링하는 자동화되고 스크립트 가능한 도구 모음을 제공합니다. 이러한 도구를 사용하면 간단한 모니터를 실행하여 가동 시간 및 기본 기능을 확인하거나 실제 사용자의 작업 및 워크플로를 모방하는 복잡한 스크립트를 만들 수 있습니다.
합성을 잘 사용하려면 팀에서 비즈니스 크리티컬 고객 여정과 종속 API를 식별하고 합성 모니터를 설정하여 추적해야 합니다. 합성 모니터 보고서는 워크로드 또는 기타 대시보드의 일부일 수 있습니다.
모니터 인덱스를 사용하여 모니터의 상태 및 메트릭을 확인할 수 있습니다.
합성을 시작하려면 합성 소개 및 모니터 만들기 를 참조하십시오.
오류 받은편지함
오류 받은 편지함 기능을 사용하면 오류가 최종 사용자에게 영향을 미치기 전에 오류를 사전에 감지하고 우선 순위를 지정하고 조치를 취할 수 있습니다. Slack과 같이 선호하는 커뮤니케이션 채널을 통해 고객에게 영향을 미치는 중대한 오류가 발생할 때마다 알림을 받게 됩니다.
오류 받은 편지함 UI를 사용하면 작업 부하의 오류를 쉽게 검토할 수 있습니다.
오류 받은 편지함을 사용하려면 일부 작업 부하를 설정해야 합니다. 시작하기 위한 리소스:
다음은 뭐지?
이 가이드는 강력한 관찰 가능성 기반을 설정하는 데 도움이 되었지만 이는 관찰 가능성 우수성을 향한 첫 번째 단계일 뿐입니다. 다음으로 New Relic의 세부 사항을 배우고 설정을 최적화하는 데 집중할 수 있습니다. 다음 단계에 대한 몇 가지 아이디어:
- 아직 더 많은 계측이 필요하다고 생각되면 더 많은 관측 가능성 도구를 찾아 설치 하십시오.
- 구성 및 사용자 지정 옵션에 대해 알아보려면 사용 중인 도구 및 기능에 대한 문서를 읽으십시오.
- 데이터 수집을 이해하고 최적화합니다.
- 데이터 쿼리에 대한 New Relic University 수업을 완료하고 다른 수업 을 듣습니다.
- 관찰 가능성 목표를 계획하고 관찰 가능성 우수성을 달성하는 방법에 대해 자세히 알아보려면 관찰 가능성 성숙도 시리즈 를 참조하세요. 여기에는 최적의 계측 , 코드로서의 관찰 가능성 , 경고 품질 관리 등을 보장하기 위한 가이드가 포함되어 있습니다.