Questa pagina contiene un indice di best practice per i criteri di avviso con una condizione basata su Monitoring Query Language (MQL). Puoi utilizzare le informazioni raccolte qui come riferimento rapido di cosa tenere presente quando si configura un criterio di avviso con una condizione basata su MQL.
Questa pagina non descrive le nozioni di base sull'utilizzo delle query MQL nei criteri di avviso. Se sei un nuovo utente, consulta Criteri di avviso con MQL.
Operazioni consigliate per le query MQL nei criteri di avviso
La valutazione dei criteri di avviso coinvolge più servizi interni.
A causa del modo in cui questi servizi interagiscono con MQL, consigliamo vivamente di utilizzare alcune operazioni MQL anziché altre.
Ad esempio, se
utilizzi delta anziché delta_gauge, gli avvisi potrebbero essere attivati
in orari errati.
La tabella seguente mostra un elenco delle operazioni da evitare e quelle consigliate da utilizzare.
| Azioni non consigliate | Consigliato |
|---|---|
adjacent_rate |
rate |
adjacent_delta |
delta_gauge |
delta |
delta_gauge |
window |
sliding |
Utilizza l'istruzione every 30s con i criteri di avviso
I criteri di avviso valutano la loro condizione ogni 30 secondi. Questo intervallo di tempo è chiamato finestra di output.
Ti consigliamo di includere un'operazione esplicita di every 30s
come promemoria visivo di questo periodo.
Ad esempio, la seguente query MQL per i criterio di avviso include un'istruzione every 30s esplicita:
fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count | group_by sliding(1h) | every 30s
Se salvi un criterio di avviso con una query MQL che utilizza un valore diverso per l'operazione every, Cloud Monitoring utilizza comunque un valore di 30 secondi quando il criterio di avviso è attivo. Ad esempio,
un criterio di avviso con la seguente query ha ancora una finestra di output di 30 secondi:
fetch gce_instance :: compute.googleapis.com/instance/disk/write_bytes_count | group_by sliding(1h) | every 90s
Migliora l'efficienza delle query
Le query vengono eseguite lentamente durante l'elaborazione di grandi volumi di dati. Per migliorare l'efficienza delle query, puoi provare a ridurre la quantità di dati elaborati. Le seguenti sezioni forniscono diverse opzioni per ridurre il volume di dati valutati dalla query.
Inserisci i filtri all'inizio della query
Quando inserisci i filtri in precedenza nella query, puoi filtrare i dati non necessari prima che la query esegua operazioni sui dati. Ad esempio, considera la seguente query:
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'
La query potrebbe essere eseguita più velocemente se sposti l'operazione filter prima dell'operazione 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'
Riduci la finestra di allineamento delle query
Quando una query utilizza l'operazione align, una finestra di allineamento più piccola rappresenta un intervallo di tempo più breve valutato da Cloud Monitoring per ogni punto della serie temporale. Di conseguenza, puoi provare a migliorare l'efficienza della query riducendo il valore dell'operazione align.
Ad esempio, la seguente query ha una finestra di allineamento di due ore:
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'
Tuttavia, se hai bisogno di visualizzare i dati solo per un periodo di tempo di un'ora, puoi ridurre la finestra di allineamento a 1 ora:
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'
Per ulteriori informazioni, vedi Allineamento.
Diminuisci la durata del criterio di avviso
La finestra della durata del criterio di avviso rappresenta il periodo di tempo in cui ogni misura deve violare la condizione prima che venga inviato un avviso. Se riduci la durata del criterio di avviso senza aumentare la finestra di allineamento delle query, Cloud Monitoring avrà meno punti da valutare per la condizione del criterio di avviso.
Per ulteriori informazioni, consulta Finestra Durata.
Assegna valori predefiniti ai metadati null
Se un valore dei metadati è null, le query potrebbero produrre risultati imprevisti. Puoi evitare risultati imprevisti utilizzando la funzione or_else
per assegnare un valore predefinito ai metadati che altrimenti avrebbero un valore nullo.
Ad esempio, esegui una query che aggrega tutti i dati:
fetch k8s_pod :: networking.googleapis.com/pod_flow/egress_bytes_count | group_by [], 24h, sum(egress_bytes_count) | condition val() > 10'MBy'
La query produce un risultato di 10 MBy. Quindi, esegui una query per verificare come i 10 MBy sono distribuiti tra le zone dei nodi:
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 query di distribuzione restituisce i seguenti risultati:
node_zone |
egress_byte_count |
|---|---|
| us-central1-f | 7,3 MBy |
| us-west1-b | 2,5 MB |
Questi risultati mostrano un totale di 9,8 MBy rispetto ai 10 MBy previsti. Questa discrepanza può verificarsi se una delle etichette dei metadati aggregate ha un valore nullo, ad esempio nel seguente set di dati:
| valore | valore metadati |
|---|---|
| 7,3 MBy | us-central1-f |
| 2,5 MB | us-west1-b |
| 0,2 MB |
Per evitare problemi con metadati nulli, puoi eseguire il wrapping del riferimento dei metadati in un'operazione or_else, che ti consente di specificare un valore predefinito nel caso in cui una colonna di metadati non abbia alcun valore. Ad esempio, la seguente query utilizza or_else per impostare un valore dei metadati pari a no zone per tutte le colonne di metadati senza un valore:
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'
Questa nuova query produce i seguenti risultati, la cui somma è 10 MBy:
node_zone |
egress_byte_count |
|---|---|
| us-central1-f | 7,3 MBy |
| us-west1-b | 2,5 MB |
| nessuna zona | 0,2 MB |