En esta página, se describe cómo puedes optimizar y supervisar tus costos 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 costos con el Explorador de costos. El Explorador de costos proporciona visualizaciones actuales e históricas de los datos de costos y las métricas de utilización. Por lo tanto, los datos te ayudan a identificar oportunidades de optimización.
Optimizar
En esta sección, se proporciona orientación para reducir u optimizar los costos asociados con Cloud Logging, Cloud Trace y Google Cloud Managed Service para Prometheus.
Reduce el almacenamiento de registros
Para reducir los costos de almacenamiento de Cloud Logging, configura filtros de exclusión en tus receptores de registros para evitar que se enruten ciertos 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 receptor, este no la enruta al destino. Las entradas de registro excluidas no se consideran en tu asignación de almacenamiento. Si deseas obtener instrucciones para 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 compatible. Cloud Logging no cobra por enrutar registros a destinos compatibles. Sin embargo, es posible que se te cobre cuando un destino reciba registros:
Para obtener información sobre el enrutamiento de registros fuera de Cloud Logging, consulta Enruta registros a destinos compatibles.
Optimiza los costos del servicio administrado para Prometheus
Los precios del servicio administrado para Prometheus están diseñados para ser controlables. 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 global del servicio. Si deseas obtener más información, consulta Filtra métricas exportadas. Usa los archivos de configuración de etiquetado de métricas en tu configuración de recopilación de Prometheus para descartar las métricas al momento de la transferencia, en función de los comparadores de etiquetas.
Mantén la cardinalidad alta y los datos locales de bajo valor. Puedes ejecutar Prometheus estándar junto con el servicio administrado, usar la misma configuración de scape y conservar los datos locales que no vale la pena enviar al almacén de datos global del servicio.
Los precios del servicio administrado para Prometheus están diseñados para ser previsibles.
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 14cuenta 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 cobrara por métrica, tendrías que pagar por la cardinalidad de un mes completo, todo a la vez, cada vez que se iniciara 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 que emite el usuario, incluidas las que se emiten cuando se ejecutan las reglas de grabación de Prometheus, se cobran a través de las llamadas a la API de Cloud Monitoring. Para conocer la tarifa actual, consulta la tabla de resumen de los precios de Managed Service para Prometheus o los precios de Monitoring.
Reduce el uso de Trace
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.
Cómo reducir tu factura de alertas
A partir del 1 de mayo de 2026, como muy pronto, Cloud Monitoring comenzará a cobrar por el uso de políticas de alertas. Para obtener información sobre el modelo de precios, consulta Precios de las alertas.En este documento, se describen las estrategias que puedes usar para reducir los costos de las alertas.
Consolida las políticas de alertas para que operen en más recursos
Debido al costo de USD 0.10 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. Considera los siguientes ejemplos:
Ejemplo 1
Datos
- 100 VM
- Cada VM emite una métrica,
metric_name metric_nametiene una etiqueta, que tiene 10 valores.
- Una condición de alerta
- La condición se agrega a nivel de la VM
- Período de ejecución de 30 segundos
- Costo de la condición: 1 condición * USD 0.10 por mes = USD 0.10 por mes
- Costo de series temporales: 100 series temporales devueltas por período × 86,400 períodos por mes = 8.6 millones de series temporales devueltas por mes × USD 0.35 por millón de series temporales = USD 3.02 por mes
- Costo total: USD 3.12 por mes
Ejemplo 2
Datos
- 100 VM
- Cada VM emite una métrica,
metric_name metric_nametiene una etiqueta, que tiene 10 valores.
- 100 condiciones
- Cada condición se filtra y agrega a una VM.
- Período de ejecución de 30 segundos
- Costo de la condición: 100 condiciones * USD 0.10 por mes = USD 10 por mes
- Costo de series temporales: 100 condiciones * 1 serie temporal devuelta por condición por período * 86,400 períodos por mes = 8.6 millones de series temporales devueltas por mes * USD 0.35 por millón de series temporales = USD 3.02 por mes
- Costo total: USD 13.02 por mes
En ambos ejemplos, supervisas la misma cantidad de recursos. Sin embargo, el ejemplo 2 usa 100 políticas de alertas, mientras que el ejemplo 1 usa solo una. Como resultado, el ejemplo 1 es casi USD 10 más económico por mes.
Agrega solo el nivel sobre el que necesitas generar alertas
La agregación en niveles de granularidad más altos genera costos más altos que la agregación en niveles de granularidad más bajos. Por ejemplo, agregar datos a nivel del proyecto Google Cloud es más económico que hacerlo a nivel del clúster, y agregar datos a nivel del clúster es más económico que hacerlo a nivel del clúster y del espacio de nombres.
Considera los siguientes ejemplos:
Ejemplo 1
Datos
- 100 VM
- Cada VM emite una métrica,
metric_name metric_nametiene una etiqueta, que tiene 10 valores.
- Una condición de alerta
- La condición se agrega a nivel de la VM
- Período de ejecución de 30 segundos
- Costo de la condición: 1 condición * USD 0.10 por mes = USD 0.10 por mes
- Costo de series temporales: 100 series temporales devueltas por período × 86,400 períodos por mes = 8.6 millones de series temporales devueltas por mes × USD 0.35 por millón de series temporales = USD 3.02 por mes
- Costo total: USD 3.12 por mes
Ejemplo 4
Datos
- 100 VMs, en las que cada VM pertenece a un servicio
- Cinco servicios en total
- Cada VM emite una métrica,
metric_name metric_nametiene una etiqueta, que tiene 10 valores.
- Una condición
- Agregados de condiciones a nivel del servicio
- Período de ejecución de 30 segundos
- Costo de la condición: 1 condición * USD 0.10 por mes = USD 0.10 por mes
- Costo de series temporales: 5 series temporales devueltas por período * 86,400 períodos por mes = 432,000 series temporales devueltas por mes * USD 0.35 por millón de series temporales = USD 0.14 por mes
- Costo total: USD 0.24 por mes
Ejemplo 5
Datos
- 100 VM
- Cada VM emite una métrica,
metric_name metric_nametiene 100 etiquetas con 1,000 valores cada una.
- Una condición
- La condición se agrega a nivel de la VM
- Período de ejecución de 30 segundos
- Costo de la condición: 1 condición * USD 0.10 por mes = USD 0.10 por mes
- Costo de series temporales: 100 series temporales devueltas por período * 86,400 períodos por mes = 8.5 millones de series temporales devueltas por mes * USD 0.35 por millón de series temporales = USD 3.02 por mes
- Costo total: USD 3.12 por 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 detallada a la VM.
Además, compara el ejemplo 1 con el ejemplo 5: En este caso, la cardinalidad de la métrica en el ejemplo 5 es 10,000 veces mayor que la cardinalidad de la métrica en el 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 a que la cantidad de VMs 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 interesa recibir alertas sobre el uso de CPU, es posible que desees agregar datos a nivel de la VM y la CPU. Si te interesa recibir alertas sobre la latencia por extremo, tal vez quieras agregar datos a nivel del extremo.
No generes alertas sobre datos sin procesar ni agregar
Monitoring usa un sistema de métricas dimensionales, 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 VMs que emiten una métrica y esa métrica tiene 10 etiquetas con 10 valores cada una, tu cardinalidad total es 100 * 10 * 10 = 10,000.
Como resultado de la forma en que se ajusta la cardinalidad, las alertas sobre los datos sin procesar pueden ser extremadamente costosas. En el ejemplo anterior, se devuelven 10,000 series temporales para cada período de ejecución. Sin embargo, si agregas los datos a la VM, solo se devolverán 100 series temporales por período de ejecución, independientemente de la cardinalidad de la etiqueta de los datos subyacentes.
Las alertas sobre datos sin procesar también te exponen al riesgo de aumentar las 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 aumentará a 100 * 11 * 10 = 11,000 series temporales. En este caso, la cantidad de series temporales devueltas aumenta en 1,000 en cada período de ejecución, aunque tu política de alertas no cambie. En cambio, si agregas los datos a la VM, a pesar del aumento de la cardinalidad subyacente, solo se mostrarán 100 series temporales.
Cómo filtrar respuestas innecesarias
Configura tus condiciones para evaluar solo los datos necesarios para tus necesidades de alertas. Si no tomarías medidas para corregir algo, exclúyelo de tus políticas de alertas. Por ejemplo, probablemente no necesites generar alertas sobre la VM de desarrollo de un pasante.
Para reducir los costos y las alertas innecesarias, puedes filtrar las series temporales que no sean importantes. Puedes usar etiquetas de metadatos Google Cloud para etiquetar recursos con categorías y, luego, filtrar las categorías de metadatos innecesarias.
Usa operadores de transmisión superior para reducir la cantidad de series temporales que se muestran
Si tu condición usa una consulta de PromQL o MQL, puedes usar un operador de top-streams para seleccionar una cantidad de las series temporales que se muestran con los valores más altos:
Por ejemplo, una cláusula topk(metric, 5) en una consulta de PromQL limita la cantidad de series temporales que se muestran a cinco en cada período de ejecución.
Limitar la cantidad de series temporales principales puede provocar la falta de datos y alertas defectuosas, como las siguientes:
- Si más de N series temporales incumplen tu umbral, perderás datos fuera de las primeras N series temporales.
- Si una serie temporal infractora se produce fuera de las principales N series temporales, es posible que tus incidentes se cierren automáticamente a pesar de que la serie temporal excluida siga incumpliendo el umbral.
- Es posible que tus consultas de condición no te muestren contexto importante, como las series temporales de referencia que funcionan según lo previsto.
Para mitigar estos riesgos, elige valores grandes para N y usa el operador top-streams solo en las políticas de alertas que evalúan muchas series temporales, como las alertas para contenedores individuales de Kubernetes.
Aumenta 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 de tu 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 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.
Supervisar
En esta sección, se describe cómo supervisar tus costos creando políticas de alertas. Una política de alertas puede supervisar los datos de las métricas y notificarte cuando esos datos superen un umbral.
Supervisa los bytes de registros mensuales transferidos
Para crear una política de alertas que se active cuando la cantidad de bytes de registros escritos en tus buckets de registros supere el límite definido por el usuario para Cloud Logging, usa la siguiente configuración.
| Nueva condición Campo |
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 registros mensuales ingeridos. |
| Filtro | Ninguno |
| Series temporales Agregación de series temporales |
sum |
| Ventana progresiva | 60 m |
| Función analítica progresiva | max |
| Configura el activador de alertas Campo |
Valor |
|---|---|
| Tipo de condición | Threshold |
| Activador de alertas | Any time series violates |
| Posición del umbral | Above threshold |
| Valor del umbral | Tú determinas el valor aceptable. |
| Período para volver a probar | El valor mínimo aceptable es 30 minutos. |
Supervisa las métricas totales 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. Para obtener más información, consulta Configura una alerta de facturación.
Supervisa los intervalos de seguimiento mensuales transferidos
Para crear una política de alertas que se active cuando el número de intervalos de Cloud Trace transferidos en un mes supere el límite definido por el usuario, usa la siguiente configuración.
| Nueva condición Campo |
Valor |
|---|---|
| Recurso y métrica | En el menú Recursos, selecciona Global. En el menú Categorías de métricas, selecciona Facturación. En el menú Métricas, selecciona Intervalos de seguimiento mensuales transferidos. |
| Filtro | |
| Series temporales Agregación de series temporales |
sum |
| Ventana progresiva | 60 m |
| Función analítica progresiva | max |
| Configura el activador de alertas Campo |
Valor |
|---|---|
| Tipo de condición | Threshold |
| Activador de alertas | Any time series violates |
| Posición del umbral | Above threshold |
Threshold value |
Tú determinas el valor aceptable. |
| Período para volver a probar | El valor mínimo aceptable es 30 minutos. |
Configura una alerta de facturación
Crea una alerta a través de la página Presupuestos y alertas de la consola de Google Cloud para recibir una notificación si tus cargos previstos o facturables superan un presupuesto.
-
En la consola de Google Cloud , ve a la página 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.
- En el menú de navegación de Facturación, selecciona Presupuestos y alertas.
- Haz clic en Crear presupuesto .
- Completa el diálogo del presupuesto. En este cuadro de diálogo, seleccionarás Google Cloud proyectos y productos, 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.