New Relic Now Start training on Intelligent Observability February 25th.
Save your seat.

소프트웨어를 구축하는 일도 쉽지는 않지만, 오류를 효과적으로 분류하는 것도 결코 만만치 않은 일입니다. 업타임과 안정성을 유지하고, 궁극적으로 잠재적인 수익 손실을 방지하려면, 고객에게 영향을 미칠 수 있는 문제를 신속하게 해결해야 합니다. 

문제를 더 빨리 해결하려면, 오류의 우선순위를 지정하고 통합 경험 내에서 풍부한 컨텍스트 데이터를 활용할 수 있어야 합니다. 뉴렐릭 에러스 인박스(errors inbox)의 최신 업데이트는 오류 해결 워크플로우를 가속화하고 고객에게 영향을 미치는 문제를 해결하는 데 집중하여 평균 해결 시간(MTTR)을 줄이는 데 도움을 주는 컨텍스트를 제공합니다.

영향을 받는 사용자와 알림에 기반한 오류의 우선순위 지정

에러 인박스의 최신 개선 기능은 다양한 오류 그룹의 중요도 수준을 결정하는 데 도움을 줍니다. 이제, 오류 그룹의 영향을 받는 사용자 수를 확인하고 이 메트릭을 기반으로 알림을 생성할 수 있습니다. 그런 다음 ROI가 가장 높은 오류에 집중할 수 있습니다.

오류의 영향을 받는 사용자 수를 기반으로 뉴렐릭 알림을 생성할 수 있습니다. 간단한 튜토리얼 영향을 받는 사용자 기반의 알림 설정을 확인해 보십시오.

오류 인스턴스로 연결된 트레이스를 확인하고 근본 원인을 신속하게 파악

현대의 애플리케이션은 여러 요소와 서비스로 구성되어 문제의 근본 원인을 식별하기 어렵습니다. 시스템에서 여러 서비스들이 상호 작용하는 방식을 완전히 이해하지 못하는 경우에는 특히 더 어렵습니다. 문제가 발생한 위치를 식별하기 위해 특정 오류 메시지를 해독하거나 발생한 문제가 애플리케이션 성능을 손상시킨 이유를 이해하기 위해 여러 툴 간에 전환을 해야 할 수도 있습니다.

이제 에러 인박스에서 분산 추적에 직접 액세스하여 한 곳에서 인사이트를 확보하고 오류를 분석할 수 있습니다.

오류를 선택하여 상호 연관된 트레이스로 전체 요청에 대한 개요를 살펴보고, 기간, 스팬 수 및 발생한 오류에 대한 요약 정보를 확인할 수 있습니다.

보다 세부적인 컨텍스트를 얻으려면 Explore를 선택합니다.

그런 다음, 요청에 대한 보다 세분화된 뷰를 열어 전체 트레이스의 세부 정보와 기록된 모든 스팬의 시각화된 정보를 볼 수 있습니다. 이러한 시각화를 통해 문제가 발생한 위치를 빠르게 식별하고 문제를 해결하는 데 집중할 수 있습니다.

Slack을 사용한 엔터티 수준의 협업

뉴렐릭의 Slack 통합에 대해 아는 분들도 계실 겁니다. 이제 여기에서 한 단계 더 나아가, 엔터티 수준까지 Slack 알림이 지원되어 팀 전체가 더 효과적으로 협업할 수 있게 되었습니다.

이 향상된 통합 기능은 서비스 또는 애플리케이션과 관련된 인박스로 알림을 전송합니다. 이제 각 팀은 자체 소유한 애플리케이션에 집중하고 협업할 수 있습니다.

에러 인박스를 Slack과 연결하는 방법에 대한 자세한 내용은 다음 비디오를 시청하십시오.

또는 다음 단계를 따르십시오.

  1. Slack 워크스페이스에 뉴렐릭 앱이 설치되어 있다면, 먼저 뉴렐릭 앱을 설치합니다.
  2. 뉴렐릭 에러 인박스 하나를 열고, 오른쪽 상단 모서리에 있는 알림 설정 아이콘(벨 모양)을 선택합니다.
  3. Slack 버튼이 꺼져 있으면, 켭니다.
  4. 사용 가능한 워크스페이스가 없으면, 더하기(+) 버튼을 클릭해 Slack을 활성화합니다.
  5. 인증 후 알림을 보낼 워크스페이스와 특정 채널을 선택합니다.
  6. Test를 클릭해 메시지가 올바른 채널로 전송되고 있는지 확인합니다.

영향을 받는 사용자 기반 알림 설정

이 새로운 기능을 최대한 활용하려면, 먼저 사용자 영향 데이터를 뉴렐릭으로 전송해야 합니다. 그런 다음 다음을 결정하여 알림을 설정합니다.

  • 오류가 생성되며 모니터링하고 알림을 설정할 엔터티
  • 사용 사례에서 가장 중요한 알림 신호
  • 조직에 중요한 임계값

