인제스트 데이터 최적화

APM 에이전트가 생성하는 데이터의 양은 다음과 같은 여러 요인에 의해 결정됩니다.

• 애플리케이션에 의해 생성된 유기적 트래픽의 양(예를 들어, 하루에 백만 번 호출되는 애플리케이션은 모든 것이 동일하면 하루에 1,000번 호출되는 애플리케이션보다 더 많은 데이터를 생성함)

• 기본 트랜잭션 데이터 자체의 일부 특성(URL의 길이 및 복잡성)

• 애플리케이션이 데이터베이스 쿼리를 보고하는지 여부

• 애플리케이션에 많은(또는 임의의) 사용자 정의 속성이 있는 트랜잭션이 있는지 여부

• 애플리케이션의 오류 볼륨

• 애플리케이션 에이전트가 분산 추적을 위해 구성되었는지 여부

  볼륨 관리

  애플리케이션에 대한 모든 호출이 필요하다고 가정할 수 있지만 전체 아키텍처를 보다 효율적으로 만드는 것이 가능합니다. 클라이언트가 10초마다 호출하는 사용자 프로필 마이크로서비스가 있을 수 있습니다. 이것은 일부 사용자 정보가 다른 클라이언트에 의해 업데이트되는 경우 대기 시간을 줄이는 데 도움이 됩니다. 그러나 예를 들어 이 서비스에 대한 호출 빈도를 매분으로 줄이는 옵션이 있습니다.

  사용자 정의 속성

  APM API 에 대한 호출을 사용하여 추가된 addCustomParameter 사용 자 정의 속성은 트랜잭션 페이로드에 추가 속성을 추가합니다. 이들은 종종 유용하지만 상황이 바뀌면 데이터의 가치가 떨어지거나 쓸모 없게 될 수도 있습니다.

  Java 에이전트는 기본적으로 다음 request.headers 을 캡처합니다.

• request.headers.referer

• request.headers.accept

• request.headers.contentLength

• request.headers.host

• request.headers.userAgent

  개발자는 addCustomParameter 사용하여 자세한 헤더를 사용하여 더 많은 정보를 캡처할 수도 있습니다.

  APM과 관련하여 사용할 수 있는 풍부한 구성의 예는 Java 에이전트 설명서를참조하십시오.

  오류 이벤트

  APM이 오류를 처리하는 방법을 찾아 데이터 양을 줄일 수 있습니다. 예를 들어 현재 제거할 수 없는 무해하지만 용량이 큰 오류가 있을 수 있습니다.

  이렇게 하려면 오류에 대해 collect, ignore 또는 mark as expected 사용할 수 있습니다. 자세한 내용은 APM 오류 관리를 참조하십시오.

  데이터베이스 쿼리

  APM 인스턴스의 매우 가변적인 측면 중 하나는 데이터베이스 호출 수 및 구성 설정입니다. 이를 돕기 위해 데이터베이스 쿼리 모니터링의 자세한 정도를 제어할 수 있습니다. 이러한 쿼리는 Transaction traces 페이지에 표시됩니다.

  일반적인 데이터베이스 쿼리 설정 변경 사항은 다음과 같습니다.

• 쿼리 수집을 난독화하거나 해제하는 대신 원시 쿼리 데이터를 수집합니다.

• 스택 추적 임계값을 변경합니다.

• 쿼리 설명 계획 수집을 켭니다.

  자세한 내용은 트랜잭션 추적 데이터베이스 쿼리 페이지 를 참조하세요.

  이벤트 제한 설정

  APM 및 모바일 에이전트는 수집 주기당 보고할 수 있는 이벤트 수에 제한이 있습니다. 제한이 없는 경우 전송된 이벤트 수가 충분히 많으면 애플리케이션 또는 New Relic의 성능에 영향을 미칠 수 있습니다. 한계에 도달하면 에이전트는 이벤트 샘플링을 시작하여 수확 주기 전반에 걸쳐 이벤트를 나타냅니다. 에이전트마다 한도가 다릅니다.

  제한이 있고 샘플링 대상인 이벤트에는 다음이 포함됩니다.

• 에이전트 API를 통해 보고된 사용자 지정 이벤트(예: .NET 에이전트의 RecordCustomEvent )

• Mobile

• MobileCrash

• MobileHandledException

• MobileRequest

• Span (분산 추적 샘플링 참조)

• Transaction

• TransactionError

  대부분의 에이전트에는 샘플링된 트랜잭션에 대한 이벤트 제한을 변경하기 위한 구성 옵션이 있습니다. 예를 들어 Java 에이전트는 max_samples_stored 사용합니다. max_samples_stored 의 기본값은 2000 이고 최대값은 10000 입니다. 이 값은 에이전트 인스턴스에서 60초마다 보고할 수 있는 샘플링된 이벤트 수를 제어합니다. 이벤트 샘플링 제한에 대한 전체 설명은 이벤트 제한 을 참조하십시오.

  NRQL EXTRAPOLATE 연산자 를 통해 샘플링된 이벤트를 보정할 수 있습니다.

  샘플링 발생 방식을 변경하기 전에 다음 사항에 유의하십시오.

• 보고하는 이벤트가 많을수록 에이전트는 더 많은 메모리를 사용합니다.

• 일반적으로 에이전트의 이벤트 보고 한도를 높이지 않고도 필요한 데이터를 얻을 수 있습니다.

• 페이로드 크기 제한은 1MB(10^6바이트)(압축)이므로 이벤트 수는 여전히 해당 제한의 영향을 받을 수 있습니다. 이벤트가 삭제되고 있는지 확인하려면 413 HTTP 상태 메시지에 대한 에이전트 로그를 참조하십시오.

  로그 샘플링 속도

  New Relic APM 언어 에이전트의 최신 버전은 로그를 New Relic에 직접 전달할 수 있습니다. 경우에 따라 각 APM 에이전트 인스턴스에서 발생할 수 있는 대규모 로깅 스파이크의 일부 제한을 제어할 수 있습니다.

  APM 에이전트 로그 샘플링에 대한 자세한 내용은 로그 전달자 를 참조하십시오.

  트랜잭션 추적

  성장 동력

  • 연결된 서비스 수
  • 연결된 서비스당 모니터링되는 메서드 호출 수

  APM에서 트랜잭션 추적 은 애플리케이션의 트랜잭션 및 데이터베이스 호출에 대한 심층적인 세부 정보를 기록합니다. 트랜잭션 추적에 대한 기본 설정을 편집할 수 있습니다.

  이는 또한 트랜잭션 추적 구성을 통해 구성할 수 있습니다. 구성 가능성의 수준과 모드는 언어별로 다릅니다.

  서버 측 구성을 사용하여 사용할 수 있는 트랜잭션 추적 설정은 사용하는 New Relic 에이전트에 따라 다릅니다. UI에는 각각에 대한 설명이 포함되어 있습니다. UI 설정에는 다음이 포함될 수 있습니다.

• 트랜잭션 추적 및 임계값

• 기록 수준 및 입력 필드를 포함한 기록 SQL

• 로그 SQL 및 스택 추적 임계값

• SQL 쿼리 계획 및 임계값

• HTTP 코드 및 오류 클래스를 포함한 오류 수집

• 느린 쿼리 추적

