Precios de Google Cloud Observability

Los precios de Google Cloud Observability te permiten controlar el uso y los gastos. Los productos de Google Cloud Observability se cobran según el volumen de datos o el uso. Puedes usar las asignaciones gratuitas de uso de datos para comenzar sin compromisos ni tarifas por adelantado.

En las siguientes tablas, se resume la información de precios de Cloud Logging, Cloud Monitoring y Cloud Trace.

Resumen de precios de Cloud Logging

Función Precio1 Asignación gratuita por mes Fecha de entrada en vigencia
Almacenamiento de Logging*
excepto para los registros de red vendidos.		 $0.50/GiB;
Se cobra una sola vez por la transmisión de registros al almacenamiento de bucket de registros para indexación, consultas y análisis. Incluye hasta 30 días de almacenamiento en buckets de registros. No se aplican cargos adicionales por consultar y analizar datos de registros.
 Primeros 50 GiB por proyecto al mes 1 de julio de 2018
Almacenamiento de registros de red vendidos† $0.25/GiB;
Se cobra una sola vez por la transmisión de registros de telemetría de red al almacenamiento de bucket de registros para indexación, consultas y análisis. Incluye hasta 30 días de almacenamiento en buckets de registros. No se aplican cargos adicionales por consultar y analizar datos de registros. 		No aplicable 1 de octubre de 2024
Retención de Logging‡ Se facturará mensualmente $0.01 por GiB para los registros retenidos durante más de 30 días según la retención. Los registros retenidos durante el período de retención predeterminado no generan costos de retención. 1 de enero de 2022
Enrutador de registros♣  Sin cargos adicionales No aplicable No aplicable
Análisis de registros♥  Sin cargos adicionales No aplicable No aplicable
*  El volumen de almacenamiento cuenta el tamaño real de las entradas de registro antes de la indexación. No se aplican cargos de almacenamiento por los registros almacenados en el _Requiredbucket de registro.
 †  Los registros de terceros son registros de redes de Google Cloud que generan los servicios de Google Cloud cuando se habilita la generación de estos registros. Los registros de terceros incluyen registros de flujo de VPC, registros de reglas de firewall y registros de Cloud NAT. Estos registros también están sujetos a los precios de la telemetría de red. Para obtener más información, consulta Registros de terceros.
 ‡  No se aplican cargos de retención por los registros almacenados en el bucket de registros _Required, que tiene un período de retención fijo de 400 días.
 ♣  El enrutamiento de registros se define como el reenvío de registros recibidos a través de la API de Cloud Logging a un destino admitido. Es posible que se apliquen cargos de destino a los registros enrutados.
 ♥  No se aplican cargos por actualizar un bucket de registros para usar el Análisis de registros o emitir consultas en SQL desde la página Análisis de registros.
 Nota: El lenguaje de precios de Cloud Logging cambió el 19 de julio de 2023. Sin embargo, las asignaciones gratuitas y las tarifas no cambiaron. Tu factura podría mencionar el idioma anterior de los precios.

Resumen de precios de Cloud Monitoring

Función Precio Asignación gratuita por mes Fecha de entrada en vigencia
Todos los datos de Monitoring
(excepto aquellos transferidos mediante Managed Service para Prometheus)		 $0.2580 por MiB1: En primer lugar, de 150 a 100,000 MiB
$0.1510 por MiB: después de 100,000–250,000 MiB
$0.0610 por MiB: > 250,000 MiB		 Todas las métricas no cobrables de Google Cloud
Los primeros 150 MiB por cuenta de facturación para las métricas que se cobran por bytes transferidos		 1 de julio de 2018
Métricas transferidas mediante Google Cloud Managed Service para Prometheus, incluidas las métricas del plano de control de GKE $0.06 por cada millón de muestras†: los primeros 0-50,000 millones de muestras transferidas#
$0.048 por cada millón de muestras: los siguientes 50,000 a 250,000 millones de muestras transferidas
$0.036 por cada millón de muestras: los siguientes 250,000 a 500,000 millones de muestras transferidas
$0.024 por cada millón de muestras: más de 500,000 millones de muestras transferidas		 No aplicable 8 de agosto de 2023
Llamadas a la API de Monitoring $0.01 por cada 1,000 llamadas a la API de Read
(las llamadas a la API de Write son gratuitas)		 Se incluye el primer millón de llamadas a la API de Read por cuenta de facturación 1 de julio de 2018
Ejecución de verificaciones de tiempo de actividad de Monitoring $0.30 por cada 1,000 ejecuciones‡ 1 millón de ejecuciones por proyecto de Google Cloud 1 de octubre de 2022
Ejecución de monitores sintéticos de Monitoring $1.20 por cada 1,000 ejecuciones* 100 ejecuciones por cuenta de facturación 1 de noviembre de 2023
Políticas de alertas $1.50 por mes por cada condición en una política de alertas
$0.35 por 1,000,000 de series temporales devueltas por la consulta de una condición de política de alertas de métricas♣		 No aplicable Abril de 2026
†  Google Cloud Managed Service para Prometheus usa el almacenamiento de Cloud Monitoring de datos de métricas creados de forma externa y la API de Monitoring para recuperar esos datos. El servicio administrado para los medidores de Prometheus se basa en muestras transferidas en lugar de bytes para alinearse con las convenciones de Prometheus. Si quieres obtener más información sobre la medición basada en muestras, consulta Precios para la capacidad de control y previsibilidad. Para obtener ejemplos de procesamiento, consulta ejemplos de precios basados en muestras transferidas.
 #  Las muestras se cuentan por cuenta de facturación.
 ‡  Las ejecuciones se cobran a la cuenta de facturación en la que se definen. Para obtener más información, consulta Precios para la ejecución de verificaciones de tiempo de actividad.
 *  Las ejecuciones se cobran a la cuenta de facturación en la que se definen. Es posible que se te cobren cargos adicionales de otros servicios de Google Cloud por cada ejecución, incluidos servicios como Cloud Run Functions, Cloud Storage y Cloud Logging. Para obtener información sobre estos cargos adicionales, consulta el documento de precios del servicio de Google Cloud correspondiente.
 ♣  Para obtener más información, consulta los Precios de las alertas.

Resumen de precios de Cloud Trace

Función Precio Asignación gratuita por mes Fecha de entrada en vigor
Transferencia de Trace $0.20 por cada millón de intervalos Los primeros 2.5 millones de intervalos por cuenta de facturación 1 de noviembre de 2018

Para obtener información detallada sobre los costos de los productos de Google Cloud Observability, consulta las siguientes secciones de esta página:

Para obtener información sobre los precios de GKE Enterprise, consulta GKE Enterprise.

Visualiza tu uso

Para ver tu uso actual, dirígete a la página Informes de Facturación de Cloud en la consola de Google Cloud.

Ir a Facturación de Cloud

Puedes usar la calculadora de precios para calcular la facturación según tus datos de uso actuales.

Por ejemplo, considera una configuración en la que cada instancia de VM de Compute Engine genera 10 GiB de registros cobrables y 20 MiB de métricas cobrables por mes. Puedes determinar los costos previstos de Cloud Monitoring y Cloud Logging mediante la calculadora de precios.

1 VM 10 VMs 100 VM 1,000 VM
Costo de las métricas por mes $0.00 $12.90 $477.30 $5,121.30
Costo de Logging por mes $0.00 $25.00 $475.00 $4,975.00
Costo total $0.00 $37.90 $952.30 $10,096.30

Configura una alerta de facturación

Crea una alerta a través de la página Presupuestos y alertas de la consola de Google Cloud para recibir una notificación si tus cargos previstos o facturables superan un presupuesto.

  1. En la consola de Google Cloud, ve a la página Facturación:

    Ir a Facturación

    También puedes usar la barra de búsqueda para encontrar esta página.

    Si tienes más de una cuenta de Facturación de Cloud, realiza una de las siguientes acciones:

    • Si quieres administrar la Facturación de Cloud para el proyecto actual, selecciona Ir a la cuenta de facturación vinculada.
    • Si deseas ubicar otra cuenta de Facturación de Cloud, selecciona Administrar cuentas de facturación y elige la cuenta para la que deseas configurar un presupuesto.
  2. En el menú de navegación de Facturación, selecciona Presupuestos y alertas.
  3. Haz clic en Crear presupuesto .
  4. Completa el diálogo del presupuesto. En este cuadro de diálogo, seleccionarás proyectos y productos de Google Cloud y, luego, crearás un presupuesto para esa combinación. De forma predeterminada, se te notifica cuando alcanzas el 50%, el 90% y el 100% del presupuesto. Para ver la documentación completa, consulta Configura presupuestos y alertas de presupuesto.

Cloud Logging

Los buckets de registros son los contenedores de Logging que almacenan datos de registros. Logging cobra por el volumen de datos de registros que se almacenan en el bucket de registros _Default y en buckets de registros definidos por el usuario. Los precios se aplican a los registros de red no vendidos cuando el volumen supera la asignación mensual gratuita, y a los registros de red vendidos.

Para el bucket de registros _Default y los buckets de registros definidos por el usuario, Logging también cobra cuando los registros se retienen por más tiempo que el período de retención predeterminado, que es de 30 días.

No hay cargos adicionales por Logging para enrutar registros, usar la API de Cloud Logging, configurar permisos de registro o por los registros almacenados en el bucket de registros _Required, que tiene un período de retención fijo de 400 días.

En esta sección, se proporciona información sobre los siguientes temas:

Para obtener un resumen de la información de precios, consulta el resumen de precios de Cloud Logging.

Para ver los límites que se aplican a tu uso de Logging, incluidos los períodos de retención de datos, consulta Cuotas y límites.

