-
[Cloudflare Workers][운영] persist=false로 traces를 외부로만 내보낼 때 head_sampling_rate와 dashboard 저장을 어떤 순서로 분리하나기타개발지식/풀스택개발 2026. 8. 4. 09:16
IT 리서치 노트
[Cloudflare Workers][운영] persist=false로 traces를 외부로만 내보낼 때 head_sampling_rate와 dashboard 저장을 어떤 순서로 분리하나
Cloudflare Workers에서 OpenTelemetry export를 켠 뒤 비용이 오르면 많은 팀이 traces sampling과 logs sampling을 같이 내린다. 하지만 2026년 8월 3일 기준 Cloudflare 공식 문서를 다시 보면, dashboard 저장과 외부 destination export는 다른 축이고, traces는 persist=false로 dashboard 저장 없이 외부로만 보낼 수도 있다. 이 글은 persist=false로 traces를 외부로만 내보낼 때 head_sampling_rate와 dashboard 저장을 어떤 순서로 분리해야 덜 꼬이는지 정리한 것이다.
1. 개요
결론부터 말하면 비용이 올랐을 때 가장 먼저 나눠야 하는 것은 traces와 logs의 비율이 아니라 dashboard retention과 external export의 경계다. traces root cause 복원성이 필요하면 external export는 유지한 채
persist=false로 dashboard 저장만 끄는 선택지가 있고, logs 검색 비용을 줄여야 하면head_sampling_rate를 따로 만지는 편이 빠르다.즉 이번 문제는 sampling 하나의 문제가 아니다. 직전 OTel export 분기 글이 traces와 Workers Logs 비용 상승을 같이 봤다면, 이번 글은 그다음 순서인 retention 분리 단계다. 저장 위치와 전송 위치를 따로 적어 두면 장애 조사 능력을 덜 잃는다.
2. 어디서 실제로 막히는가
현장에서 가장 자주 꼬이는 지점은 세 가지다. 첫째, vendor ingest 비용과 Cloudflare dashboard 저장 비용이 동시에 오르는데 둘을 같은 비용 항목으로 본다. 둘째, root cause 복원성이 필요해서 traces를 유지해야 하는데도 sampling만 내리며 조사 능력을 같이 줄인다. 셋째, Workers Logs 쿼리 비용 문제를 traces 설정으로 해결하려고 해서 logs retention과 sampling 경로를 따로 남기지 않는다.
Cloudflare export 문서는
persist=true가 기본이고 dashboard storage가 별도 과금 축이라고 설명한다. traces 문서는persist=false로 외부 destination만 traces를 보낼 수 있다고 적는다. Wrangler configuration 문서는 logs observability 쪽head_sampling_rate가 별도 손잡이라는 점을 보여 준다. 이 셋을 같이 읽으면 현재 증상은 'sampling 숫자를 몇으로 둘까'보다 '저장 위치와 전송 위치를 어디서 자를까'의 문제라는 결론이 나온다.운영 메모가 빈약하면 여기서 대부분 시간을 잃는다. Cloudflare dashboard query, vendor query, traces export 설정, logs head sampling, persist 여부가 한 줄로 문서화되어 있지 않으면 어느 비용이 실제로 줄었는지 비교도 어렵다. 특히 incident postmortem에서 traces는 필요했는데 dashboard retention만 줄였어야 했다는 결론이 뒤늦게 나오는 경우가 많다.
- 증상: vendor ingest와 dashboard 저장 비용이 같이 오른다.
- 실패: traces와 logs sampling을 같은 숫자로 함께 낮춘다.
- 막힘: persist와 head_sampling_rate를 한 설정으로 오해한다.
- 누락: incident class별로 traces가 꼭 필요한지 문서에 남기지 않는다.
질문 먼저 볼 곳 실무 판단 dashboard 비용인가 export 비용인가 persist와 destination 설정 storage와 export를 따로 기록한다 logs 검색 비용만 줄이면 되는가 head_sampling_rate logs 양 손잡이부터 분리한다 root cause 복원은 유지해야 하는가 traces export 유지 여부 persist=false를 먼저 검토한다 3. 실무에서 적용하는 순서
점검 순서는 다섯 단계가 가장 짧다. 먼저 이번 incident에서 traces가 꼭 필요한지 적는다. 다음으로 현재 dashboard 저장 여부와 external destination 경로를 문서화한다. 세 번째로 logs 비용 문제라면
head_sampling_rate를 먼저 따로 낮춘다. 네 번째로 traces는 유지하되 dashboard 저장이 불필요하면persist=false후보를 올린다. 마지막으로 dashboard query와 vendor query 둘 다에서 실제 관측성이 유지되는지 확인한다.- incident class별로 traces 필요 여부를 적는다.
- dashboard 저장과 external destination을 별도 항목으로 적는다.
- logs 비용 문제면 head_sampling_rate를 먼저 조정한다.
- traces 유지가 필요하면 persist=false를 검토한다.
- dashboard와 vendor query 둘 다에서 결과를 확인한다.
실제 운영에서는 Wrangler 설정 파일, Cloudflare dashboard observability 화면, 외부 vendor ingest 대시보드를 같은 메모에 두는 편이 좋다. 메뉴 경로, 설정 필드, query 결과 표, 로그 결과, 비교 화면을 같은 순서로 저장하고 확인해야 한다. 어떤 Worker가 persist=false인지, 어떤 Worker가 logs sampling만 조정했는지, 어느 incident에서 dashboard query가 필요했는지까지 한 줄로 남겨야 재현이 된다. 특히 같은 팀이 traces 담당과 logs 담당으로 나뉘어 있으면 이 정리가 없을 때 비용 설명이 가장 늦어진다.
observability_note: worker=api-edge incident_class=latency_root_cause dashboard_logs_sampling=0.1 otel_destination_enabled=true trace_persist=false dashboard_query_kept=false vendor_query_verified=true이 메모가 있으면 다음 비용 이슈에서도 왜 traces는 남겼고 왜 dashboard retention만 껐는지를 설명할 수 있다. 반대로 이 기록이 없으면 sampling 변경과 retention 변경이 뒤섞여 회고가 항상 길어진다.
4. 공식 문서와 예시 화면으로 확인하기
첫 자료는 Cloudflare의 OTel export 문서에서 persist와 비용을 설명하는 구간이다. 여기서는 외부 destination export와 dashboard 저장이 같은 비용 축이 아니라는 점을 먼저 확인해야 한다.
이 문장을 고정해 두면 traces 수집을 완전히 줄일지, 아니면 dashboard 저장만 끌지를 더 짧게 자를 수 있다. 이미 OTel export와 traces·Workers Logs 비용 분기 글이 큰 그림을 다뤘다면, 이번 글은 그 안에서 persist=false와 retention order를 더 좁힌 가지다.
두 번째 자료는 traces 문서의 persist=false 설명이다. Cloudflare는 외부 observability provider를 유일한 traces destination으로 둘 수도 있다고 적고 있다.
즉 traces root cause 복원성이 꼭 필요해도, Cloudflare dashboard retention까지 같이 유지해야 하는 것은 아니다. 조사 목적과 저장 위치를 분리해서 쓰는 게 핵심이다.
세 번째 자료는 Wrangler configuration 문서의 observability 설정이다. 여기서는 logs 쪽 head_sampling_rate가 기본 1이고, 별도로 조정된다는 점을 볼 수 있다.
따라서 비용이 올랐다고 traces와 logs를 같은 숫자로 같이 줄일 필요는 없다. persist는 저장 위치 손잡이고, head_sampling_rate는 logs 양 손잡이다.
실무에서는 어떤 incident class가 traces를 필요로 하고, 어떤 문제는 logs만으로 닫히는지 먼저 적어야 한다. 그 다음에 storage와 export와 sampling을 따로 건드린다.
같은 cluster의 앞단인 traces와 Workers Logs sampling 분기 글과 Workers Logs·Tail Workers·Logpush 글을 같이 보면 저장 축과 전송 축을 더 선명하게 나눌 수 있다.
설정 파일을 로그와 traces 기준으로 갈라 적어 두면 비용 회고가 쉬워진다. 실제로는 어떤 Worker가 persist=false인지, logs sampling이 얼마인지 한 눈에 보여야 한다.
이 정도만 남겨도 다음 회고에서 왜 traces는 유지했고 logs는 줄였는지 설명이 된다. dashboard retention을 껐다는 사실을 코드와 운영 메모 양쪽에 남기는 것이 포인트다.
5. 주의사항과 리스크
첫 번째 리스크는 logs 비용 문제를 traces sampling으로 풀려다가 root cause 복원성을 잃는 것이다. 두 번째 리스크는 persist=false를 검토하지 않아 같은 traces를 dashboard와 외부 vendor에 중복 저장하는 것이다. 세 번째 리스크는 dashboard query가 필요한 운영 절차를 문서화하지 않은 채 retention만 꺼 버리는 것이다.
운영 전에 확인할 때는 최소한 incident class, dashboard query 의존성, external vendor query 의존성, logs sampling, trace retention 다섯 칸을 같은 표에 두는 편이 좋다. 그래야 비용 절감과 조사 능력을 같이 판단할 수 있다.
- persist는 저장 위치 손잡이이고 head_sampling_rate는 logs 양 손잡이다.
- dashboard 비용과 vendor ingest 비용을 따로 본다.
- traces 필요 incident와 logs-only incident를 문서에서 분리한다.
6. 결론
Cloudflare Workers observability 비용이 올랐을 때는 traces와 logs를 같이 줄이는 것보다 dashboard retention과 external export를 먼저 나누는 편이 빠르다. traces 복원성이 필요하면 외부 export는 유지하고 persist=false를 검토하고, logs 비용 문제라면 head_sampling_rate를 따로 조정하면 된다.
- storage와 export를 먼저 나눈다.
- logs sampling과 traces retention을 같은 손잡이로 보지 않는다.
- dashboard query와 vendor query 절차를 함께 남긴다.
같은 가지의 앞단에는 OTel export와 비용 분기 글, traces와 Workers Logs sampling 분기 글, Workers Logs·Tail Workers·Logpush 글이 있다. 그 위에 이번 persist=false 분기를 얹으면 retention 결정이 더 실무적인 순서로 닫힌다.
7. 참고 링크
'기타개발지식 > 풀스택개발' 카테고리의 다른 글