• 스레드 프로파일러

  분산 추적

  분산 추적 구성에는 몇 가지 언어별 차이점이 있습니다. 필요에 따라 분산 추적을 비활성화할 수 있습니다. 다음은 Java 에이전트 newrelic.yml 에 대한 예입니다.

  distributed_tracing:
      enabled: false

  카피

  이것은 node.js의 예입니다. newrelic.js

  distributed_tracing: {
    enabled: false
  }

  카피

  또한 데이터 볼륨은 Infinite Tracing 사용 여부에 따라 달라집니다. APM 에이전트에 대한 표준 분산 추적(위)은 추적의 최대 10%를 캡처하지만 모든 데이터를 분석하고 가장 관련성이 높은 추적을 찾으려면 무한 추적을 설정할 수 있습니다. 표준 분산 추적에 대한 이 대안은 모든 APM 언어 에이전트에서 사용할 수 있습니다. 월별 수집을 약간 증가시킬 수 있는 주요 매개변수는 다음과 같습니다.

• 추적 관찰자 모니터링 구성

• 스팬 속성 추적 필터 구성

• 임의 추적 필터 구성

브라우저 에이전트 버전 1211 이상에서는 페이지의 모든 네트워크 요청이 AjaxRequest 이벤트로 기록됩니다. 애플리케이션 설정 UI 페이지에서 거부 목록 구성 옵션을 사용하여 이벤트를 기록하는 요청을 필터링할 수 있습니다. 이 필터에 관계없이 모든 네트워크 요청은 메트릭으로 캡처되고 AJAX 페이지에서 사용할 수 있습니다.

거부 목록 사용

세 가지 방법으로 요청을 차단할 수 있습니다.

• 모든 AjaxRequest 이벤트의 기록을 차단하려면 별표 * 를 와일드카드로 추가하십시오.

• 도메인에 대한 AjaxRequest 이벤트 기록을 차단하려면 도메인 이름만 입력하세요. 예시: example.com

• 특정 도메인 및 경로에 대한 AjaxRequest 이벤트의 기록을 차단하려면 도메인 및 경로를 입력하세요. 예시: example.com/path

• URL의 프로토콜, 포트, 검색 및 해시는 거부 목록에서 무시됩니다.

  추가한 필터가 예상대로 작동하는지 확인하려면 필터와 일치하는 AjaxRequest 이벤트에 대해 NRQL 쿼리를 실행하세요.

  거부 목록 액세스

  애플리케이션이 이벤트 생성에서 필터링할 URL의 거부 목록을 업데이트하려면 앱 설정 UI 페이지로 이동하십시오.

1. one.newrelic.com

   으로 이동하여

   Browser

   클릭합니다.

2. 앱을 선택하세요.

3. 왼쪽 탐색 메뉴에서

   App settings

   클릭합니다.

4. Ajax request deny list

   아래에 적용할 필터를 추가합니다.

5. 에이전트 설정을 업데이트하려면

   Save application settings

   선택하세요.

6. 연결된 APM 에이전트를 다시 시작하거나 브라우저 설치 복사/붙여넣기를 업데이트하여 브라우저 에이전트를 다시 배포하십시오.

   검증

   FROM AjaxRequest SELECT * WHERE requestUrl LIKE `%example.com%`

   카피

Android

에이전트 호출을 포함한 모든 설정은 MainActivity 클래스의 onCreate 메서드에서 호출됩니다. 설정을 변경하려면 다음 두 가지 방법 중 하나로 설정을 호출합니다(설정이 지원하는 경우).

NewRelic.disableFeature(FeatureFlag.DefaultInteractions);
NewRelic.enableFeature(FeatureFlag.CrashReporting);
NewRelic.withApplicationToken(NEW_RELIC_TOKEN).start(this.getApplication());

분석 설정은 이벤트 데이터 수집을 활성화하거나 비활성화합니다. 이러한 이벤트는 Crash analysis 페이지에 보고되고 사용됩니다.

에이전트 로깅 을 다소 장황하게 구성할 수도 있습니다.

iOS

Android와 마찬가지로 New Relic의 iOS 구성에서는 기능 플래그 를 활성화 및 비활성화할 수 있습니다.

다음 기능 플래그를 구성할 수 있습니다.

충돌 및 오류 보고

• NRFeatureFlag_CrashReporting
• NRFeatureFlag_HandleExceptionEvents
• NRFeatureFlag_CrashReporting

분산 추적

• NRFeatureFlag_DistributedTracing

상호작용

• NRFeatureFlag_DefaultInteractions
• NRFeatureFlag_InteractionTracing
• NRFeatureFlag_SwiftInteractionTracing

네트워크 기능 플래그

• NRFeatureFlag_ExperimentalNetworkInstrumentation
• NRFeatureFlag_NSURLSessionInstrumentation
• NRFeatureFlag_NetworkRequestEvents
• NRFeatureFlag_RequestErrorEvents
• NRFeatureFlag_HttpResponseBodyCapture

자세한 내용은 기능 플래그 를 참조하십시오.

인프라 에이전트 구성 파일에는 수집 볼륨을 제어하는 두 가지 방법이 포함되어 있습니다. 가장 중요한 수집 제어는 샘플링 속도를 구성하는 것입니다. 조정할 수 있는 몇 가지 고유한 샘플링 속도 구성이 있습니다. ProcessSample 및 NetworkSample 과 같은 특정 수집기에서 수집되는 항목을 제어하는 정규식을 만들 수도 있습니다.

구성 가능한 샘플링 속도

인프라에서 구성할 수 있는 많은 샘플링 속도가 있지만 이것이 가장 일반적으로 사용됩니다.

공정 샘플

프로세스 샘플은 호스트에서 실행 중인 모든 프로세스에 대한 정보를 전송하기 때문에 인프라 에이전트에서 가장 많은 양의 단일 데이터 소스인 경우가 많습니다. 기본적으로 비활성화되어 있지만 다음과 같이 활성화할 수 있습니다.

enable_process_metrics: true

이는 metrics_process_sample_rate -1 로 설정하는 것과 동일한 효과가 있습니다. 기본적으로 낮은 메모리를 사용하는 프로세스는 샘플링에서 제외됩니다. 자세한 내용은 disable-zero-mem-process-filter 참조하십시오.

메트릭 속성 의 값을 기반으로 메트릭 데이터의 전송을 제한할 수 있는 include_matching_metrics 구성하여 보내는 데이터의 양을 제어할 수 있습니다. 메트릭 속성에 대한 리터럴 또는 부분 값을 정의하여 메트릭 데이터를 포함합니다. 예를 들어 process.name ^java 정규식과 일치하는 모든 프로세스의 host.process.cpuPercent 을 보내도록 선택할 수 있습니다.

이 예에서는 실행 파일과 이름을 사용하여 프로세스 메트릭을 포함합니다.

include_matching_metrics:             # You can combine attributes from different metrics
    process.name:
      - regex "^java"                   # Include all processes starting with "java"
    process.executable:
      - "/usr/bin/python2"              # Include the Python 2.x executable
      - regex "\\System32\\svchost"     # Include all svchost executables

Kubernetes 통합에 이 필터를 사용할 수도 있습니다.

env:
    - name: NRIA_INCLUDE_MATCHING_METRICS
      value: |
        process.name:
          - regex "^java"
        process.executable:
          - "/usr/bin/python2"
          - regex "\\System32\\svchost"

네트워크 인터페이스 필터

구성은 다음 패턴에 따라 특정 문자 또는 숫자 시퀀스로 시작하는 인터페이스를 찾을 수 있는 간단한 패턴 일치 메커니즘을 사용합니다.

• {name}[other characters]
• [number]{name}[other characters], 여기서 index-1 옵션을 사용하여 이름을 지정합니다.

