트레이스가 이어지고 끊기는 것을 본다

이 실습은 진짜 OpenTelemetry 에서 돕니다

VM 안에 OTel 컬렉터 · Jaeger · 서로를 부르는 서비스 둘이 실제로 떠
있습니다. 요청이 오가고, 스팬이 만들어지고, 컬렉터를 거쳐 Jaeger 에 쌓입니다.

앞 모듈의 트레이싱 실습은 가짜 클러스터에서 돌았습니다. 요청이 오가지
않으니 전파가 끊기는 현상 자체가 일어나지 않았습니다. 그것이 OTCA 가
가장 많이 묻는 자리인데도요.

SDK 를 깔지 않습니다. 서비스가 표준 라이브러리로 OTLP/HTTP 를 직접
만듭니다. OTCA 가 묻는 것이 traceparent 의 생김새와 OTLP 의 모양이라,
손으로 만들어 보는 편이 오히려 시험 범위에 가깝습니다.

처음 뜨는 데 4분쯤 걸립니다.

준비된 것

frontend   http://127.0.0.1:30080   backend 를 부릅니다backend    obs 네임스페이스 안컬렉터     설정은 /etc/otelcol/config.yamlJaeger     http://127.0.0.1:30686질의 도구  traces frontend

단계

1. 요청 하나를 흘려 스팬이 이어지는 것을 /root/otca/flow.txt 에 담으세요.
2. traceparent 를 뜯어 /root/otca/traceparent.txt 에 담으세요.
3. OTLP 로 보낸 것을 확인해 /root/otca/otlp.txt 에 담으세요.
4. 컬렉터 파이프라인에 프로세서를 넣고 순서가 처리 순서임을 /root/otca/pipeline.txt 에 담으세요.
5. 전파를 끊어 트레이스가 둘로 갈라지는 것을 /root/otca/broken.txt 에 담으세요.
6. 리소스 속성과 시맨틱 컨벤션을 /root/otca/semconv.txt 에 담으세요.
7. 샘플링을 걸고 무엇이 버려지는지 /root/otca/sampling.txt 에 담으세요.
8. /root/otca/report.md 에 services=, broken_traces=, pipeline_order= 세 줄과 설명을 쓰세요.

참고

• traces frontend 로 최근 트레이스를 봅니다. | jq 로 걸러 보세요.
• 컬렉터 설정을 고쳤으면 apply_col 로 반영합니다. 컬렉터는 설정을 다시 읽는 방법이 없어 파드를 새로 띄웁니다.
• 흔한 실수: 스팬이 도착했는데 화면에 안 보이는 것. 타임스탬프를 확인하세요. 작은 수를 넣으면 1970년으로 색인됩니다.
• 흔한 실수: Jaeger 질의 API 에 시간 범위를 안 주는 것. 빈 결과가 돌아옵니다.

단계 8개

1. 요청 하나가 남기는 것
2. 헤더 한 줄의 생김새
3. OTLP 는 저장소가 아니라 프로토콜이다
4. 프로세서 순서가 처리 순서다
5. 전파가 끊기면 무엇이 보이나
6. 이름을 마음대로 지으면 안 되는 이유
7. 무엇을 버릴 것인가
8. 무엇을 배웠나