New Relic enchâsse ses outils d’observabilité dans le cycle DevOps

New Relic entrouvre le capot

Le responsable fait ici référence au rapprochement de New Relic avec Microsoft Azure. Le partenariat permet d’intégrer les agents de l’éditeur (dont ceux dédiés à Windows) à même la console Azure et faire communiquer sa plateforme à Azure Monitor. L’éditeur dispose de plus de 500 intégrations, dont celles consacrées aux services des éditeurs tiers et des fournisseurs tels GCP, Azure et AWS.

Cela ne veut pas dire que New Relic déploie sa solution sur tous les clouds. L’éditeur s’appuie sur deux régions, US et EU, pour stocker les données de ses clients. « New Relic est auto-hébergé avec des services de colocation appelés Server Central dans un centre de données Tier 3 à Chicago et un centre de données hébergé par IBM près de Francfort en Allemagne, ainsi qu'un service de stockage en cloud via AWS », précise sa documentation.

Pour faire simple, cette plateforme repose sur des pipelines d’ingestion Apache Kafka dans des instances d’une base de données propriétaires (New Relic Database ou NRDB). Elle partage une même couche de stockage S3 et est couplée à une collection d’agents APM, des plugins OpenTelemetry et Prometheus. En 2022, cette plateforme de télémétrie distribuée et massivement parallèle exécutait des dizaines de milliers de JVM, et stockait plusieurs exaoctets de données (traces, métriques, logs, événements).

Cette proximité avec la communauté OpenTelemetry est une priorité pour l’éditeur. « Nous voulons continuer de faire de New Relic la plateforme la plus ouverte possible qui permet de pousser de la télémétrie IT, software, métier, UX, depuis à peu près n’importe quelle source de données », vante Gregory Ouillon.

New Relic investit par ailleurs dans ses moteurs de corrélation, afin « de relier les différents composants de télémétrie entre eux pour avoir une vue topologique en temps réel extrêmement précise de l'architecture ».

« Nous sommes capables de détecter quels logs appartiennent à quelles traces, comment des traces sont reliées à des logs, comment des logs sont reliés à une transaction APM », décrit le CTO EMEA.

Des expériences « horizontales » pour les développeurs

Mais chez New Relic, toute cette belle mécanique est cachée sous une interface qui relie plusieurs fonctionnalités.

« Le moteur de relation nous permet de faire un lien de navigation entre les outils de diagnostic, c’est-à-dire les vues optimisées par New Relic », assure Gregory Ouillon.

Toutes les données de télémétrie sont accessibles par un administrateur ayant accès à la licence full stack, mais les développeurs, eux, sont invités à utiliser des « expériences horizontales ».

L’une des volontés de l’éditeur est de rapprocher les outils de supervision au plus près des environnements manipulés par les développeurs. Cela passe par exemple par la supervision des environnements JFrog Artifactory et Xray. Il s’agit de surveiller et d’optimiser les pipelines CI/CD, mais aussi par l’accès aux données de télémétrie depuis les IDE du marché.

En ce sens, New Relic a introduit CodeStream en octobre 2021. Présenté comme un outil de collaboration, il permet d’accéder depuis un IDE (VScode, Jetbrains, Visual Studio) à des visualisations pour superviser les « golden signals et des erreurs » dans le code d’une application ou d’une architecture. Il est possible d’effectuer des commentaires, des révisions de code, ou encore d’approuver des pull requests en provenance de GitHub, BitBucket et GitLab.

Le 9 mars dernier, New Relic annonçait la prise en charge des environnements .NET, Java, PHP, Python, Rugy, Go et Nodejs.

Les développeurs, les SRE et les Ops peuvent obtenir les métriques affichées sous forme de ligne de texte au-dessus de chaque méthode instrumentée. L’outil renseigne les temps de latences, le débit et le taux d’erreurs observés dans les trente dernières minutes. Il en va de même pour les SLO, mais aussi pour enrichir les revues de code.

« L'idée, c'est d'apporter progressivement aux développeurs la compréhension de la performance de son code en production jusqu'au niveau méthode, de sorte qu'il va s'approprier cette notion de performance mesurable », résume le CTO EMEA.

Pour les organisations qui n’utilisent pas New Relic, l’outil est disponible en open source. Il peut également s’intégrer avec les outils de gestion d’erreurs et de projets (Jira, Trello, Asana, etc.) et les autres outils de collaboration (Slack, Teams).

« Des millions de développeurs utilisent CodeStream », assure Gregory Ouillon. « Cela reste toutefois un outil utilisé par des équipes avancées dans leur démarche DevOps. […] Ce n’est pas encore pour tout le monde », concède-t-il.

Suivant le niveau d’adoption et la maturité des utilisateurs, New Relic pourrait pousser davantage de fonctionnalités « de plus en plus sophistiquées de debugging, de profiling, d’analyse ».

Errors Inbox : New Relic tente de centraliser la gestion des erreurs

New Relic investit également dans Errors Inbox, la boîte de réception des erreurs intégrée à sa plateforme depuis 2021. « Cela a pris un peu de temps pour que les usagers se l’approprient », constate le responsable.

