데이터 수집 최적화

계정이 예산보다 약 20% 더 많이 수집하고 있습니다. 그들은 소비를 줄이는 방법을 찾도록 관리자로부터 요청을 받았습니다. 가장 중요한 가치 동인은 가동 시간, 성능 및 안정성 입니다.

그들의 재산에는 다음이 포함됩니다.

• APM(개발, 스테이징, 프로덕션)

• 분산 추적

• 브라우저

• 100개 호스트의 인프라 모니터링

• K8s 모니터링(개발, 스테이징, 프로덕션)

• 로그(dev, staging, prod - 디버그 포함)

  최적화 계획

  • 디버그 로그 생략(문제가 있는 경우 켤 수 있음)(5% 절약)
  • Kubernetes 클러스터 탐색기를 표시하는 데 필요하지 않은 여러 K8 상태 메트릭 생략(10% 절약)
  • 새로운 기능에 대한 많은 A/B 테스트를 수행할 때 수집했던 일부 사용자 정의 브라우저 이벤트를 삭제합니다(10% 절약).

  이러한 변경 사항을 실행한 후 팀은 예산보다 5% 낮고 NPM 파일럿을 수행할 공간을 확보했습니다. 그들의 관리자는 상당한 가동 시간과 안정성 관찰 가능성을 잃지 않고 있는 것에 만족합니다.

  최종 결과

  • 원래 예산보다 5%
  • 가동 시간, 성능 및 안정성 목표를 제공하는 NPM 파일럿을 위해 생성된 헤드룸
  • 가동 시간 및 신뢰성 관찰 가능성의 손실 최소화

모바일 모니터링 및 브라우저 모니터링에 중점을 둔 새로운 사용자 대면 플랫폼을 담당하는 팀이 예산보다 50% 초과 운영되고 있습니다. 수집 규모를 적절하게 조정해야 하지만 고객 경험 관찰 가능성을 희생하지 않는 것에 대해 단호합니다.

그들의 재산에는 다음이 포함됩니다.

• 이동하는

• 브라우저

• APM

• 분산 추적

• 프로세스 샘플을 포함한 30개 호스트의 인프라

• 일부 백엔드 비동기 프로세스에 대한 서버리스 모니터링

• 서버리스 기능의 로그

• 다양한 클라우드 통합

  최적화 계획

  • 서버리스 로그 생략(기본적으로 Lambda 통합에서 얻는 것과 중복됨)
  • 호스트의 프로세스 샘플 속도를 1분마다 감소
  • DEV 환경에서 프로세스 샘플 데이터 삭제
  • New Relic 인프라 에이전트에서 제공하는 다른 인프라 모니터링과 고도로 중복되는 EC2 통합을 끕니다.

  최종 결과

  • 원래 예산의 5%
  • 성수기를 통과하기에 충분합니다.
  • 고객 경험 관찰 가능성 손실 없음

  변경 사항을 실행한 후 이제 원래 예산의 5%에 불과하지만 성수기까지 이를 수행하기에 충분할 것이라고 결론지었습니다.

한 팀이 대규모 Python 모놀리스를 4개의 마이크로서비스로 리팩토링하는 과정에 있습니다. 모놀리스는 고객 데이터베이스 및 캐시 계층을 포함한 새로운 아키텍처와 많은 인프라를 공유합니다. 예산이 70% 초과되었으며 공식적으로 모노리스를 폐기하려면 2개월이 소요됩니다.

그들의 재산에는 다음이 포함됩니다.

• K8s 모니터링(마이크로서비스)

• New Relic 호스트 모니터링(모놀리스)

• APM(마이크로서비스 및 호스트 모니터링)

• 분산 추적(마이크로서비스 및 호스트 모니터링)

• PostgreSQL(공유)

• Redis(공유)

• MSSQL(마이크로서비스 아키텍처용 미래 DB)

• 로드 밸런서 로깅(마이크로서비스 및 호스트 모니터링)

  최적화 계획

  • 5xx 응답 코드만 모니터링하도록 로드 밸런서 로깅 구성(모노리스)
  • 모놀리스를 실행하는 호스트에 대한 ProcessSample , StorageSample 및 NetworkSample - 60초의 맞춤 샘플 속도
  • 현재 새 아키텍처에서 사용하지 않으므로 MSSQL 모니터링을 비활성화합니다.
  • 모놀리스에 대한 분산 추적은 마이크로서비스 아키텍처에 비해 훨씬 덜 유용하므로 비활성화합니다.

  최종 결과

  • 원래 예산보다 1%
  • 혁신 및 성장 관찰 가능성 손실 없음

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 인스턴스의 매우 가변적인 측면 중 하나는 데이터베이스 호출 수와 설정한 구성입니다. 우리는 장황한 데이터베이스 쿼리 모니터링의 정도에 대해 상당한 양의 제어 권한을 가지고 있습니다. 이러한 쿼리는 트랜잭션 추적 페이지에 표시됩니다.

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

