Google Cloud Observability 가격 책정

Google Cloud Observability의 가격 책정을 통해 사용량과 지출을 관리할 수 있습니다. Google Cloud Observability 제품의 가격은 데이터 볼륨 또는 사용량에 따라 책정됩니다. 무료 데이터 사용 할당량을 사용하여 선불 요금이나 약정 없이 시작할 수 있습니다.

다음 표에는 Cloud Logging, Cloud Monitoring, Cloud Trace의 가격 책정 정보가 요약되어 있습니다.

Cloud Logging 가격 책정 요약

Cloud Monitoring 가격 책정 요약

Cloud Trace 가격 책정 요약

Google Cloud Observability 제품 비용에 관한 자세한 내용은 이 페이지의 다음 섹션을 참조하세요.

• Cloud Logging
• Cloud Monitoring
• Error Reporting
• Cloud Profiler
• Cloud Trace

GKE Enterprise 가격 책정에 대한 자세한 내용은 GKE Enterprise를 참조하세요.

사용량 보기

현재 사용량을 보려면 Google Cloud 콘솔의 Cloud Billing 보고서 페이지로 이동합니다.

Cloud Billing으로 이동

가격 계산기를 사용하여 현재 사용량 데이터를 기준으로 청구액을 예상할 수 있습니다.

예를 들어 매월 모든 Compute Engine VM 인스턴스에서 10GiB의 요금이 부과되는 로그와 20MiB의 요금이 부과되는 측정항목을 생성하는 구성의 경우 가격 계산기를 사용하여 Cloud Monitoring 및 Cloud Logging의 예상 비용을 확인할 수 있습니다.

결제 알림 구성

청구 가능 또는 예측 요금이 예산을 초과하는 경우 알림을 받으려면 Google Cloud 콘솔의 예산 및 알림 페이지를 사용하여 알림을 만듭니다.

1. Google Cloud 콘솔에서 Billing 페이지로 이동합니다.

   결제로 이동

   검색창을 사용하여 이 페이지를 찾을 수도 있습니다.

   Cloud Billing 계정이 두 개 이상 있으면 다음 중 하나를 수행합니다.

   • 현재 프로젝트의 Cloud Billing을 관리하려면 연결된 결제 계정으로 이동을 선택합니다.
   • 다른 Cloud Billing 계정을 찾으려면 결제 계정 관리를 선택하고 예산을 설정할 계정을 선택합니다.
2. 결제 탐색 메뉴에서 예산 및 알림을 선택합니다.
3. add_box 예산 만들기를 클릭합니다.
4. 예산 대화상자를 작성합니다. 이 대화상자에서 Google Cloud 프로젝트 및 제품을 선택한 다음 이 조합에 대한 예산을 만듭니다. 기본적으로 예산의 50%, 90%, 100%에 도달하면 알림이 전송됩니다. 자세한 문서는 예산 및 예산 알림 설정을 참조하세요.

Cloud Logging

로그 버킷은 로그 데이터를 저장하는 Logging 컨테이너입니다. Logging은 _Default 로그 버킷과 사용자 정의 로그 버킷에 저장된 로그 데이터의 볼륨에 대해 요금을 부과합니다. 볼륨이 월별 무료 할당량을 초과하는 경우 배포되지 않은 네트워크 로그와 배포된 네트워크 로그에 가격이 적용됩니다.

_Default 로그 버킷 및 사용자 정의 로그 버킷의 경우 Logging은 로그가 기본 보관 기간인 30일보다 오래 보관될 때도 요금을 청구합니다.

로그를 라우팅하거나, Cloud Logging API를 사용하거나, 로그 범위를 구성하거나, _Required 로그 버킷(400일의 고정 보관 기간이 적용됨)에 저장된 로그에 대해 Logging에서 부과하는 추가 요금은 없습니다.

이 섹션에서는 다음 주제에 관한 정보를 제공합니다.

• Cloud Logging 스토리지 모델
• 스토리지 가격 책정
• 보관 가격 책정
• Vended 네트워크 로그
• 로그 스토리지 줄이기
• 로그 기반 측정항목 가격 책정
• 수집된 월별 로그 바이트에 대한 알림 정책 만들기

가격 책정 정보의 요약은 Cloud Logging 가격 책정 요약을 참조하세요.

데이터 보관 기간 등 Logging 사용 시 적용되는 한도는 할당량 및 한도를 참조하세요.

Cloud Logging 사용량 데이터를 보고 이해하려면 예상 청구액 확인을 참조하세요.

Cloud Logging 스토리지 모델

Google Cloud 프로젝트마다 Logging은 두 개의 로그 버킷 _Required과 _Default을 자동으로 만듭니다. 이 두 버킷에 대해 Logging은 각각 이름이 _Required 및 _Default인 로그 싱크를 자동으로 만듭니다. 이 싱크는 상응하는 이름이 지정된 로그 버킷으로 로그를 라우팅합니다. _Required 싱크는 사용 중지하거나 수정할 수 없습니다. _Default 싱크를 중지하거나 수정하여 _Default 버킷에 새 로그를 저장하지 못하도록 할 수 있습니다.

Google Cloud 프로젝트에서 사용자 정의 로그 버킷을 만들 수 있습니다. 또한 Google Cloud 조직의 Google Cloud 프로젝트에서도 모든 조합의 로그를 이러한 로그 버킷으로 라우팅하도록 싱크를 구성할 수 있습니다.

_Default 로그 버킷과 사용자 정의 로그 버킷의 경우 커스텀 보관 기간을 구성할 수 있습니다.

로그 애널리틱스를 사용하도록 로그 버킷을 업그레이드할 수 있습니다. 로그 애널리틱스를 사용하도록 로그 버킷을 업그레이드하는 것은 무료입니다.

Cloud Logging 버킷 및 싱크에 대한 자세한 내용은 라우팅 및 스토리지 개요를 참조하세요.

스토리지 가격 책정

Logging은 _Required 버킷에 저장된 로그에 대해 요금을 부과하지 않습니다. _Required 버킷을 삭제하거나 _Required 싱크를 수정할 수는 없습니다. _Required 버킷은 다음 로그를 저장합니다.

• 관리 활동 감사 로그
• 시스템 이벤트 감사 로그
• Google Workspace 관리자 감사 로그
• Enterprise 그룹스 감사 로그
• 로그인 감사 로그
• 액세스 투명성 로그 액세스 투명성 로그 사용 설정에 대한 자세한 내용은 액세스 투명성 로그 문서를 참조하세요.

Logging은 총 볼륨이 월별 무료 할당량을 초과하면 _Default 로그 버킷 및 사용자 정의 로그 버킷에 저장된 로그 데이터의 사전 색인이 생성된 볼륨에 대해 요금을 청구합니다. _Default 로그 버킷 또는 사용자 정의 로그 버킷에 쓰기가 모두 스토리지 할당량에 반영됩니다. 예를 들어 하나의 로그 항목을 3개의 로그 버킷으로 라우팅하는 싱크가 있는 경우 해당 로그 항목은 3번 저장됩니다.

보관 가격 책정

다음 표에는 로그 버킷에 저장된 로그의 데이터 보관 기간이 나와 있습니다.

로그가 기본 보관 기간보다 오래 보관되면 Logging은 보관 비용을 청구합니다. _Required 로그 버킷의 보관 기간은 구성할 수 없습니다. 로그가 로그 버킷의 기본 보관 기간 동안에만 저장되는 경우에는 보관 비용이 없습니다.

로그 버킷의 보관 기간을 줄이면 만료된 로그가 삭제되지 않는 7일의 유예 기간이 적용됩니다. 만료된 로그는 쿼리하거나 볼 수 없습니다. 그러나 이 7일 동안 로그 버킷의 보관 기간을 연장하여 전체 액세스 권한을 복원할 수 있습니다. 유예 기간 동안 저장된 로그는 보관 비용에 반영됩니다.

로그 항목을 여러 로그 버킷으로 라우팅하면 스토리지 및 보관 비용이 여러 번 청구될 수 있습니다. 예를 들어 로그 항목을 _Default 로그 버킷과 사용자 정의 로그 버킷으로 라우팅한다고 가정해 보겠습니다. 또한 두 버킷 모두에 대해 30일 이상의 커스텀 보관 기간을 구성한다고 가정해 보겠습니다. 이 구성의 경우 스토리지 요금 2건과 보관 요금 2건이 청구됩니다.

Vended 네트워크 로그

발신 네트워크 로그는 로그 생성을 구성할 때만 사용할 수 있습니다. 전송된 네트워크 로그를 생성하는 서비스는 로그 생성 요금을 청구합니다. 이러한 로그를 로그 버킷에 저장하거나 지원되는 다른 대상으로 라우팅하면 Cloud Logging 또는 대상 위치에서도 요금이 부과됩니다. 로그 생성 비용에 대한 자세한 내용은 네트워크 원격 분석 가격 책정을 참조하세요.

전송된 네트워크 로그를 사용 설정하는 방법은 VPC 흐름 로그 구성, 방화벽 규칙 로깅 사용, Cloud NAT: 로그 및 측정항목을 참조하세요.

