Retour

Chronique Tech - Monitoring

Le monitoring des importations de données : un investissement nécéssaire

Bonne nouvelle ! L'équipe technique de Stackadoc a terminé l'importation et la mise en place du flux de données en provenance de l'Assemblée Nationale et du Sénat !

Mais pour maintenir constant ce flux de données, il nous a fallu mettre en place un système complexe de surveillance de ces flux. Nous revenons en détail sur l'infrastructure mise en place dans ce document.


Pourquoi monitorer nos flux de données Open Data ?

Des programmes hétérogènes

Les logs d’importation de données dans les indexes ElasticSearch sont susceptibles de provenir de sources très différentes les unes des autres.

Cette hétérogénéité provient de la distribution des codes dans le temps, et aux différents langages de programmation utilisés pour le scrapping, l'encodage et l'insertion des données dans notre base.


30 minutes par jour

Au fur et à mesure des développements, après la mise en production de plusieurs scrappers, le temps de vérification et de monitoring des importations augmente constamment. A tel point qu’un minimum de 30 minutes par jour était nécéssaire pour vérifier la bonne importation des données dans nos indexes.


Toujours plus

Pourquoi ne pas utiliser tous les « gadgets » mis à notre disposition ? Aujourd’hui nos containers Docker interagissent avec nous sur Slack pour nous dire quand les flux d'importation ne sont bons !


Notre architecture

Nous avons actuellement 12 containers docker qui opèrent en parallèle pour ingérer et traiter les données en provenance de l’Assemblée Nationale et du Sénat. Ils sont aussi responsables des enrichissements de données, des analyses et de la récupération des données externes. Cette conception modulaire permet d’isoler chaque type de données, ainsi lorsque qu’un fournisseur de données modifie les accès ou le format de ses données, seul un container est impacté.


Néanmoins nous avons implémenté les différents scrappers à des temps différents ce qui explique qu’ils ont une structure de logs plus ou moins différents. Le point commun à ces 12 containers est qu’ils redirigent les logs vers un fichier texte.


L’objectif ici est de présenter les outils Filebeat, Kibana et Watcher qui nous ont permis de monter l’infrastructure de monitoring de notre plateforme avec beaucoup de fluidité.


FILEBEAT : notre agent de transferts de logs


Filebeat est très facile à mettre en oeuvre et à déployer dans le Cloud. Nous avons embarqué une image Docker Filebeat dans chaque scrapper en production. Avec quelques variables de configurations spécifique à notre environnement Elastic-Heroku, les logs du container se déversent directement dans un index, des tableaux de bord préconfigurés sont même disponibles si votre structure de log est reconnue.

Plus sur Filebeat ici : https://www.elastic.co/fr/beats/filebeat

WATCHER : un outil KIBANA pour les alertes


Une fois les logs se déversant dans notre index, il s’agit de classer les logs en fonction de leur niveau d’information. Grace à Kibana nous pouvons faire des requêtes avancées. Ainsi nous identifions les logs erreurs/neutres/succès (en terme d’importation). Le langage de requête Lucene a permis de requêter des logs de structure différentes et les classifier.
Watcher est l’outil interne à Kibana permettant de lever des alertes.


Une fois la fréquence, et la requête établie nous pouvons exécuter Watcher qui fera tourner la routine. Dès lors qu’un log d’erreur arrive, une notification Watcher est levée, et ce toutes les 10 minutes.

Plus sur Watcher ici : https://www.elastic.co/guide/en/kibana/current/watcher-ui.html

 

SLACK : le fil d'ariane 


Que vient faire Slack dans un bulletin sur le monitoring de logs ?
Une fois Watcher configuré, la plus value était déjà là mais il manquait la dimension ‘diffusion de l’information’. En effet parfois les logs monitorés sont porteurs de lourdes conséquence pour la qualité de service de la plateforme. Pour cette raison il faut que ce type d’information soit diffusée automatiquement et rapidement aux équipes en charge de réagir à ce type d’évènements.
Quoi de mieux qu’un espace Slack qui relaie toutes les erreurs de nos scrapers en temps-réel ?
Watcher permet d’alerter non seulement via des notifications mais également en se connectant à un espace Slack grâce à son webhook. Une rapide configuration des credentials dans le fichier conf «yml» et les alertes tombent dans l’espace Slack !

Il ne reste plus qu’a inviter les bonnes personnes à cet espace.

Pour ceux qui n'utiliseraient pas déjà Slack  : https://slack.com/intl/fr-fr/

Bon à savoir

Conservez les crédentials à l’abri dans l’elasticsearch keystore: pratique et sûr. Ainsi faites référence au keystore dans les fichier conf plutôt que de les hard-coder.

Pour ne pas polluer les discutions d’équipe, mieux vaut créer un nouvel espace slack que seules les parties prenantes rejoindront.

Ressources utiles

La documentation Filebeat :

Exemples de construction d’alertes Watcher:

Comment trouver le webhook de son espace Slack ? (être admin)

©2020 - Stackadoc Developpement. Tous droits réservés.