ELK et le besoin de plus d'élan avec le logging

Lors du lancement de Simply Business, nous avons recherché les bonnes pratiques en matière de développement de technologie et de logiciels pour les incorporer à notre façon d'opérer. Mais la théorie des bonnes pratiques ne se traduit pas toujours par des processus culturellement efficaces dans toute une entreprise en pleine évolution. 

Nous avons tiré trois leçons de notre passage d'un stack Elasticsearch, Logstash et Kibana (ELK) à l'utilisation par toutes les équipes d'ingénieurs logiciels de la gestion des logs de New Relic.

1. Créez des vues enregistrées préfiltrées

Le stack ELK était considéré comme le meilleur stack technologique pour l'observabilité. Mais lorsque nous avons commencé à collaborer avec d'autres équipes, comme celles des ventes et du service client, nous avons découvert qu'il ne répondait pas à nos besoins. Un stack ELK contient de nombreuses fonctionnalités, mais la plupart ne sont pas utilisées par la majorité des ingénieurs logiciels. Il est également incroyablement difficile à gérer pour les équipes non techniques. 

Dans le stack ELK, le schéma de données passe en priorité. Vous ne pouvez pas avoir de conflits de noms de champ. Vous ne pouvez pas écrire un attribut particulier parce qu'il a un nom réservé. Tout cela devient vite problématique. Par exemple, si quelqu'un inscrit la date et l'heure en suivant le format ISO 86001, puis le format de l'horodatage UNIX, vous ne pouvez plus interroger ces logs dans un stack ELK. C'est l'un des défis, parmi d'autres, que rencontrent les équipes qui veulent utiliser les capacités de logging.

La plupart des utilisateurs ont besoin d'une bonne zone de recherche pour filtrer les logs et répondre aux questions importantes en ce qui concerne l'ingestion des données ou la latence des requêtes. Dans la gestion des logs de New Relic, la syntaxe des requêtes est intuitive : elle ressemble à la syntaxe des libellés Gmail. Les personnes qui ne sont pas habituées à utiliser le langage SQL peuvent quand même s'en servir. Nous disposons de nos propres attributs personnalisés partagés sur toutes les applications avec les tags et les libellés spécifiques à l'entreprise. Du point de vue de la maintenance, nous n'utilisons pas les partitions de données, ni quoi que ce soit de très sophistiqué. Nous pouvons interroger l'intégralité de nos logs et juste utiliser les filtres, et c'est toujours assez rapide pour la plupart de nos besoins.

Il y a simplement moins de maintenance et il n'est pas nécessaire de conserver des modèles ou de gérer des instances, même sur une solution ELK hébergée.

2. Utilisez les tags pour rendre les dashboards accessibles

Nos développeurs travaillent dans toute l'entreprise en collaboration avec les équipes commerciales et en contact avec la clientèle. Nous envoyons des dashboards à beaucoup de gens. 

Pour nos conseillers, nous créons des dashboards qui montrent la latence et le temps que passe une personne moyenne à attendre au téléphone. Ces dashboards peuvent être personnalisés pour les équipes et les responsables commerciaux. Ensuite, les parties prenantes peuvent prendre la main. Elles n'ont pas besoin de connaître un langage de requête et peuvent filtrer les données sans assistance. C'est un point déterminant. Nos dashboards peuvent être utilisés dans toute l'organisation pour que tout le monde soit sur la même longueur d'onde en ce qui concerne les objectifs pour l'expérience client.

Les logs en contexte ont été très utiles aux équipes qui les ont adoptés, et ils sont en train de devenir une composante intégrale du workflow. Pour le débogage, nous passons des alertes aux logs. Une alerte nous indique que quelque chose ne va pas avec une requête limitée dans le temps pour les logs des applications. Nous la générons aussi dans notre langage de requête parce que nous connaissons le nom de l'application, le nom de la branche et quand l'erreur s'est produite. Nous préremplissons ensuite cette requête.

3. Évitez tout ce qui brille et alimente le feu de la complexité

Nous avons d'abord pensé que le fait d'offrir les meilleurs outils d'observabilité dans chaque catégorie serait bénéfique à nos développeurs de logiciels. Nous nous sommes rapidement rendu compte de l'impact sur la productivité des ingénieurs et de l'augmentation du stress mental qui venait avec chaque outil ajouté. Il est assez difficile d'acquérir les compétences nécessaires pour utiliser un seul outil efficacement, mais quand on en ajoute trois ou quatre à un stack, cela devient impossible. Les développeurs restent fidèles aux logiciels qu'ils connaissent déjà même quand il y a de meilleurs outils disponibles, c'est la nature humaine.

Avec l'utilisation de tant d'outils, l'argent est vite devenu un autre gros souci. Nous étions en passe de dépenser un million de dollars (USD) par an sur les seuls outils d'observation. Vu la taille de notre entreprise, la part du budget utilisée juste pour l'observabilité n'était pas viable. En plus, nous n'obtenions pas le retour sur investissements qu'il nous aurait fallu pour pouvoir justifier cette dépense.

Nous avons décidé de réduire notre stack technologique et choisi d'utiliser New Relic comme seul outil d'observabilité. Et pour la première fois, nous avons pu disposer de toutes nos données télémétriques (y compris les logs, traces et métriques) en un seul et même endroit, et nous pouvons même monitorer, déboguer et améliorer tout notre stack. En nous concentrant sur un seul outil, nous avons fait des économies et préservé notre énergie mentale. Toutes les données dont ont besoin nos développeurs sont accessibles directement depuis New Relic. Ainsi, ils n'ont pas à gaspiller leur temps à rechercher les codes à double authentification pour pouvoir se connecter à plusieurs systèmes. Ils n'ont pas non plus besoin d'être des experts de l'observabilité, car la plateforme s'en charge. Lorsque nous avons demandé aux développeurs ce qu'ils préféraient du passage à New Relic, ils ont répondu que c'était le fait qu'ils n'avaient pas à gérer cinq interfaces différentes ni de multiples langages de requêtes.