서비스 특성화: 앱의 계측 및 원격 측정 최적화

이 가이드는 디지털 자산을 모니터링하고 개선하는 데 필요한 계측 및 원격 측정 데이터가 있는지 확인하는 과정을 안내합니다. 이것은 관찰 가능성 성숙도에 대한 시리즈 의 일부입니다.

개요

"내 서비스를 적절하게 측정하는 데 필요한 모든 원격 측정이 있습니까?"

프로덕션 모니터링을 위한 서비스를 온보딩하는 프로세스는 처음부터 시작하여 처음부터 진행되는 경향이 있습니다. 일반적으로 서비스는 에이전트 기반 모니터링으로 인스턴스화되며 서비스 제공을 담당하는 팀은 에이전트에서 나오는 원격 분석을 읽어야 합니다(프로세스는 찻잎을 읽는 것과 유사할 수 있음). 그들은 관찰할 수 있는 것을 기반으로 서비스가 어떻게 작동하는지 이해하기 위해 거꾸로 작업합니다.

New Relic에서는 수만 번의 관찰 가능성 배포를 통해 최적의 서비스 제공 측정의 정의에 더 많은 관련 디자이너, 설계자 및 개발자가 포함된다는 것을 발견했습니다. IT 격언 "좌파 이동" 의 출현은 개발 단계가 완료된 후 발생하는 소프트웨어 수명 주기 활동에 개발자를 보다 직접적으로 참여시킬 필요가 있음을 나타냅니다.

서비스 관찰 가능성의 경우 개발자가 프로덕션 원격 분석 정의에 의미 있게 기여할 수 있는 방법에 대한 구체적인 지침이 거의 없다는 것을 알았습니다. 이 가이드는 개발자가 원격 측정의 상태를 평가하고 개선할 수 있는 경로를 제안하는 실용적인 제안을 제공하기 위한 것입니다. 개발자 기대치를 프로덕션 시스템의 런타임 동작과 밀접하게 연결하는 관찰 가능성 프로그램은 비정상적인 조건을 진단하고 수정하는 데 훨씬 더 효과적입니다. 보다 직접적인 개발자 연결은 또한 보다 강력하고 성능이 뛰어난 서비스를 생성합니다.

다음 중 하나라도 해당되는 경우 이 가이드를 사용하기에 좋은 후보자입니다.

• 귀하의 개발 팀은 프로덕션 관찰 가능성 설계에서 연결이 끊어졌습니다.
• 생산 모니터링 프로그램은 새로운 서비스/기능의 도입과 원격 측정 및 경고 적용 범위 사이의 지연으로 어려움을 겪고 있습니다.
• 진단 및 비즈니스 KPI 측정을 개선하려면 계측에 추가 비즈니스 컨텍스트를 제공해야 합니다.
• 고도로 맞춤화되거나 독점 소프트웨어 프레임워크를 사용합니다.
• 귀하의 서비스는 현재 개발 중입니다. 레거시 서비스 및 상용 기성 플랫폼에서 구축된 서비스는 일반 계측 옵션과 함께 더 잘 제공되는 경향이 있습니다.

요망되는 결과

이 가이드는 서비스의 런타임 작업(코드 실행)과 외부 실행 측정(합성 테스트를 통해)에서 파생된 메트릭에 중점을 둡니다. 서비스 계측 계획은 원격 분석을 통해 단일 서비스 런타임을 설명하는 데 사용되는 접근 방식입니다.

최신 모니터링 시스템은 서비스 구현의 기술적 세부 사항에 대한 깊은 통찰력을 제공합니다. 분산 추적 또는 바이트코드 계측 기능을 통해 운영 팀은 상세한 서비스 원격 분석을 신속하게 수집할 수 있습니다. 불행히도 운영 팀은 계측기에서 수집한 원격 측정의 품질을 평가할 수 있는 최적의 위치에 있지 않은 경우가 많습니다. 이 문제는 서비스 제공 팀이 라이브 프로덕션 시스템에서 처음으로 원격 측정 수집을 구현해야 한다는 사실로 인해 더욱 복잡해졌습니다.

해당 계측을 개선할 목적으로 프로덕션 사용자에게 부적절하게 계측된 서비스를 노출하면 고객 만족을 위험에 빠뜨리는 기간이 생성됩니다. 소프트웨어 제공과 관찰 가능성 프로그램 간의 강력한 연결 없이 코드 기반에서 새로운 기능이 제공되기 때문에 이 번인 기간은 종종 탈출하기 어려워집니다.

서비스 계측 개선에 개발 직원을 참여시키면 다음과 같은 방식으로 관찰 가능성 이점을 실현해야 합니다.

1. 더 나은 정보에 입각한 개발 결정:

• 변동성 또는 예상치 못한 행동의 영역을 감지하고 해결합니다.
• 코드에서 중복성 또는 견고성이 부족한 종속성을 이해하고 서비스를 리팩토링하기 위한 조치를 취합니다.
• 최종 사용자 집단이 귀하의 소프트웨어를 어떻게 사용하는지 감사합니다. 개선 사항이 가장 큰 영향을 미치는 부분을 더 잘 이해할 수 있습니다.