전송된 네트워크 로그를 찾으려면 로그 탐색기에서 다음 로그 이름으로 필터링합니다.

• projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows
• projects/PROJECT_ID/logs/compute.googleapis.com%2Ffirewall
• projects/PROJECT_ID/logs/compute.googleapis.com%2Fnat_flows
• projects/PROJECT_ID/logs/networkmanagement.googleapis.com%2Fvpc_flows

로그 스토리지 줄이기

Cloud Logging 스토리지 비용을 줄이려면 로그 싱크에 제외 필터를 구성하여 특정 로그가 라우팅되지 않도록 제외합니다. 제외 필터는 필터와 일치하는 모든 로그 항목을 삭제하거나 로그의 일부만 삭제할 수 있습니다. 로그 항목이 싱크의 제외 필터와 일치하면 싱크는 로그 항목을 대상으로 라우팅하지 않습니다. 제외된 로그 항목은 스토리지 할당량에 포함되지 않습니다. 제외 필터 설정에 대한 안내는 로그 제외를 참조하세요.

Cloud Logging 스토리지 비용을 줄이는 또 다른 옵션은 Cloud Logging에서 지원되는 대상으로 로그를 라우팅하는 것입니다. Cloud Logging은 로그를 지원되는 대상으로 라우팅하는 데 요금을 부과하지 않습니다. 하지만 대상에서 로그를 수신하면 요금이 부과될 수 있습니다.

• Cloud Storage 가격 책정
• BigQuery 가격 책정
• Pub/Sub 가격 책정

Cloud Logging에서 로그를 라우팅하는 방법에 대한 자세한 내용은 지원되는 대상으로 로그 라우팅을 참조하세요.

로그 기반 측정항목 가격 책정

시스템 정의 로그 기반 측정항목은 모든 Google Cloud 프로젝트에 제공되며 요금이 부과되지 않습니다.

사용자 정의 로그 기반 측정항목은 Cloud Monitoring 커스텀 측정항목의 클래스이며 요금이 부과됩니다. 가격 세부정보는 청구 가능한 측정항목을 참조하세요.

자세한 내용은 로그 기반 측정항목 개요를 참조하세요.

수집된 월별 로그 바이트에 대한 알림 정책 만들기

로그 버킷에 기록되는 로그 바이트 수가 Cloud Logging의 사용자 정의 한도를 초과할 때 트리거되는 알림 정책을 만들려면 다음 설정을 사용하세요.

Cloud Monitoring

Monitoring은 다음 항목에 대한 요금을 청구합니다.

• 수집된 측정항목 데이터가 월별 무료 측정항목 할당량을 초과하는 경우 수집된 바이트별로 측정된 측정항목입니다.

  요금이 부과되지 않는 측정항목은 할당량 한도로 집계되지 않습니다.

• 수집된 샘플 수로 측정되는 측정항목

• 월별 무료 API 할당량을 초과하는 Cloud Monitoring API 읽기 호출

  Monitoring API 쓰기 호출은 할당량 한도로 집계되지 않습니다.

• 업타임 체크 실행

• 합성 모니터 실행

• 월별 활성 조건 수로 측정된 알림 정책 조건입니다.

• 알림 정책 조건의 쿼리에서 반환된 시계열입니다.

Monitoring에서 수집이란 Monitoring에 시계열을 작성하는 프로세스를 의미합니다. 각 시계열에는 몇 가지 데이터 포인트가 포함됩니다. 이러한 데이터 포인트를 기준으로 수집 요금이 부과됩니다. 가격 정보는 Cloud Monitoring 가격책정을 참조하세요.

이 섹션에서는 다음 정보를 제공합니다.

• 요금이 부과되는 측정항목 및 요금이 부과되지 않는 측정항목의 정의
• 바이트 및 샘플 기반 수집 전략에 관한 설명
• 수집된 바이트를 기준으로 청구되는 측정항목의 가격 책정 예시
• 수집된 샘플에 따라 요금이 청구되는 측정항목의 가격 책정 예시
• 업타임 체크 실행 가격 책정 예시(시행일: 2022년 10월 1일).
• 합성 모니터 실행에 대한 가격 책정 예시(시행일: 2023년 11월 1일).
• 알림 가격 책정 설명 및 예시(시행일: 2025년 4월).

현재 가격 정보는 Cloud Monitoring 가격 책정을 참조하세요.

Monitoring 사용 시 적용되는 한도는 할당량 및 한도를 참조하세요.

현재 사용량을 보려면 다음 중 하나를 수행합니다.

• Google Cloud 콘솔에서 Billing 페이지로 이동합니다.

  결제로 이동

  검색창을 사용하여 이 페이지를 찾을 수도 있습니다.

• Google Cloud 콘솔에서 settings 설정 페이지로 이동합니다.

  설정으로 이동

  검색창을 사용하여 이 페이지를 찾은 경우 부제목이 Monitoring인 결과를 선택합니다.

현재 사용량 데이터를 기준으로 청구액을 예상할 수 있습니다.

요금이 부과되지 않는 측정항목

Google Cloud, GKE Enterprise, Knative의 측정항목 데이터에는 요금이 부과되지 않습니다. 요금이 부과되지 않는 무료 측정항목은 다음과 같습니다.

• Google Cloud 측정항목. 자세한 내용은 각주 2를 참조하세요.
• GKE Enterprise 측정항목. 자세한 내용은 각주 2를 참조하세요.
• Istio 측정항목
• Knative 측정항목
• Google Kubernetes Engine 시스템 측정항목
• agent.googleapis.com/agent/ 측정항목

요금이 부과되는 측정항목

요금이 부과되지 않는 측정항목 섹션에 나열된 측정항목을 제외한 모든 측정항목 데이터는 요금이 부과됩니다. 대부분의 측정항목 수집은 바이트 수로 요금이 청구되지만 일부 측정항목은 샘플 수로 청구됩니다. 이러한 가격 책정 모델은 다음 섹션에서 설명합니다.

수집 비용의 요인은 다음과 같습니다.

• 측정항목에서 수집한 데이터 포인트 유형(스칼라 값 또는 분포 값)

  • 특정 측정항목 유형과 관련된 데이터 유형에 대한 자세한 내용은 측정항목 목록을 참조하세요.
  • 스칼라 및 분포 데이터 유형에 대한 자세한 내용은 값 유형을 참조하세요.

• 시계열에 기록된 데이터 포인트의 수입니다. 이 값은 데이터가 샘플링되는 빈도와 데이터의 카디널리티에 따라 다릅니다. 카디널리티는 측정항목 및 모니터링 리소스 유형의 조합에 대해 생성되는 시계열 수를 결정합니다. 자세한 내용은 카디널리티를 참조하세요.

시계열에 포함된 측정항목 및 리소스 라벨값은 요금에 반영되지 않습니다.

수집된 바이트별로 청구되는 측정항목

다음 측정항목은 청구 가능하며 수집된 바이트 수에 따라 가격이 책정됩니다.

• agent.googleapis.com/agent/ 그룹을 제외한 agent.googleapis.com의 에이전트 측정항목

  2021년 8월 6일부터 agent.googleapis.com/processes/ 측정항목은 청구 가능한 다른 측정항목의 볼륨 요금의 5%로 청구됩니다. 예를 들어 프로세스 측정항목 100MiB 수집은 다른 청구 가능한 측정항목 5MiB 수집과 비용이 동일합니다.³

• 작업 에이전트와 타사 통합의 측정항목: 이러한 측정항목은 workload.googleapis.com/APPLICATION.METRIC 형식의 식별자를 사용하여 Cloud Monitoring에 수집됩니다. 예를 들어 측정항목 유형 workload.googleapis.com/nginx.requests이 이 카테고리에 속합니다.

• 운영 에이전트에 의해 Cloud Monitoring에 workload.googleapis.com 측정항목으로 수집된 OpenTelemetry 프로토콜 (OTLP) 측정항목 이는 구성 옵션입니다. 자세한 내용은 OTLP 측정항목의 수집 형식을 참조하세요.

• 커스텀 측정항목: Cloud Monitoring API 또는 언어별 클라이언트 라이브러리, webstore, OpenTelemetry를 사용하여 전송된 측정항목을 포함하되 이에 국한되지 않습니다.

• 외부 측정항목

• 사용자 정의 로그 기반 측정항목

가격 책정을 위해 수집량을 다음과 같이 계산합니다.

• 스칼라 데이터 유형: 시계열에 쓰인 각 데이터 포인트당 8바이트 (사용자 정의 로그 기반 카운터 측정항목이 이 카테고리에 속합니다.)
• 분포 데이터 유형: 시계열에 기록된 각 데이터 포인트당 80바이트

시계열의 데이터 포인트에 대한 자세한 내용은 시계열: 모니터링 리소스의 데이터를 참조하세요.

수집된 샘플별로 청구되는 측정항목

다음 측정항목은 청구 가능하며 수집된 샘플 수에 따라 가격이 책정됩니다.

• Google Cloud Managed Service for Prometheus의 측정항목, prometheus.googleapis.com 측정항목

가격 책정을 위해 샘플 수를 다음과 같이 계산합니다.

