Precios de Google Cloud Observability

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

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

Resumen de precios de Cloud Logging

Resumen de precios de Cloud Monitoring

Resumen de precios de Cloud Trace

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

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

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

Visualiza tu uso

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

Ir a Facturación de Cloud

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

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

Configura una alerta de facturación

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

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

   Ir a Facturación

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

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

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

Cloud Logging

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

En el caso del bucket de registros _Default y en el de los buckets de registros definidos por el usuario, Logging también cobra cuando se conservan los registros por un período superior al período de retención predeterminado, que es de 30 días.

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

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

• Modelo de almacenamiento de Cloud Logging
• Precios de almacenamiento
• Precios de retención
• Registros de red enviados
• Reduce el almacenamiento de tus registros
• Precios de las métricas basadas en registros
• Crear una política de alertas sobre los bytes de registros transferidos mensualmente

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

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

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

Modelo de almacenamiento de Cloud Logging

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

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

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

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

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

Precios de almacenamiento

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

• Registros de auditoría de actividad del administrador
• Registros de auditoría de eventos del sistema
• Registros de auditoría del administrador de Google Workspace
• Registros de auditoría de los grupos empresariales
• Registros de auditoría de acceso
• Registros de Transparencia de acceso. Para obtener información sobre cómo habilitar los registros de Transparencia de acceso, consulta la documentación de los registros de Transparencia de acceso.

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

Precios de retención

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

Logging cobra costos de retención cuando los registros se conservan por más tiempo que el período de retención predeterminado. No puedes configurar el período de retención para el bucket de registros _Required. No hay costos de retención cuando los registros se almacenan solo por el período de retención predeterminado del bucket de registros.

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

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

Registros de red vendidos

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

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

Para encontrar tus registros de red vendidos, en el Explorador de registros filtra 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 tus registros

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

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

• Precios de Cloud Storage
• Precios de BigQuery
• Precios de Pub/Sub

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

Precios de las métricas basadas en registros

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

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

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

Crear una política de alertas sobre los bytes de registros transferidos mensualmente

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

Cloud Monitoring

Monitoring cobra lo siguiente:

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

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

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

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

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

• La ejecución de verificaciones de tiempo de actividad

• Ejecución de monitores sintéticos.

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

• Series temporales que muestra la consulta de una condición de política de alertas.

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

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

• Definiciones de las métricas cobrables y no cobrables.
• Descripciones de las estrategias de transferencia basadas en bytes y de muestra
• Ejemplos de precios para métricas cobradas por bytes transferidos.
• Ejemplos de precios para métricas cobradas por muestras transferidas.
• Ejemplos de precios para la ejecución de verificaciones de tiempo de actividad (fecha de entrada en vigencia: 1 de octubre de 2022).
• Ejemplos de precios para la ejecución de monitores sintéticos (fecha de entrada en vigencia: 1 de noviembre de 2023).
• Descripciones y ejemplos de precios por alertas (fecha de entrada en vigencia: abril de 2025).

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

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

Para consultar tu uso actual, realiza una de las siguientes acciones:

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

  Ir a Facturación

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

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

  Ir a Configuración

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

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

Métricas no cobrables

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

• Métricas de Google Cloud. Para obtener información adicional, consulta la nota 2 al pie de página
• Métricas de GKE Enterprise. Para obtener información adicional, consulta la nota 2 al pie de página
• Métricas de Istio
• Métricas de Knative
• Métricas del sistema de Google Kubernetes Engine
• Métricas de agent.googleapis.com/agent/

Métricas cobrables

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

Los siguientes factores contribuyen a los costos de transferencia:

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

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

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

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

Métricas que cobran los bytes transferidos

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

• Métricas del agente en agent.googleapis.com, excepto el grupo agent.googleapis.com/agent/

  A partir del 6 de agosto de 2021, las métricas agent.googleapis.com/processes/ se cobrarán al 5% de la tarifa por volumen de otras métricas cobrables. Por ejemplo, transferir 100 MiB de métricas de procesos costará lo mismo que transferir 5 MiB de otras métricas cobrables.³

• Métricas de integraciones en terceros con el agente de operaciones. Estas métricas se transfieren a Cloud Monitoring con identificadores con el formato workload.googleapis.com/APPLICATION.METRIC; por ejemplo, el tipo de métrica workload.googleapis.com/nginx.requests entra en esta categoría.