2. 개선된 문제 해결:

• 서비스의 보다 정확하고 상황에 맞는 원격 분석을 통해 오류를 보다 정확하고 실행 가능한 방식으로 감지할 수 있습니다.
• 더 나은 원격 분석 이름 지정을 통해 운영 직원은 인시던트 중에 개발자와 공통 언어를 사용하여 인시던트를 분류하고 수정하는 시간을 줄일 수 있습니다.

핵심 성과 지표

소프트웨어 제공 및 운영 프로그램의 지속적인 개선을 측정하는 데 도움이 되는 몇 가지 간단한 KPI를 식별하는 것이 중요합니다. 개선된 계측에 투자할 때 고려해야 할 두 가지 주요 KPI 유형이 있습니다.

• 비즈니스 KPI 는 전체 프로그램 목표에 맞게 조정되며 각 서비스에 대한 지속적인 프로그램 개선을 입증하기 위해 일관되게 측정되어야 합니다.
• 실무자 KPI 는 서비스 개발 및 관리에 참여하는 사람들의 직무 실행 변화를 측정하는 데 사용됩니다.

아래에서 더 자세히 살펴보겠습니다.

비즈니스 KPI

비즈니스 KPI에는 다음이 포함됩니다.

개업의 KPI

실무자 KPI에는 다음이 포함됩니다.

전제 조건

개발 프로세스에 서비스 계측 방식을 도입하기 전에 New Relic University 에서 제공하는 New Relic 기본 사항에 대해 알아 보십시오.

NRU 교육 외에도 다음 문서 리소스를 검토하고 편리하게 보관하십시오.

• APM 에이전트 설치 및 구성

• 계측 가이드:

  • C-SDK
  • 가다
  • 자바
  • .그물
  • 노드.js
  • PHP
  • 파이썬
  • 루비
  • OpenTelemetry SDK

• New Relic 합성 모니터링 소개

현재 상태 설정

서비스의 현재 상태를 설정하려면 다음 두 단계를 거쳐야 합니다.

• 계측 요구 사항 결정
• 엔드포인트 테스트 이해

이에 대해서는 아래에서 더 자세히 설명합니다.

계측 요구 사항 결정

계측은 소프트웨어 시스템의 런타임 동작 및 비즈니스 기능을 설명할 목적으로 소프트웨어 시스템 및 관련 서비스에서 원격 측정을 획득하는 프로세스입니다. 모니터링 시스템은 소프트웨어 시스템의 기능을 모니터링할 때 간격을 좁히기 위해 미세 조정할 수 있는 원격 측정 수집을 위한 일반 기능을 제공하는 경향이 있습니다. 이 사용 사례에서는 관찰 가능성 프로그램이 고객 경험 - 품질 기반 가이드 를 완료했으며 서비스에 대해 잘 고려되고 배포된 원격 분석 수집 아키텍처가 있다고 가정합니다.

경보 정의를 제외하고 계측은 관찰 가능성과 관련하여 가장 개방적이고 사용자 정의 가능한 활동을 제공합니다. New Relic 플랫폼은 기기를 고도로 맞춤화할 수 있는 기능을 제공합니다. 이 때문에 서비스를 계측하는 데 들일 시간과 노력을 신중하게 고려해야 합니다.

모든 서비스 계측 자산 및 종속성과 마찬가지로 계측 도입에는 지속적인 감독 및 유지 관리가 필요하므로 프로젝트에 대해 발생하게 될 기술적 부채의 한 형태입니다. 계측 프로세스를 시작할 때 계속해서 스스로에게 다음과 같은 질문을 하고 싶습니다.

이 계측을 통해 얻을 수 있는 가시성이 구현 및 지원 비용의 가치가 있습니까?

결정 매트릭스

첫 번째 단계로 관찰 가능성 플랫폼에서 얻은 기본 계측을 평가하고 스스로에게 질문해야 합니다.

원격 측정이 내 서비스의 기능과 목적을 적절하게 설명합니까?

당신의 서비스가 무엇을 하는지 생각해보세요. 아마도 주문을 받고 주문의 무결성을 검증해야 하고 해당 주문을 교환소 서비스에 전달하고 요청자에게 다시 전달되는 확인 코드를 수신할 수 있습니다. 이 예는 서비스 기능을 세분화하고 서비스가 어떻게 작동하는지에 대한 정보에 입각한 평가를 하기에 충분한 원격 측정 및 컨텍스트가 있는지 평가할 수 있는 명확한 경로를 제공합니다.

이 개념 다이어그램이 서비스 구현을 나타내는 경우 언제든지 알아야 합니다.

• 얼마나 많은 요청을 받습니까?
• 얼마나 많은 메시지와 HTTP 요청을 보내야 합니까?
• 얼마나 많은 요청이 성공했습니까?
• 전체 요청에 대한 응답 시간은 얼마입니까?
• 종속성에 대한 호출에 대한 응답 시간은 얼마입니까?
• 이 프로세스는 몇 개의 요청에서 얼마나 많은 리소스를 사용해야 합니까?
• 내 모든 실패 지점은 무엇입니까?