• 스칼라 데이터 유형: 시계열에 쓰인 각 포인트당 1개
• 분포 데이터 유형: 시계열에 쓰인 각 포인트당 2개 + 0이 아닌 히스토그램 버킷당 1개

시계열의 데이터 포인트에 대한 자세한 내용은 시계열: 모니터링 리소스의 데이터를 참조하세요.

수집된 측정항목 알림

수집된 월별 측정항목을 기준으로 알림을 만들 수는 없으나 Cloud Monitoring 비용을 기준으로 알림을 만들 수 있습니다. 자세한 내용은 결제 알림 구성을 참조하세요.

수집된 바이트를 기반으로 한 가격 책정 예시

다음 예시에서는 수집된 바이트에 따라 청구되는 측정항목의 측정항목 데이터의 예상 수집 비용을 구하는 방법을 설명합니다. 이 예시는 계산의 예시를 보여줍니다. 전체적인 예상 금액을 확인하려면 가격 계산기를 사용하세요. 이 도구에 액세스하는 경우 Google Cloud Observability 제품을 사용하여 측정항목, 로깅, trace 데이터를 입력합니다.

기본 시나리오: 매달 몇몇 측정항목 데이터에 대한 쓰기 작업을 수행하는 여러 모니터링 리소스(Compute Engine, Google Kubernetes Engine, App Engine 등)를 사용한다고 가정합니다.

이 시나리오의 변수는 다음과 같습니다.

• 리소스 수
• 측정항목 수
• 측정항목이 Google Cloud 측정항목인지 여부
• 측정항목 데이터의 쓰기 비율

이 섹션의 예시는 2020년 7월 Monitoring 가격을 기준으로 합니다.

일반 배경

다음 가격 책정의 예에서는 수집되는 각 측정항목 데이터 포인트가 double, int64 또는 bool 유형이며 가격 책정을 위해 8바이트로 집계된다고 가정합니다. 한 달은 약 730시간(365일/12개월*24시간), 즉 43,800분입니다.

한 달에 분당 데이터 포인트 1개의 비율로 데이터를 쓰는 측정항목 1개의 경우:

• 총 데이터 포인트: 43,800개
• 수집된 데이터 총량:
  • 350,400바이트(데이터 포인트 43,800개*8바이트)
  • 0.33416748MiB(350,400바이트/1,048,576바이트/MiB)

한 달에 시간당 데이터 포인트 1개 비율로 데이터를 쓰는 측정항목 1개의 경우:

• 총 데이터 포인트: 730개
• 수집된 데이터 총량:
  • 5,840바이트(데이터 포인트 730개*8바이트)
  • 0.005569458MiB(5,840바이트/1,048,576바이트/MiB)

예시

시나리오 1: 리소스 1,000개에서 각각 75개의 측정항목에 대한 쓰기 작업을 수행합니다. 모두 Google Cloud 측정항목으로서 분당 데이터 포인트 1개의 비율로 쓰기 작업이 진행됩니다.

• 월별 수집 데이터: 25,063MiB: 측정항목 1개당 0.33416748MiB*75,000(즉, 리소스 1,000개, 측정항목 75개)
• 대략적인 월별 비용: $0.00(Google Cloud 측정항목은 무료로 포함됨)

시나리오 2: 리소스 1,000개에서 각각 75개의 커스텀 측정항목에 대한 쓰기 작업을 수행합니다. 요금이 부과되는 측정항목으로 분당 데이터 포인트 1개의 비율로 쓰기 작업이 진행됩니다.

• 월별 수집 데이터: 25,063MiB(위 시나리오와 동일)
• 대략적인 월별 비용: $6,427.55

시나리오 3: 리소스 1,000개에서 각각 75개의 커스텀 측정항목에 대한 쓰기 작업을 수행합니다. 요금이 부과되는 측정항목으로 시간당 데이터 포인트 1개의 비율로 쓰기 작업이 진행됩니다.

• 월별 수집 데이터: 418MiB = 측정항목 1개당 0.005569458MiB*75,000
• 대략적인 월별 비용: $69.14

시나리오 4: 리소스 1개에서 500,000개의 측정항목에 대한 쓰기 작업을 수행합니다. 요금이 부과되는 측정항목으로 각각 분당 데이터 포인트 1개의 비율로 쓰기 작업이 진행됩니다.

• 월별 수집 데이터: 167,084MiB: 측정항목 1개당 0.33416748MiB*500,000
• 대략적인 월별 비용: $35,890.98

제어 기능 및 예측 가능성 가격 책정

Managed Service for Prometheus의 가격 책정은 제어 가능하도록 설계되었습니다. 샘플별로 요금이 부과되므로 다음 수단을 사용하여 비용을 관리할 수 있습니다.

• 샘플링 기간: 측정항목 스크랩 기간을 15초에서 60초로 변경하면 카디널리티를 그대로 유지하면서 75% 의 비용 절감 효과를 얻을 수 있습니다. 작업별, 대상별, 전역별로 샘플링 기간을 구성할 수 있습니다.

• 필터링: 필터링을 사용하면 서비스의 로벌 데이터 저장소로 전송되는 샘플 수를 줄일 수 있습니다. 자세한 내용은 내보낸 측정항목 필터링을 참조하세요. Prometheus 스크레이핑 구성에서 측정항목 재라벨 구성 구성을 사용하여 라벨 일치자를 기준으로 수집 시 측정항목을 삭제합니다.

• 카디널리티가 높고 가치가 낮은 데이터를 로컬에 유지합니다. 동일한 scape 구성을 사용하여 관리형 서비스와 함께 표준 Prometheus를 실행할 수 있으며 서비스의 전역 데이터 스토어로 전송할 가치가 없는 데이터를 로컬에 유지할 수 있습니다.

Managed Service for Prometheus의 가격은 예측 가능하도록 설계되었습니다.

• 희소 히스토그램 사용에 따른 불이익은 없습니다. 샘플은 0이 아닌 첫 번째 값에서만 집계되며 이후에는 _n 버킷 값이 _n-1 버킷 값보다 큰 경우에 집계됩니다. 예를 들어 값이 10 10 13 14 14 14인 히스토그램은 첫 번째, 세 번째, 네 번째 버킷에서 샘플 3개가 집계됩니다.

  히스토그램 수와 용도에 따라 가격 책정에서 변경되지 않은 버킷을 제외하면 일반적으로 히스토그램 버킷이 표시하는 절대 수보다 청구를 위해 집계되는 샘플이 20~40% 더 적을 수 있습니다.

• 샘플 단위로 요금이 부과되는 경우 HPA 또는 GKE Autopilot에서 만든 컨테이너와 같이 빠르게 확장되거나 확장되지 않은 선점형 컨테이너 또는 임시 컨테이너 사용에 따른 불이익이 없습니다.

  Managed Service for Prometheus가 측정항목별로 요금을 청구하는 경우 새 컨테이너가 실행될 때마다 한 달 동안의 카디널리티에 대한 비용을 한 번에 지불합니다. 샘플당 가격 책정을 사용하면 컨테이너가 실행 중일 때만 비용을 지불합니다.

알림 쿼리를 포함한 쿼리

Prometheus 기록 규칙이 실행될 때 실행된 쿼리를 포함하여 사용자가 실행한 모든 쿼리는 Cloud Monitoring API 호출을 통해 요금이 청구됩니다. 현재 요율은 Managed Service for Prometheus 가격 책정 또는 Monitoring 가격 책정의 요약 표를 참조하세요.

수집된 샘플을 기반으로 한 가격 책정 예시

다음 예시는 수집된 샘플을 기준으로 요금이 청구되는 측정항목 수집 비용을 추정하는 방법을 설명합니다. 샘플 기반 청구는 Google Cloud Managed Service for Prometheus에 사용됩니다.

결제 데이터를 제공하는 것이 아니라 계산 기법을 보여주기 위한 예시입니다.

기본 시나리오: 매달 몇몇 시계열에 걸쳐 포인트에 대한 쓰기 작업을 수행하는 컨테이너 또는 포드가 몇 개 있습니다. 데이터는 스칼라 값 또는 분포로 구성될 수 있습니다.

이 시나리오의 변수는 다음과 같습니다.

• 컨테이너 또는 포드의 수입니다.
• 시계열의 수
• 데이터가 스칼라 값, 분포 또는 두 가지 모두로 구성되었는지 여부
• 데이터의 쓰기 비율입니다.

샘플 수 계산

가격을 추정하려면 먼저 샘플 수를 계산하는 방법을 알아야 합니다. 값으로 집계되는 샘플 수는 다음에 따라 달라집니다.

• 스칼라 값인지 분포 값인지 여부
• 값이 기록되는 비율

이 섹션에서는 월별 결제 기간에 시계열에 작성된 샘플 수를 추정하는 방법을 설명합니다.

한 달은 약 730시간(365일/12개월 * 24시간), 43,800분, 즉 2,628,000초입니다.

시계열이 스칼라 값을 쓰면 각 값이 샘플 한 개로 집계됩니다. 한 달간 작성된 샘플 수는 값을 쓴 빈도에 따라 달라집니다. 다음 예를 고려하세요.

