[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-19。"],[],[],null,["Cloud Trace, a distributed tracing system for\nGoogle Cloud, helps you\nunderstand how long it takes your application to handle incoming\nrequests from users or other applications, and how long it takes to complete\noperations like RPC calls performed when handling the requests.\nTrace can also help you when you are developing a service or\ntroubleshooting a failure. For example, it can help you understand how requests\nare processed in a complicated microservices architecture, and it might help\nyou identify which logs to examine.\n\nBecause Trace receives latency data from some Google Cloud\nservices, such as [App Engine](/appengine/docs), and from\napplications instrumented with the [Cloud Trace API](/trace/api),\nit can help you answer the following questions:\n\n- How long does it take my application to handle a given request?\n- Why is it taking my application so long to handle a request?\n- Why do some of my requests take longer than others?\n- What is the overall latency of requests to my application?\n- Has latency for my application increased or decreased over time?\n- What can I do to reduce application latency?\n- What are my application's dependencies?\n\nIf you're curious about how you can use Trace to help you manage\nyour applications, then read the blog\n[Troubleshooting distributed applications: Using traces and logs together for root-cause analysis](https://cloud.google.com/blog/products/devops-sre/using-cloud-trace-and-cloud-logging-for-root-cause-analysis).\n\nFor information about profiling your application,\nsee [Cloud Profiler](/profiler).\n\nEnvironment support\n\nTrace runs on Linux in the following environments:\n\n- [Compute Engine](/compute/docs)\n- [Google Kubernetes Engine (GKE)](/kubernetes-engine/docs)\n- [Apigee](/apigee/docs/api-platform/develop/enabling-distributed-trace) (Public Preview)\n- [App Engine flexible environment](/appengine/docs/flexible)\n- [App Engine standard environment](/appengine/docs/standard)\n- [Cloud Run](/run/docs/trace)\n- [Cloud Service Mesh](/service-mesh/docs/observability/accessing-traces)\n- [Cloud SQL query insights](/sql/docs/mysql/using-query-insights)\n- Non-Google Cloud environments\n\nTrace provides client libraries for instrumenting your\napplication to capture trace information. For per-language setup instructions,\nsee [Instrument for Trace](/trace/docs/setup).\n\nConfigurations with automatic tracing\n\nSome configurations result in automatic capture of trace data:\n\n- App Engine standard environment\n\n Java 8, Python 2, and PHP 5 applications don't need to use the\n Trace client libraries. These runtimes automatically send\n latency data to Trace for requests to application URIs.\n The requests include latency data for round-trip RPC calls to\n App Engine services. Trace works with all\n App Engine Admin APIs, with the exception of Cloud SQL.\n- Cloud Run functions and Cloud Run\n\n For incoming and outgoing HTTP requests, latency data is automatically\n sent to Trace.\n\nLanguage support **Note:** You can instrument your application so that it collects application-specific information. Several open-source instrumentation frameworks let you collect metrics, logs, and traces from your application and send that data to any vendor, including Google Cloud. To instrument your application, we recommend that you use a vendor-neutral instrumentation framework that is open source, such as [OpenTelemetry](https://opentelemetry.io/), instead of vendor- and product-specific APIs or client libraries.\n|\n| \u003cbr /\u003e\n|\n| For information about instrumenting your applications by using\n| vendor-neutral instrumentation frameworks, see\n| [Instrumentation and observability](/stackdriver/docs/instrumentation/overview).\n\nThe following table summarizes the availability of Trace\nclient libraries and of [OpenTelemetry](https://opentelemetry.io/)\nlibraries for which there is an exporter to Trace.\n\n| Language | Client library available | OpenTelemetry lib/exporter available |\n|-----------------------------------------------|--------------------------|--------------------------------------|\n| [C++](/trace/docs/setup/cpp-ot) | Yes | Yes |\n| C# ASP.NET Core | Yes | No |\n| C# ASP.NET | Yes | No |\n| [Go](/trace/docs/setup/go-ot) | Yes | Yes |\n| [Java](/trace/docs/setup/java-ot) | Yes | Yes |\n| [Node.js](/trace/docs/setup/nodejs-ot) | Yes | Yes |\n| [PHP](/php/docs/reference/cloud-trace/latest) | Yes | No |\n| [Python](/trace/docs/setup/python-ot) | Yes | Yes |\n| Ruby | Yes | Yes |\n\n[OpenTelemetry](https://opentelemetry.io/)\nlibraries are simpler to use than the Trace client libraries\nbecause they hide some of the complexity of the corresponding\nTrace API. For instrumentation recommendations, see\n[Choose an instrumentation approach](/stackdriver/docs/instrumentation/choose-approach).\n\nComponents\n\nTrace consists of a tracing client, which collects *traces* and\nsends them to your Google Cloud project. You can then use the\nGoogle Cloud console to view and analyze the data collected by the agent.\nFor information about the data model, see\n[Traces and spans](/trace/docs/traces-and-spans).\n\nTracing client\n\nIf an OpenTelemetry library is [available for your programming\nlanguage](#language_support), you can simplify the process of creating and\nsending trace data by using\n[OpenTelemetry](https://opentelemetry.io/).\nIn addition to being simpler to use, OpenTelemetry\nimplements batching which might improve performance.\n\nIf an OpenTelemetry library doesn't exist, then instrument your code by\nimporting the Trace SDK library and by using the Cloud Trace API.\nThe Cloud Trace API sends trace data to your Google Cloud project.\n\nTracing interface\n\nYou can view and analyze your trace data\nin near real-time in the Trace interface.\n\nThe **Trace Explorer** page displays aggregate information about\nyour trace data and lets you examine individual\ntraces in detail. The aggregated latency data is shown on a heatmap, which\nyou can explore with your pointer. To restrict which data is displayed, you\ncan add filters. This page also lets you view and explore individual spans and\ntraces:\n\n- For information about how to view trace data stored in multiple projects, see [Create and manage trace scope](/trace/docs/trace-scope/create-and-manage).\n- For information about filtering and viewing your trace data, see [Find and explore traces](/trace/docs/finding-traces).\n\nVPC Service Controls support\n\nTrace is a VPC Service Controls supported service. The\nTrace service name is `cloudtrace.googleapis.com`. Any\nVPC Service Controls restrictions that you create for the\nTrace service apply only to that service. Those restrictions\ndon't apply to any other services, including those like the\n[`telemetry.googleapis.com` service](/stackdriver/docs/reference/telemetry/overview),\nwhich can also ingest trace data.\n\nFor more information, see the following:\n\n- [VPC Service Controls documentation](/vpc-service-controls/docs).\n- [Supported products and limitations](/vpc-service-controls/docs/supported-products).\n\nPricing\n\nTo learn about pricing for Cloud Trace, see the [Google Cloud Observability pricing](https://cloud.google.com/stackdriver/pricing) page.\n\nWhat's next\n\n- Try the [Quickstart](/trace/docs/trace-app-latency).\n\n- For information about quotas and limits, see\n [Quotas and limits](/trace/docs/quotas).\n\n- Read our resources about [DevOps](/devops) and explore the\n [DevOps Research and Assessment](https://dora.dev/) research program."]]