network_interface_filters:
  prefix:
    - dummy
    - lo
  index-1:
    - tun

Linux용 기본 네트워크 인터페이스 필터:

• dummy , lo , vmnet , sit , tun , tap 또는 veth
• tun 또는 tap

Windows용 기본 네트워크 인터페이스 필터:

• Loop , isatap 또는 Local

기본값을 재정의하려면 구성 파일에 고유한 필터를 포함합니다.

network_interface_filters:
  prefix:
    - dummy
    - lo
  index-1:
    - tun

사용자 정의 속성

사용자 지정 속성은 인프라 에이전트의 데이터에 주석을 추가하는 데 사용되는 다른 도구의 태그와 유사한 키-값 쌍입니다. 이 메타데이터를 사용하여 필터 세트를 작성하고 결과를 그룹화하고 데이터에 주석을 달 수 있습니다. 예를 들어 머신의 환경(스테이징 또는 프로덕션), 머신이 호스트하는 서비스(예: 로그인 서비스) 또는 해당 머신을 담당하는 팀을 나타낼 수 있습니다.

사용자 정의 속성의 예 newrelic.yml

custom_attributes:
  environment: production
  service: billing
  team: alpha-team

Kubernetes와 같은 복잡하고 분산된 시스템은 짧은 시간 내에 많은 원격 측정을 생성할 수 있는 잠재력이 있습니다. Kubernetes에서 데이터 수집을 관리하는 몇 가지 좋은 방법이 있습니다. K8s 배포에서 관찰 가능성을 코드로 사용하는 경우 매우 간단합니다.

수집 감소에 대한 결정을 내리기 전에 이 Kubernetes 데이터 수집 분석 대시보드를 설치하는 것이 좋습니다. 이 대시보드를 얻으려면 인프라 통합 빠른 시작 을 참조하십시오.

긁는 간격

관찰 가능성 목표에 따라 기본 시간이 15초인 스크랩 간격 조정을 고려할 수 있습니다. Kubernetes 클러스터 탐색기는 45초마다 새로 고쳐집니다. Kubernetes 데이터의 주요 용도가 KCE 시각화를 지원하는 것이라면 스크랩 간격을 20초로 변경하는 것을 고려할 수 있습니다. 15초에서 20초로 변경하면 상당한 영향을 미칠 수 있습니다.

이를 관리하는 방법에 대한 자세한 내용은 Helm 통합 스크랩 간격 문서를 참조하세요.

네임스페이스 필터링

Kubernetes 통합 버전 3 이상에서는 라벨을 지정하여 스크랩할 네임스페이스를 필터링할 수 있습니다. 기본적으로 모든 네임스페이스는 스크랩됩니다.

Kubernetes와 동일한 방식으로 namespaceSelector 를 사용합니다. 라벨과 일치하는 네임스페이스만 포함하려면 newrelic-infrastructure 섹션 아래에서 values-newrelic.yaml 에 다음을 추가하여 namespaceSelector 을 변경합니다.

common:
  config:
    namespaceSelector:
      matchLabels:
        key1 : "value1"

이 예에서는 레이블이 newrelic.com/scrape 인 네임스페이스만 true 로 스크랩됩니다.

global:
  licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
  cluster: _K8S_CLUSTER_NAME_

# ... Other settings as shown above

# Configuration for newrelic-infrastructure
newrelic-infrastructure:
  # ... Other settings as shown above
  common:
    config:
      namespaceSelector:
        matchLabels:
          newrelic.com/scrape: "true"

Kubernetes 일치 식을 사용하여 네임스페이스를 포함하거나 제외할 수도 있습니다. 유효한 연산자는 다음과 같습니다.

• In
• NotIn
• Exists
• DoesNotExist

matchExpressions 섹션의 일반 구조는 다음 행 중 하나 이상입니다.

{key: VALUE, operator: OPERATOR, values: LIST_OF_VALUES}

다음은 완전한 예입니다.

common:
  config:
    namespaceSelector:
      matchExpressions:
      - {key: newrelic.com/scrape, operator: NotIn, values: ["false"]}

이 예에서는 newrelic.com/scrape 레이블이 false 로 설정된 네임스페이스가 제외됩니다.

global:
  licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
  cluster: _K8S_CLUSTER_NAME_

# ... Other settings as shown above

# Configuration for newrelic-infrastructure
newrelic-infrastructure:
  # ... Other settings as shown above
  common:
    config:
      namespaceSelector:
        matchExpressions:
        - {key: newrelic.com/scrape, operator: NotIn, values: ["false"]}

차트의 README 파일 에서 할 수 있는 설정의 전체 목록을 확인하세요.

