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 funcionen en más recursos
Debido al costo de USD 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. 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 1.50 por mes = USD 1.50 por mes
- Costo de las series temporales: 100 series temporales que se muestran por período × 86,400 períodos por mes = 8.6 millones de series temporales que se muestran por mes × USD 0.35 por millón de series temporales = USD 3.02 por mes
- Costo total: USD 4.52 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 se agrega a una VM.
- Período de ejecución de 30 segundos
- Costo de las condiciones: 100 condiciones × USD 1.50 por mes = USD 150 por mes
- Costo de las series temporales: 100 condiciones * 1 serie temporal que se muestra por condición por período * 86,400 períodos por mes = 8.6 millones de series temporales que se muestran por mes * USD 0.35 por millón de series temporales = USD 3.02 por mes
- Costo total: USD 153.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 150 más económico por mes.
Agrupa solo los niveles en los que necesitas generar alertas
La agregación a niveles más altos de detalle genera costos más altos que la agregación a niveles más bajos de detalle. Por ejemplo, la agregación a nivel del proyecto de Google Cloud es más económica que la agregación a nivel del clúster, y la agregación a nivel del clúster es más económica que la agregación 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 1.50 por mes = USD 1.50 por mes
- Costo de las series temporales: 100 series temporales que se muestran por período × 86,400 períodos por mes = 8.6 millones de series temporales que se muestran por mes × USD 0.35 por millón de series temporales = USD 3.02 por mes
- Costo total: USD 4.52 por mes
Ejemplo 4
Datos
- 100 VMs, en las que cada una 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
- Condiciones agregadas al nivel del servicio
- Período de ejecución de 30 segundos
- Costo de la condición: 1 condición × USD 1.50 por mes = USD 1.50 por mes
- Costo de las series temporales: 5 series temporales que se devuelven por período x 86,400 períodos por mes = 432,000 series temporales que se devuelven por mes x USD 0.35 por millón de series temporales = USD 0.14 por mes
- Costo total: USD 1.64 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 al nivel de la VM
- Período de ejecución de 30 segundos
- Costo de la condición: 1 condición × USD 1.50 por mes = USD 1.50 por mes
- Costo de las series temporales: 100 series temporales que se muestran por período × 86,400 períodos por mes = 8.5 millones de series temporales que se muestran por mes × USD 0.35 por millón de series temporales = USD 3.02 por mes
- Costo total: USD 4.52 por mes
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, 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, como la política de alertas del Ejemplo 1 y del Ejemplo 5 se agregan a la VM y como 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 funcionen mejor para tu caso de uso. Por ejemplo, si te interesa generar alertas sobre el uso de la CPU, te recomendamos que realices la agregación a nivel de la VM y la CPU. Si te importa generar alertas sobre la latencia por extremo, te recomendamos que realices la agregación a nivel del extremo.
No envíes alertas sobre datos sin procesar ni agregados
La supervisión usa un sistema de métricas dimensionales, en el que cualquier métrica tiene un total de [cardinality][cardinality] 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 escala de la cardinalidad, las alertas sobre datos sin procesar pueden ser muy costosas. En el ejemplo anterior, se muestran 10,000 series temporales para cada período de ejecución. Sin embargo, si agregas datos a la VM, solo se muestran 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, la 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 cada período de ejecución, aunque tu política de alertas no cambie. En cambio, si agregas a la VM, a pesar del aumento de la cardinalidad subyacente, solo se muestran 100 series temporales.
Cómo filtrar respuestas innecesarias
Configura las condiciones para que evalúen 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, es probable que no necesites enviar una alerta en 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 Google Cloud etiquetas de metadatos para etiquetar recursos con categorías y, luego, filtrar las categorías de metadatos que no se necesitan.
Usa operadores de flujo 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.
Limitarse a una cantidad máxima de series temporales podría provocar que se pierdan datos y alertas defectuosas, como las siguientes:
- Si más de N series temporales incumplen tu límite, no se mostrarán los datos fuera de las N series temporales principales.
- Si se produce una serie temporal que incumple el umbral fuera de las N series temporales principales, es posible que tus incidentes se cierren automáticamente a pesar de que las series temporales excluidas aún infrinjan el umbral.
- Es posible que tus consultas de condiciones no te muestren contexto importante, como las series temporales del modelo de referencia que funcionan según lo previsto.
Para mitigar esos 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.
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
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 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.