계측은 애플리케이션의 런타임 동작에 대한 데이터를 생성하거나 수집하는 특정 코드를 의미합니다. 애플리케이션 내에서 OpenTelemetry에서 제공하는 것과 같은 계측은 언어 런타임, 프레임워크 또는 애플리케이션 로직에 대한 도메인별 정보를 수집한 다음, 해당 데이터를 Google Cloud 프로젝트나 다른 대상으로 전송할 수 있습니다.
원격 분석이라고도 하는 이 데이터는 측정항목, 로그, trace를 포함합니다.
CPU 사용량, 메모리 사용량, 디스크 사용량과 같은 시스템 수준 측정항목은 애플리케이션 문제를 감지하는 데 유용하지만 애플리케이션 수준의 문제에 대해 유용한 정보를 제공하지는 않습니다. 계측을 통해 애플리케이션이 문제의 근본 원인을 진단하는 데 필요한 데이터를 생성할 수 있습니다. 원격 분석 결과를 통해 애플리케이션 내부에서 발생하는 상황을 알 수 있기 때문입니다.
예를 들어 로그에는 특정 오류 메시지 또는 스택 추적과 같은 프로그램 관련 컨텍스트와 소스 코드의 위치가 포함되는 경우가 많습니다. 마찬가지로 분산 trace는 요청을 처리할 때 여러 서비스가 상호작용하는 방식을 이해하는 데 도움이 됩니다. 측정항목은 애플리케이션이 정상적으로 작동하지 않을 때 해당 사실을 알려줍니다.
애플리케이션을 계측하려면 원격 분석을 생성하고 데이터를 저장 및 쿼리할 수 있는 위치로 전송합니다. 예를 들어 계측은 Google Cloud 프로젝트에 원격 분석을 보낼 수 있습니다.
Google Cloud Observability의 서비스는 원격 분석 데이터를 수집, 분석하고 상관관계를 파악하는 데 도움이 됩니다. 또한 빠르게 시작할 수 있도록 기본 대시보드 및 알림 정책과 같은 기본값을 제공합니다. Google Cloud Observability에 대한 자세한 내용은 Google Cloud의 모니터링 가능성을 참조하세요.
다음 그림은 애플리케이션이 계측을 사용하여 원격 분석을 생성하고 스토리지 시스템으로 전송하는 방법을 보여줍니다.
앞의 그림과 같이 계측 코드는 애플리케이션의 프로세스 내에 존재하며 애플리케이션과 상호작용하여 원격 분석 데이터를 생성합니다. 그런 다음, 계측 프레임워크는 구성된 스토리지 시스템으로 원격 분석을 내보냅니다. 그림에서 스토리지 시스템은 Google Cloud 프로젝트입니다.
공급업체 중립적인 계측 프레임워크 정보
Google Cloud에만 원격 분석을 전송하려는 경우에도 공급업체 중립적인 오픈소스 계측 프레임워크를 사용하여 애플리케이션을 계측하는 것이 좋습니다. 이러한 유형의 프레임워크에는 몇 가지 주요 이점이 있습니다.
공급업체 종속 없음
공급업체 중립적인 프레임워크는 특정 공급업체에 한정되지 않으며 생성된 원격 분석에 대해 자체 데이터 모델을 제공합니다. 따라서 여러 공급업체에 데이터를 보낼 수 있으며 일반적으로 코드 수정 없이도 공급업체를 변경할 수 있습니다.
원격 분석 수집을 위한 표준화된 절차
OpenTelemetry와 같이 잘 설계된 프레임워크는 애플리케이션에서 원격 분석을 수집하는 표준화된 접근 방식을 제공합니다. 지원되는 언어로 작성된 애플리케이션에 동일한 프레임워크를 사용할 수 있습니다. 또한 프레임워크가 표준화되므로 모든 서비스에서 원격 분석을 수집하고 비교할 수 있습니다.
상호 운용이 가능한 라이브러리
계측 프레임워크는 원격 분석 신호를 수집하는 풍부한 라이브러리 생태계를 포함하며 라이브러리의 상호 운용이 가능합니다.
예를 들어 OpenTelemetry는 trace 데이터를 수집하는 라이브러리와 측정항목 데이터를 수집하는 라이브러리를 제공합니다. 두 라이브러리 중 하나를 사용하거나 모두 사용할 수 있습니다.
일반 권장사항
이 섹션에는 애플리케이션을 계측하는 방법에 대한 일반적인 권장사항이 포함되어 있습니다. Google Cloud에 관한 안내는 계측 방식 선택을 참조하세요.
OpenTelemetry는 애플리케이션 계측을 위한 통합 프레임워크를 제공하는 오픈소스 프로젝트입니다. 또한 널리 사용되는 라이브러리에 대한 계측 라이브러리를 제공합니다.
OpenTelemetry는 원격 분석을 수신 및 변환하고 내보낼 수 있는 독립형 에이전트인 OpenTelemetry Collector를 제공합니다. OpenTelemetry Collector 구성 파일은 OpenTelemetry Collector의 동작을 결정합니다.
원격 분석을 에이전트에 전송하거나 스토리지 시스템에 직접 전송하려면 OpenTelemetry 프로토콜(OTLP)을 사용합니다.
Prometheus는 인기 있는 오픈소스 모니터링 시스템입니다. Prometheus 클라이언트 라이브러리를 사용하여 애플리케이션에서 측정항목을 생성할 수 있으며, 널리 사용되는 프레임워크에 대한 서드 파티 계측 라이브러리 생태계가 있습니다.
Prometheus 클라이언트는 자체 측정항목을 에이전트가 스크래핑할 수 있는 HTTP 엔드포인트로 노출합니다.
[[["이해하기 쉬움","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(UTC)"],[],[],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)."]]
