eBay s’appuie sur Beats pour monitorer des pétacotets de logs chaque jour
Le moins qu’on puisse dire, c’est qu’avec 1,2 pétaoctet quotidien de logs et 5 millions de points de données d’indicateurs entrant par seconde, eBay a de quoi s’occuper ! Chaque jour, l’équipe de logging et de monitoring de la société d’e-commerce est confrontée à une tâche monumentale : collecter et visualiser l’ensemble de ces logs et de ces indicateurs. Et comme la plupart des entreprises, elle se sert d’un éventail d’applications (comme Hadoop ou MySQL pour ne citer qu’elles) pour alimenter différents cas d’utilisation dans les équipes.
C’est alors que les conteneurs ont fait leur apparition, proposant une nouvelle façon de déployer les applications. L’équipe a commencé à conteneuriser avec Docker et à effectuer le déploiement avec Kubernetes, qu’elle utilise aussi pour gérer le cycle de vie. Seulement, il restait une problématique de taille : l’évolution continuelle des applications et de l’environnement. Difficile de suivre le rythme ! C’est là qu’intervient Beats. Pour collecter et envoyer des logs de transfert et des indicateurs depuis Docker et Kubernetes, Filebeat et Metricbeat sont deux solutions idéales.
L’équipe souhaitait également voir les charges de travail au fur et à mesure de leur apparition. Avant que la fonctionnalité d’autodécouverte ne soit proposée dans Beats (nouveauté de la version 6.2), eBay a donc créé sa propre fonction : Collectbeat. Construite sur libbeat, cette fonction a découvert de nouveaux pods dans les clusters Kubernetes. Collectbeat s’est appuyé sur l’API Kubernetes pour mettre au jour les charges de travail, collecter des données et les enrichir, puis les envoyer sur le système de monitoring interne. Connu sous le nom de Sherlock.io, ce système a été conçu pour être flexible et s’adapter à l’adoption de nouvelles technologies.
L’aspect « collecte » ? C’est fait. Tournons-nous maintenant vers l’analyse et la visualisation. La collecte des données est utile uniquement si les utilisateurs d’eBay sont capables de les analyser avec des étiquettes communes. L’étape suivante consistait donc à trouver le moyen de baliser les données avec des métadonnées avant qu’elles ne soient transférées. Logique ! Vijay Samuel et son équipe eBay ont donc conçu un processeur appelé « add_kubernetes_metadata », qui reprend les messages des logs et les charges des indicateurs et y ajoute des métadonnées, comme le nom et l’espace de pod. Ce processeur est désormais disponible sur GitHub. Un exemple parfait qui montre la puissance des projets open source menés à bien par la communauté.
Bien sûr, eBay continue à évoluer. Et qui dit adoption de nouvelles technologies, dit plus d’applications, plus de logs et plus d’indicateurs. Concrètement, si l’on se penche sur la croissance de logging organique d’eBay, celle-ci est de 50 % d’une année sur l’autre. Question : comment la société fait-elle pour gérer des volumes croissants de données alors que les ressources sont limitées ? Une tactique consiste à mesurer les applications au niveau de l’hôte/du pool en créant des quotas basés sur le niveau et en appliquant des limites de rétention. Une autre méthode consiste à donner la priorité à des types spécifiques de données : d’abord les événements, puis les indicateurs donnant une visibilité opérationnelle, et enfin les logs. Pour vérifier la pertinence de l’ordre de priorité, rien de plus simple : basez-vous sur les calendriers d’événements et la fonction d’autodécouverte qui permet d’ajouter une pondération aux configurations.
Envie d’en savoir plus sur les outils et les stratégies de l’équipe eBay ? Regardez la présentation de Vijay lors d’Elastic{ON} 2018 pour avoir plus d’infos sur Sherlock.io et sur la façon dont eBay utilise Beats pour monitorer l’ensemble des données de ses clusters Kubernetes. Vous voulez en savoir plus sur l’utilisation de la Suite Elastic pour monitorer Kubernetes et Docker ? Découvrez notre webinaire Elastic Stack: Monitoring Kubernetes Applications with Beats.