• 난독화하거나 쿼리 수집을 끄는 대신 원시 쿼리 데이터 수집

• 스택 추적 임계값 변경

• 쿼리 설명 계획 수집 켜기

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

  이벤트 제한 설정

  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 코드 및 오류 클래스를 포함한 오류 수집

• 느린 쿼리 추적

• 스레드 프로파일러

  분산 추적

  분산 추적 구성에는 언어별로 몇 가지 차이점이 있습니다.

  필요에 따라 분산 추적을 비활성화할 수 있습니다. 다음은 자바 에이전트 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 으로 이동, 브라우저를 클릭합니다.

2. 앱을 선택하세요.

3. 왼쪽 탐색 메뉴에서 앱 설정 을 클릭합니다.

4. Ajax 요청 거부 목록 아래에서 적용하려는 필터를 추가합니다.

5. 애플리케이션 설정 저장 을 선택하여 에이전트 구성을 업데이트합니다.

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());

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

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

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

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

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

구성 가능한 샘플링 속도

인프라에서 구성할 수 있는 샘플링 속도는 여러 가지가 있지만 가장 일반적으로 사용되는 샘플링 속도입니다.

| 반응, 반응 | 기본값 | 비활성화 | | -------------- | ------- | ------- | | metrics_storage_sample_rate | 5 | -1 | | metrics_process_sample_rate | 20 | -1 | | metrics_network_sample_rate | 10 | -1 | | metrics_system_sample_rate | 5 | -1 | | metrics_nfs_sample_rate | 5 | -1 |

공정 샘플

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

enable_process_metrics: true

이는 metrics_process_sample_rate 을 -1 로 설정하는 것과 동일한 효과를 가집니다.

기본적으로 메모리가 부족한 프로세스는 샘플링에서 제외됩니다. 자세한 내용은 disable-zero-mem-process-filter 을(를) 참조하십시오.

메트릭 속성 값을 기반으로 메트릭 데이터 전송을 제한할 수 있는 include_matching_metrics 을 구성하여 New Relic으로 전송되는 데이터의 양을 제어할 수 있습니다.

메트릭 속성에 대한 리터럴 또는 부분 값을 정의하여 메트릭 데이터를 포함합니다. 예를 들어, 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"

exclude_matching_metrics 사용하면 메트릭 데이터를 제외하는 데에도 비슷하게 사용할 수 있습니다.

네트워크 인터페이스 필터

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