애플리케이션 런타임을 위한 대부분의 모니터링 프레임워크는 이와 같은 원격 측정을 기본 기능으로 수집합니다. 그러나 때때로 서비스의 특정 구현은 모니터링 소프트웨어에서 만든 일반적인 계측 가정에 대한 문제를 제기합니다. 이 경우 관찰 가능성 플랫폼은 요구 사항을 수용하고 기본 모니터링 구성을 수정할 수 있는 기능을 제공해야 합니다.

다음 표에는 계측을 통해 추가 원격 분석 또는 메타데이터 캡처를 추가하는 것을 고려할 수 있는 몇 가지 추가 상황이 나와 있습니다. 다음의 사례 섹션에서는 관찰 가능성 플랫폼이 서비스를 관리하는 데 필요한 원격 측정을 제공하도록 이러한 격차를 줄이는 방법을 설명합니다.

계측에 대한 고려 사항:

엔드포인트 테스트 이해

끝점 테스트는 주어진 시스템 오류의 근본 원인을 결정하는 방법을 크게 가속화하는 간단하고 실용적인 접근 방식입니다. 이를 통해 운영 및 지원 팀은 실제 문제가 있음을 신속하게 파악하고 해당 문제를 특정 서비스로 격리할 수 있습니다.

최신 소프트웨어 시스템은 작업을 완료하기 위해 여러 서비스에 의존합니다. 역사적으로 이러한 서비스 엔드포인트를 모니터링하는 프로세스는 간단했습니다. 아키텍처 팀은 운영 팀에 대해 잘 문서화된 종속성 맵을 생성합니다. 운영 팀은 충실하게 항목별 엔드포인트를 확인합니다.

오늘날에는 지속적인 전달 프로세스와 소규모 배치 변경으로 운영 팀이 종합 검사를 예측하고 사전에 정의하기 어려운 속도로 새로운 엔드포인트와 종속성을 생성하고 배포할 수 있습니다. 서비스 개발자에게 개발 단계에서 프로덕션 서비스 테스트를 정의할 수 있는 더 큰 제어 범위를 제공함으로써 관찰 가능성 프로그램에 대한 엔드포인트 테스트 범위를 크게 늘릴 수 있습니다.

결정 매트릭스

합성 수표를 생성할지 여부를 결정하는 것은 간단합니다. 종속성에 대한 실패의 첫 번째 발생을 알고 싶을 것입니다. 다음 질문 중 하나라도 "예"라고 답한 경우 전용 종합 검사를 만드는 것이 좋습니다.

• 엔드포인트가 고객을 대상으로 합니까?
• 끝점이 새 종속성을 호출합니까?
• 엔드포인트가 다른 네트워크 인프라에 있습니까?
• 엔드포인트가 여러 서비스 간에 공유됩니까?
• 엔드포인트가 CDN에서 지원하는 콘텐츠 출처입니까?

개선 프로세스

개선 프로세스에는 종종 다음과 같은 주요 단계가 포함됩니다.

• 계측 구성
• 서비스 기능 격리
• 사용자 정의 트랜잭션 이름 정의
• 서비스 구성 요소 측정
• 프레임워크가 측정되었는지 확인
• 모든 외부 통화 추적
• 엔드포인트 테스트

이제 더 자세히 살펴보겠습니다.

계측 구성

각 New Relic 에이전트는 다양한 구성 옵션을 제공합니다. 일반적으로 인프라 호스트, 애플리케이션 런타임 및 클라우드 서비스 공급자에 대한 연결 내에 에이전트를 포함하는 표준 접근 방식을 정의합니다. 기본 에이전트 구성은 일반적이며 광범위하게 적용할 수 있습니다.

개발자가 배포 적용 가능성에 영향을 미치는 가장 좋은 방법 중 하나는 서비스 인스턴스에 대한 기본 구성 옵션을 재정의하는 것입니다. 다음은 고려해야 할 기본 계측 옵션입니다.

효과적인 서비스 이름 만들기

서비스에 부여한 이름은 네임스페이스 를 제공합니다(에이전트 데이터를 찾을 수 있는 위치). New Relic이 서비스의 동작을 이해하기 위해 사용하는 가장 중요한 전략 중 하나는 유사한 것을 함께 집계하고 집계에서 파생된 공통점을 사용하여 분산을 분리하는 것입니다.

최신 서비스는 종종 용량 처리 또는 특정 기능 세분화를 보장하기 위해 여러 컨텍스트에 배포됩니다. 집계의 이점을 활용하려면 서비스 런타임이 동일한 운영 특성을 가진 인스턴스를 그룹화하는 것이 매우 중요합니다. 따라서 서비스를 배포할 때 배포된 서비스의 이름을 지정하는 데 도움이 되도록 다음 세 가지 기준에 세심한 주의를 기울이십시오.

