추적 샘플링 추적

1) 관찰 가능한 이유

O11y (Observability) 는 무슨 일이 일어나고 있는지, 왜, 어떻게 고쳐야하는지에 대한 세 가지 질문에 4 가지 신호에 의존합니다

측정 항목 (집계, 빠르게 반응);

통나무 (세부 사항 및 법의학);

흔적 (교차 절단 원인-효과 관계);

프로필 (prod 모드에서 CPU/heap/lock 경합).

키: 신호 + 원격 측정 경제학 (샘플링, 보존, 압축) 간의 상관 관계.

2) 신호 맵 및 원리

2. 1 RED/USE

RED (API의 경우): RPS (Rate), 오류 (% 5xx/4xx 중요), 지속 시간 (p50/p95/p99).
사용 (리소스 용): 활용, 포화, 오류 (NIC, CPU, 디스크, 대기열).

2. 2 가지 제품 불변량

SLO를 정의하십시오 (예: "p95 대기 시간 '/v1/결제 ' 30 일 만에 5% "). SLO를 위반하거나 태울 때만 경고가 "비명을 지르십시오".

2. 3 맥락

W3C 추적 컨텍스트 ('traceparent', 'tracestate') 및 수하물을 구현하여 해당/비즈니스 속성 (예: '테넌트', '지역', PII 없음).

3) 관찰 가능성 아키텍처

SDK/자동 계측: 서비스에서의 OpenTelemetry (OTel) (잘/gRPC/DB/클라이언트).
버스로서의 OTel 수집가: 수신 → 농축 → 샘플링 → 수출 (Prometheus, Tempo/Jaeger, Loki/ELK, ClickHouse).

• 측정 항목: Prometheus/Mimir/VictoriaMetrics;
• 트레일: Tempo/Jaeger/Zipkin;
• 로그: Loki/ELK/Vector → S3 + deshevoye 스토리지;
• 프로필: Pyroscope/Parca.
• 상관 관계: 서비스 그래프, 예제, p99 그래프에서 특정 추적으로의 전환.

4) 추적 샘플링: 전략

4. 1 헤드 기반 샘플링

간단하고 저렴한 구현 (SDK/ingress).
단점: 드문 오류/느린 쿼리를 놓칠 수 있습니다.

언제: 높은 RPS, 엄격한 예산, 예측 가능한 점유율 (예: 1-5%) 이 필요합니다.

4. 테일 기반 샘플링 2 개

스팬이 끝난 후 수집기에서 결정합니다.
오류, p99, 특정 라우트/테넌트와 같은 변칙을 선택할 수 있습니다.
단점: 버퍼링, 단단하고 비싸다.

언제: "의미있는" 트레일이 적당한 비용으로 필요합니다.

4. 3 결합 모델

글로벌 헤드 1-5% 및 테일 규칙: "항상 오류/느린 스팬 저장", "카나리아 트래픽의 50% 샘플", "사고시 모든 지불 경로를 저장하십시오".

5) 동적 샘플링 및 원격 측정 예산

예산 인식: 볼륨 초과하면 임계 값을 올립니다 (예: p99 만 선택). 5 +, 오류 전용).
경로/테넌트 별 규칙: 중요한 엔드 포인트/테넌트-더 큰 점유율.
적응 형 창: 버스트 → 일시적으로 오류/느린 속도를 증가시킵니다.
카디널리티 감소: 사용자 에이전트 정규화, IP/ASN, 스쿼시 스택 추적, 마스크 비밀.

6) 구성 (참조)

6. 1 OpenTelemetry Collector-테일 샘플링 (yaml-fection)

yaml receivers:
otlp: { protocols: { http: {}, grpc: {} } }

processors:
batch: { send_batch_size: 8192, timeout: 2s }
tail_sampling:
decision_wait: 5s num_traces: 100000 expected_new_traces_per_sec: 5000 policies:
- name: always-error type: status_code status_code: { status_codes: [ERROR] }
- name: slow-endpoints type: latency latency: { threshold_ms: 300 }      # p95 цель
- name: important-routes type: string_attribute string_attribute: { key: http. target, values: ["/v1/payments", "/v1/payouts"] }
- name: tenant-eu1 type: string_attribute string_attribute: { key: tenant, values: ["eu-1"] }
- name: probabilistic-default type: probabilistic probabilistic: { sampling_percentage: 5. 0 }

