eBPF 에이전트 모범 사례 가이드

뉴렐릭 eBPF 에이전트는 eBPF 기술을 사용하여 코드 측정이 필요 없는 단일 에이전트에서 APM 기능을 제공합니다. 이 접근 방식은 모델링 구현, 배포를 위해 팀과 협력할 필요성을 제거함으로써 플랫폼 엔지니어링 팀의 역량을 강화합니다.

eBPF APM은 언제 사용해야 할까요?

• 대규모 구현, 배포: 대규모로 구현하고 배포해야 하며 개별 언어 에이전트의 오버헤드 없이 "충분히 좋은" 지표를 요구하는 많은 기능을 구현하는 경우.
• 알 수 없거나 수정 불가능한 워크로드: 모니터링하려는 로드가 알 수 없는 프로그래밍 언어로 작성되었거나 수정할 수 없는 경우.
• 플랫폼 엔지니어링 효율성: 개별 팀과의 조율 없이 규모에 맞게 구현하고, 배포하고 모니터링하려는 경우.
• Linux 중심 환경: eBPF가 Kubernetes와 호스트 환경 모두에서 Linux에서 훌륭하게 작동하므로 Windows 플랫폼을 모니터링할 필요가 없는 경우입니다.
• 분산 추적 요구 사항 없음: 모니터링 요구 사항에 분산 추적 기능이 필요하지 않은 경우입니다.

eBPF 대 기존 APM 비교

eBPF APM과 기존 APM 에이전트의 차이점을 이해하면 올바른 접근 방식을 선택하는 데 도움이 됩니다.

데이터 소스 관점

eBPF APM은 모니터링 관점을 애플리케이션 계층에서 커널 계층으로 전환합니다.

구현, 배포에 대한 모범 사례

전통적인 APM 보완

포괄적인 적용 범위를 위해 eBPF 에이전트를 사용하여 APM 언어 에이전트를 보완하세요. 이를 통해 이중 데이터 수집 없이 eBPF APM과 APM 에이전트 간의 공존을 통해 완벽한 APM 적용 범위를 확보할 수 있습니다.

권장 접근 방식:

• APM 언어 에이전트: 심층적인 인사이트, 반전 추적 또는 맞춤형 측정이 필요한 가장 중요한 기능에 사용합니다.
• eBPF APM: 계측되지 않은 서비스, 타사 앱을 포함한 모든 기타 서비스에 적용하며, 새로운 서비스를 지속적으로 검색/보고하는 데 사용합니다.

더 심층적인 컨텍스트를 위한 네트워크 메트릭 추가

eBPF 에이전트는 애플리케이션 경계를 넘어 네트워크 상태를 파악할 수 있도록 세부적인 네트워크 메트릭(TCP, DNS 등)도 제공할 수 있습니다. 이 기능은 보완적인 기능이며 eBPF APM과 함께 또는 단독으로 사용할 수 있습니다. 더 자세한 내용은 네트워크 메트릭스를 참조하십시오.

다음 구현, 배포 옵션을 사용할 수 있습니다.

완전한 MELT를 위한 로그 수집을 추가합니다.

eBPF 에이전트는 또한 별도의 로그 전달자를 배포하지 않고도 기본적으로 애플리케이션 로그를 수집하고 뉴렐릭 메타데이터로 보강할 수 있습니다. 이 기능은 동일한 에이전트에서 실행되므로 추가로 배포할 필요 없이 eBPF APM 및 네트워크 메트릭과 함께 활성화할 수 있습니다. 자세한 내용은 eBPF 로그를 참조하십시오.

중복 로그 수집을 자동으로 방지하려면 reportLogs: "auto" 을(를) 사용하십시오: eBPF 에이전트는 APM 에이전트가 자체적으로 로그를 활발히 수집하는 경우에만 해당 APM 에이전트에서 백오프하며, OpenTelemetry 에이전트가 연결될 때마다 완전히 백오프합니다. 해당 엔티티에 대해 로그를 보고하는 다른 에이전트가 없음을 확인한 경우에만 "true" 을(를) 사용하십시오.

구현 권장 사항

• 확장을 위해 eBPF APM 으로 시작: 많은 디자인에 걸쳐 대규모로 구현, 배포하다 모니터링이 필요하고 복잡한 조정 없이 "충분히 좋은" 지표를 원한다면 eBPF APM 으로 시작하세요.

