e-Xpert Solutions Lausanne
Auteur : Gilliek
Date de publication : 9 novembre 2020 - Dernière mise à jour : 22 décembre 2021
Un cas typique d’usage du module LTM d’un F5 BIG-IP est de publier des applications derrière un virtual server qui va faire du reverse proxy. Les utilisateurs accèdent ainsi à l’application à travers ce virtual server. Un certain nombre de facteurs (réseau, firewall, crash applicatif, etc.) peuvent causer une interruption du trafic entre le virtual server et l’application empêchant ainsi l’accès au service.
Ce use-case illustre les possibilités de monitoring et de reporting de notre solution pour le module LTM de F5 BIG-IP. Sur le virtual server, il y a généralement un monitor qui est configuré afin de s’assurer que l’application ou le service publié derrière le virtual serveur est disponible. En cas de changement d’état, un log est émis. L’idée de ce use-case case est donc d’une part de s’appuyer sur ces logs afin de trapper quand un virtual server devient indisponible et quand il devient disponible à nouveau. Et d’autre part, d’utiliser les iControl (API REST) du BIG-IP afin d’enrichir ces logs et ainsi afficher plus d’information à l’utilisateur.
Nous allons créer les éléments suivants :
IMPORTANT : Le Use-Case décrit ici, comme tous nos use-cases, est packagé et fourni prêt à l’emploi. Cet article décrit l’implémentation à but purement informatif.
Collecte et visualisation du statut des Virtual Servers
La première étape est celle où on va récupérer de façon régulière le statut des virtual servers du BIG-IP. Pour cela, on va créer un workflow qui s’exécute toutes les 2 minutes (par exemple) suivi de l’exécution d’un Insight Script qui va tout simplement envoyer une requête sur l’API REST du BIG-IP et stocker le résultat dans un KV store (Key/Value store) sur Insight :
A partir du KV store contenant le statut on peut facilement créer notre dashboard :
Détection d'un changement d'état
Pour la suite, nous allons définir un workflow d’alerting qui va se charger de trapper les logs de changement d’état d’un virtual server en temps réel, c’est-à-dire qu’à chaque fois qu’un log arrive dans la solutions, il va être envoyé dans ce pipeline :
Regardons de plus près à quoi ressemble notre requête qui va être exécutée dans la première étape du pipeline :
Le log reçu du BIG-IP a le format suivant :
La première partie de notre query consiste à filtrer les logs afin qu’il ne reste plus que ceux contenant « SNMP_TRAP: Virtual ». Ensuite, afin de pouvoir utiliser ce log, nous avons besoin d’extraire les informations de celui-ci. Pour ce faire, nous utilisons une expression régulière :
Finalement, nous allons enrichir le log à partir des informations récupérées précédemment via l’API à l’aide du filter « map » qui va aller effectuer un lookup dans le KV store.
Une fois les logs filtrés, les champs extraits et enrichis, nous avons un bloc conditionnel dans notre workflow :
Ce bloc nous permet de gérer les deux statuts possibles récupérés dans le log: available et unavailable. Ensuite, il suffit d’envoyer un e-mail en fonction de chaque statut, par exemple :
Afin de fournir plus d’information dans l’e-mail, nous y injectons les informations extraites précédemment.
Ensuite, nous avons besoin de deux scripts: Le premier pour le cas où le virtual serveur passe en « unavailable », nous avons besoin de mettre l’information de côté pour pouvoir calculer le downtime par la suite. Et le deuxième, pour quand le virtual serveur repasse en « available » afin de calculer le downtime.
Dashboard de l’indisponibilité des virtual servers
Maintenant que la pièce principale du puzzle est en place, le workflow d’alerting qui va détecter l’indisponibilité du virtual server et alerter, nous allons offrir aux utilisateurs de la visibilité :
Ce dashboard liste toutes les indisponibilités détectées au cours de la période de temps sélectionnée. Il offre également des informations concernant la durée de ces indisponibilités, permettant ainsi d’évaluer l’impact de celui-ci sur l’application ou le service correspondant.
Rapport hebdomadaire
Finalement, nous pouvons maintenant configurer la génération d’un rapport hebdomadaire. Pour cela, il nous suffit juste de créer un rapport qui reprend le dashboard précédemment présenté :
Avec les configurations suivantes :
Le rapport sera généré tous les lundis à minuit, à partir de notre dashboard avec un intervalle de temps de 7 jours.
Le rapport généré sera envoyé par e-mail, mais il est également possible de le consulter directement depuis l’interface :
Ce use-case présente une brique de base à la mise en place d’un monitoring efficace de la disponibilité des virtual servers. Grace aux fonctionnalités de notre solution d’analytics pour F5, il est possible d’aller encore plus loin. Voici quelques améliorations pouvant être apportées :
Dans ce use-case, nous avons implémenté toute une série d’outils qui va permettre aux utilisateurs de la solution d’avoir une meilleure visibilité sur l’état de santé des virtual servers déployés sur les BIG-IP et par conséquent sur les applications accédées à travers celui-ci. De plus, les dashboards et le rapport qui ont été mis en place vont permettre d’identifier rapidement les virtual servers posant le plus de soucis. Ainsi il sera possible de prendre des mesures avant qu’il y ait un impact auprès des utilisateurs du service.
N’hésitez pas à nous contacter via le formulaire de contact pour avoir plus d’information concernant ce use-case ou sur la solution.
Events
Archives