Precios de Cloud Monitoring

Los precios de Google Cloud Observability te permiten controlar tu uso y el gasto. Los precios de los productos de Google Cloud Observability se determinan según el volumen de datos o uso. Puedes utilizar las asignaciones de uso de datos gratuitas para empezar sin pagos o compromisos 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
Almacenamiento de registros* 0,50 USD/GiB;
Un único cargo por la transmisión de registros en el almacenamiento de segmentos de registros para la indexación, las consultas, y el análisis; 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
Conservación de Logging† 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.
Router de registros‡ Sin cargos adicionales No aplicable
Analíticas de registros♣ Sin cargos adicionales 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 la Segmento de registros de _Required.
 † No se aplican cargos de retención por 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 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 segmento de registros para usar Analíticas de registros o emitir consultas de SQL no conlleva ningún coste. en la página Analíticas de registros.
 Nota: El idioma de 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 el idioma de los precios.

Resumen de precios de Cloud Monitoring

Función Precio Asignación gratuita al mes Fecha de entrada en vigor
<ph type="x-smartling-placeholder"></ph> Todos los datos de Monitoring
excepto los datos ingeridos por 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 que no son facturables
Primeros 150 MiB por cuenta de facturación de métricas cobradas por bytes ingeridos		 1 de julio del 2018
Métricas ingeridas mediante Google Cloud Managed Service para Prometheus, que incluye Métricas del plano de control de GKE 0,06 USD por millón de muestras†: entre 0 y 50.000 millones de muestras ingeridas†
0,048 USD por millón de muestras: próximos entre 50.000 y 250.000 millones de muestras ingeridas
0,036 USD por millón de muestras: próximos 250-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
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 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 7 de enero del 2025
† Servicio gestionado de Google Cloud para Prometheus Almacenamiento de Cloud Monitoring para datos y usos de métricas creados externamente la API de Monitoring para obtener esos datos. Servicio gestionado para medidores de Prometheus basado en muestras ingeridas en lugar de bytes que se deben alinear con Prometheus convenciones de uso. 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 <ph type="x-smartling-placeholder"></ph> 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 procedentes de otros servicios de Google Cloud incluidos servicios como Cloud Functions, Cloud Storage y Cloud Logging. Para obtener información acerca de 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 obtener información sobre 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. de 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, sigue estos pasos: crea una alerta desde 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, realiza una de las siguientes acciones siguiente:

    • 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 _Default y en los segmentos de registros definidos por el usuario, cuando el volumen supere asignación mensual gratuita. Para el segmento de registros _Default y para los segmentos de registros definidos por el usuario, También se cobra cuando los registros se conservadas durante más tiempo del periodo de retención predeterminado, que es 30 días.

No se aplican cargos adicionales por Logging por enrutar registros, para usar la API de Cloud Logging o en el caso de 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 un resumen de la información sobre precios, consulta 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

En cada proyecto de Google Cloud, Logging automáticamente crea dos segmentos de registros: _Required y _Default. En estos dos segmentos, Logging crea automáticamente sumideros de registro. llamado _Required y _Default, que dirigen registros al segmentos de registros. No puedes inhabilitar ni modificar el sumidero de _Required. Puede inhabilitar o modificar el sumidero _Default para evitar que el segmento _Default almacenar 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 en proyectos de Google Cloud en tus la organización de Google Cloud a esos segmentos de registros.

En el caso de los segmentos de registros definidos por el usuario y de _Default, puedes hacer lo siguiente: Configurar un periodo de retención personalizado.

Puedes actualizar tus segmentos de registros para usarlos 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 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:

.

Logging cobra por el volumen indexado previamente de datos de registro que se almacenados en el segmento de registros de _Default y en los contenedores de registros definidos por el usuario, Si el volumen total supera la asignación mensual gratuita. Cada escritura de una entrada de registro en el contenedor de registros _Default o en un segmento de registros definido por el usuario se tiene en cuenta de cara a la asignación de almacenamiento. Por ejemplo, si tienes sumideros que enrutan una entrada de registro a tres segmentos de registros, entonces 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 contenedores 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.

Cuando los registros se conservan durante más tiempo, se cobran los costes de retención. que el periodo de conservación predeterminado. No se puede configurar el periodo de conservación para el contenedor de registros _Required. No se aplica ningún coste de conservación si los registros solo se almacenan durante periodo de conservación predeterminado del segmento de registros.