• 완전한 가시성을 위해 네트워크 지표 추가: eBPF APM 이 구현, 배포되면 eBPF 네트워크 지표를 추가하여 포괄적인 문제 해결, 처리 기능에 대한 경계를 넘어 가시성을 확보하는 것을 고려하세요.

• 통합 문제 해결을 위한 로그 수집 추가: 준비가 되면 eBPF 로그를 켜서 별도의 로그 전달자를 배포하지 않고 애플리케이션 로그를 수집하십시오.

데이터 샘플링 및 미세 조정

APM 언어 에이전트는 고정된 저장소를 사용하여 트랜잭션 이벤트 를 제한하며, 기본값은 분당 10,000개의 이벤트 입니다(transaction_events.max_samples_stored(으)로 구성됨). eBPF 에이전트는 단일 고정 분당 한도를 사용하지 않습니다. 대신 각 텔레메트리 유형을 다르게 샘플링하므로, 각 유형이 어떻게 작동하는지 이해하면 중요한 신호를 잃지 않고 데이터 볼륨과 비용을 제어하는 데 도움이 됩니다.

스팬 샘플링 작동 방식

eBPF 에이전트는 스팬을 분당 고정된 수로 제한하지 않습니다. 각 프로토콜에 대해 사용자가 설정한 임계값을 초과하는 스팬만 내보냅니다:

• 지연시간 임계값 (samplingLatency): 주어진 경로에 대해 선택한 백분위수보다 느린 스팬을 내보냅니다. 기본값은 p50 (중앙값)입니다. 가장 느린 꼬리 부분만 유지하고 데이터 볼륨을 줄이려면 p90 또는 p99 에 가깝게 높이고, 거의 모든 스팬을 유지하고 가시성을 높이려면 p1 또는 p0 에 가깝게 낮추십시오. p0 에서 p99 사이의 모든 백분위수가 허용됩니다.
• 오류율 임계값 (samplingErrorRate, HTTP): 1 에서 100 사이의 값입니다. 경로의 오류율이 이 임계값을 초과하면 실패가 샘플링에서 누락되지 않도록 해당 경로의 스팬이 내보내집니다. 오류 기반 내보내기를 비활성화하려면 비워 두십시오.

연결되지 않은 스팬 제어

에이전트가 캡처하지만 상위 항목과 연결할 수 없는 스팬을 연결되지 않은 스팬이라고 합니다. 이들은 max_unlinked_spans 에 의해 프로토콜당 제한됩니다(기본값 100, 제한을 비활성화하려면 0 로 설정하십시오). unlinked_spans_error_quota_percentage 설정(기본값 30)은 해당 예산의 일부를 오류 스팬을 위해 예약하므로, 정상 스팬이 먼저 도착하더라도 실패가 계속 표시됩니다.

튜닝 예시

샘플링은 Helm values.yaml 파일(Kubernetes) 또는 /etc/newrelic-ebpf-agent/newrelic-ebpf-agent.yaml (Linux 호스트)에서 구성됩니다. 두 경우 모두 키는 동일합니다.

protocols:
  global:
    max_unlinked_spans: 100          # 0 disables the cap
    unlinked_spans_error_quota_percentage: 30
  http:
    enabled: true
    spans:
      enabled: true
      samplingLatency: "p90"         # keep only slower requests, less data
      samplingErrorRate: "5"         # always keep routes with >5% errors
logDataFilters:
  applicationLogReporting:
    maxSamplesPerMinute: 10000         # APM-equivalent reservoir for logs

권장 사항

• 트레이스 가시성을 극대화하려면: samplingLatency 을(를) p0 에 가깝게 낮추고 samplingErrorRate을(를) 낮게 설정하되, 수집량이 증가할 것을 예상하십시오.
• 데이터를 줄이려면: samplingLatency (예: p90 또는 p99)을(를) 높이고, 원치 않는 프로토콜을 모두 비활성화(또는 프로토콜 메트릭만 유지하려면 spans.enabled: false 만 비활성화)하며, 로그에 대해 maxSamplesPerMinute 을(를) 낮추십시오.
• 메트릭을 염두에 두십시오: 메트릭은 스팬 샘플링의 영향을 받지 않습니다. 해당 데이터가 전혀 필요하지 않은 경우에만 전체 프로토콜을 비활성화하십시오.

관련 기사