• 내 서비스가 특정 고객을 대상으로 합니까?
• 내 서비스가 다른 코드베이스를 실행하고 있습니까?
• 내 코드베이스가 다른 런타임 구성을 사용하고 있습니까?

이러한 질문에 "예"라고 답한 경우 서비스에 대한 고유한 이름을 만드는 것이 좋습니다.

청중 기준

청중을 최종 사용자 또는 서비스 기능의 그룹으로 생각하십시오. 서비스가 북미 및 유럽 배포 간에 분할된 경우 해당 배포의 런타임을 그에 따라 그룹화해야 합니다. 예를 들어:

newrelic.appname = PORTAL_AMER

그리고

newrelic.appname = PORTAL_EMEA

이렇게 하면 해당 대상이 만든 원격 분석을 함께 그룹화하여 특정 사용자 대상과 관련된 서비스 문제의 컨텍스트 유사성을 더 잘 이해할 수 있습니다.

때때로 우리가 애플리케이션을 배포하는 방식은 관리 기능이 있는 포털 애플리케이션과 같은 서비스의 운영 컨텍스트를 나눕니다. 관리 기능이 일반 포털 코드베이스에 포함되어 있을 수 있지만 클러스터의 한 인스턴스만 포털 관리 요청을 처리합니다. 이 경우 기능적 잠재고객 세분화 기회가 있으므로 적절한 이름을 지정해야 합니다. 예를 들어:

newrelic.appname = PORTAL_MAIN

그리고

newrelic.appname = PORTAL_ADMIN

코드베이스 기준

하나의 서비스를 가장하여 다른 코드 버전을 실행하는 경우 해당 런타임 인스턴스를 분할하고 이름 지정 체계의 일부로 버전 이름 지정을 통합하는 것을 고려하십시오. 다른 서비스 버전을 실행하는 하나의 서비스 이름으로 코드를 그룹화하면 생성하는 모든 메트릭의 신호 대 잡음비가 증가합니다.

다른 코드 버전은 다른 양의 컴퓨팅 리소스를 사용하거나 데이터를 다르게 처리할 수 있습니다. 메트릭에서 얻은 신호가 다른 기능 구현으로 인한 경우 서비스가 정상적으로 작동하는지 확인하기가 매우 어려워집니다.

여러 버전을 동시에 실행하는 경우 서비스 이름에 숫자 식별자를 추가하는 것이 좋습니다. 예를 들어:

newrelic.appname = PORTAL_MAIN_V112

그리고

newrelic.appname = PORTAL_MAIN_V115

LaunchDarkly 또는 Split과 같은 기능 플래그 프레임워크 프레임워크를 사용하는 경우 단일 코드베이스 내에 여러 버전의 애플리케이션 또는 서비스가 있을 수 있습니다. 이러한 조건을 해결하려면 서비스 기능 격리에 대한 섹션을 참조하십시오.

런타임 기준

서비스 인스턴스가 런타임 제약 조건이 다른 시스템에 배포되는 경우 자체 원격 분석 네임스페이스에 캡슐화되어야 합니다. 이는 공유 리소스에 대한 네트워크 연결 이점을 제공하는 다른 데이터 센터에 배포하거나 서비스가 다른 메모리 또는 스레드 구성을 사용하여 별도의 컴퓨팅 계층에서 실행 중일 수 있습니다.

코드 런타임 작업에 영향을 주는 이러한 특성으로 인해 다른 작업 동작으로 이어지는 다양한 동작이 발생할 수 있습니다. 예를 들어:

newrelic.appname = PORTAL_NYC_DC

그리고

newrelic.appname = PORTAL_REALLY_BIG_FOOTPRINT

기본 에이전트 구성 재정의

각 New Relic APM 에이전트는 기본 구성을 수정하기 위한 다양한 옵션을 제공합니다. 가장 포괄적이고 일관된 위치는 각 에이전트 설치와 함께 제공되는 구성 파일입니다. 그러나 New Relic 에이전트는 명령줄 매개변수를 서비스 인스턴스 런타임에 직접 전달하거나, 환경 변수를 사용하거나, 런타임 시 에이전트의 SDK 내에서 함수를 호출하여 구성할 수도 있습니다.

.NET 에이전트 구성 옵션은 다음과 같습니다.

• New Relic .NET SDK API 사용
• 환경 변수
• 구성 파일 옵션

서비스 기능 격리

효과적인 서비스 이름 만들기 섹션에 표시된 것처럼 계측의 주요 목표 중 하나는 유사한 런타임 제약 조건을 단일 명명된 단위로 그룹화하도록 New Relic 에이전트를 구성하는 것입니다. 소프트웨어 시스템이 결정론적 방식으로 작동해야 하기 때문에 우리는 이것을 제안합니다.

특정 입력 세트의 경우 예상 범위의 측정 가능한 결과를 얻어야 합니다. 이러한 제약 조건을 명명된 서비스 런타임 구성 요소에 편안하게 포함할 수 있는 정도는 정상적인 동작을 이해하고 비정상적인 동작을 격리하는 데 크게 도움이 됩니다.