제외된 네임스페이스를 어떻게 알 수 있습니까? [#excluded-namespaces]

클러스터 내의 모든 네임스페이스는 K8sNamespace 샘플 덕분에 나열됩니다.nrFiltered 속성은 네임스페이스와 관련된 데이터를 스크랩할지 여부를 결정합니다.

이 쿼리를 사용하여 모니터링 중인 네임스페이스를 확인합니다.

FROM K8sNamespaceSample SELECT displayName, nrFiltered
WHERE clusterName = INSERT_NAME_OF_CLUSTER SINCE
2 MINUTES AGO

제외된 네임스페이스에서 어떤 데이터가 삭제됩니까? [#namespaces-discarded-data]

다음 샘플은 제외된 네임스페이스에 사용할 수 없습니다.

• K8sContainerSample
• K8sDaemonsetSample
• K8sDeploymentSample
• K8sEndpointSample
• K8sHpaSample
• K8sPodSample
• K8sReplicasetSample
• K8sServiceSample
• K8sStatefulsetSample
• K8sVolumeSample

Kubernetes 상태 메트릭

Kubernetes 클러스터 탐색기에는 다음 KSM(kube 상태 메트릭)만 필요합니다.

• 컨테이너 데이터

• 클러스터 데이터

• 노드 데이터

• 포드 데이터

• 볼륨 데이터

• API 서버 데이터

  1

• 컨트롤러 관리자 데이터

  1

• ETCD 데이터

  1

• 스케줄러 데이터

  1

¹ 관리되는 Kubernetes 환경(EKS, GKE, AKS 등)에서 수집되지 않음

다음 중 일부를 비활성화하는 것을 고려할 수 있습니다.

• DaemonSet 데이터

• 배포 데이터

• 엔드포인트 데이터

• 네임스페이스 데이터

• 레플리카세트 데이터

  2

• 서비스 데이터

• StatefulSet 데이터

² 기본 경고에 사용됨: "ReplicaSet에 원하는 양의 포드가 없습니다."

매니페스트(배포)에서 상태 메트릭 업데이트의 예

$
[spec]
$
  [template]
$
    [spec]
$
      [containers]
$
        [name=kube-state-metrics]
$
        [args]
$
        #- --collectors=daemonsets
$
        #- --collectors=deployments
$
        #- --collectors=endpoints
$
        #- --collectors=namespaces
$
        #- --collectors=replicasets
$
        #- --collectors=services
$
        #- --collectors=statefulsets

매니페스트(ClusterRole)에서 상태 메트릭 업데이트의 예

$
[rules]
$
# - apiGroups: ["extensions", "apps"]
$
#   resources:
$
#   - daemonsets
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: ["extensions", "apps"]
$
#   resources:
$
#   - deployments
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: [""]
$
#   resources:
$
#   - endpoints
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: [""]
$
#   resources:
$
#   - namespaces
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: ["extensions", "apps"]
$
#   resources:
$
#   - replicasets
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: [""]
$
#   resources:
$
#   - services
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: ["apps"]
$
#   resources:
$
#   - statefulsets
$
#   verbs: ["list", "watch"]

nri-bundle 차트의 구성 lowDataMode

Helm 차트는 자세한 정보를 삭제하는 대신 수집되는 데이터의 양을 줄이는 옵션을 지원합니다. 활성화하려면 nri-bundle 차트에서 global.lowDataMode true 로 설정하세요.

lowDataMode nri-bundle 차트의 세 가지 특정 구성요소에 영향을 미칩니다.

1. 인프라 에이전트 간격을 15 }초에서 30 초로 늘립니다.
2. Prometheus OpenMetrics 통합은 아래 Helm 문서에 표시된 대로 몇 가지 메트릭을 제외합니다.
3. 레이블 및 주석 세부정보가 로그에서 삭제됩니다.

이 구성에 대한 자세한 내용은 Helm 문서 에서 찾을 수 있습니다.

New Relic의 온호스트 통합은 Postgresql, MySQL, Kafka, RabbitMQ 등과 같은 타사 서비스에 대한 다양한 통합 세트를 나타냅니다. 이 문서의 범위에서 모든 최적화 기술을 제공하는 것은 불가능하지만 일반적으로 다음 기술이 적용됩니다.

• 샘플링 속도 관리

• 수집 범위를 늘리거나 줄일 수 있는 구성 부분 관리

• 사용자 지정 쿼리를 허용하는 구성 부분 관리

• 모든 온호스트 통합 데이터에 적용할 인프라 에이전트의 사용자 정의 속성을 관리합니다.

  몇 가지 예를 사용하여 보여드리겠습니다.

  PostgreSQL 통합

  성장 동력

  • 모니터링되는 테이블 수
  • 모니터링되는 인덱스 수

  PostgreSQL 온-호스트 통합 구성은 데이터 볼륨을 관리하는 데 도움이 될 수 있는 다음과 같은 조정 가능한 설정을 제공합니다.

• interval: 기본값은 15초입니다.

• COLLECTION_LIST: 모니터링할 테이블 목록(ALL을 사용하여 ALL을 모니터링)

• COLLECT_DB_LOCK_METRICS: dblock 측정항목 수집

• PGBOUNCER: pgbouncer 측정항목 수집

• COLLECT_BLOAT_METRICS: 팽창 지표 수집

• METRICS: 측정항목만 수집하려면 true 으로 설정합니다.

• INVENTORY: 인벤토리 수집만 활성화하려면 true 으로 설정합니다.

• CUSTOM_METRICS_CONFIG: 사용자 지정 컬렉션 쿼리가 포함된 구성 파일

  Sample config:

  integrations:
    - name: nri-postgresql
      env:
        USERNAME: postgres
        PASSWORD: pass
        HOSTNAME: psql-sample.localnet
        PORT: 6432
        DATABASE: postgres
        COLLECT_DB_LOCK_METRICS: false
        COLLECTION_LIST: '{"postgres":{"public":{"pg_table1":["pg_index1","pg_index2"],"pg_table2":[]}}}'
        TIMEOUT:  10
      interval: 15s
      labels:
        env: production
        role: postgresql
      inventory_source: config/postgresql

  카피

  카프카 통합

  성장 동력

  • 클러스터의 브로커 수
  • 클러스터의 주제 수

  Kafka 온-호스트 통합 구성은 데이터 볼륨을 관리하는 데 도움이 될 수 있는 다음과 같은 조정 가능한 설정을 제공합니다.

• interval: 기본값은 15초입니다.

• TOPIC_MODE: 수집하는 주제의 수를 결정합니다. 옵션은 all , none , list 또는 regex 입니다.

• METRICS: 측정항목만 수집하려면 true 으로 설정합니다.

• INVENTORY: 인벤토리 수집만 활성화하려면 true 으로 설정합니다.

• TOPIC_LIST: 모니터링할 주제 이름의 JSON 배열입니다. topic_mode가 list로 설정된 경우에만 적용됩니다.

• COLLECT_TOPIC_SIZE: 메트릭 토픽 크기를 수집합니다. 옵션은 true 또는 false 이며 기본값은 false 입니다.

• COLLECT_TOPIC_OFFSET: 메트릭 토픽 오프셋을 수집합니다. 옵션은 true 또는 false 이며 기본값은 false 입니다.

  주제 수준 지표, 특히 오프셋의 수집은 수집하는 데 리소스를 많이 사용할 수 있으며 데이터 볼륨에 영향을 미칠 수 있습니다. 클러스터에 새로운 Kafka 토픽을 추가하는 것만으로도 클러스터의 수집이 10배 증가할 수 있습니다.

  몽고DB 통합

  성장 동력

  • 모니터링되는 데이터베이스 수

  MongoDB 통합은 데이터 볼륨을 관리하는 데 도움이 될 수 있는 다음과 같은 조정 가능한 설정을 제공합니다.

• interval: 기본값은 15초입니다.

• METRICS: 측정항목만 수집하려면 true 으로 설정합니다.

• INVENTORY: 인벤토리 수집만 활성화하려면 true 으로 설정합니다.

• FILTERS: 컬렉션 이름 배열에 대한 데이터베이스 이름의 JSON 맵. 비어 있으면 기본적으로 모든 데이터베이스와 컬렉션이 사용됩니다.

  사용하는 온호스트 통합의 경우 기본값이 모든 데이터베이스에서 측정항목을 수집하는 것인 FILTERS 와 같은 매개변수를 인식하는 것이 중요합니다. 모니터링 우선 순위를 사용하여 수집된 데이터를 간소화할 수 있는 영역입니다.

  Example configuration with different intervals for METRIC and INVENTORY:

  integrations:
    - name: nri-mongodb
      env:
        METRICS: true
        CLUSTER_NAME: my_cluster
        HOST: localhost
        PORT: 27017
        USERNAME: mongodb_user
        PASSWORD: mongodb_password
      interval: 15s
      labels:
        environment: production
  
    - name: nri-mongodb
      env:
        INVENTORY: true
        CLUSTER_NAME: my_cluster
        HOST: localhost
        PORT: 27017
        USERNAME: mongodb_user
        PASSWORD: mongodb_password
      interval: 60s
      labels:
        environment: production
      inventory_source: config/mongodb

  카피

  Elasticsearch 통합

  성장 동력

  • 클러스터의 노드 수
  • 클러스터의 인덱스 수

  Elasticsearch 통합은 데이터 볼륨을 관리하는 데 도움이 될 수 있는 다음과 같은 조정 가능한 설정을 제공합니다.

• interval: 기본값은 15초입니다.

• METRICS: 측정항목만 수집하려면 true 으로 설정합니다.

• INVENTORY: 인벤토리 수집만 활성화하려면 true 으로 설정합니다.

• COLLECT_INDICES: 인덱스 메트릭을 수집할지 여부를 나타냅니다.

• COLLECT_PRIMARIES: 기본 메트릭을 수집할지 여부를 나타냅니다.

• INDICES_REGEX: 인덱스를 수집하는 필터입니다.

• MASTER_ONLY: 선출된 마스터에서만 클러스터 메트릭을 수집합니다.

  Example configuration with different intervals for METRICS and INVENTORY:

  integrations:
    - name: nri-elasticsearch
      env:
        METRICS: true
        HOSTNAME: localhost
        PORT: 9200
        USERNAME: elasticsearch_user
        PASSWORD: elasticsearch_password
        REMOTE_MONITORING: true
      interval: 15s
      labels:
        environment: production
  
    - name: nri-elasticsearch
      env:
        INVENTORY: true
        HOSTNAME: localhost
        PORT: 9200
        USERNAME: elasticsearch_user
        PASSWORD: elasticsearch_password
        CONFIG_PATH: /etc/elasticsearch/elasticsearch.yml
      interval: 60s
      labels:
        environment: production
      inventory_source: config/elasticsearch

  카피

  JMX 통합

  성장 동력

  • 에 나열된 측정항목 COLLECTION_CONFIG

  JMX 통합은 본질적으로 일반적입니다. 모든 JMX 인스턴스에서 메트릭을 스크랩할 수 있습니다. 이 통합에 의해 수집되는 항목을 제어할 수 있습니다. 일부 기업에서 New Relic 환경 JMX 메트릭은 수집된 모든 데이터의 상대적으로 높은 비율을 나타냅니다.

  JMX 통합은 데이터 볼륨을 관리하는 데 도움이 될 수 있는 다음과 같은 조정 가능한 설정을 제공합니다.

• interval: 기본값은 15초입니다.

• METRICS: 측정항목만 수집하려면 true 으로 설정합니다.

• INVENTORY: 인벤토리 수집만 활성화하려면 true 으로 설정합니다.

• METRIC_LIMIT: 엔터티당 수집할 수 있는 메트릭 수입니다. 이 한도를 초과하면 엔터티가 보고되지 않습니다. 0의 제한은 제한이 없음을 의미합니다.

• LOCAL_ENTITY: 로컬 엔터티에 대한 모든 메트릭을 수집합니다. 로컬 호스트를 모니터링할 때만 사용됩니다.

• COLLECTION_FILES: 메트릭 컬렉션 정의 파일에 대한 전체 파일 경로의 쉼표로 구분된 목록입니다. 호스트에 설치하는 경우 기본 JVM 측정항목 수집 파일은 /etc/newrelic-infra/integrations.d/jvm-metrics.yml 에 있습니다.

• COLLECTION_CONFIG: 메트릭 컬렉션을 JSON으로 구성합니다.

  수집된 데이터의 양을 가장 많이 제어하는 것은 COLLECTION_CONFIG 항목입니다. 스크래핑하는 JMX 모델을 이해하면 최적화에 도움이 됩니다.

  COLLECTION_CONFIG JVM 메트릭의 예

  COLLECTION_CONFIG='{"collect":[{"domain":"java.lang","event_type":"JVMSample","beans":[{"query":"type=GarbageCollector,name=*","attributes":["CollectionCount","CollectionTime"]},{"query":"type=Memory","attributes":["HeapMemoryUsage.Committed","HeapMemoryUsage.Init","HeapMemoryUsage.Max","HeapMemoryUsage.Used","NonHeapMemoryUsage.Committed","NonHeapMemoryUsage.Init","NonHeapMemoryUsage.Max","NonHeapMemoryUsage.Used"]},{"query":"type=Threading","attributes":["ThreadCount","TotalStartedThreadCount"]},{"query":"type=ClassLoading","attributes":["LoadedClassCount"]},{"query":"type=Compilation","attributes":["TotalCompilationTime"]}]}]}'

  카피

  NonHeapMemoryUsage.Init 과 같은 해당 구성에서 하나의 항목을 생략하면 수집된 전체 데이터 볼륨에 실질적인 영향을 미칩니다.

  COLLECTION_CONFIG Tomcat 메트릭의 예

  COLLECTION_CONFIG={"collect":[{"domain":"Catalina","event_type":"TomcatSample","beans":[{"query":"type=UtilityExecutor","attributes":["completedTaskCount"]}]}]}

  카피

  기타 온-호스트 통합

  수집을 최적화하는 데 도움이 되는 구성 옵션과 함께 호스트 내 통합이 많이 있습니다. 일반적으로 사용되는 몇 가지는 다음과 같습니다.

• NGINX

• MySQL

• Redis

• 아파치

• RabbitMQ

  이것은 더 많은 것을 배우기 위한 좋은 출발점 입니다.

이 섹션은 Kentik의 ktranslate 에이전트에 의존하는 New Relic의 네트워크 성능 모니터링에 중점을 둡니다. 이 에이전트는 매우 정교하며 주요 최적화 작업을 수행하기 전에 고급 구성 문서 를 완전히 이해하는 것이 중요합니다. 구성 옵션에는 다음이 포함됩니다.

• mibs_enabled: KTranslate 도커 이미지가 폴링할 모든 활성 MIB의 배열입니다. 이 목록은 discovery_add_mibs 속성이 true 인 경우 검색 중에 자동으로 생성됩니다. 여기에 나열되지 않은 MIB는 구성 파일의 어떤 장치에서도 폴링되지 않습니다. MIB-NAME.tableName 구문을 사용하여 MIB 파일에서 직접 SNMP 테이블을 지정할 수 있습니다. 예: HOST-RESOURCES-MIB.hrProcessorTable .

• user_tags: 키:값 쌍 속성을 사용하여 장치에 더 많은 컨텍스트를 제공합니다. 이 수준의 태그는 구성 파일의 모든 장치에 적용됩니다.

• devices: 흐름을 모니터링할 장치를 나열하는 섹션

• traps: SNMP 트랩으로 모니터링할 IP 및 포트를 구성합니다(기본값은 127.0.0.1:1162 ).

• discovery: 끝점을 검색할 수 있는 방법을 구성합니다. 이 섹션에서 다음 매개변수는 범위를 늘리거나 줄이는 데 가장 많이 사용됩니다.

  • cidrs: CIDR 표기법 의 대상 IP 범위 배열입니다.
  • ports: SNMP 폴링 중 스캔할 대상 포트의 배열입니다.
  • debug: 검색 중에 디버그 수준 로깅을 활성화할지 여부를 나타냅니다. 기본적으로 다음으로 설정되어 있습니다. false
  • default_communities: SNMP 폴링 중에 검색할 SNMPv1/v2c 커뮤니티 문자열의 배열입니다. 이 배열은 순서대로 평가되며 발견은 첫 번째 통과 커뮤니티를 수락합니다.

  관찰 가능성 요구 사항에 대한 값을 생성하지 않는 데이터 필터링을 지원하기 위해 global.match_attributes.{} 및/또는 devices.<deviceName>.match_attributes.{} 속성 맵을 설정할 수 있습니다.

  이는 데이터를 New Relic으로 보내기 전에 KTranslate 수준에서 필터링을 제공하여 인터페이스와 같은 모니터링을 세밀하게 제어할 수 있습니다.

  자세한 내용은네트워크 성능 모니터링 구성 을 참조하십시오.

로그는 일반적으로 자체 라우팅 및 변환 규칙이 있는 전용 전달 계층을 통해 로그를 라우팅한다는 점에서 가장 유연한 원격 분석 소스 중 하나입니다. 다양한 전달자가 있으므로 가장 일반적으로 사용되는 전달자에 중점을 둘 것입니다.

• APM 언어 에이전트(최신 버전)

• 유창한

• Fluentbit

• New Relic 인프라 에이전트(내장 Fluentbit)

• 로그스태시

  APM 에이전트 로그 샘플링

  New Relic 언어 에이전트의 최신 버전은 로그를 New Relic에 직접 전달할 수 있습니다. 각 APM 에이전트 인스턴스에서 발생할 수 있는 대규모 로깅 스파이크의 일부 제한을 제어할 수 있습니다.

  환경 변수 NEW_RELIC_APPLICATION_LOGGING_FORWARDING_MAX_SAMPLES_STORED 로 샘플링을 활성화하고 APM 에이전트 로깅 대기열이 저장할 최대 로그 수를 제공하여 구성할 수 있습니다. 사용자 지정 우선 순위 대기열을 기반으로 작동하며 모든 로그 메시지에 우선 순위를 부여합니다. 트랜잭션 내에서 발생하는 로그는 트랜잭션의 우선 순위를 갖습니다.

  로그 대기열은 우선순위와 로그가 도착한 시간에 따라 정렬됩니다. 높은 우선 순위가 먼저 적용되고 필요한 경우 최신 로그가 우선 적용됩니다. 로그는 대기열에 개별적으로 추가되며(트랜잭션에 있는 로그도 포함) 한계에 도달하면 대기열 끝에 있는 로그가 최신 로그를 위해 푸시됩니다.

  아래 리소스 섹션에는 간단한 방법으로 로그 볼륨을 추적하는 데 도움이 되는 빠른 시작 대시보드가 있습니다. 추적 로그 볼륨을 사용하면 관측 가능성 요구 사항에 맞게 샘플링 속도를 조정하거나 비활성화할 수 있습니다.

  Fluentd 또는 Fluentbit에서 필터 구성

  대부분의 일반 포워더는 필터링 및 변환을 포함하는 상당히 완전한 라우팅 워크플로우를 제공합니다. 당사의 인프라 에이전트는 원치 않는 로그를 필터링하기 위한 매우 간단한 패턴을 제공합니다.

  레코드 필터링을 위한 정규식입니다. tail, systemd, syslog 및 tcp ( none 형식만 해당) 소스에 대해서만 지원됩니다. 이 필드는 Unix 시스템의 grep -E 와 유사한 방식으로 작동합니다. 예를 들어 캡처 중인 특정 파일에 대해 다음을 사용하여 WARN 또는 ERROR 포함하는 레코드를 필터링할 수 있습니다.

  - name: only-records-with-warn-and-error
      file: /var/log/logFile.log
      pattern: WARN|ERROR

  카피

  유용한 필터링 또는 구문 분석을 수행하는 Fluentbit용으로 미리 작성된 Fluentd 구성이 있는 경우 로깅 구성으로 가져올 수 있습니다. 이렇게 하려면 logging.d 폴더의 .yaml 파일에서 config_file 및 parsers 매개변수를 사용합니다.

• config_file: 기존 Fluent Bit 설정 파일의 경로입니다. 소스가 겹치면 뉴렐릭의

  로그 관리

  에 중복된 메시지가 생성됩니다.

• parsers_file: 기존 Fluent Bit 파서 파일의 경로입니다.

  다음 파서 이름이 예약되어 있습니다: rfc3164 , rfc3164-local 및 rfc5424 .

  데이터 파이프라인의 로그에 속성 또는 태그를 삽입하고 변환을 수행하는 방법을 배우면 New Relic 드롭 규칙을 사용하여 다운스트림 기능을 드롭하는 데 도움이 될 수 있습니다. 소스에 대한 메타데이터로 로그를 보강하여 백엔드에 드롭할 항목에 대한 중앙 집중식 및 되돌릴 수 있는 결정을 내릴 수 있습니다. 최소한 다음 속성이 어떤 형태로든 로그에 있는지 확인하십시오.

• 팀

• 환경(dev/stage/prod)

• 애플리케이션

• 데이터 센터

• 로그 수준

  다음은 몇 가지 자세한 라우팅 및 필터링 리소스입니다.

• Fluentd의 공통 필터 및 라우팅 패턴

• Fluentbit 데이터 파이프라인

• New Relic 인프라 에이전트로 로그 전달

  인프라 에이전트의 기본 속성 세트 조정

  인프라 에이전트는 호스트에 추가된 모든 사용자 지정 태그를 포함하여 기본적으로 일부 속성을 추가합니다. aws.[attributename] 형식으로 New Relic에 표시되는 많은 수의 AWS 태그를 포함하여 구성이 그 이상을 가져올 수 있습니다. 이러한 특성은 중요하므로 계획된 구성 변경과 관련하여 시각화, 분석 및 경고 요구 사항을 평가하는 것이 좋습니다. 예를 들어 Kubernetes 클러스터의 로그는 다음과 같은 메타데이터가 없으면 유용하지 않을 수 있습니다.

• cluster_name

• pod_name

• container_name

• node_name

New Relic은 Prometheus 지표를 New Relic으로 전송하기 위한 두 가지 기본 옵션을 제공합니다. 메트릭 수집을 관리하기 위한 모범 사례는 주로 두 번째 옵션인 POMI(Prometheus OpenMetrics 통합)에 중점을 둡니다. 이 구성 요소는 New Relic에서 생성되었기 때문입니다.

옵션 1: Prometheus 원격 쓰기 통합

Prometheus 서버 스크레이프 구성 옵션은 Prometheus 구성 문서를 참조하십시오. 이러한 스크레이프 구성은 Prometheus 서버에서 수집하는 메트릭을 결정합니다. remote_write 매개변수를 구성하면 수집된 측정항목을 New Relic Metric API를 통해 New Relic 데이터베이스(NRDB)에 쓸 수 있습니다.

옵션 2: Prometheus OpenMetrics 통합(POMI)

POMI는 동적으로 검색된 Prometheus 엔드포인트와 정적 Prometheus 엔드포인트 모두에서 메트릭을 스크랩하는 독립형 통합입니다. 그런 다음 POMI는 New Relic Metric API를 통해 이 데이터를 NRDB로 보냅니다. 이 통합은 현재 Prometheus 서버를 실행하지 않는 고객에게 이상적입니다.

POMI: 긁힌 라벨

POMI는 기본적으로 레이블 또는 주석 prometheus.io/scrape=true 을 포함하는 모든 Prometheus 엔드포인트를 검색합니다. 이것은 많은 수의 엔드포인트일 수 있으므로 클러스터에 배포된 항목에 따라 많은 수의 메트릭이 수집됩니다.

scrape_enabled_label 매개변수를 사용자 정의로 수정하는 것이 좋습니다(예: newrelic/scrape), 데이터 수집이 가장 중요한 경우 Prometheus 엔드포인트에 선택적으로 레이블을 지정합니다.

최신 참조 구성은 nri-prometheus-latest.yaml 을 참조하십시오.

POMI config parameter:

# Label used to identify scrapable targets. 
# Defaults to "prometheus.io/scrape"
  scrape_enabled_label: "prometheus.io/scrape"

POMI는 기본적으로 노드 수준에서 노출된 모든 Prometheus 끝점을 검색합니다. 여기에는 일반적으로 Kubelet 및 cAdvisor에서 오는 지표가 포함됩니다. New Relic Kubernetes Daemonset을 실행 중인 경우 POMI가 중복 측정항목을 수집하지 않도록 require_scrape_enabled_label_for_nodes: true 설정하는 것이 중요합니다.

New Relic Kubernetes Daemonset의 대상이 되는 엔드포인트 는 GitHub의 Kubernetes README를 참조하세요.

POMI: 노드에 대한 스크랩 레이블

POMI는 기본적으로 노드 수준에서 노출된 모든 Prometheus 끝점을 검색합니다. 여기에는 일반적으로 Kubelet 및 cAdvisor에서 오는 지표가 포함됩니다. New Relic Kubernetes Daemonset을 실행 중인 경우 POMI가 중복 측정항목을 수집하지 않도록 require_scrape_enabled_label_for_nodes: true 설정하는 것이 중요합니다.

New Relic Kubernetes Daemonset의 대상이 되는 엔드포인트 는 GitHub의 Kubernetes README를 참조하세요.

POMI 구성 매개변수

# Whether k8s nodes need to be labeled to be scraped or not. 
# Defaults to false.
  require_scrape_enabled_label_for_nodes: false

포미: 공존 nri-kubernetes

New Relic의Kubernetes 통합 은 즉시 여러 메트릭 을 수집합니다. 그러나 Kubernetes 클러스터에서 사용 가능한 모든 가능한 메트릭을 수집하지는 않습니다.

POMI 구성에는 뉴렐릭 Kubernetes 통합이 이미 Kube State Metrics에서 수집하고 있는 지표 하위 집합에 대한 disable 지표 수집을 수행하는 이와 유사한 섹션이 표시됩니다.

Kubelet 및 cAdvisor 측정항목이 중복되지 않도록 require_scrape_enabled_label_for_node: true 설정하는 것도 매우 중요합니다.

POMI config parameters:

transformations:
    - description: "Uncomment if running New Relic Kubernetes integration"
      ignore_metrics:
        - prefixes:
          - kube_daemonset_
          - kube_deployment_
          - kube_endpoint_
          - kube_namespace_
          - kube_node_
          - kube_persistentvolume_
          - kube_persistentvolumeclaim_
          - kube_pod_
          - kube_replicaset_
          - kube_service_
          - kube_statefulset_

POMI: 요청/제한 설정

POMI를 실행할 때 약 500k DPM을 생성하는 클러스터에 대해 다음 리소스 제한 을 적용하는 것이 좋습니다.

• CPU 제한: 1코어(1000m)
• 메모리 제한: 1Gb 1024(1G)

클러스터에서 충분한 리소스를 POMI에 제공하려면 CPU 및 메모리에 대한 리소스 요청을 설정해야 합니다. 매우 낮은 값으로 설정(예: cpu: 50m) "잡음이 많은 이웃"이 클러스터 리소스를 사용할 수 있습니다.

POMI config parameter:

spec:
  serviceAccountName: nri-prometheus
  containers:
  - name: nri-prometheus
    image: newrelic/nri-prometheus:2.2.0
    resources:
      requests:
        memory: 512Mi
        cpu: 500m
      limits:
        memory: 1G
        cpu: 1000m

POMI: DPM 및 카디널리티 추정

카디널리티가 GB 수집당 청구 가능 항목과 직접 연결되지는 않지만 New Relic은 카디널리티 및 분당 데이터 포인트에 대한 특정 속도 제한을 유지합니다. Prometheus 클러스터에서 카디널리티 및 DPM을 시각화할 수 있다는 것은 매우 중요할 수 있습니다.

Prometheus 서버를 이미 실행 중인 경우 POMI 또는 remote_write 를 활성화하기 전에 DPM 및 카디널리티 추정을 실행할 수 있습니다.

Data points per minute (DPM):

rate(prometheus_tsdb_head_samples_appended_total[10m]) * 60

Top 20 metrics (highest cardinality):

topk(20, count by (<DNT>**name**</DNT>, job)({__name__=~".+"}))

일부 New Relic 클라우드 통합은 클라우드 공급자의 API에서 데이터를 가져옵니다. 이 구현을 통해 AWS CloudWatch, Azure Monitor 및 GCP Stackdriver와 같은 모니터링 API에서 데이터가 수집되고 특정 서비스의 API에서 인벤토리 메타데이터가 수집됩니다.

다른 클라우드 통합은 AWS Kinesis와 같은 스트리밍 서비스를 통해 푸시되는 스트리밍 지표(또는 "푸시된" 지표)에서 데이터를 가져옵니다.

폴링 API 기반 통합

클라우드 통합에서 더 많거나 적은 데이터를 보고하려는 경우 또는 클라우드 계정에서 제한 속도 및 조절 제한에 도달하는 것을 방지하기 위해 클라우드 공급자의 API 사용을 제어해야 하는 경우 구성 설정을 변경하여 수정할 수 있습니다. 그들이 보고하는 데이터의 양. 두 가지 주요 컨트롤은 다음과 같습니다.

• 폴링 빈도 변경

• 보고되는 데이터 변경

  폴링 빈도를 변경하려는 비즈니스 이유의 예는 다음과 같습니다.

• Billing

  : AWS CloudWatch 청구서를 관리해야 하는 경우 폴링 빈도를 줄이는 것이 좋습니다. 이 작업을 수행하기 전에 클라우드 통합에 설정된 공지 조건이 이 축소의 영향을 받지 않는지 확인하세요.

• New services

  : 새로운 서비스나 설정을 구현, 배포하고 데이터를 더 자주 수집하려는 경우 일시적으로 폴링 빈도를 늘리는 것이 좋습니다.

  주의

  통합에 대한 구성 설정을 변경하면 경고 조건 및 차트 추세에 영향을 줄 수 있습니다.

  자세한 내용은 폴링 구성 을 참조하십시오.

  "스트리밍" 또는 "푸시된" 측정항목

  점점 더 많은 클라우드 통합이 대기 시간을 크게 줄이는 API 폴링을 사용하는 대신 스트리밍 서비스를 통해 데이터를 푸시하는 옵션을 제공하고 있습니다. 일부 사용자가 관찰한 한 가지 문제는 샘플링 속도를 구성할 수 없기 때문에 볼륨을 제어하기가 쉽지 않다는 것입니다.

  데이터 삭제를 위한 New Relic 규칙은 볼륨이 너무 높은 스트리밍 메트릭을 필터링하는 기본 방법입니다. 그러나 스트림 볼륨을 제한하는 데 도움이 되도록 클라우드 공급자 측에서 수행할 수 있는 몇 가지 작업이 있습니다.

  예를 들어 AWS에서는 조건 키를 사용하여 CloudWatch* 네임스페이스에 대한 액세스를 제한 할 수 있습니다.

  다음 정책은 사용자가 MyCustomNamespace 이라는 네임스페이스에서만 측정항목을 게시하도록 제한합니다.

  {
    "Version": "2012-10-17",
    "Statement": {
      "Effect": "Allow",
      "Resource": "*",
      "Action": "cloudwatch:PutMetricData",
      "Condition": {
        "StringEquals": {
          "cloudwatch:namespace": "MyCustomNamespace"
        }
      }
    }
  }

  카피

  다음 정책은 사용자가 CustomNamespace2 을(를) 제외한 모든 네임스페이스에 측정항목을 게시하도록 허용합니다.

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Resource": "*",
        "Action": "cloudwatch:PutMetricData"
      },
      {
        "Effect": "Deny",
        "Resource": "*",
        "Action": "cloudwatch:PutMetricData",
        "Condition": {
          "StringEquals": {
            "cloudwatch:namespace": "CustomNamespace2"
          }
        }
      }
    ]
  }

  카피