L’éditeur a ainsi adjoint la possibilité de recevoir des erreurs en provenance des agents APM, serverless, RUM, les crashs mobiles, les synthétiques, ainsi que les erreurs OpenTelemetry. Plus récemment, New Relic a ajouté une intégration bidirectionnelle avec Jira. « En un clic, l’on peut assigner un ticket dans Jira depuis Errors Inbox ».

Errors Inbox figure par ailleurs un indicateur important : l’impact utilisateur. « Comme nous avons la compréhension de l’utilisation de la stack par les sessions, nous pouvons fournir une métrique concernant le nombre d’utilisateurs impactés par une erreur ou un problème. Cela aide au triage des erreurs et à la priorisation de la dette technique », avance le CTO Europe.

Par exemple, une erreur peut remonter régulièrement sans avoir de répercussions sur les usagers d’une application, alors que certaines erreurs, plus sporadiques, peuvent entraîner la non-disponibilité d’un service.

En outre, Errors Inbox détecte les régressions. « Chaque fois que l’on a un groupe d’erreurs, nous créons une signature unique que nous gardons en mémoire. Si cette erreur est réintroduite, nous la détectons automatiquement et nous le notifions aux utilisateurs », décrit Grégory Ouillon.

L’adoption lente peut aussi être dû au fait que l’outil générait beaucoup de bruits avant que New Relic œuvre pour regrouper les erreurs par périmètre et pour rassembler des batchs de notifications (par exemple 2 000 erreurs d’un coup).

Il y a aussi le fait que la brique APM de New Relic possède son propre système de gestion des erreurs. « L’on s’attend à emmener progressivement les utilisateurs vers Errors Inbox, l’endroit où l’on gère la dette technique ».

Détecter un plus grand nombre de changements

Dans la même veine, New Relic a revu la notion de suivi des changements en février 2023. Autrefois réservé à la partie APM, l’éditeur l’a étendu à l’ensemble des domaines couverts par la plateforme d’observabilité.

Pour cela, il a fait évoluer ses marqueurs qui servaient auparavant à désigner un déploiement. « Nous avons enrichi le modèle de données pour intégrer davantage de métadonnées afin de définir ce qu’est un changement », relate le CTO EMEA.

Il peut s’agir d’un déploiement canari, blue/green, de l’activation d’un feature flag, d’un déploiement Terraform, voire « d’un changement physique au niveau d’un pare-feu que nous savons capturer à l’aide de la collecte de tickets Jira ».

Les changements notifiés dans une interface dédiée sont associés à une fenêtre d’analyse. L’objectif : comparer la situation actuelle, probablement dégradée, à une période antérieure. Comme certaines équipes effectuent plusieurs centaines, voire plusieurs centaines à plusieurs milliers de déploiements par jour, New Relic travaille actuellement à la mise en place d’un système de détection des « méta-changements ». Il s’agit de suivre les impacts d’une modification sur un périmètre élargi ou mesurer les effets progressifs d’un déploiement en plusieurs étapes. D’où la nécessité de s'intégrer aux outils de CI/CD, comme JFrog, mais aussi Jenkins.

Gestion des vulnérabilités : New Relic sur les traces de Datadog

L’autre tendance importante de ce marché consiste à intégrer des fonctions de cybersécurité dans leurs offres. Ce rapprochement de l’observabilité et des analyses de la sécurité va de pair avec l’émergence des pratiques DevSecOps plutôt qu’à une véritable remise en question des SIEM existants.

New Relic a suivi ce même chemin, même s’il accuse un certain retard sur ses concurrents.

Ainsi, il lancé en disponibilité générale en janvier 2023 sa propre interface de gestion de vulnérabilités en quasi-temps réel. Celui-ci inventorie les compositions des builds récupérées par les agents APM et les compare avec une base de données de CVE. Même si beaucoup d’acteurs proposent cette capacité, l’éditeur remarque qu’elle a fait mouche chez les clients. « Quand nous avons expliqué aux clients ce que nous voulions faire, nous nous sommes aperçus que peu d’entre eux avaient la maîtrise de leur inventaire de code », note Gregory Ouillon.

L’outil permet de surfacer la zone de vulnérabilité d’un logiciel, puis de classifier et de prioriser les vulnérabilités à remédier rapidement.

A l’instar de Datadog, New Relic ne veut pas simplement détecter et alerter, mais proposer un moyen de bloquer les attaques référencées par l’OWASP. C’est en ce sens qu’il a annoncé le rachat de K2 Cybersecurity, une petite startup californienne éditrice d’un IAST et d’un RASP.

GPT Ops

Enfin, New Relic s’intéresse à un segment pour l’instant relativement peu couverts par les plateformes d’observabilité : le MLOps. L’éditeur intègre sa plateforme avec SageMaker d’AWS, DataRobot, mais aussi quelques outils spécialisés dont Aporia, Comet ou Mona. Sans surprise, il a tenu à surfer sur la vague ChatGPT. New Relic propose d’ores et déjà un moyen d’intégrer ses outils de surveillance avec les API d’OpenAI. Pour l’instant, il s’agit de monitorer l’utilisation des services de l’entreprise soutenue par Microsoft. L’instrumentation (tenant sur deux lignes de code) sert à obtenir un extrait de la commande en entrée et de la réponse en sortie, le temps de réponse, le nombre de tokens (mots) moyens par requête et le coût d’utilisation des API. Comme les portes de l’IP de la célèbre startup sont closes, il n’est guère possible de faire mieux actuellement.