En este documento, se describen las estrategias que puedes usar para reducir los costos de las alertas. Para obtener información sobre el modelo de precios, consulta Precios de Google Cloud Observability.
Consolida las políticas de alertas para que operen en más recursos
Las alertas cobran un costo por condición. Por este motivo, cuando sea posible, usa una política de alertas para supervisar varios recursos en lugar de crear una política de alertas para cada recurso.
Por ejemplo, supongamos que tienes 100 VMs. Cada VM genera una serie temporal para el tipo de métrica my_metric. Estas son dos formas diferentes de supervisar las series temporales:
Crearás una política de alertas que tendrá una condición. La condición supervisa
my_metricy agrega datos a nivel de la VM. Después de la agregación, hay una serie temporal para cada VM. Por lo tanto, la condición supervisa 100 series temporales.Creas 100 políticas de alertas y cada una contiene 1 condición. Cada condición supervisa la serie temporal de
my_metricpara una de las VMs y agrega datos a nivel de la VM. Por lo tanto, cada condición supervisa una serie temporal.
La segunda opción, que crea 100 condiciones, es más costosa que la primera, que solo crea 1 condición. Ambas opciones supervisan 100 series temporales.
Agrega solo el nivel sobre el que necesitas generar alertas
Hay un costo por cada serie temporal que supervisa una política de 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.
Por ejemplo, supongamos que tienes 100 VMs. Cada VM genera una serie temporal para el tipo de métrica my_metric. Cada una de tus VMs pertenece a uno de los cinco servicios. Decides crear una política de alertas que tenga una condición que supervise my_metric. Estas son dos opciones de agregación diferentes:
Agregas datos al servicio. Después de la agregación, hay una serie temporal para cada servicio. Por lo tanto, la condición supervisa 5 series temporales.
Agregas datos a nivel de la VM. Después de la agregación, hay una serie temporal para cada VM. Por lo tanto, la condición supervisa 100 series temporales.
La segunda opción, que supervisa 100 series temporales, es más costosa que la primera, que solo supervisa cinco.
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 la CPU, es posible que desees agregar datos a nivel de la VM y la CPU. Si te interesa recibir alertas sobre la latencia por servicio, es posible que desees agregar datos a nivel del servicio.
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 los incidentes 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, no tendrás datos fuera de las N series temporales principales.
- 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.