모든 New Relic 드롭 규칙은 동일한 백엔드 데이터 모델 및 API에 의해 구현됩니다. 로그 관리는 삭제 규칙을 매우 쉽게 생성하고 모니터링할 수 있는 강력한 UI를 제공합니다.

이 자습서 시리즈의 이전 부분에서는 특정 데이터를 사용하지 않을 수 있는 방법을 보여주기 위해 몇 가지 연습을 통해 원격 분석의 우선 순위를 지정하는 방법을 다루었습니다. 이 예를 다시 살펴보겠습니다.

Omit debug logs (knowing they can be turned on if there is an issue) (saves 5%)

방법 1: UI 로그

• 로그 UI에서 필터를 사용하여 관심 있는 로그를 식별합니다. level: DEBUG .

• 삭제하려는 로그를 찾는지 확인합니다.

• level:debug 및 log_level:Debug 과 같은 일부 대체 구문을 확인하십시오. 이러한 변형은 일반적입니다.

• Manage data

  아래에서

  Drop filters

  클릭하고 '디버그 로그 삭제'라는 필터를 생성하고 활성화합니다.

• 규칙이 작동하는지 확인합니다.

방법 2: NerdGraph API

• 관련 NRQL 쿼리를 만듭니다.

  SELECT count(*) FROM Log WHERE `level` = 'DEBUG'

  카피