효과적인 서비스 명명 전략을 결정했으면 다음 단계는 서비스에 대해 수집된 원격 분석을 살펴보고 서비스의 기능을 적절하게 격리하는지 확인하는 것입니다. 우리가 가장 자주 접하는 구현 패턴은 웹 요청에 의해 호출되는 일련의 함수입니다. 서비스 런타임에 대한 웹 요청을 처음 수신하고 처리하면 처리 리소스가 할당됩니다. New Relic은 이 리소스 할당 및 코드 실행을 트랜잭션으로 정의합니다.

New Relic 에이전트는 감지되는 트랜잭션에 대한 네임스페이스를 생성하는 일련의 가정으로 구성됩니다. 이러한 가정은 에이전트 언어 런타임에 따라 다릅니다. 예를 들어 New Relic Java 에이전트가 트랜잭션 이름을 결정하는 방법에 대한 좋은 예는 Java 에이전트의 트랜잭션 이름 지정 설명서 에서 찾을 수 있습니다.

그러나 에이전트 트랜잭션 명명 프로토콜을 적용한 후에도 만족스럽지 못한 결과를 남길 수 있습니다. 컨텍스트를 개선하기 위해 트랜잭션의 이름을 지정하는 추가 도구를 추가하면 서비스의 실행 동작에 대한 이해가 크게 향상될 수 있습니다.

트랜잭션 이름 지정의 목표는 개발자가 아닌 사람도 이해하기 쉬운 접근 방식으로 서비스 기능을 잘 분할하는 APM 트랜잭션 보기여야 합니다.

트랜잭션 분석 이미지는 트랜잭션 세분화의 좋은 예입니다. 서비스의 더 넓은 코드베이스 내에서 각 트랜잭션이 수행하는 작업의 양에 대한 자세한 추적을 제공합니다. 또한 비즈니스 컨텍스트(트랜잭션이 수행하는 작업)에 대한 힌트를 제공하는 일반 사용자 친화적인 이름으로 트랜잭션을 표시합니다. 트랜잭션 이름 지정 및 속성 포함에 대해 자세히 알아볼 때 데이터의 비기술적 관찰자가 이름 지정 접근 방식에 액세스할 수 있도록 해야 합니다.

둔감한 트랜잭션 분석 이미지는 트랜잭션 이름 세분화의 나쁜 예를 보여줍니다. 이 경우 트랜잭션 볼륨의 약 60%가 OperationHandler/handle 으로 지정됩니다. 트랜잭션 볼륨의 백분율 속성과 이름의 일반적인 특성은 모두 해당 트랜잭션 네임스페이스 아래에 지나치게 열성적인 트랜잭션 집계가 있을 수 있음을 나타냅니다.

트랜잭션 이름 지정 접근 방식을 검증하는 좋은 방법은 서비스 웹 트랜잭션 히스토그램 대시보드에서 상당한 기간 동안 트랜잭션에 대한 응답 시간 분포를 검토하는 것입니다.

서비스 트랜잭션 이미지는 광범위한 트랜잭션 응답률을 보여줍니다. 대부분의 트랜잭션이 0-200밀리초 범위에 있지만 200-1000밀리초 범위의 값을 나타냅니다. 트랜잭션에 대해 매우 분산된 응답 범위가 있는 경우 다음과 같이 자문해야 합니다.

이 트랜잭션의 이름을 지정하는 데 도움이 될 수 있는 트랜잭션 실행 중 어떤 정보가 있습니까?

많은 경우에 비정규 분포는 매개변수가 요청에 전달되거나 트랜잭션이 수행하도록 요청받은 작업의 직접적인 결과입니다. 서비스 쿼리 트랜잭션이 데이터 범위를 매개변수로 사용할 수 있다고 생각하는 것은 매우 쉽습니다. 날짜 범위가 작을수록 조회 시간이 더 빨라질 수 있습니다. 따라서 일부 예상 매개변수 제약 조건(> 1일, 1-5일, >5일)에서 파생된 의미 체계를 제공하면 보다 의미 있는 세분화를 제공할 수 있습니다.

목표는 고유한 특성이 가장 적은 트랜잭션을 그룹화하는 데 도움이 되는 트랜잭션 이름을 만드는 것입니다.

정규 분포 이미지는 서비스 내에서 보다 의도적으로 명명된 트랜잭션을 보여줍니다. 이 경우 웹 트랜잭션 응답 시간이 더 밀접하게 그룹화되어 일관된 실행 특성을 나타냅니다.

트랜잭션 명명 전략이 수행하는 작업 유형별로 서비스 기능을 그룹화하는 일관된 메커니즘을 제공하도록 함으로써 비정상적인 동작을 신속하게 격리하거나 변형의 근본 원인을 더 잘 이해할 수 있습니다. 이를 통해 애플리케이션을 리팩토링하고 서비스 기능의 전반적인 예측 가능성을 높일 수 있습니다.

사용자 정의 트랜잭션 이름 정의

