SystemDataRecorder

Défi

SystemDataRecorder est peut-être le package le plus complet et le plus simple pour la surveillance professionnelle des performances, l’analyse des performances, la dimensionnement des systèmes et la planification de la capacité dans des environnements professionnels exigeants. Il assure un enregistrement cohérent des données sur les systèmes et les appareils, permet l’accès aux données brutes et est conçu pour des analyses de séries temporelles. Cela peut ne pas sembler évident pour les non-experts en logiciels, mais il s’agit bel et bien d’une solution très puissante et attendue depuis longtemps à un problème persistant.

Bien que les ordinateurs existent depuis plus de 25 ans, il n’existe toujours pas de surveillance cohérente des performances entre les différents systèmes d’exploitation, car chaque environnement déploie son propre type d’outils de surveillance et de collecte de données. L’enregistrement cohérent des données sur différents systèmes d’exploitation est très difficile à réaliser sans acheter de logiciels séparés pour chaque environnement ou installer des solutions tierces. Même le format utilisé pour enregistrer les données varie d’un système à l’autre, faisant de la collecte et de l’analyse des données un cauchemar logistique.

En examinant de près les systèmes d’exploitation individuels, il est facile de constater que les méthodes d’obtention des données de performance sont en réalité similaires, mais des interfaces différentes sont utilisées avec une terminologie variable selon les fournisseurs et le type spécifique d’implémentation. L’idée derrière SystemDataRecorder est d’avoir plusieurs agents de collecte de données standard pour obtenir des métriques à partir des interfaces système afin d’exporter ces informations d’une manière unifiée. Pour les données exportées, un fichier texte brut peut être utilisé, en évitant tout format de fichier spécial, afin de rendre ce fichier utilisable par tout outil d’analyse disponible. De cette façon, un simple module d’enregistrement de données peut être utilisé pour le dépannage système, l’analyse des performances, l’analyse des pannes système, etc., et il est facile à activer sur un grand nombre d’hôtes dans un centre de données, et le système d’exploitation utilisé ne joue plus de rôle.

SystemDataRecorder était déjà disponible et se révélait être la lumière au bout du tunnel pour les systèmes Linux et Solaris, lorsque Redwerk a été contacté pour l’adapter également aux environnements serveur Windows 2003 et 2008. L’objectif était que ces serveurs fonctionnent avec des métriques similaires à celles de SystemDataRecorder pour Linux ou Solaris. La solution devait utiliser le moins de ressources système possible, être de petite taille et suffisamment robuste pour ne pas créer de surcharges système. Les enregistreurs devaient être implémentés en tant que services Windows, c’est-à-dire des applications natives pour les systèmes 32 bits et 64 bits. Toutes les données devaient être stockées dans un fichier texte brut.

Un défi supplémentaire consistait à porter sous Windows la capacité de surveiller la sortie des fichiers de données brutes. Pour chaque modification dans un fichier, un POST HTTP/HTTPS devait être envoyé à un système backend afin d’être analysé ultérieurement. Le logiciel devait être distribué sous forme de package logiciel adapté à une installation automatique sur Windows sans nécessiter d’interaction utilisateur.

Solution

Nos recherches ont montré qu’un service écrit en C/C++ recevant des dizaines de paramètres et écrivant des données dans un fichier utilise environ 2 Mo de RAM et seulement des ressources CPU mineures. Le même service en C# utilise un minimum de 6 Mo, et bien qu’il soit plus facile à développer, il nécessite également un minimum de .NET 2.0. Après analyse des avantages et des inconvénients, le code a été développé en C. De cette façon, nous avons réussi à minimiser l’abstraction et avons pu utiliser des routines simples pour accéder aux métriques du noyau Windows sans les surcoûts qu’aurait entraînés l’utilisation d’un langage orienté objet. Toutes les données du service ont été obtenues via l’API WMI.

Pour chaque enregistreur individuel, le paramètre clé à utiliser est le nombre de secondes entre chaque mesure. La valeur par défaut était de 60 secondes. Nous avons également trouvé une solution pour lancer avec un certain paramètre sous Windows. Les enregistreurs se lancent et écrivent des données dans leurs propres fichiers individuels. Après cette première étape, les fichiers sont rotatifs et compressés. Sous Linux ou Solaris, cela est implémenté à l’aide de cron, mais pour Windows, nous avons dû trouver notre propre solution.

Le processus de développement a été très solide et basé sur des étapes logiques de recherche, de test et de déploiement. Les tests ont inclus des problèmes très intéressants. Nous avons dû nous assurer que les enregistreurs fonctionnaient sans fuites de mémoire ni autres déviations pendant au moins 48 heures. Nous les avons même laissés fonctionner pendant le week-end, afin de pouvoir les surveiller correctement, en effectuant des tests d’acceptation appropriés.

Pour que le processus et la solution soient solides et complets, les situations d’urgence telles que les pannes de courant ou les redémarrages système non planifiés doivent également être prises en compte. Pour faire face à de tels scénarios, les services doivent redémarrer automatiquement au démarrage du système et continuer à enregistrer et stocker les données dans les fichiers de sortie.