• 삭제하려는 로그를 찾는지 확인하십시오.

• 속성 이름 및 값의 변형을 확인하십시오( Debug 대 DEBUG ).

• 다음 NerdGraph 문을 실행하고 작동하는지 확인하십시오.

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_DATA
        nrql: "SELECT * FROM Log WHERE `level` = 'DEBUG'"
        description: "Drops DEBUG logs.  Disable if needed for troubleshooting."
      }
    ]
  ) {
    successes {
      id
    }
    failures {
      submitted {
        nrql
      }
      error {
        reason
        description
      }
    }
  }
}

권장 사항을 구현해 보겠습니다. Drop process sample data in DEV environments .

• 관련 쿼리를 만듭니다.

  SELECT * FROM ProcessSample WHERE `env` = 'DEV'

  카피

• 삭제하려는 프로세스 샘플을 찾는지 확인하십시오.

• ENV 및 Environment 와 같은 env 의 다른 변형을 확인합니다.

• Dev 및 Development 와 같은 다양한 DEV 를 확인합니다.

• NerdGraph API를 사용하여 다음 명령문을 실행하고 작동하는지 확인하십시오.

  mutation {
    nrqlDropRulesCreate(
      accountId: YOUR_ACCOUNT_ID
      rules: [
        {
          action: DROP_DATA
          nrql: "SELECT * FROM ProcessSample WHERE `env` = 'DEV'"
          description: "Drops ProcessSample from development environments"
        }
      ]
    ) {
      successes {
        id
      }
      failures {
        submitted {
          nrql
        }
        error {
          reason
          description
        }
      }
    }
  }

  카피

