Precios de Google Cloud Observability

Los precios de Observability de Google Cloud te permiten controlar el uso y los gastos. El precio de los productos Observability de Google Cloud se calcula según el volumen de datos o el uso. Con las asignaciones de uso de datos gratuito, puedes 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 *
excepto los registros de red proporcionados por el operador.		 0, 50 USD/GiB;
Cargo único por el envío de registros al almacenamiento del contenedor de registros para realizar tareas de indexación, consulta y análisis.Incluye hasta 30 días de almacenamiento en contenedores de registro. 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 proporcionado por el operador† 0,25 USD/GiB;
Cargo único por el envío de registros de telemetría de red al almacenamiento del contenedor de registros para realizar tareas de indexación, consulta y análisis.Incluye hasta 30 días de almacenamiento en contenedores de registro. No se aplican cargos adicionales por consultar y analizar datos de registros. 		No aplicable 1 de octubre del 2024
Conservació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 hayan conservado durante el periodo de conservación predeterminado no tienen ningún coste de conservación. 1 de enero del 2022
Enrutador 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 aplican cargos por el almacenamiento de los registros en el segmento de registros_Required.
 †  Los registros vendidos son los registros de red de Google Cloud que generan los servicios de Google Cloud cuando se habilita la generación de estos registros. Los registros que se venden incluyen los registros de flujos de VPC, los registros de reglas de cortafuegos y los 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 el artículo sobre registros vendidos.
 ‡  No hay cargos por conservación de los registros almacenados en el segmento de registros _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 recibidos a través de la API de Cloud Logging a un destino admitido. Es posible que se apliquen cargos por el destino a los registros enrutados.
 ♥  Actualizar un contenedor de registros para usar Analíticas de registros o enviar consultas de SQL desde la página Analíticas de registros no tiene coste económico.
 Nota: El texto que explica los precios de Cloud Logging cambió el 19 de julio del 2023. Sin embargo, las asignaciones gratuitas y las tarifas no han cambiado. Es posible que tu factura haga referencia al antiguo idioma de precios.

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 datos ingeridos 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 que se facturan mediante 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-50.000 millones de muestras ingeridas#
0,048 USD por millón de muestras: siguientes 50.000-250.000 millones de muestras ingeridas
0,036 USD por millón de muestras: siguientes 250.000-500.000 millones de muestras ingeridas
0,024 USD por millón de muestras: más de 500.000 millones de muestras ingeridas		 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
Ejecución de Monitorización de las comprobaciones de disponibilidad del servicio 0,30 USD por 1000 ejecuciones‡ 1 millón de ejecuciones por proyecto de Google Cloud 1 de octubre del 2022
Ejecución de Monitorizar los supervisores 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 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♣		 No aplicable Abril del 2026
†  Google Cloud Managed Service para Prometheus utiliza el almacenamiento de Cloud Monitoring para crear datos de métricas creados de forma externa y la API de Monitoring para recuperarlos. Managed Service para Prometheus se basa en muestras ingeridas en lugar de bytes para que se ajuste 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.
 #  Los ejemplos se cuentan por cada cuenta de facturación.
 ‡  Las ejecuciones se cobran en la cuenta de facturación en la que están definidas. Consulta el artículo Precios de la ejecución de la comprobación de disponibilidad del servicio para obtener más información.
 *  Las ejecuciones se cobran en la cuenta de facturación en la que están definidas. En cada ejecución, podrían aplicarse cargos adicionales por otros servicios de Google Cloud, como 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 monitorización de Google Cloud, consulta las siguientes secciones de esta página:

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

Comprobar el uso

Para consultar tu uso actual, ve a la página de informes de Facturación de Cloud, que se encuentra 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 VM 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

Si quieres recibir una notificación cuando tus cargos previstos o facturables superen un presupuesto concreto, puedes crear 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 usando 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 los contenedores de Logging que almacenan los datos de registros. Se te cobra por el volumen de datos de registros que se almacenan en el segmento de registros _Default y en los segmentos 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.