exporters:
otlphttp/tempo: { endpoint: http://tempo:4318 }
prometheus: { endpoint: "0. 0. 0. 0:9464" }

service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, tail_sampling]
exporters: [otlphttp/tempo]

6. 2 프로 메테우스-예제 (조각)

응용 프로그램에서 히스토그램을 기록 할 때 'trace _ id' 로 예제를 추가하십시오. Grafana에서는 "바늘" 을 클릭하면 흔적이 생깁니다.

yaml scrape_configs:
- job_name: api scrape_interval: 10s honor_labels: true static_configs: [{ targets: ["api:9100"] }]
exemplar_limit: 10

6. 3 Loki-로그 비용 절감

레이블은 안정적입니다 ('서비스', 'env', 'region', 'route _ class').
높은 카디널리티 (요청 _ id, 사용자 _ id) -페이로드이지만 수정이 있습니다.
"성공적인" InfoLog를 샘플링하고 오류/경고를 저장하십시오.

6. 4 예거/템포-보존 및 지수

원시 트레일을 3-7 일 동안 저장하고 집계/대칭을 더 오래 저장하십시오.
저렴한 스토리지 (S3 호환) 에서 파켓/블록을 사용하면 색인이 컴팩트합니다.

7) 추적 시뮬레이션

7. 1 명칭과 속성

'서비스. 이름 ',' 서비스. 버전 '', 배포 환경 '.
'http. 방법 '', http. 경로 ',' http. 대상 ',' http. 상태 _ 코드 ',' net. 동료. 이름 '.
PII가없는 비즈니스 속성: '테넌트', '지역', '결제 _ 제공자', '게임 _ id'.

7. 2 개의 이벤트 및 연결

스팬 이벤트: 중요한 포인트 (DB 트랜잭션 시작, 재개발, 회로 개방, 캐시 미스).
링크: zapros → vebkhuk/sobytiye 통신; EDA 및 아웃 박스/받은 편지함에 유용합니다.

7. 인스턴스 3 개

대기 시간/크기 히스토그램에 'trace _ id' 가있는 예를 추가하십시오: → 추적에서 한 번의 클릭으로 추적 메트릭까지 탐색.

8) 지표: 무엇과 방법

8. 1 기술

경로/테넌트/제공자 (PSP, KYC) 별 RED.
'db _ exections _ in _ use', 'http _ client _ in _ flight', 'queu _ deep'.
안정화: 재 시도, 타임 아웃, 회로 개방/반 개방, 속도 제한 적중.
이동/자바/파이썬 런타임: GC 일시 정지, 힙합, 안전 포인트, GIL 지연.

8. 2 비즈니스 메트릭

등록/로그인/예금/결론, 전환, 실패 3DS/KYC, 차지 백 비율.
중요한 기능: 시간 대 지갑, 성공률 지불.

8. 3 카디널리티 및 스토리지

노골적인 버킷이있는 히스토그램 (예: '[50,100,200,300,500,1000,2000] ms').
카디널리티가 높은 마크 (원시 사용자 _ id, 요청 _ id) 를 피하십시오. 로그/트레일로 가져 가십시오.

9) 로그: 표준 및 상관 관계

형식: JSON + 필요한 키 ('타임 스탬프', '레벨', '메시지', 'trace _ id', 'span _ id', 'service', 'env').
편집: 마스크 PAN, 토큰, PII.

샘플링: '오류/경고' 의 경우 100%, '잡음' 경로의 '정보' 의 경우 5-20%

'trace _ id' 를 통한 추적 바인딩. 로그 문자열 → "피봇" 을 추적하고 그 반대도 마찬가지입니다.

10) 판매 프로파일 링

CPU/heap/alloc/lock에 연속 프로파일 링 (Pyroscope/Parca) 을 사용하십시오.
p99 피크와 핫 스택의 상관 관계; 7-14 일 동안 유지하십시오.

