Avez-vous ressenti ce moment de doute lorsqu’on vous a dit que vos nouvelles applications seraient hébergées dans le cloud ? Moi oui. À quel moment vous êtes-vous vraiment senti prêt à les gérer ?
Pour de nombreuses entreprises, prendre en charge l’exploitation d’une application hébergée dans le cloud est une réalité assez nouvelle, et les implications en termes d’organisation, de compétences et d’outils sont encore des sujets à traiter.
Au début, on n’a pas vraiment le choix. Le fournisseur de cloud propose ses propres outils, que l’intégrateur qui vous accompagne est formé à utiliser.
Du coup, les administrateurs se retrouvent avec au moins deux outils de monitoring : celui auquel ils sont habitués et avec lequel ils travaillent tous les jours et celui qui ne couvre que ces nouvelles infrastructures. Chaque fois que vous ajoutez un nouveau fournisseur… vous ajoutez aussi un nouvel outil !
Et c’est là que leur quotidien devient vraiment compliqué et qu’un mécanisme d’intégration offrant une vision consolidée de l’ensemble du système d’information et de tous ces outils devient indispensable.
PRTG propose depuis longtemps des capteurs spécifiques pour les environnements cloud tels qu’AWS et, plus récemment, Azure. Mais comme pour le reste de l’infrastructure, il y a toujours ces fameux 20% de besoins spécifiques qui restent à couvrir.
Si PRTG est par nature une solution de monitoring d’infrastructure ouverte, c’est parce qu’il existe depuis longtemps un besoin de capteurs personnalisés. Il est donc logique de continuer à utiliser PRTG comme agrégateur de toutes vos métriques, y compris celles de ces nouvelles infrastructures cloud.
La solution évidente consiste à utiliser des capteurs REST ou HTTP qui peuvent requêter un endpoint et analyser son contenu. Il s’agit d’une solution élégante car elle n’est pas très gourmande en ressources et convient à de nombreux types de ressources web.
Mais elle ne couvre pas tous les cas. L’authentification nécessite parfois la génération d’un jeton de session, et la collecte de métriques à partir d’une ressource nécessite souvent de solliciter plusieurs endpoints dont les réponses doivent être agrégées.
La solution consiste alors à écrire et maintenir un script PowerShell ou Python. Cela permet de résoudre tous les problèmes évoqués ci-dessus.
Bien sûr, il faut avoir le temps et les compétences nécessaires pour le faire. Vous pouvez également trouver des scripts prêts à l’emploi, gratuits ou payants, auprès de fournisseurs. Il est aussi parfois difficile de gérer la charge d’exécution de ces scripts.
Le fait est que ces scripts doivent être déployés sur chaque sonde où ils sont nécessaires et qu’ils doivent être mis à jour aussi souvent que les API des fournisseurs de cloud évoluent.
C’est sur ce point que nous souhaitons attirer votre attention. Contrairement aux API des composants internes tels que votre baie de stockage ou votre orchestrateur de réseau, les API des fournisseurs de cloud computing évoluent constamment, ce qui rend la maintenance de ces scripts assez fastidieuse.
Comment pouvez-vous combiner les avantages de ces deux solutions tout en évitant leurs inconvénients ?
Senhub décharge l’équipe IT de la complexité de l’écriture, de la maintenance, du déploiement et de l’exécution des scripts et rend l’intégration de ce nouveau capteur aussi facile que celle d’un capteur natif.
Senhub peut être configuré via son interface graphique ou ses API REST par votre outil d’automatisation.
Une fois la configuration en deux étapes effectuée (voir l’exemple ci-dessous), Senhub vous fournit un endpoint unique que vous pourrez configurer dans un capteur HTTP Data Advanced.
Chaque fois que le endpoint est sollicité, Senhub interroge la ressource cloud et répond à votre plateforme dans le format JSON spécifique à PRTG. Il n’y a donc plus rien à faire, si ce n’est de définir les seuils qui vous conviennent.
Regardons deux exemples simples de la mise en œuvre de la solution et de ses avantages.
Exemple 1: Intégrationde l’outil APM
Au-delà du monitoring de l’infrastructure technique il y a la qualité de service perçue par l’utilisateur. Pour couvrir cet aspect clé de ce qu’est la qualité de service informatique en 2022, nous utilisons des outils APM comme Ekara d’ip-label ou Synthetics de New Relic pour nous mettre à la place des utilisateurs. Nous mesurons très précisément les temps de réponse et vérifions que l’application fonctionne correctement.
Concrètement, l’outil APM exécute régulièrement un scénario utilisateur (Scenario) ou collecte les métriques de chaque transaction utilisateur pour chaque connexion (Real User Monitoring).
En connectant votre outil APM à PRTG, nous enrichissons le cockpit des administrateurs avec des informations cruciales. Senhub y parvient par un processus très simple en deux étapes :
La première étape consiste à fournir à Senhub certaines informations telles que les informations d’identification et les paramètres :
Senhub enregistre et stocke en toute sécurité les informations d’identification nécessaires pour se connecter aux ressources cloud ciblées. Lorsque ces informations d’identification sont modifiées, il n’est pas nécessaire de reconfigurer tous les connecteurs, mais uniquement le vault.
Lors de l’instanciation d’un connecteur, plusieurs paramètres sont souvent nécessaires. Le premier est généralement le vault à utiliser. Ensuite, en fonction du connecteur, vous pouvez choisir plus ou moins de métriques à collecter.
La deuxième étape consiste à obtenir le endpoint de l’instance et à le configurer dans un capteur HTTP Data Advanced.
La troisième étape est, eh bien, il n’y a pas de troisième étape sauf pour intégrer ce tout nouveau capteur dans votre plateforme PRTG !
Exemple 2 : métriques du Service Bus Azure
Être exhaustif dans le monde du monitoring IT : c’est compliqué.
Il est impossible de développer et de maintenir des milliers de capteurs pour répondre aux besoins spécifiques de chaque administrateur. De même, les APIs renvoient parfois une pléthore d’informations qui ne peuvent pas toujours être regroupées au sein d’un même capteur, surtout si l’on applique la recommandation de Paessler de ne pas dépasser 50 canaux.
Senhub complète efficacement PRTG pour ces besoins spécifiques.
Par exemple, dans les architectures applicatives récentes, les développeurs utilisent les composants Azure Service Bus, qui ne sont rien d’autre que les tuyaux par lesquels les applications échangent des données entre elles. Quand nous disons « échange », nous entendons « file d’attente » et gestion des abonnements entre applications. Nous comprenons que ce bus de service est un composant crucial de l’architecture logicielle. Senhub vous permet de collecter les métriques de chaque file d’attente dans PRTG.
Après cette première décennie de la « génération cloud », rares sont ceux qui disent encore « c’est l’avenir, tout doit aller dans le cloud ».
La vérité se situe, comme souvent, dans un juste milieu très pragmatique. Certaines parties du système d’information sont bien mieux gérées par des spécialistes dans le cloud, tandis que d’autres restent plus efficaces et hébergées bien au chaud dans votre propre centre de données.
Le seul véritable enjeu est de garder à l’œil et de consolider toutes les métriques sur le fonctionnement du système d’information en cloud, désormais hybride et multi-fournisseurs. Il est également essentiel de garder la fonction d’alerte centralisée et de ne pas compliquer la gestion des flux de travail de l’équipe IT.
Comme on dit souvent: » la confiance ne se délègue pas « . Si l’on suit ce précepte, il est bon de garder le contrôle de son outil de monitoring et de l’enrichir avec des connecteurs de nouvelle génération comme Senhub.
Matthieu Noirbusson
Co-fondateur et Président
Une preuve de concept vaut toutes les grandes explications. Vous pouvez essayer Senhub dès maintenant et sans engagement.
Créez simplement votre compte (aucune carte de crédit n’est requise) et commencez à surveiller vos assets Cloud avec votre propre outil de monitoring IT.
Si vous avez des questions, envoyez-nous un courriel à contact@senhub.io ou chatter directement avec un de nos helpers.