En el caso del segmento de registros _Default y de los segmentos de registros definidos por el usuario, Logging también aplica cargos cuando los registros se conservan durante un periodo superior al período de conservación predeterminado, que es de 30 días.

Logging no aplica cargos adicionales por enrutar registros, usar la API de Cloud Logging, configurar alcances de registro o por los registros almacenados en el segmento de registros _Required, que tiene un periodo de conservación fijo de 400 días.

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

Para ver un resumen de 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

Logging crea automáticamente dos segmentos de registros por cada proyecto de Google Cloud: _Required y _Default. Después, Logging crea automáticamente sumideros de registros llamados _Required y _Default que enrutan los registros a los segmentos de registros correspondientes. No puedes inhabilitar ni modificar el sumidero _Required. Puedes inhabilitar o modificar el sumidero _Default para evitar que el segmento _Default almacene nuevos registros.

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

En el caso del segmento de registros de _Default y de los segmentos de registros definidos por el usuario, puedes configurar un periodo de conservación personalizado.

Puedes actualizar tus contenedores de registros para usar Analíticas de registros. Actualizar un segmento de registros para usar Analíticas de registros no tiene coste económico.

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

Precio de almacenamiento

No se aplica ningún cargo por los registros almacenados en el segmento de registros _Required. No puedes eliminar el segmento _Required ni modificar el sumidero _Required. El segmento _Required almacena los siguientes registros:

Cuando utilizas Logging, se te cobra por el volumen de datos de registros preíndices que se almacena en el segmento de registros _Default y en los segmentos de registros definidos por el usuario, cuando el volumen total supera la asignación mensual gratuita. Cada entrada de registro que escribas en el segmento de registro _Default o en un segmento de registro definido por el usuario se contabilizará de cara a tu asignación de almacenamiento. Por ejemplo, si tienes sumideros que enrutan una entrada de registro a tres segmentos diferentes, esa entrada de registro se almacena tres veces.

Precios de retención

En la siguiente tabla se indican los periodos de conservación de los 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.

Los registros tienen un coste de conservación cuando se conservan durante más tiempo que el periodo de conservación predeterminado. No puedes configurar el periodo de conservación del segmento de registros _Required. No se aplican costes de conservación cuando los registros se almacenan solo durante el periodo de conservación predeterminado del segmento de registros.

Si acortas el periodo de conservación de un segmento de registros, se aplica un período de gracia de siete días durante el cual no se eliminan los registros vencidos. No puedes consultar ni ver registros caducados. Sin embargo, en esos siete días, puedes restaurar el acceso completo ampliando el periodo de retención del segmento de registros. Los registros almacenados durante el periodo de gracia se incluyen en los costes de conservación.

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

Registros de red proporcionados

Los registros de red vendidos solo están disponibles cuando configuras la generación de registros. Los servicios que generan registros de red proporcionados por el operador cobran por la generación de registros. Si almacenas estos registros en un segmento de registros o los diriges a otro destino admitido, 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 la telemetría de red.

Para obtener información sobre cómo habilitar los registros de red que se venden, consulta Configurar Registros de flujo de VPC, Usar Registros de reglas de cortafuegos, y Cloud NAT: registros y métricas.

Para encontrar los registros de red de tu proveedor, filtra en 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 costes de almacenamiento de Cloud Logging, configura filtros de exclusión en los sumideros de registros para excluir determinados registros del enrutamiento. Los filtros de exclusión pueden quitar todas las entradas de registro que coincidan con el filtro o solo quitar un porcentaje de los registros. Cuando una entrada de registro coincide con un filtro de exclusión de un sumidero, este no dirige la entrada de registro al destino. Las entradas de registro excluidas no se restan de la asignación de almacenamiento. Consulta las instrucciones sobre cómo configurar filtros de exclusión en Exclusión de registros.

Otra opción para reducir los costes 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 los registros se reciban en un destino:

Para obtener información sobre cómo enrutar los registros fuera de Cloud Logging, consulta la sección Ruta los registros a los 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 los bytes de registro ingeridos al mes

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