11) SLO/결함 예산 경고

SLO 경고: "잘못된 예산은 X %/hour보다 빠르게 사용됩니다" (예측 경고).
원인이 아닌 증상: CPU가 아닌 클라이언트 수준 (RUM/edge 또는 경로 당) 에 경고하십시오.
다중 창, 멀티 번 비율: 1 시간 2%, 6 시간 5% - 2 가지 조건.
계획된 열화 중 침묵: 피처 플래그/카나리아 중 임계 값 이동.

12) 비용 및 유지

볼륨 할당량: 월 10N TB/월 추적, 로그-뜨거운 3-7 일, 차가운 S3 30-90 일, 지표-다운 샘플링 (1 분 → 5 분 → 1 시간).
꼬리 규칙은 × 10- × 100의 부피를 줄이고 잘못/느리게 유지합니다.
최저 비용 신호-지표; 가장 높은 값- "정확한" 트레일 및 프로파일.

13) 안티 패턴

"100% 트레일 항상" → 비용, 소음 및 브레이크의 폭발.
키/마스킹없이 무료 형식의 로그.
무한 레이블 메트릭 (user _ id/ip/full UA).
'수하물 '/' 수하물' 은 없습니다-상관 관계가 없습니다.
SLO 대신 CPU/힙에 대한 경고-혜택없이 "화상" 채팅.
오류 우선 순위/느림없이 "랜덤 1%" 샘플링-귀중한 사례를 잃습니다.

14) 대시 보드의 예 (골격)

API 개요: RPS, 클래스 별 오류율, 대기 시간 p95/p99 (예제는 클릭 가능), 상단 라우트.
릴리스/카나리아: 구/새 버전 메트릭, 이상 비율, 개방형 회로, 재 시도 비교.
PSP/KYC: 공급자 별 성공률, 대기 시간 및 실패, 지불 오류와의 상관 관계.
Infra: 리소스, 대기열 채도, 네트워크 삭제로 사용하십시오.

15) iGaming/Finance의 세부 사항

중요한 경로 (예금/결론): 사고 또는 제한된 창에 대해서만 100% 추적; 일반 모드에서 - 꼬리 "모두 오류/긴 대기 시간이 있음".
지역/테넌트: 수하물에 '테넌트', '관할권', '브랜드' 를 추가하십시오. 관할권별로 SLO를 구축하십시오.
Antifrod/bot 필터: 메트릭 및 미량의 위험 API 솔루션 (허용/거부/챌린지), 챌린지 통과 속도, 속도 적중.
감사/준수: PII없이 필요한 최소한을 유지하십시오. 고정 로그-별도의 회로에서.

16) Prod 준비 점검표

• 엔드-투-엔드 전파 ('수하물', '수하물'), 로그/메트릭/트레이스 상관 관계.
• 테일 샘플링 (오류/느린/중요한 라우트) + 확률 적 불이행이있는 OTel 수집기.
• RED/USE 메트릭, 명시 적 버킷, 예제 → 추적으로 전환.
• SLO 및 잘못된 예산 경고 (두 개의 타임 라인).
• 원격 측정 규정 및 예산; 다운 샘플링 메트릭; 로그를위한 냉장 보관.
• 표준화 된 JSON 로그, 수정 PII/비밀.
• 판매 프로파일 링 포함; 사건에 대한 "핫" 스택 대시 보드.
• 카나리아 대시 보드 및 버전 비교; "사각 지대" 없이 해제하십시오.
• 런북: 사건의 샘플링 점유율을 일시적으로 높이는 방법.
• 속성/라벨 명명 문서 및 고 카디널리티 억제.

17) TL; DR

상관 관계 구축: RED/USE → 예시 메트릭 → 트레일 → 로그/프로파일. 결합 된 샘플링을 통한 비용 관리: 작은 헤드% + 테일 규칙 (오류, 느리고 중요한 경로/테넌트). 경고-SLO 및 오류 예산. 보류와 카디널리티를 통제하고 OTel Collector를 "중추 신경계 '로 사용하십시오. "지불/관할 경로-우선 원격 측정 및 엄격한 데이터 위생.