Para ver y comprender los datos de uso de Cloud Logging, consulta Estima tu facturación.

Modelo de almacenamiento de Cloud Logging

Para cada proyecto de Google Cloud, Logging crea automáticamente dos buckets de registros: _Required y _Default. Para estos dos buckets, Logging crea automáticamente receptores de registros llamados _Required y _Default que enrutan los registros a los buckets de registros con los nombres correspondientes. No puedes inhabilitar ni modificar el receptor _Required. Puedes inhabilitar o modificar de alguna otra forma el receptor _Default para evitar que el bucket _Default almacene registros nuevos.

Puedes crear buckets de registros definidos por el usuario en cualquiera de tus proyectos de Google Cloud. También puedes configurar receptores para enrutar cualquier combinación de registros, incluso en los proyectos de Google Cloud de tu organización de Google Cloud, a estos buckets de registros.

Para el bucket de registros _Default y los buckets de registros definidos por el usuario, puedes configurar un período de retención personalizado.

Puedes actualizar tus buckets de registros para usar el Análisis de registros. No se aplican cargos por actualizar un bucket de registros para usar el Análisis de registros.

Para obtener más información sobre los buckets y receptores de Cloud Logging, consulta Descripción general del enrutamiento y el almacenamiento.

Precios de almacenamiento

Logging no cobra por los registros almacenados en el bucket _Required. No puedes borrar el bucket _Required ni modificar el receptor _Required. El bucket _Required almacena los siguientes registros:

Logging cobra por el volumen de datos de registros preindexados que se almacenan en el bucket de registros _Default y en buckets de registros definidos por el usuario, cuando el volumen total supera la asignación mensual gratuita. Cada escritura de una entrada de registro en el bucket de registros _Default o en un bucket de registros definido por el usuario se suma a tu asignación de almacenamiento. Por ejemplo, si tienes receptores que enrutan una entrada de registro a tres buckets de registros, esa entrada de registro se almacena tres veces.

Precios de retención

En la siguiente tabla, se muestran los períodos de retención de datos para los registros almacenados en buckets de registros:

Bucket Período de retención predeterminado Retención personalizada
_Required 400 días No configurable
_Default 30 days Configurable
Definido por el usuario 30 days Configurable

Los registros cobran costos de retención cuando los registros se retienen más tiempo que el período de retención predeterminado. No puedes configurar el período de retención para el bucket de registros _Required. No hay costos de retención cuando los registros se almacenan solo durante el período de retención predeterminado del bucket de registros.

Si acortas el período de retención de un bucket de registros, entonces hay un período de gracia de siete días en el que no se borran los registros vencidos. No puedes consultar ni ver registros vencidos. Sin embargo, en esos siete días, puedes restablecer el acceso completo extendiendo el período de retención del bucket de registros. Los registros almacenados durante el período de gracia se incluyen en tus costos de retención.

Si enrutas una entrada de registro a varios buckets de registros, se te pueden cobrar los costos de almacenamiento y retención varias veces. Por ejemplo, supongamos que enrutas una entrada de registro al bucket de registros _Default y a un bucket de registros definido por el usuario. Además, supongamos que configuras un período de retención personalizado para ambos buckets que es más largo que 30 días. Con esta configuración, recibirás dos cargos por almacenamiento y dos cargos por retención.

Registros de red vendidos

Los registros de red vendidos están disponibles solo cuando configuras la generación de registros. Los servicios que generan registros de red vendidos cobran por la generación de registros. Si almacenas estos registros en un bucket de registros o los enrutas a otro destino compatible, también estarás sujeto a los cargos de Cloud Logging o del destino. Para obtener información sobre los costos de generación de registros, consulta Precios de la telemetría de red.

Para obtener más información sobre cómo habilitar los registros de red de terceros, consulta Configura los registros de flujo de VPC, Usa el registro de reglas de firewall y Cloud NAT: Registros y métricas.

Para encontrar los registros de red vendidos, filtra el Explorador de registros por los siguientes nombres de registro:

  • 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

Reduce el almacenamiento de registros

Para reducir los costos de almacenamiento de Cloud Logging, configura filtros de exclusión en los receptores de registros para excluir ciertos registros de ser enrutados. Los filtros de exclusión pueden quitar todas las entradas de registro que coincidan con el filtro o pueden quitar solo un porcentaje de los registros. Cuando una entrada de registro coincide con un filtro de exclusión de un receptor, el receptor no enruta la entrada de registro al destino. Las entradas de registro excluidas no cuentan en tu asignación de almacenamiento. Si deseas obtener instrucciones para configurar filtros de exclusión, consulta Exclusiones de registros.

Otra opción para reducir los costos de almacenamiento de Cloud Logging es enrutar los registros fuera de Cloud Logging a un destino compatible. Cloud Logging no cobra por enrutar registros a destinos compatibles. Sin embargo, es posible que se te cobre cuando un destino reciba registros:

Para obtener información sobre el enrutamiento de registros fuera de Cloud Logging, consulta Enruta registros a destinos compatibles.

Precios de las métricas basadas en registros

Las métricas basadas en registros definidas por el sistema se proporcionan para todos los proyectos de Google Cloud y no son cobrables.

Las métricas basadas en registros definidas por el usuario son una clase de métricas personalizadas de Cloud Monitoring y son cobrables. Para obtener más información sobre los precios, consulta las métricas cobrables.

Para obtener más información, consulta Descripción general de las métricas basadas en registros.

Crear una política de alertas sobre los bytes de registro mensuales transferidos

Para crear una política de alertas que se active cuando la cantidad de bytes de registros escritos en tus buckets de registros supere el límite que definió el usuario para Cloud Logging, usa la siguiente configuración.

Nueva condición
Campo
Valor
Recurso y métrica En el menú Recursos, selecciona Global.
En el menú Categorías de métricas, selecciona Métrica basada en registros.
En el menú Métricas, selecciona Bytes de transferencia de registros por mes.
Filtro Ninguno
Series temporales
Agregación de series temporales		 sum
Ventana progresiva 60 m
Función analítica progresiva max
Configura el activador de alertas
Campo
Valor
Tipo de condición Threshold
Activador de alertas Any time series violates
Posición del umbral Above threshold
Valor del umbral Tú determinas el valor aceptable.
Período para volver a probar El valor mínimo aceptable es 30 minutos.

Cloud Monitoring

Monitoring cobra lo siguiente:

  • Métricas medidas por bytes transferidos cuando los datos de métricas transferidos exceden la asignación mensual gratuita de métricas.

    Las métricas no cobrables no cuentan para el límite de la asignación.

  • Métricas medidas por la cantidad de muestras transferidas.

  • Llamadas de lectura a la API de Cloud Monitoring que superan la asignación mensual gratuita de la API

    Las llamadas de escritura a la API de Monitoring no cuentan para el límite de asignación.

  • Ejecución de verificaciones de tiempo de actividad

  • Ejecución de monitores sintéticos.

  • Condiciones de la política de alertas medidas por la cantidad de condiciones activas por mes.

  • Series temporales devueltas por la consulta de una condición de política de alertas.

En Monitoring, la transferencia se refiere al proceso de escritura de series temporales en Monitoring. Cada serie temporal incluye una cantidad de datos; esos datos son la base de los cargos por transferencia. Para obtener información sobre los precios, consulta Precios de Cloud Monitoring.

En esta sección, se proporciona la siguiente información:

Para obtener información de los precios actuales, consulta Precios de Cloud Monitoring.

Para ver los límites que se aplican en el uso de Monitoring, consulta Cuotas y límites.

Para ver tu uso actual, haz una de las siguientes acciones:

  • En la consola de Google Cloud, ve a la página Facturación:

    Ir a Facturación

    También puedes usar la barra de búsqueda para encontrar esta página.

  • En la consola de Google Cloud, ve a la página  Configuración:

    Ir a Configuración

    Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Monitoring.

Puedes calcular tus facturas según tus datos de uso actuales.

Métricas no cobrables

No se cobran los datos de las métricas de Google Cloud, GKE Enterprise y Knative. A continuación se detallan las métricas que no son cobrables (gratuitas):

Métricas cobrables

Todos los datos de métricas, excepto las métricas que se enumeran en la sección titulada Métricas no cobrables, son cobrables. La mayor parte de la transferencia de métricas se cobra según la cantidad de bytes, pero algunas se cobran según la cantidad de muestras. Estos modelos de precios se describen en las secciones siguientes.

Los siguientes factores contribuyen a los costos de transferencia:

  • El tipo de datos (valores escalares o de distribución) que recopilan las métricas.

    • Para obtener información sobre el tipo de datos asociado con un tipo de métrica específico, consulta la lista de métricas.
    • Para obtener información sobre los tipos de datos escalares y de distribución, consulta Tipos de valores.

  • Es la cantidad de datos escritos en la serie temporal. Este valor depende de la frecuencia con la que se realizan las muestras de datos y la cardinalidad de tus datos. La cardinalidad determina cuántas series temporales se generan para una combinación de tipos de métricas y recursos supervisados. Para obtener más información, consulta Cardinalidad.

Los valores de la etiqueta de métrica y recursos que forman parte de las series temporales no contribuyen a los cargos.

Métricas que cobran los bytes transferidos

Las siguientes métricas son cobrables y se cobran según la cantidad de bytes transferidos:

Para determinar los precios, el volumen de transferencia se calcula de la siguiente manera:

  • Para un tipo de dato escalar: 8 bytes por cada dato escrito en una serie temporal. Las métricas de contador basadas en registros definidas por el usuario entran en esta categoría.
  • Para un tipo de datos de distribución: 80 bytes por cada dato escrito en una serie temporal.

Para obtener información sobre los datos en series temporales, consulta Series temporales: datos de un recurso supervisado.

