En esta página se describe cómo puedes optimizar y monitorizar tus costes de Google Cloud Observability. Para obtener información sobre los precios, consulta los precios de Google Cloud Observability.
También te pueden interesar los siguientes documentos:
- Calcula tus facturas.
- Ejemplos de precios
- Optimiza los costes con Explorador de costes. Cost Explorer ofrece visualizaciones actuales e históricas de los datos de costes y las métricas de utilización. Por lo tanto, los datos le ayudan a identificar oportunidades de optimización.
Optimizar
En esta sección se explica cómo reducir u optimizar los costes asociados a Cloud Logging, Cloud Trace y Google Cloud Managed Service para Prometheus.
Reducir el almacenamiento de registros
Si quieres reducir los costes de almacenamiento de Cloud Logging, configura filtros de exclusión en los sumideros de registros para evitar que se enruten determinados registros. Los filtros de exclusión pueden quitar todas las entradas de registro que coincidan con el filtro o solo un porcentaje de los registros. Cuando una entrada de registro coincide con un filtro de exclusión de un sumidero, el sumidero no enruta la entrada de registro al destino. Las entradas de registro excluidas no se restan de la asignación de almacenamiento. Para obtener instrucciones sobre cómo configurar filtros de exclusión, consulta la sección sobre exclusiones de registros.
Otra opción para reducir los costes de almacenamiento de Cloud Logging es enrutar los registros fuera de Cloud Logging a un destino compatible. Cloud Logging no cobra por enrutar registros a destinos admitidos. Sin embargo, es posible que se te cobre cuando un destino reciba registros:
Para obtener información sobre cómo enrutar registros fuera de Cloud Logging, consulta el artículo Enrutar registros a destinos admitidos.
Optimizar los costes de Managed Service para Prometheus
Los precios de Managed Service para Prometheus están diseñados para poder controlarse. Como se aplica una tarifa por muestra, puedes usar los siguientes métodos para controlar los costes:
Periodo de muestreo: cambiar el periodo de extracción de métricas de 15 segundos a 60 segundos puede suponer un ahorro de costes del 75 %, sin sacrificar la cardinalidad. Puedes configurar los periodos de muestreo por tarea, por objetivo o en todo el mundo.
Filtrado: puedes usar el filtrado para reducir el número de muestras enviadas al almacén de datos global del servicio. Para obtener más información, consulta Filtrar métricas exportadas. Usa configuraciones de reetiquetado de métricas en tu configuración de extracción de Prometheus para reducir las métricas en el momento de la ingestión, en función de las opciones de coincidencia de las etiquetas.
Mantén los datos locales de alta cardinalidad y bajo valor. Puedes ejecutar Prometheus estándar junto con el servicio gestionado usando las mismas configuraciones y mantener los datos que no vale la pena enviar al almacén de datos mundial del servicio localmente.
Los precios de Managed Service para Prometheus están diseñados para ser predecibles.
No se te penalizará por tener histogramas dispersos. Las muestras solo se cuentan para el primer valor distinto de cero y cuando el valor del segmento n sea mayor que el valor del segmento n‐1. Por ejemplo, un histograma con valores
10 10 13 14 14 14cuenta como tres muestras: en el primer, tercer y cuarto segmento.Según la cantidad de histogramas que uses y la forma en que los uses, la exclusión de segmentos sin cambios en los precios suele generar un 20 % o un 40 % menos de muestras con fines de facturación que la cantidad absoluta que indicarían los segmentos de histograma.
Si cobras por muestra, no se te aplicará ninguna penalización por los contenedores de escalado rápido, sin escalar, interrumpibles o efímeros, como los creados por HPA o Autopilot de GKE.
Si Managed Service for Prometheus se facturara según cada métrica, pagarías una cardinalidad de un mes completo cada vez que se añadiera un nuevo contenedor. Con los precios por muestra, pagas solo cuando el contenedor se está ejecutando.
Consultas, incluidas las consultas de alerta
Todas las consultas realizadas por el usuario, incluidas las que se hacen cuando se ejecutan reglas de grabación de Prometheus, se cobran a través de las llamadas a la API de Cloud Monitoring. Para consultar la tarifa actual, ve a las secciones de Cloud Monitoring de la página Precios de Google Cloud Observability.
Reducir el uso de Trace
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.
Reducir la factura de las alertas
A partir del 1 de mayo del 2026, como muy pronto, Cloud Monitoring empezará a cobrar por el uso de políticas de alertas. Para obtener información sobre el modelo de precios, consulta el resumen de precios de Cloud Monitoring.En este documento se describen las estrategias que puede usar para reducir los costes de las alertas.
Consolidar políticas de alertas para que funcionen en más recursos
Debido al coste de 0,10 USD por condición, resulta más rentable usar una política de alertas para monitorizar varios recursos que usar una política de alertas para monitorizar cada recurso. Ten en cuenta los siguientes ejemplos:
Ejemplo 1
Datos
- 100 VM
- Cada VM emite una métrica,
metric_name. metric_nametiene una etiqueta con 10 valores
- Una condición de alerta
- Agrega las condiciones a nivel de máquina virtual
- Periodo de ejecución de 30 segundos
- Coste de la condición: 1 condición * 0,10 USD al mes = 0,10 USD al mes
- Coste de las series temporales: 100 series temporales devueltas por periodo * 86.400 periodos al mes = 8,6 millones de series temporales devueltas al mes * 0,35 USD por millón de series temporales = 3,02 USD al mes
- Coste total: 3,12 USD al mes
Ejemplo 2
Datos
- 100 VM
- Cada VM emite una métrica,
metric_name. metric_nametiene una etiqueta con 10 valores
- 100 condiciones
- Cada condición se filtra y se agrega en una VM
- Periodo de ejecución de 30 segundos
- Coste de las condiciones: 100 condiciones * 0,10 USD al mes = 10 USD al mes
- Coste de las series temporales: 100 condiciones * 1 serie temporal devuelta por condición y periodo * 86.400 periodos al mes = 8,6 millones de series temporales devueltas al mes * 0,35 USD por millón de series temporales = 3,02 USD al mes
- Coste total: 13,02 USD al mes
En ambos ejemplos, se monitoriza el mismo número de recursos. Sin embargo, el ejemplo 2 usa 100 políticas de alertas, mientras que el ejemplo 1 solo usa una. Por lo tanto, el ejemplo 1 es casi 10 USD más barato al mes.
Agrega solo el nivel en el que necesites recibir alertas
La agregación a niveles de granularidad más altos conlleva costes superiores a la agregación a niveles de granularidad más bajos. Por ejemplo, agregar datos a nivel de proyecto es más barato que hacerlo a nivel de clúster, y agregar datos a nivel de clúster es más barato que hacerlo a nivel de clúster y de espacio de nombres. Google Cloud
Ten en cuenta los siguientes ejemplos:
Ejemplo 1
Datos
- 100 VM
- Cada VM emite una métrica,
metric_name. metric_nametiene una etiqueta con 10 valores
- Una condición de alerta
- Agrega las condiciones a nivel de máquina virtual
- Periodo de ejecución de 30 segundos
- Coste de la condición: 1 condición * 0,10 USD al mes = 0,10 USD al mes
- Coste de las series temporales: 100 series temporales devueltas por periodo * 86.400 periodos al mes = 8,6 millones de series temporales devueltas al mes * 0,35 USD por millón de series temporales = 3,02 USD al mes
- Coste total: 3,12 USD al mes
Ejemplo 4
Datos
- 100 máquinas virtuales, donde cada una pertenece a un servicio
- Cinco servicios en total
- Cada VM emite una métrica,
metric_name. metric_nametiene una etiqueta con 10 valores
- Una condición
- Agrega las condiciones al nivel de servicio
- Periodo de ejecución de 30 segundos
- Coste de la condición: 1 condición * 0,10 USD al mes = 0,10 USD al mes
- Coste de las series temporales: 5 series temporales devueltas por periodo * 86.400 periodos al mes = 432.000 series temporales devueltas al mes * 0,35 USD por millón de series temporales = 0,14 USD al mes
- Coste total: 0,24 USD al mes
Ejemplo 5
Datos
- 100 VM
- Cada VM emite una métrica,
metric_name. metric_nametiene 100 etiquetas con 1000 valores cada una
- Una condición
- Agrega las condiciones a nivel de máquina virtual
- Periodo de ejecución de 30 segundos
- Coste de la condición: 1 condición * 0,10 USD al mes = 0,10 USD al mes
- Coste de las series temporales: 100 series temporales devueltas por periodo * 86.400 periodos al mes = 8,5 millones de series temporales devueltas al mes * 0,35 USD por millón de series temporales = 3,02 USD al mes
- Coste total: 3,12 USD al mes
Compara el ejemplo 1 con el ejemplo 4: ambos ejemplos operan con los mismos datos subyacentes y tienen una sola política de alertas. Sin embargo, como la política de alertas del ejemplo 4 se agrega al servicio, es menos costosa que la política de alertas del ejemplo 1, que se agrega de forma más granular a la máquina virtual.
Además, compare el ejemplo 1 con el ejemplo 5: en este caso, la cardinalidad de la métrica del ejemplo 5 es 10.000 veces superior a la del ejemplo 1. Sin embargo, como la política de alertas del ejemplo 1 y del ejemplo 5 se agregan a la VM, y como el número de VMs es el mismo 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 práctico. Por ejemplo, si te interesa recibir alertas sobre la utilización de la CPU, puedes agregar datos a nivel de máquina virtual y de CPU. Si te interesa recibir alertas sobre la latencia por endpoint, puedes agregar datos a nivel de endpoint.
No crees alertas a partir de datos sin procesar ni agregar
Monitoring usa un sistema de métricas dimensionales, en el que cualquier métrica tiene una cardinalidad total igual al número de recursos monitorizados multiplicado por el número de combinaciones de etiquetas de esa métrica. Por ejemplo, si tiene 100 máquinas virtuales que emiten una métrica y esa métrica tiene 10 etiquetas con 10 valores cada una, la cardinalidad total es 100 × 10 × 10 = 10.000.
Debido a la forma en que se escala la cardinalidad, las alertas sobre datos sin procesar pueden ser extremadamente caras. En el ejemplo anterior, se devuelven 10.000 series temporales por cada periodo de ejecución. Sin embargo, si agregas datos a la máquina virtual, solo se devolverán 100 series temporales por periodo de ejecución, independientemente de la cardinalidad de las etiquetas de los datos subyacentes.
Si creas alertas basadas en datos sin procesar, también corres el riesgo de que aumente el número de series temporales cuando tus métricas reciban nuevas etiquetas. En el ejemplo anterior, si un usuario añade una etiqueta nueva a tu métrica, la cardinalidad total aumentará a 100 * 11 * 10 = 11.000 series temporales. En este caso, el número de series temporales devueltas aumenta en 1000 en cada periodo de ejecución,aunque la política de alertas no cambie. Si, por el contrario, agregas los datos a la VM, aunque aumente la cardinalidad subyacente, solo se devolverán 100 series temporales.
Filtrar las respuestas innecesarias
Configura las condiciones para evaluar solo los datos que sean necesarios para tus alertas. Si no vas a tomar medidas para corregir algo, exclúyelo de tus políticas de alertas. Por ejemplo, probablemente no necesites enviar alertas sobre la VM de desarrollo de un becario.
Para reducir los incidentes y los costes innecesarios, puede filtrar las series temporales que no sean importantes. Puedes usar etiquetas de metadatos para etiquetar recursos con categorías y, a continuación, filtrar las categorías de metadatos que no necesites. Google Cloud
Usar operadores de flujo superior para reducir el número de series temporales devueltas
Si tu condición usa una consulta de PromQL, puedes usar un operador de los flujos principales para seleccionar un número de las series temporales devueltas con los valores más altos:
- PromQL:
topk
Por ejemplo, una cláusula topk(metric, 5) en una consulta de PromQL limita el número de series temporales devueltas a cinco en cada periodo de ejecución.
Si limitas el número de series temporales, es posible que falten datos y que se produzcan incidentes erróneos, como los siguientes:
- Si más de N series temporales superan el umbral, no se mostrarán los datos que no estén entre las N series temporales principales.
- Si una serie temporal infractora se produce fuera de las N series temporales principales, es posible que los incidentes se cierren automáticamente aunque la serie temporal excluida siga infringiendo el umbral.
- Es posible que tus consultas de condición no te muestren contexto importante, como series temporales de referencia que funcionan correctamente.
Para mitigar estos riesgos, elige valores grandes para N y usa el operador top-streams solo en políticas de alertas que evalúen muchas series temporales, como incidentes de contenedores de Kubernetes individuales.
Aumentar la duración del periodo de ejecución (solo PromQL)
Si tu condición usa una consulta PromQL, puedes modificar la duración del periodo de ejecución configurando el campo evaluationInterval en la condición.
Los intervalos de evaluación más largos dan como resultado menos series temporales devueltas al mes. Por ejemplo, una consulta de condición con un intervalo de 15 segundos se ejecuta el doble de veces que una consulta con un intervalo de 30 segundos, y una consulta con un intervalo de 1 minuto se ejecuta la mitad de veces que una consulta con un intervalo de 30 segundos.
Monitorizar
En esta sección se describe cómo monitorizar los costes creando políticas de alertas. Una política de alertas puede monitorizar datos de métricas y enviarte una notificación cuando esos datos superen un umbral.
Monitorizar los bytes de registro ingeridos al mes
Para crear una política de alertas que se active si el número de bytes de registro escritos en tus cubos de registro supera el límite que has definido en Cloud Logging, sigue los pasos que se indican más abajo:
| Campo Nueva condición |
Valor |
|---|---|
| Recurso y métrica | En el menú Recursos, selecciona Global. En el menú Categorías de métricas, selecciona Métrica basada en registros. En el menú Métricas, selecciona Bytes de registro mensuales ingeridos. |
| Filtro | Ninguno |
| Entre series temporales Agregación de series temporales |
sum |
| Ventana de tiempo | 60 m |
| Función de ventana móvil | max |
| Configurar el activador de alertas Campo |
Valor |
|---|---|
| Tipo de condición | Threshold |
| Activador de alerta | Any time series violates |
| Posición del umbral | Above threshold |
| Valor de umbral | Tú eliges el valor aceptable. |
| Ventana de repetición de la prueba | El valor mínimo aceptable es 30 minutos. |
Monitorizar el total de 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, consulta Configurar una alerta de facturación.
Monitorizar los intervalos de trazas ingeridos al mes
Para crear una política de alertas que se active cuando la métrica de intervalos de Cloud Trace ingeridos al mes supere el límite que has definido, sigue los pasos que se indican más abajo.
| Campo Nueva condición |
Valor |
|---|---|
| Recurso y métrica | En el menú Recursos, selecciona Global. En el menú Categorías de métricas, selecciona Facturación. En el menú Métricas, selecciona Intervalos de traza ingeridos al mes. |
| Filtro | |
| Entre series temporales Agregación de series temporales |
sum |
| Ventana de tiempo | 60 m |
| Función de ventana móvil | max |
| Configurar el activador de alertas Campo |
Valor |
|---|---|
| Tipo de condición | Threshold |
| Activador de alerta | Any time series violates |
| Posición del umbral | Above threshold |
Threshold value |
Tú eliges el valor aceptable. |
| Ventana de repetición de la prueba | El valor mínimo aceptable es 30 minutos. |
Configurar una alerta de facturación
Si quieres recibir una notificación cuando tus cargos previstos o facturables superen un presupuesto concreto, puedes crear una alerta en la página Presupuestos y alertas de la Google Cloud consola:
-
En la Google Cloud consola, ve a la página Facturación:
También puedes encontrar esta página mediante la barra de búsqueda.
Si tienes más de una cuenta de facturación de Cloud, sigue uno de estos pasos:
- Para gestionar la facturación de Cloud del proyecto seleccionado, elige Ir a la cuenta de facturación vinculada.
- Si quieres acceder a otra cuenta de facturación de Cloud, haz clic en Gestionar cuentas de facturación y elige la cuenta cuyo presupuesto quieras configurar.
- En el menú de navegación Facturación, selecciona Presupuestos y alertas.
- Haz clic en Crear presupuesto.
- Completa el cuadro de diálogo del presupuesto. En este cuadro de diálogo, tienes que seleccionar la combinación de Google Cloud proyectos y productos 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.