Les choix techniques chez i-Run.

On est prêts à faire mille fois une requête, mais on n’aime pas faire les choses 1000 fois.

Le respect de ce mantra passe par l’automatisation (ansible, script, pipeline…) mais aussi par bien choisir ses outils au départ afin d’éviter certaines déconvenues (comme de devoir le changer rapidement).

Cet article, va vous présenter le process de décision technique en place dans l’équipe, comment on prend le temps de poser le besoin avant de déployer un outil, afin de trouver le plus adapté à nos usages.

Contexte

Jusqu’alors, notre équipe DevOps maintient une stack Elastic afin de faciliter leurs consultations.

En cours de restructuration de nos infrastructures, nous en avons profité pour ré-évaluer nos besoins et en particulier, le choix de notre stack de logs. La mise à l’épreuve de notre stack face de nouveaux outils disponibles s’imposait alors.

Le plan

Concertation

Une concertation, avec l’ensemble des intervenants concernés, est organisée pour faire le point sur nos besoins présents et futurs en matière de logs.

Les parties identifiées sont donc :

• Les DevOps
• Les Administrateurs système
• Les Développeurs
• Les Fonctionnels qui analysent les problèmes le nez dans les logs applicatifs

Les besoins

• Open-source
• Plateforme GNU/linux
• Pérennité (taille de la communauté, activité sur le projet)
• Stabilité de la solution
• Maintenabilité
• Stockage et filtrage des logs par environnement, application, niveau…
• Facilité d’utilisation pour les développeurs (visualisation, recherche)
• Sécurité (implémentation ssl, contrôle d’accès)
• Robustesse (scalabilité, haute disponibilité)

Les candidats

Grace à une veille technologique du turfu et une assiduité hors du commun de tous nos collaborateurs, deux solutions nous apparaissent comme crédibles :

• ELK/EFK, solution fiable, éprouvée et actuellement en place dans notre infra.
• Grafana Loki, le nouveau qui promet simplicité, efficacité.

L’étape suivante sera l’établissement d’un POC afin de déterminer laquelle de ces solutions répond le mieux aux besoins établis précédemment.

Le déroulement du poc

Élaboration du cadre

Puis tout ça prend consistance dans un ticket qui contient :

• La synthèse de nos besoins
• Le cadre (infrastructure nécessaire, estimation du temps nécessaire)
• Les notes de déploiement (limites, avantages de la solution, éventuelles difficultés rencontrées…)

Ce ticket a ensuite été attribué à la personne en charge de son élaboration.

Les membres de l’équipe peuvent ainsi suivre facilement l’évolution du POC grâce aux notes contenues dans ce ticket et les labels qui permettent rapidement de visualiser l’état (Todo, Doing, Done, Blocked) sur les boards de Gitlab.

La solution de la stack Elastic est déjà en place et en dehors de quelques mises à jours, cela ne nécessite pas grand-chose.

La prise d’information

Avant de commencer, on se documente un peu sur nos candidats :

• La documentation d’installation (officielle)
• Les préconisations de l’éditeur (bonnes pratiques)
• Les retours d’expériences de la communauté.

Une courte description de Loki

C’est un outil de stockage & consultation de log (Grafana loki sur google c’est mieux !) répondant aux principes KISS. Il est scalable horizontalement, avec deux types d’architectures (au choix) : microservice ou monolithique.

Prévu pour tourner sur du conteneur/pod, avec l’objectif d’être simple à maintenir et réduire les coûts de stockage.

Son outil de visualisation est Grafana, c’est versatile, connu, complet, facile d’utilisation.

L’agent Promtail est chargé de récupérer les logs, il est plus limité qu’un Logstash mais aussi plus léger.

Partie technique

Un docker sur une VM dédiée nous procure un environnement rapidement. Le reste se passe dans un projet ansible, contenant les rôles suivant:

• Loki
• Grafana
• Promtail

Enfin, il nous suffit d’ouvrir un flux à partir d’un Logstash|syslog déjà en place, et d’importer les logs réels de la prod par le biais de Promtail.

L’utilisation massive et quasi exclusive d’Ansible dans nos infrastructures, permet des déploiements versionnés, sauvegardés, reproductibles et facilement intégrables à notre CI.

Le bilan

Nous avons ensuite établis une réunion entre les différentes parties concernées par l’outil afin de mesurer les bons et mauvais cotés de chaque solution.

En voici, un résumé..

Au final, Grafana Loki aura coché beaucoup de cases, mais que fait-il de mieux qu’elastic ?

• Le volume de stockage.

Elastic quant à lui, est plus rassurant sur :

• La pérennité : il bénéficie d’une activité, d’un historique d’utilisation en production, de la taille de la communauté pour lui.
• Il est plus complet et plus abouti.

Pour nous, Elastic reste le choix #Runstoppable, prometteur et versatile.

Lors de l'écriture de cet article, Loki manque de maturité, il est de loin le plus efficace sur le stockage mais reste très orienté administration système. Son usage par les équipes de dev et fonctionnelle demanderait trop d’ajustements.