이 가이드에는 New Relic으로 OpenTelemetry를 구현하기 위한 팁과 모범 사례가 포함되어 있으며 다음에 유용합니다.
- 현재 APM 솔루션 또는 기타 타사 모니터링 솔루션을 사용하고 있지만 OpenTelemetry로 전환하려는 기존 New Relic 고객
- OpenTelemetry 및 New Relic을 사용하도록 전환하려는 모든 조직
이 가이드는 New Relic으로 OpenTelemetry 데이터를 최대한 활용하는 데 도움이 되는 10가지 중요한 단계를 안내합니다.
1. OpenTelemetry를 사용한 계측 애플리케이션
모든 OpenTelemetry 여정의 첫 번째 단계는 애플리케이션을 계측하는 것입니다. 이 가이드는 이 단계에 대한 개요를 제공하고 몇 가지 중요한 고려 사항을 강조합니다. 자세한 지침은 OpenTelemetry 시작 방법을참조하십시오.
Java, .NET, Python 및 Node.js와 같은 일부 언어의 경우 OpenTelemetry는 자동 계측 접근 방식을 제공합니다. 이것은 나중에 구축할 수 있는 많은 응용 프로그램을 위한 좋은 출발점입니다. 자동 계측에 대한 지침은 여기에서 찾을 수 있습니다.
수동 계측은 Go와 같이 자동 계측을 지원하지 않는 언어에 사용할 수 있습니다. 또한 자동 계측을 통해 수집된 원격 측정을 보강하는 데 사용할 수 있습니다.
자동 계측은 추적 및 경우에 따라 메트릭을 수집합니다. 이 두 신호는 애플리케이션을 관찰하는 데 중요합니다.
어떤 계측 접근 방식을 선택하든 New Relic UI의 다양한 부분이 제대로 작동하기 위해 특정 속성의 존재에 의존한다는 점을 이해하는 것이 중요합니다.
리소스를 UI의 항목과 연결하려면 service.name 속성이 필요합니다. 그리고 특정 창이 켜지려면 service.instance.id 필요합니다.
New Relic의 OpenTelemetry 엔터티에 대한 골든 신호 차트에는 차트를 구동할 범위 또는 지표를 선택할 수 있는 토글이 포함되어 있습니다. New Relic은 다음 지표를 기반으로 스팬에서 황금 신호를 도출합니다.
http.server.durationrpc.server.durationhttp.status_code
이러한 메트릭이 자동 계측과 함께 아직 표시되지 않은 경우 SDK를 사용하여 애플리케이션의 계측에 추가합니다.
이러한 모든 속성은 OpenTelemetry 리소스 시맨틱 규칙에 의해 정의되며 일반적으로 OpenTelemetry SDK를 사용하여 리소스를 생성하여 설정됩니다.
OpenTelemetry를 사용하여 로그를 캡처할 수도 있습니다. OpenTelemetry 추적을 컨텍스트 내 로그인 기능과 연관시킬 수 있도록 service.name, trace.id및 span.id 속성이 로그 항목에 포함되어 있는지 확인합니다. OpenTelemetry 로그 보고에 대한 자세한 내용은 OpenTelemetry 로그 문서를참조하십시오.
2. OpenTelemetry 수집기 배포
다음으로 일괄 처리, 재시도 및 암호화와 같은 작업을 오프로드하므로 프로덕션에서 OpenTelemetry를 사용하는 데 권장되는 OpenTelemetry 수집기를 배포할 차례입니다.
다음은 OpenTelemetry 수집기 구성에 대한 몇 가지 팁입니다.
- 올바른 끝점을 사용하십시오. OTLP 데이터를 엔드포인트로 내보내도록 구성해야 합니다. 이것은 OpenTelemetry Collector에서 데이터를 보내는 문서에 설명되어 있습니다.
- Avoided dropped data [데이터 삭제 방지]. 데이터 삭제를 방지하려면 길이가 4095자를 초과하는 속성을 자르는 것이 좋습니다. 이러한 사례를 적용하는 예는 이 수집기 구성을 참조하세요.
- 인프라. 인프라 메트릭을 수집하려면 수집기 구성에 호스트 메트릭 수신기를 포함합니다. 호스트 수신기를 수집기 구성의 일부로 사용하는 경우 호스트 엔터티의 일부로 호스트 메트릭을 자동으로 감지하고 골든 메트릭을 합성합니다(간단히 말해 인프라 에이전트와 동일한 경험을 얻습니다).
- 스케일링. 대규모 OpenTelemetry 배포는 성능 및 복원력 이점 모두를 위해 수집기 확장 전략을 선택해야 합니다. 수집기 크기 조정에 대한 자세한 내용은 OpenTelemetry 문서를참조하십시오.
- Kubernetes.OpenTelemetry 계측 서비스가 Kubernetes 환경에서 실행 중인 경우 OpenTelemetry 계측 애플리케이션을 Kubernetes에 연결의 단계를 따르십시오. 이렇게 하면 Kubernetes 데이터가 OpenTelemetry 데이터와 상호 연관됩니다.
많은 고객이 에이전트 및 게이트웨이 배포 방법을 모두 사용하여 수집기를 실행하도록 선택합니다.
- Agent: 이 방법을 사용하면 수집기가 애플리케이션과 동일한 호스트에서 실행됩니다(예: 바이너리, 사이드카 또는 데몬셋).
- 게이트웨이: 이 방법을 사용하면 하나 이상의 수집기 인스턴스가 클러스터, 데이터 센터 또는 지역별로 독립 실행형 서비스로 실행됩니다.
각 호스트의 에이전트 수집기는 데이터를 게이트웨이 수집기 클러스터로 내보내기 전에 기본 처리 작업을 수행합니다. 그러면 게이트웨이 수집기가 데이터를 New Relic으로 내보내도록 구성됩니다. 자세한 내용은 New Relic을 사용한 OpenTelemetry용 참조 아키텍처를참조하십시오.
3. 트레이스 샘플링 전략 구현
기본적으로 OpenTelemetry는 애플리케이션에서 추적의 100%를 캡처하여 New Relic으로 보냅니다. 따라서 생산에 OpenTelemetry를 배포하기 전에 추적을 위한 샘플링 전략을 구현해야 합니다. 이는 원격 측정과 관련된 애플리케이션 오버헤드를 줄이는 데 도움이 될 뿐만 아니라 네트워크에서 데이터 유출량과 New Relic으로의 데이터 수집량을 줄이는 데 도움이 됩니다.
OpenTelemetry 샘플링과 관련된 모범 사례는 샘플링 문서 를참조하십시오. 과도한 데이터 송신 및 수집을 피하면서 문제를 해결하기 위해 충분한 추적 데이터를 보장하기 위해 부하 테스트 프로세스(아래 설명)의 일부로 샘플링 구성을 조정해야 합니다.
꼬리 기반 샘플링을 사용하는 경우 고립되고 조각난 범위를 피하도록 주의하십시오. 분리된 범위를 방지하기 위해 테일 샘플링 프로세서를 사용할 때 컬렉터를 스케일링하는 방법은 컬렉터 스케일링에 대한 OpenTelemetry 문서를참조하십시오.
4. 부하 테스트 수행 및 구성 조정
응용 프로그램과 함께 OpenTelemetry를 생산에 투입하기 전에 낮은 환경에서 부하 테스트를 수행하는 것이 가장 좋습니다. 이를 통해 다음과 같은 기회를 얻을 수 있습니다.
- 증가하는 CPU 및 메모리 사용률과 서비스 대기 시간을 분석하여 애플리케이션에서 OpenTelemetry 계측의 오버헤드를 측정합니다.
- 수집기에서 데이터 이그레스 볼륨을 측정하고 New Relic으로 볼륨을 수집합니다. 둘 다 수집을 늘리고 청구에 영향을 미칠 수 있습니다.
- 이것은 또한 OpenTelemetry Collector를 로드 테스트하고 프로덕션과 같은 로드를 충분히 처리할 수 있는지 확인할 수 있는 기회를 제공합니다. 수집기 크기 조정에 대한 팁은 OpenTelemetry 문서를참조하십시오.
5. 서비스 수준 목표 정의
OpenTelemetry 데이터가 New Relic으로 유입되면 SLO가 충족되지 않는 시점을 판단하고 그에 따라 조치를 취할 수 있도록 서비스 수준 목표를 정의하는 것이 중요합니다.
서비스 수준은 최종 사용자(또는 클라이언트 애플리케이션) 관점에서 서비스 성능을 측정하는 데 사용됩니다. New Relic을 사용하면 애플리케이션에 대한 SLI(서비스 수준 지표) 및 SLO(서비스 수준 목표)를 정의하고 사용할 수 있습니다. OpenTelemetry 계측 서비스에 대한 서비스 수준을 구성하는 것이 좋습니다.
SLO 세트를 생성하면 New Relic이 SLI 데이터 생성을 시작합니다. 운영 보기는 다양한 시간대에서 서비스 수준이 어떻게 향상되거나 저하되는지 보여줍니다. 이 보기를 사용하여 시간 경과에 따른 SLI 달성률(%)을 추적하고 각 서비스 수준에 대한 규정 준수를 확인할 수 있습니다.
또한 각 SLO에 대한 오류 예산을 모니터링할 수 있습니다. 이는 목표를 손상시키지 않고 SLO 기간 동안 여전히 잘못된 응답을 가질 수 있는 요청의 비율을 나타냅니다.
6. 알림 및 인시던트 관리 구성
애플리케이션의 최종 사용자에게 영향을 미치기 전에 문제를 감지하고 수정할 수 있도록 경고 정책을 구성하는 것도 중요합니다.
높은 수준에서, 하나 이상의 경고 조건을 포함하는 경고 정책을 통해 구성됩니다. 경고 조건의 사건은 문제로 그룹화됩니다. 마지막으로 문제는 문제를 알림으로 전환하는 논리가 포함된 워크플로를 트리거할 수 있습니다. 이러한 개념을 이해하는 데 도움이 되는 다이어그램을 보려면 경고 개념 을 참조하세요.
예를 들어 OpenTelemetry 계측 서비스의 응답 시간이 500ms를 초과하는 경우 인시던트를 열도록 경고 조건을 정의할 수 있습니다. 그런 다음 경고 조건 사고가 발생할 때 이메일 알림을 배포 목록으로 보내는 워크플로를 정의하거나 Slack을 사용하여 대기 중인 팀에 알릴 수 있습니다.
비즈니스에 중대한 영향을 미치는 인시던트가 발생할 때 알리도록 서비스 수준에 대한 경고를 구성할 수도 있습니다.
조건이 있는 경고 정책을 만드는 방법을 알아보려면 첫 번째 경고 만들기를참조하십시오. 문제를 알림으로 전환하는 방법을 알아보려면 워크플로우를참조하십시오. 워크플로를 생성할 때 Slack, ServiceNow 및 Jira와 같은 타사 시스템에 알림을 보낼 대상을 하나 이상 지정할 수 있습니다.
New Relic 경보를 사고 관리 시스템 및 프로세스와 통합하는 것은 애플리케이션 문제에 대한 더 많은 가시성을 제공하고 문제의 빠른 해결을 용이하게 하는 통찰력을 제공하기 때문에 OpenTelemetry 데이터에서 가치를 얻는 데 핵심입니다.
알림에 대한 추가 도움말:
7. 관련 엔터티를 그룹화하기 위한 워크로드 생성
New Relic 워크로드를 사용하면 관련 엔터티를 그룹화하여 전체 스택에서 프런트엔드에서 백엔드 서비스로 집계된 상태 및 활동 데이터를 제공할 수 있습니다. 워크로드는 복잡한 시스템의 상태를 이해하고, 문제를 감지하고, 인시던트의 원인과 영향을 이해하고, 이러한 문제를 신속하게 해결하는 데 도움이 됩니다.
OpenTelemetry 서비스를 관련 엔터티와 함께 그룹화하는 워크로드를 만드는 것이 좋습니다. 여기에는 인프라 모니터링을 통해 모니터링되는 엔터티가 포함될 수 있습니다. , 쿠버네티스 모니터링, 및 기타 엔터티. 워크로드를 사용하면 엔터티를 보다 관리하기 쉬운 단위로 그룹화할 수 있으며 일반적으로 해당 엔터티를 담당하는 팀과 연계됩니다. 이는 수천 개의 모니터링되는 엔터티가 있을 수 있는 대규모 환경에 특히 유용합니다.
워크로드를 생성하면 오류 수신함과 같은 New Relic의 다른 유용한 기능이 잠금 해제됩니다. 오류 받은 편지함을 통해 팀은 고객에게 영향을 미치기 전에 모든 오류를 사전에 감지, 분류 및 조치할 수 있습니다. 오류를 지능적으로 그룹화하여 노이즈를 줄이고 중요한 오류를 빠르고 효율적으로 감지할 수 있습니다. 이를 통해 팀은 한 화면에 표시되는 APM, 브라우저(RUM), 모바일, 서버리스(AWS Lambda) 데이터 및 OpenTelemetry의 오류를 포함하여 전체 스택의 오류를 해결할 수 있습니다.
응용 프로그램 서비스에 대해 OpenTelemetry가 구현되면 오류 수신함을 사용하여 최종 사용자에게 영향을 미치기 전에 가장 일반적인 오류를 사전에 검토하고 해결하는 것이 좋습니다. 오류 수신함에서 오류 그룹을 식별하는 데 사용되는 OpenTelemetry 속성에 대해 알아보려면 고유한 지문이 생성되는 방법 을참조하십시오.
8. 맞춤형 시각화를 위한 대시보드 구축
New Relic은 시작하는 데 도움이 되도록 OpenTelemetry 데이터에 대한 다양한 기본 보기를 제공합니다. 팀에서 문제를 사전에 해결하고 식별하기 위해 데이터를 사용하기 시작하면 맞춤형 시각화의 필요성을 발견할 수 있습니다. 이를 위해 사용자 지정 대시보드를 만들 수 있습니다.
맞춤형 대시보드 생성의 이점과 이를 시작하는 방법에 대해 알아보려면 대시보드 를참조하십시오.
9. 사용자 정의 계측으로 컨텍스트 추가
자동 계측으로 시작하든 수동 계측으로 시작하든 문제를 분류하는 동안 추가 데이터가 필요하면 시간이 지남에 따라 추가 계측을 추가하는 것이 좋습니다. 예를 들어:
- 스팬에 특성을 추가하여 요청에 대한 추가 컨텍스트를 제공할 수 있습니다. 이는 문제 해결 중에 문제의 비즈니스 영향을 이해하는 데 도움이 될 수 있습니다(예: 멀티 테넌트 애플리케이션 문제 해결을 지원하기 위해 스팬에 테넌트 ID 추가). .
- 추가 중첩 범위를 캡처하여 응용 프로그램의 특정 측면을 보다 심층적으로 문제 해결하기 위한 세부 정보를 제공할 수 있습니다.
- 기술적인 관점(예: 캐시 적중 및 누락 수 추적) 또는 비즈니스 관점(예: 체크아웃 중 카트에 있는 평균 항목 수 추적)에서 사용자 지정 메트릭을 캡처할 수 있습니다.
OpenTelemetry 문서는 언어별로 이에 대한 지침과 예를 제공합니다. 예를 들어 Java를 사용하는 경우 다음 문서를 사용할 수 있습니다.
또한 다양한 언어를 사용하여 OpenTelemetry 수동 계측을 보여주는 몇 가지 예가 있습니다.
10. 사용, 측정 및 개선
관찰 가능성 성숙도를 개선하려면 지속적인 개선 사고 방식을 채택하는 것이 중요합니다. New Relic에서 캡처한 OpenTelemetry 및 기타 데이터를 사용하여 문제를 해결하므로 다음 사항에 유의하고 적절한 조치를 취해야 합니다.
- 최종 사용자가 영향을 받기 전에 기존 경고 조건이 사전에 문제를 감지했습니까? 그렇지 않은 경우 경고 조건을 조정하거나 새 조건을 추가해야 합니다.
- 조치가 필요하지 않은 중요한 알림이 계속 표시됩니까? 그렇다면 조치가 필요한 조건만 발생하도록 경보 조건을 조정해야 합니다.
- 문제를 해결하기 위해 추적에 충분한 세부정보가 제공되었습니까? 그렇지 않은 경우 계측을 검토하고 더 많은 스팬 속성 및 중첩 스팬 캡처를 고려해야 합니다.
- 문제 해결에 사용자 지정 NRQL 쿼리가 필요했습니까? 그렇다면 결과 차트 중 일부를 대시보드에 통합하는 것을 고려해야 합니다.
시간이 지남에 따라 계측이 개선됨에 따라 문제를 사전에 감지하는 능력이 향상되고 문제 해결 시간이 단축됩니다. 이로 인해 MTTD(평균 감지 시간)와 MTTR(평균 해결 시간)이 모두 감소합니다.
경고 품질을 개선하고 최적화하여 궁극적으로 가동 시간과 가용성을 높이고 MTTR을 줄이며 경고 볼륨을 줄이는 프로세스를 안내하는 경고 품질 관리 가이드가 있습니다.
또한 서비스 수준 관리의 품질을 개선하고 최적화하는 방법을 안내하는 서비스 수준 관리 가이드 도 있습니다. 이러한 권장 사항을 성공적으로 구현하면 다음과 같은 이점을 얻을 수 있습니다.
- 비즈니스 중단 사건의 수 감소
- 감소된 MTTR
- 인시던트당 노력 감소