New Relic 에이전트 트랜잭션 이름 지정 서비스에는 New Relic 에이전트 SDK에 대한 SetName(String name) 유사 API 호출이 필요합니다. 각 언어 런타임 에이전트에는 이름을 설정하기 위한 고유한 구문과 옵션이 있습니다.

예를 들어 HTTP 요청 매개변수의 값을 가져와 New Relic Java 에이전트에서 트랜잭션의 이름을 지정하는 데 사용하려면 다음과 유사한 코드를 사용할 수 있습니다.

com.newrelic.agent.Agent.LOG.finer("[my query handler] Renaming transaction based on an important query parameter");

com.newrelic.api.agent.NewRelic.setTransactionName("Query Handler_" + (javax.servlet.http.HttpServletRequest)_servletrequest_0).getParameter("important_query_parm"));

참고: New Relic 트랜잭션 이름에는 최대 용량이 있습니다. 트랜잭션 이름 지정 전략은 수천 개의 잠재적 트랜잭션 이름이 있는 경우 어느 정도의 특수성을 절충해야 합니다.

너무 많은 트랜잭션 이름이 보고되면 New Relic은 해당 트랜잭션 이름을 그룹화하는 규칙을 만들려고 시도합니다. 자세한 내용은 메트릭 그룹화 문제와 관련된 에이전트 문제 해결 가이드 에서 찾을 수 있습니다.

메트릭 그룹화 문제가 의심되는 경우 New Relic으로 지원 사례를 여십시오. 그러면 트랜잭션 이름 지정 문제의 원인을 격리하기 위해 기꺼이 협력하겠습니다.

트랜잭션으로 매개변수 캡처

트랜잭션 이름은 서비스 동작을 더 잘 이해할 수 있도록 서비스 기능을 세분화하는 강력한 방법입니다. 이를 통해 New Relic UI에서 직접 기능을 개별적으로 분리할 수 있습니다.

그러나 트랜잭션 이름을 분리하지 않고 서비스 기능에 대한 추가 컨텍스트를 얻으려는 경우가 많습니다. 이는 서비스에서 특성 캡처를 도입하여 수행할 수 있습니다.

name:value 쌍 속성을 추가하여 각 거래의 세부정보를 꾸밀 수 있습니다. 속성은 APM 트랜잭션 추적 및 오류 UI를 통해 또는 Transaction 이벤트 유형에서 매개변수의 직접 쿼리를 통해 각 트랜잭션 이벤트에서 사용할 수 있습니다.

다음은 APM 오류 UI에서 볼 수 있는 트랜잭션 추적 세부 정보의 예입니다.

유용한 트랜잭션 이름 세분화를 개발했다면 속성의 추가 컨텍스트를 사용하여 예기치 않은 결과를 가져온 입력, 집단 또는 세그먼트를 더 잘 이해할 수 있습니다.

APM UI 내에서 트랜잭션의 컨텍스트를 이해할 수 있을 뿐만 아니라 매개변수의 도입은 트랜잭션 데이터를 직접 쿼리하여 트랜잭션을 집계하고 분석하는 데 매우 유용한 도구입니다. 사용자 정의 속성이 각 트랜잭션에 추가되어 특정 조건을 쉽게 분리하고 패싯합니다.

매개변수 캡처 접근 방식은 Split 또는 LaunchDarkly와 같은 기능 플래그 시스템과 함께 사용할 수도 있습니다. 이 경우 기능 플래그에 대한 결정 핸들러를 구현할 때 고객에게 표시되는 버전이나 기능을 제어하는 코드 블록에 적용되는 플래그 컨텍스트(예: optimized_version = on )를 캡처하는 것을 고려하십시오.

예를 들어 HTTP 요청 매개변수의 값을 가져와 New Relic Java 에이전트와 함께 사용자 정의 속성으로 저장하려면 다음과 유사한 코드를 사용할 수 있습니다.

com.newrelic.agent.Agent.LOG.finer("[my query handler] Adding an Attribute to transaction based on an important query parameter");

com.newrelic.api.agent.NewRelic.addCustomParameter("ImportantParm", (javax.servlet.http.HttpServletRequest)_servletrequest_0).getParameter("important_query_parm"));

서비스 구성 요소 측정

서비스 컨텍스트 내에서 특정 트랜잭션의 동작은 기능을 분리하고 소프트웨어 시스템이 효과적으로 작동하도록 하는 강력한 방법입니다. 그러나 소프트웨어 시스템의 동작을 보는 또 다른 방법은 구현의 세부 구성 요소 실행 모델을 검토하는 것입니다. 애플리케이션 프레임워크 코드 구성 요소는 서비스 전체에서 공유되며 구성 요소 성능에 대한 지속적인 평가는 전체 서비스 상태에 대한 통찰력을 제공할 수 있습니다.

New Relic에는 구성 요소 실행 세부 정보를 관찰할 수 있는 두 곳이 있습니다. APM의 서비스 요약 대시보드는 구성 요소(예: 가비지 수집 실행 또는 데이터베이스 호출)별로 분류된 서비스의 복합 실행 보기를 제공합니다.

유사한 분류가 거래별로 제공됩니다.

