[Cloudflare Workers][운영] OpenTelemetry export를 켠 뒤 traces와 Workers Logs 비용이 같이 늘 때 head_sampling_rate와 persist를 어디부터 나누나

IT 리서치 노트

[Cloudflare Workers][운영] OpenTelemetry export를 켠 뒤 traces와 Workers Logs 비용이 같이 늘 때 head_sampling_rate와 persist를 어디부터 나누나

Cloudflare Workers에 OpenTelemetry export를 붙이고 나면 traces와 Workers Logs 비용이 같이 늘어나는 순간이 온다. 2026년 8월 3일 기준 Cloudflare 공식 문서를 다시 보면, traces와 logs는 각각 sampling을 따로 가질 수 있고, traces는 `persist: false`로 Cloudflare 대시보드 저장 없이 외부 destination만 쓸 수도 있다. 이 글은 OpenTelemetry export를 켠 뒤 비용이 같이 늘 때 head_sampling_rate와 persist를 어디부터 나누는 편이 덜 꼬이는지 정리한 것이다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 OTel export 이후 비용이 늘었다고 해서 traces와 Workers Logs sampling을 같은 숫자로 같이 내릴 필요는 없다. traces root cause 복원이 더 중요하면 traces sampling은 높게 유지하고 persist: false로 저장 위치를 바꾸는 편이 맞고, 저장 로그 검색성이 더 중요하면 Workers Logs head_sampling_rate부터 줄이는 편이 더 짧다.

즉 비용 문제는 sampling 하나의 문제가 아니라 저장 위치와 export 범위의 문제다. traces를 Cloudflare에 남길지, 외부 stack에만 둘지, logs를 얼마나 저장할지를 अलग개로 적어 두어야 같은 장애 때 조사 능력을 잃지 않는다.

2. 어디서 실제로 막히는가

실무에서 제일 먼저 꼬이는 지점은 세 가지다. 첫째, OTel export를 켠 뒤 비용이 늘면 traces와 logs sampling 값을 한 번에 같이 내린다. 둘째, traces를 줄이면 path 복원성이 사라지는데도 Cloudflare 저장량만 보고 같은 비율로 줄인다. 셋째, traces를 외부 destination으로만 보내도 되는지 검토하지 않고 Cloudflare 저장과 외부 ingest를 둘 다 유지한다.

Cloudflare traces 문서는 tracing 기본 sampling rate가 1이라고 적고, Workers Logs 문서는 logs도 기본 head sampling rate가 1이라고 설명한다. 또 traces 문서는 persist: false로 대시보드 저장 없이 외부 destination만 쓸 수 있다고 밝히고, OTel export 문서는 traces와 logs를 모두 export할 수 있다고 적는다. 이 네 가지를 같이 읽으면 비용 증가는 같은 숫자 하나의 문제가 아니라 traces 저장, logs 저장, 외부 export 세 축이 겹친 결과라는 사실이 분명해진다.

• 증상: OTel export를 켠 뒤 Cloudflare 저장량과 외부 ingest가 같이 늘어난다.
• 실패: traces와 logs sampling을 같은 숫자로 한꺼번에 낮춘다.
• 막힘: persist 설정을 보지 않고 sampling만 계속 만진다.
• 누락: 어떤 incident는 traces가 필요하고 어떤 incident는 logs면 충분한지 미리 적지 않는다.

질문	먼저 볼 곳	실무 판단
trace 복원성이 중요한가	traces sampling과 persist	sampling보다 저장 위치를 먼저 나눈다
로그 검색성이 중요한가	Workers Logs sampling	logs 비율을 따로 조절한다
비용이 Cloudflare 저장인지 외부 ingest인지	persist 값과 destination metrics	저장 축과 전송 축을 अलग개로 기록한다

3. 실무에서 적용하는 순서

