Aperçu

J'utilise New Relic dans un environnement de production + environnement de développement depuis environ un an et demi, et j'ai accumulé des connaissances, j'aimerais donc les partager. Les fonctionnalités décrites ici incluent la version payante.

Explication détaillée: surveillance et amélioration des performances avec NewRelic-Part 1 Explication détaillée: surveillance et amélioration des performances avec NewRelic-Part 2

Qu'est-ce que New Relic

NewRelic est un outil utilisé pour surveiller l'état des serveurs ou des applications et améliorer leurs performances. Il existe divers outils de surveillance existants tels que zabbix, ganglia, nagios et munin, mais je pense que New Relic est supérieur en raison de sa facilité d'utilisation. Une fois installé, vous aurez toutes les métriques dont vous avez besoin pour exécuter votre application sur le serveur. Avec les outils de surveillance existants, les utilisateurs qui l'installent doivent définir et configurer les métriques requises et, dans certains cas, écrire des scripts. À cet égard, New Relic a une métrique par défaut très riche et est organisée pour une visualisation facile, et dans de nombreux cas, elle est suffisante sans aucun paramètre supplémentaire. Il existe de nombreux plug-ins qui peuvent être facilement installés même s'ils ne figurent pas dans les métriques existantes.

Dans cet article, je voudrais présenter chaque étude de cas des fonctionnalités que tout le monde connaît dans New Relic aux fonctionnalités détaillées de la version payante.

Environnement prérequis

Nous développons un serveur d'applications pour les jeux sur smartphone. Vous trouverez ci-dessous un diagramme environnemental de l'application prenant des mesures avec New Relic.

Environnement AWS
Application Django (python) avec plusieurs serveurs d'applications sur EC2
Un serveur d'applications est connecté à MySQL et Redis

Et c'est une configuration très générale

Commençons maintenant l'étude de cas de l'ingénieur serveur: sunny:

Cas 1: l'application est lente mais ne peut pas être plus rapide?

Je pense que beaucoup de gens vous le diront. C'est trop difficile à comprendre, alors commençons par définir le problème. Quelle API est lente? Quand êtes-vous arrivé en retard? Est-ce lent seulement dans certains cas? Et les autres utilisateurs? Il y en a beaucoup, mais je serai précis sur ce qui ne va pas. En conséquence, les problèmes suivants ont été détectés.

L'API de Gacha a ralenti depuis environ un jour. Tous les autres joueurs ne sont pas lents, certains sont rapides.

Maintenant que c'est assez spécifique, jetons un coup d'œil à New Relic. Sélectionnez l'application dans APPS, puis appuyez sur l'élément appelé Transactions. Si vous sélectionnez "Temps de réponse moyen le plus lent", vous pouvez voir les API qui sont plus lentes par ordre de temps de réponse. (Remarque: c'est globalement lent, mais je n'ai pas encore réglé le serveur avant l'amélioration des performances ...)

Si vous cliquez sur gacha là, vous verrez la page suivante sur le côté droit.

En regardant cette page, vous pouvez voir ce qui suit.

Prendre beaucoup de temps avec les fonctions en code python
Beaucoup sélectionnent unit_player_xx
De nombreuses insertions et mises à jour de unit_player_xx

Lors de la recherche d'un goulot d'étranglement en combinant à la fois le contenu de la définition du problème et le code source, les points suivants étaient des problèmes.

La réponse de l'utilisateur qui possède un grand nombre d'unités a été lente => La liste complète des unités acquises de l'utilisateur est renvoyée par l'API, mais ce n'est pas nécessaire, supprimez-la
Plusieurs insert / udpate sont en cours d'exécution pour chaque unité acquise par gacha => Le système de mise à jour est effectué en bloc

En prenant les mesures ci-dessus, l'API est devenue plus rapide et le temps de réponse n'est plus un problème. De cette manière, New Relic permet d'améliorer les performances en acquérant le nombre de problèmes SQL pour chaque API, le nombre de requêtes émises à Redis et le temps d'exécution du code python.

Cependant, il convient de noter ici que le temps moyen est juste le temps qu'il a fallu, donc si le processeur du serveur est plein, le code python ne peut pas être traité et le temps de code sera long.

Cas 2: MySQL semble lent, mais quelle en est la cause?

Cela semble être un cas pour expliquer un élément MySQL dans NewRelic, mais cela peut arriver. Lorsque le nombre d'utilisateurs augmente, le CPU du serveur d'application est d'environ 50% et il semble qu'il n'y ait pas de problème, mais si quelque chose ralentit, cela peut être dû à MySQL ou Redis.

Quand je ne suis pas sûr, je regarde l'aperçu de base

Il semble que MySQL soit lent. Dans un tel cas, sélectionnez Bases de données dans le volet gauche et examinez les éléments suivants pour le moment. (Remarque: c'est une autre fois, juste une introduction)

Le temps de réponse de chaque requête étant connu, il est évident que la requête est lente. Ce cas a tendance à être un modèle précoce lorsque l'historique des données était petit, mais ralenti lorsque l'historique des données était important. Dans certains cas, vous avez peut-être oublié de coller l'index, ou vous n'avez peut-être pas besoin de l'historique en premier lieu, alors corrigez cela. En cliquant sur chaque requête, vous verrez également quelle API émet cette requête, ce qui vous aidera à vous améliorer.

Cet élément ne peut être consulté que sur une base requête par requête, mais si vous souhaitez voir les métriques du serveur MySQL lui-même, le plugin MySQL est recommandé. (Remarque: c'est une autre fois, juste une introduction)

http://newrelic.com/plugins/new-relic-platform-team/52

Après l'installation, vous pouvez voir les éléments suivants.

Cas 3: Le processeur est plein, mais que se passe-t-il?

Parfois, vous voulez savoir quel processus occupe le processeur, mais les métriques standard de la console AWS ne vous le disent pas du tout. Même dans un tel cas, New Relic peut être pris avec l'agent installé par défaut.

Sélectionnez SERVEURS dans le volet supérieur. Sélectionnez Processus dans le volet gauche pour voir quels processus utilisent le plus de CPU.

Cas 4: Je veux savoir quand j'ai déployé

Vous pouvez marquer l'heure du déploiement en lançant un événement à l'API Web de NewRelic.

Cas 5: après la libération

C'est un cas, je ne suis pas sûr, mais c'est une histoire que New Relic a été installé uniquement sur le serveur de production. New Relic n'est efficace que lorsqu'il est mis sur le serveur de développement pendant la période de développement. Un schéma courant est que même s'il fonctionne rapidement en développement, ses performances se détériorent en production. Je ne sais pas que les requêtes SQL sont lentes car l'environnement de développement n'est pas surchargé. Dans un tel cas, mettez New Relic dans l'environnement de développement et surveillez le nombre de problèmes SQL pour chaque API. Bien sûr, vous pouvez faire le test de charge pour chaque version, mais dans de nombreux cas, ce n'est pas réaliste en termes de coût et de temps. Cela coûte un peu mensuel, mais je pense que vous pouvez payer assez.

Conclusion

Jusqu'à présent, nous avons résumé l'utilisation de base de New Relic pour chaque cas. La prochaine fois, je présenterai Key Transactions, X-Ray, qui est une fonction utile de New Relic que j'ai récemment apprise.

[PYTHON] Explication détaillée Surveillance et amélioration des performances avec NewRelic-Part 1