Les limites de résultats de requêtes d'Amazon CloudWatch Logs Insights passent de 10 000 à 100 000 lignes. AWS a aussi doté son API GetQueryResults de la prise en charge de la pagination. Ces ajouts doivent aider les développeurs et les ingénieurs en fiabilité des sites (Site Reliability Engineers ou SRE) à dépanner et à déboguer plus efficacement les applications distribuées à grande échelle. Selon un post publié sur le blog d'AWS, avec cette mise à jour du service de surveillance et d'observabilité, les équipes SRE pourront éviter, lors des enquêtes sur les incidents, du débogage et des audits opérationnels dans les environnements d'entreprise, d’avoir à diviser à plusieurs reprises les requêtes en fenêtres temporelles plus petites.
Selon les analystes, cette initiative apporte un raisonnement opérationnel solide. « L'ancienne limite de 10 000 lignes de CloudWatch posait un réel problème pour les grands systèmes distribués. En cas de panne, les équipes SRE devaient souvent réexécuter la même requête sur plusieurs petites fenêtres temporelles et combiner manuellement les résultats. Les pipelines automatisés de surveillance et de conformité nécessitaient également une logique personnalisée supplémentaire, ce qui rendait les systèmes plus complexes et plus fragiles », a expliqué Pareekh Jain, analyste principal chez Pareekh Consulting. « La nouvelle limite de 100 000 résultats facilite considérablement les analyses. Les équipes peuvent désormais analyser des incidents de plus grande envergure en une seule requête, ce qui réduit le travail manuel et accélère le dépannage. Les tableaux de bord, les exportations et l’analyse des tendances s’appuient également sur des données plus complètes », a noté M. Jain. « Dans les environnements de microservices où une seule requête touche de nombreux services, les équipes ont désormais beaucoup plus de chances de visualiser l’impact complet d’une défaillance en une seule recherche », a ajouté M. Jain.
Le support de la pagination pourrait stimuler l’automatisation de l’observabilité
Gaurav Dewan, directeur de recherche chez Avasant, estime que le support de la pagination par l’API GetQueryResults constitue l’amélioration architecturale la plus « importante ». « Auparavant, les API de requête pouvaient renvoyer des ensembles de données tronqués, obligeant les équipes à réexécuter les requêtes avec des filtres supplémentaires ou à mettre en œuvre une logique personnalisée pour récupérer des résultats complets, ce qui ajoutait de la complexité, en particulier pour les workflows automatisés comme les runbooks, les bots ou les pipelines d’ingestion SIEM », a souligné M. Dewan. « Grâce à la pagination, les résultats des requêtes sont désormais accessibles de manière incrémentielle et structurée, ce qui facilite la récupération par programmation de grands ensembles de données et devrait améliorer la fiabilité des workflows d’automatisation construits sur CloudWatch », a-t-il avancé.
Malgré ces avantages immédiats, aucun des deux analystes ne pensent que cette mise à jour permettra de se passer de plateformes d’observabilité ou SIEM tierces dans les environnements d’entreprise. « Ces ajouts réduisent les frictions au niveau des détails, mais ne comble pas les lacunes structurelles qui justifient l’adoption d’outils tiers d’observabilité ou de SIEM », a fait remarquer M. Jain. « Si les équipes chargées du dépannage des charges de travail Lambda, ECS ou EKS au sein d’AWS peuvent désormais s’appuyer davantage sur CloudWatch pour les enquêtes sur les incidents au lieu d’exporter les journaux vers des outils tiers, simplement en raison des limites de requêtes antérieures, pour le SIEM, l’analyse de sécurité, la conformité ou les environnements multicloud, des plateformes telles que Datadog, Splunk ou Elastic offrent toujours une visibilité multiplateforme plus étendue, une corrélation avancée et des fonctionnalités de gouvernance à long terme que CloudWatch ne couvre pas entièrement », a fait valoir M. Jain.
Pas d’économies directes sur les coûts du cloud
M. Jain estime également que cette mise à jour ne permettra pas de réaliser des économies directes importantes sur les coûts du cloud, notant que la tarification de CloudWatch Logs Insights est principalement basée sur le volume de données analysées plutôt que sur le nombre de résultats renvoyés. « Au contraire, le principal avantage devrait provenir de l’efficacité opérationnelle et d’une résolution plus rapide des incidents », a-t-il déclaré. « Si les équipes SRE passent moins de temps à se heurter aux limites de requêtes, à relancer des recherches et à assembler des journaux, elles peuvent identifier les problèmes beaucoup plus rapidement. Pour les applications des grandes entreprises, une réduction du temps d’investigation des pannes de 15 minutes à 2 minutes peut se traduire par une valeur opérationnelle et commerciale significative », a reconnu M. Jain. Selon AWS, les utilisateurs professionnels peuvent limiter le nombre d'enregistrements renvoyés par une requête à l'aide de la commande « LIMIT », après avoir défini des limites maximales pour les requêtes via la console Amazon CloudWatch ou l'interface de ligne de commande AWS (AWS CLI). Cette fonctionnalité est désormais généralement disponible pour tous les utilisateurs dans toutes les régions AWS.