이 문서에서는, 스팬의 데이터가 Cloud Trace로 전송되었는지 여부를 나타내는 샘플링 개념에 대해 소개합니다. 스팬의 데이터가 Cloud Trace로 전송되면 해당 스팬이 샘플링되었다고 합니다. 한 trace에서 모든 스팬의 데이터가 기록되면 trace가 완료됩니다. 하지만 분산 trace 시스템의 각 계측 구성요소가 처리 중인 스팬을 기록할지 여부를 독립적으로 결정하므로 trace에는 스팬이 누락되는 경우가 종종 있습니다.
각 구성요소는 처리 중인 스팬이 샘플링되는지 여부에 대해 자체적으로 결정하지만, 이 결정은 상위 요소의 샘플링 결정에 영향을 받을 수 있습니다. 예를 들어 모든 구성요소에 '상위 스팬이 샘플링되면 현재 스팬을 샘플링하고 그렇지 않으면 스팬의 50%를 샘플링한다'라는 규칙이 있다고 가정합니다. 이 시나리오에서는 다음 사항이 적용됩니다.
루트 스팬은 trace의 모든 스팬이 샘플링되는지 여부를 결정합니다.
루트 스팬이 샘플링되면 trace의 모든 스팬이 샘플링됩니다. 따라서 trace가 완료됩니다.
구성요소는 컨텍스트를 사용하여 샘플링 결정을 하위 요소에 전달할 수 있습니다.
예를 들어 월드 와이드 웹 컨소시엄(W3C) traceparent 헤더에서 sampled 플래그는 상위 요소의 샘플링 결정을 저장합니다.
샘플링을 컨텍스트 전파와 혼동하지 않도록 주의하세요. 샘플링은 구성요소가 스팬에 대한 데이터를 기록하는지 여부를 말합니다. 컨텍스트 전파는 스팬 ID와 같은 스팬에 대한 정보가 하위 구성요소에 전달되는지를 나타냅니다.
샘플링 전략
샘플링 결정은 헤드 기반 또는 테일 기반일 수 있습니다.
헤드 기반 샘플링에서는 스팬을 처리하는 구성요소에서 요청을 수신할 때 샘플링 결정이 내려집니다.
테일 기반 샘플링에서는 전체 trace를 사용할 수 있을 때까지 샘플링 결정이 지연됩니다.
분산 추적 시스템 문서에서 '100% 샘플링'이라는 문구를 볼 수 있습니다. 이 문구는 trace 또는 구성요소에 적용될 수 있습니다. trace에 적용되면 모든 스팬이 샘플링되었거나 trace가 완료되었음을 의미합니다. 구성요소에 적용되면 구성요소가 처리하는 모든 스팬을 샘플링합니다.
헤드 기반 샘플링
헤드 기반 샘플러는 일반적으로 항상 스팬을 샘플링하거나 확률적 샘플링 전략을 사용하도록 구성됩니다.
항상 샘플 구성을 사용하면 스팬을 제공하고 trace 데이터를 쓸 수 있는 모든 구성요소가 처리하는 스팬을 샘플링합니다. 이상적으로는 모든 trace가 완료되면 오류 문제 해결에 필요한 정보를 얻을 수 있습니다.
이러한 유형의 구성은 quotas 또는 스토리지 비용 한도 초과의 원인이 될 수 있습니다.
확률적 샘플링을 사용하면 모든 스팬이 샘플링되는 것은 아닙니다.
이 방법의 실제 동작은 구성요소의 구현에 따라 달라집니다. 일부 구현에서는 모든 스팬의 샘플링 가능성이 동일합니다. 다른 경우에는 상위 요소의 샘플링 결정이 스팬이 샘플링되는지 여부에 영향을 미칩니다.
trace에는 모든 스팬이 포함되어 있지 않을 수 있습니다. 이러한 문제는 확률적 샘플링 사용, 할당량 또는 요청을 처리하지만 스팬을 샘플링하지 않는 구성요소 때문일 수 있습니다.
테일 기반 샘플링
Cloud Trace는 테일 기반 샘플링을 지원하지 않습니다. Cloud Trace로 데이터를 전송하는 구성요소에서 샘플링 결정을 내려야 합니다.
테일 기반 샘플링을 사용하려면 샘플링 결정을 내린 후 Cloud Trace로 데이터를 전달하는 trace 정보를 수신하는 중간 서버를 사용하면 됩니다. 예를 들어 꼬리 샘플링 프로세서와 함께 OpenTelemetry Collector를 사용해 지연된 샘플링 결정을 내릴 수 있습니다.
테일 샘플링을 사용하려는 경우 다음 사항을 고려하세요.
샘플링 결정을 내리기 전에 모든 스팬을 trace에 저장해야 합니다.
따라서 많은 양의 임시 스토리지가 필요하거나 다른 오버헤드가 발생할 수 있습니다.
일반적으로 trace에 대한 스팬을 생성할 수 있는 모든 구성요소는 조정이 필요합니다. 일반적으로 OpenTelemetry를 사용하는 개발자는 동일한 trace ID의 모든 스팬을 동일한 수집기로 라우팅합니다.
샘플링 및 Google Cloud 서비스
각 Google Cloud 서비스는 자체 샘플링 결정을 내리며, 모든 Google Cloud 서비스가 샘플링을 하는 것은 아닙니다. 즉, 서비스가 Cloud Trace에 데이터를 전송하지 않을 수도 있습니다.
Google Cloud 서비스에서 샘플링을 지원하는 경우 이 서비스는 일반적으로 다음을 구현합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2024-12-17(UTC)"],[],[],null,["# Trace sampling\n\nThis document introduces the concept of *sampling* , which refers to whether\ndata for a [span](/trace/docs/traces-and-spans#span) is sent to Cloud Trace. When data for a span\nis sent to Cloud Trace, then that span is *sampled*. When data for every\nspan in a trace is recorded, the trace is complete. However, traces frequently\nhave missing spans because each instrumented component in a distributed tracing\nsystem independently decides whether or not to record the\nspan it is processing.\n\nAlthough each component makes its own decision as to whether the span it is\nprocessing is sampled, that decision can be influenced by the parent's\nsampling decision. For example, assume every component has a rule that says\n\"if the parent span is sampled, then sample the current span; otherwise,\nsample 50% of the spans\". In this scenario, the following is true:\n\n- The root span determines whether all spans in the trace are sampled.\n- When the root span is sampled, all spans in the trace are sampled. Therefore, the trace is complete.\n\nComponents can pass their sampling decision to the child by using context.\nFor example, in the World Wide Web Consortium (W3C)\n[`traceparent` header](https://www.w3.org/TR/trace-context/),\nthe [`sampled` flag](https://www.w3.org/TR/trace-context/#sampled-flag) stores the parent's sampling decision.\n\nDon't confuse sampling with [context propagation](/trace/docs/trace-context). Sampling\nrefers to whether a component records data about a span. Context propagation\nrefers to whether information about the span, such as the span ID, is\npassed to child components.\n\nSampling strategies\n-------------------\n\nSampling decisions can either be head-based or tail-based.\nIn *head-based sampling* , the sampling decision is made when the request is\nreceived by the component processing the span.\nIn *tail-based sampling*, the sampling decision is delayed\nuntil after the entire trace is available.\n\nYou might encounter the phrase \"100% sampling\" in documentation for\ndistributed tracing systems. This phrase might apply to a trace or to a\ncomponent. When applied to a trace, it means that all spans have been sampled,\nor equivalently, that the trace is complete. When applied to a component,\nit means that the component samples every span it processes.\n\n### Head-based sampling\n\nHead-based samplers are typically configured to always sample spans or to\nuse a probabilistic sampling strategy:\n\n- With *always sample* configurations, all components\n that service spans and that can write trace data, sample the spans they\n process. Ideally, all traces are complete,\n and therefore you have the information necessary to troubleshoot failures.\n This type of configuration might cause you to exceed [quotas](/trace/docs/quotas),\n or your storage cost limits.\n\n- With *probabilistic* sampling, not all spans are sampled.\n The actual behavior for this approach depends\n on the component's implementation. In some implementations, all spans have\n the same probability of being sampled. In others, the sampling decision of\n the parent influences whether a span is sampled.\n\nTraces might not contain every span. This might be expected due to the use of\n*probabilistic* sampling, or it might be due to quota, or to components that\nprocess a request but don't sample the span.\n\n### Tail-based sampling\n\nCloud Trace doesn't support tail-based sampling; sampling\ndecisions must be made in the components that send data to Cloud Trace.\n\nIf you want to use tail-based sampling, then you can use an intermediary\nserver that receives tracing information which relays data to\nCloud Trace after making a sampling decision. For example, you can use\nthe [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/)\nwith the [Tail Sampling Processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/tailsamplingprocessor)\nto make a delayed sampling decision.\n\nIf you plan to use tail sampling, consider the following:\n\n- You must store all spans in a trace before you make a sampling decision. Therefore, you might require a large amount of temporary storage or incur other overhead.\n- In general, all components that can generate spans for trace need to coordinate. Typically, developers that use OpenTelemetry route all spans for the same trace ID to the same collector.\n\nSampling and Google Cloud services\n----------------------------------\n\n| **Note:** Cloud Trace has no role in a component's sampling decision. Instead, Cloud Trace manages a repository for storing distributed tracing information.\n\nEach Google Cloud service makes its own sampling decisions,\nand not all Google Cloud services sample. That is, a service might never send\ndata to Cloud Trace.\n\nWhen sampling is supported by a Google Cloud service, that service typically\nimplements the following:\n\n- A default sample rate.\n- A mechanism to use the parent's sampling decision as a hint as to whether to sample the span.\n- Maximum sampling rate.\n\nTo request that a Google Cloud service add support for sampling,\nuse the [Google Issue Tracker](https://developers.google.com/issue-tracker/guides/access-ui).\n\nWhat's next\n-----------\n\n- For a discussion about how you can pick a sampling strategy by span name,\n see [Jaeger remote sampling](https://www.youtube.com/live/Q2K1rJn67X8?si=q6idOBJkaifykl9g&t=2574).\n\n- We recommend that you review the following open-source documentation to help\n you determine which sampling approach is best for your in-development and\n deployed applications:\n\n - [OpenTelemetry Sampling](https://opentelemetry.io/docs/concepts/sampling/)\n - [OpenTelemetry probability sampling](https://opentelemetry.io/docs/specs/otel/trace/tracestate-probability-sampling/)\n - [OpenTelemetry tail sampling processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/tailsamplingprocessor)\n - [`sampled` flag](https://www.w3.org/TR/trace-context/#sampled-flag)\n- Google Cloud service documentation:\n\n - [Enabling distributed tracing in Apigee](/apigee/docs/api-platform/develop/enabling-distributed-trace)\n - [Using distributed tracing with Cloud Run](/run/docs/trace)\n - [Cloud Endpoints: Trace sampling rate](/endpoints/docs/openapi/tracing#trace_sampling_rate)"]]