운영 순서는 다섯 단계가 가장 짧다. 먼저 이번 incident에서 traces가 필요한지, logs면 충분한지 적는다. 다음으로 현재 traces sampling, logs sampling, persist 값을 메모한다. 세 번째로 Cloudflare 저장 비용과 외부 destination ingest를 अलग개로 본다. 네 번째로 traces가 꼭 필요하면 sampling을 유지한 채 persist만 끄는 선택지를 검토한다. 마지막으로 로그 검색성이 필요하면 Workers Logs sampling만 따로 조정하고, 다시 2xx/4xx incident 한 번을 기준으로 조사 가능성을 재검증한다.

1. 이번 조사에 traces가 필요한지 먼저 적는다.
2. traces/logs sampling과 persist 값을 함께 메모한다.
3. Cloudflare 저장 비용과 외부 ingest 비용을 따로 본다.
4. trace가 필요하면 sampling보다 persist 분리를 먼저 검토한다.
5. logs 검색성이 필요하면 Workers Logs sampling만 따로 줄인다.

실제 운영에서는 Cloudflare 대시보드 observability 설정, Wrangler 설정, 외부 OTel vendor ingest 화면을 같은 타임라인으로 놓는 편이 좋다. traces와 logs 둘 다 기본값 1에서 시작했다면, 어느 순간 비용이 커졌을 때 무조건 둘 다 0.1로 낮추기보다 traces root cause 복원, logs 검색, vendor ingest 세 목적을 먼저 나눠야 한다.

observability_note:
incident_class=latency_root_cause
traces_head_sampling_rate=1
logs_head_sampling_rate=0.1
trace_persist=false
cloudflare_storage_cost_checked=true
vendor_ingest_cost_checked=true

이 메모가 있으면 다음 비용 이슈에서도 왜 traces는 유지했고 logs만 줄였는지, 왜 sampling이 아니라 persist를 먼저 건드렸는지 설명이 쉬워진다.

4. 공식 문서와 예시 화면으로 확인하기

첫 공식 화면은 traces export 문서에서 `persist: false`를 설명하는 구간이다. 이 옵션을 켜면 traces를 외부 OTel destination으로만 보내고 Cloudflare 대시보드에 저장하지 않을 수 있다.

Cloudflare traces 문서는 `persist: false`로 대시보드 저장 없이 외부 OTel destination만 쓸 수 있다고 설명한다.

즉 traces 저장 비용이 문제일 때는 sampling만 만지기 전에 저장 자체를 남길지부터 나눠야 한다. traces를 외부 stack에만 둘 수 있다면 같은 incident라도 Cloudflare 저장량과 외부 OTLP 전송량을 अलग개로 다룰 수 있다.

두 번째 자료는 traces의 기본 sampling 값이다. tracing이 켜져 있으면 기본 head sampling rate가 1이라 100% 요청이 trace될 수 있다는 점을 먼저 적어 두어야 한다.

Cloudflare traces는 기본 sampling rate가 1이라 tracing을 켜면 전량 수집이 시작된다고 설명한다.

이 기본값을 모르고 OTEL export만 붙이면 trace volume이 생각보다 빨리 커진다. 비용이 늘었을 때 logs 때문인지 traces 때문인지 먼저 나누려면 traces 기본값부터 기억해야 한다.

세 번째 공식 화면은 Workers Logs 문서다. 로그 쪽도 head_sampling_rate를 지정하지 않으면 기본값이 1이라는 점을 보여 준다.

Workers Logs도 head_sampling_rate를 지정하지 않으면 기본값 1로 전량 저장을 시작한다고 적고 있다.

traces와 logs가 둘 다 기본 100%면, OTEL export를 붙인 뒤 비용이 늘어나는 구간은 거의 항상 둘 중 하나가 아니라 둘 다다. 그래서 같은 숫자를 한 번에 내리기보다 저장 목적과 조사 목적을 먼저 나눠야 한다.

네 번째 자료는 Cloudflare OTel export 문서의 telemetry type 설명이다. traces와 logs를 둘 다 외부 destination으로 내보낼 수 있다는 점이 핵심이다.

Cloudflare는 traces와 logs를 모두 OTel destination으로 export할 수 있다고 설명한다.