• Las métricas del protocolo OpenTelemetry (OTLP) transferidas a Cloud Monitoring como métricas workload.googleapis.com por parte del Agente de operaciones. Esta es una opción de configuración. Si deseas obtener más información, consulta Formatos de transferencia para métricas de OTLP.

• Métricas personalizadas, incluidas, sin limitaciones, las métricas enviadas mediante la API de Cloud Monitoring o las bibliotecas cliente de lenguaje específico, OpenCensus y OpenTelemetry.

• Métricas externas

• Métricas basadas en registros definidas por el usuario

Para determinar los precios, el volumen de transferencia 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 contadores definidas por el usuario y basadas en registros entran en esta categoría.
• Para un tipo de datos de distribución: 80 bytes por cada dato escrito en una serie temporal.

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

Métricas que cobran las muestras transferidas

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

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

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

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

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

Alerta de métricas transferidas

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

Ejemplos de precios basados en bytes transferidos

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

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

Las variables entre los escenarios incluyen:

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

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

Trasfondo común

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

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

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

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

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

Ejemplos

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

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

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

• Transferencia mensual: 25,063 MiB (igual que la anterior)
• Costo aproximado por mes: $6,427.55

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

• Transferencia mensual: 418 MiB = 0.005569458 MiB para una métrica × 75,000
• Costo aproximado por mes: $69.14

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

• Transferencia mensual: 167,084 MiB: 0.33416748 MiB para una métrica × 500,000
• Costo aproximado por mes: $35,890.98

Precios para la capacidad de control y previsibilidad

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

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

• Filtrado: puedes usar filtros para reducir la cantidad de muestras enviadas al almacén de datos local del servicio. Para obtener más información, consulta Filtra métricas exportadas. Usa la configuración de reetiquetado de métricas en la configuración de recopilación de Prometheus para descartar métricas en el momento de la transferencia, en función de los comparadores de etiquetas.

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

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

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

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

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

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

Búsquedas, incluidas las consultas de alertas

Todas las consultas emitidas por el usuario, incluidas las consultas emitidas cuando se ejecutan las reglas de registro de Prometheus, se cobran a través de las llamadas a la API de Cloud Monitoring. Si deseas conocer la tarifa actual, consulta la tabla de resumen de los precios del servicio administrado para Prometheus o los precios de Monitoring.

Ejemplos de precios basados en muestras transferidas

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

El objetivo de estos ejemplos es ilustrar técnicas de cálculo, no para proporcionar datos de facturación.

La situación básica es la siguiente: tienes una cantidad de contenedores o pods que escriben puntos en un número determinado de series temporales cada mes. Los datos pueden consistir en valores escalares o distribuciones.

Las variables entre los escenarios incluyen:

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

Contar muestras

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

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

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

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

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

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

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

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

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

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

En los siguientes cálculos y en la tabla de resumen, se indica la cantidad máxima de muestras y la cantidad esperada de muestras más realistas:

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

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

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

  • Tasa de escritura: 1 valor/60 s
  • Cantidad máxima de muestras:
    • Por histograma: 52
    • Por mes: 2,277,600 (52 * 1 valor/60 s * 2,628,000 segundos/mes)
  • Muestras esperadas, suponiendo que hay un 25% vacío:
    • Por histograma: 39.5 (2 + 0 .75(50), o 2 + (50 - 12.5))
    • Por mes: 1,730,100 (39.5 * 1 valor/60 s * 2,628,000 segundos por mes)
  • Muestras esperadas, suponiendo que hay un 40% vacío:
    • Por histograma: 32 (2 + 0 .6(50) o 2 + (50 - 20))
    • Por mes: 1,401,600 (32 * 1 valor/60 s * 2,628,000 segundos por mes)

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

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

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

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

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

Ejemplos

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Los primeros 50,000 millones de muestras se cobran a la primera tarifa.
• Los siguientes 200,000 millones de muestras se cobran con la segunda tarifa.
• Los 87,260 millones restantes de muestras se cobran en función de la tercera tarifa.

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

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

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

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

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

Situación 5: Tienes lo siguiente:

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

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

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

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

