Precios de Google Cloud Observability

Los precios de Google Cloud Observability te permiten controlar el uso y el gasto. Los precios de los productos de Google Cloud Observability se determinan según el volumen de datos o el uso. Puedes utilizar las asignaciones gratuitas de uso de datos para empezar a utilizar el servicio sin compromisos ni tarifas por adelantado.

En las siguientes tablas se resumen los precios de Cloud Logging, Cloud Monitoring y Cloud Trace.

Resumen de precios de Cloud Logging

Función Precio1 Asignación gratuita al mes Fecha de entrada en vigor
Almacenamiento de registros*
, salvo en el caso de los registros de red de vendedores.		 0, 50 USD/GiB
El cargo único por transmitir registros a los segmentos de almacenamiento de registros para indexarlos, hacer consultas y analizarlos.Incluye hasta 30 días de almacenamiento en segmentos de registros. No se aplican cargos adicionales por consultar y analizar datos de registros.
 Primeros 50 GiB/proyecto/mes 1 de julio del 2018
Almacenamiento de registros de red vendido† 0,25 USD por GiB
Cargo único por transmitir registros de telemetría de red al almacenamiento de segmentos de registros para indexar, consultar y analizar datos.Incluye hasta 30 días de almacenamiento en segmentos de registros. No se aplican cargos adicionales por consultar y analizar datos de registros. 		No aplicable 1 de octubre del 2024
Retención de registros‡ 0,01 USD por GiB al mes para los registros conservados durante más de 30 días (se factura mensualmente según la conservación). Los registros que se conservan durante el periodo de conservación predeterminado no tienen ningún coste de conservación. 1 de enero del 2022
Router de registros♣ Sin cargos adicionales No aplicable No aplicable
Analíticas 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 aplica ningún cargo por el almacenamiento de los registros almacenados en el segmento de registros de _Required.
 †  Los registros vendidos son registros de redes de Google Cloud que los servicios de Google Cloud generan cuando la generación de dichos registros está habilitada. Entre los registros que se venden se incluyen los registros de flujo de VPCs, los registros de reglas de cortafuegos y los registros de Cloud NAT. Estos registros también están sujetos a los precios de telemetría de red. Para obtener más información, consulta los registros vendidos.
 ‡  No se aplican cargos por la retención de los registros almacenados en el segmento de registros de _Required, que tiene un periodo de conservación fijo de 400 días.
 ♣  El enrutamiento de registros se define como el reenvío de los registros que se reciben a través de la API de Cloud Logging a un destino compatible. Es posible que se apliquen cargos por el destino a los registros enrutados.
 ♥  Actualizar un segmento de registros para usar Analíticas de registros o emitir consultas de SQL desde la página Analíticas de registros no implica ningún coste.
 Nota: Los precios de Cloud Logging cambió el 19 de julio del 2023. No obstante, las asignaciones gratuitas y las tarifas siguen siendo las mismas. Puede que tu factura esté relacionada con el texto de precios anterior.

Resumen de precios de Cloud Monitoring

Función Precio Asignación gratuita al mes Fecha de entrada en vigor
Todos los datos de Monitoring
, excepto los que se hayan ingerido mediante Managed Service para Prometheus		 0,2580 USD por MiB1: de los primeros 150 a 100.000 MiB
0,1510 USD por MiB: los siguientes 100.000-250.000 MiB
0,0610 USD por MiB: >250.000 MiB		 Todas las métricas de Google Cloud no facturables
Primeros 150 MiB por cuenta de facturación para métricas cobradas por bytes ingeridos		 1 de julio del 2018
Métricas ingeridas mediante Google Cloud Managed Service para Prometheus, incluidas las métricas del plano de control de GKE 0,06 USD por millón de muestras†: primeros 0,036 millones de muestras ingeridas#
0,048 USD por millón de muestras ingeridas
0,036 USD por millón de muestras ingeridas
0,036 USD por millón de muestras ingeridas
0,024 millones de muestras ingeridas más de 5000 millones de muestras: siguientes		 No aplicable 8 de agosto del 2023
Llamadas a la API de Monitoring 0,01 USD por 1000 llamadas de lectura a la API
(las de escritura son gratuitas)		 Se incluye el primer millón de llamadas de lectura a la API por cuenta de facturación 1 de julio del 2018
Ejecutar las comprobaciones de disponibilidad del servicio de Monitoring 0,30 USD por 1000 ejecuciones‡ 1 millón de ejecuciones por proyecto de Google Cloud 1 de octubre del 2022
Ejecución de monitorización de monitores sintéticos 1,20 USD por 1000 ejecuciones* 100 ejecuciones por cuenta de facturación 1 de noviembre del 2023
Políticas de alertas 1,50 USD al mes por cada condición de una política de alertas
0,35 USD por cada 1.000.000 series temporales devueltas por la consulta de una condición de política de alertas de una métrica♣		 No aplicable Abril del 2025
†  El servicio gestionado de Google Cloud para Prometheus utiliza el almacenamiento de Cloud Monitoring para los datos de métricas creados externamente y utiliza la API de Monitoring para recuperar esos datos. Servicio gestionado para medidores de Prometheus basado en muestras ingeridas en lugar de en bytes, para ajustarse a las convenciones de Prometheus. Para obtener más información sobre la medición basada en muestras, consulta Precios de controlabilidad y predictibilidad. Para ver ejemplos computacionales, consulta Ejemplos de precios basados en muestras ingeridas.
 #  Las muestras se contabilizan por cuenta de facturación.
 ‡  Las ejecuciones se cobran en la cuenta de facturación en la que están definidas. Para obtener más información, consulta Precios de la ejecución de comprobaciones de disponibilidad del servicio.
 *  Las ejecuciones se cobran en la cuenta de facturación en la que están definidas. En cada ejecución, es posible que se apliquen cargos adicionales por otros servicios de Google Cloud, incluidos servicios como las funciones de Cloud Run, Cloud Storage y Cloud Logging. Para obtener más información sobre estos cargos adicionales, consulta el documento de precios del servicio de Google Cloud correspondiente.
 ♣  Para obtener más información, consulta Precios de alertas.

Resumen de precios de Cloud Trace

Función Precio Asignación gratuita al mes Fecha de entrada en vigor
Ingestión en Trace 0,20 USD por millón de intervalos Primeros 2,5 millones de intervalos por cuenta de facturación 1 de noviembre del 2018

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

Para conocer los precios de GKE Enterprise, consulta GKE Enterprise.

Comprobar el uso

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

Ir a Facturación de Cloud

Te puedes basar en esos datos para predecir los importes de tus facturas con la calculadora de precios.

Pongamos, por ejemplo, una configuración en la que cada instancia de máquina virtual de Compute Engine genera 10 GiB de registros facturables y 20 MiB de métricas facturables al mes. La calculadora de precios te permite determinar los costes previstos de Cloud Monitoring y Cloud Logging:

1 VM 10 VMs 100 VM 1000 VM
Coste mensual de las métricas 0,00 USD 12,90 USD 477,30 USD 5121,30 USD
Coste mensual del almacenamiento de registros 0,00 USD 25,00 USD 475,00 USD 4975,00 USD
Coste total: 0,00 USD 37,90 USD 952,30 USD 10.096,30 USD

Configurar una alerta de facturación

Para recibir una notificación si los cargos facturables o previstos superan un presupuesto, crea una alerta en la página Presupuestos y alertas de la consola de Google Cloud:

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

    Ve a Facturación.

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

    Si tienes más de una cuenta de facturación de Cloud, sigue uno de estos pasos:

    • Para gestionar la facturación de Cloud del proyecto seleccionado, elige Ir a la cuenta de facturación vinculada.
    • Si quieres acceder a otra cuenta de facturación de Cloud, haz clic en Gestionar cuentas de facturación y elige la cuenta cuyo presupuesto quieras configurar.
  2. En el menú de navegación Facturación, selecciona Presupuestos y alertas.
  3. Haz clic en Crear presupuesto.
  4. Completa el cuadro de diálogo del presupuesto. En este cuadro de diálogo, tienes que seleccionar la combinación de proyectos y productos de Google Cloud y, luego, crear su presupuesto. De forma predeterminada, se te notificará cuando se alcance el 50 %, el 90 % y el 100 % del presupuesto. Si quieres ver la documentación completa, consulta la información sobre cómo configurar presupuestos y sus alertas.

Cloud Logging

Los segmentos de registros son contenedores de Logging que almacenan datos de registros. Cuando utilizas Logging, se te cobra por el volumen de datos de registro que se almacenan en el segmento de registros de _Default y en los segmentos de registros definidos por el usuario. Los precios se aplican a los registros de red no enviados cuando el volumen supera la asignación mensual gratuita y a los registros de red enviados.

