En esta página, se incluye un índice de prácticas recomendadas para las políticas de alertas con una condición basada en el lenguaje de consulta de Monitoring (MQL). Puedes usar la información recopilada aquí como una referencia rápida de lo que debes tener en cuenta cuando configuras una política de alertas con una condición basada en MQL.
En esta página, no se describen los conceptos básicos para usar las consultas de MQL en tus políticas de alertas. Si eres un usuario nuevo, consulta Políticas de alertas con MQL.
Operaciones recomendadas para consultas de MQL en políticas de alertas
La evaluación de políticas de alertas involucra varios servicios internos.
Debido a la forma en que estos servicios interactúan con MQL, te recomendamos
usar ciertas operaciones de MQL en lugar de otras.
Por ejemplo, si
usas delta en lugar de delta_gauge, las alertas pueden activarse en momentos incorrectos.
En la siguiente tabla, se muestra una lista de operaciones que se deben evitar y las que se recomiendan usar en su lugar.
| Evitar | Recomendado |
|---|---|
adjacent_rate |
rate |
adjacent_delta |
delta_gauge |
delta |
delta_gauge |
window |
sliding |
Usa la declaración every 30s con políticas de alertas
Las políticas de alertas evalúan su condición cada 30 segundos. Este intervalo de tiempo se denomina ventana de salida.
Te recomendamos que las condiciones incluyan una operación every 30s explícita como recordatorio visual de este período.
Por ejemplo, la siguiente consulta de MQL de políticas de alertas incluye una declaración every 30s explícita:
fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count | group_by sliding(1h) | every 30s
Si guardas una política de alertas con una consulta de MQL que usa un valor diferente para la operación every, Cloud Monitoring sigue usando un valor de 30 segundos cuando la política de alertas está activa. Por ejemplo, una política de alertas con la siguiente consulta todavía tiene una ventana de resultados de 30 segundos:
fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count | group_by sliding(1h) | every 90s
Mejora la eficiencia de las consultas
Las consultas se ejecutan con lentitud cuando se procesan grandes volúmenes de datos. Para mejorar la eficiencia de las consultas, puedes intentar reducir la cantidad de datos que procesa la consulta. En las siguientes secciones, se proporcionan varias opciones para reducir el volumen de datos que evalúa tu consulta.
Coloca filtros antes en tu consulta
Cuando colocas filtros antes en tu consulta, estos pueden filtrar los datos innecesarios antes de que la consulta ejecute operaciones en tus datos. Por ejemplo, considera la siguiente consulta:
fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count | group_by [resource.zone], .sum | filter zone = 'us-west1-b' | condition val() > 5'GBy'
Es posible que la consulta se ejecute más rápido si mueves la operación filter antes de la operación group_by:
fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count | filter zone = 'us-west1-b' | group_by [resource.zone], .sum | condition val() > 5'GBy'
Disminuir la ventana de alineación de consultas
Cuando una consulta usa la operación align, una ventana de alineación más pequeña representa un intervalo de tiempo más pequeño que Cloud Monitoring evalúa para cada punto en la serie temporal. Como resultado, puedes intentar mejorar la eficiencia de las consultas reduciendo el valor de la operación align.
Por ejemplo, la siguiente consulta tiene una ventana de alineación de dos horas:
fetch gce_instance :: compute.googleapis.com/instance/disk/read_bytes_count | group_by window(1h), .sum | align next_older(2h) | every 30s | condition val() > 2'GBy'
Sin embargo, si necesitas ver los datos de solo un período de 1 hora, puedes reducir el período de alineación a 1 hora:
fetch gce_instance :: compute.googleapis.com/instance/disk/read_bytes_count | group_by window(1h), .sum | align next_older(1h) | every 30s | condition val() > 2'GBy'
Para obtener más información, consulta Alineación.
Disminuye el período de duración de la política de alertas
El período de duración de la política de alertas representa el período en el que cada medición debe infringir la condición antes de que se envíe una alerta. Si reduces el período de duración de tu política de alertas sin aumentar el período de alineación de consultas, Cloud Monitoring tendrá menos puntos para evaluar según la condición de la política de alertas.
Para obtener más información, consulta Período de duración.
Asigna valores predeterminados a metadatos nulos
Si un valor de metadatos es nulo, tus consultas podrían producir resultados inesperados. Puedes evitar resultados inesperados con la función or_else para asignar un valor predeterminado a los metadatos que, de lo contrario, tendrían un valor nulo.
Por ejemplo, ejecutas una consulta que agrega todos tus datos juntos:
fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count | group_by [], 24h, sum(egress_bytes_count) | condition val() > 10'MBy'
La consulta produce un resultado de 10 MB. A continuación, ejecuta una consulta para verificar cómo se distribuyen los 10 MB entre las zonas de nodos:
fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count | group_by [metadata.system.node_zone], 24h, sum(egress_bytes_count) | condition val() > 10'MBy'
La consulta de distribución muestra los siguientes resultados:
node_zone |
egress_byte_count |
|---|---|
| us-central1-f | 7.3 MB |
| us-west1-b | 2.5 MB |
Estos resultados muestran un total de 9.8 MB en lugar de los 10 MB y previstos. Esta discrepancia puede ocurrir si una de las etiquetas de metadatos agregadas tiene un valor nulo, como en el siguiente conjunto de datos:
| valor | valor de metadatos |
|---|---|
| 7.3 MB | us-central1-f |
| 2.5 MB | us-west1-b |
| 0.2 MB |
Para evitar problemas relacionados con los metadatos nulos, puedes unir la referencia de metadatos en una operación or_else, que te permite especificar un valor predeterminado en caso de que una columna de metadatos no tenga ningún valor. Por ejemplo, la siguiente consulta usa or_else a fin de establecer un valor de metadatos de no zone para cualquier columna de metadatos sin un valor:
fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count | group_by [or_else(metadata.system.node_zone, 'no zone')], 24h, sum(egress_bytes_count) | condition val() > 10'MBy'
Esta consulta nueva produce los siguientes resultados, que suman 10 MB:
node_zone |
egress_byte_count |
|---|---|
| us-central1-f | 7.3 MB |
| us-west1-b | 2.5 MB |
| sin zona | 0.2 MB |