중복 적용 범위로 데이터를 줄임으로써 데이터 사용량을 줄일 수 있습니다. 예를 들어 nri-mysql 또는 nri-postgresql 와 같은 SQL 데이터베이스를 모니터링하는 New Relic 온호스트 통합 중 하나뿐만 아니라 AWS RDS 통합이 실행 중인 환경에서 일부 중복 측정항목을 삭제할 수 있습니다.

예를 들어 다음과 같은 쿼리를 실행할 수 있습니다.

FROM Metric select count(*) where metricName like 'aws.rds%' facet metricName limit max

그러면 패턴과 일치하는 모든 metricName 값이 표시됩니다.

결과에서 aws.rds.cpu% 패턴의 많은 양의 메트릭이 있음을 알 수 있습니다. 다음과 같은 다른 도구가 있으므로 삭제할 수 있습니다.

• 관련 쿼리를 만듭니다.

  FROM Metric select * where metricName like 'aws.rds.cpu%' facet metricName limit max since 1 day ago

  카피

• 삭제하려는 프로세스 샘플을 찾는지 확인하십시오.

• NerdGraph API를 사용하여 다음 명령문을 실행하고 작동하는지 확인하십시오.

  mutation {
    nrqlDropRulesCreate(
      accountId: YOUR_ACCOUNT_ID
      rules: [
        {
          action: DROP_DATA
          nrql: "FROM Metric select * where metricName like 'aws.rds.cpu%' facet metricName limit max since 1 day ago"
          description: "Drops rds cpu related metrics"
        }
      ]
    ) {
      successes {
        id
      }
      failures {
        submitted {
          nrql
        }
        error {
          reason
          description
        }
      }
    }
  }

  카피