En el caso de los segmentos de registros _Default y definidos por el usuario, también se cobra cuando los registros se retienen durante un tiempo superior al periodo de conservación predeterminado, que es de 30 días.

Logging no te cobrará ninguna tarifa adicional por enrutar registros, usar la API de Cloud Logging, configurar ámbitos de registro ni acceder a los registros almacenados en el segmento de registros de _Required, que tiene un periodo de conservación fijo de 400 días.

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

Para ver información resumida sobre los precios, consulta el resumen de precios de Cloud Logging.

Para conocer los límites que se aplican a tu uso de Logging, incluidos los periodos de conservación de datos, consulta Cuotas y límites.

Para ver y conocer tus datos de uso de Cloud Logging, consulta cómo estimar tu facturación.

Modelo de almacenamiento de Cloud Logging

Para cada proyecto de Google Cloud, Logging crea automáticamente dos segmentos de registros: _Required y _Default. En estos dos segmentos, Logging crea automáticamente sumideros de registro llamados _Required y _Default que dirigen los registros a los segmentos de registro con nombre correspondiente. No puedes inhabilitar ni modificar el sumidero de _Required. Puedes inhabilitar o modificar el sumidero _Default para evitar que el segmento _Default almacene registros nuevos.

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

Puedes configurar un periodo de conservación personalizado para el segmento de registros _Default y el definido por el usuario.

Puedes actualizar tus segmentos de registros para usar Analíticas de registros. Actualizar un segmento de registros para usar Analíticas de registros es gratis.

Para obtener más información sobre los segmentos y sumideros de Cloud Logging, consulta la descripción general del enrutamiento y el almacenamiento.

Precio de almacenamiento

Logging no te cobrará por los registros almacenados en el segmento de _Required. No puedes eliminar el segmento _Required ni modificar el sumidero de _Required. El segmento _Required almacena los siguientes registros:

Cuando el volumen total supera la asignación mensual gratuita, Logging se cobra por el volumen indexado previamente de datos de registros que se almacenan en el segmento de registros _Default y en los segmentos de registros definidos por el usuario. Cada escritura de una entrada de registro en el segmento de registro _Default o en uno definido por el usuario se contabiliza en la asignación de almacenamiento. Por ejemplo, si tienes sumideros que enrutan una entrada de registro a tres segmentos de registro, esa entrada de registro se almacena tres veces.

Precios de retención

En la siguiente tabla se indican los periodos de conservación de datos de los registros almacenados en segmentos de registros:

Segmento Periodo de conservación predeterminado Conservación personalizada
_Required 400 días No se pueden configurar.
_Default 30 días Se pueden configurar.
Definido por el usuario 30 días Se pueden configurar.

En Logging se cobran los costes de retención cuando los registros se retienen durante más tiempo del periodo de conservación predeterminado. No puedes configurar el periodo de conservación del segmento de registros de _Required. No se aplica ningún coste de conservación si los registros se almacenan únicamente durante el periodo de conservación predeterminado del segmento.

Si acortas el periodo de conservación de un segmento de registros, los registros que hayan vencido no se eliminarán durante un periodo de gracia de siete días. No puedes hacer consultas ni ver los registros caducados. Sin embargo, esos siete días puedes restaurar el acceso completo ampliando el periodo de conservación del segmento de registros. Los registros almacenados durante el periodo de gracia se tienen en cuenta para calcular los costes de retención.

Si enrutas una entrada de registro a varios segmentos de registro, es posible que se te cobren los costes de almacenamiento y conservación varias veces. Por ejemplo, supongamos que enrutas una entrada de registro al segmento de registros _Default y a un segmento definido por el usuario. Además, supongamos que configuras un periodo de retención personalizado para ambos segmentos que es superior a 30 días. Con esta configuración, se te cobrarán dos cargos por almacenamiento y dos por retención.

Registros de red vendidos

Los registros de red vendidos solo están disponibles cuando configuras la generación de registros. Los servicios que generan registros de red de venta cobra por generar registros. Si almacenas estos registros en un segmento de registros o los enrutas a otro destino compatible, también se te aplicarán cargos de Cloud Logging o del destino. Para obtener información sobre los costes de generación de registros, consulta los precios de telemetría de red.

Si quieres obtener más información sobre cómo habilitar los registros de red de venta, consulta las secciones sobre cómo configurar registros de flujo de VPC, usar el almacenamiento de registros de reglas de cortafuegos y registros y métricas de Cloud NAT.

Para encontrar los registros de tu red de venta, filtra por los siguientes nombres de registro en Explorador de registros:

  • 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

Reducir el almacenamiento de registros

Si quieres reducir tus costes de almacenamiento de Cloud Logging, configura filtros de exclusión en los sumideros de registros para evitar que se enruten determinados registros. Los filtros de exclusión pueden quitar todas las entradas de registro que coincidan con el filtro o solo un porcentaje de los registros. Cuando una entrada de registro coincide con un filtro de exclusión de un sumidero, el sumidero no la enruta al destino. Las entradas de registro excluidas no se tienen en cuenta para la asignación de almacenamiento. Para obtener instrucciones sobre cómo configurar filtros de exclusión, consulta el artículo Exclusiones de registros.

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

Para obtener información sobre cómo enrutar registros fuera de Cloud Logging, consulta la sección Enrutar registros a destinos admitidos.

Precios de las métricas basadas en registros

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

Las métricas basadas en registros definidas por el usuario son un tipo de métricas personalizadas de Cloud Monitoring y son facturables. Si necesitas más información acerca de los precios, consulta la sección sobre métricas facturables.

Para obtener más detalles, consulta la información general sobre las métricas basadas en registros.

Crear una política de alertas sobre la ingesta mensual de bytes de registro ingeridos

Para crear una política de alertas que se active cuando el número de bytes de registro escritos en tus segmentos de registros supere el límite definido por el usuario de Cloud Logging, sigue los pasos que se indican más abajo.

Campo Nueva condición
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 registro ingeridos mensuales.
Filtro Ninguno
En series temporales
Agregación de series temporales		 sum
Ventana móvil 60 m
Función de ventana retrospectiva max
Campo Configurar activador de alerta
Campo
Valor
Tipo de condición Threshold
Activador de alertas Any time series violates
Posición de umbral Above threshold
Valor del umbral Tú eliges el valor aceptable.
Ventana de nueva prueba El valor mínimo aceptable es 30 minutos.

Cloud Monitoring

Monitoring cobra por lo siguiente:

  • Métricas calculadas por bytes ingeridos, cuando los datos de métricas ingeridas superan la asignación mensual gratuita.

    Las métricas no facturables no se tienen en cuenta para calcular el límite de asignación.

  • Métricas medidas por número de muestras ingeridas.

  • 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 se tienen en cuenta para el límite de asignación.

  • Ejecución de comprobaciones de disponibilidad del servicio.

  • Ejecución de monitores sintéticos.

  • Condiciones de políticas de alertas medidas por el número de condiciones activas al mes.

  • Serie temporal devuelta por la consulta de una condición de política de alerta.

En Monitoring, la ingestión hace referencia al proceso de escribir series temporales en Monitoring. Cada serie temporal incluye algunos datos. esos datos son la base de los cargos de ingestión. Para obtener información sobre los precios, consulta los precios actuales de Cloud Monitoring.

En esta sección se ofrece la siguiente información:

Para obtener más información, consulta los precios actuales de Cloud Monitoring.

Para conocer los límites que se aplican a tu uso de Monitoring, consulta Cuotas y límites.

Para consultar tu uso actual, sigue uno de estos pasos:

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

    Ve a Facturación.

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

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

    Ve a Ajustes.

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

Te puedes basar en esos datos para predecir los importes de tus facturas.

Métricas no facturables

Los datos de las métricas de Google Cloud, GKE Enterprise y Knative no son facturables. Entre ellas se incluyen las siguientes:

Métricas facturables

Todos los datos de métricas, excepto los de las métricas que se indican en la sección Métricas no facturables, se facturan. La mayor parte de la ingestión de las métricas se cobra según el número de bytes, pero algunos se cargan por el número de muestras, dichos modelos de precios se describen en las siguientes secciones.

Los siguientes factores contribuyen a los costes de ingestión:

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

    • Para obtener información sobre el tipo de datos asociado a 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 el artículo sobre los tipos de valores.

  • Número de datos escritos en una serie temporal. Este valor depende de la frecuencia con la que se muestrean los datos y de la cardinalidad de ellos. La cardinalidad determina cuántas series temporales se generan para una combinación de tipos de métricas y de recursos monitorizados. para obtener más información, consulta Cardinalidad.

Los valores de las métricas y las etiquetas de recursos que forman parte de la serie temporal no se contabilizan en tus cargos.

Métricas cobradas por bytes ingeridos

Las siguientes métricas son facturables y se facturan según el número de bytes ingeridos:

A la hora de establecer los precios, el volumen de ingestión se calcula de la siguiente manera:

  • Para un tipo de datos escalar: 8 bytes por cada dato escrito en una serie temporal. Las métricas de contador basadas en registros definidas por el usuario se incluyen 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 de una serie temporal, consulta la sección Serie temporal: los datos de un recurso monitorizado.

Métricas cobradas por muestras ingeridas

Las siguientes métricas son facturables y se facturan según el número de muestras ingeridas:

A la hora de establecer los precios, el recuento de la muestra se calcula de la siguiente manera:

  • Para un tipo de datos escalar: 1 por cada punto escrito en una serie temporal.
  • Para un tipo de datos de distribución: 2 por cada punto escrito en una serie temporal, más 1 por cada segmento de histograma que tenga un recuento distinto de cero.

Para obtener información sobre los datos de una serie temporal, consulta la sección Serie temporal: los datos de un recurso monitorizado.

Alertas sobre las métricas ingeridas

No se pueden crear alertas basadas en las métricas ingeridas mensualmente. Sin embargo, sí puedes crear alertas para los costes de Cloud Monitoring. Para obtener más información al respecto, consulta la sección Configurar una alerta de facturación.

Ejemplos de precios basados en bytes ingeridos

En los siguientes ejemplos se muestra cómo estimar los costes de recoger datos de métricas de los bytes que se ingieren. Estos ejemplos sirven para ilustrar los cálculos. Si quieres obtener estimaciones más completas, usa la calculadora de precios. Si accedes a esta herramienta, usa el producto Google Cloud Observability para introducir datos de métricas, registros y trazas.

La situación básica es esta: tienes varios recursos monitorizados (como Compute Engine, Google Kubernetes Engine o App Engine) que escriben datos aportados por unas cuantas métricas cada mes.

Entre las variables de las situaciones se incluyen las siguientes:

  • La cantidad de recursos
  • La cantidad de métricas
  • Si las métricas son de Google Cloud o no
  • La frecuencia con la que se escriben los datos de métricas

Los ejemplos de esta sección corresponden a los precios de Monitoring a fecha de julio del 2020.

Aspectos comunes

En los siguientes ejemplos de precios, se presupone que cada dato de métrica ingerido es de tipo doble, int64 o bool. Además, se consideran como de 8 bytes a la hora de calcular los precios. Un mes tiene aproximadamente 730 horas (es decir, 365 días divididos entre 12 meses y multiplicados por 24 horas), lo que equivale a 43.800 minutos.

En el caso de una frecuencia de escritura de métricas de 1 dato por minuto durante un mes:

  • Los datos totales son 43.800.
  • El volumen total ingerido es el siguiente:
    • 350.400 bytes (43.800 datos * 8 bytes)
    • 0,33416748 MiB (350.400 bytes / 1.048.576 bytes por MiB)

En el caso de una frecuencia de escritura de métricas de 1 dato por hora durante un mes:

  • Los datos totales son 730.
  • El volumen total ingerido es el siguiente:
    • 5840 bytes (730 datos * 8 bytes)
    • 0,005569458 MiB (5840 bytes / 1.048.576 bytes por MiB)

Ejemplos

Situación 1: Dispones de 1000 recursos y cada uno de ellos escribe 75 métricas. Estas métricas son solo de Google Cloud y se escriben a una velocidad de 1 dato por minuto.

  • Ingestión mensual: 25.063 MiB = 0,33416748 MiB de 1 métrica * 75.000 (es decir, 1000 recursos y 75 métricas)
  • Coste mensual aproximado: 0,00 USD (las métricas de Google Cloud son gratuitas)
MiB ingeridos Tarifa (USD por MiB) Coste (USD)
Sin límite 0,00 0,00 USD
Total 25.063 0,00 USD

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

  • Ingestión mensual: 25.063 MiB (igual que en la situación anterior)
  • Coste mensual aproximado: 6427,55 USD
MiB ingeridos Tarifa (USD por MiB) Coste (USD)
150 0,00 0,00 USD
24.913 0,258 6427,55 USD
Total 25.063 6427,55 USD

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

  • Ingestión mensual: 418 MiB = 0,005569458 MiB de 1 métrica * 75.000
  • Coste mensual aproximado: 69,14 USD
MiB ingeridos Tarifa (USD por MiB) Coste (USD)
150 0,00 0,00 USD
267 0,258 69,14 USD
Total 417 69,14 USD

Situación 4: Tienes 1 recurso que escribe 500.000 métricas. Estas métricas son facturables y se escriben a una velocidad de 1 dato por minuto.

  • Ingestión mensual: 167.084 MiB = 0,33416748 MiB de 1 métrica * 500.000
  • Coste mensual aproximado: 35.890,98 USD
MiB ingeridos Tarifa (USD por MiB) Coste (USD)
150 0,00 0,00 USD
99.850 0,258 25.761,30 USD
67.084 0,151 10.129,68 USD
Total 167.084 35.890,98 USD

Precios de controlabilidad y predictibilidad

Los precios del servicio gestionado para Prometheus están diseñados para que se puedan controlar. Como se aplica una tarifa por muestra, puedes usar los siguientes métodos para controlar los costes:

  • Periodo de muestreo: cambiar el periodo de extracción de métricas de 15 segundos a 60 segundos puede suponer un ahorro de costes del 75 %, sin sacrificar la cardinalidad. Puedes configurar los periodos de muestreo por tarea, por objetivo o en todo el mundo.

  • Filtrado: puedes usar el filtrado para reducir el número de muestras enviadas al almacén de datos lobal del servicio. Para obtener más información, consulta Filtrar métricas exportadas. Usa configuraciones de reetiquetado de métricas en tu configuración de extracción de etiquetas de Prometheus para eliminar métricas en el momento de la ingestión según las coincidencias de etiquetas.

  • Mantenga una alta cardinalidad y datos de bajo valor de forma local. Puedes ejecutar Prometheus estándar junto con el servicio gestionado mediante las mismas configuraciones de paisaje y conservar a nivel local los datos que no merezca la pena enviarlos al almacén de datos global del servicio.

Los precios del servicio gestionado para Prometheus están diseñados para ser predecibles.

  • No se te penalizará por tener histogramas dispersos. Las muestras solo se cuentan para el primer valor distinto de cero y cuando el valor del segmento n sea mayor que el valor del segmento n‐1. Por ejemplo, un histograma con valores 10 10 13 14 14 14 cuenta como tres muestras: en el primer, tercer y cuarto segmento.

    Según la cantidad de histogramas que uses y la forma en que los uses, la exclusión de segmentos sin cambios en los precios suele generar un 20 % o un 40 % menos de muestras con fines de facturación que la cantidad absoluta que indicarían los segmentos de histograma.

  • Si cobras por muestra, no se te aplicará ninguna penalización por los contenedores de escalado rápido, sin escalar, interrumpibles o efímeros, como los creados por HPA o Autopilot de GKE.

    Si Managed Service para Prometheus se cobraba por cada métrica, pagarías la cardinalidad de todo un mes cada vez que se activase un contenedor nuevo. Con los precios por muestra, pagas solo cuando el contenedor se está ejecutando.

Consultas, incluidas las consultas de alerta

Todas las consultas emitidas por los usuarios, incluidas las emitidas cuando se ejecutan las reglas de registro de Prometheus, se cobran a través de las llamadas a la API de Cloud Monitoring. Si quieres saber cuál es el precio actual, consulta la tabla de resumen de precios de Google Cloud Managed Service for Prometheus o los precios de Monitoring.

Ejemplos de precios basados en muestras ingeridas

En los siguientes ejemplos se muestra cómo estimar los costes de recoger métricas de las muestras ingeridas. La carga basada en muestras se utiliza en Google Cloud Managed Service para Prometheus.

Estos ejemplos sirven para ilustrar las técnicas de cálculo y no para proporcionar datos de facturación.

La situación básica es esta: tienes varios contenedores o pods que escriben puntos en algunas series temporales al mes. Los datos pueden estar formados por valores escalares o distribuciones.

Entre las variables de las situaciones se incluyen las siguientes:

  • El número de contenedores o pods.
  • El número de series temporales.
  • Si los datos están formados por valores escalares, distribuciones o ambos.
  • La frecuencia con la que se escriben los datos.

Recuento de muestras

Para poder calcular los precios, necesitas saber cómo hacer el recuento de muestras. El número de muestras de un valor depende de lo siguiente:

  • Si el valor es un escalar o una distribución
  • La frecuencia con 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 periodo de facturación mensual.

Un mes tiene aproximadamente 730 horas (365 días divididos entre 12 meses y multiplicados por 24 horas), 43.800 minutos o 2.628.000 segundos.

