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

Dans le milieu des ingénieurs SRE/DevOps, cela ne surprendra personne qu'un jour un client (ou un système de surveillance) apparaisse et signale que « tout est perdu » : le site ne fonctionne pas, les paiements ne passent pas, la vie se détériore. ... Peu importe à quel point vous souhaiteriez aider dans une telle situation , cela peut être très difficile de le faire sans un outil simple et compréhensible. Souvent, le problème est caché dans le code de l'application lui-même ; il vous suffit de le localiser.

Et dans le chagrin et dans la joie…

Il se trouve que nous sommes depuis longtemps et profondément tombés amoureux de New Relic. C'était et reste un excellent outil pour surveiller les performances des applications, et permet également d'instrumenter l'architecture du microservice (à l'aide de son agent) et bien plus encore. Et tout aurait pu être formidable sans un changement dans la politique tarifaire du service : il coût de avec les années 2013 a grandi plus de 3 fois. De plus, depuis l'année dernière, l'obtention d'un compte d'essai nécessite une communication avec un responsable personnel, ce qui rend difficile la présentation du produit à un client potentiel.

Situation habituelle : New Relic n'est pas nécessaire de manière « permanente », ils ne s'en souviennent qu'au moment où les problèmes commencent. Mais vous devez quand même payer régulièrement (140 USD par serveur et par mois), et dans une infrastructure cloud évolutive automatiquement, les sommes s'additionnent plutôt. Bien qu'il existe une option Pay-As-You-Go, l'activation de New Relic vous obligera à redémarrer l'application, ce qui peut entraîner la perte de la situation problématique pour laquelle tout a été démarré. Il n'y a pas si longtemps, New Relic a introduit un nouveau plan tarifaire - Essentiels, - qui à première vue semble être une alternative raisonnable à Professional... mais après un examen plus approfondi, il s'est avéré qu'il manque certaines fonctions importantes (en particulier, il n'a pas Transactions clés, Traçage inter-applications, Traçage distribué).

En conséquence, nous avons commencé à réfléchir à la recherche d’une alternative moins chère et notre choix s’est porté sur deux services : Datadog et Atatus. Pourquoi sur eux ?

À propos des concurrents

Disons tout de suite qu'il existe d'autres solutions sur le marché. Nous avons même envisagé les options Open Source, mais tous les clients ne disposent pas de capacité libre pour héberger des solutions auto-hébergées... - de plus, elles nécessiteront une maintenance supplémentaire. Le couple que nous avons choisi s'est avéré être le plus proche de nos besoins:

support intégré et développé pour les applications PHP (la pile de nos clients est très diversifiée, mais c'est un leader incontesté dans le contexte de la recherche d'une alternative à New Relic) ;
coût abordable (moins de 100 USD par mois et par hôte) ;
instruments automatiques;
intégration avec Kubernetes ;
La similitude avec l'interface de New Relic est un plus notable (car nos ingénieurs y sont habitués).

Ainsi, lors de la phase de sélection initiale, nous avons éliminé plusieurs autres solutions populaires, et notamment :

Tideways, AppDynamics et Dynatrace – moyennant des frais ;
Stackify est bloqué en Fédération de Russie et affiche trop peu de données.

Le reste de l'article est structuré de telle manière que les solutions en question seront d'abord brièvement présentées, après quoi je parlerai de notre interaction typique avec New Relic et de notre expérience/impressions résultant de l'exécution d'opérations similaires dans d'autres services.

Présentation des concurrents sélectionnés

Sur New Relic, probablement tout le monde a entendu ? 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 eu aucun problème à intégrer un très grand nombre d'applications en PHP, Ruby et Python, et nous avons également eu de l'expérience en matière d'intégration avec C# et Go. Les auteurs du service proposent des solutions pour surveiller les applications, les infrastructures, tracer les infrastructures de microservices, créer des applications pratiques pour les appareils des utilisateurs et bien plus encore.

Cependant, l'agent New Relic fonctionne sur des protocoles propriétaires et ne prend pas en charge OpenTracing. L'instrumentation avancée nécessite des modifications spécifiquement pour New Relic. Enfin, le support de Kubernetes est encore expérimental.

A commencé son développement en 2010 Datadog semble nettement plus intéressant que New Relic précisément en termes d'utilisation dans les environnements Kubernetes. En particulier, il prend en charge l'intégration avec les protocoles NGINX Ingress, collection de journaux, statsd et OpenTracing, ce qui vous permet de suivre une demande utilisateur à partir du moment où elle est connectée jusqu'à son achèvement, ainsi que de trouver des journaux pour cette demande (tous deux côté serveur Web). et chez le consommateur).

Lors de l’utilisation de Datadog, nous avons constaté qu’il construisait parfois la carte du microservice de manière incorrecte et présentait certaines lacunes techniques. Par exemple, il a mal identifié le type de service (en prenant Django pour un service de mise en cache) et a provoqué 500 erreurs dans une application PHP utilisant la populaire bibliothèque Predis.

Atatus — l'instrument le plus jeune ; le service a été lancé en 2014. Son budget marketing est nettement inférieur à celui des concurrents listés, les mentions sont beaucoup moins fréquentes. Cependant, l'outil lui-même est très similaire à New Relic, non seulement dans ses capacités (APM, surveillance du navigateur, etc.), mais aussi en apparence.

Un inconvénient majeur est qu’il ne prend en charge que Node.js et PHP. D’un autre côté, il est nettement mieux implémenté que Datadog. Contrairement à ce dernier, Atatus ne nécessite pas que les applications apportent des modifications ou ajoutent des étiquettes supplémentaires au code.

Comment nous travaillons avec New Relic

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

C'est facile à voir sur le graphique pic - Analysons-le. Dans New Relic, les transactions Web sont immédiatement sélectionnées pour une application Web, tous les composants sont indiqués dans le graphique de performances, il existe des panneaux de taux d'erreur, de taux de requêtes... Le plus important est que directement à partir de ces panneaux, vous pouvez vous déplacer entre les différents certaines parties de l'application (par exemple, cliquer sur MySQL mènera à la section base de données).

Puisque dans l'exemple considéré on constate un regain d'activité PHP, cliquez sur ce graphique et accédez automatiquement à Transactions:

La liste des transactions, qui sont essentiellement des contrôleurs du modèle MVC, est déjà triée par Le plus long, ce qui est très pratique : on voit immédiatement ce que fait l’application. Voici des exemples de requêtes longues qui sont automatiquement collectées par New Relic. En changeant de tri, il est facile de trouver :

le contrôleur d'application le plus chargé ;
contrôleur le plus fréquemment demandé ;
le plus lent des contrôleurs.

De plus, vous pouvez développer chaque transaction et voir ce que faisait l'application au moment où le code a été exécuté :

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

On peut voir que deux méthodes prennent beaucoup de temps, et en même temps l'heure à laquelle la requête a été exécutée, son URI et son domaine sont également affichés. Très souvent, cela permet de retrouver la demande dans les journaux. Aller à Détails des traces, vous pouvez voir d'où ces méthodes sont appelées :

Et dans Requêtes de base de données — évalue les requêtes sur les bases de données qui ont été exécutées pendant l'exécution de l'application :

Forts de ces connaissances, nous pouvons évaluer pourquoi l'application ralentit et travailler avec le développeur pour élaborer une stratégie pour résoudre le problème. En réalité, New Relic ne donne pas toujours une image claire, mais il aide à choisir le vecteur d’investigation :

longtemps PDO::Construct nous a conduit au fonctionnement étrange de pgpoll ;
instabilité dans le temps Memcache::Get a suggéré que la machine virtuelle n'était pas configurée correctement ;
une augmentation suspecte du temps de traitement des modèles 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 également qu'au lieu d'exécuter du code, quelque chose lié au stockage de données externe grandisse sur l'écran principal - et peu importe ce que ce sera : Redis ou PostgreSQL - ils sont tous cachés dans l'onglet Bases de données.

Vous pouvez sélectionner une base spécifique pour la recherche et trier les requêtes, de la même manière que dans Transactions. Et en allant dans l'onglet requête, vous pouvez voir combien de fois cette requête se produit dans chacun des contrôleurs d'application, et également estimer la fréquence à laquelle elle est appelée. C'est très confortable :

L'onglet contient des données similaires Services externes, qui masque les requêtes adressées aux services HTTP externes, telles que l'accès au stockage d'objets, l'envoi d'événements à la sentinelle, etc. Le contenu de l'onglet est complètement similaire à celui des bases de données :

Concurrents : opportunités et impressions

Maintenant, le plus intéressant est de comparer les capacités de New Relic avec ce que proposent les concurrents. Malheureusement, nous n'avons pas pu tester les trois outils sur une seule version d'une application exécutée en production. Nous avons cependant essayé de comparer des situations/configurations aussi identiques que possible.

1. Chien de données

Datadog nous accueille avec un panel avec un mur de services :

Il essaie de diviser les applications en composants/microservices, donc dans l'exemple d'application Django, nous verrons 2 connexions à PostgreSQL (defaultdb и postgres), ainsi que Céleri, Redis. Travailler avec Datadog nécessite une connaissance minimale des principes MVC : vous devez comprendre d'où proviennent généralement les demandes des utilisateurs. Cela aide généralement carte des services:

Au fait, il y a quelque chose de similaire dans New Relic :

... et leur carte, à mon avis, est rendue plus simple et plus claire : elle n'affiche pas les composants d'une application (ce qui la rendrait trop détaillée, comme dans le cas de Datadog), mais uniquement des services ou microservices spécifiques.

Revenons à Datadog : à partir de la carte des services, nous pouvons voir que les requêtes des utilisateurs arrivent à Django. Passons au service Django et voyons enfin ce à quoi nous nous attendions :

Malheureusement, il n'y a pas de graphique ici par défaut Temps de transaction Web, similaire à ce que nous voyons sur le panneau principal de New Relic. Cependant, il peut être configuré à la place du planning % du temps passé. Il suffit de le basculer sur Temps moyen par demande par type... et maintenant le graphique familier nous regarde !

La raison pour laquelle Datadog a choisi un graphique différent reste un mystère pour nous. Une autre chose frustrante est que le système ne mémorise pas le choix de l’utilisateur (contrairement aux deux concurrents), et donc la seule solution est de créer des panneaux personnalisés.

Mais j'ai été satisfait 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 sur les gestionnaires du serveur Web (Gunicorn). Tout est quasiment pareil que dans New Relic... et même un peu plus (logs) !

Sous les graphiques se trouvent des transactions complètement similaires à New Relic :

Dans Datadog, les transactions sont appelées les ressources. Vous pouvez trier les contrôleurs par nombre de requêtes, par temps de réponse moyen et par temps maximum passé pour une période de temps sélectionnée.

Vous pouvez étendre la ressource et voir tout ce que nous avons déjà observé dans New Relic :

Il existe des statistiques sur la ressource, une liste généralisée des appels internes et des exemples de requêtes pouvant être triées par code de réponse... D'ailleurs, nos ingénieurs ont beaucoup aimé ce tri.

N’importe quel exemple de ressource dans Datadog peut être ouvert et étudié :

Les paramètres de la requête, un graphique récapitulatif du temps passé sur chaque composant et un graphique en cascade montrant la séquence d'appels sont présentés. Vous pouvez également passer à une arborescence du graphique en cascade :

Et le plus intéressant est de visualiser la charge de l'hôte sur lequel la requête a été exécutée et de visualiser les logs des requêtes.

Belle intégration !

Vous vous demandez peut-être où sont les onglets Bases de données и Services externes, comme dans New Relic. Il n'y en a pas ici : puisque Datadog décompose l'application en composants, PostgreSQL sera pris en compte un service séparé, et au lieu de services externes, cela vaut la peine de chercher aws.storage (il en sera de même pour tous les autres services externes auxquels l'application peut accéder).

Voici un exemple avec postgres:

En gros, il y a tout ce que nous voulions :

Vous pouvez voir de quel « service » provient la demande.

Il ne serait pas inutile de rappeler que Datadog s'intègre parfaitement à NGINX Ingress et permet d'effectuer un traçage de bout en bout à partir du moment où une requête arrive dans le cluster, et permet également de recevoir des métriques statsd, de collecter des logs et des métriques d'hébergement. .

Un énorme avantage de Datadog est son prix prend forme de la surveillance de l'infrastructure, de l'APM, de la gestion des journaux et des tests synthétiques, c'est-à-dire Vous pouvez choisir votre forfait en toute flexibilité.

2.État

L'équipe Atatus affirme que son service est « le même que celui de New Relic, mais en meilleur ». Voyons si c'est vraiment le cas.

Le panneau principal semble similaire, mais il n'a pas été possible de déterminer le Redis et le memcached utilisés dans l'application.

APM sélectionne toutes les transactions par défaut, même si généralement seules les transactions Web sont nécessaires. Comme dans Datadog, il n'y a aucun moyen de naviguer vers le service souhaité depuis le panneau principal. De plus, les transactions sont listées après les erreurs, ce qui ne semble pas très logique pour APM.

Dans les transactions Atatus, tout est aussi similaire que possible à New Relic. L'inconvénient est que la dynamique de chaque contrôleur n'est pas immédiatement visible. Il faut le chercher dans la table des contrôleurs, en triant par Le plus de temps consommé:

La liste habituelle des contrôleurs est disponible dans l'onglet Explorer:

À certains égards, ce tableau rappelle celui de Datadog et je l'aime mieux que celui similaire de New Relic.

Vous pouvez développer chaque transaction et voir ce que faisait l'application :

Le panel fait aussi davantage penser à Datadog : il y a un certain nombre de demandes, une image générale des appels. Le panneau supérieur fournit un onglet d'erreur Échecs HTTP et des exemples de requêtes lentes Suivis de sessions:

Si vous accédez à une transaction, vous pouvez voir un exemple de trace, vous pouvez obtenir une liste des requêtes adressées à la base de données et consulter les en-têtes de requête. Tout est similaire à New Relic :

En général, Atatus se contente de traces détaillées - sans le collage typique des appels de New Relic dans un bloc de rappel :

Il lui manque cependant un filtre qui (comme New Relic) couperait les requêtes ultra-rapides (<5 ms). En revanche, j'ai aimé l'affichage de la réponse finale de la transaction (succès ou erreur).

Panel Bases de données vous aidera à étudier les requêtes adressées aux bases de données externes que l'application effectue. Permettez-moi de vous rappeler qu'Atatus n'a trouvé que PostgreSQL et MySQL, bien que Redis et Memcached soient également impliqués dans le projet.

Les demandes sont triées selon les critères habituels : fréquence de réponse, temps de réponse moyen, etc. Je voudrais également mentionner l'onglet avec les requêtes les plus lentes - c'est très pratique. De plus, les données de cet onglet pour PostgreSQL coïncidaient avec les données de l'extension pg_stat_statements - excellent résultat !

Insérer Demandes externes complètement identique aux bases de données.

résultats

Les deux outils présentés ont bien fonctionné dans le rôle d’APM. N'importe lequel d'entre eux peut offrir le minimum requis. Nos impressions peuvent être brièvement résumées comme suit :

Datadog

Avantages:

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

Inconvénients:

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

Atatus