삭제 규칙에 대한 한 가지 중요한 점은 특정 속성을 삭제하지만 나머지 데이터의 무결성을 유지하는 규칙을 구성할 수 있다는 것입니다. 이를 사용하여 NRDB에서 개인 데이터를 제거하거나 지나치게 큰 로그 레코드에서 스택 추적 또는 JSON의 큰 청크와 같은 지나치게 큰 속성을 삭제합니다.

이러한 삭제 규칙을 설정하려면 action 필드를 { DROP_DATA DROP_ATTRIBUTES 로 변경합니다.

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_ATTRIBUTES
        nrql: "SELECT stack_trace, json_data FROM Log where appName='myApp'"
        description: "Drops large fields from logs for myApp"
      }
    ]
  ) {
    successes {
      id
    }
    failures {
      submitted {
        nrql
      }
      error {
        reason
        description
      }
    }
  }
}

이 예에서는 특정 트레이스 ID의 상대적 분포를 활용하여 대략적인 무작위 샘플링을 할 수 있습니다. rlike 연산자를 사용하여 스팬 trace.id 속성의 선행 값을 확인할 수 있습니다. 다음 예는 범위의 약 25%를 삭제할 수 있습니다.

SELECT * FROM Span WHERE trace.id rlike r'.*[0-3]' and appName = 'myApp'

유용한 표현은 다음과 같습니다.

• r'.*0' 약 6.25%

• r'.*[0-1]' 약 12.5%

• r'.*[0-2]' 약 18.75%

• r'.*[0-3]' 약 25.0%

  숫자가 부족하면 문자를 사용할 수 있습니다. 예를 들면 다음과 같습니다.

• r'.*[a0-9]' 약 68.75%

• r'.*[a-b0-9]' 약 75.0%

  다음은 전체 돌연변이의 예입니다.

  mutation {
    nrqlDropRulesCreate(
      accountId: YOUR_ACCOUNT_ID
      rules: [
        {
          action: DROP_DATA
          nrql: "SELECT * FROM Span WHERE trace.id rlike r'.*[0-3]' and appName = 'myApp'"
          description: "Drops approximately 25% of spans for myApp"
        }
      ]
    ) {
      successes {
        id
      }
      failures {
        submitted {
          nrql
        }
        error {
          reason
          description
        }
      }
    }
  }

  카피

  팁

  trace.id은 16진수이므로 trace.id 의 모든 문자는 0123456789abcdef 값입니다. RLIKE 패턴에 추가하는 각 문자는 최종 문자가 균일하게 분포되어 있다고 가정할 때 범위 이벤트 행의 추가 1/16과 일치합니다. 16진수에 사용되지 않는 F 이외의 문자를 추가하는 경우 추가된 숫자는 일치율에 영향을 미치지 않습니다.

앞의 예는 NRDB의 다른 이벤트 또는 지표에서 이러한 기술을 사용하기 위해 알아야 할 모든 것을 보여줍니다. 기억하세요: 쿼리할 수 있으면 삭제할 수 있습니다. 삭제 규칙에 대한 쿼리를 구성하는 정확한 방법에 대해 질문이 있는 경우 당사에 문의하십시오.