Google Cloud Logging facture 0,5 $/Gio de logs ingérés, avec une offre gratuite de 50 Gio par projet. La facture reste généralement modeste, mais certains scénarios peuvent faire flamber ces coûts. Google s'est jusqu'ici montré plutôt clément en accordant des remboursements, mais mieux vaut garder la main au cas où cette politique souple viendrait à changer.
Pourquoi les coûts de logging peuvent-ils s'envoler ?
Nous avons vu ce scénario se répéter de nombreuses fois : un développeur déploie une nouvelle version avec un niveau de verbosité de débogage accru. Ou il crée un nouveau load balancer HTTP sans désactiver la configuration par défaut qui diffuse ses logs d'accès. Et soudain, votre utilisation de Logging est multipliée par 100, avec des coûts qui suivent la même courbe.
Si vous surveillez activement les coûts de vos projets, vous repérerez probablement ce pic en quelques jours. D'autres seront moins chanceux, et c'est alors le phénomène bien connu du choc à la facturation.
Comment évaluer le débit d'ingestion des logs
Comme la plupart des autres services Google Cloud, Logging produit des métriques précieuses, accessibles depuis le service Monitoring.
La première métrique à examiner est Log bytes ingested.
Voici un exemple de graphique pour cette métrique :
Log bytes ingested, ventilé par service produisant les logs — dernière heure
Sur la dernière heure, aucun motif particulier ne se dégage : difficile, donc, de détecter une anomalie.
En étendant la plage temporelle à un mois, un motif clair apparaît : les logs sont produits massivement les jours ouvrés (du lundi au vendredi) :
Log bytes ingested, ventilé par service produisant les logs — dernier mois, les jours ouvrés sont encadrés en bleu
Voilà un motif exploitable : si l'une des séries temporelles s'en écarte, on sait qu'un problème pourrait provoquer une émission excessive de logs dans le service concerné.
Comment approfondir l'analyse des métriques de logs
Toutes les ressources GCP émettent la métrique Log bytes. Pour isoler par exemple le débit d'émission de logs d'App Engine, il suffit de tracer le graphique suivant :
Analyse détaillée de l'émission de logs d'App Engine
L'analyse, c'est bien — mais comment mettre tout cela sous surveillance ?
Comme vous vous en doutez, personne n'a envie de rester scotché à un graphique toute la journée en guettant la moindre anomalie. Alors, comment surveiller le débit d'émission de logs de manière proactive ?
Si le débit d'émission est constant tout au long de la journée, il suffit de créer une politique d'alerte dans Monitoring. Elle se déclenchera dès qu'une série temporelle augmentera au-delà d'un pourcentage configuré.
En revanche, si l'émission de logs est cyclique, la surveillance se complique. L'émission fluctue au cours de la journée, et des hausses ou baisses sont attendues. Configurer une alerte sur cette base risque donc de générer de nombreuses fausses alertes.
Pour contourner ce problème, vous pouvez lisser la saisonnalité en modifiant la période d'agrégation.
Ignorer la saisonnalité d'une série temporelle
On peut lisser les données affichées en agrégeant sur une période plus longue. Par exemple, le graphique qui ressemblait à ceci avec une période d'agrégation d'une minute :
Log bytes ingested — période d'agrégation fixée à 1 minute
…ressemblera à cela une fois la période d'agrégation portée à un jour :
Log bytes ingested — période d'agrégation fixée à 1 jour
…et à ceci avec une période d'agrégation d'une semaine :
Log bytes ingested — période d'agrégation fixée à 1 semaine
Ce dernier graphique se prête parfaitement à la mise en place d'une alerte lorsqu'une série temporelle augmente (ou diminue) au-delà d'un certain pourcentage.
Malheureusement, Google Cloud Monitoring ne prend pas en charge actuellement les périodes d'agrégation supérieures à 25 heures pour les politiques d'alerte : impossible, donc, de construire une telle alerte depuis Cloud Monitoring.
Nous avons sollicité Google pour suggérer la suppression de cette limite de 25 heures, afin de permettre des alertes pertinentes sur l'émission de logs quand les séries temporelles sont cycliques. Une demande de fonctionnalité a été soumise ; n'hésitez pas à lui ajouter une étoile si cette fonctionnalité vous intéresse.
Merci de votre lecture ! Pour rester en contact, suivez-nous sur le DoiT Engineering Blog , la page LinkedIn DoiT et le compte Twitter DoiT . Pour découvrir nos opportunités de carrière, rendez-vous sur https://careers.doit-intl.com .