Si acortas el periodo de conservación de un segmento de registros, habrá un periodo de periodo de gracia en el que no se eliminan los registros caducados. No puedes consultar ni ver registros caducados. Sin embargo, durante ese tiempo, podrás restaurar el acceso completo ampliar 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, se te puede cobrar los costes de almacenamiento y retención varias veces. Por ejemplo, supongamos que diriges Una entrada de registro en el segmento de registros de _Default y en uno definido por el usuario. Además, supongamos que configuras un periodo de retención personalizado para ambos segmentos. superior a 30 días. Para esta configuración, recibirás dos cargos por almacenamiento y dos por retención.

Reducir el almacenamiento de registros

Logging te permite identificar y excluir manualmente entradas de registro de se almacenen en segmentos de registros mediante la configuración de filtros de exclusión en los sumideros. Los filtros de exclusión te permiten reducir los costes de almacenamiento. Por otro lado, también te recomendamos si quieres enrutar tus registros fuera de Cloud Logging.

Los filtros de exclusión pueden quitar todas las entradas de registro que coincidan con el filtro, o solo puede eliminar un porcentaje de los registros que coincidan con el filtro. Cuando una entrada de registro coincide con un filtro de exclusión de un sumidero, ese sumidero no dirige la entrada de registro al destino. Como resultado, el destino no ingiere la entrada de registro. Las entradas de registro excluidas no se tienen en cuenta con respecto a la asignación de almacenamiento. Para obtener instrucciones sobre cómo configurar filtros de exclusión, consulte Exclusiones de registros

Si quieres conservar el acceso a los registros que no están almacenados en segmentos de registros, también puedes usar sumideros de registro para enrutar las entradas de registro de Cloud Logging a un destino. Cloud Logging no te cobra por enrutar registros. Sin embargo, sí se te cobrará por los servicios de Google Cloud que reciban tus registros. por el uso. Para obtener más información, consulta los siguientes documentos:

Para obtener información sobre cómo enrutar registros fuera de Cloud Logging, consulta Enruta los 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 de bytes de registro escritos en tus segmentos de registros superan el límite definido por el usuario en Cloud Logging, utiliza los siguientes ajustes.

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 Monitoring:

    Ir a Configuración de Monitoring

    Si utilizas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo sea 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 facturable. 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, utiliza 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 de Managed Service para Prometheus se han diseñado para ser controlable. 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 que se envían a al almacén de datos lobal del servicio; para obtener más información, consulta Filtrar las métricas exportadas. Use configuraciones de reetiquetado de métricas en su Configuración de extracción de Prometheus para eliminar métricas en el momento de la ingestión sobre las coincidencias de etiquetas.

  • Mantenga una alta cardinalidad y datos de bajo valor de forma local. Puedes ejecutar una versión estándar de Prometheus junto con el servicio gestionado, usando las mismas configuraciones de paisaje y mantener los datos de forma local y que no merezca la pena enviarlo al almacén de datos global del servicio.

Los precios de Managed Service para Prometheus se han diseñado para ser predecible.

  • 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 el servicio gestionado de Prometheus se cobra por métrica: pagarías la cardinalidad de un mes completo cada vez que se colocaba 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 el usuario, incluidas las emitidas cuando Prometheus reglas de grabación se ejecutan y se cobran mediante 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. Basada en muestras se utiliza para 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 €
De 50 a 250 miles de millones (250.000 millones) 0,048 USD por millón 9600,00 €
De 250.000 millones a 500.000 millones (500.000 millones) 0,036 USD por millón 9000,00 €
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 por lo que solo se aplica la primera. No se cobran muestras al otras 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$
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 un tiempo de funcionamiento más 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" para supervisar las comprobaciones de disponibilidad del servicio.

Los siguientes ejemplos muestran cómo estimar los costes de realizar comprobaciones de disponibilidad del servicio. Estos ejemplos pretenden ilustrar técnicas de cálculo y no facilitar datos de facturación.

Recuento de ejecuciones de comprobaciones de disponibilidad del servicio