이미 traces와 Workers Logs sampling 분기 글이 같은 대시보드 안의 저장 비율을 다뤘다면, 이번 글은 export destination까지 포함해 저장 위치와 sampling을 다시 나누는 후속편이다.

다섯 번째 자료는 실제 분기표다. 비용이 늘어도 traces를 낮출지, logs를 낮출지, persist를 끌지, OTel destination 필터를 바꿀지는 같은 답이 아니다.

Cloudflare OTel export 이후 비용 증가를 traces, logs, persist 설정으로 나누는 판단표다.

이 표를 기준으로 보면 logs 저장량 문제를 trace sampling으로 풀거나, 반대로 trace 복원성이 필요한 incident를 logs sampling으로 잘못 줄이는 실수를 줄일 수 있다.

마지막 자료는 Wrangler 설정 예시다. traces sampling, logs sampling, persist를 한 번에 같은 값으로 묶지 않고 목적별로 나누는 모습이 중요하다.

traces, logs, persist를 분리한 Cloudflare Workers observability 설정 예시다.

같은 클러스터의 앞단인 Workers Logs와 Tail Workers와 Logpush 분기 글까지 같이 보면 저장 경로, export 경로, sampling 손잡이를 한 줄로 정리하기 쉽다.

5. 주의사항과 리스크

첫 번째 리스크는 traces와 logs를 같은 비율로 줄여 trace root cause를 잃는 것이다. 두 번째는 비용이 저장 문제인지 export 문제인지 구분하지 않고 Cloudflare 설정 하나만 계속 바꾸는 것이다. 세 번째는 persist: false를 검토하지 않아 같은 trace를 Cloudflare와 외부 vendor에 동시에 오래 저장하는 것이다.

운영 전에 확인할 때는 incident class, traces sampling, logs sampling, persist, vendor ingest 다섯 칸을 같은 표에 두는 편이 좋다. 그래야 어떤 조사 능력을 유지할지와 어떤 저장 비용을 포기할지를 같이 결정할 수 있다.

• sampling과 persist는 같은 손잡이가 아니다.
• Cloudflare 저장 비용과 외부 ingest 비용을 अलग개로 본다.
• trace 복원성이 필요한 incident는 logs 비용 문제와 분리한다.

6. 결론

Cloudflare Workers에서 OpenTelemetry export를 켠 뒤 비용이 늘 때는 sampling 하나만 내리는 식으로 접근하면 조사 능력까지 같이 줄어든다. traces와 Workers Logs 역할을 나누고, traces는 필요하면 유지하되 persist를 분리하고, logs는 검색성 기준으로 따로 조절하는 편이 덜 꼬인다.

• traces와 logs는 같은 숫자로 같이 줄이지 않는다.
• persist: false는 sampling과 다른 축으로 본다.
• Cloudflare 저장과 외부 ingest를 각각 기록한다.

이 가지를 실제 운영 순서까지 더 좁히려면 새 후속 글인 persist=false로 traces를 외부로만 내보낼 때 head_sampling_rate와 dashboard 저장을 어떤 순서로 분리하나를 이어서 보면 좋다. export destination을 Cloudflare 저장과 분리한 뒤 dashboard retention과 query 흐름을 어떤 화면에서 확인해야 하는지까지 한 단계 더 정리해 두었다.

같은 가지의 앞단에는 traces와 Workers Logs sampling 분기 글, Workers Logs와 Tail Workers와 Logpush 분기 글, waitUntil과 Queue·Tail Worker 분기 글이 있다. 그 위에 이번 export·persist 분기를 얹으면 observability 비용 조정 메모가 더 실무적으로 닫힌다.

7. 참고 링크

1. https://developers.cloudflare.com/workers/observability/traces/
2. https://developers.cloudflare.com/workers/observability/logs/workers-logs/
3. https://developers.cloudflare.com/workers/observability/exporting-opentelemetry-data/
4. https://developers.cloudflare.com/workers/wrangler/configuration/
5. https://developers.cloudflare.com/workers/best-practices/workers-best-practices/