Administra los costos de las alertas

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 y Ejemplos de precios de las alertas.

Consulta tu factura estimada con la calculadora de precios integrada en la IU

Cuando creas o editas una política de alertas, Cloud Alerting muestra el costo estimado de la política. Puedes usar esta calculadora para ver cómo cambia tu costo estimado a medida que modificas los parámetros de tu política de alertas.

Usa el Explorador de métricas para verificar el recuento de puntos devueltos

La cantidad de puntos que devuelve la consulta de la política de alertas depende principalmente de la cardinalidad del resultado de la consulta de la política de alertas. Para ver la cardinalidad estimada de tu política de alertas, haz lo siguiente:

  • Para una condición de alerta de umbral de métrica, usa el Explorador de métricas para crear una consulta idéntica. Agrega una transformación secundaria de Serie temporal de recuento por Ninguno.
  • Para una condición de alerta de PromQL, copia la consulta en el Explorador de métricas y, luego, haz lo siguiente:
    • Divide tu consulta en cláusulas separadas dividiendo cada operador >, <, >=, <=, ==, !=, AND, OR y UNLESS.
    • Borra cualquier cláusula que no contenga una métrica, como un valor de umbral numérico.
    • Encierra cada cláusula en una función count().
    • Suma los resultados.

  • En el caso de una condición de alerta de MQL, copia la consulta en el Explorador de métricas. Quita la línea | condition. Agrega una línea | group_by [], .count al final.

    El MQL dejó de estar disponible, y es posible que Atención al cliente de Cloud rechace los casos en los que se solicite ayuda para depurar problemas de facturación.

Consolida las políticas de alertas para que operen en más recursos

Las alertas cobran un costo por referencia de métrica, y cada política de umbral de métrica tiene una referencia de métrica 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 un punto por minuto para el tipo de métrica my_metric. Estas son dos formas diferentes en las que puedes supervisar los puntos que se devuelven:

  • Creas una política de alertas que tiene una condición y, por lo tanto, una referencia de métrica. La condición supervisa my_metric y agrega datos al nivel de la VM. Después de la agregación, se devuelve un punto para cada VM. Por lo tanto, la condición genera 100 puntos que se devuelven por evaluación.

  • Creas 100 políticas de alertas, y cada una contiene una condición y, por lo tanto, tiene una referencia de métrica. Cada condición supervisa la serie temporal my_metric de una de las VMs y agrega datos a nivel de la VM. Por lo tanto, cada condición devuelve un punto por evaluación.

La segunda opción, que crea 100 condiciones (100 referencias de métricas), es más costosa que la primera, que solo crea 1 condición (1 referencia de métrica). Ambas opciones devuelven 100 puntos por evaluación.

Agrega solo el nivel sobre el que necesitas generar alertas

Se devuelve un punto para 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 proyectoGoogle 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 un punto 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, cada ejecución de la política de alertas devuelve un punto para cada servicio. Por lo tanto, la condición devuelve 5 puntos por ejecución.

  • Agregas datos a nivel de la VM. Después de la agregación, cada ejecución de la política de alertas devuelve un punto para cada VM. Por lo tanto, la condición devuelve 100 puntos por ejecución.

La segunda opción, que devuelve 100 puntos por ejecución, es más costosa que la primera, que solo devuelve cinco puntos por ejecución.

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 se envían 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 puntos para cada período de ejecución. Sin embargo, si agregas datos a la VM, solo se devuelven 100 puntos 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 que se devuelvan más puntos cuando tus métricas reciban 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 puntos devueltos aumenta en 1,000 en cada período de ejecución, aunque tu política de alertas no haya cambiado. 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 puntos que se muestran

Si tu condición usa una consulta de PromQL, puedes usar un operador de top-streams para seleccionar una cantidad de los puntos 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 puntos que se muestran a cinco en cada período de ejecución.

Limitar la cantidad de puntos principales puede provocar que falten datos y que se produzcan incidentes defectuosos, como los siguientes:

  • Si más de N puntos incumplen tu umbral, perderás datos fuera de los primeros N puntos.
  • Si se produce un punto infractor fuera de los N puntos principales, es posible que tus incidentes se cierren automáticamente a pesar de que los puntos excluidos sigan incumpliendo el umbral.
  • Es posible que tus consultas de condiciones no te muestren contexto importante, como los puntos 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 puntos devueltos 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.

No uses "Recurso no especificado" (solo para métricas basadas en registros)

Las condiciones de alerta que usan métricas basadas en registros te permiten establecer "Recurso no especificado" como tu tipo de recurso supervisado. Cuando lo haces, la condición de alerta inicia una consulta independiente para cada tipo de recurso supervisado en Cloud Monitoring. Como cada consulta factura un mínimo de un punto devuelto, no especificar el tipo de recurso genera una factura alta por los puntos devueltos.

Para reducir tu factura, elige un tipo de recurso específico en lugar de usar "Recurso no especificado". Esto funciona porque la mayoría de las métricas basadas en registros solo aparecen en un tipo de recurso. Si tu métrica basada en registros aparece en varios tipos de recursos, puedes crear varias políticas de alertas o usar varias condiciones en una sola política de alertas.