Para estimar el coste de tus comprobaciones de disponibilidad del servicio, necesitas saber cuántas ejecuciones regionales se producen en un mes. Cargos de monitorización 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 lo 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 los siguientes factores: opciones de configuración:

  • La frecuencia con la que se ejecuta la comprobación de disponibilidad del servicio (cada minuto, 5 minutos, 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 el tiempo de funcionamiento comprobación está configurada para una sola VM, el número de destinos es 1. Si la comprobación de disponibilidad del servicio está configurada para un grupo de recursos, el número de objetivos es el número de recursos del grupo.

Al configurar una comprobación de disponibilidad del servicio, debes especificar una ubicación para la comprobación de disponibilidad del servicio, y cada ubicación se asigna a una o varias regiones. La en la tabla de abajo se muestran las ubicaciones válidas para las comprobaciones de disponibilidad del servicio y las regiones al que se asignan:

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, necesitas saber cuántas regiones cubre la ubicación de comprobación de disponibilidad del servicio:

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

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

  • Una comprobación de disponibilidad del servicio configurada para ejecutarse una vez por minuto en USA ejecuciones en 3 regiones. Si esta comprobación de disponibilidad del servicio está configurada para comprobar un solo esta comprobación de disponibilidad del servicio 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, se ejecuta la comprobación de disponibilidad del servicio 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 ejecutan en 5 regiones. Esta comprobación de disponibilidad del servicio se ejecuta 219.000 veces en un mes si para un solo destino.

En la siguiente tabla se muestran los recuentos de ejecuciones por horas y mensuales de una sola una comprobación de disponibilidad del servicio configurada para ejecutarse con diferentes frecuencias en diferentes 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, es decir, multiplica las ejecuciones restantes por 0,0003.

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

Situación 1: Tienes una comprobación de disponibilidad del servicio USA que comprueba una VM una vez por 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 comprobación de disponibilidad del servicio USA que comprueba un grupo de recursos de 10 miembros una vez por minuto. Esta comprobación se realiza dentro de 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 orientaciones.

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 €

Situación 3: Tienes 10 comprobaciones de disponibilidad del servicio de GLOBAL y cada uno de ellos comprueba una VM una vez por minuto. Estas comprobaciones se llevan a cabo en 6 regiones, por lo que cada comprobación se ejecuta 262.800 veces al mes. El total mensual ejecuciones es 2.628.000 (10 * 262.800). El coste de esta situación 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 €

Situación 4: Tienes 5 comprobaciones de disponibilidad del servicio en la ubicación USA que comprueban una VM una vez cada 5 minutos. Estas comprobaciones se llevan a cabo en 3 regiones, por lo que cada una check se ejecuta 26 280 veces al mes. El total de ejecuciones mensuales de este conjunto de comprobaciones es 105.120 (4 * 26.280).

También dispones de 2 comprobaciones de disponibilidad del servicio de GLOBAL que comprueban 1 VM una vez cada 15 minutos. Estas comprobaciones se ejecutan en 6 regiones, por lo que cada una se ejecuta 17.520 veces al mes. Las ejecuciones mensuales totales de esta conjunto de comprobaciones es 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)

Cloud Monitoring cobra por cada ejecución de un monitor sintético, más allá del 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 ejecutarlos cada 5 minutos, el número total de de ejecuciones al mes es 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, a continuación, 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 por cada 1000 ejecuciones)
26 784 26 684 32,02 USD

Precios de las alertas

A partir del 7 de enero del 2025, 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 describe cuándo un recurso o un grupo de recursos se encuentra 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. Al posponer o inhabilitar la política, no se evitar que se te cobre.

  • Políticas de alertas de métricas y basadas en registros: políticas de alertas que usan cualquier tipo de condición, excepto las condiciones de coincidencia con registro, que son alertas de métricas políticas; Las condiciones de las políticas de alertas de métricas devuelven series temporales. Durante cada periodo de ejecución, se ejecutan las condiciones de las políticas de alertas de métricas sus consultas en el almacén de datos de Cloud Monitoring. El objeto que se devuelve series temporales se comparan con un umbral para determinar si la cuando se active la política de alertas.

    Las políticas de alertas basadas en registros utilizan condiciones de coincidencia de registros. Condiciones de coincidencia del registro no devuelve ninguna serie temporal.

  • Periodo de ejecución: la frecuencia con la que Cloud Monitoring ejecuta la condición. En la mayoría de los tipos de condición, es de 30 segundos y no se puede ha cambiado. 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, se muestra una métrica que avisa ejecuta la consulta de su condición en Cloud Monitoring almacén de datos. Cloud Monitoring devuelve datos de series temporales como respuesta a cada consulta. Cada serie temporal de la respuesta se cuenta como una serie temporal. .

    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.

    Como tienes 100 máquinas virtuales, cada una puede generar 10 series temporales (una por valor de cada etiqueta), tendrás un total de 1000 series temporales subyacentes. Cada máquina virtual también contiene una etiqueta con metadatos que registra a cuáles de tus cinco servicios pertenece la VM.

    Puedes configurar tus políticas de alertas de las siguientes formas: PromQL, donde cada configuración genera un número diferente de series temporales devueltas 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 como resultado 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 <ph type="x-smartling-placeholder">
    </ph>
  • Una condición de alerta
  • La condición se agrega al nivel de VM
  • Periodo de ejecución de 30 segundos
