檢測是指產生或收集應用程式執行階段行為相關資料的特定程式碼。在應用程式中,OpenTelemetry 等檢測工具可收集有關語言執行階段、架構或應用程式邏輯的網域特定資訊,然後將這些資料傳送至 Google Cloud 專案或其他目的地。這類資料也稱為遙測資料,包括指標、記錄檔和追蹤記錄。
系統層級指標 (例如 CPU 用量、記憶體用量和磁碟用量) 對於偵測應用程式問題非常有用,但無法提供太多應用程式層級問題的洞察資訊。因為產生的遙測資料會顯示應用程式內部發生的情形,因此檢測工具可協助應用程式產生診斷問題根本原因所需的資料。舉例來說,記錄通常會包含程式的相關背景資訊,例如特定錯誤訊息或堆疊追蹤,以及原始碼中的位置。同樣地,分散式追蹤記錄可協助您瞭解多個服務在處理要求時的互動情形。指標可讓您在應用程式運作不正常時收到通知。
檢測應用程式時,系統會產生遙測資料,並將資料傳送至可儲存及查詢資料的位置。舉例來說,您的檢測程式可能會將遙測資料傳送至 Google Cloud 專案。Google Cloud Observability 中的服務可協助您收集、分析及比對遙測資料。這些預設值可讓您更快上手,例如預設資訊主頁和快訊政策。如要進一步瞭解 Google Cloud Observability,請參閱「 Google Cloud中的觀測功能」。
下圖說明應用程式如何使用檢測功能,產生並傳送遙測資料至儲存系統:
如上圖所示,檢測程式碼位於應用程式程序中,並與應用程式互動以產生遙測資料。然後,檢測架構會將遙測資料匯出至已設定的儲存系統。在圖中,儲存系統就是您的 Google Cloud 專案。
關於廠商中立的檢測架構
即使您只打算將遙測資料傳送至 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"]],["上次更新時間:2025-09-04 (世界標準時間)。"],[],[],null,["# Instrumentation and observability\n\n*Instrumentation* refers to the specific code that generates or collects data\nabout your application's runtime behavior. Inside of your application,\ninstrumentation, such as that provided by OpenTelemetry,\ncan collect domain specific information about the\nlanguage runtime, framework, or application logic, and then send that data\nto a Google Cloud project or to some other destination.\nThis data, which is also known as *telemetry* , includes\n[metrics](/stackdriver/docs#metrics-def), [logs](/stackdriver/docs#logs-def), and\n[traces](/stackdriver/docs#traces-def).\n\nSystem-level metrics such as CPU usage, memory usage, and disk usage are\nvaluable for detecting problems with your application, but they don't provide\nmuch insight into application-level concerns. Instrumentation can help your\napplication generate the data that you need to\ndiagnose the root cause of a problem, because the resulting telemetry shows\nyou what is happening inside of your application.\nFor example, logs often include context about your\nprogram like a specific error message or stacktrace, and the location in\nyour source code. Similarly, distributed traces help you understand how multiple\nservices interact when processing requests. Metrics let you get notified\nwhen your application isn't behaving correctly.\n\nInstrumenting your application involves generating telemetry and sending it\nto where the data can be stored and queried. For example, your instrumentation\nmight send telemetry to a Google Cloud project.\nServices in Google Cloud Observability help you to collect, analyze, and\ncorrelate telemetry data. They also provide built-in defaults to help you get\nstarted faster such as default dashboards and alert policies. For\nmore information about Google Cloud Observability, see\n[Observability in Google Cloud](/stackdriver/docs).\n\nThe following figure illustrates how an application uses instrumentation to\ngenerate and send telemetry to a storage system:\n\nAs illustrated in previous figure, the instrumentation code exists within your\napplication's process and interacts with the application to generate telemetry\ndata. The instrumentation framework then exports your telemetry to a configured\nstorage system. In the figure, the storage system is your Google Cloud project.\n\nAbout vendor-neutral instrumentation frameworks\n-----------------------------------------------\n\nEven if you plan to send telemetry only to Google Cloud, we recommend that you\nuse a vendor-neutral open source instrumentation framework to instrument your\napplications. These types of frameworks have some key benefits:\n\nNo vendor lock-in\n: Vendor-neutral frameworks aren't tied to any particular vendor and they\n provide their own data model for the generated telemetry. Therefore, you\n can send data to multiple vendors, and you usually can change which vendor\n you use without modifying your code.\n\nStandardized procedures for collecting telemetry\n: Well-designed frameworks, such as OpenTelemetry, provide a standardized approach\n to collecting telemetry from applications. You can use the same framework\n for applications written in supported languages. And because the\n framework is standardized, you can collect and compare the telemetry from\n all of your services.\n\nInteroperable libraries\n: Instrumentation frameworks include a rich ecosystem of libraries that\n gather telemetry signals, and these libraries are interoperable.\n For example, OpenTelemetry provides libraries to collect trace data and to\n collect metric data. You can use either library, or both libraries.\n\nGeneral recommendations\n-----------------------\n\nThis section contains general recommendations about how to instrument your\napplication. For guidance that is specific to Google Cloud,\nsee [Choose an instrumentation approach](/stackdriver/docs/instrumentation/choose-approach).\n\nTo collect metrics, we recommend that you use [OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/) or\n[Prometheus](https://prometheus.io):\n\n- OpenTelemetry is an open source project that provides a\n unified framework for application instrumentation. It also provides\n instrumentation libraries for popular libraries.\n OpenTelemetry provides a standalone agent,\n the [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/), that can receive, transform,\n and export telemetry. The\n [OpenTelemetry Collector configuration file](https://opentelemetry.io/docs/collector/configuration/)\n determines the behavior of the OpenTelemetry Collector.\n To send telemetry to an agent or directly to a storage system, use the\n [OpenTelemetry Protocol (OTLP)](https://opentelemetry.io/docs/specs/otlp/).\n\n- Prometheus is a popular open source\n monitoring system. You can use the\n [Prometheus client libraries](https://prometheus.io/docs/instrumenting/clientlibs/) to\n generate metrics from your application, and there is a third-party\n ecosystem of instrumentation libraries for popular frameworks.\n Prometheus clients expose their metrics as an HTTP endpoint that can be\n scraped by an agent.\n\nTo collect traces, we recommend that you use [OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/).\n\nTo collect logs, we recommend that you use a framework which can be\nconfigured to output\n[JSON-structured logs for Cloud Logging](/logging/docs/structured-logging).\nFor writing log data, we recommend the following:\n\n- Go: [`slog`](https://pkg.go.dev/log/slog).\n- Python: [`logging`](https://docs.python.org/3/library/logging.html).\n- JavaScript: [Pino](https://getpino.io/).\n- Java: [SLF4J](https://www.slf4j.org/) with [Log4j2](https://logging.apache.org/log4j/2.x/).\n\nGoogle Cloud solutions\n----------------------\n\nGoogle Cloud Observability provides flexible options for collecting telemetry:\n\n- For code samples that illustrate how to instrument your application to\n send telemetry to Google Cloud, see the following:\n\n - [Sample overview](/stackdriver/docs/instrumentation/setup/sample-overview).\n - [Go instrumentation sample](/stackdriver/docs/instrumentation/setup/go).\n - [Java instrumentation sample](/stackdriver/docs/instrumentation/setup/java).\n - [Node.js instrumentation sample](/stackdriver/docs/instrumentation/setup/nodejs).\n - [Python instrumentation sample](/stackdriver/docs/instrumentation/setup/python).\n- To learn how to collect and view latency data from your applications, see\n [View latency of app requests](/trace/docs/trace-app-latency).\n\n- For information about Google Cloud's fully managed, multi-cloud,\n cross-project solution for Prometheus, see\n [Google Cloud Managed Service for Prometheus](/stackdriver/docs/managed-prometheus).\n\n- For information about how to configure the [Ops Agent](/stackdriver/docs/solutions/agents/ops-agent),\n see the following documents:\n\n - [Collect OTLP metrics and traces](/stackdriver/docs/solutions/agents/ops-agent/otlp).\n - [Collect Prometheus metrics](/monitoring/agent/ops-agent/prometheus).\n\nWhat's next\n-----------\n\nFor more information about Google Cloud Observability, see\n[Observability in Google Cloud](/stackdriver/docs)."]]