Métricas que cobran las muestras transferidas

Las siguientes métricas son cobrables y se cobran según la cantidad de muestras transferidas:

  • Métricas de Google Cloud Managed Service para Prometheusprometheus.googleapis.com

Para determinar los precios, el conteo de muestra se calcula de la siguiente manera:

  • Para un tipo de dato escalar: 1 por cada punto escrito en una serie temporal.
  • En el caso de un tipo de datos de distribución, se consideran 2 por cada punto escrito en una serie temporal, más 1 por cada bucket de histograma que tiene un recuento distinto de cero.

Para obtener información sobre los datos en series temporales, consulta Series temporales: datos de un recurso supervisado.

Alerta de métricas transferidas

No se puede crear una alerta en función de las métricas mensuales transferidas. Sin embargo, puedes crear una para tus costos de Cloud Monitoring. Si quieres obtener más información, consulta Configura una alerta de facturación.

Ejemplos de precios basados en bytes transferidos

En los siguientes ejemplos, se muestra cómo obtener una estimación de los costos de recopilación de datos de métricas para las métricas que se cobran por bytes transferidos. Estos ejemplos tienen el propósito de ilustrar los cálculos. Usa la calculadora de precios para obtener estimaciones más completas. Si accedes a esta herramienta, usa el producto de Google Cloud Observability para ingresar tus datos de seguimiento, métricas y registros.

El escenario básico es el siguiente: tienes un número de recursos supervisados, como Compute Engine, Google Kubernetes Engine o App Engine, que escriben datos a partir de un número de métricas todos los meses.

Las variables entre los escenarios incluyen:

  • La cantidad de recursos
  • La cantidad de métricas
  • Si las métricas son de Google Cloud o no
  • La velocidad a la que se escriben estos datos

Los ejemplos de esta sección son para precios de Monitoring a partir de julio de 2020.

Trasfondo común

En los siguientes ejemplos de precios, se supone que cada dato de métrica transferido es del tipo doble, int64 o booleano. Estos tipos cuentan como 8 bytes para el cálculo de precios. Hay aproximadamente 730 horas (365 días/12 meses × 24 horas) en un mes, o 43,800 minutos.

Para cada dato de métrica que se escribe a una velocidad de 1 dato por minuto en un mes, el cálculo es el siguiente:

  • Datos totales: 43,800
  • Volumen transferido total:
    • 350,400 bytes (43,800 datos × 8 bytes)
    • 0.33416748 MiB (350,400 bytes/1,048,576 bytes/MiB)

Para cada dato de métrica que se escribe a una velocidad de 1 dato/hora en un mes, el cálculo es el siguiente:

  • Datos totales: 730
  • Volumen transferido total:
    • 5,840 bytes (730 datos × 8 bytes)
    • 0.005569458 MiB (5,840 bytes/1,048,576 bytes/MiB)

Ejemplos

Situación 1: Tienes 1,000 recursos y cada uno escribe 75 métricas. Estas métricas solo corresponden a Google Cloud y se escriben a una velocidad de 1 dato/minuto.

  • Transferencia mensual: 25,063 MiB: 0.33416748 MiB para una métrica × 75,000 (es decir, 1,000 recursos, 75 métricas)
  • Costo aproximado por mes: $0.00 (las métricas de Google Cloud se incluyen de forma gratuita)
MiB transferidos Tarifa ($/MiB) Costo ($)
Sin límite 0.00 $0.00
Total 25,063 $0.00

Situación 2: Tienes 1,000 recursos y cada uno escribe 75 métricas personalizadas. Estas son métricas cobrables que se escriben a una velocidad de 1 dato por minuto.

  • Transferencia mensual: 25,063 MiB (igual que la anterior)
  • Costo aproximado por mes: $6,427.55
MiB transferidos Tarifa ($/MiB) Costo ($)
150 0.00 $0.00
24,913 0.258 $6,427.55
Total 25,063 $6,427.55

Situación 3: Tienes 1,000 recursos y cada uno escribe 75 métricas personalizadas. Estas son métricas cobrables que se escriben a una velocidad de 1 dato por hora.

  • Transferencia mensual: 418 MiB = 0.005569458 MiB para una métrica × 75,000
  • Costo aproximado por mes: $69.14
MiB transferidos Tarifa ($/MiB) Costo ($)
150 0.00 $0.00
267 0.258 $69.14
Total 417 $69.14

Situación 4: Tienes 1 recurso que escribe 500,000 métricas. Estas son métricas cobrables que se escriben cada una a una velocidad de 1 dato por minuto.

  • Transferencia mensual: 167,084 MiB: 0.33416748 MiB para una métrica × 500,000
  • Costo aproximado por mes: $35,890.98
MiB transferidos Tarifa ($/MiB) Costo ($)
150 0.00 $0.00
99,850 0.258 $25,761.30
67,084 0.151 $10,129.68
Total 167,084 $35,890.98

Precios para la capacidad de control y previsibilidad

Los precios del servicio administrado para Prometheus están diseñados para ser controlables. Debido a que se te cobra por muestra, puedes usar los siguientes impulsores para controlar los costos:

  • Período de muestreo: cambiar el período de recopilación de métricas de 15 segundos a 60 segundos puede implicar un ahorro de costos del 75%, sin sacrificar la cardinalidad. Puedes configurar períodos de muestreo por trabajo, por objetivo o global.

  • Filtrado: Puedes usar filtros para reducir la cantidad de muestras enviadas al almacén de datos globales del servicio. Si deseas obtener más información, consulta Filtra métricas exportadas. Usa los archivos de configuración de etiquetado de métricas en tu configuración de recopilación de Prometheus para descartar las métricas al momento de la transferencia, en función de los comparadores de etiquetas.

  • Mantén la cardinalidad alta y los datos locales de bajo valor. Puedes ejecutar Prometheus estándar con el servicio administrado mediante la misma configuración de paisaje y conservar los datos locales que no vale la pena enviar al almacén de datos global del servicio.

Los precios de Managed Service para Prometheus están diseñados para ser previsibles.

  • No se te penaliza por tener histogramas escasos. Las muestras se cuentan solo para el primer valor distinto de cero y, luego, cuando el valor de bucket n es mayor que el valor de bucket n-1. Por ejemplo, un histograma con valores 10 10 13 14 14 14 cuenta como tres muestras para el primer, tercer y cuarto bucket.

    Según la cantidad de histogramas que uses y para qué los uses, la exclusión de depósitos sin cambios de los precios, por lo general, podría hacer que se cuenta entre un 20% y un 40% menos de muestras para fines de facturación que el valor absoluto de la cantidad de histogramas que indicarían.

  • Cuando cobras por cada muestra, no te penalizan por los contenedores rápidos, sin escala, interrumpibles o efímeros, como los que crea el HPA o Autopilot de GKE.

    Si el servicio administrado para Prometheus se cobra por métrica, tendrías que pagar por la cardinalidad de un mes completo, todo a la vez, cada vez que se iniciara un contenedor nuevo. Con los precios por muestra, pagas solo mientras se ejecuta el contenedor.

Búsquedas, incluidas las consultas de alertas

Todas las consultas que emite el usuario, incluidas las que se emiten cuando se ejecutan las reglas de grabación de Prometheus, se cobran a través de las llamadas a la API de Cloud Monitoring. Para conocer la tarifa actual, consulta la tabla de resumen de los precios de Managed Service para Prometheus o los precios de Monitoring.

Ejemplos de precios basados en muestras transferidas

En los siguientes ejemplos, se muestra cómo estimar los costos de recopilación de métricas que se cobran por muestras transferidas. Se usa la facturación basada en muestras para Google Cloud Managed Service para Prometheus.

Estos ejemplos tienen el propósito de ilustrar las técnicas de cálculo, no de proporcionar datos de facturación.

El escenario básico es el siguiente: tienes una cantidad de contenedores o Pods que escriben puntos en una cantidad de series temporales cada mes. Los datos pueden consistir en valores escalares o distribuciones.

Las variables entre los escenarios incluyen:

  • La cantidad de contenedores o Pods.
  • La cantidad de series temporales.
  • Si los datos consisten en valores escalares, distribuciones o ambos.
  • La velocidad a la que se escriben estos datos.

Contar muestras

Antes de calcular los precios, debes saber cómo contar las muestras. La cantidad de muestras que se cuentan para un valor depende de los siguientes factores:

  • Si el valor es un escalar o una distribución
  • La velocidad a la que se escriben los valores

En esta sección, se describe cómo estimar el número de muestras escritas para una serie temporal durante el período de facturación mensual.

En un mes, hay aproximadamente 730 horas (365 días / 12 meses 24 horas), 43,800 minutos o 2,628,000 segundos.

Si una serie temporal escribe valores escalares, entonces cada valor cuenta como una muestra. La cantidad de muestras escritas en un mes depende solo de la frecuencia con la que se escriben los valores. Considera los siguientes ejemplos:

  • Para valores escritos cada 15 segundos:
    • Velocidad de escritura: 1 valor/15 s = 1 muestra/15 s
    • Muestras por mes: 175,200 (1 muestra/15 s * 2,628,000 segundos/mes)
  • Para valores escritos cada 60 segundos:
    • Velocidad de escritura: 1 valor/60 s = 1 muestra/60 s
    • Muestras por mes: 43,800 (1 muestra/60 s * 2,628,000 segundos/mes)

Si una serie temporal escribe valores de distribución, cada valor puede contener 2 + n muestras, donde n es la cantidad de buckets en el histograma. La cantidad de muestras escritas en un mes depende de la cantidad de buckets en los histogramas y de la frecuencia con la que se escriben los valores.