Si una serie temporal escribe valores escalares, cada valor cuenta como una muestra. El número de muestras escritas en un mes depende únicamente de la frecuencia con la que se escriban los valores. Ten en cuenta los siguientes ejemplos:

  • En el caso de los valores escritos cada 15 segundos:
    • Velocidad de escritura: 1 valor dividido entre 15 s = 1 muestra dividida entre 15 s
    • Muestras al mes: 175.200 (1 muestra dividida entre 15 s y multiplicada por 2.628.000 segundos al mes)
  • En el caso de los valores escritos cada 60 segundos:
    • Velocidad de escritura: 1 valor dividido entre 60 s = 1 muestra dividida entre 60 s
    • Muestras al mes: 43.800 (1 muestra dividida entre 60 s y multiplicada por 2.628.000 segundos al mes)

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

Por ejemplo, cada instancia de un histograma de 50 segmentos puede contener 52 muestras. Si los valores se escriben cada 60 segundos, un histograma de 50 segmentos escribe como máximo 2.277.600 muestras al mes. Si el histograma tiene 100 segmentos y se escribe una vez cada 60 segundos, cada histograma puede contener 102 muestras y escribe como máximo 4.467.600 muestras al mes.

La mayoría de las series temporales de distribución contienen un número inferior al máximo de muestras. En la práctica, entre el 20 % y el 40 % de los segmentos de histogramas están vacíos. Este porcentaje es incluso mayor para los usuarios con histogramas dispersos, como los generados por Istio.

Al contar muestras para el precio, solo se incluyen los segmentos con valores que no estén vacíos. El número máximo de muestras por histograma es 2 + n . Si el 25 % de los segmentos está vacío, el número esperado de muestras es 2 + 0,75 n por histograma. Si el 40 % de los segmentos está vacío, el número previsto de muestras es 2 + 0,60 n por histograma.

Los siguientes cálculos y tablas de resumen muestran el número máximo de muestras y una cantidad de muestras más realista:

  • En el caso de los valores de histogramas de 50 segmentos cada 15 segundos:

    • Velocidad de escritura: 1 valor dividido entre 15 s
    • Número máximo de muestras:
      • Por histograma: 52
      • Al mes: 9.110.400 (52 multiplicado por 1 valor, dividido entre 15 s y multiplicado por 2.628.000 segundos al mes)
    • Ejemplos esperados (suponiendo que el 25 % esté vacío):
      • Por histograma: 39,5 (2 + 0,75(50), o 2 + (50 - 12,5))
      • Al mes: 6.920.400 (39,5 multiplicado por 1 valor, dividido entre 15 s y multiplicado por 2.628.000 segundos al mes)
    • Ejemplos esperados (suponiendo que el 40 % esté vacío):
      • Por histograma: 32 (2 + 0,6(50) o 2 + (50 - 20))
      • Al mes: 5.606.400 (32 multiplicado por 1 valor, dividido entre 15 s y multiplicado por 2.628.000 segundos al mes)

  • En el caso de los valores de histogramas de 50 segmentos escritos cada 60 segundos:

    • Velocidad de escritura: 1 valor dividido entre 60 s
    • Número máximo de muestras:
      • Por histograma: 52
      • Al mes: 2.277.600 (52 multiplicado por 1 valor, dividido entre 60 y multiplicado por 2.628.000 segundos al mes)
    • Ejemplos esperados (suponiendo que el 25 % esté vacío):
      • Por histograma: 39,5 (2 + 0,75(50), o 2 + (50 - 12,5))
      • Al mes: 1.730.100 (39,5 multiplicado por 1 valor, dividido entre 60 s y multiplicado por 2.628.000 segundos al mes)
    • Ejemplos esperados (suponiendo que el 40 % esté vacío):
      • Por histograma: 32 (2 + 0,6(50) o 2 + (50 - 20))
      • Al mes: 1.401.600 (32 multiplicado por 1 valor, dividido entre 60 s y multiplicado por 2.628.000 segundos al mes)

  • Para los valores de histogramas de 100 segmentos escritos cada 15 segundos:

    • Velocidad de escritura: 1 valor dividido entre 15 s
    • Número máximo de muestras:
      • Por histograma: 102
      • Al mes: 17.870.400 (102 multiplicado por 1 valor, dividido entre 15 s y multiplicado por 2.628.000 segundos al mes)
    • Ejemplos esperados (suponiendo que el 25 % esté vacío):
      • Por histograma: 77 (2 + 0,75(100) o 2 + (100 - 25))
      • Al mes: 13.490.400 (77 multiplicado por 1 valor, dividido entre 15 s y multiplicado por 2.628.000 segundos al mes)
    • Ejemplos esperados (suponiendo que el 40 % esté vacío):
      • Por histograma: 62 (2 + 6(100) o 2 + (100 - 40))
      • Al mes: 10.862.400 (62 multiplicado por 1 valor, dividido entre 15 s y multiplicado por 2.628.000 segundos al mes)

  • En el caso de los valores de histogramas de 100 segmentos cada 60 segundos:

    • Velocidad de escritura: 1 valor dividido entre 60 s
    • Número máximo de muestras:
      • Por histograma: 102
      • Al mes: 4.467.600 (102 multiplicado por 1 valor, dividido entre 60 s y multiplicado por 2.628.000 segundos al mes)
    • Ejemplos esperados (suponiendo que el 25 % esté vacío):
      • Por histograma: 77 (2 + 0,75(100) o 2 + (100 - 25))
      • Al mes: 3.372.600 (77 multiplicado por 1 valor, dividido entre 60 s y multiplicado por 2.628.000 segundos al mes)
    • Ejemplos esperados (suponiendo que el 40 % esté vacío):
      • Por histograma: 62 (2 + 6(100) o 2 + (100 - 40))
      • Al mes: 2.715.600 (62 multiplicado por 1 valor, dividido entre 60 s y multiplicado por 2.628.000 segundos al mes)

En la siguiente tabla se resume la información anterior:

Recuento de grupos Velocidad de escritura Muestras al mes
(máx.)		 Muestras al mes
(25 % vacío)		 Muestras al mes
(40 % vacío)
50 1 ejemplo/ 15 s 9.110.400 6.920.400 5.606.400
50 1 ejemplo/ 60 s 2.277.600 1.730.100 1.401.600
100 1 ejemplo/ 15 s 17.870.400 13.490.400 10.862.400
100 1 ejemplo/ 60 s 4.467.600 3.372.600 2.715.600

Ejemplos

Para estimar los precios, cuenta el número de muestras escritas a lo largo de un mes y aplica los valores de precios. Los precios de las muestras se fijan por millones, en el caso de los intervalos apilados, según se indica a continuación:

Intervalo de ingestión Managed Service for Prometheus Máximo para el rango
Hasta 50 mil millones (50.000 millones) 0,06 USD/millón 3000,00 USD
De 50 a 250 miles de millones (250.000 millones) 0,048 USD por millón 9600,00 USD
De 250.000 millones a 500.000 millones (500.000 millones) 0,036 USD por millón 9000,00 USD
Más de 500.000 millones (500.000 millones) 0,024 USD por millón  

El resto de esta sección funciona mediante situaciones posibles.

Situación 1: tienes 100 contenedores y cada uno de ellos escribe 1000 series temporales escalares.

Variante A: si cada serie temporal se escribe cada 15 segundos (1 muestra/15 s), el número de muestras escritas al mes es de 17.520.000.000 (175.200 muestras al mes multiplicadas por 1000 series temporales y 100 contenedores), o 17,52 millones.