간단한 다음의 세 가지 단계를 따릅니다.

1. 알림 서비스의 entity.guid를 파악합니다.

일반적으로 모든 NRQL 문자열을 기반으로 알림을 생성할 수 있습니다. 이 튜토리얼에서는 고객에게 영향을 주는 오류 생성 엔터티에 대한 알림을 생성합니다. 알림을 설정하려는 엔터티가 APM 서비스인 경우, 메뉴에서 APM & services를 클릭하고 알림을 설정하려는 서비스를 선택합니다. 이 스크린샷과 같이 See metadata and manage tags를 선택하여 서비스의 entity.guid를 찾습니다.

 

그런 다음, entity.guid를 이 예시에서와 같이 복사합니다.

엔터티는 오류를 생성하는 모든 소스 및 워크로드에 존재하지만 여기에 국한되지는 않습니다.

보다 자세한 내용은 엔터티의 정의 및 찾는 방법을 확인하시기 바랍니다.

2. 영향을 받는 사용자 수를 가져오는 쿼리를 만듭니다.

영향을 받는 사용자를 반환하는 NRQL 쿼리를 생성하려면, 먼저 알림에 포함할 서비스를 결정하고 서비스의 entity.guids를 가져와야 합니다.

entity.guids를 파악한 후, 쿼리 빌더로 이동하여 다음 NRQL 문자열을 삽입합니다.

SELECT uniqueCount(newrelic.error.group.user_impact)FROM Metric WHERE metricName='newrelic.error.group.userImpact' AND entity.guid in(entity.guid1, entity.guid2, …) FACET error.group.guid TIMESERIES

entity.guid를 알림을 전송하려는 서비스의 GUID로 교체합니다.

이 쿼리는 제공된 entity.guids의 서비스로 인해 생겨난 각 오류 그룹의 영향을 받는 고유한 사용자 수를 반환합니다. 다음으로, 영향을 받는 고유한 사용자 수가 임계값을 초과할 때 트리거되는 알림을 정의해야 합니다.

이 데이터를 쿼리 빌더에 포함시키면, 쿼리 문자열을 조정할 수 있습니다.

알림 신호를 생성하려는 문자열이 있으면, Create alert를 선택합니다. NRQL 알림 조건을 구성할 수 있는 창이 표시됩니다.

3. 영향을 받는 사용자 메트릭을 기반으로 NRQL 알림을 생성합니다.

계측된 서비스에서 영향을 받는 사용자 수를 기반으로 알림을 생성하려면, 먼저 NRQL 알림 조건을 생성해야 합니다. 다음 단계를 따릅니다.

Edit an alert condition 창에서 조건을 트리거하는 임계값을 정의합니다. 조건 위반이 강조 표시되어 특정 사용 사례에 대한 최상의 임계값을 결정하는 데 도움을 줍니다. 이상적인 임계값은 사용 사례에 따라 다르지만, 알림을 트리거하지 않는 가장 작은 값과 위반 기간이 좋은 시작점이 될 수 있습니다.

집계 기간을 세부 조정하면, 알림 노이즈를 줄이고 보다 실행 가능한 알림을 생성하는 데 도움이 될 수 있습니다.

기간이 너무 짧은 경우, 임계값이 작으면 몇 가지 일시적인 오류로 인해 잘못된 알림을 유발될 수 있고, 임계값이 너무 크면 어느 정도 지속적으로 영향을 받는 사용자 스트림을 놓칠 수 있습니다. 보다 자세한 내용은 기간과 관련된 문서를 참조하십시오.

이제 조건을 저장할 준비가 되었습니다. 아래로 스크롤 하거나 알림 구성 섹션을 축소한 후, Save condition을 선택합니다.

이제 알림 정책이 생성되고 기본 설정으로 활성화됩니다. 보다 자세한 내용은 뉴렐릭의 정책 문서를 확인하십시오.

참고: 사용되는 NRQL 문자열은 오류 그룹별로 패싯됩니다. 오류 그룹이 위반 기간의 임계값을 초과하면 알림이 트리거된다는 의미입니다. 각 오류 그룹의 영향을 받는 총 사용자 수뿐만 아니라 영향을 받는 총 사용자 수를 측정하는 것이 더 적합한 경우도 있을 수 있습니다. 이 경우, FACET 절을 제거할 수 있습니다. 이 샘플 쿼리를 참조하십시오.

SELECT uniqueCount(newrelic.error.group.user_impact) FROM Metric WHERE metricName='newrelic.error.group.user_impact' AND entity.guid in(entityGuid1, entityGuid2, …)

하나의 알림 조건에서 사용하는 엔터티들은 동일한 유형이 아니어도 됩니다.