파이프라인 취소 게이트웨이는 대시보드에서 실행되는 OpenTelemetry기반 데이터 처리 파이프라인입니다. 이는 델메트리 데이터를 뉴렐릭으로 보내기 전에 처리하여 데이터 비용, 신호 품질 및 데이터 관리를 제어할 수 있습니다.
파이프라인 제어 게이트웨이는 어떤 문제를 해결합니까?
조직은 데이터 처리 방식에 대한 가시성과 세부적인 제어 부족으로 인해 시끄럽고 관련성이 떨어지는 텔레메트리 데이터에 압도당하고 있습니다. 이로 인해 의미 있는 인사이트를 찾고 데이터를 효과적으로 관리하기가 어려워지며 비용이 증가하고 운영 효율성이 떨어집니다.
잡음이 섞인 데이터를 필터링합니다.
문제: 디버그 로그, 테스트 환경 데이터 및 상태 점검으로 인해 시스템에 불필요한 정보가 넘쳐나 중요한 문제를 찾기가 어렵습니다.
게이트웨이를 사용한 솔루션:
- 운영 환경에서 모든 DEBUG 로그를 필터링합니다.
- 네트워크에서 벗어나기 전에 테스트 환경에서 모든 텔레메트리를 삭제하세요.
- 매일 수백만 개의 항목을 생성하는 상태 점검 로그를 삭제합니다.
- 로그 레벨, 환경, 서비스 이름 또는 기타 속성으로 필터링
결과: 신호 대 잡음비가 향상되어 중요한 이상 징후와 추세를 더 쉽게 파악할 수 있습니다.
데이터 수집 비용 절감
문제: 귀하의 옵저빌리버티 청구액은 $80,000/월이며, 70%는 일상적인 로그인 수집에서 발생합니다. 대량의 저가치 데이터는 인사이트를 제공하지 않고 비용만 증가시킵니다.
게이트웨이를 사용한 솔루션:
- INFO 로그의 95%만 샘플링하고 ERROR 및 WARN 로그는 100% 유지합니다.
- 비용을 지불하지 않는 사용자에 대한 사용자별 지표 삭제(사용자 기반의 80%)
- 출처에서 중복되거나 불필요한 텔레메트리를 필터링합니다.
- 비즈니스 가치를 기준으로 세부적인 수준까지 데이터를 관리하세요.
결과: 데이터 용량을 85% 줄여 월 요금을 8만 달러에서 1만 2천 달러로 절감하면서도 모든 핵심 데이터는 그대로 유지할 수 있습니다.
맥락을 추가하고 데이터를 풍부하게 만드세요
문제: 마이크로서비스들이 서로 다른 로깅 프레임워크를 사용하고 있습니다. 서비스 A 로그인 level=ERROR, 서비스 B 로그인 severity=error, 서비스 C 로그인 log_level=3. 통합 대시보드나 알림을 생성할 수 없습니다.
게이트웨이를 사용한 솔루션:
- 속성 이름 정규화: 모든 변형을 다음으로 변환합니다.
severity.text=ERROR - 조직 데이터 추가:
team,cost_center,region모든 텔레메트리에 - 비즈니스 컨텍스트를 추가하여 내용을 보강하세요: 결제 엔드포인트에
business_criticality=HIGH추가하세요 - 환경 이름 표준화:
env,environment,deploy_env→deployment.environment
결과: 하나의 쿼리로 모든 서비스를 이용할 수 있습니다. 통합 대시보드는 코드 변경 없이 정확한 교차 서비스 지표를 표시합니다.
누가 이 기능을 사용해야 할까요?
다음과 같은 경우 파이프라인 위험 게이트웨이가 유용할 것입니다.
- 시끄럽고 관련 없는 텔레메트리 데이터에 압도당함
- 데이터 수집 비용을 줄여야 합니다.
- 신호 대 잡음비를 개선하여 중요한 문제를 더 빨리 찾아내고 싶으신가요?
- 텔레메트리 데이터에 조직적 맥락을 추가해야 함
- 쿼리 효율성을 높이기 위해 비정형 로그 데이터를 정형화하고 싶습니다.
- 데이터 개인정보 보호 규정을 준수해야 합니다.
- 네트워크를 통해 전송되는 데이터를 제어하고 싶으신가요?
핵심 개념
텔레메트리 유형
게이트웨이는 4가지 텔레메트리 유형을 독립적으로 처리합니다.
- 지표: 수치적 측정(CPU 사용량, 요청률, 메모리 소비)
- 이벤트: 개별 발생(구현, 배포, 사용자 가입, 오류)
- 로그: 애플리케이션 활동에 대한 텍스트 기반 기록
- 트레이스: 마이크로서비스(개별 범위)에 분산된 요청 흐름
각 유형은 자체 프로세서를 갖춘 별도의 파이프라인을 통해 처리됩니다.
프로세서
프로세서는 파이프라인의 구성 요소입니다. 각 프로세서 유형은 특정 목적을 수행합니다.
팁
게이트웨이 프로세서는 변환문과 부울 조건을 작성하기 위해 OTTL(OpenTelemetry Transformation Language)을 사용합니다. OTTL은 풍부한 기능 세트를 갖춘 강력한 공급업체 비종속 언어입니다. 자세한 내용은 OpenTelemetry OTTL 문서를 참조하십시오.
변환 프로세서는 OTTL을 사용하여 데이터를 수정합니다.
- 속성을 추가, 업데이트 또는 삭제합니다.
- 정규 표현식 패턴을 사용하여 문자열을 파싱합니다.
- 기존 데이터에서 새로운 필드를 도출합니다.
- 높은 카디널리티 속성을 해시합니다.
- 예시 함수:
set(),replace_pattern(),delete_key()Hash()
필터 프로세서는 OTTL 부울 표현식을 사용하여 데이터를 삭제합니다.
- 조건에 맞는 모든 레코드를 삭제합니다.
- 여러 조건을 조합하여 필터링합니다.
- 예시 표현:
attributes["http.url"] matches ".*health.*",duration < 100000000
샘플링 프로세서는 데이터 용량을 지능적으로 줄입니다.
- 기본 샘플링 비율을 설정합니다(예: 전체 데이터의 10% 샘플링).
- 조건부 규칙을 정의합니다(예: 오류는 100% 유지하고 성공은 5%만 샘플링).
- 속성 값 또는 패턴을 이용한 샘플링 제어
중요
속도 샘플링은 로그 이벤트 및 트레이스에 대해 지원되지만 조건부 샘플링은 로그 이벤트에 대해서만 지원됩니다.
YAML 기반 설정
게이트웨이 설정은 선언적 구조의 YAML 파일을 사용합니다.
version: 2.0.0autoscaling: minReplicas: 6 maxReplicas: 10 targetCPUUtilizationPercentage: 60configuration: simplified/v1: troubleshooting: proxy: false requestTraceLogs: false steps: receivelogs: description: Receive logs from OTLP and New Relic proprietary sources output: - probabilistic_sampler/Logs receivemetrics: description: Receive metrics from OTLP and New Relic proprietary sources output: - filter/Metrics receivetraces: description: Receive traces from OTLP and New Relic proprietary sources output: - probabilistic_sampler/Traces probabilistic_sampler/Logs: description: Probabilistic sampling for all logs output: - filter/Logs config: global_sampling_percentage: 100 conditionalSamplingRules: - name: sample the log records for ruby test service description: sample the log records for ruby test service with 70% sampling_percentage: 70 source_of_randomness: trace.id condition: resource.attributes["service.name"] == "ruby-test-service" probabilistic_sampler/Traces: description: Probabilistic sampling for traces output: - filter/Traces config: global_sampling_percentage: 80 filter/Logs: description: Apply drop rules and data processing for logs output: - transform/Logs config: error_mode: ignore logs: rules: - name: drop the log records description: drop all records which has severity text INFO value: log.severity_text == "INFO" filter/Metrics: description: Apply drop rules and data processing for metrics output: - transform/Metrics config: error_mode: ignore metric: rules: - name: drop entire metrics description: delete the metric on basis of humidity_level_metric value: (name == "humidity_level_metric" and IsMatch(resource.attributes["process_group_id"], "pcg_.*")) datapoint: rules: - name: drop datapoint description: drop datapoint on the basis of unit value: (attributes["unit"] == "Fahrenheit" and (IsMatch(attributes["process_group_id"], "pcg_.*") or IsMatch(resource.attributes["process_group_id"], "pcg_.*"))) filter/Traces: description: Apply drop rules and data processing for traces output: - transform/Traces config: error_mode: ignore span: rules: - name: delete spans description: deleting the span for a specified host value: (attributes["host"] == "host123.example.com" and (IsMatch(attributes["control_group_id"], "pcg_.*") or IsMatch(resource.attributes["control_group_id"], "pcg_.*"))) span_event: rules: - name: Drop all the traces span event description: Drop all the traces span event with name debug event value: name == "debug_event" transform/Logs: description: Transform and process logs output: - nrexporter/newrelic config: log_statements: - context: log name: add new field to attribute description: for otlp-test-service application add newrelic source type field conditions: - resource.attributes["service.name"] == "otlp-java-test-service" statements: - set(resource.attributes["source.type"],"otlp") transform/Metrics: description: Transform and process metrics output: - nrexporter/newrelic config: metric_statements: - context: metric name: adding a new attributes description: 'adding a new field into a attributes ' conditions: - resource.attributes["service.name"] == "payments-api" statements: - set(resource.attributes["application.name"], "compute-application") transform/Traces: description: Transform and process traces output: - nrexporter/newrelic config: trace_statements: - context: span name: remove the attribute description: remove the attribute when service name is payment-service conditions: - resource.attributes["service.name"] == "payment-service" statements: - delete_key(resource.attributes, "service.version") nrexporter/newrelic: description: Export to New Relic주요 특징:
- 버전 선언: version:
2.0.0설정 스키마를 지정합니다. - 단계 이름 지정: 형식은 프로세서 유형/텔레메트리 유형입니다(예:
transform/Logs,filter/Metrics). - 출력 변경: 각 단계는 출력 대상, 목표 등을 선언하여 처리 파이프라인을 생성합니다.
Pipeline 흐름
게이트웨이는 지표, 이벤트 및 로그, 트레이스라는 세 가지 독립적인 파이프라인으로 데이터를 구성합니다. 이러한 격리는 예를 들어 대량의 로그가 중요한 성능 전송의 처리 또는 전달을 방해하지 않도록 보장합니다.
각 파이프라인은 세 가지 기능 단계로 구성됩니다.
- 수신기(입력)는 데이터의 진입점입니다. 게이트웨이는 다음으로부터 들어오는 텔레메트리를 자동으로 수신합니다:
OpenTelemetry(OTLP): OTel SDK 및 수집기의 표준 데이터입니다.
뉴렐릭 에이전트: 독점 텔레메트리 에이전트.
- 프로세서(논리 및 변환)는 사용자 지정 규칙이 적용되는 부분입니다. 데이터 처리 방식은 세 가지 주요 프로세서 유형을 사용하여 정의합니다.
예시: 확률적 또는 조건부 샘플링을 통해 볼륨을 줄입니다.
필터: 조건에 따라 특정 레코드 또는 속성을 제외합니다.
변환: OpenTelemetry Transformation Language(OTTL)를 사용하여 로그를 구문 분석하고, 속성 이름을 변경하거나, 메타데이터로 데이터를 보강할 수 있습니다.
- 수출업체(이그레스)는 데이터가 처리, 필터링 및 샘플링되면 남은 고가치 텔레메트리를 뉴렐릭 cloud 로 안전하게 전송합니다.
YAML에서 파이프라인을 정의할 때 프로세서를 특정 텔레메트리 유형에 매핑해야 합니다. 설정을 체계적으로 관리하기 위해 표준 명명 패턴인 processor_type/telemetry_type 을 사용합니다.
예:
변환/로그: 로그 데이터에만 변환 로직을 적용합니다.
필터/메트릭: 메트릭에 대한 삭제 규칙을 구체적으로 적용합니다.
sampling/트레이스: 일간 트레이스의 물량을 관리합니다.
메모:
- cloud 규칙(계정별 적용)과 달리 게이트웨이 규칙은 조직 전체에 적용됩니다.
- 프로세서는 이름에 명시된 텔레메트리 유형에만 영향을 미칩니다. 필터/로그 규칙은 실수로 지표나 트레이스를 삭제하지 않습니다.
구성 방법
UI기반 설정
게이트웨이 UI는 YAML을 작성하지 않고도 규칙을 생성할 수 있는 폼 기반 인터페이스를 제공합니다.
- 변환 규칙: 안내형 OTTL 문 작성기를 사용하여 속성을 추가/수정합니다.
- 삭제 규칙: 조건 빌더를 사용하여 NRQL 기반 필터링 규칙을 생성합니다.
- 샘플링 비율 규칙: 슬라이더를 사용하여 전체 및 조건부 샘플링 비율을 설정합니다.
UI 백그라운드에서 YAML 설정을 생성하고 실시간 미리보기를 제공합니다. 자세한 지침은 UI 가이드를 참조하세요.
YAML 설정
고급 사용자 또는 코드형 워크플로우의 경우 YAML 설정 파일을 직접 편집합니다.
- 프로세서 순서 및 파이프라인 구조에 대한 완벽한 제어
- Git을 이용한 버전 관리
- 자동화된 구현, 연속 통합/연속 배포(CI/CD)를 통한 배포
- UI에 노출되지 않은 고급 OTTL 기능에 접근할 수 있습니다.
설정 참조는 YAML 개요를 참조하세요.
설정 구현, 배포
게이트웨이는 통합 설정 모델을 사용합니다.
- 모든 처리 단계를 정의하는 YAML 설정 파일을 생성합니다.
- UI 통해 클러스터에 구현하다, 배포하다 (YAML 업로드)
- 게이트웨이는 조직의 모든 게이트웨이에 설정을 적용합니다.
- 모든 클러스터는 동일한 규칙을 사용하여 동일한 방식으로 데이터를 처리합니다.
버전 관리:
- 설정 변경이 있을 때마다 새 버전이 생성됩니다.
- 버전 기록을 확인하고 필요한 경우 이전 버전으로 되돌릴 수 있습니다.
- "필요 구현, 배포" 배지에 보류 중인 변경 사항이 표시됩니다.
다음 단계
당신의 길을 선택하세요:
- 시각적 설정: 게이트웨이 UI사용
- YAML 설정: YAML 구조 학습
또는 특정 프로세서 유형을 자세히 살펴보세요.