분산 추적

분산 추적

1) 왜 그리고 무엇인가

분산 추적은 전체 요청 경로를 따라 작업을 연결하는 방법입니다. 전면 → 게이트웨이 → 마이크로 서비스 → 데이터베이스/캐시 → 브로커 → bs/파이프 라인.
결과는 스팬 (스팬) 의 트레이스이며, 각 스팬은 속성, 이벤트 및 상태로 구성 요소의 작동을 캡처합니다. 이렇게하면 RCA가 가속화되고 SLO를 유지하고 MTTR을 줄일 수 있습니다.

• 중요한 경로와 병목 현상의 가시성.
• 증상 (지표) 과 원인 (스팬) 및 세부 사항 (로그) 의 상관 관계
• 배송, 대기열, DLQ, 팬 아웃, 대기 시간의 "톱" 분석.

2) 추적 데이터 모델

추적-' trace _ id '로 그래프를 호출하십시오.
스팬-о계정 ра자료: '이름', '종류' (SERVER/CLIENT/PRODUCER/CONSUCER/INTERNAL), '시작/종료', '상태', '속성', '이벤트', '링크 [].
속성 - 값 키 (경로, db. 시스템, 메시징. 시스템, 클라우드. 지역 등).
이벤트 - 스팬 내부의 인스턴트 태그 (예: '재 시도', '캐시 _ 미스').
스팬 링크-" 부모-자식 "(batchi, retrai, fan-in/out) 외부의 연결.
리소스 - 프로세스/서비스 메타 데이터 ('서비스 이름 ', 버전, 환경).

3) 맥락과 내약성

3. 1 W3C 추적 컨텍스트

• 'traceparent': '버전-traceid-spanid-flags' (플래그에는 샘플링 포함).
• 'tracestate': 공급 업체 별 상태 (최소).
• 수하물-비즈니스 컨텍스트 키 (제한된 PII/비밀 없음).

3. 2 던지기 컨텍스트

해: 'traceparent '/' tracestate'; gRPC: 메타 데이터; 웹 소켓: 업그레이드 및 메시지;

메시지: 헤더 (Kafka/NATS/RabbitMQ) -PRODUCER로 원래 컨텍스트를 저장하고 CONSUMER로 전송하십시오.
기본: 컨텍스트를 "전달" 하지 마십시오. (쿼리, 행, db. 시스템), 값은 아닙니다.

4) 샘플링: 파산하지 않는 방법

헤드 샘플링: 확률/규칙 별 (경로, 세입자, 엔드 포인트).
테일 샘플링 (수집기): "흥미로운" 트레일 저장-오류, 긴 p95/p99, 희귀 경로.
Exemplars: Histogram metrics는 특정 'trace _ id' 에 대한 참조를 저장합니다.
권장 사항: 5xx/타임 아웃/p99의 헤드 5-20% + 테일 규칙 100%.

5) 속성 및 분류 (최소 필요)

• '서비스. 이름 ',' 서비스. 버전 '', 배포 환경 ',' 구름. 지역 ',' http. 경로 ',' http. 방법 '', http. 상태 _ 코드 ',' db. 시스템 ',' db. '(데이터없이 단축/없이)', 메시징. 시스템 ',' 메시징. 작업 ',' 피어. 서비스 ',' net. 동료. 이름 ',' 테넌트. id ',' 요청. id '.

비즈니스 레이블: 깔끔하고 PII가 없습니다. 예: '순서. 세그먼트 ',' 계획. 계층 '.

6) 비동기 스크립트, 대기열 및 배치

PRODUCER → ConSUMER: 컨텍스트가있는 스팬 PRODUCER를 생성합니다. 메시지-헤더 (수하물, 수하물). CONSUMER는 링크에서 PRODUCER까지 SERVER/CONSUMER-span을 시작합니다 (엄격한 계층 구조가없는 경우).
팬 아웃: 하나의 입력-많은 출력 → 자식 스팬 또는 링크.
배치: CONSUMER는 N 개별 컨텍스트에 대해 각 메시지에 대해 '이벤트' 와 함께 N 메시지의 버스트 → 하나의 스팬을 읽습니다.