• 15초마다 기록되는 값의 경우:
  • 쓰기 속도: 값 1개/15초 = 샘플 1개/15초
  • 월별 샘플: 175,200(샘플 1개/15초 * 2,628,000초/월)
• 60초마다 기록되는 값의 경우:
  • 쓰기 속도: 값 1개/60초 = 샘플 1개/60초
  • 월별 샘플: 43,800(샘플 1개/60초 * 2,628,000초/월)

시계열이 분포 값을 쓰면 각 값에 2+n개의 샘플이 포함될 수 있습니다. 여기서 n은 히스토그램의 버킷 수입니다. 한 달간 작성된 샘플 수는 히스토그램의 버킷 수와 값을 쓴 빈도에 따라 달라집니다.

예를 들어 50개 버킷 히스토그램의 각 인스턴스에는 52개의 샘플이 포함될 수 있습니다. 값이 60초마다 한 번씩 작성되면 50개 버킷 히스토그램은 매월 최대 2,277,600개의 샘플을 작성합니다. 히스토그램에 100개의 버킷이 있고 60초마다 한 번씩 작성된 경우 각 히스토그램은 한 달에 샘플 102개와 쓰기 샘플 최대 4,467,600개까지 포함할 수 있습니다.

대부분의 배포 시계열에는 최대 샘플 수보다 적은 수가 포함됩니다. 실제로 히스토그램 버킷의 20~40%는 비어 있습니다. 희소 히스토그램을 사용하는 사용자(예: Istio에서 생성된 사용자)에서 이 비율이 훨씬 더 높습니다.

가격 책정을 위한 샘플을 집계할 때 값이 비어 있지 않은 버킷만 포함됩니다. 히스토그램당 최대 샘플 수는 2+n개입니다 . 버킷의 25%가 비어 있을 경우 예상되는 샘플 수는 히스토그램당 2+0 .75n개입니다. 버킷의 40%가 비어 있을 경우 예상되는 샘플 수는 히스토그램당 2+0 .60n개입니다.

다음 계산 및 요약 표에는 최대 샘플 수와 현실적으로 예상되는 샘플 수가 나와 있습니다.

• 15초마다 기록되는 50개 버킷 히스토그램 값의 경우:

  • 쓰기 속도: 값 1개/15초
  • 최대 샘플 수:
    • 히스토그램당: 52개
    • 월별: 9,110,400(52 * 값 1개/15초 * 2,628,000초/월)
  • 25%가 비어있다고 가정한 예상 샘플:
    • 히스토그램당: 39.5(2+0.75(50) 또는 2+(50-12.5))
    • 월별: 6,920,400(39.5 * 값 1개/15초 * 2,628,000초/월)
  • 40%가 비어있다고 가정한 예상 샘플:
    • 히스토그램당: 32 (2+0.6(50) 또는 2+(50-20))
    • 월별: 5,606,400(32 * 값 1개/15초 * 2,628,000초/월)

• 60초마다 기록되는 50개 버킷 히스토그램 값의 경우:

  • 쓰기 속도: 값 1개/60초
  • 최대 샘플 수:
    • 히스토그램당: 52개
    • 월별: 2,277,600(52 * 값 1개/60초 * 2,628,000초/월)
  • 25%가 비어있다고 가정한 예상 샘플:
    • 히스토그램당: 39.5(2+0.75(50) 또는 2+(50-12.5))
    • 월별: 1,730,100(39.5 * 값 1개/60초 * 2,628,000초/월)
  • 40%가 비어있다고 가정한 예상 샘플:
    • 히스토그램당: 32 (2+0.6(50) 또는 2+(50-20))
    • 월별: 1,401,600(32 * 값 1개/60초 * 2,628,000초/월)

• 15초마다 기록되는 100개 버킷 히스토그램 값의 경우:

  • 쓰기 속도: 값 1개/15초
  • 최대 샘플 수:
    • 히스토그램당: 102개
    • 월별: 17,870,400(102 * 값 1개/15초 * 2,628,000초/월)
  • 25%가 비어있다고 가정한 예상 샘플:
    • 히스토그램당: 77(2+0.75(100) 또는 2+(100-25))
    • 월별: 13,490,400(77 * 값 1개/15초 * 2,628,000초/월)
  • 40%가 비어있다고 가정한 예상 샘플:
    • 히스토그램당: 62(2+0.6(100) 또는 2+(100-40))
    • 월별: 10,862,400(62 * 값 1개/15초 * 2,628,000초/월)

• 60초마다 기록되는 100개 버킷 히스토그램 값의 경우:

  • 쓰기 속도: 값 1개/60초
  • 최대 샘플 수:
    • 히스토그램당: 102개
    • 월별: 4,467,600(102 * 값 1개/60초 * 2,628,000초/월)
  • 25%가 비어있다고 가정한 예상 샘플:
    • 히스토그램당: 77(2+0.75(100) 또는 2+(100-25))
    • 월별: 3,372,600(77 * 값 1개/60초 * 2,628,000초/월)
  • 40%가 비어있다고 가정한 예상 샘플:
    • 히스토그램당: 62(2+0.6(100) 또는 2+(100-40))
    • 월별: 2,715,600(62 * 값 1개/60초 * 2,628,000초/월)

다음은 앞의 정보를 요약한 표입니다.

예시

가격을 추정하려면 한 달간 작성된 샘플 수를 집계하고 가격 책정 값을 적용합니다. 샘플 가격은 다음과 같이 누적된 범위에서 백만 개 단위로 책정됩니다.

이 섹션의 나머지 부분에서는 가능한 시나리오를 살펴봅니다.

시나리오 1: 1,000개의 스칼라 시계열을 작성하는 100개의 컨테이너가 있습니다.

대안 A: 각 시계열이 15초마다(샘플 1개/15초) 작성되는 경우 매월 작성된 샘플 수는 17,520,000,000(샘플 175,200개/월 * 시계열 10,000개 * 컨테이너 100개) 또는 175억 2,000만입니다.

대안 B: 각 시계열이 60초마다(샘플 1개/60초) 작성되는 경우 매월 작성된 샘플 수는 4,380,000,000(샘플 43,800개/월 * 시계열 1,000개 * 컨테이너 100개) 또는 43억 8,000만입니다.

두 경우 모두 샘플이 50,000만 개 미만이므로 첫 번째 비율만 적용됩니다. 다른 요율로는 요금이 청구되지 않습니다.

시나리오 2: 1,000개의 스칼라 시계열을 작성하는 1,000개의 컨테이너가 있습니다.

대안 A: 각 시계열이 15초(샘플 1개/15초)마다 작성되는 경우 매월 작성된 샘플 수는 175,200,000,000,000개 또는 1,752억 개입니다.

• 첫 번째 요율로 처음 500억 개의 샘플에 대한 요금이 청구됩니다.
• 나머지 1,252억 개의 샘플이 두 번째 요율로 청구됩니다.
• 다른 요금으로 청구된 샘플이 없습니다.

대안 B: 각 시계열이 60초(샘플 1개/60초)마다 작성되는 경우 매월 작성된 샘플 수는 43,800,000,000개 또는 438억 개입니다. 이 월별 값은 500억 개 샘플 미만이므로 첫 번째 비율만 적용됩니다.

시나리오 3: 1,000개의 100개 버킷 분포 시계열을 작성하는 100개의 컨테이너가 있습니다. 버킷의 25%가 비어 있을 것으로 예상합니다.

대안 A: 각 시계열이 15초마다(샘플 1개/15초) 작성되는 경우 매월 작성된 샘플 수는 1,349,040,000,000(샘플 13,490,400개/월 * 시계열 1,000개 * 컨테이너 100개) 또는 1조 3490억 4000만입니다.

• 첫 번째 요율로 처음 500억 개의 샘플에 대한 요금이 청구됩니다.
• 다음 2,000억 개의 샘플이 두 번째 요율로 청구됩니다.
• 그다음 2억 5천만 개의 샘플에는 세 번째 요율로 요금이 청구됩니다.
• 나머지 749,040만 개의 샘플은 네 번째 요율로 요금이 청구됩니다.

대안 B: 각 시계열이 60초마다(샘플 1개/60초) 작성되는 경우 매월 작성된 샘플 수는 337,260,000,000(샘플 3,372,600개/월 * 시계열 1,000개 * 컨테이너 100개) 또는 3372억 6,000만입니다.

• 첫 번째 요율로 처음 500억 개의 샘플에 대한 요금이 청구됩니다.
• 다음 2,000억 개의 샘플이 두 번째 요율로 청구됩니다.
• 나머지 872억 6,000만 개의 샘플이 세 번째 요율로 청구됩니다.

시나리오 4: 10,000개의 100개 버킷 분포 시계열을 작성하는 1,000개의 컨테이너가 있습니다. 버킷의 40%가 비어 있을 것으로 예상합니다.

대안 A: 각 시계열이 15초마다(샘플 1개/15초) 작성되는 경우 매월 작성된 샘플 수는 108,624,000,000,000(샘플 10,862,400개/월 * 시계열 10,000개 * 컨테이너 1,000개) 또는 108조 6240억입니다.