Por ejemplo, cada instancia de un histograma de 50 bucket puede contener 52 muestras. Si los valores se escriben una vez cada 60 segundos, un histograma de 50 bucket escribe como máximo 2,277,600 muestras por mes. Si el histograma tiene 100 buckets y se escribe una vez cada 60 segundos, cada histograma puede contener 102 muestras y escribe, como máximo, 4,467,600 muestras por mes.

La mayoría de las series temporales de distribución contienen menos de la cantidad máxima de muestras. En la práctica, entre el 20% y el 40% de los buckets de histograma están vacíos. Este porcentaje es incluso más alto para los usuarios con histogramas dispersos, como los generados por Istio.

Cuando se cuentan muestras para la fijación de precios, solo se incluyen los buckets con valores no vacíos. La cantidad máxima de muestras por histograma es 2 + n . Si el 25% de tus buckets están vacíos, entonces la cantidad esperada de muestras es 2 + .75n por histograma. Si el 40% de tus buckets están vacíos, entonces la cantidad esperada de muestras es 2 + .60n por histograma.

En los siguientes cálculos y la tabla de resumen, se muestra la cantidad máxima de muestras y las cantidades esperadas más realistas de muestras:

  • Para valores de histogramas de 50 bucket escritos cada 15 segundos:

    • Tasa de escritura: 1 valor/15 s
    • Muestras máximas:
      • Por histograma: 52
      • Por mes: 9,110,400 (52 * 1 valor/15 s * 2,628,000 segundos/mes)
    • Muestras esperadas, suponiendo un 25% de vacío:
      • Según el histograma: 39.5 (2 + .75(50), o 2 + (50 - 12.5))
      • Por mes: 6,920,400 (39.5 * 1 valor/15 s * 2,628,000 segundos/mes)
    • Muestras esperadas, suponiendo un 40% de vacío:
      • Según el histograma: 32 (2 + .6(50), o 2 + (50 - 20))
      • Por mes: 5,606,400 (32 * 1 valor/15 s * 2,628,000 segundos/mes)

  • Para valores de histogramas de 50 depósitos escritos cada 60 segundos:

    • Tasa de escritura: 1 valor/60 s
    • Máximo de muestras:
      • Por histograma: 52
      • Por mes: 2,277,600 (52 * 1 valor/60 s * 2,628,000 segundos/mes)
    • Muestras esperadas, suponiendo un 25% de vacío:
      • Según el histograma: 39.5 (2 + .75(50), o 2 + (50 - 12.5))
      • Por mes: 1,730,100 (39.5 * 1 valor/60 s * 2,628,000 segundos/mes)
    • Muestras esperadas, suponiendo un 40% de vacío:
      • Según el histograma: 32 (2 + .6(50), o 2 + (50 - 20))
      • Por mes: 1,401,600 (32 * 1 valor/60 s * 2,628,000 segundos/mes)

  • Para valores de histogramas de 100 bucket escritos cada 15 segundos:

    • Tasa de escritura: 1 valor/15 s
    • Muestras máximas:
      • Por histograma: 102
      • Por mes: 17,870,400 (102 * 1 valor/15 s * 2,628,000 segundos/mes)
    • Muestras esperadas, suponiendo un 25% de vacío:
      • Según el histograma: 77 (2 + .75(100), o 2 + (100 - 25))
      • Por mes: 13,490,400 (77 * 1 valor/15 s * 2,628,000 segundos/mes)
    • Muestras esperadas, suponiendo un 40% de vacío:
      • Según el histograma: 62 (2 + .6(100), o 2 + (100 - 40))
      • Por mes: 10,862,400 (62 * 1 valor/15 s * 2,628,000 segundos/mes)

  • Para valores de histogramas de 100 bucket escritos cada 60 segundos:

    • Tasa de escritura: 1 valor/60 s
    • Muestras máximas:
      • Por histograma: 102
      • Por mes: 4,467,600 (102 * 1 valor/60 s * 2,628,000 segundos/mes)
    • Muestras esperadas, suponiendo un 25% de vacío:
      • Según el histograma: 77 (2 + .75(100), o 2 + (100 - 25))
      • Por mes: 3,372,600 (77 * 1 valor/60 s * 2,628,000 segundos/mes)
    • Muestras esperadas, suponiendo un 40% de vacío:
      • Según el histograma: 62 (2 + 0 .6(100), o 2 + (100 - 40))
      • Por mes: 2,715,600 (62 * 1 valor/60 s * 2,628,000 segundos/mes)

En la siguiente tabla, se resume la información mencionada antes:

Recuento de buckets Tasa de escritura Muestras por mes
(máx.)		 Muestras por mes
(25% vacío)		 Muestras por mes
(40% vacío)
50 1 muestra/15s 9,110,400 6,920,400 5,606,400
50 1 muestra/60s 2,277,600 1,730,100 1,401,600
100 1 muestra/15s 17,870,400 13,490,400 10,862,400
100 1 muestra/60s 4,467,600 3,372,600 2,715,600

Ejemplos

Para estimar los precios, cuenta la cantidad de muestras escritas en un mes y aplica los valores de precios. Las muestras se cobran por millón para rangos apilados de la siguiente manera:

Rango de transferencia Servicio administrado para Prometheus Máximo para el rango
Hasta 50,000 millones $0.06/millón USD 3,000.00
De 50,000 millones a 250,000 millones $0.048/millón USD 9,600.00
De 250,000 millones a 500,000 millones $0.036/millón USD 9,000.00
Más de 500,000 millones $0.024/millón  

En el resto de esta sección, se describen posibles situaciones.

Situación 1: Tienes 100 contenedores y cada uno escribe 1,000 series escalares escalares.

Variante A: Si cada serie temporal se escribe cada 15 segundos (1 muestra/15), la cantidad de muestras escritas por mes es 17,520,000,000 (175,200 muestras por mes). * 1,000 series temporales * 100 contenedores) o 17,520 millones.

Variante B: Si cada serie temporal se escribe cada 60 segundos (1 muestra/60), la cantidad de muestras escritas por mes es 4,380,000,000 (43,800 muestras por mes) * 1,000 series temporales * 100 contenedores) o 4,380 millones.

En ambos casos, hay menos de 50,000 millones de muestras, por lo que solo se aplica la primera tarifa. No se cobran muestras a las otras tarifas.

Variante Muestras transferidas Rango de transferencia Servicio administrado para Prometheus
($0.06, $0.048, $0.036, $0.024)
A (1 muestra/15 s)



Total 		17,520 millones



17,520 millones 		Hasta 50,000 millones
Hasta 250,000 millones
Hasta 500,000 millones
Más de 500,000 millones 		$1,051.20



$1,051.20
B (1 muestra/60 s)



Total 		4,380 millones



4,380 millones 		Hasta 50,000 millones
Hasta 250,000 millones
Hasta 500,000 millones
Más de 500,000 millones 		$262.80



$262.80

Situación 2: Tienes 1,000 contenedores y cada uno escribe 1,000 series temporales de escalares.

Variante A: Si cada serie temporal se escribe cada 15 segundos (1 muestra/15), la cantidad de muestras escritas por mes es 175,200,000,000 o 175,200 millones:

  • Los primeros 50,000 millones de muestras se cobran a la primera tarifa.
  • Los 125,200 millones restantes de muestras se cobran con la segunda tarifa.
  • No hay muestras cobradas a las otras tarifas.

Variante B: Si cada serie temporal se escribe cada 60 segundos (1 muestra/60), la cantidad de muestras escritas por mes es 43,800,000,000, o 43,800 millones. Este valor mensual es inferior a 50,000 millones de muestras, por lo que solo se aplica la primera tarifa.

Variante Muestras transferidas Rango de transferencia Servicio administrado para Prometheus
($0.06, $0.048, $0.036, $0.024)
A (1 muestra/15 s)



Total 		50,000 millones
125,200 millones


175,200 millones 		Hasta 50,000 millones
Hasta 250,000 millones
Hasta 500,000 millones
Más de 500,000 millones 		$3,000.00
$6,009.60


$9,009.60
B (1 muestra/60 s)



Total 		43,800 millones



43,800 millones 		Hasta 50,000 millones
Hasta 250,000 millones
Hasta 500,000 millones
Más de 500,000 millones 		$2,628.00



$2,628.00

Situación 3: Tienes 100 contenedores y cada uno escribe 1,000 series temporales de distribución de 100 buckets. Esperas que el 25% de los depósitos esté vacío.

Variante A: Si cada serie temporal se escribe cada 15 segundos (1 muestra/15), la cantidad de muestras escritas por mes es 1,349,040,000,000 (13,490,400 muestras por mes). * 1,000 series temporales * 100 contenedores) o 1,349,040 millones.

  • Los primeros 50,000 millones de muestras se cobran a la primera tarifa.
  • Los siguientes 200,000 millones de muestras se cobran con la segunda tarifa.
  • Los siguientes 250,000 millones de muestras se cobran con la tercera tarifa.
  • Los 749,040 millones de muestras restantes se cobran con la cuarta tarifa.

Variante B: Si cada serie temporal se escribe cada 60 segundos (1 muestra/60), la cantidad de muestras escritas por mes es 337,260,000,000 (3,372,600 muestras por mes) * 1,000 series temporales * 100 contenedores) o 337,260 millones.

  • Los primeros 50,000 millones de muestras se cobran a la primera tarifa.
  • Los siguientes 200,000 millones de muestras se cobran con la segunda tarifa.
  • Los 87,260 millones restantes de muestras se cobran en función de la tercera tarifa.
Variante Muestras transferidas Rango de transferencia Servicio administrado para Prometheus
($0.06, $0.048, $0.036, $0.024)
A (1 muestra/15 s)



