🥇Pas que New Relic : un regard sur Datadog et Atatus

Dans le milieu des ingénieurs SRE/DevOps, il n'est pas surprenant qu'un jour un client (ou un système de surveillance) apparaisse en disant que « tout est perdu » : le site ne fonctionne pas, les paiements ne passent pas, la vie est morose... Bien qu'on souhaite aider dans une telle situation, le faire sans un outil simple et clair est souvent très compliqué. Souvent, le problème est caché dans le code même de l'application — il suffit juste de le localiser.

Dans le malheur comme dans la joie…

Il se trouve que nous avons aimé New Relic depuis très longtemps. Il a été et reste un excellent outil pour la surveillance de la performance des applications, et permet également de mettre en œuvre une architecture de microservices (grâce à son agent) et bien d'autres choses. Et tout pourrait être merveilleux, si ce n'était pour les changements de politique tarifaire du service : son le coût depuis 2013 a augmenté de plus de 3 fois. De plus, depuis l'année dernière, pour obtenir un compte d'essai, il faut communiquer avec un gestionnaire personnel, ce qui complique la présentation du produit à un client potentiel.

Situation classique : New Relic n'est pas nécessaire sur une « base permanente », on n'y pense que lorsque le problème commence. Mais il faut quand même payer régulièrement (140 USD par serveur par mois), et dans une infrastructure cloud évolutive, les sommes s'accumulent rapidement. Bien qu'il existe une option « Pay-As-You-Go », l'activation de New Relic nécessitera un redémarrage de l'application, ce qui pourrait entraîner la perte de la situation problématique pour laquelle tout cela a été mis en place. Récemment, New Relic a lancé un nouveau tarif — Essentials, qui semble au premier abord être une alternative raisonnable au Professional… mais en y regardant de plus près, il s'avère que certaines fonctions importantes sont absentes (notamment, il n'y a pas de Transactions Clés, Traçage d'Application Croisée, Traçage Distribué).

En conséquence, nous avons commencé à chercher une alternative moins chère, et notre choix s'est porté sur deux services : Datadog et Atatus. Pourquoi exactement ceux-là ?

Sur les concurrents

Je précise immédiatement qu'il existe d'autres solutions sur le marché. Nous avons même envisagé des options Open Source, mais tous les clients n'ont pas la capacité libre pour héberger des solutions de type self-hosted... — de plus, elles nécessiteront une maintenance supplémentaire. Le duo que nous avons choisi s'est avéré être le plus proche de nos besoins:

support intégrée et développée pour les applications PHP (la stack de nos clients est très variée, mais c'est clairement un leader dans le contexte de la recherche d'alternatives à New Relic);
tarifs abordables (moins de 100 USD par mois pour l'hébergement);
instrumentation automatique;
intégration avec Kubernetes;
ressemblance avec l'interface de New Relic — un avantage notable (car nos ingénieurs y sont habitués).

C'est pourquoi, lors de la première sélection, nous avons écarté plusieurs autres solutions populaires, notamment :

Tideways, AppDynamics et Dynatrace — à cause du coût;
Stackify — bloqué en RF et ne montre que trop peu de données.

L'article suivant est construit de manière à d'abord présenter brièvement les solutions considérées, après quoi je parlerai de notre interaction type avec New Relic et de notre expérience/des impressions concernant la réalisation d'opérations similaires sur d'autres services.

Présentation des concurrents sélectionnés

À propos de New Relic, a probablement été entendu par chacun ? Ce service a commencé son développement il y a plus de 10 ans, en 2008. Nous l'utilisons activement depuis 2012 et n'avons pas rencontré de problèmes pour intégrer un véritable grand nombre d'applications en PHP, Ruby et Python, et nous avons également eu de l'expérience d'intégration avec C# et Go. Les créateurs du service proposent des solutions pour le suivi des applications, des infrastructures, le traçage des infrastructures de microservices, ont créé des applications conviviales pour les appareils utilisateurs et bien plus encore.

Cependant, l'agent New Relic fonctionne avec des protocoles propriétaires, il n'y a pas de support pour OpenTracing. Pour une instrumentation avancée, des modifications spéciales pour New Relic sont nécessaires. Enfin, le support de Kubernetes est encore à un stade expérimental.

Développé en 2010 Datadog semble beaucoup plus intéressant que New Relic en termes d'application dans des environnements Kubernetes. En particulier, il prend en charge l'intégration avec NGINX Ingress, la collecte de journaux, les protocoles statsd et OpenTracing, ce qui permet de suivre la demande utilisateur depuis son initiation jusqu'à la fin du traitement, ainsi que de retrouver des journaux associés à cette demande (à la fois du côté du serveur web et du côté des consommateurs).

Lors de l'utilisation de Datadog, nous avons rencontré des problèmes où il construisait parfois incorrectement la carte des microservices, ainsi que quelques inconvénients techniques. Par exemple, il identifiait incorrectement le type de service (prenant Django pour un service de mise en cache) et provoquait des erreurs 500 dans l'application PHP utilisant la bibliothèque populaire Predis.

Atatus — l'outil le plus jeune ; le service a été lancé en 2014. Son budget marketing est clairement inférieur à celui des concurrents mentionnés, et ses mentions sont beaucoup plus rares. Néanmoins, l'outil en soi ressemble beaucoup à New Relic, non seulement par ses fonctionnalités (APM, surveillance des navigateurs, etc.), mais aussi par son apparence.

Un inconvénient majeur est le support limité à Node.js et PHP. D'un autre côté, il est bien mieux réalisé que chez Datadog. Contrairement à ce dernier, Atatus ne nécessite pas de modifications des applications ni d'ajout d'étiquettes supplémentaires dans le code.

Comment nous utilisons New Relic

Voyons maintenant comment nous utilisons généralement New Relic. Imaginons que nous avons un problème qui nécessite une solution :

Il est facile de remarquer une poussée — analysons-le. Dans New Relic, pour l'application web, les transactions web sont immédiatement sélectionnées, le graphique de performance indique tous les composants, avec des panneaux sur le taux d'erreur et le taux de demande… L'essentiel est que depuis ces panneaux, on peut naviguer entre différentes parties de l'application (par exemple, un clic sur MySQL nous amène à la section des bases de données).

Puisque dans cet exemple nous voyons une poussée d'activité PHP, clickons sur ce graphique et nous passerons automatiquement à Transactions:

La liste des transactions, qui sont essentiellement des contrôleurs du modèle MVC, est déjà triée par Le plus consommateur de temps, ce qui est très pratique : nous voyons immédiatement ce que l'application fait. Des exemples de requêtes longues, qui sont automatiquement collectées par New Relic, sont également disponibles ici. En changeant le tri, il est facile de trouver :

le contrôleur le plus demandé de l'application ;
le contrôleur le plus souvent demandé ;
le plus lent des contrôleurs.

De plus, il est possible de développer chaque transaction et de voir ce que l'application faisait au moment de l'exécution du code :

Enfin, l'application conserve des exemples de traces de requêtes longues (qui prennent plus de 2 secondes). Voici le panneau pour une longue transaction :

On voit que deux méthodes prennent beaucoup de temps, et en même temps, le temps où la requête a été exécutée, son URI et son domaine sont affichés. Cela aide souvent à retrouver la requête dans les logs. En passant à Détails de la trace, on peut voir d'où ces méthodes sont appelées :

Et dans Requêtes de base de données — évaluer les requêtes aux bases de données qui ont été exécutées pendant le fonctionnement de l'application :

Armés de ces connaissances, nous pouvons évaluer la cause du ralentissement de l'application et élaborer avec le développeur une stratégie pour résoudre le problème. En réalité, New Relic ne fournit pas toujours une image claire, mais il aide à choisir la direction de l'enquête :

long PDO::Construct nous a conduit à un fonctionnement étrange de pgpoll ;
instabilité dans le temps Memcache::Get a suggéré un paramétrage incorrect de la machine virtuelle ;
le temps de traitement de modèle suspectement élevé a conduit à une boucle imbriquée vérifiant la présence de 500 avatars dans le stockage d'objets ;
et ainsi de suite…

Il arrive aussi que, plutôt que l'exécution de code sur l'écran principal, quelque chose lié au stockage externe augmente — peu importe si c'est : Redis ou PostgreSQL, — tous se cachent dans l'onglet Bases de données.

Vous pouvez choisir une base de données spécifique pour l'analyse et trier les requêtes — de la même manière que cela se fait dans Transactions. En passant à l'onglet requête, vous pouvez voir combien de fois cette requête apparaît dans chacun des contrôleurs de l'application, ainsi qu'évaluer à quelle fréquence elle est appelée. C'est très pratique :

Des données similaires se trouvent dans l'onglet Services externes, qui cache les requêtes vers des services HTTP externes, tels que l'accès au stockage d'objets, l'envoi d'événements à sentry ou quelque chose de similaire. En termes de contenu, cet onglet est totalement similaire à Databases :

Concurrents : fonctionnalités et impressions

Maintenant, la partie intéressante — comparons les capacités de New Relic avec celles des concurrents. Malheureusement, nous n'avons pas pu tester les trois outils sur la même version d'une application en production. Cependant, nous avons essayé de comparer des situations/configurations aussi identiques que possible.

1. Datadog

Datadog nous accueille avec un tableau de bord affichant tous les services :

Il essaie de fragmenter les applications en composants/microservices, c'est pourquoi dans l'exemple de l'application Django fourni, nous verrons 2 connexions à PostgreSQL (defaultdb et postgres), ainsi que Celery et Redis. Travailler avec Datadog nécessite de vous familiariser avec les principes de MVC : il est essentiel de comprendre où les requêtes des utilisateurs aboutissent. En général, cela est facilité par une carte des services:

Au fait, quelque chose de similaire existe aussi dans New Relic :

… cependant, leur carte est, à mon avis, plus simple et plus claire : elle affiche non pas les composants d'une seule application (ce qui aurait été trop détaillé, comme dans le cas de Datadog), mais uniquement des services ou microservices spécifiques.

Revenons à Datadog : la carte des services montre que les requêtes des utilisateurs arrivent dans Django. Passons au service Django et enfin nous verrons ce que nous attendions :

Malheureusement, par défaut, il n'y a pas de graphique ici Temps de transaction web, similaire à celui que nous voyons sur le tableau de bord principal de New Relic. Cependant, il peut être configuré à la place du graphique % de temps passé. Il suffit de le basculer en Temps moyen par requête par type… et voilà, le graphique familier se présente à nous !

Pourquoi Datadog a-t-il privilégié un autre graphique — cela reste un mystère pour nous. Cela a aussi déçu que le système ne mémorise pas le choix de l'utilisateur (contrairement aux deux concurrents), donc uniquement la création de tableaux de bord personnalisés nous sauve.

Cependant, nous avons été ravis de la possibilité dans Datadog de passer de ces graphiques aux métriques des serveurs associés, de lire les journaux et d'évaluer la charge des gestionnaires de serveur web (Gunicorn). C'est presque comme dans New Relic… et même un peu plus (les journaux) !

Sous les graphiques, se trouvent les transactions, entièrement similaires à New Relic :

Dans Datadog, les transactions s'appellent ressources. Les contrôleurs peuvent être triés par le nombre de requêtes, par le temps moyen de réponse, par le temps maximum dépensé pendant la période choisie.

Une ressource peut être déployée et on peut voir tout ce que nous avons déjà observé dans New Relic :

Il y a des statistiques sur la ressource, une liste résumée des appels internes et des exemples de requêtes qui peuvent être triés par code de réponse… À noter que ce tri a beaucoup plu à nos ingénieurs.

Tout exemple de ressource dans Datadog peut être ouvert et étudié :

Les paramètres de la requête sont présentés, un diagramme récapitulatif du temps passé sur chacun des composants et un diagramme en cascade, où l'on voit la séquence des appels. Il est également possible de passer à une vue en arbre du diagramme en cascade :

Et le plus intéressant — voir la charge de l'hôte sur lequel la requête a été exécutée, ainsi que consulter les journaux de la requête.

Excellente intégration !

Il peut se poser la question de savoir où sont les onglets Bases de données et Services externes, comme dans New Relic. Ici, il n'y en a pas : étant donné que Datadog décompose l'application en composants, PostgreSQL sera considéré comme un service séparé, et au lieu des services externes, il faut chercher aws.storage (il en sera de même pour chaque autre service externe auquel l'application peut faire appel).

Voici un exemple avec postgres:

En gros, tout ce que nous voulions est là :

On peut voir de quel « service » est venue la requête.

Il est bon de rappeler que Datadog s'intègre parfaitement avec NGINX Ingress et permet de réaliser un traçage complet depuis l'arrivée de la requête dans le cluster, tout en acceptant les métriques statsd et en collectant les journaux et les métriques des hôtes.

Un énorme plus pour Datadog est que son prix se compose de la surveillance de l'infrastructure, de l'APM, de la gestion des journaux et des tests Synthetics, c'est-à-dire que l'on peut choisir un plan de manière flexible.

2. Atatus

L'équipe d'Atatus affirme que leur service est « comme New Relic, mais meilleur ». Voyons si c'est vraiment le cas.

La barre supérieure ressemble effectivement à l'autre, mais il n'a pas été possible de déterminer les Redis et memcached utilisés dans l'application.

L'APM sélectionne par défaut toutes les transactions, bien que, comme d'habitude, seules les Web soient nécessaires. Comme avec Datadog, il n'y a pas de possibilité de passer au service souhaité depuis le tableau principal. De plus, les transactions se trouvent dans la liste après les erreurs, ce qui semble peu logique pour l'APM.

Dans les transactions d'Atatus, tout ressemble beaucoup à New Relic. L'inconvénient est que la dynamique de chaque contrôleur n'est pas immédiatement visible. Il faut la chercher dans le tableau des contrôleurs, en triant par Most Time Consumed:

La liste familière des contrôleurs est disponible dans l'onglet Explore:

Cette table rappelle d'une certaine manière Datadog et est plus appréciée que celle de New Relic.

Chaque transaction peut être développée pour voir ce que faisait l'application :

Le tableau ressemble également plutôt à Datadog : il y a le nombre de requêtes, la vue d'ensemble des appels. La barre supérieure fournit un onglet pour les erreurs HTTP Failures et des exemples de requêtes lentes Session Traces:

Si on passe à la transaction, on peut voir un exemple de traçage, obtenir une liste des requêtes à la base de données et voir les en-têtes de la requête. Tout est similaire à New Relic :

Globalement, Atatus a été ravi de fournir des traçages détaillés - sans les collages d'appels typiques de New Relic dans le bloc de rappel :

Cependant, il manque un filtre qui (comme dans New Relic) éliminerait les requêtes ultra-rapides (<5ms). D'un autre côté, l'affichage de la réponse finale de la transaction (réussite ou erreur) était apprécié.

Panneau Bases de données aidera à étudier les requêtes vers les bases de données externes effectuées par l'application. Je rappelle qu'Atatus n'a trouvé que PostgreSQL et MySQL, bien que Redis et memcached soient également utilisés dans le projet.

Les requêtes sont triées selon des critères familiers : fréquence d'activation, temps de réponse moyen, etc. Il convient de noter l'onglet présentant les requêtes les plus lentes - c'est très pratique. De plus, les données dans cet onglet pour PostgreSQL correspondent à celles fournies par l'extension. pg_stat_statements — un excellent résultat !

Onglet Requêtes externes est entièrement identique à Databases.

Conclusions

Les deux outils présentés se sont bien comportés en tant qu'APM. Chacun d'eux peut offrir le minimum nécessaire. En résumé, nous pouvons dire que :

Datadog

Avantages :

une grille tarifaire pratique (l'APM coûte 31 USD par hôte) ;
a très bien fonctionné avec Python ;
intégration avec OpenTracing
intégration avec Kubernetes;
intégration avec NGINX Ingress.

Inconvénients :

le seul APM qui a causé une indisponibilité de l'application en raison d'une erreur de module (predis) ;
faible auto-instrumentation PHP ;
définition partiellement étrange des services et de leur but.

Atatus