• 첫 번째 요율로 처음 500억 개의 샘플에 대한 요금이 청구됩니다.
• 다음 2,000억 개의 샘플이 두 번째 요율로 청구됩니다.
• 그다음 2억 5천만 개의 샘플에는 세 번째 요율로 요금이 청구됩니다.
• 나머지 108,124,000개의 샘플에는 네 번째 요율로 요금이 청구됩니다.

대안 B: 각 시계열이 60초마다(샘플 1개/60초) 작성되는 경우 매월 작성된 샘플 수는 27,156,000,000,000(샘플 2,715,600개/월 * 시계열 10,000개 * 컨테이너 1,000개) 또는 27조 1,560억입니다.

• 첫 번째 요율로 처음 500억 개의 샘플에 대한 요금이 청구됩니다.
• 다음 2,000억 개의 샘플이 두 번째 요율로 청구됩니다.
• 그다음 2억 5천만 개의 샘플에는 세 번째 요율로 요금이 청구됩니다.
• 나머지 26,656,000개의 샘플에는 네 번째 요율로 요금이 청구됩니다.

시나리오 5: 다음과 같이 가정합니다.

• 1,000개의 컨테이너에서 각각 15초마다 1,000개의 스칼라 시간열을 씁니다. 매월 작성된 샘플 수는 175,200,000,000,000개 또는 1,752억 개입니다. (시나리오 2, 대안 A)

• 각각 10,000개의 100개 배포 시계열을 15초마다 작성하는 1,000개의 컨테이너입니다. 버킷의 40%가 비어 있을 것으로 예상합니다. 매월 작성된 샘플 수는 108,624,000,000,000개 또는 108조 6240억 개입니다. (시나리오 4, 대안 A)

월별 총 샘플 수는 108조 7,992억 개(1,752억 개 + 1,086억 2,400만 개)입니다.

• 첫 번째 요율로 처음 500억 개의 샘플에 대한 요금이 청구됩니다.
• 다음 2,000억 개의 샘플이 두 번째 요율로 청구됩니다.
• 그다음 2억 5천만 개의 샘플에는 세 번째 요율로 요금이 청구됩니다.
• 나머지 108,299,200개의 샘플에는 네 번째 요율로 요금이 청구됩니다.

업타임 체크 실행 가격 책정 (시행일: 2022년 10월 1일)

Monitoring은 월별 무료 할당량인 100만 회를 초과하는 업타임 체크의 리전별 실행에 대해 요금을 청구합니다. 3개 리전에서 실행되는 검사는 3번의 실행으로 집계됩니다.

업타임 체크 실행 비용은 실행 1,000회당 $0.30입니다. 요금은 청구서에 '업타임 체크 모니터링'의 SKU 'CA14-D3DE-E67F'로 표시됩니다.

다음 예시에서는 업타임 체크 실행 비용을 예측하는 방법을 보여줍니다. 이 예시는 결제 데이터를 제공하기 위한 것이 아닌 계산 기술을 보여주기 위한 것입니다.

업타임 체크 실행 횟수 계산

업타임 체크 비용을 추정하려면 한 달에 발생하는 리전 실행 수를 알아야 합니다. Monitoring의 요금은 실행 1,000개당 $0.30이며, 월별 무료 할당량은 실행 100만 개입니다.

업타임 체크 비용을 추정하려면 다음 계산을 사용합니다.

(EXECUTIONS_PER_MONTH - 1,000,000) * .0003

각 업타임 체크의 실행 횟수는 다음 구성 선택에 따라 달라집니다.

• 업타임 체크 실행 빈도(1분, 5분, 10분 또는 15분)입니다.

• 업타임 체크가 실행되는 리전의 수입니다.

• 업타임 체크가 구성된 대상 수입니다. 단일 VM에 업타임 체크가 구성된 경우 대상 수는 1입니다. 리소스 그룹에 업타임 체크가 구성된 경우 대상 수는 그룹의 리소스 수입니다.

업타임 체크를 구성할 때 업타임 체크를 위한 위치를 지정하면 각 위치가 하나 이상의 리전에 매핑됩니다. 다음 표에는 업타임 체크의 유효한 위치와 매핑되는 리전이 나와 있습니다.

3개 이상의 리전에서 실행되도록 업타임 체크를 구성해야 합니다.

업타임 체크의 실행 수를 추정하려면 업타임 체크 위치가 적용되는 리전 수를 알아야 합니다.

• ASIA_PACIFIC, EUROPE, SOUTH_AMERICA에는 각각 리전 1개가 포함됩니다.
• USA에는 3개의 리전이 포함되어 있습니다.
• GLOBAL에는 6개의 리전이 포함되어 있습니다.

한 달은 약 730시간(365일 / 12개월 * 24시간) 또는 43,800분입니다.

• USA에서 1분에 한 번 실행되도록 구성된 업타임 체크는 3개 리전에서 실행됩니다. 이 업타임 체크가 단일 VM을 확인하도록 구성된 경우 이 업타임 체크는 한 달에 131,400회(3 * 43,800)회 실행됩니다. 구성원이 10명인 리소스 그룹을 확인하도록 검사가 구성된 경우 업타임 체크는 한 달에 1,314,000회 (10 * 131,400)회 실행됩니다.

• ASIA_PACIFIC, EUROPE, USA에서 1분에 한 번 실행되도록 구성된 업타임 체크는 5개 리전에서 실행됩니다. 단일 대상에 대해 구성된 경우 이 업타임 체크는 한 달에 219,000회 실행됩니다.

다음 표에서는 여러 리전에서 서로 다른 빈도로 실행되도록 구성된 단일 업타임 체크의 시간별 및 월별 실행 횟수를 보여줍니다.

예시

가격을 추정하려면 월별 총 실행 횟수를 결정하고 1,000,000회를 뺍니다. 나머지 실행은 실행 1,000회당 $0.30의 요금이 청구되므로 나머지 실행에 0 .0003을 곱합니다.

(EXECUTIONS_PER_MONTH - 1,000,000) * .0003

시나리오 1: 1분에 한 번씩 VM 1개를 확인하는 USA 위치에 업타임 체크가 1개 있습니다. 이 검사는 3개 리전에서 실행됩니다. 이 검사는 한 달에 131,400회 실행되며 비용은 없습니다.

시나리오 2: 구성원이 10명인 리소스 그룹을 1분마다 한 번씩 확인하는 USA 위치에 업타임 체크가 1번 있습니다. 이 검사는 3개 리전에서 실행됩니다. 이 검사는 한 달에 10 * 131,400회 실행되며 비용은 월 $94.20입니다. 이 시나리오와 시나리오 1의 유일한 차이점은 타겟의 수입니다.

시나리오 3: GLOBAL 업타임 체크가 10번이 있고 각 업타임 체크는 1분에 한 번씩 VM 1개를 확인합니다. 이러한 검사는 6개 리전에서 실행되므로 각 검사는 한 달에 262,800번 실행됩니다 월간 총 실행은 2,628,000회 (10 * 262,800회)입니다. 이 시나리오의 비용은 월 $488.40입니다.

시나리오 4: USA 위치에 5분마다 한 번씩 VM 1개를 확인하는 업타임 체크가 5번 있습니다. 이러한 검사는 3개 리전에서 실행되므로 각 검사는 한 달에 26,280번 실행됩니다. 이 검사 세트의 월별 총 실행은 105,120 (4 * 26,280)입니다.

또한 15분마다 한 번씩 VM 1개를 확인하는 GLOBAL 업타임 체크가 2번 있습니다. 이러한 검사는 6개 리전에서 실행되므로 각 검사는 한 달에 17,520번 실행됩니다. 이 검사 세트의 총 월별 실행은 35,040회 (2 * 17,520)입니다.

총 월별 실행 수는 140,160 (105,120 + 35,040)입니다. 이 시나리오에는 비용이 들지 않습니다.

합성 모니터 실행 가격 책정 (시행일: 2023년 11월 1일)

Cloud Monitoring은 결제 계정당 100개의 실행이라는 월별 무료 할당량을 초과하여 합성 모니터를 실행할 때마다 요금을 청구합니다. 예를 들어 3개의 합성 모니터를 만들고 각 모니터를 5분마다 실행하도록 구성한 경우 월별 총 실행 횟수는 26,784회입니다.

Number of executions per month =  3 synthetic monitors * 1 execution per monitor per 5 minutes *
                                  1440 minutes per day * 31 days per month
                               =  26,784

청구 가능한 실행 수를 확인하려면 총 실행 수에서 무료 할당량을 뺀 다음 결과를 비용을 곱합니다.

알림 가격 책정

2025년 4월부터 Cloud Monitoring에서 알림에 대한 요금을 청구하기 시작합니다. 가격 책정 모델은 다음과 같습니다.

• 알림 정책의 조건마다 월 $1.50
• 측정항목 알림 정책 조건의 쿼리에서 반환된 시계열 1,000,000개당 $0.35

이 섹션에서는 다음 정보를 제공합니다.

• 알림 용어 정의
• 다양한 알림 정책 구성에 따른 요금의 예시
• 알림 정책을 통합하거나 삭제하여 비용 절감을 위한 제안사항
• 알림 정책에 대한 청구 선택 해제에 대한 정보