트랜잭션 구성 요소 세그먼트는 일관된 성능 동작을 나타내는 경향이 있으므로 이 일관성을 사용하여 기본 동작의 변경 사항을 감지할 수 있습니다. 이것은 근본적인 문제의 좋은 표시가 될 수 있습니다. 리소스 제약은 개별 트랜잭션 세부 정보보다 구성 요소 프레임워크 내에서 더 명확하게 나타나는 경향이 있습니다. 이를 통해 서비스 내에서 실행되는 모든 코드에서 경험하는 공통 제약 조건을 통해 종속성의 특성을 추론할 수 있습니다.

프레임워크가 측정되었는지 확인

프레임워크 계측을 위한 구문은 서비스가 작성된 언어에 따라 다르지만 일반적인 접근 방식은 모든 사람에게 일관됩니다. 서비스 내의 실행 스레드를 New Relic 원격 측정 내의 트랜잭션에 대한 비유로 고려하십시오. 스택의 각 메서드 또는 함수 실행은 추가 계측을 추가할 수 있는 기회입니다. 이러한 방식으로 New Relic은 트랜잭션에 대한 시간 주석이 있는 호출 스택을 유지 관리하고 이러한 메서드/함수 시작/중지 타이밍을 사용하여 일련의 구성 요소 메트릭으로 집계합니다.

특정 논리 세그먼트가 서비스 또는 트랜잭션의 기능에 중요한 경우 해당 호출을 New Relic 에이전트에 대한 콜백으로 래핑하여 에이전트가 개별 코드 구성 요소에 들어갔다는 것을 이해하고 해당 시간 내에서 소비된 시간을 집계할 수 있도록 하십시오. 그에 따라 구성 요소. 콜백에 메트릭 이름을 전달하여 서비스 및 트랜잭션에 대한 구성 요소 세그먼트 메트릭을 생성합니다.

메트릭 이름 지정 옵션은 계측 언어에 따라 다르므로 특정 언어 설명서를 참조하십시오.

New Relic 에이전트를 사용하면 계측에 대한 사용자 지정 메트릭 이름을 지정할 수 있습니다. metricName 은 구성요소에 대해 집계된 측정항목을 결정하는 데 사용됩니다. 다음 예는 자바 에이전트 SDK @Trace 주석에 전달되는 metricName 매개변수를 보여줍니다.

@Weave
public abstract class MQOutboundMessageContext implements OutboundTransportMessageContext {

    @Trace(dispatcher = true, metricName="MQTransport")
    public void send(final TransportSendListener listener) throws TransportException {
        try {
            NewRelic.getAgent().getTracedMethod().setMetricName("Message", "MQ", "Produce");
            MQHelper.processSendMessage(this, NewRelic.getAgent().getTracedMethod());
        } catch (Exception e) {
            NewRelic.getAgent().getLogger().log(Level.FINE, e, "Unable to set metadata on outgoing MQ message");
        }

        Weaver.callOriginal();
    }

}

모든 외부 서비스 호출 추적

클라이언트 계측은 서비스에서 외부 리소스에 대한 호출을 캡슐화하는 것을 말합니다. 일반적으로 New Relic 에이전트는 HTTP, gRPC, 메시징 및 데이터베이스 프로토콜에 널리 사용되는 클라이언트를 인식하고 적절한 계측 패턴을 적용하여 해당 클라이언트에 대한 호출을 외부 서비스로 집계합니다.

프로토콜에 대한 고유한 클라이언트 핸들러를 작성했거나 매우 새롭거나 약간의 틈새를 사용하는 경우 New Relic 에이전트는 클라이언트를 인식하지 못하고 클라이언트 호출의 동작을 기록할 수 있습니다. 이를 위해 APM 내의 외부 서비스 및 데이터베이스를 확인하여 서비스에 대해 예상되는 모든 외부 효과를 나타내야 합니다.

모든 서비스의 종속성이 여기에 표시되는지 확인하는 것이 중요합니다. 서비스 종속성이 표시되지 않으면 APM 에이전트가 적절하게 추적할 수 있도록 외부 호출을 가로채기 위해 새로운 계측을 도입해야 합니다. 다음 예는 상담원이 캡처하기 위해 Golang에서 외부 호출을 래핑하는 방법을 보여줍니다.

package main

import (
    "net/http"

    "github.com/newrelic/go-agent/v3/newrelic"
)

func currentTransaction() *newrelic.Transaction {
    return nil
}

func main() {
    txn := currentTransaction()
    client := &http.Client{}
    request, _ := http.NewRequest("GET", "http://www.example.com", nil)
    segment := newrelic.StartExternalSegment(txn, request)
    response, _ := client.Do(request)
    segment.Response = response
    segment.End()
}

다른 에이전트 API 외부 호출 추적의 예:

• 가다 ExternalSegment
• 자바 ExternalParameters
• 파이썬 external_trace

엔드포인트 테스트

엔드포인트 테스트는 서비스 계측 프로그램에 두 가지 이점을 제공합니다.