. Costes resultantes <ph type="x-smartling-placeholder">
    </ph>
  • Coste de las condiciones: 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 que se devuelven 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), 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 <ph type="x-smartling-placeholder">
    </ph>
  • 100 condiciones
  • Cada condición se filtra y se agrega en una VM
  • Periodo de ejecución de 30 segundos
. Costes resultantes <ph type="x-smartling-placeholder">
    </ph>
  • 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 que se devuelven al mes * 0,35 USD por millón de series temporales = 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 <ph type="x-smartling-placeholder">
    </ph>
  • 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 <ph type="x-smartling-placeholder">
    </ph>
  • Coste de las condiciones: 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 que se devuelven 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 <ph type="x-smartling-placeholder">
    </ph>
  • Una condición
  • La condición se agrega al nivel de servicio
  • Periodo de ejecución de 30 segundos
. Costes resultantes <ph type="x-smartling-placeholder">
    </ph>
  • Coste de las condiciones: 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; más 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 <ph type="x-smartling-placeholder">
    </ph>
  • Una condición
  • La condición se agrega al nivel de VM
  • Periodo de ejecución de 30 segundos
. Costes resultantes <ph type="x-smartling-placeholder">
    </ph>
  • Coste de las condiciones: 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 que se devuelven al mes * 0,35 USD por 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 unión de 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 <ph type="x-smartling-placeholder">
    </ph>
  • 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 <ph type="x-smartling-placeholder">
    </ph>
  • Coste de las condiciones: 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 que se devuelven al mes * 0,35 USD por millón de series temporales = 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 <ph type="x-smartling-placeholder">
    </ph>
  • Coste de las condiciones: 100 condición * 1,50 USD al mes = 150,00 $ al mes
  • Coste de la serie temporal: 0 USD 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

Cuando configures políticas de alertas basadas en métricas, ten en cuenta lo siguiente: sugerencias para reducir el coste de las facturas de alertas.

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

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

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

Si agregamos los niveles más altos de granularidad, los costes serán más altos que y los datos se agregan a niveles inferiores de granularidad. Por ejemplo, agregar al nivel de proyecto de Google Cloud es más barato que agregar a nivel de clúster, y la agregación a nivel de clúster es más barata que la agregación a nivel de clúster y de espacio de nombres.

Por ejemplo, compara el Ejemplo 1 con el Ejemplo 4: Ambos ejemplos se ejecutan sobre los mismos datos subyacentes y tienen una única . Sin embargo, dado que la política de alertas del ejemplo 4 se suma a la más barato que la política de alertas del Ejemplo 1, que se agrega 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 la cardinalidad de la métrica en el ejemplo 1. Sin embargo, como la política de alertas de En el ejemplo 1 y en el ejemplo 5 se agregan datos a la VM y, dado que el número de máquinas virtuales es el mismo en ambos ejemplos; los ejemplos son equivalentes en precio.

Cuando configures tus políticas de alertas, elige niveles de agregación que se adapten mejor a tu caso práctico. Por ejemplo, si te interesa recibir alertas sobre la CPU uso, puede que quieras agregar al nivel de máquina virtual y de CPU. Si te interesa alertar sobre la latencia por punto final, entonces deberías agregar hasta el nivel de endpoint.

No crear alertas sobre datos sin procesar ni agregados

En la supervisión se utiliza un sistema de métricas dimensionales en el que todas las métricas tiene una cardinalidad total igual al número de recursos monitorizados multiplicado por el número de combinaciones de etiquetas de esa métrica. Para 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 de 100 × 10 × 10 = 10.000

Como consecuencia de la escala de la cardinalidad, las alertas sobre datos en bruto pueden ser extremadamente caro. En el ejemplo anterior, se devuelven 10.000 series temporales por cada periodo de ejecución. Sin embargo, si agregas datos a la VM, tienes que Solo se devuelven 100 series temporales por periodo de ejecución, independientemente de la etiqueta la cardinalidad de los datos subyacentes.