Total 		50,000 millones
200,000 millones
250,000 millones
749,040 millones
1,349,040 millones 		Hasta 50,000 millones
Hasta 250,000 millones
Hasta 500,000 millones
Más de 500,000 millones 		$3,000.00
$9,600.00
$9,000.00
$17,976.96
$39,576.96
B (1 muestra/60 s)



Total 		50,000 millones
200,000 millones
87,260 millones

337,260 millones 		Hasta 50,000 millones
Hasta 250,000 millones
Hasta 500,000 millones
Más de 500,000 millones 		$3,000.00
$9,600.00
$3,141.36

$15,741.36

Situación 4: Tienes 1,000 contenedores y cada uno escribe 10,000 series temporales de distribución de 100 buckets. Esperas que el 40% de los depósitos esté vacío.

Variante A: Si cada serie temporal se escribe cada 15 segundos (1 muestra/15), la cantidad de muestras escritas por mes es 108,624,000,000,000 (10,862,400 muestras por mes). * 10,000 series temporales * 1,000 contenedores o 108,624,000 millones.

  • Los primeros 50,000 millones de muestras se cobran a la primera tarifa.
  • Los siguientes 200,000 millones de muestras se cobran con la segunda tarifa.
  • Los siguientes 250,000 millones de muestras se cobran con la tercera tarifa.
  • Los 108,124,000 millones restantes de muestras se cobran con la cuarta tarifa.

Variante B: Si cada serie temporal se escribe cada 60 segundos (1 muestra/60), la cantidad de muestras escritas por mes es 27,156,000,000,000 (2,715,600 muestras por mes). * 10,000 series temporales * 1,000 contenedores, o 27,156,000 millones.

  • Los primeros 50,000 millones de muestras se cobran a la primera tarifa.
  • Los siguientes 200,000 millones de muestras se cobran con la segunda tarifa.
  • Los siguientes 250,000 millones de muestras se cobran con la tercera tarifa.
  • Los 26,656,000 millones restantes de muestras se cobran con la cuarta tarifa.
Variante Muestras transferidas Rango de transferencia Servicio administrado para Prometheus
($0.06, $0.048, $0.036, $0.024)
A (1 muestra/15 s)



Total 		50,000 millones
200,000 millones
250,000 millones
108,124,000 millones
108,624,000 millones 		Hasta 50,000 millones
Hasta 250,000 millones
Hasta 500,000 millones
Más de 500,000 millones 		$3,000.00
$9,600.00
$9,000.00
$2,594,976.00
$2,616,576.00
B (1 muestra/60 s)



Total 		50,000 millones
200,000 millones
250,000 millones
26,656,000 millones
27,156,000 millones 		Hasta 50,000 millones
Hasta 250,000 millones
Hasta 500,000 millones
Más de 500,000 millones 		$3,000.00
$9,600.00
$9,000.00
$639,744.00
$661,344.00

Situación 5: Tienes lo siguiente:

  • 1,000 contenedores, cada uno escribe 1,000 series temporales de escalares cada 15 segundos. La cantidad de muestras escritas por mes es 175,200,000,000 o 175,200 millones. (Situación 2, variante A)

  • 1,000 contenedores, cada uno escribe 10,000 series temporales de distribución de 100 bucket cada 15 segundos. Esperas que el 40% de los depósitos esté vacío. La cantidad de muestras escritas por mes es 108,624,000,000,000 o 108,624,000 millones. (Situación 4, variante A)

La cantidad total de muestras por mes es 108,799,200 millones (175,200 millones + 108,624,000 millones).

  • Los primeros 50,000 millones de muestras se cobran a la primera tarifa.
  • Los siguientes 200,000 millones de muestras se cobran con la segunda tarifa.
  • Los siguientes 250,000 millones de muestras se cobran con la tercera tarifa.
  • Los 108,299,200 millones de muestras restantes se cobran con la cuarta tarifa.
Variante Muestras transferidas Rango de transferencia Servicio administrado para Prometheus
($0.06, $0.048, $0.036, $0.024)
2A + 4A



Total 		50,000 millones
200,000 millones
250,000 millones
108,299,200 millones
108,799,200 millones 		Hasta 50,000 millones
Hasta 250,000 millones
Hasta 500,000 millones
Más de 500,000 millones 		$3,000.00
$9,600.00
$9,000.00
$2,599,180.80
$2,620,780.80

Precios para la ejecución de verificaciones de tiempo de actividad (fecha de vigencia: 1 de octubre de 2022)

Los cargos de Monitoring se aplican por cada ejecución regional de una verificación de tiempo de actividad, más allá de la asignación mensual gratuita de 1 millón de ejecuciones. Una verificación que se ejecuta en tres regiones se considera como tres ejecuciones.

El costo de la ejecución de la verificación de tiempo de actividad es de $0.30 por 1,000 ejecuciones. El cargo aparece en tu factura como SKU “CA14-D3DE-E67F” para “Verificaciones de tiempo de actividad de supervisión”.

En los siguientes ejemplos, se muestra cómo estimar los costos de ejecutar verificaciones de tiempo de actividad. Estos ejemplos tienen el propósito de ilustrar técnicas de cálculo, no de proporcionar datos de facturación.

Cuenta las ejecuciones de las verificaciones de tiempo de actividad

Para estimar el costo de las verificaciones de tiempo de actividad, debes saber cuántas ejecuciones regionales se producen en un mes. Los cargos de supervisión son de $0.30 por 1,000 ejecuciones, con un cupo mensual gratuito de 1 millón de ejecuciones.

Para estimar el costo de tus verificaciones de tiempo de actividad, puedes usar el siguiente cálculo:

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

Para cada verificación de tiempo de actividad, la cantidad de ejecuciones depende de las siguientes opciones de configuración:

  • La frecuencia con la que se ejecuta la verificación de tiempo de actividad: cada minuto, 5 minutos, 10 minutos o 15 minutos.

  • La cantidad de regiones en las que se ejecuta la verificación de tiempo de actividad.

  • La cantidad de objetivos para los que se configuró la verificación de tiempo de actividad. Si la verificación de tiempo de actividad está configurada para una sola VM, la cantidad de objetivos es 1. Si la verificación de tiempo de actividad está configurada para un grupo de recursos, la cantidad de objetivos es la cantidad de recursos en el grupo.

Cuando configuras una verificación de tiempo de actividad, especificas una ubicación para la verificación de tiempo de actividad y cada ubicación se asigna a una o más regiones. En la siguiente tabla, se muestran las ubicaciones válidas para las verificaciones de tiempo de actividad y las regiones a las que se asignan:

Ubicación de la configuración de la verificación de tiempo de actividad Incluye regiones de Google Cloud
ASIA_PACIFIC asia-southeast1
EUROPE europe-west1
SOUTH_AMERICA southamerica-east1
USA us-central1, us-east4, us-west1
GLOBAL Todas las regiones incluidas por otras ubicaciones

Debes configurar tus verificaciones de tiempo de actividad para que se ejecuten en al menos tres regiones.

Para estimar la cantidad de ejecuciones de una verificación de tiempo de actividad, debes saber cuántas regiones abarca la ubicación de la verificación de tiempo de actividad:

  • ASIA_PACIFIC, EUROPE y SOUTH_AMERICA incluyen 1 región cada uno.
  • USA incluye 3 regiones.
  • GLOBAL incluye 6 regiones.

En un mes, hay aproximadamente 730 horas (365 días / 12 meses × 24 horas) o 43,800 minutos.

  • Una verificación de tiempo de actividad configurada para ejecutarse una vez por minuto en USA se ejecuta en 3 regiones. Si esta verificación de tiempo de actividad está configurada para verificar una sola VM, entonces se ejecuta 131,400 veces (3 * 43,800) en un mes. Si la verificación está configurada para verificar un grupo de recursos de 10 miembros, la verificación de tiempo de actividad se ejecuta 1,314,000 (10 * 131,400) veces en un mes.

  • Una verificación de tiempo de actividad configurada para ejecutarse una vez por minuto en ASIA_PACIFIC, EUROPE y USA se ejecuta en 5 regiones. Esta verificación de tiempo de actividad se ejecuta 219,000 veces en un mes si se configura para un solo objetivo.

En la siguiente tabla, se muestran los recuentos de ejecución por hora y por mes de una sola verificación de tiempo de actividad configurada para ejecutarse con diferentes frecuencias en diferentes cantidades de regiones:

Frecuencia de ejecución de la verificación, una vez cada:
 		 Cantidad de regiones
 		 Ejecuciones por hora
por objetivo		 Ejecuciones mensuales
por objetivo
1 minuto 3
4
5
6 		180
240
300
360 		131,400
175,200
219,000
262,800
5 minutos 3
4
5
6 		36
48
60
72 		26,280
35,040
43,000
52,660
10 minutos 3
4
5
6 		18
24
30
36 		13,140
17,520
21,900
26,280
15 minutos 3
4
5
6 		12
16
20
24 		8,760
11,680
14,600
17,520

Ejemplos

Para estimar los precios, determina tus ejecuciones mensuales totales y resta 1,000,000. Cualquier ejecución restante se cobra a USD 0.30 por 1,000 ejecuciones, así que multiplica las ejecuciones restantes por 0 .0003.

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

Situación 1: Tienes 1 verificación de tiempo de actividad en la ubicación USA que verifica 1 VM una vez por minuto. Esta verificación se ejecuta en 3 regiones. La verificación se ejecuta 131,400 veces al mes y no tiene costo.

Ejecuciones mensuales totales
 		 Ejecuciones mensuales facturables
(más de 1,000,000)		 Costo
($0.30 por cada 1,000 ejecuciones)
131,400 0 $0.00

