Il est essentiel de surveiller des applications dont l'architecture est chaque jour plus complexes : voici comment le réaliser avec la LogDataPlatform d' OVHCloud qui collecte et indexe efficacement des données très diverses pour les synthétiser dans des tableaux de bords et alertes.A travers cet article nous allons voir comment mettre en place un monitoring complet de ses logs, aussi diversifiés soient-ils, pour répondre aux questions de Performance, Sécurité, Compréhension des usages, Optimisation des infrastructures.
Le patrimoine applicatif des entreprises est confronté à une double croissance, qui justifie à elles seules d'avoir une approche industrielle de la surveillance de leur bon fonctionnement :
➡️ Le nombre d'applications déployées,
➡️ La complexité des architectures utilisées.
Concernant ce deuxième point, les applications sont de moins en moins monolithiques et sont donc l'assemblage complexe de multiples services dont le schéma ci-dessous en donne un aperçu.
Le monitoring des différents types de logs (applicatif, système,...) est donc capital dans une architecture complexe, il nous permet d'être rassuré sur la santé de notre système SI en offrant un point central qui donne des enseignements en un coup d'œil et éviter des investigations fastidieuses, d'être réactif en cas d'anomalie et de garantir :
✅ La performance : Le monitoring des logs permet d'identifier les goulots d'étranglement, les erreurs de configuration et les problèmes de performances. Cela permet d'optimiser l'ensemble du système pour des performances maximales.
✅ La disponibilité : La détection rapide d'erreur permet d'être réactif et de réduire le temps d'arrêts des services
✅ La sécurité : la surveillance des logs permet de détecter les activités suspectes ou les violations de sécurité. Cela contribue à renforcer la sécurité de l'infrastructure en identifiant les menaces potentielles.
Par la suite, nous verrons que le format des logs envoyés vers la Log Data Platform est important afin d'exploiter au maximum les informations qu'elles contiennent.
Pour que les logs soient indexés dans la Log Data Platform, il faut qu'ils soient envoyés en respectant un protocole/format précis. Voici, un tableau tiré de la documentation de OVHCloud affichant les protocoles/formats supportés par la Log Data Platform :
En fonction du protocole/format de vos logs et du protocole réseau choisi, il faudra les envoyer vers le port associé.
❓❓ Que faire si mes logs ne respectent aucun de ces protocoles ou formats ❓❓
2 solutions :
Instancier un « Outils de collecte » OVHCloud (un Logstash) qui va permettre de détecter le format de vos logs via des filtres Grok.Configurer un processeur Filebeat afin d'enrichir la structure de données envoyées par Filebeat. Parmi ces processeurs il y a le dissect qui réalise le même traitement que Logstash.La différence entre Logstash et le processeur dissect est que ce premier permet l'utilisation d'expressions régulières . Nous discuterons plus en détail de la solution avec les processeurs.Voyons maintenant comment les logs sont collectés.
Collecte des logs avec Filebeat
Composant de la suite Elastic , Filebeat ( https://www.elastic.co/fr/beats/filebeat ) est un agent léger et complet qui permet facilement d'envoyer les logs au fil de l'eau vers la Log Data Platform .Sa simplicité d'utilisation permet une prise en main rapide⏱️. Pour envoyer les logs nous pouvons utiliser les modules mis à disposition par Filbeat ou configurer manuellement des entrées qui permettent de regrouper plusieurs fichiers de logs, d'y apporter un traitement si nécessaire puis de les envoyer vers la Log Data Platform.
L'utilisation de variables : On utilise ici ... qui fait référence à une de nos variables définies dans notre base de données PostgreSql.
Quelques fonctionnalités intéressantes de Filebeat
Filebeat offre la possibilité de parser et d' enrichir les logs avant de les envoyer à la plateforme grâce à différents processeurs. Nous allons voir deux cas d’utilisation intéressants du processeur.
DBT propose deux manières de rédiger des tests fonctionnels :
Des tests spécifiques qui sont des requêtes SQL détaillées qui recherchent à vérifier une ou plusieurs conditions particulières.
Des tests génériques qui sont des requêtes SQL que l'on variabilise et qui prennent comme arguments la colonne et le nom de du modèle par exemple.
DBT propose également des tests unitaires de non régression qui comparent les résultats d'un fichier du projet et le résultat d'une requête.Tous les tests sont écrits sur un fichier de configuration à l'intérieur du modèle. Ils peuvent s'écrire assez rapidement et réduire considérablement la quantité de code à écrire pour les développeurs.
L'intégration de DBT au sein du projet Bestway a été simple et rapide. Les développements étant en SQL, cela a permis une montée en compétence rapide sur l'outil sans pour autant que nous soyons limités par le langage grâce à l'utilisation du Jinja. En combinant avec Flask et Cloud run, nous avons pu automatiser les exécutions et l'intégrer facilement à notre architecture.La simplicité de tester et de documenter le code s'avère très utile pour comprendre, expliquer et fiabiliser des requêtes SQL complexes et nombreuses.DBT est un outil efficace qui permet de se concentrer sur les développements à valeur ajoutée ce qui est satisfaisant.Il reste néanmoins un petit bémol : débugger une requête SQL de 500 lignes est plus rapide avec DBT mais cela reste tout de même un processus très chronophage que l'on aurait moins en utilisant d'autres langages.Pour en savoir plus sur DBT et son fonctionnement : https://docs.getdbt.com/
Steven JAMAN , Ingénieur Cloud & Data @ Novagen
« Novagen, créateur de solutions Data innovantes pour développer votre Business. »
N'hésitez pas à nous contacter pour tirer le meilleur parti possible de vos données !
contact@novagen.tech
