[[["์ดํดํ๊ธฐ ์ฌ์","easyToUnderstand","thumb-up"],["๋ฌธ์ ๊ฐ ํด๊ฒฐ๋จ","solvedMyProblem","thumb-up"],["๊ธฐํ","otherUp","thumb-up"]],[["์ดํดํ๊ธฐ ์ด๋ ค์","hardToUnderstand","thumb-down"],["์๋ชป๋ ์ ๋ณด ๋๋ ์ํ ์ฝ๋","incorrectInformationOrSampleCode","thumb-down"],["ํ์ํ ์ ๋ณด/์ํ์ด ์์","missingTheInformationSamplesINeed","thumb-down"],["๋ฒ์ญ ๋ฌธ์ ","translationIssue","thumb-down"],["๊ธฐํ","otherDown","thumb-down"]],["์ต์ข ์ ๋ฐ์ดํธ: 2025-09-03(UTC)"],[],[],null,["# Using distributed tracing\n\nIncoming requests to Cloud Run services\nautomatically generate traces that you can view in [Cloud Trace](/trace/docs/overview).\nYou can use these traces to identify sources of any latency issues in your\nimplementation without needing to add further instrumentation in Cloud Trace.\nThe standard W3C trace context propagation header [`traceparent`](https://www.w3.org/TR/trace-context/#traceparent-header) is automatically populated for Cloud Run requests.\n\nHowever, if you do add [additional instrumentation](/trace/docs/setup#instrumenting_tracing_for_applications),\nyou can also use Cloud Trace to measure the time it takes for\nthe request to propagate through each layer in your implementation, for example,\nthe time it takes to complete a database query, receive results from an API\nrequest, or run some complex business logic. Each of these\nlayer-specific time measurements is a \"span\". You can view the traces\nin Cloud Trace as waterfall graphs reflecting the latency values.\n\nBilling charges\n---------------\n\nAutomatically generated traces in Cloud Run, whether sampled or\nforced, do not result in billing charges. However, if you use Cloud Trace libraries and\nadd your own spans by correlating them to Cloud Run provided spans,\nyou will be charged by [Cloud Trace](/stackdriver/pricing#trace-costs).\n\nTrace sampling rate\n-------------------\n\nCloud Run doesn't sample the traces for every request. When used with\nCloud Run, requests are sampled at a maximum rate of\n0.1 requests per second\nfor each instance (or one request every 10 seconds). You can also [force a particular request to be\ntraced](/trace/docs/setup#force-trace). If you force a request to be\ntraced, this request is sampled at a maximum rate of 0.1 second for each\ninstance (or 10 requests per second).\n\nCloud Run does not support configuration of the Cloud Run\nsample rate.\n\nWhen to add instrumentation\n---------------------------\n\nTraces are automatically generated without any instrumentation\nrequired in your service. However, in some cases, you may want to add instrumentation\ncode to your service to take full advantage of the Cloud Trace feature. For example,\nyou need to add instrumentation if you want to:\n\n- Create custom trace spans, for example, to get timing data for how long it takes your service to get work back from the Cloud Translation API.\n- Propagate trace context so Cloud Trace shows the request flow across multiple services as a single request.\n\nTo add instrumentation, refer to [Instrumenting tracing for applications](/trace/docs/setup#instrumenting_tracing_for_applications)\nNote that traces resulting from instrumentation in your service will incur\nstandard [Cloud Trace billing charges](/stackdriver/pricing).\n| **Note:** If you instrument trace and use custom spans, you may want to [add labels to the spans](/trace/docs/trace-labels) to make it easier to filter for them in the Cloud Trace UI.\n\nViewing traces\n--------------\n\nTo learn more, refer to the documentation on\n[viewing traces](/trace/docs/finding-traces)."]]
