올바른 서비스 원격 측정 캡처

계측 요구 사항 결정

먼저, 구체적으로 무엇을 해야 하는지 결정해야 합니다. 비즈니스 요구 사항을 충족하는 모든 서비스에는 다음 질문에 답할 수 있는 충분한 도구가 있어야 하며, 이제 어떤 부분에 답할 수 있고 답할 수 없는지 확인하여 어떤 영역에 집중해야 하는지 알 수 있습니다.

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

계측 구성

다음으로 계측 구성을 시작할 차례입니다. 각 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

newrelic.appname = PORTAL_NYC_DC

newrelic.appname = PORTAL_REALLY_BIG_FOOTPRINT

기본 에이전트 구성 재정의

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

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

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

서비스 기능 격리

효과적인 서비스 이름 만들기 섹션에 표시된 대로 계측의 기본 목표 중 하나는 유사한 런타임 제약 조건을 단일 명명 단위로 그룹화하도록 New Relic 에이전트를 구성하는 것입니다. 특정 입력 세트에 대해 예상되는 측정 가능한 결과 범위를 얻어야 합니다. 이러한 항목을 명명된 서비스 런타임 구성 요소에 편안하게 포함할 수 있으면 정상적인 동작을 이해하고 문제를 격리하는 데 큰 도움이 됩니다.

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

그러나 에이전트 트랜잭션 명명 프로토콜을 적용한 후에도 필요에 따라 만족스럽지 못한 결과를 얻을 수 있습니다. 트랜잭션 이름을 지정하고 컨텍스트를 개선하기 위한 추가 계측을 추가하면 서비스 실행 동작에 대한 이해를 크게 향상시킬 수 있습니다.

트랜잭션 이름 지정의 목표는 개발자가 아닌 사람도 쉽게 이해할 수 있는 접근 방식으로 서비스 기능을 효과적으로 분할하는 APM 트랜잭션 보기가 되어야 합니다. 위의 거래 내역 이미지는 거래 분할의 좋은 예입니다. 이는 서비스의 광범위한 코드베이스 내에서 각 트랜잭션이 수행하는 작업량에 대한 자세한 추적을 제공할 뿐만 아니라 트랜잭션이 수행하는 작업에 대한 통찰력을 제공하는 사용자 친화적인 일반 이름을 사용하여 트랜잭션을 제공합니다. 트랜잭션 이름 지정 및 속성 포함에 대해 자세히 알아보면 기술적 지식이 없는 데이터 관찰자가 액세스할 수 있는 이름 지정 접근 방식을 만들어야 합니다.

위 이미지의 거래 분석은 거래 이름 분할의 나쁜 예를 보여줍니다. 이 경우 거래량의 약 60%에 OperationHandler/handle 이라는 이름이 지정됩니다. 트랜잭션 볼륨의 속성 백분율과 이름의 일반적인 특성은 모두 해당 네임스페이스 아래에 트랜잭션이 너무 많이 집계되었을 수 있음을 나타냅니다.

귀하의 목표는 아래와 같이 고유한 특성이 가장 적은 그룹 거래를 용이하게 하는 거래 이름을 만드는 것입니다.

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

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

New Relic 에이전트 트랜잭션 이름 지정 서비스를 사용하려면 New Relic 에이전트 SDK에 대한 SetName(String name)같은 API 호출을 호출해야 합니다. 각 언어 런타임 에이전트에는 이름 설정을 위한 고유한 구문과 옵션이 있습니다. 자세한 정보가 필요하면 아래 예를 참조하세요.

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 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 에이전트에 대한 콜백으로 래핑하여 에이전트가 개별 코드 구성 요소를 입력했음을 이해하고 해당 코드 내에서 소비된 시간을 집계할 수 있도록 하는 것이 좋습니다. 그에 따라 구성 요소. 콜백에 지표 이름을 전달하면 서비스 및 트랜잭션에 대한 구성 요소 세그먼트 지표가 생성됩니다.

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

우리 에이전트를 사용하면 계측에 대한 사용자 정의 측정항목 이름을 지정할 수 있습니다. 구성요소에 대해 집계된 측정항목을 결정하기 위해 metricName 사용합니다. 다음 예에서는 Java 에이전트 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, 메시징 및 데이터베이스 프로토콜에 널리 사용되는 클라이언트를 인식하고 적절한 계측 패턴을 적용하여 해당 클라이언트에 대한 호출을 외부 서비스로 집계합니다.

프로토콜에 대한 자체 클라이언트 핸들러를 작성했거나 매우 새로운 것을 사용하는 경우 에이전트가 클라이언트를 인식하지 못하고 클라이언트 호출 동작을 기록하지 못할 수 있습니다. 이를 위해서는 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

엔드포인트 테스트

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

• Defect detection:

  간단한 참/거짓 결과를 생성하는 엔드포인트에 대한 테스트를 인코딩함으로써 운영에서는 개별 오류를 격리하여 서비스 제공의 무결성이 손상되었는지 확인할 수 있습니다.

• Baselining:

  신세틱스 또는 기계 테스트는 제어 관점에서 서비스 제공의 일관성을 평가할 수 있는 예측 가능한 조건 세트를 제공합니다.

  우리의 종합 모니터링은 향상된 Selenium JavaScript SDK를 사용하여 다양한 테스트 유형을 생성하는 기능을 제공합니다. Selenium 기반 테스트 스크립트가 정의되면 스크립트 실행 위치와 빈도를 관리합니다. 합성 테스트는 각각 고유한 초점을 가진 다양한 테스트 옵션을 제공합니다. 자세한 내용은 합성 모니터링 문서를 참조하세요.

  먼저 종합 검사를 위한 결정 매트릭스를 만들어야 합니다. 합성 수표를 생성해야 하는지 여부를 아는 것은 간단합니다. 종속성에 대한 첫 번째 실패 발생을 알고 싶을 것입니다. 다음 질문 중 하나라도 "예"라고 대답한다면 전용 종합 검사 생성을 고려해 보십시오.

• 엔드포인트가 고객을 대상으로 합니까?

• 끝점이 새 종속성을 호출합니까?

• 엔드포인트가 다른 네트워크 인프라에 있습니까?

• 엔드포인트가 여러 서비스 간에 공유됩니까?

• 엔드포인트가 CDN에서 지원하는 콘텐츠 출처입니까?

  그런 다음 엔드포인트 가용성과 무결성을 평가하기 위해 가능한 가장 간단한 테스트 구현을 고려해야 합니다. 예를 들어, 통화 그룹에 대한 현재 환율을 제공하는 새로운 서비스 엔드포인트를 방금 생성했습니다. 이는 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 인터페이스에서 합성 스크립트를 직접 구성할 수 있지만 소스 리포지토리 시스템 내에서 엔드포인트 테스트를 유지하고 자동화를 사용하는 것이 좋습니다. 이를 통해 엔드포인트 테스트에는 서비스가 프로덕션 서비스 제공에 도입하는 새로운 엔드포인트 종속성이 수반됩니다.