Nueva condición
Campo
Valor
Recurso y métrica En el menú Recursos, selecciona Global.
En el menú Categorías de métricas, seleccione Métrica basada en registros.
En el menú Métricas, selecciona Bytes de registros ingeridos al mes.
Filtro Ninguno
En series temporales
Agregación de series temporales		 sum
Ventana móvil 60 m
Función de ventana continua max
Configurar activador de alertas
Campo
Valor
Tipo de condición Threshold
Activación de la alerta Any time series violates
Posición del umbral Above threshold
Valor de umbral Tú eliges el valor aceptable.
Ventana de volver a hacer la 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 las comprobaciones de disponibilidad del servicio.

  • Ejecución de monitores sintéticos.

  • Las condiciones de las políticas de alertas se miden por el número de condiciones activas al mes.

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

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 ver tu uso actual, haz una de las siguientes acciones:

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

    Ve a Facturación

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

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

    Ve a Ajustes

    Si utilizas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Monitorización.

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 de Google Cloud Observability para introducir los 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 de Managed Service for Prometheus están diseñados para poder controlarse. 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 global 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 Prometheus para reducir las métricas en el momento de la ingestión, en función de las opciones de coincidencia de las etiquetas.

  • Mantén los datos locales de alta cardinalidad y bajo valor. Puedes ejecutar Prometheus estándar junto con el servicio gestionado usando las mismas configuraciones y mantener los datos que no vale la pena enviar al almacén de datos mundial del servicio localmente.

Los precios de Managed Service for 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 for Prometheus se facturara según cada métrica, pagarías una cardinalidad de un mes completo cada vez que se añadiera un nuevo contenedor. Con los precios por muestra, pagas solo cuando el contenedor se está ejecutando.

Consultas, incluidas las consultas de alerta

Todas las consultas que emite el usuario, incluidas las que se emiten cuando se ejecutan reglas de grabación 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. El servicio gestionado de Prometheus de Google Cloud se factura según una muestra.

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 intervalo
Hasta 50 mil millones (50.000 millones) 0,06 $/millón 3000,00 USD
De 50 a 250 miles de millones (250.000 millones) 0,048 $/millón 9600,00 USD
De 250.000 a 500.000 millones 0,036 $/millón 9000,00 USD
Más de 500.000 millones 0,024 $/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, el número de muestras es inferior a 50.000 millones, por lo que solo se aplica la primera tarifa. Las muestras no se cobran según las otras tarifas.

