Google Cloud Logging ha un costo di 0,5 $ per GiB di log ingeriti, con una soglia gratuita di 50 GiB per progetto. Di norma la spesa complessiva resta contenuta, ma ci sono casi in cui questi costi possono schizzare alle stelle. Finora Google si è dimostrata piuttosto comprensiva in queste situazioni, concedendo rimborsi, ma è bene mantenere il controllo qualora questa politica permissiva dovesse cambiare.
Perché i costi di logging possono schizzare?
Lo abbiamo visto succedere molte volte: uno sviluppatore rilascia una nuova versione con un livello di verbosità di debug più elevato. Oppure crea un nuovo HTTP load balancer senza disattivare la configurazione predefinita che invia in streaming gli access log. Nel giro di poco l'utilizzo di Logging cresce di 100 volte e i costi seguono lo stesso ritmo.
Chi monitora attivamente i costi di progetto individuerà con tutta probabilità questo picco entro un paio di giorni. Altri potrebbero essere meno fortunati e ritrovarsi alle prese con il fin troppo noto fenomeno del bill shock.
Come valutare il tasso di ingestione dei log
Come quasi tutti gli altri servizi di Google Cloud, anche Logging produce metriche preziose, disponibili nel servizio Monitoring.
La metrica da cui partire è "Log bytes ingested".
Ecco un grafico di esempio di questa metrica:
Log bytes ingested, suddivisi per servizio che produce i log — ultima ora
Osservando l'ultima ora non emerge alcun pattern, e quindi è difficile rilevare anomalie.
Se estendiamo l'intervallo a un mese, vediamo chiaramente un pattern: i log vengono prodotti in modo intensivo nei giorni feriali (lunedì — venerdì):
Log bytes ingested, suddivisi per servizio che produce i log — ultimo mese, i giorni feriali sono evidenziati nei riquadri blu
Si tratta di un pattern analizzabile: se una qualsiasi delle serie temporali si discosta da questo andamento, sappiamo che potremmo avere un problema che causa un'emissione eccessiva di log nel servizio interessato.
Come approfondire l'analisi delle metriche dei log
Tutte le risorse GCP emettono la metrica "Log bytes". Se, ad esempio, volessimo isolare il tasso di emissione dei log di App Engine, potremmo tracciare questo grafico:
Approfondimento sull'emissione dei log di App Engine
L'analisi va bene, ma come si monitora tutto questo?
Come avrà intuito, nessuno ha voglia di restare a fissare un grafico tutto il giorno aspettando che spunti un'anomalia. Come si può quindi monitorare in modo proattivo il tasso di emissione dei log?
Se il tasso di emissione è costante nell'arco della giornata, basta creare una policy di alerting in Monitoring: invierà un avviso ogni volta che una serie temporale cresce di una percentuale prestabilita.
Se invece l'emissione dei log è ciclica, il monitoraggio diventa più complesso. L'emissione fluttua durante la giornata, perciò aumenti e diminuzioni della serie temporale sono fisiologici. Di conseguenza, un alert basato su questo dato rischia di generare numerosi falsi allarmi.
Per aggirare il problema si può attenuare la stagionalità modificando il periodo di aggregazione.
Ignorare la stagionalità delle serie temporali
Possiamo levigare i dati tracciati aggregandoli su un arco di tempo più ampio. Ad esempio, il grafico che con un periodo di aggregazione di un minuto si presentava così:
Log bytes ingested — periodo di aggregazione impostato a 1 minuto
…assume questo aspetto con un periodo di aggregazione di un giorno:
Log bytes ingested — periodo di aggregazione impostato a 1 giorno
…e questo con un periodo di aggregazione di una settimana:
Log bytes ingested — periodo di aggregazione impostato a 1 settimana
Sull'ultimo grafico è senz'altro possibile impostare un alert quando una qualsiasi delle serie temporali aumenta (o diminuisce) di una certa percentuale.
Purtroppo, al momento Google Cloud Monitoring non supporta periodi di aggregazione superiori a 25 ore per le Alerting Policy, quindi non è possibile costruire un alert di questo tipo da Cloud Monitoring.
Ci siamo rivolti a Google chiedendo di rimuovere il limite delle 25 ore, in modo da poter impostare alert efficaci sull'emissione dei log quando le serie temporali sono cicliche. È stata aperta una feature request: se la funzionalità le interessa, può aggiungere una stella per supportarla.
Grazie per la lettura! Per restare in contatto, ci segua sul DoiT Engineering Blog, sul canale LinkedIn di DoiT e sul canale Twitter di DoiT. Per scoprire le opportunità di carriera, visiti https://careers.doit-intl.com.