Variante B: si cada serie temporal se escribe cada 60 segundos (1 muestra/60 s), el número de muestras escritas al mes es de 4.380.000.000 (43.800 muestras al mes multiplicadas por 1000 series temporales y 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. No se cobran muestras con las demás tarifas.

Variante Muestras ingeridas Intervalo de ingestión Servicio gestionado para Prometheus
(0,06 USD, 0,048 USD, 0,036 USD, 0,024 USD)
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 		1051,20 USD



1051,20 USD
B (1 muestra/60 s)



Total 		4380 millones



4380 millones 		Hasta 50.000 millones
Hasta 250.000 millones
Hasta 500.000 millones
Más de 500.000 millones 		262,80 USD



262,80 USD

Situación 2: tienes 1000 contenedores y cada uno escribe 1000 series temporales escalares.

Variante A: si cada serie temporal se escribe cada 15 segundos (1 muestra/15 s), el número de muestras escritas al mes es de 175.200.000.000 o 175.200 millones:

  • Los primeros 50.000 millones de muestras se cobran con la primera tarifa.
  • Los 125.200 millones de muestras restantes se cobran con la segunda tarifa.
  • No se cobran muestras con las demás tarifas.

Variante B: si cada serie temporal se escribe cada 60 segundos (1 muestra/60 s), el número de muestras escritas al mes es de 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 ingeridas Intervalo de ingestión Servicio gestionado para Prometheus
(0,06 USD, 0,048 USD, 0,036 USD, 0,024 USD)
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 		3000,00 USD
6009,60 USD


9009,60 USD
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 		2628,00 USD



2628,00 USD

Situación 3: tienes 100 contenedores y cada uno escribe 1000 series de 100 segmentos de series temporales de distribución. Esperas que el 25 % de los segmentos esté vacío.

Variante A: si cada serie temporal se escribe cada 15 segundos (1 muestra/15 s), el número de muestras escritas al mes es de 1.349.040.000.000 (13.490.400 muestras al mes multiplicadas por 1000 series temporales y 100 contenedores), o 1.349.040 millones.

  • Los primeros 50.000 millones de muestras se cobran con la primera tarifa.
  • Los siguientes 200.000 millones de muestras restantes se cobran con la segunda tarifa.
  • Los siguientes 250.000 millones de muestras se cobran a la tercera tarifa.
  • Los 749.040 millones de muestras restantes se cobran al cuarto precio.

Variante B: si cada serie temporal se escribe cada 60 segundos (1 muestra/60 s), el número de muestras escritas al mes es de 337.260.000.000 (3.372.600 muestras al mes multiplicadas por 1000 series temporales y 100 contenedores), o 337.260 millones.

  • Los primeros 50.000 millones de muestras se cobran con la primera tarifa.
  • Los siguientes 200.000 millones de muestras restantes se cobran con la segunda tarifa.
  • Los 87.260 millones de muestras restantes se cobran con la tercera tarifa.
Variante Muestras ingeridas Intervalo de ingestión Servicio gestionado para Prometheus
(0,06 USD, 0,048 USD, 0,036 USD, 0,024 USD)
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 		3000,00 USD
9600,00 USD
9000,00 USD
17.976,96 USD
39.576,96 USD
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 		3000,00 USD
9600,00 USD
3141,36 USD

15.741,36 USD

Situación 4: tienes 1000 contenedores y cada uno de ellos escribe 10.000 series de 100 segmentos temporales de distribución. Esperas que el 40 % de los segmentos esté vacío.

Variante A: si cada serie temporal se escribe cada 15 segundos (1 muestra/15 s), el número de muestras escritas al mes es de 108.624.000.000.000 (10.862.400 muestras al mes multiplicadas por 10.000 series temporales y 1000 contenedores), o 108.624.000 millones.

  • Los primeros 50.000 millones de muestras se cobran con la primera tarifa.
  • Los siguientes 200.000 millones de muestras restantes se cobran con la segunda tarifa.
  • Los siguientes 250.000 millones de muestras se cobran a la tercera tarifa.
  • Los 108.124.000 millones de muestras restantes se cobran al cuarto precio.

Variante B: si cada serie temporal se escribe cada 60 segundos (1 muestra/60 s), el número de muestras escritas al mes es de 27.156.000.000.000 (2.715.600 muestras al mes multiplicadas por 10.000 series temporales y 1000 contenedores), o 27.156.000 millones.

  • Los primeros 50.000 millones de muestras se cobran con la primera tarifa.
  • Los siguientes 200.000 millones de muestras restantes se cobran con la segunda tarifa.
  • Los siguientes 250.000 millones de muestras se cobran a la tercera tarifa.
  • Los 26.656.000 millones de muestras restantes se cobran al cuarto precio.
Variante Muestras ingeridas Intervalo de ingestión Servicio gestionado para Prometheus
(0,06 USD, 0,048 USD, 0,036 USD, 0,024 USD)
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 		3000,00 USD
9600,00 USD
9000,00 USD
2.594.976,00 USD
2.616.576,00 USD
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 		3000,00 USD
9600,00 USD
9000,00 USD
639.744,00 USD
661.344,00 USD

Situación 5: cumples las siguientes condiciones:

  • 1000 contenedores, cada uno de los cuales escribe 1000 series temporales escalares cada 15 segundos. El número de muestras escritas al mes es de 175.200.000.000 o 174.200 millones. (Situación 2, variante A).

  • 1000 contenedores, cada uno de los cuales escribe 10.000 de series de 100 segmentos de series temporales de distribución cada 15 segundos. Esperas que el 40 % de los segmentos esté vacío. El número de muestras escritas al mes es de 108.624.000.000.000 o 108.624 millones. (Situación 4, variante A).

El número total de muestras al mes es 108.799.200 millones (175.200 millones + 108.624.000 millones).

  • Los primeros 50.000 millones de muestras se cobran con la primera tarifa.
  • Los siguientes 200.000 millones de muestras restantes se cobran con la segunda tarifa.
  • Los siguientes 250.000 millones de muestras se cobran a la tercera tarifa.
  • Los 108.299.200 millones de muestras restantes se cobran al cuarto precio.
Variante Muestras ingeridas Intervalo de ingestión Servicio gestionado para Prometheus
(0,06 USD, 0,048 USD, 0,036 USD, 0,024 USD)
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 		3000,00 USD
9600,00 USD
9000,00 USD
2.599.180,80 USD
2.620.780,80 USD

Precios de la ejecución de comprobaciones de disponibilidad del servicio (fecha de entrada en vigor: 1 de octubre del 2022)

Monitorizar los cargos de cada ejecución regional de una comprobación de disponibilidad del servicio, más allá de la asignación mensual gratuita de 1 millón de ejecuciones. Una comprobación que se ejecuta en tres regiones cuenta como tres ejecuciones.

El coste de la ejecución de la comprobación de disponibilidad del servicio es de 0,30 USD por cada 1000 ejecuciones. El cargo aparece en tu factura como el código SKU "CA14-D3DE-E67F" de "Monitorización de comprobaciones de disponibilidad del servicio".

En los siguientes ejemplos se muestra cómo estimar los costes de ejecutar comprobaciones de disponibilidad del servicio. Estos ejemplos tienen como objetivo ilustrar técnicas de cálculo, no para proporcionar datos de facturación.

Recuento de ejecuciones de comprobaciones de disponibilidad del servicio

Para estimar el coste de tus comprobaciones de disponibilidad del servicio, debes saber cuántas ejecuciones regionales se llevan a cabo en un mes. El coste de la monitorización es de 0,30 USD por cada 1000 ejecuciones, con una asignación mensual gratuita de 1 millón de ejecuciones.

Para estimar el coste de tus comprobaciones de disponibilidad del servicio, puedes usar el siguiente cálculo:

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

En cada comprobación de disponibilidad del servicio, el número de ejecuciones depende de las siguientes opciones de configuración:

  • La frecuencia con la que se ejecuta la comprobación de disponibilidad del servicio (cada minuto, 5, 10 o 15 minutos).

  • Número de regiones en las que se ejecuta la comprobación de disponibilidad del servicio.

  • Número de objetivos en los que está configurada la comprobación de disponibilidad del servicio. Si la comprobación de disponibilidad del servicio está configurada para una sola máquina virtual, el número de objetivos es 1. Si se ha configurado una comprobación de disponibilidad del servicio para un grupo de recursos, el número de destinos será el número de recursos del grupo.

Al configurar una comprobación de disponibilidad del servicio, debes especificar una ubicación para dicha comprobación y cada ubicación se asigna a una o varias regiones. En la siguiente tabla se muestran las ubicaciones válidas para las comprobaciones de disponibilidad del servicio y las regiones a las que están asociadas:

Ubicación para la configuración de la comprobación de disponibilidad del servicio 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 en otras ubicaciones

Debes configurar las comprobaciones de disponibilidad del servicio para que se ejecuten en al menos tres regiones.

Para calcular el número de ejecuciones de una comprobación de disponibilidad del servicio, debes saber cuántas regiones cubre dicha ubicación:

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

En un mes, el cálculo sería el siguiente: 730 horas (365 días / 12 meses × 24 horas) o 43.800 minutos.

  • Una comprobación de disponibilidad del servicio configurada para ejecutarse una vez por minuto en USA se ejecuta en 3 regiones. Si esta comprobación de disponibilidad del servicio se configura para comprobar una sola máquina virtual, se ejecuta 131.400 (3 × 43.800) veces en un mes. Si la comprobación está configurada para comprobar un grupo de recursos de 10 miembros, la comprobación de disponibilidad del servicio se ejecuta 1.314.000 (10 * 131.400) veces en un mes.

  • Una comprobación de disponibilidad del servicio configurada para ejecutarse una vez por minuto en ASIA_PACIFIC, EUROPE y USA se ejecuta en 5 regiones. Esta comprobación de disponibilidad del servicio se ejecuta 219.000 veces en un mes si se configura para un solo objetivo.

En la siguiente tabla se muestran los recuentos de ejecuciones por horas y meses de una única comprobación de disponibilidad del servicio configurada para ejecutarse con diferentes frecuencias en distintos números de regiones:

Frecuencia de ejecución de la comprobación, una vez cada:
 Número 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 		8760
11.680
14.600
17.520

Ejemplos

Para calcular los precios, calcula el total de ejecuciones mensuales y resta 1.000.000. Las ejecuciones restantes se cobran a 0,30 USD/1000 ejecuciones, así que multiplica las ejecuciones restantes por 0,0003.

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

Situación 1: Tienes una ubicación de comprobación de disponibilidad del servicio USA que comprueba una VM cada minuto. Esta comprobación se lleva a cabo en 3 regiones. El cheque se ejecuta 131.400 veces al mes y no cuesta nada.

Ejecuciones mensuales totales
 Ejecuciones mensuales facturables
(más de 1.000.000)		 Coste
(0,30 USD por 1000 ejecuciones)
131 400 0 0,00 USD

Situación 2: Tienes una ubicación de comprobación de disponibilidad del servicio USA que comprueba un grupo de recursos de 10 miembros una vez por minuto. Esta comprobación se lleva a cabo en 3 regiones. La comprobación se ejecuta 10 × 131.400 veces al mes y cuesta 94,20 USD al mes. La única diferencia entre esta situación y la situación 1 es el número de objetivos.

Ejecuciones mensuales totales
 Ejecuciones mensuales facturables
(más de 1.000.000)		 Coste
(0,30 USD por 1000 ejecuciones)
1.314.000 (10 objetivos) 314 000 94,20 USD

Situación 3: Tienes 10 comprobaciones de disponibilidad del servicio de GLOBAL, y cada una de ellas comprueba una máquina virtual una vez por minuto. Estas comprobaciones se ejecutan en 6 regiones, por lo que cada una se ejecuta 262.800 veces al mes. El total de ejecuciones mensuales es de 2.628.000 (10 × 262.800). Este escenario cuesta 488,40 USD al mes.

Ejecuciones mensuales totales
 Ejecuciones mensuales facturables
(más de 1.000.000)		 Coste
(0,30 USD por 1000 ejecuciones)
2.628.000 1.628.000 488,40 USD

Situación 4: Tienes 5 comprobaciones de disponibilidad del servicio en la ubicación USA que comprueban una VM cada 5 minutos. Estas comprobaciones se ejecutan en tres regiones, por lo que cada una de ellas se ejecuta 26.280 veces al mes. El total de ejecuciones mensuales de este conjunto de comprobaciones es de 105.120 (4 × 26.280).

También dispones de dos comprobaciones de disponibilidad del servicio de GLOBAL que comprueban una máquina virtual cada 15 minutos. Estas comprobaciones se ejecutan en 6 regiones, por lo que cada una se ejecuta 17.520 veces al mes. El total de ejecuciones mensuales de este conjunto de comprobaciones es de 35.040 (2 × 17.520).

El total de ejecuciones mensuales es de 140.160 (105.120 + 35.040). Esta situación no supone ningún coste.

Ejecuciones mensuales totales
 Ejecuciones mensuales facturables
(más de 1.000.000)		 Coste
(0,30 USD por 1000 ejecuciones)
140 160 0 0,00 USD

Precios de la ejecución de supervisión sintética (fecha de entrada en vigor: 1 de noviembre del 2023)

Con Cloud Monitoring se cobra por cada ejecución de un monitor sintético, más allá de la asignación gratuita al mes de 100 ejecuciones por cuenta de facturación. Por ejemplo, si creas tres monitores sintéticos y configuras cada uno de ellos para que se ejecute cada 5 minutos, el número total de ejecuciones al 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 el número de ejecuciones que se pueden cobrar, resta la asignación gratuita del número total de ejecuciones y multiplica el resultado por el coste:

Ejecuciones mensuales totales
 Ejecuciones mensuales facturables
(más de 100 ejecuciones por cuenta de facturación)		 Coste
(1,20 USD/1000 ejecuciones)
26 784 26 684 32,02 USD

Precios de las alertas

A partir de abril del 2025, como mínimo, Cloud Monitoring empezará a cobrar por alertas. El modelo de precios es el siguiente:

  • 1,50 USD al mes por cada condición incluida en una política de alertas
  • 0,35 USD por cada 1.000.000 de series temporales devueltas por la consulta de una condición de política de alertas de métrica.

En esta sección se ofrece 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 está en un estado que requiere una respuesta.

    Por cada condición se cobra 1,50 € al mes. Para que se te deje de cobrar por una condición, debes eliminar la política de alertas. Posponer o inhabilitar la política no impide que se te cobre.

  • Políticas de alertas de métricas y basadas en registros: las políticas de alertas que usan cualquier tipo de condición, excepto las condiciones de coincidencia con registros son políticas de alerta de metric. Las condiciones de las políticas de alertas de métricas devuelven series temporales. Durante cada periodo 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. A continuación, las series temporales devueltas se comparan con respecto a un umbral para determinar si se activa la política de alertas.

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

  • Periodo de ejecución: frecuencia con la que Cloud Monitoring ejecuta tu condición. En la mayoría de los tipos de condición, es de 30 segundos y no se puede cambiar. Las condiciones que utilizan una consulta de PromQL pueden definir este periodo. Para obtener más información, consulta Aumentar la duración del periodo de ejecución (solo en PromQL).

  • Serie temporal devuelta: durante cada periodo 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.

    El número de series temporales que se devuelven en un mes viene determinado por tres factores:

    • La forma y el ámbito de los datos subyacentes.
    • Los filtros y las agregaciones que usas en la consulta de tu condición.
    • Periodo de ejecución.

    Por ejemplo, supongamos que tienes una configuración con lo siguiente:

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

    Puesto que tienes 100 máquinas virtuales, que cada una puede generar 10 series temporales (una por cada valor de etiqueta), tienes un total de 1000 series temporales subyacentes. Además, cada máquina virtual contiene una etiqueta con metadatos que registra a cuáles de tus servicios pertenece cada máquina virtual.

    Puedes configurar tus políticas de alertas de las siguientes formas mediante PromQL, donde cada configuración devuelve un número diferente de series temporales por periodo de ejecución:

    Configuración Consulta de PromQL Series temporales devueltas por periodo
    Sin agregación rate(metric_name[1m]) 1000
    Agregar datos a la VM sum by (vm) (rate(metric_name[1m])) 100
    Agregar al valor de la etiqueta sum by (label_key) (rate(metric_name[1m])) 10
    Se agrega al servicio sum by (service) (rate(metric_name[1m])) 5
    Agregado al valor y servicio de la etiqueta sum by (service, label_key) (rate(metric_name[1m])) 50
    Se agrega a la flota sum (rate(metric_name[1m])) 1
    Filtrar y agregar a una VM sum (rate(metric_name{vm="my_vm_name"}[1m])) 1
    Filtrar y agregar a un servicio sum (rate(metric_name{service="my_service_name"}[1m])) 1

Ejemplos de precios

Los siguientes ejemplos tienen lugar en un mes de 30 días, lo que da lugar a los siguientes periodos de evaluación:

  • 86.400 periodos de ejecución de 30 segundos al mes
  • 172.800 periodos de ejecución de 15 segundos al mes (solo consultas PromQL)

Ejemplo 1: Una política que se agrega a la VM, 30 segundos

En este ejemplo, utilice las siguientes configuraciones:

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 VM
  • Periodo de ejecución de 30 segundos
Costes resultantes
  • Coste de la condición: 1 condición * 1,50 USD al mes = 1,50 USD al mes
  • Coste de la serie temporal: 100 series temporales devueltas por periodo × 86.400 periodos al mes = 8,6 millones de series temporales devueltas al mes × 0,35 USD por cada millón de series temporales = 3,02 USD al mes
  • Coste total: 4,52$al mes

Ejemplo 2: 100 políticas (una por máquina virtual), agregaciones a la máquina virtual y 30 segundos

En este ejemplo, utilice las siguientes configuraciones:

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 en una VM
  • Periodo de ejecución de 30 segundos
Costes resultantes
  • Coste de la condición: 100 condiciones * 1,50 USD al mes = 150 USD al mes
  • Coste de la serie temporal: 100 condiciones × 1 serie temporal devuelta por condición y periodo × 86.400 periodos al mes = 8,6 millones de series temporales devueltas al mes × 0,35 USD por cada millón de series temporales devueltas = 3,02 USD al mes
  • Coste total: 153,02$al mes

Ejemplo 3: Una política que se agrega a la VM, 15 segundos

En este ejemplo, utilice las siguientes configuraciones:

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 VM
  • Periodo de ejecución de 15 segundos
Costes resultantes
  • Coste de la condición: 1 condición * 1,50 USD al mes = 1,50 USD al mes
  • Coste de la serie temporal: 100 series temporales devueltas por periodo × 172.800 periodos al mes = 17,3 millones de series temporales devueltas al mes × 0,35 USD por millón de series temporales = 6,05 USD al mes
  • Coste total: 7,55$al mes

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

En este ejemplo, utilice las siguientes configuraciones:

Datos

  • 100 máquinas virtuales, donde cada una de ellas 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
  • Periodo de ejecución de 30 segundos
Costes resultantes
  • Coste de la condición: 1 condición * 1,50 USD al mes = 1,50 USD al mes
  • Coste de la serie temporal: 5 series temporales devueltas por periodo × 86.400 periodos al mes = 432.000 series temporales devueltas al mes × 0,35 USD por millón de series temporales = 0,14 USD al mes
  • Coste total: 1,64$al mes

Ejemplo 5: Agrega una política a la VM; mayor cardinalidad subyacente por VM (30 segundos)

En este ejemplo, utilice las siguientes configuraciones:

Datos

  • 100 VM
  • Cada VM emite una métrica: metric_name
  • metric_name tiene 100 etiquetas con 1000 valores cada una
Política de alertas
  • Una condición
  • La condición se agrega al nivel de VM
  • Periodo de ejecución de 30 segundos
Costes resultantes
  • Coste de la condición: 1 condición * 1,50 USD al mes = 1,50 USD al mes
  • Coste de la serie temporal: 100 series temporales devueltas por periodo × 86.400 periodos al mes = 8,5 millones de series temporales devueltas al mes × 0,35 USD por cada millón de series temporales = 3,02 USD al mes
  • Coste total: 4,52$al mes

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

En este ejemplo, utilice las siguientes configuraciones:

Datos

  • 100 VM
  • Cada máquina virtual 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 VM
  • La condición usa un operador OR para unificar las métricas
  • Periodo de ejecución de 30 segundos
Costes resultantes
  • Coste de la condición: 1 condición * 1,50 USD al mes = 1,50 USD al mes
  • Coste de la serie temporal: 2 métricas × 100 series temporales devueltas por métrica y periodo × 86.400 periodos al mes = 17,3 millones de series temporales devueltas al mes × 0,35 USD por millón de series temporales devueltas = 6,05 USD al mes
  • Coste total: 7,55$al mes

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

En este ejemplo, use la siguiente configuración:

Políticas de alertas

  • 100 condiciones (una condición por política de alertas basada en registros)
Costes resultantes
  • Coste de la condición: 100 condición * 1,50 USD al mes = 150,00 USD al mes
  • Coste de la serie temporal: 0 $ (Las políticas de alertas basadas en registros no devuelven series temporales).
  • Coste total: 150,00$al mes

Sugerencias para reducir tu factura de alertas

Sigue las sugerencias que se indican a continuación para reducir el coste de las facturas de alertas al configurar políticas de alertas basadas en métricas.

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

Como el coste de cada condición es de 1,50 USD, es más rentable usar una política de alertas para monitorizar varios recursos que emplear una sola política de alertas para monitorizar cada recurso. Por ejemplo, compara el ejemplo 1 con el ejemplo 2. En ambos ejemplos, monitorizas la misma cantidad de recursos. Sin embargo, en el ejemplo 2 se usan 100 políticas de alertas, mientras que en el ejemplo 1 solo se usa una. En consecuencia, Ejemplo 1 es casi 150 USD más barato al mes.

Agrega solo el nivel sobre el que quieres activar la alerta.

Agregar los datos a niveles más altos de granularidad conlleva unos costes más altos que hacerlo con niveles más bajos de granularidad. Por ejemplo, realizar un proceso de agregación a nivel de proyecto de Google Cloud es más barato que hacerlo a nivel de clúster, y otro a nivel de clúster es más barato que hacerlo a nivel de clúster y de espacio de nombres.

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

Asimismo, compara el ejemplo 1 con el ejemplo 5: En este caso, la cardinalidad de la métrica del ejemplo 5 es 10.000 veces superior a la del ejemplo 1 de la métrica. Sin embargo, dado que la política de alertas del ejemplo 1 y del ejemplo 5 se agregan a la máquina virtual y el número de máquinas virtuales es el mismo en ambos ejemplos, el precio de los ejemplos es equivalente.

Cuando configures tus políticas de alertas, elige los niveles de agregación que mejor se adapten a tu caso práctico. Por ejemplo, si te interesa alertar sobre el uso de CPU, puede que te interese agregar los datos a nivel de máquina virtual y de CPU. Si te interesa alertar sobre la latencia de cada punto de conexión, puedes agregarlo a nivel de endpoint.

No crear alertas sobre datos sin procesar ni agregados

En la monitorización se utiliza un sistema de métricas dimensionales en el que cualquier métrica tiene una cardinalidad total igual al número de recursos monitorizados multiplicado por el número de combinaciones de etiquetas de esa métrica. Por ejemplo, si tienes 100 máquinas virtuales que emiten una métrica y esa métrica tiene 10 etiquetas con 10 valores cada una, tu cardinalidad total será 100 × 10 × 10 = 10.000.

Como consecuencia de la escala de la cardinalidad, las alertas sobre datos en bruto pueden resultar extremadamente costosas. En el ejemplo anterior, se devuelven 10.000 series temporales por cada periodo de ejecución. Sin embargo, si agregas datos a la máquina virtual, solo se devuelven 100 series temporales por periodo de ejecución, independientemente de la cardinalidad de las etiquetas de los datos subyacentes.

Al crear alertas sobre datos en bruto, corres el riesgo de aumentar las series temporales cuando las métricas reciben nuevas etiquetas. En el ejemplo anterior, si un usuario añade una etiqueta a tu métrica, la cardinalidad total aumenta a 100 × 11 × 10 = 11.000 series temporales. En este caso, el número de series temporales devueltas aumenta en 1000 en cada periodo de ejecución,aunque tu política de alertas no cambie. Si agregas datos a la máquina virtual, a pesar del aumento de la cardinalidad subyacente, solo obtendrás 100 series temporales devueltas.

Excluye las respuestas innecesarias

Configura tus condiciones para evaluar solo los datos necesarios para satisfacer tus necesidades de alertas. Si no tomas medidas para corregir algo, puedes excluirlo de tus políticas de alertas. Por ejemplo, probablemente no tengas que avisar de la máquina virtual de desarrollo de un becario.

Para reducir las alertas y los costes innecesarios, puedes excluir las series temporales que no sean importantes. Puedes usar las etiquetas de metadatos de Google Cloud para etiquetar recursos con categorías y, después, filtrar las categorías de metadatos que no necesites.

Utilizar operadores de flujo superior para reducir el número de series temporales que se devuelven

Si tu condición utiliza una consulta de PromQL o MQL, puedes usar un operador de flujos principales para seleccionar varias series temporales que se devuelvan con los valores más altos:

Por ejemplo, una cláusula topk(metric, 5) en una consulta de PromQL limita el número de series temporales que se devuelven a cinco en cada periodo de ejecución.

Si limitas las series a un número superior de series temporales, podrían faltar datos y recibir alertas defectuosas como las siguientes:

  • Si más de N series temporales infringen tu umbral, perderás datos que estén fuera de las N series temporales principales.
  • Si una serie temporal infractora se produce fuera de la serie temporal N principal, es posible que los incidentes se cierren automáticamente a pesar de que la serie temporal excluida sigue infringiendo el umbral.
  • Es posible que las consultas de condiciones 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 de flujos principales solo en políticas de alertas que evalúan muchas series temporales, como alertas para contenedores de Kubernetes concretos.

Aumentar la duración del periodo de ejecución (solo en PromQL)

Si tu condición usa una consulta de PromQL, puedes modificar la duración del periodo de ejecución definiendo el campo evaluationInterval de la condición.

Cuanto más largos sean los intervalos de evaluación, menos series temporales se devolverán al 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 la frecuencia que una consulta con un intervalo de 30 segundos.

Inhabilitar la función

Si tienes un contrato de Google Cloud que no caduca hasta abril del 2025, puedes retrasar la facturación de las alertas hasta que llegue la fecha de renovación de tu contrato. Para ello, solicita una exención al equipo de facturación de alertas de Cloud Monitoring. Las exenciones para clientes con contratos activos se estudiarán caso por caso.

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

Error Reporting

Puedes informar de los datos de errores a tu proyecto de Google Cloud mediante la API de Error Reporting o la API de Cloud Logging.

No se cobra por utilizar Error Reporting. Sin embargo, sí se pueden aplicar cargos por este servicio porque las entradas de registro se generan y luego las almacena.

Para conocer los límites que se aplican a tu uso de Error Reporting, consulta Cuotas y límites.

Cloud Profiler

El uso de Cloud Profiler no conlleva ningún coste.

Para conocer los límites que se aplican a tu uso de Profiler, consulta Cuotas y límites.

Cloud Trace

Los cargos de Trace se basan en el número de intervalos de Trace que se hayan ingerido y analizado. Cuando se envían datos de latencia a Trace, se empaquetan en una traza compuesta por intervalos, los cuales ingiere el backend de Cloud Trace. Cuando consultas los datos de trazas, Cloud Trace analiza los intervalos almacenados. En esta sección se ofrece la siguiente información:

  • Definición de los intervalos de trazas facturables y no facturables
  • Ejemplo de precios
  • Servicios para reducir la ingestión de intervalos de trazas
  • Opciones para configurar una política de alertas que te notifique cuando tu ingestión de intervalos de trazas alcance un umbral

Para obtener más información, consulta los precios actuales de Cloud Trace.

Para conocer los límites que se aplican a tu uso de Trace, consulta Cuotas y límites.

Para obtener más información sobre cómo consultar el uso actual o anterior, consulta la sección Calcular las facturas.

Intervalos de trazas no facturables

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: la ingestión de estas trazas no es facturable.

Intervalos de trazas facturables

La ingestión de los intervalos de trazas, excepto la de los intervalos que se indican en la sección Intervalos de trazas no facturables, se factura y su precio depende del volumen de ingestión. Se incluyen los intervalos que hayas creado con los instrumentos que añadas a la aplicación estándar de App Engine.

Ejemplos de precios

Los ejemplos corresponden a los precios de Trace a fecha de julio del 2020.

  • Si ingieres 2 millones de intervalos en un mes, el coste es de 0 USD. Los primeros 2,5 millones de intervalos ingeridos al mes son gratuitos.
  • Si ingieres 14 millones de intervalos en un mes, el coste es de 2,30 USD. Los primeros 2,5 millones de intervalos al mes son gratuitos, y el coste de los demás se calcula con esta fórmula: 11,5 millones de intervalos * 0,20 USD = 2,30 USD.
  • Si ingieres 1000 millones de intervalos en un mes, el coste es de 199 USD. Los primeros 2,5 millones de intervalos al mes son gratuitos, y el coste de los demás se calcula con esta fórmula: 997,5 millones de intervalos * 0,20 USD = 199,50 USD.

Reducción del uso de intervalos de trazas

Si quieres controlar el volumen de ingestión de intervalos de Trace, ajusta la frecuencia de muestreo de trazas. De esta forma, puedes buscar el equilibrio entre el número de trazas necesarias para analizar el rendimiento y el coste asumible.

En los sistemas donde hay un gran volumen de tráfico, la mayoría de los clientes muestrean 1 de cada 1000 transacciones (o incluso 1 de cada 10.000) y, aun así, disponen de información suficiente para analizar el rendimiento.

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

Alertas sobre los intervalos ingeridos al mes

Para crear una política de alertas que se active cuando la métrica de intervalos de Cloud Trace ingeridos al mes supere el límite que has definido, sigue los pasos que se indican más abajo.

Campo Nueva condición
Valor
Recurso y métrica En el menú Recursos, selecciona Global.
En el menú Categorías de métricas, seleccione Facturación.
En el menú Métricas, selecciona Intervalos de traza mensuales ingeridos.
Filtro
En series temporales
Agregación de series temporales		 sum
Ventana móvil 60 m
Función de ventana retrospectiva max
Campo Configurar activador de alerta
Campo
Valor
Tipo de condición Threshold
Activador de alertas Any time series violates
Posición de umbral Above threshold
Threshold value Tú eliges el valor aceptable.
Ventana de nueva prueba El valor mínimo aceptable es 30 minutos.

GKE Enterprise

Los registros y métricas del sistema GKE Enterprise no tienen coste económico. 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 en los clústeres de GKE que se hayan registrado en el momento de crearlos en proyectos habilitados de GKE Enterprise. Los registros del plano de control generan cargos de Cloud Logging y las métricas que están activadas de forma predeterminada se incluyen sin coste adicional.

Para ver la lista de los registros y las métricas de GKE incluidos, consulta las secciones Qué registros se recogen y Métricas disponibles.

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

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

Preguntas frecuentes

¿Qué funciones de producto son gratuitas?

El precio del uso de los productos de Google Cloud Observability se establece en función del volumen de datos. Aparte de los costes por volumen de datos que se describen en esta página, el uso de todas las funciones adicionales del producto Google Cloud Observability es gratuito.

¿Cuánto debo pagar?

Para calcular el coste del uso, consulta cómo estimar tus facturas.

Para despejar las dudas que tengas al respecto, consulta las preguntas sobre la facturación.

¿Cómo puedo analizar el desglose del uso?

El explorador de métricas incluye varias métricas que son de gran utilidad a la hora de desglosar y analizar el volumen de registros y de métricas. Si quieres obtener más información al respecto, consulta el uso detallado en el explorador de métricas.

Si te interesa aprender a gestionar tus costes, consulta estas entradas de blog:

¿Cómo afectan a la facturación los ámbitos de las métricas y los de registro?

En la mayoría de los casos, los ámbitos de métricas y los ámbitos de registro no afectan a la facturación. Los registros y las métricas los cobra el proyecto, la cuenta de facturación, la carpeta u organización que recibe los datos. El ámbito de las métricas de un proyecto define la colección de recursos cuyas métricas puede ver y supervisar el proyecto. El ámbito de las métricas no influye en qué recurso recibe datos de las métricas ni provocar que los datos se dupliquen. Del mismo modo, en el ámbito de registro solo se enumeran los recursos que almacenan o enrutan las entradas de registro que quieres ver.

Supongamos, por ejemplo, que tu organización tiene 100 máquinas virtuales (VM): 60 están alojadas en el proyecto A y 40 en el B. El proyecto A recibe y almacena las métricas de sus VMs, y se cobra cuando las métricas son facturables. De forma similar, el proyecto B recibe y almacena las métricas de sus VMs y se cobra cuando las métricas son facturables. Si creas un ámbito de métricas que incluya ambos proyectos, podrás ver las métricas combinadas de tus 100 VMs. Puedes ver solo las métricas del proyecto A, solo las métricas del proyecto B o la combinación de métricas. Aunque puedes ver las métricas de este proyecto de dos formas, no hay implicaciones de facturación.

¿Qué ocurre si supero las asignaciones gratuitas?

Se te empezará a cobrar automáticamente por el uso cuando superes las asignaciones gratuitas. No perderás ningún registro ni ninguna métrica. Para calcular el posible coste, consulta cómo estimar tu facturación.

Puedes crear una política de alertas para monitorizar tu uso y recibir alertas cuando estés a punto de alcanzar el umbral de facturación.

En mis proyectos tengo muchos registros de Google Cloud que no uso. Me preocupa que me los cobren. ¿Cómo puedo evitarlo?

Si quieres controlar la ingestión en Logging, puedes excluir registros. Para obtener más información al respecto, consulta la sección sobre cómo reducir el uso de registros.

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

No, los servicios que envían entradas de registro no pueden determinar si estas se ingieren en Logging o no.

¿Se me cobrará dos veces por los registros de los flujos de la nube privada virtual?

Si envías a Logging los registros de los flujos de la nube privada virtual (VPC), se te exime de pagar el cargo por generarlos; solo tienes que abonar la tarifa por usar Logging. Sin embargo, si los envías, pero luego excluyes esos registros de Logging, se aplican los cargos correspondientes a los registros de flujos de la VPC. Para obtener más información, consulta la calculadora de precios de Google Cloud y, a continuación, selecciona la pestaña titulada "Cloud Load Balancing y servicios de red".

1 A la hora de establecer los precios, todas las unidades se tratan comobinario medidas, como, por ejemplo:mebibytes (MiB o 2)20 bytes) ogibibytes (GiB o 2)30 bytes).

2 No se cobra por las métricas de Google Cloud ni de GKE Enterprise que se miden hasta 1 dato por minuto, que es la resolución más alta actualmente. En el futuro, es posible que se apliquen cargos por métricas que tengan una resolución superior.

3 Las métricas de procesos se recogen a una tarifa predeterminada y predefinida de una vez por minuto, que no se puede cambiar. De forma general, estos datos cambian lentamente, por lo que estas métricas se muestrean en exceso. Por lo tanto, las métricas del proceso de carga al 5 % de la tarifa estándar se alinean con la tarifa estándar si las métricas se muestrean a intervalos de 20 minutos. De esta forma, a los usuarios que recojan 100 MiB de datos de esas métricas se les cobrará solo por 5 MiB.

Siguientes pasos

Solicita un presupuesto personalizado

Gracias al modelo de pago por uso de Google Cloud, solo pagas por los servicios que usas. Ponte en contacto con nuestro equipo de Ventas para solicitar un presupuesto personalizado para tu empresa.
Contactar con Ventas