• {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 배포에서 관찰 가능성을 코드로 사용하는 경우 매우 간단합니다. K8 수집 감소에 대한 결정을 내리기 전에 이 Kubernetes 데이터 수집 분석 대시보드를 설치하는 것이 좋습니다. 이 대시보드를 얻으려면 인프라 통합 빠른 시작 을 참조하십시오.

긁는 간격

관찰 가능성 목표에 따라 스크래핑 간격 조정을 고려할 수 있습니다. 기본값은 15초입니다. 이제 Kubernetes 클러스터 탐색기가 45초마다 새로 고쳐집니다. K8 데이터의 주요 용도가 KCE 시각화를 지원하는 것이라면 스크래핑 간격을 20초로 변경하는 것을 고려할 수 있습니다. 15초에서 20초로의 변화는 상당한 영향을 미칠 수 있습니다. 이를 관리하는 방법에 대한 자세한 내용은 Helm 통합 스크랩 간격 문서 를 참조하세요.

네임스페이스 필터링

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

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

Kube 상태 측정항목

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

• 컨테이너 데이터
• 클러스터 데이터
• 노드 데이터
• 포드 데이터
• 볼륨 데이터
• API 서버 데이터 ¹
• 컨트롤러 관리자 데이터 ¹
• ETCD 데이터 ¹
• 스케줄러 데이터 ¹

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

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

• DaemonSet 데이터
• 배포 데이터
• 엔드포인트 데이터
• 네임스페이스 데이터
• 레플리카세트 데이터 ²
• 서비스 데이터
• 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: 사용자 지정 컬렉션 쿼리가 포함된 구성 파일

  샘플 구성:

  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 과 같은 매개변수를 알고 있어야 합니다. 모니터링 우선 순위를 사용하여 수집된 데이터를 간소화할 수 있는 영역입니다.

  METRIC 및 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: 선출된 마스터에서만 클러스터 메트릭을 수집합니다.

  METRICS 및 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에서 필터 구성

  대부분의 일반 전달자는 필터링 및 변환을 포함하는 상당히 완전한 라우팅 워크플로 를 제공합니다. New Relic의 인프라 에이전트는 원치 않는 로그를 필터링하기 위한 몇 가지 매우 간단한 패턴을 제공합니다. 레코드 필터링을 위한 정규식입니다. tail , systemd , syslog 및 tcp (형식이 없는 경우에만) 소스에 대해서만 지원됩니다. 이 필드는 Unix 시스템의 grep -E 와 유사한 방식으로 작동합니다. 예를 들어, 캡처 중인 특정 파일에 대해 다음을 사용하여 WARN 또는 ERROR 이 포함된 레코드를 필터링할 수 있습니다.

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

  카피

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

• config_file: 기존 Fluent Bit 구성 파일의 경로입니다. 중복되는 소스는 New Relic의 로그 관리에서 중복 메시지를 생성합니다.

• 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으로 보내기 위한 두 가지 기본 옵션을 제공합니다. 이 문서에서 메트릭 수집을 관리하기 위한 모범 사례는 주로 옵션 2인 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 Server를 실행하지 않는 고객에게 이상적입니다.

POMI: 긁힌 라벨

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

scrape_enabled_label 매개변수를 사용자 정의(예: newrelic/scrape )로 수정하고 데이터 수집이 가장 중요한 경우 Prometheus 끝점에 선택적으로 레이블을 지정하거나 주석을 추가하는 것이 좋습니다.

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

POMI 구성 매개변수:

# 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 구성에서 New Relic Kubernetes 통합이 Kube State Metrics 에서 이미 수집하고 있는 메트릭 하위 집합에 대한 메트릭 수집을 비활성화 하는 이와 유사한 섹션을 볼 수 있습니다.

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

POMI 구성 매개변수:

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)

CPU 및 메모리에 대한 리소스 요청은 POMI가 클러스터에서 충분한 리소스를 받을 수 있도록 적절한 값으로 설정해야 합니다. 이것을 매우 낮은 값(예: cpu: 50m)으로 설정하면 "시끄러운 이웃"이 클러스터 리소스를 사용할 수 있습니다.

POMI 구성 매개변수:

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 Server를 실행하고 있는 경우 POMI 또는 remote_write 를 활성화하기 전에 해당 서버에서 DPM 및 카디널리티 추정을 실행할 수 있습니다.

분당 데이터 포인트(DPM):

rate(prometheus_tsdb_head_samples_appended_total[10m]) * 60

상위 20개 측정항목(가장 높은 카디널리티):

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

일부 New Relic 클라우드 통합은 클라우드 제공업체의 API에서 데이터를 가져옵니다. 이 구현에서는 일반적으로 AWS CloudWatch, Azure Monitor 및 GCP Stackdriver와 같은 모니터링 API에서 데이터를 수집하고 특정 서비스의 API에서 인벤토리 메타데이터를 수집합니다.

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

폴링 API 기반 통합

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

• 폴링 빈도 변경

• 보고되는 데이터 변경

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

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

• 새 서비스 : 새 서비스 또는 구성을 배포하고 데이터를 더 자주 수집하려는 경우 폴링 빈도를 일시적으로 늘릴 수 있습니다.

  주의

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

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

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

  점점 더 많은 클라우드 통합에서 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로 구현됩니다. 그러나 New Relic 로그 관리는 드롭 규칙을 매우 쉽게 생성하고 모니터링할 수 있는 강력한 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 과 같은 일부 대체 구문을 확인하십시오. 이러한 변형은 일반적입니다.
• 데이터 관리 에서 필터 삭제 를 클릭하고 '디버그 로그 삭제'라는 필터를 만들고 활성화합니다.
• 규칙이 작동하는지 확인합니다.

방법 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 과 같은 env 의 다른 변형을 확인하고 Environment

• DEV Dev 및 Development

• 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
        }
      }
    }
  }

  카피

경우에 따라 중복 적용 범위가 있는 데이터를 절약할 수 있습니다. 예를 들어 AWS RDS 통합이 실행되고 있고 nri-mysql 또는 nri-postgresql 과 같은 SQL 데이터베이스를 모니터링하는 New Relic 온호스트 통합 중 하나가 있는 환경에서는 일부 중복 측정항목을 삭제할 수 있습니다.

빠른 탐색을 위해 다음과 같은 쿼리를 실행할 수 있습니다.

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%

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

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_ATTRIBUTES
        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
      }
    }
  }
}

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