정의

• 조건: 알림 정책의 조건은 리소스 또는 리소스 그룹이 응답이 필요한 상태에 있는 경우를 나타냅니다.

  • 필터를 사용하여 측정항목 기준 또는 측정항목 부재 쿼리를 만드는 알림 정책은 최대 6개의 조건을 결합할 수 있습니다.
  • 다음 쿼리 유형의 알림 정책에는 조건이 1개만 있을 수 있습니다.
    • Prometheus Query Language (PromQL) 쿼리
    • Monitoring Query Language(MQL)
    • 로그 일치: 로그 기반 알림에 사용됩니다.

  각 조건에는 매월 1.50달러의 요금이 부과됩니다. 조건에 대한 요금이 청구되지 않도록 하려면 알림 정책을 삭제해야 합니다. 정책을 일시중지하거나 사용 중지해도 요금이 청구되지 않습니다.

• 측정항목 및 로그 기반 알림 정책: 로그 일치 조건을 제외한 모든 조건 유형을 사용하는 알림 정책은 측정항목 알림 정책입니다. 측정항목 알림 정책의 조건은 시계열을 반환합니다. 각 실행 기간 동안 측정항목 알림 정책의 조건은 Cloud Monitoring Datastore를 대상으로 쿼리를 실행합니다. 그런 다음 기준을 기준으로 반환된 시계열을 평가하여 알림 정책의 실행 여부를 결정합니다.

  로그 기반 알림 정책은 로그 일치 조건을 사용합니다. 로그 일치 조건은 시계열을 반환하지 않습니다.

• 실행 기간: Cloud Monitoring에서 조건을 실행하는 빈도입니다. 대부분의 조건 유형에서 30초이며 변경할 수 없습니다. PromQL 쿼리를 사용하는 조건에서 이 기간을 설정할 수 있습니다. 자세한 내용은 실행 기간 길이 늘리기(PromQL만 해당)를 참조하세요.

• 반환된 시계열: 실행 기간마다 측정항목 알림 정책은 Cloud Monitoring Datastore를 대상으로 조건 쿼리를 실행합니다. Cloud Monitoring은 각 쿼리에 대한 응답으로 시계열 데이터를 반환합니다. 응답의 각 시계열은 반환된 시계열 1개로 계산됩니다.

  한 달에 반환되는 시계열 수는 다음 세 가지 요소로 결정됩니다.

  • 기본 데이터의 형태 및 범위
  • 조건의 쿼리에 사용하는 필터 및 집계입니다.
  • 실행 기간입니다.

  예를 들어 다음과 같은 구성이 있다고 가정해 보겠습니다.

  • 각 VM이 하나의 서비스에 속하는 가상 머신 (VM) 100개
  • 각 VM은 값이 10개인 라벨이 있는 metric_name 측정항목 1개를 내보냅니다.
  • 총 서비스 5개입니다.

  100개의 VM이 있고 각각 10개의 시계열 (라벨 값당 하나씩)을 생성할 수 있으므로 총 1,000개의 기본 시계열이 있습니다. 또한 각 VM에는 VM이 속한 5개 서비스를 기록하는 메타데이터와 유사한 라벨이 포함됩니다.

  PromQL을 사용하여 다음과 같은 방법으로 알림 정책을 구성할 수 있습니다. 각 구성에 따라 실행 기간별로 반환되는 시계열 수가 달라집니다.

  구성	PromQL 쿼리	기간당 반환되는 시계열
  집계 없음	rate(metric_name[1m])	1,000
  VM에 집계	sum by (vm) (rate(metric_name[1m]))	100
  라벨 값 집계	sum by (label_key) (rate(metric_name[1m]))	10
  서비스에 집계	sum by (service) (rate(metric_name[1m]))	5
  집계하여 라벨 값 및 서비스	sum by (service, label_key) (rate(metric_name[1m]))	50
  Fleet로 집계	sum (rate(metric_name[1m]))	1
  필터링 및 VM 1개로 집계	sum (rate(metric_name{vm="my_vm_name"}[1m]))	1
  하나의 서비스로 필터링 및 집계	sum (rate(metric_name{service="my_service_name"}[1m]))	1

가격 책정 예시

다음 예시는 한 달이 30일인 경우 다음과 같은 평가 기간을 제공합니다.

• 30초 실행 기간 86,400회/월
• 15초 실행 기간 172,800회/월 (PromQL 쿼리만 해당)

예시 1: 정책 1개, VM에 집계, 30초

이 예에서는 다음 구성을 사용합니다.

데이터

• VM 100개
• 각 VM은 하나의 측정항목 metric_name을 내보냄
• metric_name에는 1개의 라벨이 있고, 1개의 라벨에는 10개의 값이 있음

• 알림 조건 1개
• 조건이 VM 수준에 집계됨
• 실행 기간 30초

• 조건 비용: 조건 1개 * $1.50/월 = 월별 $1.50
• 시계열 비용 기간당 반환된 시계열 100개 * 월별 기간 86,400개 = 월별 반환된 시계열 860만 개 * 시계열 100만 개당 $0.35 = 월별 $3.02
• 월별 총비용: $4.52/월

예시 2: 정책 100개 (VM당 1개), VM에 집계, 30초

이 예에서는 다음 구성을 사용합니다.

데이터

• VM 100개
• 각 VM은 하나의 측정항목 metric_name을 내보냄
• metric_name에는 1개의 라벨이 있고, 1개의 라벨에는 10개의 값이 있음

• 조건 100개
• 각 조건이 필터링되고 하나의 VM으로 집계됨
• 실행 기간 30초

• 조건 비용: 조건 100개 * 월별 $1.50 = 월별 $150
• 시계열 비용 : 조건 100개 * 기간별 조건당 반환된 시계열 1개 * 월별 기간 86,400개 = 월별 반환된 시계열 860만 개 * 시계열 100만 개당 $0.35 = 월별 $3.02
• 총비용: $153.02/월

예시 3: 정책 1개, VM에 집계, 15초

이 예에서는 다음 구성을 사용합니다.

데이터

• VM 100개
• 각 VM은 하나의 측정항목 metric_name을 내보냄
• metric_name에는 1개의 라벨이 있고, 1개의 라벨에는 10개의 값이 있음

• PromQL 알림 조건 1개
• 조건이 VM 수준에 집계됨
• 실행 기간 15초

• 조건 비용: 조건 1개 * $1.50/월 = 월별 $1.50
• 시계열 비용: 기간당 반환되는 시계열 100개 * 월별 기간 172,800개 = 월별 반환된 시계열 1,730만 개 * 시계열 백만 개당 $0.35 = 월별 $6.05
• 총 비용: 월$7.55

예 4: 각 서비스에 정책 1개 집계(30초)

이 예에서는 다음 구성을 사용합니다.

데이터

• 각 VM이 하나의 서비스에 속하는 VM 100개
• 총 서비스 5개
• 각 VM은 하나의 측정항목 metric_name을 내보냄
• metric_name에는 1개의 라벨이 있고, 1개의 라벨에는 10개의 값이 있음

• 조건 1개
• 조건이 서비스 수준에 합산됨
• 실행 기간 30초

• 조건 비용: 조건 1개 * $1.50/월 = 월별 $1.50
• 시계열 비용: 기간당 반환된 시계열 5개 * 기간당 86,400개의 기간 반환 = 월별 반환된 시계열 432,000개 * 시계열 100만 개당 $0.35 = 월별 $0.14
• 총비용: $1.64/월

예시 5: VM에 정책 1개 집계, VM당 기본 카디널리티 더 높음, 30초

이 예에서는 다음 구성을 사용합니다.

데이터

• VM 100개
• 각 VM은 하나의 측정항목 metric_name을 내보냄
• metric_name에 100개의 라벨이 있고, 각 라벨에는 1,000개의 값이 있음

• 조건 1개
• 조건이 VM 수준에 집계됨
• 실행 기간 30초

• 조건 비용: 조건 1개 * $1.50/월 = 월별 $1.50
• 시계열 비용 기간당 반환된 시계열 100개 * 월별 기간 86,400개 = 월별 반환된 시계열 850만 개 * 시계열 100만 개당 $0.35 = 월별 $3.02
• 월별 총비용: $4.52/월

예시 6: VM에 정책 1개 집계, 하나의 조건으로 측정항목 2개 통합(30초)

이 예에서는 다음 구성을 사용합니다.

데이터

• VM 100개
• 각 VM은 두 가지 측정항목(metric_name_1 및 metric_name_2)을 내보냅니다.
• 두 측정항목 모두 각각 10개의 값이 있는 하나의 라벨이 있습니다.

• 조건 1개
• 조건이 VM 수준에 집계됨
• 조건에서는 OR 연산자를 사용하여 측정항목을 통합합니다.
• 실행 기간 30초

• 조건 비용: 조건 1개 * $1.50/월 = 월별 $1.50
• 시계열 비용: 측정항목 2개 * 기간별 측정항목당 반환된 시계열 100개 * 월별 기간 86,400개 = 월별 반환된 시계열 1,730만 개 * 시계열 백만 개당 $0.35 = 월별 $6.05
• 총 비용: 월$7.55

