Google Cloud에서 정의하지 않은 모든 측정항목은 사용자 정의 측정항목에 해당합니다. 여기에는 사용자가 정의할 수 있는 측정항목과 타사 애플리케이션이 정의하는 측정항목이 포함됩니다. 사용자 정의 측정항목을 사용하면 애플리케이션별 데이터 또는 클라이언트 측 시스템 데이터를 캡처할 수 있습니다. Cloud Monitoring에서 수집되는 기본 제공 측정항목을 통해서는 백엔드 지연 시간 또는 디스크 사용량에 대한 정보를 확인할 수 있지만 예를 들어 애플리케이션이 생성한 백그라운드 루틴 수는 알 수 없습니다.
로그 항목의 콘텐츠에 기반한 측정항목을 만들 수도 있습니다. 로그 기반 측정항목은 사용자 정의 측정항목의 클래스이지만 Cloud Logging에서 만들어야 합니다. 로그 기반 측정항목에 대한 자세한 내용은 로그 기반 측정항목 개요를 참고하세요.
사용자 정의 측정항목을 커스텀 측정항목 또는 애플리케이션별 측정항목이라고도 합니다. 이러한 측정항목을 사용하면 사용자 또는 타사 애플리케이션이 기본 제공 Cloud Monitoring 측정항목에서 정의하고 수집할 수 없는 정보를 정의하고 수집할 수 있습니다. 라이브러리에서 제공하는 API로 코드를 사용하여 이러한 측정항목을 캡처한 다음 Cloud Monitoring과 같은 백엔드 애플리케이션에 측정항목을 전송합니다.
Cloud Monitoring API를 직접 사용하여 로그 기반 측정항목을 제외한 사용자 정의 측정항목을 만들 수 있습니다. 하지만 OpenTelemetry를 사용하는 것이 좋습니다. 사용자 정의 측정항목을 만드는 방법은 다음 문서를 참조하세요.
OTLP 측정항목 및 trace 수집은 운영 에이전트 및 에이전트의 OpenTelemetry 프로토콜(OTLP) 수신자를 사용하여 OpenTelemetry를 사용하여 계측되고 Compute Engine에서 실행되는 애플리케이션에서 측정항목 및 trace를 수집하는 방법을 설명합니다.
Google Cloud Managed Service for Prometheus에서는 Google Kubernetes Engine 및 Kubernetes에서 실행되는 애플리케이션에서 Prometheus 측정항목을 수집하는 방법을 설명합니다.
Prometheus 측정항목 수집에서는 운영 에이전트를 사용하여 Compute Engine에서 실행되는 애플리케이션에서 Prometheus 측정항목을 수집하는 방법을 설명합니다.
API로 사용자 정의 측정항목 만들기에서는 Cloud Monitoring API를 사용하여 측정항목을 만드는 방법과 해당 측정항목에 측정항목 데이터를 추가하는 방법을 설명합니다. 이 문서에서는 API 탐색기, C#, Go, Java, Node.js, PHP, Python, Ruby 프로그래밍 언어를 사용하는 예시에서 Monitoring API를 사용하는 방법을 설명합니다.
Cloud Run에서 커스텀 측정항목 만들기에서는 Cloud Run 배포에서 OpenTelemetry Collector를 사이드카 에이전트로 사용하는 방법을 보여줍니다.
Cloud Monitoring과 관련하여 기본 제공 측정항목과 같은 사용자 정의 측정항목을 사용할 수 있습니다. 차트를 작성하고, 여기에 경고를 설정하고, 이를 읽거나 모니터링할 수 있습니다. 측정항목 데이터 읽기에 대한 자세한 내용은 다음 문서를 참조하세요.
- 측정항목 및 리소스 유형 나열에서는 사용자 정의 및 기본 제공 측정항목 유형을 나열하고 살펴보는 방법을 설명합니다. 예를 들어 이 문서의 정보를 사용하여 프로젝트의 모든 사용자 정의 측정항목 설명을 나열할 수 있습니다.
- 시계열 데이터 검색에서는 Monitoring API를 사용하여 측정항목에서 시계열 데이터를 검색하는 방법을 설명합니다. 예를 들어 이 문서에서는 API를 사용하여 Google Cloud 프로젝트의 가상 머신(VM) 인스턴스에 대한 CPU 사용률을 가져오는 방법을 설명합니다.
Google Cloud 콘솔에서는 사용자 정의 측정항목의 사용량을 볼 수 있는 전용 페이지를 제공합니다. 이 페이지의 콘텐츠에 대한 자세한 내용은 측정항목 사용량 보기 및 관리를 참고하세요.
사용자 정의 측정항목의 측정항목 설명
각 측정항목 유형에는 측정항목 데이터의 구성 방법을 정의하는 측정항목 설명이 있어야 합니다. 또한 측정항목 설명은 측정항목의 라벨과 측정항목 이름도 정의합니다. 예를 들어 측정항목 목록에는 모든 기본 제공 측정항목 유형에 대한 측정항목 설명이 표시됩니다.
Cloud Monitoring이 사용자가 작성한 측정항목 데이터를 사용하여 측정항목 설명을 만들 수도 있고 사용자가 측정항목 설명을 명시적으로 만든 후 측정항목 데이터를 작성할 수 있습니다. 어느 경우든 측정항목 데이터의 구성 방법을 결정해야 합니다.
설계 예시
단일 머신에서 실행되는 프로그램이 있고 이 프로그램이 보조 프로그램 A
및 B
를 호출한다고 가정해 보겠습니다. A
및 B
가 호출되는 빈도를 계산하려고 합니다. 또한 프로그램 A
가 분당 10회 이상 호출되고 프로그램 B
가 분당 5회 이상 호출되는 경우를 알고 싶습니다. 마지막으로, 단일 Google Cloud 프로젝트가 있고 global
모니터링 리소스에 데이터를 기록한다고 가정해 보겠습니다.
이 예시에서는 사용자 정의 측정항목에 사용할 수 있는 몇 가지 설계에 대해 설명합니다.
두 가지 사용자 정의 측정항목을 사용합니다.
Metric-type-A
는 프로그램A
에 대한 호출 수,Metric-type-B
는 프로그램B
에 대한 호출 수를 카운트합니다. 이 경우Metric-type-A
에 시계열 1개,Metric-type-B
에 시계열이 1개가 있습니다.조건이 2개인 단일 알림 정책을 만들거나 이 데이터 모드를 사용해서 조건이 하나인 2개의 알림 정책을 만들 수 있습니다. 알림 정책은 여러 조건을 지원할 수 있지만, 알림 채널에 대한 구성은 한 가지입니다.
모니터링 중인 활동 간 데이터의 유사성에 관심이 없는 경우 이 모델이 적합할 수 있습니다. 이 예시에서 활동은 프로그램
A
및B
에 대한 호출율입니다.단일 사용자 정의 측정항목을 사용하고 라벨을 사용하여 프로그램 식별자를 저장합니다. 예를 들어 라벨에
A
또는B
값을 저장할 수 있습니다. Monitoring은 각각의 고유한 라벨 조합에 대해 시계열을 만듭니다. 따라서 라벨 값이A
인 시계열과 라벨 값이B
인 시계열이 따로 존재합니다.이전 모델과 마찬가지로 단일 알림 정책 또는 두 개의 알림 정책을 만들 수 있습니다. 하지만 알림 정책의 조건이 더 복잡합니다. 프로그램
A
의 호출 비율이 기준점을 초과하면 이슈를 생성하는 조건은 라벨 값이A
인 데이터 포인트만 포함하는 필터를 사용해야 합니다.이 모델의 장점 가운데 한 가지는 간단하게 비율을 계산할 수 있다는 것입니다. 예를 들어
A
호출로 인한 총량을 확인할 수 있습니다.단일 사용자 정의 측정항목을 사용하여 호출 수를 계산하지만 어떤 프로그램을 호출했는지 기록하는 데 라벨을 사용하지 않습니다. 이 모델에는 두 프로그램의 데이터를 결합하는 단일 시계열이 있습니다. 그러나 두 프로그램의 데이터를 분리할 수 없으므로 목표를 충족하는 알림 정책을 만들 수 없습니다.
처음 두 가지 설계는 데이터 분석 요구사항을 충족시켜 주지만, 마지막 설계는 그렇지 않습니다.
자세한 내용은 사용자 정의 측정항목 만들기를 참조하세요.
사용자 정의 측정항목 이름
사용자 정의 측정항목을 만들 때 측정항목 유형을 나타내는 문자열 식별자를 정의합니다. 이 문자열은 Google Cloud 프로젝트의 사용자 정의 측정항목에서 고유해야 하며 측정항목을 사용자 정의 측정항목으로 표시하는 프리픽스를 사용해야 합니다. Monitoring의 경우 허용되는 프리픽스는 custom.googleapis.com/
, workload.googleapis.com/
, external.googleapis.com/user
, external.googleapis.com/prometheus
입니다.
프리픽스 다음에 수집하는 항목을 설명하는 이름이 표시됩니다.
사용자 정의 측정항목의 이름을 지정하는 데 권장되는 방법은 측정항목 이름 지정 규칙을 참조하세요.
다음은 측정항목 유형에 대한 두 가지 종류의 식별자 예시입니다.
custom.googleapis.com/cpu_utilization custom.googleapis.com/instance/cpu/utilization
이전 예시에서 custom.googleapis.com
프리픽스는 두 측정항목이 모두 사용자 정의 측정항목임을 나타냅니다. 두 가지 예시 모두 CPU 사용률을 측정하는 측정항목에 사용되지만 다른 조직 모델이 사용됩니다. 사용자 정의 측정항목이 많을 것으로 예상하는 경우 두 번째 예시에 사용되는 것과 같은 계층적 이름 지정 구조를 사용하는 것이 좋습니다.
모든 측정항목 유형에는 리소스 이름이라는 서비스 전체에서 고유한 식별자가 있습니다. 측정항목 유형의 리소스 이름 형식은 다음과 같습니다.
projects/PROJECT_ID/metricDescriptors/METRIC_TYPE
여기서 METRIC_TYPE
은 측정항목 유형의 문자열 식별자입니다.
이전 측정항목 예시가 my-project-id
프로젝트에 생성된 경우 이러한 측정항목의 리소스 이름은 다음과 같습니다.
projects/my-project-id/metricDescriptors/custom.googleapis.com/cpu_utilization projects/my-project-id/metricDescriptors/custom.googleapis.com/instance/cpu/utilization
이름 또는 유형 측정항목 설명에서 name
필드는 측정항목 유형의 리소스 이름을 저장하고 type
필드는 METRIC_TYPE
문자열을 저장합니다.
사용자 정의 측정항목의 모니터링 리소스 유형
시계열에 데이터를 쓸 때는 데이터의 출처를 명시해야 합니다. 데이터 소스를 지정하려면 데이터가 시작된 위치를 나타내는 모니터링 리소스 유형을 선택한 후 이를 사용해서 특정 원점을 설명합니다. 모니터링 리소스는 측정항목 유형에 포함되지 않습니다. 대신 데이터를 기록하는 시계열에 측정항목 유형에 대한 참조 및 모니터링 리소스에 대한 참조가 포함됩니다. 측정항목 유형은 데이터를 설명하지만 모니터링 리소스는 데이터가 시작된 위치를 설명합니다.
측정항목 설명을 만들기 전에 모니터링 리소스를 고려하세요. 사용 중인 모니터링 리소스 유형은 측정항목 설명에 포함해야 하는 라벨에 영향을 줍니다. 예를 들어 Compute Engine VM 리소스에는 프로젝트 ID, 인스턴스 ID, 인스턴스 영역에 대한 라벨이 포함됩니다. 따라서 Compute Engine VM 리소스에 대해 측정항목을 작성하려는 경우 리소스 라벨에 인스턴스 ID가 포함되므로, 측정항목 설명에 인스턴스 ID 라벨이 필요하지 않습니다.
각 측정항목의 데이터 포인트는 모니터링 리소스 객체와 연결되어야 합니다. 다른 모니터링 리소스 객체의 요소는 다른 시계열에 유지됩니다.
사용자 정의 측정항목과 함께 다음 모니터링 리소스 유형 중 하나를 사용해야 합니다.
aws_ec2_instance
: Amazon EC2 인스턴스dataflow_job
: Dataflow 작업gae_instance
: App Engine 인스턴스gce_instance
: Compute Engine 인스턴스generic_node
: 사용자 지정 컴퓨팅 노드generic_task
: 사용자 정의 작업gke_container
: GKE 컨테이너 인스턴스global
: 달리 적합한 리소스 유형이 없다면 이 리소스를 사용합니다. 대부분의 사용 사례에서는global
보다generic_node
또는generic_task
를 선택하는 것이 낫습니다.k8s_cluster
: Kubernetes 클러스터k8s_container
: Kubernetes 컨테이너k8s_node
: Kubernetes 노드k8s_pod
: Kubernetes 포드
애플리케이션 코드가 실행되는 물리적 리소스를 나타내는 모니터링 리소스 객체를 사용하는 것이 일반적입니다. 이 방식의 장점은 다음과 같습니다.
- 단일 리소스 유형을 사용할 때보다 성능이 향상됩니다.
- 동일한 시계열에 작성된 여러 프로세스로 인해 데이터의 순서가 잘못되는 현상을 방지합니다.
- 사용자 정의 측정항목 데이터를 동일 리소스의 다른 측정항목 데이터와 그룹으로 묶을 수 있습니다.
global
및 일반 리소스
generic_task
와 generic_node
리소스 유형은 좀 더 적합한 특정 리소스 유형이 없는 상황에서 유용합니다.
generic_task
유형은 애플리케이션 등의 작업과 같은 리소스를 정의할 때 유용합니다. generic_node
유형은 가상 머신 등 노드와 같은 리소스를 정의할 때 유용합니다. 두 generic_*
유형에는 고유한 리소스 객체를 정의할 때 사용할 수 있는 공통 라벨이 여러 개 있으므로, 집계 및 축소를 위한 측정항목 필터에서 이들을 간편하게 사용할 수 있습니다.
반대로 global
리소스 유형에는 project_id
라벨만 있습니다.
프로젝트에 측정항목 소스가 여러 개 있는 경우, 동일한 global
리소스 객체를 사용하면 측정항목 데이터의 충돌 및 덮어쓰기가 발생할 수 있습니다.
사용자 정의 측정항목을 지원하는 API 메서드
다음 표에서는 Monitoring API에서 사용자 정의 측정항목을 지원하는 메서드와 기본 제공 측정항목을 지원하는 메서드를 보여줍니다.
Monitoring API 메서드 | 사용자 정의 측정항목과 함께 사용 |
기본 제공 측정항목과 함께 사용 |
---|---|---|
monitoredResourceDescriptors.get | 예 | 예 |
monitoredResourceDescriptors.list | 예 | 예 |
metricDescriptors.get | 예 | 예 |
metricDescriptors.list | 예 | 예 |
timeSeries.list | 예 | 예 |
timeSeries.create | 예 | |
metricDescriptors.create | 예 | |
metricDescriptors.delete | 예 |
제한 및 지연 시간
사용자 정의 측정항목 및 데이터 보관과 관련된 제한사항은 할당량 및 한도를 참조하세요.
측정항목 데이터를 보관 기간보다 오래 보관하려면 Cloud Storage 또는 BigQuery와 같은 다른 위치로 데이터를 수동으로 복사해야 합니다.
사용자 정의 측정항목에 데이터를 쓸 때 발생하는 지연 시간에 대한 자세한 내용은 측정항목 데이터의 지연 시간을 참조하세요.
다음 단계
- Google Cloud Managed Service for Prometheus를 사용하여 Google Kubernetes Engine 및 Kubernetes에서 실행되는 애플리케이션에서 Prometheus 측정항목을 수집합니다.
- Compute Engine에서 실행되는 애플리케이션에서 Prometheus 측정항목을 수집합니다.
- OpenTelemetry를 사용하여 계측되고 Compute Engine에서 실행되는 애플리케이션에서 OTLP 측정항목 및 trace를 수집합니다.
- API로 사용자 정의 측정항목 만들기
- Cloud Monitoring API 소개
- 측정항목, 시계열, 리소스