DLQ: 별도의 스팬 메시징. dlq. (PHP 3 = 3.0.6, PHP 4)

Retrai: '이벤트: 재 시도' + '재 시도. 계산 '속성; 바람직하게는 새로운 어린이가 시도해야합니다.

7) 로그 및 메트릭과의 통합

'trace _ id '/' span _ id' → 로그부터 클릭하여 로그로갑니다.
RED/USE 메트릭에는 p99 피크에서 "나쁜" 스팬으로가는 예제가 포함되어 있습니다.
추적은 이벤트를 통해 기술 신호 (종속성 오류) 및 비즈니스 신호 (변환) 를 생성합니다.

8) 성능 및 비용

이벤트 샘플링 및 스로틀 링.
속성의 카디널리티 감소 ('user _ id '/' sesion _ id' as 레이블!).
수출업자에 의한 압축/버칭; 수출 시간 초과 경계.
스토리지: 뜨거운 1-7 일 후-단위/만 "문제" 트레일.
지출 범주: 수집가, 지수, 저장, 탈출.

9) 보안 및 개인 정보 보호

대중 교통: TLS 1. 3/mSL kollektor genty; 휴식 시간: 암호화, 개인 키 ("대중 교통 암호화/휴식 중" 참조).
PII 및 비밀: 속성/이벤트에 쓰지 마십시오. 생산자에 대한 토큰 화/마스킹.
멀티 테넌시: '테넌트. 자원 라벨로서의 id '및 공간 격리, 읽기 정책; 추적 액세스 감사 (감사 및 수정되지 않은 로그 참조).

10) 구현 체계 (참조)

10. 1 OpenTelemetry SDK (의사 코드)

python from opentelemetry import trace from opentelemetry. sdk. trace import TracerProvider from opentelemetry. sdk. resources import Resource from opentelemetry. sdk. trace. export import BatchSpanProcessor from opentelemetry. exporter. otlp. proto. grpc. trace_exporter import OTLPSpanExporter

provider = TracerProvider(resource=Resource. create({
"service. name":"checkout","service. version":"1. 12. 0","deployment. environment":"prod"
}))
provider. add_span_processor(BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317", insecure=True)))
trace. set_tracer_provider(provider)
tr = trace. get_tracer("checkout")

with tr. start_as_current_span("POST /pay", attributes={
"http. route":"/pay","http. method":"POST","tenant. id":"t-42"
}):
business logic, external API call and pass DB

10. 2 OTel 수집기-테일 샘플링 (조각)

yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_codes: [ERROR]
- type: latency threshold_ms: 900
- type: probabilistic sampling_percentage: 10 exporters:
otlphttp: { endpoint: http://trace-backend:4318 }
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, tailsampling]
exporters: [otlphttp]

10. 3 카프카-컨텍스트 전송 (컨셉)

프로듀서: '수하물', '수하물' 헤더를 추가하십시오.
연락처: 메시지가 새 스트림을 시작하면 새 SERVER/CONSUMER가 링크에서 컨텍스트까지 헤더로 확장됩니다.

11) 데이터/ETL... ML

배치 파이프 라인의 경우: 'dataset을 사용한 배치/파티션 범위. 항아리 ',' 실행. id ',' 행. 'in/out', '신선도. 지연 '.
ML: 교육/추론, 모델 버전, 대기 시간, 기능 저장소 범위.
리니지 링크: '실행. id '달력' 데이터 세트. 항아리는 추적에서 데이터 원점 그래프로 이동할 수 있습니다.

12) 추적 플랫폼 SLO

가용성 섭취: 99 이상. 9%

색인 지연: PHP 3: PHP 4: PHP 4

헤드 샘플 범위: 주요 경로의 5-10% 이상

상태 ERROR 및 "중요 경로" 디렉토리에 따른 대기 시간> 임계 값을 갖는 트레일 100% 절약

플랫폼 경고: 낙하, 수출 타임 아웃, 인덱서 지연, 카디널리티 과열.

13) 테스트 및 검증

