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 el resumen de precios de Cloud Monitoring.
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 incidentes y los costos innecesarios, 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, puedes usar un operador de top-streams para seleccionar una cantidad de series temporales que se muestran con los valores más altos:
- PromQL:
topk
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 la generación de incidentes defectuosos, como los 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 los incidentes de 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.