Precio de la ejecución de la verificación de tiempo de actividad (fecha de entrada en vigencia: 1 de octubre de 2022)

La supervisión cobra por cada ejecución regional de una verificación de tiempo de actividad, más allá de la asignación mensual gratuita de 1 millón de ejecuciones. Una verificación que se ejecuta en tres regiones cuenta como tres ejecuciones.

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

En los siguientes ejemplos, se muestra cómo estimar los costos de la ejecución de las verificaciones de tiempo de actividad. El objetivo de estos ejemplos es ilustrar técnicas de cálculo, no para proporcionar datos de facturación.

Contar las ejecuciones de verificaciones de tiempo de actividad

Para estimar el costo de tus verificaciones de tiempo de actividad, debes saber cuántas ejecuciones regionales ocurren en un mes. Monitoring cobra $0.30 por cada 1,000 ejecuciones, con una asignación mensual gratuita de 1 millón de ejecuciones.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ejemplos

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

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

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

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

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

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

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

Tus ejecuciones mensuales totales es de 140,160 (105,120 + 35,040). Esta situación no tiene ningún costo.

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

Cloud Monitoring cobra por cada ejecución de un monitor sintético, más allá de la asignación gratuita por mes de 100 ejecuciones por cuenta de facturación. Por ejemplo, si creas 3 supervisores sintéticos y configuras cada uno para que se ejecuten cada 5 minutos, la cantidad total de ejecuciones por mes es 26,784:

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

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

Precios de las alertas

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

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

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

