La surveillance des logs évolue pour ne pas faire exploser les coûts
Qu’il s’agisse d’ajuster la tarification en fonction de la fréquence d’accès ou de réduire le volume des logs envoyés par l’infrastructure IT, de nouvelles approches de surveillance permettent de gérer le coût des applications cloud natives.
La surveillance des logs est plus critique et plus lourde à mesure que les applications natives du cloud se généralisent. Cependant, des modifications subtiles de leur gestion et des outils d’infrastructure distribués peuvent être très rentables.
Pour de nombreuses entreprises, l’observabilité est devenue un moyen incontournable de dépanner des applications composées de microservices complexes et des infrastructures gérées par logiciel. En effet, les développeurs doivent passer au peigne fin les logs des systèmes pour comprendre et réparer les problèmes rencontrés dans le code des applications. Comme les ressources IT deviennent de plus en plus éphémères (cf. les fonctions programmatiques, par exemple), les données issues des logs permettent de collecter des informations plus précises sur chacun des composants des SI.
Les logs font grimper très rapidement les factures
Toutefois, à mesure que les applications passent de monolithes installés sur un seul serveur ou une paire à haute disponibilité, à des microservices qui reposent sur plusieurs couches virtualisées, le volume de logs généré par les systèmes peut rapidement devenir ingérable. Essayer de conserver un historique pour l’examen des incidents, les enquêtes ou l’analyse des causes profondes aggrave encore le problème.
« Vous n’êtes jamais à court de logs », déclare Bob Zeller, ingénieur et fondateur de Good Eggs, un service de livraison d’épicerie à San Francisco. « Nous avons remarqué que nous dépensions énormément pour la gestion des logs ».
L’entreprise, qui emploie une trentaine d’ingénieurs, a vu son volume de logs passer de 10 Go par jour en 2015 à plus de 200 Go par jour en 2018. Résultat, la facture annuelle a atteint environ 160 000 dollars, une somme empochée par Sumo Logic, un éditeur de solutions de monitoring.
« À l’époque, c’était la deuxième facture après celle d’AWS », assure Bob Zeller.
La société a pris des mesures en 2018 pour réduire la quantité de données qu’elle stockait sur Sumo Logic. Elle a mis en place un système de transfert des logs à un ensemble de modules AWS S3 autogérés, qui envoyait uniquement les informations nécessaires au « débugage ».
« Nous avons dû renoncer à certaines choses, comme les recherches programmées qui profitaient du fait que nous transmettions tous nos logs à Sumo, mais c’était un bon compromis pour nous. »
Bob ZellerGood Eggs
« Si les ingénieurs souhaitaient effectuer une requête dans Sumo Logic, ils devaient dire à un chatbot quelle était l’application concernée et la période qui les intéressait », témoigne Bob Zeller. « Nous avons dû renoncer à certaines choses, comme les recherches programmées qui profitaient du fait que nous transmettions tous nos logs à Sumo, mais c’était un bon compromis pour nous ».
Fin 2019, cependant, Good Eggs a participé à la version bêta d’un nouveau niveau de tarification Sumo pour stocker les données peu utilisées. Il coûte environ un dixième du prix de 2 à 3 dollars par gigaoctet, qui est le tarif habituel du service Sumo Logic.
« Lorsque nous diffusions en continu tous nos logs, nous tenions pour acquis que tout était à notre disposition à la demande, à tout moment. Chercher les informations concernant l’application et la période à évaluer, avant d’effectuer une analyse, est une perte de productivité », avertit Bob Zeller.
La possibilité d’accéder aux données les moins fréquentées à un prix inférieur supprime l’étape supplémentaire qui consiste pour les développeurs à affiner leur recherche et à charger les bonnes données dans Sumo Logic à partir de S3. Le système est encore en version bêta : Bob Zeller ne peut pas encore comparer le coût de la solution avec la méthode reposant sur S3. Cependant, il espère qu’elle permettra de reprendre l’envoi de tous les logs vers Sumo Logic à un coût équivalent de son installation actuelle, moins pratique.
Le fondateur de Good Eggs espère que Sumo Logic développera des outils qui permettront aux ingénieurs d’évaluer si une requête vaut la peine d’être traitée à l’avance. Les représentants de Sumo Logic ont déclaré que cette fonctionnalité sera incluse dans le produit plus tard dans l’année.
HAProxy 2.0 simplifie le suivi des logs et améliore l’observabilité
DoubleVerify est un fournisseur de services de vérification des publicités dont le siège est à New York. Il a commencé il y a trois à remplacer les répartiteurs de charge matériels de F5 par des systèmes logiciels HAProxy. Le but était de réduire les coûts liés aux équipements. Il a fallu des efforts considérables pour obtenir une infrastructure définie par logiciel qui réplique les fonctionnalités disponibles au niveau du matériel. Il s’agit de gérer des milliards de requêtes web de l’entreprise par jour.
« Nous remplacions les dispositifs de réseau dédiés par des équilibreurs de charge logiciels. »
Wally Barnes IIIDoubleVerify
« Nous remplacions les dispositifs de réseau dédiés par des équilibreurs de charge logiciels, ce qui n’avait pas vraiment été fait à ce moment-là, du moins pas à cette échelle », a déclaré Wally Barnes III, ingénieur SRE chez DoubleVerify. « La plupart des gens mettent des serveurs web derrière HAProxy et Nginx – le remplacement des dispositifs réseau signifiait que je devais plonger dans les tripes de HAProxy pour déterminer ses capacités, les réglages que nous pouvions faire ».
La mise en production des répartiteurs de charge HAProxy a également nécessité de comprendre comment tirer parti d’un nouveau groupe de systèmes élastiques au lieu d’un jeu d’équipements matériels. Une telle opération demande de consulter de vastes quantités de données de surveillance générées les services HAProxy.
« Ce sont des milliards de requêtes par jour. Comment traiter tous ces logs ? »
Wally Barnes IIIDoubleVerify
« Ce sont des milliards de requêtes par jour. Comment traiter tous ces logs ? C’était quelque chose que nous devions résoudre. Nous avons vite découvert que nous ne pouvions pas tous les récupérer. Il n’y avait pas assez de place pour les conserver », affirme Wally Barnes.
Une première tentative de collecte de logs depuis l’un des quatre centres de données à New York a atteint les limites de transfert de données du logiciel d’analyse Splunk en quinze minutes, se rappelle-t-il.
La société a pris ses propres mesures pour envoyer des données de log partielles d’une partie de ses instances HAProxy à Splunk avec une combinaison de collecte de données syslog et un système de transfert de pub/sous-pub RabbitMQ. Mais HAProxy 2.0, sorti en juillet 2019, comprend des fonctions natives d’échantillonnage des logs, qui ont allégé la charge de gestion et amélioré sa visibilité du comportement des load balancers.
DoubleVerify vient de terminer les premiers tests de validation de la nouvelle version.
« Maintenant, je peux augmenter la quantité de logs et recevoir des informations en provenance de tous les systèmes, mais pas autant qu’auparavant. »
Wally Barnes IIIDoubleVerify
« Maintenant, je peux augmenter la quantité de logs et recevoir des informations en provenance de tous les systèmes, mais pas autant qu’auparavant », constate Wally Barnes. « Cela me donne une vision plus globale de ce qui se passe et permet aux développeurs de mieux comprendre les systèmes ».
L’approche fragmentaire de la société lui a parfois fait manquer des événements depuis les serveurs sur lesquels elle collectait des données. Avec HAProxy 2.0, l’ingénieur espère éliminer ces angles morts.
« Les résultats que nous avons pu voir étaient assez révélateurs de ce qui se passait, mais nous ne pouvions pas voir toutes les requêtes » témoigne-t-il. « Parfois il y a une explosion de trafic vers un système et cela nous permet de le détecter ».