Variante Muestras ingeridas Intervalo de ingestión Managed Service for Prometheus
(0,06 $, 0,048 $, 0,036 $ y 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 		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 $



262,80$

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.
  • Las muestras no se cobran con las otras 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 Managed Service for Prometheus
(0,06 $, 0,048 $, 0,036 $ y 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 		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 $



2628,00$

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 restantes 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 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 Managed Service for Prometheus
(0,06 $, 0,048 $, 0,036 $ y 0,024 $)
A (1 muestra/15 s)



Total 		50.000 millones
200.000 millones
250.000 millones
749.040 millones
1349,040 millones 		Hasta 50.000 millones
Hasta 250.000 millones
Hasta 500.000 millones
Más de 500.000 millones 		3000,00 €
9600,00 €
9000,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 		3000,00 EUR
9600,00 EUR
3141,36 EUR

15.741,36 EUR

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 restantes se cobran con la tercera tarifa.
  • Los 108.124.000 millones de muestras restantes se cobran con la cuarta tarifa.

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 restantes se cobran con la tercera tarifa.
  • Los 26.656.000 millones de muestras restantes se cobran con la cuarta tarifa.
Variante Muestras ingeridas Intervalo de ingestión Managed Service for Prometheus
(0,06 $, 0,048 $, 0,036 $ y 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 		3000,00 USD
9600,00 USD
9000,00 USD
2594976,00 USD
2616576,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 restantes se cobran con la tercera tarifa.
  • Los 108.299.200 millones de muestras restantes se cobran con la cuarta tarifa.
Variante Muestras ingeridas Intervalo de ingestión Managed Service for Prometheus
(0,06 $, 0,048 $, 0,036 $ y 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 		3000,00 EUR
9600,00 EUR
9000,00 EUR
2599180,80 EUR
2620780,80 EUR

Precios de la ejecución de la comprobación de disponibilidad del servicio (en vigor a partir del 1 de octubre del 2022)

Los cargos de monitorización por cada ejecución regional de una comprobación de disponibilidad, 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 SKU "CA14-D3DE-E67F" para "Comprobaciones de tiempo de funcionamiento de la monitorización".

En los siguientes ejemplos se muestra cómo estimar los costes de ejecutar comprobaciones de tiempo de funcionamiento. Estos ejemplos sirven para ilustrar las técnicas de cálculo y no para proporcionar datos de facturación.

Contar las ejecuciones de las comprobaciones de disponibilidad del servicio

Para estimar el coste de tus comprobaciones de tiempo de funcionamiento, debes saber cuántas ejecuciones regionales se realizan en un mes. Los cargos de monitorización se cobran a 0,30 USD por cada 1000 ejecuciones, con un límite mensual gratuito de 1 millón de ejecuciones.

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

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

El número de ejecuciones de cada comprobación de tiempo de funcionamiento depende de las siguientes opciones de configuración:

  • Con qué frecuencia se ejecuta la comprobación del tiempo de funcionamiento: cada minuto, cada 5 minutos, cada 10 minutos o cada 15 minutos.

  • El número de regiones en las que se ejecuta la comprobación del tiempo de funcionamiento.

  • El número de objetivos para los que se ha configurado la comprobación de disponibilidad del servicio. Si la comprobación del tiempo de funcionamiento se ha configurado para una sola máquina virtual, el número de objetivos es 1. Si la comprobación de disponibilidad se ha configurado para un grupo de recursos, el número de objetivos es el número de recursos del grupo.

Cuando configuras una comprobación de disponibilidad, especificas una ubicación para la comprobación de disponibilidad, 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 y las regiones a las que se mapean:

Ubicación de 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 tus comprobaciones de tiempo de funcionamiento para que se ejecuten en al menos tres regiones.

Para estimar el número de ejecuciones de una comprobación de disponibilidad, debes saber en cuántas regiones se aplica la ubicación de la comprobación de disponibilidad:

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

Un mes tiene aproximadamente 730 horas (365 días divididos entre 12 meses y multiplicados por 24 horas), lo que equivale a 43.800 minutos.

  • Una comprobación de tiempo de funcionamiento configurada para que se ejecute una vez por minuto en USA ejecuciones en 3 regiones. Si esta comprobación del tiempo de funcionamiento está configurada para comprobar una única máquina virtual, se ejecutará 131.400 (3 * 43.800) veces al mes. Si la comprobación está configurada para comprobar un grupo de recursos de 10 miembros, la comprobación de disponibilidad se ejecuta 1314000 veces (10 * 131400) en un mes.

  • Una comprobación del tiempo de actividad configurada para que se ejecute una vez por minuto en ASIA_PACIFIC, EUROPE y USA se ejecuta en 5 regiones. Esta comprobación del tiempo de funcionamiento se ejecuta 219.000 veces al 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 comprobación del tiempo de funcionamiento configurada para ejecutarse con diferentes frecuencias en diferentes números de zonas:

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 		8.760
11.680
14.600
17.520

Ejemplos

Para estimar los precios, determina el total de ejecuciones mensuales y resta 1.000.000. Los anuncios que no se hayan mostrado se cobrarán a 0,30 USD por cada 1000 impresiones, por lo que debes multiplicar el número de anuncios que te quedan por 0,0003.

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

Situación 1: tienes una comprobación de disponibilidad en la ubicación USA que comprueba una VM una vez por minuto. Esta comprobación se ejecuta en 3 regiones. La comprobación se ejecuta 131.400 veces al mes y no tiene coste.

Ejecuciones mensuales totales
 		 Ejecuciones mensuales por las que se cobre
(más de 1.000.000)		 Coste
(0,30 USD por 1000 ejecuciones)
131.400 0 0,00 USD

Situación 2: tienes una comprobación de disponibilidad en la ubicación USA que comprueba un grupo de recursos de 10 miembros una vez por minuto. Esta comprobación se ejecuta 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 este escenario y el escenario 1 es el número de objetivos.

Ejecuciones mensuales totales
 		 Ejecuciones mensuales por las que se cobre
(más de 1.000.000)		 Coste
(0,30 USD por 1000 ejecuciones)
1314000 (10 objetivos) 314.000 94,20 USD

Situación 3: tienes 10 GLOBAL comprobaciones de tiempo de funcionamiento, cada una de las cuales comprueba 1 VM una vez por minuto. Estas comprobaciones se ejecutan en 6 regiones, por lo que cada comprobación se ejecuta 262.800 veces al mes. El total de ejecuciones mensuales es de 2.628.000 (10 * 262.800). Este caso práctico cuesta 488,40 USD al mes.

Ejecuciones mensuales totales
 		 Ejecuciones mensuales por las que se cobre
(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 en la ubicación USA que comprueban 1 VM cada 5 minutos. Estas comprobaciones se ejecutan en 3 regiones, por lo que cada comprobación 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 tienes 2 GLOBAL comprobaciones de disponibilidad que comprueban 1 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 140.160 (105.120 + 35.040). Esta situación no tiene coste económico.

Ejecuciones mensuales totales
 		 Ejecuciones mensuales por las que se cobre
(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 monitores sintéticos (fecha de entrada en vigor: 1 de noviembre del 2023)

Cloud Monitoring cobra por cada ejecución de un monitorización sintética, más allá de la cuota gratuita de 100 ejecuciones al mes 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, 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 te cobrarán, resta la cuota gratuita del número total de ejecuciones y, a continuación, multiplica el resultado por el coste:

Ejecuciones mensuales totales
 		 Ejecuciones mensuales imputables
(más de 100 ejecuciones por cuenta de facturación)		 Coste
(1,20 USD por 1000 ejecuciones)
26.784 26.684 32,02 €

Precios de las alertas

A partir de abril del 2026, Cloud Monitoring empezará a cobrar por las 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 se encuentra en un estado que requiere una respuesta.

    El precio por cada condición es de 1,50 USD al mes. Para dejar de recibir cargos por una condición, debes eliminar la política de alertas. Aplazarla o inhabilitarla no hace que dejes de pagar.

  • Políticas de alertas basadas en métricas y en registros: las políticas de alertas que usan cualquier tipo de condición, excepto las de coincidencia con 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 periodo de ejecución, las condiciones de las políticas de alertas basadas en métricas ejecutan sus consultas en el almacén de datos de Cloud Monitoring. Las series temporales devueltas 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 coincidencia de registros no devuelven ninguna serie temporal.

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

  • Series temporales devueltas: 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 devueltas en un mes depende 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 periodo de ejecución.

    Por ejemplo, imagina que tienes la siguiente configuración:

    • 100 máquinas virtuales (VMs), 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.

    Como tienes 100 máquinas virtuales, y cada una puede generar 10 series temporales (una por cada valor de etiqueta), tienes un total de 1000 series temporales subyacentes. Cada VM también contiene una etiqueta similar a los metadatos que registra a cuál de tus cinco servicios pertenece.

    Puedes configurar tus políticas de alertas de las siguientes maneras mediante PromQL, donde cada configuración da como resultado un número distinto de series temporales devueltas por periodo de ejecución:

    Configuración Consulta de PromQL Series temporales devueltas por periodo
    No hay agregación rate(metric_name[1m]) 1000
    Agregación 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
    Filtrar y agregar datos en una VM sum (rate(metric_name{vm="my_vm_name"}[1m])) 1
    Filtrar y agregar datos en un servicio sum (rate(metric_name{service="my_service_name"}[1m])) 1

Ejemplos de precios

En los siguientes ejemplos, el mes tiene 30 días, por lo que se producen 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 de PromQL)

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

En este ejemplo, usa 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
  • Condición de agregación al nivel de máquina virtual
  • 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 las series temporales: 100 series temporales devueltas por periodo * 86.400 periodos al mes = 8,6 millones de series temporales devueltas al mes * 0,35 USD por 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), agregación en la máquina virtual, 30 segundos

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

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

En este ejemplo, usa 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
  • Condición de agregación a nivel de máquina virtual
  • 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 las series temporales: 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 USD al mes

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

En este ejemplo, usa las siguientes configuraciones:

Datos

  • 100 máquinas virtuales, cada una de las cuales 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 las series temporales: 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 USD al mes

Ejemplo 5: Agregar una política a la VM; mayor cardinality subyacente por VM, 30 segundos

En este ejemplo, usa 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
  • Condición de agregación al nivel de máquina virtual
  • 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 las series temporales: 100 series temporales devueltas por periodo * 86.400 periodos al mes = 8,5 millones de series temporales devueltas al mes * 0,35 USD por millón de series temporales = 3,02 USD al mes
  • Coste total: 4,52$al mes

Ejemplo 6: Agregar una política a la máquina virtual; unir dos métricas en una condición; 30 segundos

En este ejemplo, usa las siguientes configuraciones:

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
  • Condición de agregación a nivel de máquina virtual
  • La condición usa un operador OR para unir 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 las series temporales: 2 métricas * 100 series temporales devueltas por métrica por periodo * 86400 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 USD al 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)
Costes resultantes
  • Coste de la condición: 100 condiciones * 1,50 USD al mes = 150,00 USD al mes
  • Coste de las series temporales: 0 USD (las políticas de alertas basadas en registros no devuelven series temporales).
  • Coste total: 150,00 USD al 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 coste de tus facturas de alertas.

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

Debido al coste de 1,50 USD por condición, es más rentable usar una política de alertas para monitorizar varios recursos que usarla para monitorizar cada recurso. Por ejemplo, compara el ejemplo 1 con el ejemplo 2: en ambos ejemplos monitorizas el mismo número de recursos. Sin embargo, el ejemplo 2 utiliza 100 políticas de alertas, mientras que el ejemplo 1 solo usa una. Por lo tanto, el ejemplo 1 es casi 150 USD más barato al mes.

Agrupa los datos solo en el nivel en el que necesites recibir alertas

La agregación a niveles de granularidad más altos tiene un coste mayor que la agregación a niveles de granularidad más bajos. Por ejemplo, agregar datos al nivel de proyecto de Google Cloud es más barato que agregarlos al nivel de clúster, y agregarlos al nivel de clúster es más barato que agregarlos al nivel de clúster y espacio de nombres.

Por ejemplo, compara el ejemplo 1 con el ejemplo 4: ambos ejemplos se basan en los mismos datos y tienen una sola política de alertas. Sin embargo, como la política de alertas del ejemplo 4 se aplica al servicio, es menos costosa que la política de alertas del ejemplo 1, que se aplica de forma más específica a la máquina virtual.

Además, 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. Sin embargo, como la política de alertas del ejemplo 1 y del ejemplo 5 se agrega a la VM y el número de VMs es el mismo en ambos ejemplos, los precios son equivalentes.

Cuando configures las políticas de alertas, elige los niveles de agrupación que mejor se adapten a tu caso. Por ejemplo, si te interesa recibir alertas sobre el uso de la CPU, es posible que quieras agregar los datos a nivel de máquina virtual y de CPU. Si te interesa recibir alertas sobre la latencia por punto de conexión, es posible que quieras agrupar los datos a nivel de punto de conexión.

No generes alertas con datos sin procesar ni agregados

La monitorización usa un sistema de métricas dimensionales, donde 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, la cardinalidad total es 100 * 10 * 10 = 10.000.

Debido a la forma en que se escala la cardinalidad, las alertas basadas en datos sin procesar pueden ser extremadamente caras. En el ejemplo anterior, se devuelven 10.000 series temporales para cada periodo de ejecución. Sin embargo, si se agrega a la VM, solo se devuelven 100 series temporales por periodo de ejecución, independientemente de la cardinalidad de la etiqueta de los datos subyacentes.

Las alertas basadas en datos sin procesar también te exponen al riesgo de que se incrementen las series temporales cuando tus métricas reciben nuevas etiquetas. En el ejemplo anterior, si un usuario añade una etiqueta nueva a la 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, en cambio, se agrega a la VM, a pesar del aumento de la cardinalidad subyacente, solo se devolverán 100 series temporales.

Filtra las respuestas innecesarias

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

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

Usa operadores de flujo principal para reducir el número de series temporales devueltas

Si tu condición usa una consulta PromQL o MQL, puedes utilizar un operador de top-streams para seleccionar un número de las series temporales devueltas 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 devueltas a cinco en cada periodo de ejecución.

Si limitas el número máximo de series temporales, es posible que falten datos y que se generen alertas erróneas, como las siguientes:

  • Si más de N series temporales superan el umbral, no se mostrarán los datos que no pertenezcan a las primeras N series temporales.
  • Si una serie temporal infractora se encuentra fuera de las N series temporales principales, es posible que tus incidentes se cierren automáticamente aunque la serie temporal excluida siga infringiendo el umbral.
  • Puede que tus consultas de condición no muestren contexto importante, como series temporales de referencia que funcionan según lo previsto.

Para mitigar estos 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.

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

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

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

Desactivar

Si tienes un contrato de Google Cloud que no vence hasta abril del 2026, puedes solicitar una exención al equipo de facturación de Cloud Monitoring para que se te aplique una excepción en la facturación de las alertas hasta que se deba renovar tu contrato. Las exenciones para los clientes con contratos activos se considerará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 datos de errores a tu proyecto de Google Cloud mediante la API de Error Reporting o la API de Cloud Logging.

No hay ningún cargo por usar la función de informes de errores. Sin embargo, es posible que se te apliquen cargos de Cloud Logging, ya que Cloud Logging genera las entradas de registro y, después, las almacena.

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

Cloud Profiler

No hay ningún coste asociado al uso de Cloud Profiler.

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 información sobre cómo ver tu uso actual o pasado, consulta Cómo estimar tus facturas.

Intervalos de trazas no facturables

Los precios de Cloud Trace no se aplican a los intervalos que generan automáticamente el entorno estándar de App Engine, las funciones de Cloud Run o Cloud Run. La ingestión de estas trazas no es facturable.

Las trazas generadas automáticamente no consumen cuota de la API de Cloud Trace y no se tienen en cuenta en las métricas de uso de la API.

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.

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, seleccione Intervalos de traza ingeridos al mes.
Filtro
En series temporales
Agregación de series temporales		 sum
Ventana móvil 60 m
Función de ventana continua max
Configurar activador de alertas
Campo
Valor
Tipo de condición Threshold
Activación de la alerta Any time series violates
Posición del umbral Above threshold
Threshold value Tú eliges el valor aceptable.
Ventana de volver a hacer la prueba El valor mínimo aceptable es 30 minutos.

GKE Enterprise

No hay ningún cargo 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 crear el clúster en un proyecto habilitado para GKE Enterprise. Los registros de la zona de control conllevan cargos de Cloud Logging, mientras que las métricas incluidas de forma predeterminada no tienen coste adicional.

Para ver la lista de registros y métricas de GKE incluidos, consulta Qué registros se recogen 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 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 de los productos de Observability de Google Cloud se basa en el volumen de datos. Además de los costes de volumen de datos que se describen en esta página, todas las funciones adicionales de Observability de Google Cloud son gratuitas.

¿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 quieres saber cómo gestionar tus costes, consulta estos artículos de blog:

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

En la mayoría de los casos, los ámbitos de métricas y los ámbitos de registros no afectan a la facturación. Los registros y las métricas se cobran al proyecto, la cuenta de facturación, la carpeta o la organización que recibe los datos. El ámbito de las métricas de un proyecto define la colección de los recursos cuyas métricas puede ver y monitorizar. Si defines un ámbito de métricas, no afectará al recurso que recibe los datos de las métricas ni hará que se dupliquen. De forma similar, un ámbito de registro solo enumera 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 selecciona la pestaña "Cloud Load Balancing and Network Services".

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 medidas hasta a 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