• 결함 감지: 단순한 참/거짓 결과를 생성하는 끝점에 대한 테스트를 인코딩하여 운영 팀이 서비스 제공의 무결성이 손상되었는지 판단하기 위해 개별 오류를 분리할 수 있습니다.
• 기준 설정: 종합 또는 기계 테스트는 제어 관점에서 서비스 제공의 일관성을 평가할 수 있는 예측 가능한 조건 세트를 제공합니다.

New Relic의 종합 모니터링은 향상된 Selenium JavaScript SDK를 사용하여 다양한 테스트 유형을 생성할 수 있는 기능을 제공합니다. Selenium 기반 테스트 스크립트가 정의되면 New Relic은 스크립트 실행 위치와 빈도를 관리합니다.

합성 테스트는 각각 고유한 초점이 있는 다양한 테스트 옵션을 제공합니다. 자세한 내용은 종합 모니터링 설명서 를 참조하십시오.

서비스 개발자의 관점에서 가장 많이 사용되는 모니터 유형은 엔드포인트 가용성 입니다. 이 모니터 유형은 HTTP 요청 조건을 스크립팅하는 기능을 제공합니다. 이는 액세스 가능한 API에 대한 POST 또는 GET만큼 간단하거나 Selenium 모니터링 스크립트가 다단계 프로세스의 기능적 무결성을 확인하기 위해 요청을 연속적으로 평가하는 여러 단계를 포함할 수 있습니다.

실제로 개발자는 끝점 가용성과 무결성을 평가하기 위해 가능한 가장 간단한 테스트를 구현하는 것을 고려해야 합니다. 예를 들어, 통화 그룹에 대한 현재 환율을 제공하는 새 서비스 끝점을 방금 만들었습니다. 이것은 JSON 개체 배열을 반환하는 끝점에서 간단한 GET입니다.

• 요청 예: http://example-ip:3000/exchange
• 응답 예:

[
  {
    "status": [
      "quote"
    ],
    "_id": "5b9bf97f61c22f4fb5beb5c9",
    "name": "cdn",
    "Created_date": "2021-07-12T18:10:07.488Z",
    "__v": 1
  },
  {
    "status": [
      "quote"
    ],
    "_id": "5b9bfb2a61c22f4fb5beb5ca",
    "name": "usd",
    "Created_date": "2021-07-12T18:17:14.224Z",
    "__v": 0.80
  },
  {
    "status": [
      "quote"
    ],
    "_id": "5b9bfb3261c22f4fb5beb5cb",
    "name": "eur",
    "Created_date": "2021-07-12T18:17:22.476Z",
    "__v": 0.68
  },
  {
    "status": [
      "quote"
    ],
    "_id": "5b9bfb3761c22f4fb5beb5cc",
    "name": "mex",
    "Created_date": "2021-07-12T18:17:27.009Z",
    "__v": 15.97
  }
]

이 서비스가 작동 가능한 것으로 간주되려면 요청에 응답해야 하지만 4가지 통화 응답도 제공해야 합니다. 우리는 현재 콘텐츠에 대해 걱정하지 않고 각 CDN, USD, EUR 및 MEX 통화에 대해 하나의 배열에 4개의 요소를 다시 가져온다는 사실에 대해 걱정하지 않습니다.

New Relic 합성 모니터링을 사용하면 API 테스트 스크립트는 다음과 같이 보일 수 있습니다.

/**
* This script checks to see if we get the currency data from the endpoint.
*/
var assert = require('assert');
var myQueryKey = 'secret_key';
var options = {
  uri: 'http://example_ip:3000/exchange',
  headers: {
    'X-Query-Key': myQueryKey,
    'Accept': 'application/json'
  }
};

function callback (err, response, body){
  var data = JSON.parse(body);
  var info = body;
  if (Array.isArray(data)) {
    if (data.length !== 4) {
      assert.fail('Unexpected results in API Call, result was ' + JSON.stringify(data));
    }
  }
}

$http.get(options, callback);

합성 스크립트는 New Relic 인터페이스에서 직접 구성할 수 있지만 소스 리포지토리 시스템 내에서 엔드포인트 테스트를 유지 관리하고 자동화를 사용하는 것이 좋습니다. 이렇게 하면 서비스가 프로덕션 서비스 제공에 도입하는 새로운 엔드포인트 종속성을 엔드포인트 테스트가 수반하는지 확인하는 데 도움이 됩니다.

가치 실현

서비스 계측의 영향은 프로세스를 감독하는 데 투자하려는 관심 수준과 직접적인 관련이 있습니다. 서비스 모니터링 프로세스와 마찬가지로 관찰 가능성 프로그램은 노력에 대한 투자에 대한 기대 수익에 대해 비판적으로 생각하는 전담 팀 기능을 통해 이점을 얻을 수 있습니다. 다음은 조직의 투자 비용과 기대 효과에 대해 생각하기 위한 몇 가지 지침입니다.

다음 섹션에서는 서비스 계측을 관찰 가능성 관행에 통합하여 예상해야 하는 투자 및 수익을 추정하는 접근 방식을 간략하게 설명합니다.

투자

보고