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.
Une étude au Royaume-Uni montre qu'une personne sur quatre évalue le secteur de l'assurance comme étant le pire pour arriver à faire quoi que ce soit en ligne quand on est un client. Chez Simply Business, nous pensons que l'assurance devrait être très claire, facile à organiser et instantanée. Nous simplifions l'achat de polices d'assurance pour que nos clients — qui sont pour l'essentiel de petites entreprises et des entrepreneurs individuels au Royaume-Uni, en Europe, aux États-Unis et au Canada — n'aient pas à téléphoner ni à apporter de formulaires en main propre.
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.
Le dashboard utilisé par Simply Business pour les métriques de téléphonie
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.
Simply Business utilise ce dashboard pour examiner l'utilisation des ressources du conteneur via les filtres.
New Relic vs ELK: Log management showdown
On a final note, here’s a comparative table outlining the key elements to consider when comparing New Relic and ELK for log management capabilities. The right choice for your business will ultimately depend on your specific requirements, budget, in-house expertise, and the level of control you need over your log management infrastructure.
| Aspect | New Relic | ELK Stack |
|---|---|---|
| Components | New Relic Logs, New Relic Infrastructure | Elasticsearch, Logstash, Kibana |
| Log collection | Agents collect logs from various sources | Logstash collects, processes, and ships logs |
| Storage | Cloud-based storage | Self-hosted, scalable storage with Elasticsearch |
| Data parsing | Automatic parsing and categorization of log data | Custom parsing and filtering configurations with Logstash |
| Alerting | Custom alerting based on log events | Custom alerting and notification capabilities |
| Ease of use | User-friendly interface with guided setup | Steeper learning curve, especially for complex configurations |
| Scalability | Scales with New Relic's infrastructure | Scalable, suitable for large-scale log management |
| Cost | Subscription-based pricing model | Open-source, no licensing cost, but requires hardware and maintenance |
| Community support | Strong community support | Active community and extensive online resources |
| Use cases | Well-suited for businesses preferring a managed solution with easy setup | Ideal for businesses with in-house expertise and need for customization |
| Security | Offers security features such as encryption at rest and in transit | Requires careful configuration for securing data and access control |
| Compliance | Complies with industry standards and regulations | Compliance is achievable but requires configuration and monitoring |
| Updates and support | Regular updates and support from New Relic | Updates depend on the user, with support from the community and forums |
Étapes suivantes
- Regardez une vidéo dans laquelle Mikio Tsunematsu parle des trois hérésies de l'observabilité.
-
Apprenez à passer d'un logging efficace pour l'observabilité full-stack avec Les meilleures pratiques de gestion des logs.
- Apprenez-en plus pour bien démarrer avec la gestion des logs.
Les opinions exprimées sur ce blog sont celles de l'auteur et ne reflètent pas nécessairement celles de New Relic. Toutes les solutions proposées par l'auteur sont spécifiques à l'environnement et ne font pas partie des solutions commerciales ou du support proposés par New Relic. Veuillez nous rejoindre exclusivement sur l'Explorers Hub (discuss.newrelic.com) pour toute question et assistance concernant cet article de blog. Ce blog peut contenir des liens vers du contenu de sites tiers. En fournissant de tels liens, New Relic n'adopte, ne garantit, n'approuve ou n'approuve pas les informations, vues ou produits disponibles sur ces sites.
