Une infrastructure de clusters elk

Ces derniers mois, j'ai mis en oeuvre une infrastructure de clusters elk ( Elasticsearch, Logstash, Kibana ) sur gcp ( Google Cloud Platform ) en mode IAAS.

Pour ce faire, j'ai utilisé le shell, gcloud, ansible et terraform. Le pilotage de l'infrastructure peut se faire en mode manuel via une VM distante ou de manière automatisée sur Jenkins en mode conteneur ou sur Airflow. un ordonnanceur ( basique ).

En terme d'architecture, elle est virtualisée via des VM et repose sur des groupes d'instance pour la résilience et l'auto-scalabilité. Entre chaque groupe d'instance, des LB de niveau 4 permettent de gérer l'élasticité de l'infrastructure.

Elle est en mode streaming et non en mode batch, elle s'appuie sur un groupe d'instances logstash, chaque filtre de chaque instance effectuant des pull sur une queue pubsub en amont où les logs arrivent, l'objectif  de cette architecture étant de mettre en place un puit de logs à moyen terme.

Le coeur de l'architecture multi-environnment est un cluster elasticsearch, un groupe d'instance pour les master nodes et un groupe d'instance pour les data nodes. Par précaution, les data nodes ne sont pas auto-scalables, l'ajout ou la suppression des noeuds automatisés nécessitant une décision préliminaire. Contrairement à la partie cliente scalable classiquement sur la CPU ( logstash, kibana ), la partie data est délicate à scaler ( métrique, performance disque et réseau, gestion de la taille des data pour la suppression, ... ).

Les groupes d'instances sont régionaux. Ainsi, pour le groupe d'instances des data nodes, ils sont répartis au mieux sur trois zones ( = datacenters ) dans un périmètre acceptable pour la latence réseau, pour ma part, vu le client, on a opté pour la Belgique. Cette configuration permet d'assurer une HA de qualité.

En terme de disponibilité, si vous avez une VM qui plante suite par exemple à un problème kernel, oui, cela peut arriver, elle est immédiatement relancée.

Les datas sont visualisables via une ferme de VM Kibana. Elles sont disponibles au réseau extérieur de Google via un reverse proxy.

Par rapport à l'on-premise, on change de monde. Plus de machines à acheter et à attendre, plus de compétences réparties sur n équipes fonctionnant en mode silo, plus besoin de tailler les infras sur des pics, plus besoin de régler les pbs en envoyant un ticket d'incident à n équipes ... et je ne vous parle pas de la mise en production !

Reste la problématique du prix. Sur ce plan, on joue sur la taille des clusters. En dev, on a des clusters minimaux et non pas des mono-noeuds ( groupe d'instance à une VM et à deux pour les master nodes ) ce qui permet d'avoir de l'élasticité en fonction des besoins. On a aussi des environnements éphémères, merci au cloud car désormais, supprimer et recréer un cluster est automatisable ( pour ma part, c'est fait à 90%, mais on pourrait aller plus loin ).

Et puis, avis personnel, si on comptait enfin tous les coûts cachés d'une infra on-premise ... Suivant les usages, les contraintes, la confidentialité des données, ... cela prendra du temps mais on va droit vers un environnement hybride. La voie est tracée !

Pour être complet, un plugin gcp permet de gérer les snapshots sur un bucket, un agent stackdriver permet de monitorer les VM et il est possible de le compléter avec un agent applicatif pour le suivi du cluster elasticsearch. La brique Stackdriver permet aussi de créer des dashboards, un système d'alerte ...

Pour ceux qui souhaitent approfondir le sujet, voilà un bon point d'entrée: construction d'une infra elk via Terraform