Escenario 2: Tienes 1 verificación de tiempo de actividad en la ubicación USA que verifica un grupo de recursos de 10 miembros una vez por minuto. Esta verificación se ejecuta en 3 regiones. La verificación se ejecuta 10 * 131,400 veces al mes y cuesta USD 94.20 por mes. La única diferencia entre esta situación y la 1 es la cantidad de objetivos.

Ejecuciones mensuales totales
 		 Ejecuciones mensuales facturables
(más de 1,000,000)		 Costo
($0.30 por cada 1,000 ejecuciones)
1,314,000 (10 objetivos) 314,000 USD 94.20

Situación 3: Tienes 10 GLOBAL verificaciones de tiempo de actividad, cada una de las cuales verifica 1 VM una vez por minuto. Estas verificaciones se ejecutan en 6 regiones, por lo que cada una se ejecuta 262,800 veces al mes. El total de ejecuciones mensuales es 2,628,000 (10 * 262,800). En esta situación, el costo es de USD 488.40 por mes.

Ejecuciones mensuales totales
 		 Ejecuciones mensuales facturables
(más de 1,000,000)		 Costo
($0.30 por cada 1,000 ejecuciones)
2,628,000 1,628,000 USD 488.40

Situación 4: Tienes 5 verificaciones de tiempo de actividad en la ubicación USA que verifican 1 VM una vez cada 5 minutos. Estas verificaciones se ejecutan en 3 regiones, por lo que cada una se ejecuta 26,280 veces al mes. El total de ejecuciones mensuales para este conjunto de verificaciones es 105,120 (4 * 26,280).

También tienes 2 verificaciones de tiempo de actividad GLOBALque verifican 1 VM una vez cada 15 minutos. Estas verificaciones se ejecutan en 6 regiones, por lo que cada una se ejecuta 17,520 veces al mes. El total de ejecuciones mensuales para este conjunto de verificaciones es de 35,040 (2 * 17,520).

Tu total de ejecuciones mensuales es de 140,160 (105,120 + 35,040). Este escenario no tiene costo.

Ejecuciones mensuales totales
 		 Ejecuciones mensuales facturables
(más de 1,000,000)		 Costo
($0.30 por cada 1,000 ejecuciones)
140,160 0 $0.00

Precios para la ejecución de monitores sintéticos (fecha de entrada en vigencia: 1 de noviembre de 2023)

Cloud Monitoring cobra por cada ejecución de un monitor sintético, más allá del cupo gratuito por mes de 100 ejecuciones por cuenta de facturación. Por ejemplo, si creas 3 monitores sintéticos y configuras cada uno de ellos para que se ejecuten cada 5 minutos, tu cantidad total de ejecuciones por mes será de 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

Para determinar la cantidad de ejecuciones facturables, resta la asignación gratuita de la cantidad total de ejecuciones y, luego, multiplica el resultado por el costo:

Ejecuciones mensuales totales
 		 Ejecuciones mensuales facturables
(más de 100 ejecuciones por cuenta de facturación)		 Costo
($1.20 por cada 1,000 ejecuciones)
26,784 26,684 USD 32.02

Precios de las alertas

A partir de abril de 2026, Cloud Monitoring comenzará a cobrar por las alertas. El modelo de precios es el siguiente:

  • $1.50 por mes por cada condición en una política de alertas.
  • $0.35 por 1,000,000 de series temporales devueltas por la consulta de una condición de política de alertas de métricas.

En esta sección, se proporciona la siguiente información:

Definiciones

  • Condición: La condición de una política de alertas describe cuándo un recurso, o un grupo de recursos, se encuentra en un estado que requiere una respuesta.

    El cargo por cada condición es de $1.50 por mes. Para dejar de pagar por una condición, debes borrar la política de alertas. Posponer o inhabilitar la política no impide que se te cobre.

  • Políticas de alertas basadas en métricas y registros: Las políticas de alertas que usan cualquier tipo de condición, excepto las condiciones de coincidencia de registros, son políticas de alertas basadas en métricas; las condiciones de las políticas de alertas basadas en métricas devuelven series temporales. Durante cada período de ejecución, las condiciones de las políticas de alertas de métricas ejecutan sus consultas en el almacén de datos de Cloud Monitoring. Las series temporales que se muestran se evalúan en función de un umbral para determinar si se activa la política de alertas.

    Las políticas de alertas basadas en registros usan condiciones de coincidencia de registros. Las condiciones de registro y coincidencia no devuelven series temporales.

  • Período de ejecución: La frecuencia con la que Cloud Monitoring ejecuta tu condición. Para la mayoría de los tipos de condiciones, este valor es de 30 segundos y no se puede cambiar. Las condiciones que usan una consulta de PromQL pueden establecer este período. Para obtener más información, consulta Aumenta la duración del período de ejecución (solo PromQL).

  • Serie temporal devuelta: Durante cada período de ejecución, una política de alertas de métricas ejecuta la consulta de su condición en el almacén de datos de Cloud Monitoring. Cloud Monitoring devuelve datos de series temporales como respuesta a cada consulta. Cada serie temporal de la respuesta se cuenta como una serie temporal devuelta.

    La cantidad de series temporales que se muestran en un mes se determina en función de tres factores:

    • La forma y el alcance de los datos subyacentes.
    • Los filtros y las agregaciones que usas en la consulta de tu condición.
    • El período de ejecución.

    Por ejemplo, considera una configuración en la que tienes lo siguiente:

    • 100 máquinas virtuales (VM), donde cada VM pertenece a un servicio.
    • Cada VM emite una métrica, metric_name, que tiene una etiqueta con 10 valores.
    • Cinco servicios en total.

    Dado que tienes 100 VM, cada una de las cuales puede generar 10 series temporales (una para cada valor de etiqueta), tienes un total de 1,000 series temporales subyacentes. Cada VM también contiene una etiqueta similar a los metadatos que registra a cuál de los cinco servicios pertenece la VM.

    Puedes configurar tus políticas de alertas de las siguientes maneras con PromQL, donde cada configuración da como resultado un número diferente de series temporales que se devuelven por período de ejecución:

    Configuración Consulta de PromQL Serie temporal devuelta por período
    Sin agregación rate(metric_name[1m]) 1,000
    Agregar a la VM sum by (vm) (rate(metric_name[1m])) 100
    Agregación al valor de la etiqueta sum by (label_key) (rate(metric_name[1m])) 10
    Agregar al servicio sum by (service) (rate(metric_name[1m])) 5
    Agregación para etiquetar el valor y el servicio sum by (service, label_key) (rate(metric_name[1m]) 50
    Agregar a la flota sum (rate(metric_name[1m])) 1
    Filtra y agrega a una VM sum (rate(metric_name{vm="my_vm_name"}[1m])) 1
    Filtra y agrega a un servicio sum (rate(metric_name{service="my_service_name"}[1m])) 1

Ejemplos de precios

Los siguientes ejemplos se realizan en un mes de 30 días, lo que da como resultado los siguientes períodos de evaluación:

  • 86,400 períodos de ejecución de 30 segundos por mes
  • 172,800 períodos de ejecución de 15 segundos por mes (solo consultas de PromQL)

Ejemplo 1: Una política, agregada a la VM, 30 segundos

En este ejemplo, usa los siguientes parámetros de configuración:

Datos

  • 100 VM
  • Cada VM emite una métrica, metric_name
  • metric_name tiene una etiqueta, que tiene 10 valores
Política de alertas
  • Una condición de alerta
  • La condición se agrega al nivel de la VM
  • Período de ejecución de 30 segundos
Costos resultantes
  • Costo de la condición: 1 condición * $1.50 por mes = $1.50 por mes
  • Costo de las series temporales: 100 series temporales devueltas por período * 86,400 períodos por mes = 8.6 millones de series temporales devueltas por mes * $0.35 por millón de series temporales = $3.02 por mes
  • Costo total: USD 4.52 por mes

Ejemplo 2: 100 políticas (una por VM), agregadas a la VM, 30 segundos

En este ejemplo, usa los siguientes parámetros de configuración:

Datos

  • 100 VM
  • Cada VM emite una métrica, metric_name
  • metric_name tiene una etiqueta, que tiene 10 valores
Políticas de alertas
  • 100 condiciones
  • Cada condición se filtra y se agrega a una VM
  • Período de ejecución de 30 segundos
Costos resultantes
  • Costo de las condiciones: 100 condiciones * USD 1.50 por mes = USD 150 por mes
  • Costo de las series temporales: 100 condiciones * 1 serie temporal devuelta por condición por período * 86,400 períodos por mes = 8.6 millones de series temporales devueltas por mes * $0.35 por millón de series temporales = $3.02 por mes
  • Costo total: $153.02 por mes

Ejemplo 3: Una política, agregada a la VM, 15 segundos

En este ejemplo, usa los siguientes parámetros de configuración:

Datos

  • 100 VM
  • Cada VM emite una métrica, metric_name
  • metric_name tiene una etiqueta, que tiene 10 valores
Política de alertas
  • Una condición de alerta de PromQL
  • La condición se agrega al nivel de la VM
  • Período de ejecución de 15 segundos
Costos resultantes
  • Costo de la condición: 1 condición * $1.50 por mes = $1.50 por mes
  • Costo de las series temporales: 100 series temporales devueltas por período * 172,800 períodos por mes = 17.3 millones de series temporales devueltas por mes * $0.35 por millón de series temporales = $6.05 por mes
  • Costo total: $7.55 por mes

Ejemplo 4: Agrega una política a cada servicio, 30 segundos

En este ejemplo, usa los siguientes parámetros de configuración:

Datos

  • 100 VMs, donde cada VM pertenece a un servicio
  • Cinco servicios en total
  • Cada VM emite una métrica, metric_name
  • metric_name tiene una etiqueta, que tiene 10 valores
Política de alertas
  • Una condición
  • La condición se agrega al nivel de servicio
  • Período de ejecución de 30 segundos
Costos resultantes
  • Costo de la condición: 1 condición * $1.50 por mes = $1.50 por mes
  • Costo de las series temporales: 5 series temporales devueltas por período * 86,400 períodos por mes = 432,000 series temporales devueltas por mes * $0.35 por millón de series temporales = $0.14 por mes
  • Costo total: $1.64 por mes

Ejemplo 5: Agrega una política a la VM; cardinalidad subyacente más alta por VM, 30 segundos

En este ejemplo, usa los siguientes parámetros de configuración:

Datos

  • 100 VM
  • Cada VM emite una métrica, metric_name
  • metric_name tiene 100 etiquetas con 1,000 valores cada una
Política de alertas
  • Una condición
  • La condición se agrega al nivel de la VM
  • Período de ejecución de 30 segundos
Costos resultantes
  • Costo de la condición: 1 condición * $1.50 por mes = $1.50 por mes
  • Costo de las series temporales: 100 series temporales devueltas por período * 86,400 períodos por mes = 8.5 millones de series temporales devueltas por mes * $0.35 por millón de series temporales = $3.02 por mes
  • Costo total: USD 4.52 por mes

Ejemplo 6: Agrega una política a la VM; une dos métricas en una condición, 30 segundos

En este ejemplo, usa los siguientes parámetros de configuración:

Datos

  • 100 VM
  • Cada VM emite dos métricas, metric_name_1 y metric_name_2
  • Ambas métricas tienen una etiqueta con 10 valores cada una
Política de alertas
  • Una condición
  • La condición se agrega al nivel de la VM
  • La condición usa un operador OR para unir las métricas
  • Período de ejecución de 30 segundos
Costos resultantes
  • Costo de la condición: 1 condición * $1.50 por mes = $1.50 por mes
  • Costo de las series temporales: 2 métricas * 100 series temporales devueltas por métrica por período *  8,6400 períodos por mes = 17.3 millones de series temporales devueltas por mes *  USD 0.35 por millón de series temporales = USD 6.05 por mes
  • Costo total: $7.55 por mes

Ejemplo 7: 100 políticas de alertas basadas en registros

En este ejemplo, usa la siguiente configuración:

Políticas de alertas

  • 100 condiciones (una condición por política de alertas basada en registros)
Costos resultantes
  • Costo de la condición: 100 condiciones * USD 1.50 por mes = USD 150.00 por mes
  • Costo de series temporales: $0 (Las políticas de alertas basadas en registros no devuelven series temporales.)
  • Costo total: $150.00 por mes

Sugerencias para reducir la factura de alertas

Cuando configures tus políticas de alertas basadas en métricas, usa las siguientes sugerencias para reducir el costo de tus facturas de alertas.

Consolida las políticas de alertas para operar en más recursos

Debido al costo de $1.50 por condición, es más rentable usar una política de alertas para supervisar varios recursos que usar una política de alertas para supervisar cada recurso. Por ejemplo, compara el Ejemplo 1 con el Ejemplo 2: En ambos ejemplos, supervisas la misma cantidad de recursos. Sin embargo, el ejemplo 2 usa 100 políticas de alertas, mientras que el ejemplo 1 usa solo una política de alertas. Como resultado, el ejemplo 1 es casi $150 más barato por mes.

Agrupa solo en el nivel que necesitas para alertar

La agregación a niveles más altos de detalle genera costos más altos que la agregación a niveles más bajos de detalle. Por ejemplo, agregar al nivel del proyecto de Google Cloud es más económico que agregar al nivel del clúster, y agregar al nivel del clúster es más económico que agregar al nivel del clúster y del espacio de nombres.

Por ejemplo, compara el Ejemplo 1 con el Ejemplo 4: Ambos ejemplos operan con los mismos datos subyacentes y tienen una única política de alertas. Sin embargo, debido a que la política de alertas del ejemplo 4 se agrega al servicio, es menos costosa que la política de alertas del ejemplo 1, que se agrega de forma más detallada a la VM.

Además, compara el ejemplo 1 con el ejemplo 5: En este caso, la cardinalidad de la métrica en el ejemplo 5 es 10,000 veces mayor que la cardinalidad de la métrica en el ejemplo 1. Sin embargo, debido a que la política de alertas en el ejemplo 1 y en el ejemplo 5 se agrega a la VM y porque la cantidad de VMs es la misma en ambos ejemplos, los ejemplos son equivalentes en precio.

Cuando configures tus políticas de alertas, elige los niveles de agregación que mejor se adapten a tu caso de uso. Por ejemplo, si te interesa recibir alertas sobre el uso de CPU, puedes agregar al nivel de VM y CPU. Si te interesa alertar sobre la latencia por extremo, entonces deberías agregar al nivel del extremo.

No generes alertas sobre datos sin procesar ni agregados.

El Monitoring usa un sistema de métricas dimensionales, en el que cualquier métrica tiene una cardinalidad total igual a la cantidad de recursos supervisados multiplicada por la cantidad de combinaciones de etiquetas en esa métrica. Por ejemplo, si tienes 100 VM que emiten una métrica y esa métrica tiene 10 etiquetas con 10 valores cada una, la cardinalidad total es 100 * 10 * 10 = 10,000.

Como resultado de cómo se escala la cardinalidad, las alertas sobre datos sin procesar pueden ser extremadamente costosas. En el ejemplo anterior, se muestran 10,000 series temporales para cada período de ejecución. Sin embargo, si agregas a la VM, solo se devolverán 100 series temporales por período de ejecución, independientemente de la cardinalidad de la etiqueta de los datos subyacentes.

Las alertas sobre datos sin procesar también te ponen en riesgo de aumentar las series temporales cuando tus métricas reciben etiquetas nuevas. En el ejemplo anterior, si un usuario agrega una etiqueta nueva a la métrica, entonces la cardinalidad total aumenta a 100 * 11 * 10 = 11,000 series temporales. En este caso, el número de series temporales que se devuelven aumenta en 1,000 cada período de ejecución, aunque la política de alertas no cambia. Si, en cambio, agregas a la VM, entonces, a pesar de la cardinalidad subyacente aumentada, solo se devolverán 100 series temporales.

Filtra las respuestas innecesarias

Configura las condiciones para evaluar solo los datos que son necesarios para tus necesidades de alertas. Si no vas a tomar medidas para corregir algo, excluyelo de tus políticas de alertas. Por ejemplo, es probable que no necesites alertas en la VM de desarrollo de un pasante.

Para reducir las alertas y los costos innecesarios, puedes filtrar las series temporales que no son importantes. Puedes usar las etiquetas de metadatos de Google Cloud para etiquetar los recursos con categorías y, luego, filtrar las categorías de metadatos que no necesitas.

Usa operadores de flujo superior para reducir la cantidad de series temporales que se devuelven

Si tu condición usa una consulta de PromQL o MQL, puedes usar un operador de streams principales para seleccionar una cantidad de las series temporales que se devuelven con los valores más altos:

Por ejemplo, una cláusula topk(metric, 5) en una consulta de PromQL limita la cantidad de series temporales que se devuelven a cinco en cada período de ejecución.

Limitarse a un número superior de series temporales podría provocar la pérdida de datos y alertas defectuosas, como las siguientes:

  • Si más de N series temporales incumplen el umbral, perderás los datos fuera de las N series temporales principales.
  • Si una serie temporal infractora se produce fuera de las series temporales de los N primeros lugares, es posible que los incidentes se cierren automáticamente a pesar de que las series temporales excluidas siguen incumpliendo el umbral.
  • Es posible que tus consultas de condición no te muestren contexto importante, como series temporales de referencia que funcionan según lo previsto.

Para mitigar esos riesgos, elige valores grandes para N y usa el operador top-streams solo en políticas de alertas que evalúen muchas series temporales, como alertas para contenedores de Kubernetes individuales.

Aumenta la duración del período de ejecución (solo PromQL)

Si tu condición usa una consulta de PromQL, puedes modificar la duración de tu período de ejecución estableciendo el evaluationInterval campo en la condición.

Los intervalos de evaluación más largos dan como resultado menos series temporales por mes; por ejemplo, una consulta de condición con un intervalo de 15 segundos se ejecuta el doble de veces que una consulta con un intervalo de 30 segundos, y una consulta con un intervalo de 1 minuto se ejecuta la mitad de veces que una consulta con un intervalo de 30 segundos.

Rechazando

Si tienes un contrato de Google Cloud existente que no vence hasta abril de 2026, puedes solicitar una exención al equipo de facturación de alertas de Cloud Monitoring para retrasar la facturación de alertas hasta que venza el contrato. Las exenciones para los clientes con contratos activos se considerarán caso por caso.

Puedes solicitar una excepción hasta el 1 de noviembre de 2024. Para solicitar una exención de facturación hasta la renovación del contrato, completa el formulario de solicitud de exención de facturación.

Error Reporting

Los datos de error se pueden informar a tu proyecto de Google Cloud mediante la API de Error Reporting o la API de Cloud Logging.

No se aplican cargos por usar Error Reporting. Sin embargo, es posible que incurras en costos de Cloud Logging, ya que Cloud Logging genera y almacena las entradas de registro.

Para ver los límites que se aplican al uso de Error Reporting, consulta Cuotas y límites.

Cloud Profiler

No hay costo asociado con el uso de Cloud Profiler.

Para ver los límites que se aplican en el uso de Profiler, consulta Cuotas y límites.

Cloud Trace

Los cobros de Trace se calculan según la cantidad de intervalos de seguimiento transferidos y analizados. Cuando se envían a Trace los datos de latencia, se empaquetan como un seguimiento compuesto por intervalos, y estos se transfieren mediante el backend de Cloud Trace. Cuando visualizas datos de seguimiento, Cloud Trace analiza los intervalos almacenados. En esta sección, se proporciona la siguiente información:

  • Se definen los intervalos de seguimiento cobrables y no cobrables.
  • Se proporciona un ejemplo de precio.
  • Se proporciona información sobre cómo reducir la transferencia de intervalos de seguimiento.
  • Se proporciona una configuración para una política de alertas que puede notificarte si tu transferencia de intervalos de seguimiento alcanza un límite.

Para obtener información de los precios actuales, consulta Precios de Cloud Trace.

Para ver los límites que se aplican en el uso de Trace, consulta Cuotas y límites.

Para obtener información sobre cómo ver tu uso actual o pasado, consulta Estima tu facturación.

Intervalos de seguimiento no cobrables

Los precios de Cloud Trace no se aplican a los intervalos generados automáticamente por el entorno estándar de App Engine, las funciones de Cloud Run o Cloud Run. Es decir, no se cobra la transferencia de estos seguimientos.

Los seguimientos generados automáticamente no consumen la cuota de la API de Cloud Trace y no se incluyen en las métricas de uso de la API.

Intervalos de seguimiento cobrables

Las transferencias de intervalos de seguimiento, excepto los intervalos que se enumeran en la sección titulada Intervalos de seguimiento no cobrables, son cobrables, y su precio se calcula según el volumen transferido. Esto incluye los intervalos creados por instrumentación que agregas a tu aplicación para el entorno estándar de App Engine.

Ejemplos de precios

Este es un ejemplo del precio de Trace a partir de julio de 2020.

  • Si transfieres 2 millones de intervalos en un mes, el costo es $0. Los primeros 2.5 millones de intervalos que transfieres cada mes son gratuitos.
  • Si transfieres 14 millones de intervalos en un mes, el costo es de $2.30. Los primeros 2.5 millones de intervalos de cada mes son gratuitos. El costo de los intervalos restantes se calcula como 11.5 millones de intervalos × $0.20 por millón de intervalos = $2.30.
  • Si transfieres mil millones de intervalos en un mes, el costo es de $199. Los primeros 2.5 millones de intervalos de cada mes son gratuitos. El costo de los intervalos restantes se calcula como 997.5 millones de intervalos × $0.20 por millón de intervalos = $199.50.

Reduce el uso de seguimientos

Puedes administrar la tasa de muestreo de seguimiento para controlar el volumen de transferencia de intervalos de Trace y así equilibrar la cantidad de seguimientos que necesitas para el análisis de rendimiento con la tolerancia de costos.

Para los sistemas de tráfico alto, la mayoría de los clientes pueden muestrear 1 de cada 1,000 transacciones (o incluso 1 de cada 10,000) y, aún así, tener suficiente información para el análisis de rendimiento.

La tasa de muestreo se configura con las bibliotecas cliente de Cloud Trace.

Alerta de las transferencias de intervalos mensuales

Para crear una política de alertas que se active cuando el número de intervalos transferidos en un mes de Cloud Trace supere el límite definido por el usuario, usa la siguiente configuración.

Nueva condición
Campo
Valor
Recurso y métrica En el menú Recursos, selecciona Global.
En el menú Categorías de métricas, selecciona Facturación.
En el menú Métricas, selecciona Transferencias de seguimiento transferidas mensualmente.
Filtro
Series temporales
Agregación de series temporales		 sum
Ventana progresiva 60 m
Función analítica progresiva max
Configura el activador de alertas
Campo
Valor
Tipo de condición Threshold
Activador de alertas Any time series violates
Posición del umbral Above threshold
Threshold value Tú determinas el valor aceptable.
Período para volver a probar El valor mínimo aceptable es 30 minutos.

GKE Enterprise

No se aplican cargos por los registros y las métricas del sistema de GKE Enterprise. Los registros del plano de control, las métricas del plano de control y un subconjunto seleccionado de métricas de estado de Kube están habilitados de forma predeterminada para los clústeres de GKE en Google Cloud que se registran en el momento de la creación del clúster en un proyecto habilitado para GKE Enterprise. Los registros del plano de control generan cargos de Cloud Logging, mientras que las métricas activadas de forma predeterminada se incluyen sin cargo adicional.

Para ver la lista de registros y métricas de GKE incluidos, consulta Qué registros se recopilan y Métricas disponibles.

En un clúster de Google Distributed Cloud, los registros y las métricas del sistema de GKE Enterprise incluyen lo siguiente:

  • Registros y métricas de todos los componentes en un clúster de administrador
  • Registros y métricas de los componentes de estos espacios de nombres en un clúster de usuario: kube-system, gke-system, gke-connect, knative-serving, istio-system, monitoring-system, config-management-system, gatekeeper-system, cnrm-system

Preguntas frecuentes

¿Qué funciones del producto se pueden usar de forma gratuita?

El uso de los productos de Google Cloud Observability se cobra por volumen de datos. Aparte de los costos de volumen de datos que se describen en esta página, el uso de todas las demás funciones de los productos de Google Cloud Observability es gratuito.

¿Cuánto tendré que pagar?

Para calcular los costos de uso, consulta Calcula tus facturas.

Para obtener ayuda con las preguntas sobre facturación, consulta Preguntas sobre facturación.

¿Cómo entiendo los detalles del uso?

Con el Explorador de métricas, puedes conocer varias métricas que te permiten desglosar y entender el volumen de tus registros y recursos. Consulta Visualiza el uso detallado en el Explorador de métricas para obtener más información.

Si te interesa aprender a administrar tus costos, consulta estas publicaciones del blog:

¿Cómo afectan los permisos de las métricas y los permisos de los registros a la facturación?

En general, los permisos de métricas y los permisos de registro no afectan la facturación. Los registros y las métricas se cobran por el proyecto, la cuenta de facturación, la carpeta o la organización que recibe los datos. El permiso de métricas de un proyecto define el conjunto de recursos cuyas métricas puede ver y supervisar ese proyecto. Cuando defines un permiso de métrica, no afectas el recurso que recibe los datos de la métrica ni haces que los datos se dupliquen. De forma similar, un ámbito de registros solo muestra los recursos que almacenan o enrutan las entradas de registro que quieres ver.

Por ejemplo, supongamos que tu organización tiene 100 máquinas virtuales (VM): 60 VM están alojadas en el proyecto A y 40 VM están en el proyecto B. El Proyecto A recibe y almacena las métricas de sus VM, y se le cobra cuando las métricas son cobrables. De manera similar, Project-B recibe y almacena las métricas de sus VM, y se le cobra cuando las métricas son cobrables. Si creas un permiso de métricas que incluye el Proyecto A y el Proyecto B, puedes ver las métricas combinadas de tus 100 VM. Ahora puedes ver solo las métricas del Proyecto A, solo las del Proyecto B o las métricas combinadas de ambos. Aunque tienes dos formas de ver las métricas del Proyecto A, no hay cambios en la facturación.

¿Qué pasa si utilizo más asignaciones que las establecidas de forma gratuita?

Se te factura automáticamente por cualquier uso que supere las asignaciones gratuitas; no pierdes ningún registro o métrica. Para comprender mejor los costos potenciales, consulta Calcula tus facturas.

Puedes crear una política de alertas que supervise el uso y te avise cuando te acerques al límite de facturación.

Tengo una gran cantidad de registros de Google Cloud que no uso en mis proyectos. Me preocupan los costos de esos registros. ¿Cómo evito pagar por ellos?

Puedes excluir registros para controlar cuáles se transfieren a Logging. Consulta cómo reducir el uso de tus registros para obtener más información.

¿Los servicios que envían registros a mi proyecto recibirán un mensaje de error si se excluyen registros?

No. Los servicios que envían entradas de registro no pueden determinar si las entradas de registro se transfieren a Logging o no.

¿Me cobrarán dos veces por los registros de flujo de la nube privada virtual?

Si envías tus registros de flujo de VPC a Logging, se renuncia a los cargos de generación del registro de flujo de VPC y solo se aplican los cargos de Logging. Sin embargo, si los envías y luego excluyes tus registros de flujo de VPC de Logging, se aplican los cargos de los registros de flujo de VPC. Para obtener más información, consulta la calculadora de precios de Google Cloud y, luego, selecciona la pestaña titulada “Balanceo de cargas y servicios de red de Cloud”.

1 Para determinar los precios, todas las unidades se tratan como medidas binarias, por ejemplo, como mebibytes (MiB, o 220 bytes) gibibytes (GiB o 230 bytes).

2 No se cobran las métricas de Google Cloud ni de GKE Enterprise que se miden en hasta 1 dato por minuto, la resolución más alta en este momento. En el futuro, es posible que se cobre por las métricas medidas en resoluciones más altas.

3 En la actualidad, las métricas de procesos se recopilan a una velocidad predeterminada predefinida de 1 por minuto, lo que no se puede cambiar. Por lo general, estos datos cambian con lentitud, por lo que se realiza un sobremuestreo de estas métricas actualmente. Por lo tanto, el cobro de las métricas de procesos al 5% de la tarifa estándar se alinea con la tasa estándar si las métricas se muestrearon en intervalos de 20 minutos. A los usuarios que recopilan 100 MiB de datos de estas métricas solo se les cobra por 5 MiB.

¿Qué sigue?

Solicita una cotización personalizada

Con los precios de pago por uso de Google Cloud, solo pagas por los servicios que usas. Comunícate con nuestro equipo de Ventas y obtén una cotización personalizada para tu organización.
Comunicarse con Ventas