• Definiciones de la terminología de alertas.
• Ejemplos de cargos por diversas configuraciones de políticas de alertas
• Sugerencias para reducir costos mediante la consolidación o la eliminación de políticas de alertas.
• Información sobre cómo inhabilitar la facturación para las políticas de alertas.

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.

  • Las políticas de alertas que usan filtros para crear consultas de umbral de métrica o ausencia de métricas pueden combinar hasta seis condiciones.
  • Las políticas de alertas con los siguientes tipos de consultas pueden tener solo una condición:
    • Consulta de Prometheus Query Language (PromQL),
    • Lenguaje de consulta de Monitoring (MQL)
    • Coincidencia de registros, que se usa en las alertas basadas en registros.

  El cargo corresponde a USD 1.50 por mes por cada condición. Para que no se te cobre por una condición, debes borrar la política de alertas. Posponer o inhabilitar la política no impedirá que se te cobre.

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

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

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

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

  Tres factores determinan la cantidad de series temporales que se muestran en un mes:

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

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

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

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

  Puedes configurar las políticas de alertas de las siguientes maneras con PromQL, en el que cada configuración da como resultado una cantidad diferente de series temporales que se muestran por período de ejecución:

  Configuración	Consulta de PromQL	Series temporales que se muestran por período
  Sin agregación	rate(metric_name[1m])	1,000
  Agregación 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
  Agregación al servicio	sum by (service) (rate(metric_name[1m]))	5
  Agregar al valor y servicio de la etiqueta	sum by (service, label_key) (rate(metric_name[1m])	50
  Agregar a la flota	sum (rate(metric_name[1m]))	1
  Filtra y agrega a una VM	sum (rate(metric_name{vm="my_vm_name"}[1m]))	1
  Filtrar y agregar a un servicio	sum (rate(metric_name{service="my_service_name"}[1m]))	1

Ejemplos de precios

Los siguientes ejemplos ocurren en un mes de 30 días, lo que genera los siguientes períodos de evaluación:

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

Ejemplo 1: Una política, agregación a la VM, 30 segundos

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

Datos

• 100 VM
• Cada VM emite una métrica, metric_name
• metric_name tiene una etiqueta, que tiene 10 valores

• Una condición de alerta
• La condición se agrega al nivel de la VM
• Período de ejecución de 30 segundos

• Costo de la condición: 1 condición × $1.50 por mes = $1.50 por mes
• Costo de series temporales: 100 series temporales mostradas por período × 86,400 períodos por mes = 8.6 millones de series temporales mostradas por mes × $0.35 por millón de series temporales = $3.02 por mes
• Costo total: USD 4.52 por mes

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

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

Datos

• 100 VM
• Cada VM emite una métrica, metric_name
• metric_name tiene una etiqueta, que tiene 10 valores

• 100 condiciones
• Cada condición se filtra y se agrega a una VM
• Período de ejecución de 30 segundos

• Costo de la condición: 100 condiciones × $1.50 por mes = $150 por mes
• Costo de serie temporal: 100 condiciones × 1 serie temporal mostrada por condición por período × 86,400 períodos por mes = 8.6 millones de series temporales mostradas por mes × $0.35 por millón de series temporales = $3.02 por mes
• Costo total: USD 153.02 por mes

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

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

Datos

• 100 VM
• Cada VM emite una métrica, metric_name
• metric_name tiene una etiqueta, que tiene 10 valores

• Una condición de alerta de PromQL
• La condición se agrega al nivel de la VM
• Período de ejecución de 15 segundos

• Costo de la condición: 1 condición × $1.50 por mes = $1.50 por mes
• Costo de series temporales: 100 series temporales mostradas por período × 172,800 períodos por mes = 17.3 millones de series temporales mostradas por mes × $0.35 por millón de series temporales = $6.05 por mes
• Costo total: USD 7.55 por mes

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

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

Datos

• 100 VMs (cada VM pertenece a un servicio)
• Cinco servicios en total
• Cada VM emite una métrica, metric_name
• metric_name tiene una etiqueta, que tiene 10 valores

• Una condición
• La condición se agrega al nivel de servicio
• Período de ejecución de 30 segundos

• Costo de la condición: 1 condición × $1.50 por mes = $1.50 por mes
• Costo de series temporales: 5 series temporales mostradas por período × 86,400 períodos por mes = 432,000 series temporales mostradas por mes × $0.35 por millón de series temporales = $0.14 por mes
• Costo total: USD 1.64 por mes

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

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

Datos

• 100 VM
• Cada VM emite una métrica, metric_name
• metric_name tiene 100 etiquetas con 1,000 valores cada una

• Una condición
• La condición se agrega al nivel de la VM
• Período de ejecución de 30 segundos

• Costo de la condición: 1 condición × $1.50 por mes = $1.50 por mes
• Costo de series temporales: 100 series temporales mostradas por período × 86,400 períodos por mes = 8.5 millones de series temporales mostradas por mes × $0.35 por millón de series temporales = $3.02 por mes
• Costo total: USD 4.52 por mes

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

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

Datos

• 100 VM
• Cada VM emite dos métricas, metric_name_1 y metric_name_2.
• Ambas métricas tienen una etiqueta con 10 valores cada una

• Una condición
• La condición se agrega al nivel de la VM
• La condición usa un operador OR para unir las métricas
• Período de ejecución de 30 segundos

• Costo de la condición: 1 condición × $1.50 por mes = $1.50 por mes
• Costo de series temporales: 2 métricas × 100 series temporales mostradas por métrica por período × 86,400 períodos por mes = 17.3 millones de series temporales mostradas por mes × $0.35 por millón de series temporales = $6.05 por mes
• Costo total: USD 7.55 por mes

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

En este ejemplo, usa la siguiente configuración:

Políticas de alertas

• 100 condiciones (una por cada política de alertas basada en registros)

• Costo de la condición: 100 condición × $1.50 por mes = $150.00 por mes
• Costo de la serie temporal: $0 (las políticas de alertas basadas en registros no muestran series temporales).
• Costo total: USD 150.00 por mes

Sugerencias para reducir la factura de alertas

Consolidar políticas de alertas para operar sobre más recursos

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

Agrega solo el nivel sobre el que necesitas generar alertas.

La agregación a niveles de detalle más altos da como resultado costos más altos que la agregación a niveles más bajos. Por ejemplo, la agregación a nivel de proyecto de Google Cloud es más económica que la de clúster, y la a nivel de clúster es más económica que la agregación a nivel de clúster y espacio de nombres.

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

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

Cuando configures tus políticas de alertas, elige los niveles de agregación que mejor se adapten a tu caso de uso. Por ejemplo, si te interesan las alertas sobre el uso de CPU, te recomendamos agregar la VM y el nivel de CPU. Si te interesa generar alertas sobre latencia por extremo, se recomienda agregar datos a nivel del extremo.

No generar alertas sobre datos sin procesar ni agregados

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

Como resultado de cómo escala la cardinalidad, crear alertas sobre datos sin procesar puede ser muy costosa. En el ejemplo anterior, se muestran 10,000 series temporales para cada período de ejecución. Sin embargo, si agregas a la VM, solo se muestran 100 series temporales por período de ejecución, sin importar la cardinalidad de las etiquetas de los datos subyacentes.

Alertar sobre datos sin procesar también te pone en riesgo de mayores series temporales cuando tus métricas reciben etiquetas nuevas. En el ejemplo anterior, si un usuario agrega una etiqueta nueva a tu métrica, tu cardinalidad total aumenta a 100 * 11 * 10 = 11,000 series temporales. En este caso, la cantidad de series temporales que se muestran aumenta en 1,000 por cada período de ejecución, a pesar de que la política de alertas no se modificó. En cambio, si agregas a la VM, entonces, a pesar del aumento de la cardinalidad subyacente, solo tienes que mostrar 100 series temporales.

Filtra las respuestas innecesarias

Configura las condiciones a fin de evaluar solo los datos necesarios para tus necesidades de alerta. Si no tomarías medidas para corregir algo, exclúyelo de tus políticas de alertas. P. ej., probablemente no necesites alertar sobre la VM de desarrollo de un pasante.

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

Usa operadores de transmisión principal para reducir la cantidad de series temporales que se devuelven

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

• PromQL: topk
• MQL: top

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

Limitar a una cantidad superior de series temporales puede generar datos faltantes y alertas erróneas, como las siguientes:

• Si más de N series temporales infringen tu umbral, perderás los datos fuera de las N series temporales principales.
• Si una serie temporal con incumplimientos ocurre fuera de la serie temporal N superior, los incidentes podrían cerrarse de forma automática a pesar de que la serie temporal excluida aún incumpla el umbral.
• Es posible que las consultas de condición no muestren el contexto importante, como las series temporales de referencia que funcionan según lo previsto.

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

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

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

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

Rechazando

Si tienes un contrato existente de Google Cloud que no vence hasta abril de 2025, puedes retrasar la facturación de alertas hasta que venza el contrato. Para ello, solicita una exención al equipo de facturación de alertas de Cloud Monitoring. Las exenciones para los clientes con contratos activos se analizarán según cada caso.

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

Error Reporting

Los datos de errores se pueden informar en el proyecto de Google Cloud mediante la API de Error Reporting o la API de Cloud Logging.

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

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

Cloud Profiler

El uso de Cloud Profiler no tiene ningún costo asociado.

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

Cloud Trace

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

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

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

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

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

Intervalos de seguimiento no cobrables

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

Intervalos de seguimiento cobrables

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

Ejemplos de precios

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

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

Reduce el uso de seguimientos

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

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

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

Alerta de las transferencias de intervalos mensuales

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

GKE Enterprise

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

Para obtener 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, los registros y las métricas del sistema de GKE Enterprise incluyen lo siguiente:

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

Preguntas frecuentes

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

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

¿Cuánto tendré que pagar?

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

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

¿Cómo entiendo los detalles del uso?

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

Si te interesa aprender a administrar tus costos, consulta estas entradas de blog:

• Precios de Cloud Logging para administradores de Cloud: cómo abordarlo y ahorrar costos
• Cuatro pasos para administrar tus costos de Cloud Logging según un presupuesto

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

En su mayoría, los permisos de métricas y los permisos de registros no afectan la facturación. Los registros y las métricas se cobran por el proyecto, la cuenta de facturación, la organización o la carpeta que recibe los datos. El permiso de métricas de un proyecto define la recopilación de los recursos cuyas métricas el proyecto puede ver y supervisar. Cuando defines un permiso de métricas, no influyes en qué recurso recibe datos de métricas ni se duplican los datos. De forma similar, un permiso de registro solo enumera los recursos que almacenan o enrutan las entradas de registro que quieres ver.

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

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

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

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

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

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

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

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

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

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

¹ Para determinar los precios, todas las unidades se tratan como medidas binarias, por ejemplo, como mebibytes (MiB, o 2²⁰ bytes) gibibytes (GiB o 2³⁰ bytes).

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

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

¿Qué sigue?

• Lee la documentación de Google Cloud Observability.
• Prueba la calculadora de precios.
• Obtén más información sobre las soluciones y casos de uso de observabilidad de Google Cloud.