Crear alertas a partir de datos en bruto también te pone en riesgo de tener más series temporales cuando las métricas reciban nuevas etiquetas. En el ejemplo anterior, si un usuario añade otra etiqueta a la métrica, la cardinalidad total aumenta a 100 * 11 * 10 = 11.000 series temporales. En este caso, el número de serie temporal aumenta en 1000 cada periodo de ejecución,aunque tus alertas la política no se ha modificado. Si agregas los datos a la VM, entonces, a pesar de la aumenta la cardinalidad subyacente, solo tienes devueltas 100 series temporales.

Excluye las respuestas innecesarias

Configure las condiciones para evaluar solo los datos que sean necesarios para su alertas. Si no tomarías medidas para corregir algo, excluye en tus políticas de alertas. Por ejemplo, probablemente no tengas que avisar en la máquina virtual de desarrollo de un becario.

Para reducir las alertas y los costes innecesarios, puedes excluir series temporales que no son importantes. Puedes usar las etiquetas de metadatos de Google Cloud para etiquetar recursos con categorías y luego filtra 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 su condición utiliza una consulta de PromQL o MQL, puede utilizar un operador de flujos superiores para seleccionar varias series temporales devueltas con los valores más altos:

Por ejemplo, una cláusula topk(metric, 5) en los límites de una consulta de PromQL el número de series temporales que se han devuelto 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 Alertas defectuosas como:

  • Si más de N series temporales infringen tu umbral, no podrás Datos fuera de las N series temporales principales.
  • Si una serie temporal infractora se produce fuera de las N series temporales principales: los incidentes podrían cerrarse automáticamente a pesar de que la serie temporal excluida no cumplen el umbral.
  • Puede que tus consultas de condiciones no te muestren contexto importante, como el valor de referencia series temporales que funcionan correctamente.

Para mitigar esos riesgos, elige valores grandes para N y usa las emisiones principales únicamente en las políticas de alerta que evalúan muchas series temporales como, por ejemplo, para cada contenedor de Kubernetes.

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

Si la condición utiliza una consulta de PromQL, puede modificar la longitud del periodo de ejecución estableciendo el campo evaluationInterval del condition.

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 con el doble de frecuencia como una consulta con un intervalo de 30 segundos y una consulta con un intervalo de 1 minuto se ejecuta con la mitad de 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 el El 7 de enero del 2025, puedes retrasar la facturación para las alertas hasta que llegues al contrato debe renovarse solicitando una exención de Cloud Monitoring al equipo de facturación. Las exenciones para clientes con contratos activos se que se deben analizar caso por caso.

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

Error Reporting

Para obtener más información, consulta los precios actuales de Error Reporting.

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 información sobre cómo ver el uso actual o anterior, consulta Calcula 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, Cloud Functions 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 Intervalos de Cloud Trace ingeridos supera el límite definido por el usuario, utilice la siguiente configuración.

Campo Nueva condición
Valor
Recurso y métrica En el menú Recursos, selecciona Global.
En el menú Categorías de métricas, selecciona Facturación.
En el menú Métricas, selecciona 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. Registros del plano de control, métricas del plano de control y el subconjunto seleccionado de métricas de estado de Kube se encuentra habilitado de forma predeterminada para clústeres de GKE en Google Cloud que se Se registran al crear el clúster en un proyecto con GKE Enterprise habilitado. Los registros del plano de control incurren en cargos de Cloud Logging, mientras que 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 Qué registros se recopilan 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 la los costes por volumen de datos descritos en esta página, el uso de todos los servicios adicionales Las funciones del producto Google Cloud Observability 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 aprender a gestionar tus costes, consulta estos blogs publicaciones:

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

En la mayoría de los casos, los ámbitos de métricas no afectan a la facturación. Los registros y las métricas se cobran en el proyecto de Google Cloud que recibe los datos. El ámbito de las métricas de un proyecto define la colección de los proyectos cuyas métricas puede ver y monitorizar. Si defines un ámbito de métricas, no afectará al proyecto que recibe los datos de las métricas ni hará que se dupliquen.

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.

En el caso de monitorizar cuentas de AWS, debes conectar una de AWS a Google Cloud creando una Proyecto de conector de AWS. Ese tipo de proyecto alberga los registros y los datos de monitorización de la cuenta de AWS.

¿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 Calculadora de precios de Google Cloud y, a continuación, seleccionamos la pestaña "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 o de GKE Enterprise que: se miden hasta un punto de datos 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