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.