CI의 추적 계약: 주요 엔드 포인트, 필수 속성, 게이트웨이/프록시를 통한 정확한 '추적' 파리에 스팬이 존재합니다.
합성/럼 샘플: 외부에서 트레일을 수집합니다.
혼돈/사건: 종속성을 비활성화하여 테일 샘플러가 "픽업" 오류인지 확인합니다.
판매 연기: 출시 후 "스팬이 있습니다" 및 모범 → 추적.

14) 점검표

판매하기 전에

• W3C 추적 컨텍스트는 모든 곳에서 던져집니다. 메시지 - 헤더.
• 기본 헤드 샘플링이 활성화되었습니다. 5xx/p99의 테일 규칙이 구성됩니다.
• 필수 속성은 경로, 방법, 상태, 서비스입니다. 버전, 테넌트. id.
• JSON은 'trace _ id '/' span _ id' 로 로그하고 예시가있는 메트릭을 로그합니다.
• PII 소독제; 이동/정지 액세스 정책에 대한 암호화.
• 대시 보드: "중요한 경로", "의존성 오류", "레트라/타임 아웃".

작동

• 속성의 카디널리티에 대한 월간 검토; 할당량.
• SLO에 의한 튜닝 테일 샘플링 (샘플에서 소음이 적고 모든 "핫").
• 전이 메트릭 → 모범이있는 훈련 RCA → 추적 → 로그.
• 대기열, DLQ, ETL 작업에 대한 표지 확인.

15) 런북

RCA: p99 상승/지불

1. RED 대시 보드를 엽니 다. 빈 p99에서 모범으로 추적합니다.
2. "좁은" CLIENT 스팬 (예: '게이트웨이') 을 찾으십시오. '), 다시 시도하십시오. 계산 ', 타임 아웃.
3. 서비스 버전/종속성, 지역/영역을 비교하십시오.
4. 열화 (캐싱 응답/RPS 제한) 를 사용하면 종속성 소유자에게 알립니다.
5. 수정 후-RCA 및 최적화 티켓.

DLQ 서지

1. '메시징 별 트레이스 필터. dlq. 출판 '.
2. 이유 (이벤트) 를 확인하고 릴리스와 관련이 있습니다.

3. 재처리를 시작하고 CONSUMER의 타임 아웃을 일시적으로 늘리고 다운 스트림 소유자에게 알리십

16) 빈번한 오류

게이트웨이/브로커를 통한 컨텍스트 예측은 없습니다. 솔루션: 미들웨어/인터 셉터, 단일 라이브러리.
모든 트레일은 100% 입니다. 비싸고 무의미한-테일 샘플링을 사용하십시오.
'trace _ id' 가없는 로그. 상관 → MTTR ZH가 손실됩니다.
속성의 PII. 마스크/토큰 화; 기술적 맥락 만 유지하십시오.
"음소거" 배경 bs. 배치/파티션 및 실행에 스팬을 추가합니다. id '.
명명 불일치. 스팬 및 속성 키 사전을 입력하십시오.

17) FAQ

Q: 머리 또는 꼬리 샘플링이 더 좋습니까?
A: 조합. 머리는 기본 층을 제공하고 꼬리는 이상/오류의 보존을 보장합니다.

Q: 엄격한 계층 구조없이 Kafka를 어떻게 추적합니까?
A: PRODUCER와 CONSUMER 간의 스팬 링크 사용; 문맥-헤더.

Q: 민감한 SQL로 무엇을해야합니까?
A: 'db. '단축/정규화 (값 없음)' 또는 'db. 작동 '+ 치수/시간.

Q: 비즈니스 지표와 어떤 관련이 있습니까?
A: PII (플랜/세그먼트) 없이 도메인의 속성을 추가하고 스팬 내에서 "비즈니스 단계" 이벤트를 사용하며 변환 메트릭에서 모범으로 이동합니다.

• "관찰 가능성: 로그, 메트릭, 추적"
• "감사 및 불변의 통나무"
• "대중 교통/휴식 시간에 암호화"
• "데이터 원점 (리니지)"
• "디자인 별 개인 정보 보호 (GDPR)"
• "비밀 관리"