예시 7: 로그 기반 알림 정책 100개

이 예에서는 다음 구성을 사용합니다.

알림 정책

• 조건 100개 (로그 기반 알림 정책당 조건 1개)

• 조건 비용: 조건 100개 * 월 $1.50 = 월 $150.00
• 시계열 비용: $0(로그 기반 알림 정책은 시계열을 반환하지 않습니다.)
• 총 비용: 월$150.00

알림 요금 절감을 위한 제안

더 많은 리소스에서 작동하도록 알림 정책 통합

조건당 $1.50의 비용이 발생하므로 하나의 알림 정책을 사용하여 각 리소스를 모니터링하는 것보다 하나의 알림 정책을 사용하여 여러 리소스를 모니터링하는 것이 더 비용 효율적입니다. 예를 들어 예시 1과 예시 2를 비교합니다. 두 예시 모두 동일한 리소스 수를 모니터링합니다. 그러나 예시 2에서는 100개의 알림 정책을 사용하고 예시 1에서는 알림 정책을 1개만 사용합니다. 따라서 예시 1은 매월 거의 $150 저렴합니다.

알림을 보내야 하는 수준까지만 집계합니다.

더 높은 수준의 세부사항으로 집계하면 더 낮은 수준의 세부사항으로 집계하는 것보다 비용이 많이 듭니다. 예를 들어 Google Cloud 프로젝트 수준으로 집계하는 것이 클러스터 수준으로 집계하는 것보다 저렴하고, 클러스터 수준으로 집계하는 것이 클러스터 및 네임스페이스 수준으로 집계하는 것보다 저렴합니다.

예를 들어 예시 1과 예시 4를 비교합니다. 두 예시 모두 동일한 기본 데이터에 대해 작동하며 단일 알림 정책을 갖습니다. 그러나 예 4의 알림 정책은 서비스에 집계되므로 VM에 보다 세부적으로 집계되는 예 1의 알림 정책보다 비용이 저렴합니다.

또한 예 1과 예 5를 비교합니다. 이 경우 예 5의 측정항목 카디널리티는 예 1의 측정항목 카디널리티보다 10,000배 높습니다. 그러나 예시 1과 예시 5의 알림 정책 모두 VM에 집계되고 두 예시의 VM 수가 동일하므로 예시의 가격은 동일합니다.

알림 정책을 구성할 때 사용 사례에 가장 적합한 집계 수준을 선택하세요. 예를 들어 CPU 사용률에 대한 알림이 중요한 경우 VM 및 CPU 수준으로 집계할 수 있습니다. 엔드포인트별 지연 시간에 대한 알림이 중요한 경우 엔드포인트 수준으로 집계할 수 있습니다.

집계되지 않은 원시 데이터에 대한 알림 표시 안 함

Monitoring은 측정기준 측정항목 시스템을 사용합니다. 이 경우 측정항목의 총 카디널리티는 모니터링되는 리소스 수에 해당 측정항목의 라벨 조합 수를 곱한 값과 같습니다. 예를 들어 측정항목을 내보내는 100개의 VM이 있고 해당 측정항목에 각각 10개의 값이 있는 라벨이 10개 있는 경우 총 카디널리티는 100 * 10 * 10 = 10,000입니다.

카디널리티가 확장되는 방식 때문에 원시 데이터에 대한 알림 비용이 매우 많이 들 수 있습니다. 이전 예시에서는 실행 기간마다 10,000개의 시계열이 반환되었습니다. 그러나 VM으로 집계하면 기본 데이터의 라벨 카디널리티에 관계없이 실행 기간당 100개의 시계열만 반환됩니다.

또한 원시 데이터에 대한 알림을 사용하면 측정항목에 새 라벨을 받을 때 시계열이 증가할 위험이 있습니다. 이전 예시에서 사용자가 측정항목에 새 라벨을 추가하면 총 카디널리티는 100 * 11 * 10 = 11,000개의 시계열로 증가합니다. 이 경우 알림 정책이 변경되지 않아도 반환되는 시계열 수가 실행 기간마다 1,000개씩 증가합니다. 대신 VM에 집계하면 기본 카디널리티가 증가해도 여전히 100개의 시계열만 반환됩니다.

불필요한 응답 필터링

알림 요구사항에 필요한 데이터만 평가하도록 조건을 구성합니다. 문제를 해결하기 위한 조치를 취하지 않는다면 알림 정책에서 해당 부분을 제외하세요. 예를 들어 인턴의 개발 VM에 대해서는 알림을 받을 필요가 없을 것입니다

불필요한 알림과 비용을 줄이기 위해 중요하지 않은 시계열을 필터링하는 것도 하나의 방법입니다. Google Cloud 메타데이터 라벨을 사용하여 저작물에 카테고리를 태그한 다음 불필요한 메타데이터 카테고리를 필터링할 수 있습니다.

상위 스트림 연산자를 사용하여 반환되는 시계열 수 줄이기

조건에서 PromQL 또는 MQL 쿼리를 사용하는 경우 상위 스트림 연산자를 사용하여 가장 높은 값으로 반환된 시계열의 수를 선택할 수 있습니다.

• PromQL: topk
• MQL: top

예를 들어 PromQL 쿼리의 topk(metric, 5) 절은 각 실행 기간에 반환되는 시계열 수를 5개로 제한합니다.

상위 시계열로 제한하면 데이터 누락 및 다음과 같은 잘못된 알림이 발생할 수 있습니다.

• N개를 초과하는 시계열이 기준점을 위반하면 상위 N개 시계열을 벗어난 데이터가 누락됩니다.
• 위반 시계열이 상위 N개의 시계열을 벗어나면 제외된 시계열이 여전히 기준을 위반하더라도 이슈가 자동으로 종료될 수 있습니다.
• 조건 쿼리가 의도한 대로 작동하는 기준 시계열과 같은 중요한 컨텍스트를 표시하지 않을 수 있습니다.

이러한 위험을 완화하려면 N에 대해 큰 값을 선택하고 개별 Kubernetes 컨테이너의 알림과 같이 여러 시계열을 평가하는 알림 정책에서만 최상위 스트림 연산자를 사용하세요.

실행 기간 길이 늘리기(PromQL만 해당)

조건이 PromQL 쿼리를 사용하는 경우 조건에서 evaluationInterval 필드를 설정하여 실행 기간의 길이를 수정할 수 있습니다.

평가 간격이 길수록 매월 반환되는 시계열 수가 적습니다. 예를 들어 간격이 15초인 조건 쿼리는 30초 간격의 쿼리보다 2배 더 자주 실행되며, 1분 간격의 쿼리는 실행 빈도가 30초 간격인 쿼리에 비해 절반 수준으로 실행됩니다.

선택 해제

2025년 4월까지 만료되지 않는 기존 Google Cloud 계약이 있는 경우 Cloud Monitoring 알림 결제팀에 예외를 요청하여 계약 갱신 기한이 될 때까지 알림에 대한 청구를 연기할 수 있습니다. 활성 계약이 있는 고객에 대한 예외는 사례별로 고려됩니다.

2024년 11월 1일까지 예외를 요청할 수 있습니다. 계약 갱신까지 결제 면제를 요청하려면 청구 면제 요청 양식을 작성하세요.

Error Reporting

Error Reporting API 또는 Cloud Logging API를 사용하여 오류 데이터를 Google Cloud 프로젝트에 보고할 수 있습니다.

Error Reporting은 무료로 사용할 수 있습니다. 하지만 로그 항목이 생성된 후 Cloud Logging에 의해 저장되므로 Cloud Logging 비용이 발생할 수 있습니다.

Error Reporting 사용 시 적용되는 한도는 할당량 및 한도를 참조하세요.

Cloud Profiler

Cloud Profiler를 사용하는 데는 비용이 들지 않습니다.

Profiler 사용 시 적용되는 한도는 할당량 및 한도를 참조하세요.

Cloud Trace

Trace는 수집 및 스캔된 trace 스팬 수를 기준으로 요금을 부과합니다. 지연 시간 데이터가 Trace로 전송되면 스팬으로 구성된 trace로 패키징되며, 스팬은 Cloud Trace 백엔드에 의해 수집됩니다. trace 데이터를 확인할 때 저장된 스팬은 Cloud Trace에 의해 스캔됩니다. 이 섹션에서는 다음 정보를 제공합니다.

• 요금이 부과되는 trace 스팬 및 요금이 부과되지 않는 trace 스팬을 정의합니다.
• 가격 책정 예시를 제공합니다.
• trace 스팬 수집을 줄이는 방법에 관한 정보를 제공합니다.
• trace 스팬 수집이 기준에 도달하는 경우 알림을 받을 수 있는 알림 정책 설정을 안내합니다.

현재 가격 정보는 Cloud Trace 가격 책정을 참조하세요.

Trace 사용 시 적용되는 한도는 할당량 및 한도를 참조하세요.

현재 또는 과거 사용량을 확인하는 방법에 대한 자세한 내용은 예상 청구액 확인을 참조하세요.

