Mise à l’échelle de la surveillance de la télémétrie avec InfluxDB

Les attentes des utilisateurs pour les applications logicielles ne cessent d’augmenter. De nos jours, on s’attend à ce que les services soient très fiables et fonctionnent bien 24h/24 et 7j/7. Tout type de temps d’arrêt va engendrer des utilisateurs frustrés et nuire à votre organisation à long terme.

Un élément clé pour améliorer la fiabilité est la surveillance de votre application. Bien que la configuration du suivi fondamental soit facile, avoir la capacité de faire évoluer le suivi efficacement à mesure que le trafic vers votre service augmente est un défi important. Vous souhaitez également être exposé à toutes les métriques importantes pour votre service et avoir la capacité de rendre les données que vous collectez utiles et exploitables avec la possibilité de les interroger et de les analyser efficacement en temps réel à la demande.

En d’autres termes, il y a une énorme différence entre les problèmes que vous rencontrez en organisant quelque chose pour une tâche secondaire ou un système à petite échelle et le déploiement d’un suivi de télémétrie à grande échelle dans un environnement de production.

Une équipe de Cisco explore InfluxDB pour créer un exemple d’une architecture de suivi de télémétrie évolutive que d’autres entreprises avec des environnements de production massifs pourraient utiliser, sans avoir à repartir de zéro. Cette configuration a permis à Cisco d’augmenter sa consommation de données de télémétrie à 3 To par jour (ou environ 16 Go par minute). Au cœur de cette architecture se trouvent Cisco IOS-XR et InfluxDB.

Présentation de l’architecture de suivi de télémétrie Cisco

Il y a 3 composants principaux dans l’architecture de télémétrie de Cisco. La toute première partie est le matériel Cisco exécutant IOS-XR, qui produit les informations de télémétrie. La 2ème partie est le représentant du collecteur qui recueille ces informations, puis les envoie à l’élément final pour le stockage, ce qui est accompli avec InfluxDB.

InfluxData

Cisco IOS-XR

IOS- XR est le système d’exploitation utilisé par Cisco pour ses routeurs haut de gamme de classe opérateur tels que les routeurs de réseau des séries CRS, 12000 et ASR 9000. Par rapport à d’autres systèmes d’exploitation réseau, IOS-XR offre un meilleur calendrier, une bien meilleure évolutivité pour les grandes configurations matérielles, la possibilité d’installer des mises à niveau ou des spots pendant que le routeur reste en service, et de nombreuses autres fonctions qui ne sont pas facilement disponibles chez les concurrents.

Une fonction particulièrement pertinente est que IOS-XR offre un streaming intégré de données de télémétrie pour augmenter la présence sur le réseau et dispose d’API facilement disponibles pour que les ingénieurs agissent en fonction des informations de télémétrie.

Pour cette architecture, Cisco a diffusé des données à partir de 3 plates-formes IOS-XR différentes : le NCS 5500, l’ASR 9000 et le routeur de la série 8000. Cisco avait en fait configuré les gadgets pour fonctionner en mode d’appel sortant, avec des GPB (Google Protocol Buffers) auto-descriptifs, sur une connexion TCP. L’un des facteurs essentiels d’une architecture de suivi de télémétrie à cette phase est de s’assurer qu’elle ne collecte pas plus de données qu’elle n’en a besoin en termes de métriques globales ainsi que de fréquence de collecte de métriques.

Représentant du collectionneur

Les données de télémétrie du matériel IOS-XR ont été envoyées à un équilibreur de charge, qui a ensuite transféré les données entre 3 différents représentants du collecteur. À grande échelle, les systèmes de collecte monothread ne seront pas en mesure de gérer la quantité de données qui leur est envoyée. Les collecteurs multi-threads ont également des problèmes en raison du fait qu’ils publient tous dans la base de données avec des connexions séparées, ce qui produit un autre ensemble de problèmes.

Pour naviguer dans ces problèmes, Cisco a composé un agent collecteur multi-traitement, le code étant open source sur GitHub. Le processus principal du représentant du collecteur est découplé du pool de travail, qui analyse les données et les soumet à InfluxDB. Le processus principal inclut les données sur une ligne au fur et à mesure qu’elles sont transmises, puis envoie les informations de télémétrie au pool de travail par lots. Le représentant du collecteur a la capacité de gérer des gigaoctets de données par 2e, tout en restant fiable grâce à cette architecture découplée. Cela peut être vu dans le diagramme ci-dessous.

InfluxData

InfluxDB

La dernière pièce de l’architecture de télémétrie est InfluxDB, qui est utilisée pour stocker les données. Pour cette expérience, InfluxDB a été publié avec 2 nœuds d’information et 3 méta-nœuds pour former un cluster afin de prendre en charge une meilleure fiabilité et de meilleures performances.

InfluxDB est une base de données de séries temporelles spécialement conçue pour gérer des volumes massifs de temps. des informations estampées, ce qui en fait un ajustement parfait pour le cas d’utilisation du suivi de télémétrie de Cisco. InfluxDB fonctionne également très bien pour toute charge de travail qui nécessite de pouvoir composer de grandes quantités de données et de pouvoir interroger ces informations en temps réel. Les cas d’utilisation courants comprennent l’IoT, l’analyse et la surveillance des applications.

InfluxDB est open source et peut être déployé par vous-même dans votre infrastructure ou établi en quelques minutes à l’aide de l’offre cloud d’InfluxData, InfluxDB Cloud. InfluxDB Cloud est une plate-forme de données de séries temporelles flexible et entièrement gérée qui permet aux utilisateurs de démarrer rapidement, puis d’évoluer facilement pour répondre à leurs besoins. Les informations consommées peuvent être affichées à l’aide d’InfluxDB Cloud intégré dans les panneaux de contrôle et les informations peuvent être interrogées à l’aide de Flux, le langage de requête fonctionnel et composable d’InfluxData créé pour les charges de travail de séries chronologiques.

Pour le cas d’utilisation de Cisco, il a apporté quelques modifications à La configuration de base d’InfluxDB pour l’améliorer en fonction de leurs besoins particuliers. Le tout premier était de changer la taille de la mémoire cache (tampon) par défaut. En raison du fait qu’ils composaient les informations par lots à partir du représentant du collecteur, InfluxDB nécessitait une plus grande quantité de réserve de mémoire afin de continuer ces informations pendant leur écriture. Au niveau du cluster, Cisco a également choisi d’autoriser les écritures de répliques dans le désordre entre les nœuds. Cela a permis une plus grande polyvalence dans la relation entre l’ordre d’arrivée des données et les horodatages associés aux points.

La mise à l’échelle des données de télémétrie est une tâche difficile que de nombreuses entreprises ont en fait essayé de résoudre elles-mêmes. L’objectif de Cisco dans cette expérience était de fournir une architecture de plan que d’autres entreprises pourraient suivre afin qu’elles n’aient pas à transformer la roue pour leur propre cas d’utilisation. InfluxDB était un élément essentiel de l’option de Cisco en raison de ses performances, de sa facilité d’utilisation et de sa base de code source ouverte.

Sam Dillard est superviseur principal des articles IoT et entreprise chez InfluxData.

— Nouveau

Le forum technique offre un endroit pour découvrir et discuter des technologies commerciales émergentes avec une profondeur et une ampleur extraordinaires. Le choix est subjectif, basé sur notre sélection des innovations que nous pensons être importantes et du plus grand intérêt pour les lecteurs d’InfoWorld. InfoWorld n’accepte pas les supports marketing pour publication et se réserve le droit de modifier tout le matériel fourni. Envoyez toutes vos questions à newtechforum@infoworld.com.