L’observabilité grignote le budget cloud sans bruit
Stockage des logs, échantillonnage des traces et labels de métriques influent sur les coûts d’observabilité. Où agir ?
Logs, métriques et traces facilitent l’exploitation des applications cloud distribuées. Leur collecte et leur stockage mobilisent des ressources et, selon le service, entraînent des coûts liés à la consommation. Les logs stockés plusieurs fois et les métriques aux nombreuses valeurs de label sont les plus difficiles à repérer. Un inventaire des flux de données montre où limiter les ressources.
L’essentiel en bref
- Les coûts dépendent du modèle de facturation de chaque service. Le volume de données, la durée de conservation et les destinations de stockage supplémentaires doivent donc être pris en compte ensemble.
- L’échantillonnage des traces exige une règle de sélection réfléchie. Le head sampling décide en amont, tandis que le tail sampling permet de sélectionner les traces à partir d’informations supplémentaires.
- Les labels de métriques peuvent fortement augmenter le nombre de séries temporelles. Les ensembles de valeurs qui continuent de croître à chaque requête ou pour chaque utilisateur sont particulièrement problématiques.
Quand les données de logs génèrent plusieurs fois des coûts
La première étape consiste à dresser une vue d’ensemble des sources, des flux de données et des destinations de stockage : quelle application produit quels logs ? Où sont-ils stockés et quelles équipes les utilisent ? Cette vue comprend aussi la transmission aux systèmes d’analyse et de sécurité. Elle permet ensuite de déterminer si une copie répond à un besoin propre.
Le modèle tarifaire précis détermine les économies possibles. Avec Google Cloud Logging, le stockage dans certains buckets de logs donne lieu à des frais liés au volume. Si une même entrée est stockée dans plusieurs buckets payants, chacune de ces copies est prise en compte dans la facturation. Une conservation plus longue peut entraîner des frais supplémentaires. D’autres services et contrats peuvent appliquer une facturation différente.
Les équipes devraient donc relever le volume et les coûts de chaque flux de données et désigner une personne responsable. Un budget assorti d’une alerte rend la croissance visible. Avant de fixer une limite stricte, il faut déterminer quels signaux doivent être conservés pour l’exploitation et la sécurité.
Utiliser l’échantillonnage des traces de manière ciblée
L’échantillonnage réduit la quantité de traces stockées en opérant une sélection. Avec le head sampling, la décision intervient tôt. À ce stade, le déroulement complet n’est pas encore connu. Le head sampling seul ne permet donc pas de tenir compte, pour chaque trace, d’une erreur qui surviendrait ultérieurement.
Le tail sampling selon OpenTelemetry peut effectuer une sélection à partir d’informations issues de plusieurs spans, par exemple selon le statut d’erreur ou la latence. Le composant d’échantillonnage doit pour cela d’abord collecter et traiter les données. Cela augmente la charge d’exploitation. Une règle de head sampling appliquée en amont peut aussi éliminer des traces avant que la sélection ultérieure n’intervienne.
Il n’est pas possible d’en déduire un taux fixe pour tous les services. Un test par service est utile : quelles erreurs et quelles opérations lentes restent visibles ? Quel volume de données atteint le backend ? La règle est ensuite adaptée à partir de ces résultats.
Évaluer la conservation et les labels selon leur utilité
Chaque classe de logs doit avoir une finalité documentée et une durée de conservation adaptée. Les données de débogage peuvent répondre à des exigences différentes de celles des journaux de sécurité ou d’audit. Avant de réduire la durée de conservation ou de supprimer des données, l’équipe responsable vérifie les obligations légales et contractuelles applicables ainsi que les besoins liés aux enquêtes sur les incidents. L’archivage peut être une option si l’accès et les coûts correspondent à l’usage prévu.
Pour les métriques, il est utile d’examiner la cardinalité. Selon Prometheus, chaque combinaison unique de noms et de valeurs de labels produit une série temporelle distincte. Les identifiants utilisateurs ou d’autres valeurs sans limite supérieure fixe peuvent entraîner une forte croissance du volume de données. Pour les métriques d’exploitation agrégées, des dimensions limitées sont généralement plus adaptées ; les cas individuels peuvent, le cas échéant, être examinés à l’aide des logs ou des traces.
Examiner régulièrement les responsabilités et les effets
Après l’inventaire, l’équipe classe les flux de données les plus importants par ordre de priorité et établit une valeur de référence pour les changements : le volume de données, les coûts et la finalité opérationnelle des signaux. L’échantillonnage et la conservation sont documentés, puis mesurés à nouveau après une modification. Il faut notamment vérifier que les alertes et les requêtes liées aux incidents fournissent toujours les informations nécessaires.
Un examen régulier réunit les équipes chargées de l’exploitation de la plateforme, les responsables des services et les responsables budgétaires. Toute nouvelle source de données est ainsi évaluée en fonction de son utilité et des coûts qu’elle entraîne.
Questions fréquentes
L’échantillonnage peut-il conserver toutes les traces d’erreur ?
Le head sampling seul ne peut pas le garantir, car la décision intervient tôt. Le tail sampling peut utiliser les erreurs comme critère de sélection, mais il doit pour cela accéder aux données de trace correspondantes et entraîne sa propre charge d’exploitation.
Combien de temps faut-il conserver les logs ?
D’un point de vue technique, il n’existe pas de durée unique pour tous les logs. L’équipe devrait examiner, pour chaque classe de données, la finalité, les besoins liés aux incidents ainsi que les exigences légales et contractuelles applicables.
Pourquoi les identifiants utilisateurs peuvent-ils coûter cher dans les métriques ?
Chaque nouvelle combinaison de labels peut produire une série temporelle supplémentaire. Un grand nombre d’identifiants utilisateurs différents augmente ainsi le volume de données et les ressources nécessaires au système de métriques.
Sélection de la rédaction
cloudmagazinQuand les GPU engloutissent le budget SaaScloudmagazinFlexera 2026 : ce que les PME peuvent vraiment adoptercloudmagazinUne région tombe, la moitié de la chaîne d’approvisionnement s’arrêtePlus du réseau MBF Media
MyBusinessFutureDe nouveaux modèles d’IA réduisent les erreurs en cascade dans les dossiers de créditDigital ChiefsCe que les cabinets de conseil taisent sur la transformationSecurityTodayUn pilote signé rend la protection des terminaux aveugleSource de l’image : générée par IA (juillet 2026)
Traduit de l’original allemand par intelligence artificielle. La version allemande fait foi.