요금이 부과되지 않는 trace 스팬

App Engine 표준, Cloud Run 함수 또는 Cloud Run에서 자동 생성된 스팬에는 Cloud Trace 가격 책정이 적용되지 않습니다. 이러한 trace 수집에는 요금이 부과되지 않습니다.

요금이 부과되는 trace 스팬

요금이 부과되지 않는 trace 섹션에 나열된 스팬을 제외한 모든 trace 스팬은 요금이 부과되며, 데이터 수집량을 기준으로 가격이 책정됩니다. 여기에는 App Engine 표준 애플리케이션에 추가한 도구에서 생성된 스팬이 포함됩니다.

가격 책정 예시

예시는 2020년 7월 Trace 가격을 기준으로 합니다.

• 한 달에 200만 개의 스팬을 수집하는 경우 비용은 $0입니다. (월별 수집된 첫 250만 개의 스팬은 무료입니다.)
• 한 달에 1,400만 개의 스팬을 수집하는 경우 비용은 $2.30입니다. (월별 첫 250만 개의 스팬은 무료입니다. 나머지 스팬의 비용은 스팬 1,150만 개*$0.20/100만 개 스팬 = $2.30으로 계산됩니다.)
• 한 달에 10억 개의 스팬을 수집하는 경우 비용은 $199입니다. (월별 첫 250만 개의 스팬은 무료입니다. 나머지 스팬의 비용은 스팬 9억 9,750만 개*$0.20/100만 개 스팬 = $199.50으로 계산됩니다.)

trace 사용량 줄이기

Trace 스팬의 수집량을 관리하려면 trace 샘플링 레이트를 관리하여 성능 분석에 필요한 trace 수와 비용 허용 범위 간의 균형을 맞추면 됩니다.

트래픽 수준이 높은 시스템의 경우 대부분의 고객이 트랜잭션 1,000개 중 1개 또는 트랜잭션 10,000개 중 1개를 샘플링하면서도 성능 분석에 충분한 정보를 얻고 있습니다.

샘플링 레이트는 Cloud Trace 클라이언트 라이브러리로 구성됩니다.

수집된 월별 스팬 알림

월별로 수집되는 Cloud Trace 스팬 수가 사용자 정의 한도를 초과하면 트리거되는 알림 정책을 만들려면 다음 설정을 사용하세요.

GKE Enterprise

GKE Enterprise 시스템 로그 및 측정항목에는 요금이 청구되지 않습니다. 클러스터 생성 시 GKE Enterprise가 사용 설정된 프로젝트에 등록된 Google Cloud의 GKE 클러스터에 대해 컨트롤 플레인 로그, 컨트롤 플레인 측정항목, Kubernetes 상태 측정항목의 선별된 하위 집합이 기본적으로 사용 설정됩니다. 컨트롤 플레인 로그에는 Cloud Logging 요금이 부과되지만 기본 설정 측정항목은 추가 비용 없이 포함됩니다.

포함된 GKE 로그 및 측정항목 목록은 수집되는 로그 및 사용 가능한 측정항목을 참조하세요.

Google Distributed Cloud 클러스터에서 GKE Enterprise 시스템 로그 및 측정항목에는 다음이 포함됩니다.

• 관리자 클러스터에 있는 모든 구성요소의 로그 및 측정항목
• 사용자 클러스터의 다음 네임스페이스에 있는 구성요소의 로그 및 측정항목: kube-system, gke-system, gke-connect, knative-serving, istio-system, monitoring-system, config-management-system, gatekeeper-system, cnrm-system

자주 묻는 질문(FAQ)

어떤 제품 기능을 무료로 사용할 수 있나요?

Google Cloud Observability 제품의 사용 가격은 데이터 볼륨을 기준으로 책정됩니다. 이 페이지에 설명된 데이터 볼륨 비용 이외에 모든 추가 Google Cloud Observability 제품 기능은 무료입니다.

사용료는 얼마인가요?

사용량에 따른 비용은 예상 청구액 확인을 참조하세요.

청구와 관련해 궁금한 점이 있으면 결제 관련 문의를 참조하세요.

사용량 세부정보는 어떻게 확인할 수 있나요?

측정항목 탐색기의 여러 측정항목을 사용하여 로그 및 측정항목 양을 자세히 분석하고 이해할 수 있습니다. 자세한 내용은 측정항목 탐색기에서 세부 사용량 보기를 참조하세요.

비용 관리 방법에 대한 자세한 내용은 다음 블로그 게시물을 참조하세요.

• Cloud 관리자를 위한 Cloud Logging 가격 책정: 접근 및 비용 절감 방법
• 예산에 따라 Cloud Logging 비용을 관리하는 4단계

측정항목 범위와 로그 범위가 결제에 어떤 영향을 미치나요?

대부분의 경우 측정항목 범위와 로그 범위는 청구에 영향을 미치지 않습니다. 로그 및 측정항목 요금은 데이터를 수신하는 프로젝트, 결제 계정, 폴더, 조직에 의해 청구됩니다. 프로젝트의 측정항목 범위는 프로젝트에서 측정항목을 보고 모니터링할 수 있는 리소스 모음을 정의합니다. 측정항목 범위를 정의해도 측정항목 데이터를 수신하는 리소스에 영향을 주거나 데이터가 중복되지는 않습니다. 마찬가지로 로그 범위에는 보려는 로그 항목을 저장하거나 라우팅하는 리소스만 나열됩니다.

예를 들어 조직에 가상 머신(VM)이 100개 있다고 가정해 보겠습니다. 60개의 VM이 프로젝트 A에서 호스팅되고 40개의 VM이 프로젝트 B에 있다고 가정해 보겠습니다. 프로젝트 A는 VM의 측정항목을 수신하고 저장하며 측정항목을 청구할 때 비용이 청구됩니다. 마찬가지로 프로젝트 B는 VM의 측정항목을 수신하고 저장하며 측정항목을 청구할 때 비용이 청구됩니다. 프로젝트 A와 프로젝트 B를 포함하는 측정항목 범위를 만들면 VM 100개에 대해 결합된 측정항목을 볼 수 있습니다. 이제 프로젝트 A의 측정항목만, 프로젝트 B의 측정항목만 또는 측정항목 조합을 볼 수 있습니다. 프로젝트 A의 측정항목을 보는 방법에는 두 가지가 있지만 청구에는 영향을 미치지 않습니다.

무료 할당량을 초과하면 어떻게 되나요?

무료 할당량을 초과한 사용량에 대해서는 자동으로 요금이 청구됩니다. 로그 또는 측정항목은 손실되지 않습니다. 청구 예상 비용에 대한 자세한 내용은 예상 청구액 확인을 참조하세요.

사용량을 모니터링하고 청구 기준에 도달하는 경우 알림을 제공하는 알림 정책을 만들 수 있습니다.

사용하지 않는 프로젝트에 많은 양의 Google Cloud 로그가 있습니다. 이 로그의 요금이 걱정되는데 어떻게 해야 하나요?

로그를 제외하여 Logging에 수집되는 로그를 제어할 수 있습니다. 자세한 내용은 로그 사용량 줄이기를 참조하세요.

로그를 제외하면 프로젝트에 로그를 전송하는 서비스에 오류가 발생하나요?

아니요. 로그 항목을 전송하는 서비스에서는 Logging의 로그 항목 수집 여부를 확인할 수 없습니다.

Virtual Private Cloud의 흐름 로그에 대해 요금이 두 번 부과되나요?

VPC 흐름 로그를 Logging으로 전송하면 VPC 흐름 로그 생성 요금이 면제되며 Logging 요금만 부과됩니다. 그러나 전송한 후 Logging에서 VPC 흐름 로그를 제외하면 VPC 흐름 로그 요금이 부과됩니다. 자세한 내용은 Google Cloud 가격 계산기를 참조한 후 'Cloud Load Balancing 및 네트워크 서비스' 탭을 선택합니다.

¹ 가격 책정을 위해 모든 단위는 메비바이트(MiB 또는 2²⁰바이트) 또는 기비바이트(GiB, 2³⁰바이트)와 같이 바이너리 단위로 취급됩니다.

² 분당 최대 데이터 포인트 1개(현재 최고 해상도)로 측정되는 Google Cloud 측정항목 또는 GKE Enterprise 측정항목에는 요금이 부과되지 않습니다. 향후 이를 초과하는 확인 속도로 측정되는 측정항목에는 요금이 부과될 수 있습니다.

³ 프로세스 측정항목은 현재 미리 정의된 분당 1회의 기본 비율(변경할 수 없음)로 수집됩니다. 이 데이터는 일반적으로 느리게 변경되므로 측정항목이 현재 초과 샘플링됩니다. 따라서 표준 비율 5%의 프로세스 측정항목 청구는 측정항목이 20분 간격으로 샘플링되는 경우 표준 비율과 일치합니다. 이러한 측정항목에서 100MiB 데이터를 수집하는 사용자는 5MiB만 부과됩니다.

다음 단계

• Google Cloud 관측 가능성 문서 읽어보기
• 가격 계산기 사용해 보기
• Google Cloud Observability 솔루션 및 사용 사례 알아보기