Share
Une application en cours d'exécution n'est pas simplement un groupe de code, le code doit également être exécuté quelque part. Je parle de vos serveurs de production. Il est tout aussi important de s’assurer que les boîtes de production se comportent que de s’assurer que le code de votre application est performant. Vous pouvez configurer des systèmes tels que Nagios pour vous aider dans ce domaine, mais leur fonctionnement peut s'avérer extrêmement complexe, nécessiter une infrastructure propre et peut être excessif (à moins que vos besoins en infrastructure ne soient extrêmement complexes). New Relic offre une alternative moins complète mais très simple en matière de surveillance des infrastructures.
Si vous avez lu certains de nos articles précédents sur New Relic, vous devriez être à l'aise avec le fonctionnement des tableaux de bord New Relic. Les tableaux de bord de surveillance du serveur utilisent les mêmes concepts. Si vous utilisez déjà New Relic, vous pouvez commencer à recevoir très rapidement des données sur les performances de votre serveur. Même si vous n'avez pas encore configuré New Relic, il peut être intéressant de l'utiliser uniquement pour la surveillance du serveur. Les quelque six tableaux de bord fournis par New Relic peuvent considérablement retarder (voire supprimer totalement) le besoin d’une solution de surveillance d’infrastructure plus complète..
Selon les besoins de votre application, vous pouvez avoir un composant Web, une base de données, un cache, une recherche, un équilibreur de charge, etc. Certains peuvent partager la même boîte. Mais, une fois que votre application dépasse une certaine taille, vous commencerez à en placer certaines sur leurs propres boîtes. Lorsque vous n'avez qu'un seul serveur de production, les choses sont faciles. SSH dans cette boîte, lancez quelques commandes shell et obtenez une bonne idée de la santé de ce serveur. À mesure que le nombre de boîtes augmente, cela peut devenir une corvée. Ce serait pratique si vous pouviez avoir un moyen de connaître la santé de toutes vos boîtes à la fois. C’est exactement le problème que résolvent les tableaux de bord du serveur New Relic. Vous obtenez un instantané de la santé de tous vos serveurs de production à la fois.
Bien entendu, vérifier manuellement l’état de santé de tous vos serveurs n’est pas la solution la plus efficace. Lorsque les choses tournent mal, vous voulez le savoir dès que cela se produit, et non la prochaine fois que vous décidez de vérifier. La plupart des systèmes de surveillance d'infrastructure disposent d'un moyen d'envoyer des alertes en cas de défaillance de certaines parties des serveurs surveillés (disque saturé, utilisation excessive de RAM, etc.). New Relic n'est pas différent. Vous pouvez utiliser l'infrastructure de stratégie d'alerte très flexible pour envoyer des notifications d'échec de la manière que vous préférez, telles que courrier électronique, points d'ancrage Web, etc..
Enfin, les problèmes d'infrastructure n'apparaissent souvent pas soudainement, le contexte historique est important. La mémoire vive sera lentement consommée pendant des heures avant que la boîte ne commence à tomber en panne, le disque se remplira pendant des jours avant que les choses ne se gâtent. La vérification ponctuelle de vos serveurs ne vous donne pas le contexte historique dont vous avez besoin pour empêcher les problèmes de se produire. S'il vous arrive de vérifier l'utilisation du disque lorsqu'il est un peu saturé, vous pouvez y remédier. Sinon, vous ne saurez que sur le problème lorsque vos boîtes mourront. New Relic collecte les données et les renvoie à leurs serveurs à tout moment, de sorte que les tableaux de bord traitent uniquement du contexte historique. Cela rend très facile de préempter certaines catégories de problèmes.
Laissez-moi vous raconter quelques histoires. Nous utilisons New Relic dans Tuts + pour la surveillance des performances des applications et celle des serveurs. Il y a quelques mois, j'étais de garde lorsque nos boîtes ont commencé à mal se comporter toutes les quelques minutes. Ils ne tombaient pas tout à fait, mais l'application fonctionnerait très mal pendant de courtes périodes. Je me suis connecté aux boîtes et j'ai constaté que l'utilisation de la mémoire était très importante. J'ai donc redémarré les serveurs un à un et les choses semblaient bien se passer pendant un moment. Mais quelques heures plus tard, tout a recommencé. Cela sentait comme une fuite de mémoire.
Je me suis donc connecté à New Relic pour consulter les graphiques. Effectivement, l'un des déploiements que nous avons effectués précédemment avait introduit une fuite de mémoire dans l'application. Cela prendrait quelques heures pour que toute la mémoire soit consommée par l'application, à quel point elle entrerait dans une frénésie désespérée en matière de récupération de place entraînant toutes sortes de problèmes amusants. En regardant les graphiques de la mémoire sur toutes les cases, il était immédiatement évident que ce qui se passait. À l'époque, aucune alerte n'avait été configurée (nous le faisons maintenant). Nous n'avons donc pas eu connaissance du problème avant que d'autres problèmes ne se manifestent. Mais, étant en mesure de comparer toutes les boîtes les unes aux autres, ainsi que le contexte historique, permettez-moi de diagnostiquer facilement le problème, de mettre en place une solution et de dormir à l'heure prévue cette nuit-là..
En voici un autre. Récemment, il y a eu une panne dans le centre de données AWS où Tuts + est hébergé. Lorsque les choses se sont finalement arrangées, nous avons redémarré toutes les boîtes pour nous assurer qu’il n’y avait pas de problèmes mineurs. Mais lorsque les boîtes sont revenues, l'application renvoyait par intermittence 500 réponses ou donnait de très mauvaises performances dans certains cas. C'était probablement un problème avec un ou plusieurs des serveurs, ce qui est très ennuyeux à diagnostiquer lorsque vous avez plusieurs boîtes. Une fois encore, regarder New Relic nous a permis de faire surface très rapidement. Une de nos boîtes est revenue avec un processus frauduleux qui consomme beaucoup de temps processeur, ce qui entraîne une mauvaise performance de l'application sur cette boîte. Une autre boîte était affectée par une sorte de problème AWS qui entraînait une utilisation à 100% des entrées-sorties de disque de cette boîte. Nous avons sorti cette boîte de notre équilibreur de charge, éliminé le processus frauduleux de l'autre et l'application a recommencé à fonctionner correctement.
Les graphiques fournis par New Relic sont vraiment utiles et je ne voudrais pas me passer d’eux, laissez-moi vous montrer comment mettre en place la surveillance des serveurs..
Tout se résume à la connexion à votre serveur et à l’installation du démon de surveillance du serveur New Relic (Nrsysmond). Si vous avez lu l'article de New Relic pour PHP, la procédure est presque identique. Comme d'habitude, supposons que nous sommes sur Ubuntu.
La première chose à faire est d’importer la clé du référentiel New Relic:
wget -O - https://download.newrelic.com/548C16BF.gpg | sudo apt-key add -
Maintenant, nous ajoutons le référentiel New Relic lui-même au système:
sudo sh -c 'echo "deb http://apt.newrelic.com/debian/ newrelic non-libre"> /etc/apt/sources.list.d/newrelic.list'
Maintenant, nous utilisons simplement apte:
sudo apt-get mise à jour sudo apt-get installer newrelic-sysmond
Une fois l’installation terminée, vous recevrez un joli message comme celui-ci:
************************************************* ************************************************ ************************************** *** *** Impossible de démarrer la nouvelle relique Server Monitor jusqu'à ce que vous insériez une clé de licence valide *** dans le fichier suivant: *** *** /etc/newrelic/nrsysmond.cfg *** *** Vous pouvez le faire en exécutant la commande suivante en tant que root: * ** *** nrsysmond-config --set license_key =*** *** Aucune donnée ne sera rapportée jusqu'à ce que le moniteur du serveur puisse démarrer. *** Vous pouvez obtenir votre clé New Relic dans la section 'Configuration' *** du menu 'Support' de votre compte New Relic (accessible à l'adresse suivante: *** https://rpm.newrelic.com). *** ********************************************** ********************** *************************** ******************************************
Faisons ce qu'il dit. Tout d'abord, passons aux paramètres de notre compte New Relic pour rechercher notre clé de licence (celle-ci sera à droite):
Maintenant exécutons la commande:
nrsysmond-config --set license_key =
Si vous vérifiez le fichier de configuration maintenant: /etc/newrelic/nrsysmond.cfg. Vous verrez votre clé de licence ici. Nous sommes prêts à démarrer l'agent:
/etc/init.d/newrelic-sysmond start
Vous pouvez maintenant vérifier votre liste de processus pour vous assurer qu'elle fonctionne:
ps -ef | grep nrsys newrelic 10087 1 0 09:25? 00:00:00 / usr / sbin / nrsysmond -c /etc/newrelic/nrsysmond.cfg -p /var/run/newrelic/nrsysmond.pid newrelic 10089 10087 0 09:25? 00:00:00 / usr / sbin / nrsysmond -c /etc/newrelic/nrsysmond.cfg -p /var/run/newrelic/nrsysmond.pid ubuntu 10100 9734 0 09:25 pts / 1 00:00:00 grep - -couleur = auto nrsys
Selon l'agent PHP, il existe deux processus. L'un est un processus de surveillance et le second est le travailleur. Le travailleur communique effectivement avec les serveurs New Relic. Le processus de surveillance le surveille simplement et si celui-ci décède, quelle qu'en soit la raison, il en génère un nouveau..
Nous pouvons également consulter les journaux pour nous assurer qu'il n'y a pas d'erreur au démarrage:
cat /var/log/newrelic/nrsysmond.log 2014-05-25 09:25:02 [10089 / main] always: Nouvelle version de Relic Server Monitor 1.4.0.471/C+IA démarrée - pid = 10089 background = true SSL = true ca_bundle =ca_path = host = ip-10-196-10-195 2014-05-25 09:25:03 [10089 / main] info: redirection RPM: collector-102.newrelic.com (50.31.164.202) port 0 (0 signifie port par défaut) )
Tout semble aller pour le mieux et vous devriez maintenant commencer à voir apparaître des données dans l'interface utilisateur de New Relic..
La plupart du temps, vous n'avez pas besoin de configurer autre chose que la clé de licence, mais si vous avez besoin d'améliorer le niveau de journalisation ou de configurer un proxy, c'est tout à fait possible. Tout vit dans /etc/newrelic/nrsysmond.cfg. Le dossier est très bien commenté et assez explicite. Si vous changez quelque chose, souvenez-vous de redémarrer le démon:
/etc/init.d/newrelic-sysmond restart
Lors de la configuration de la surveillance de serveur, il n’ya qu’une subtilité dans le nom du serveur, comme on le verra dans les tableaux de bord de New Relic. Par défaut, New Relic prendra le nom d’hôte de la boîte de dialogue et en fera le nom du serveur dans les tableaux de bord (c’est-à-dire la sortie du nom d'hôte commander). Je vous recommande de le garder de cette façon. Si vous utilisez également New Relic pour la surveillance des applications, conservez le nom d’hôte, tel que généré par le nom d'hôte commande, car le nom du serveur garantira que New Relic pourra déterminer correctement quelles applications sont exécutées sur quelles boîtes et lier le tout correctement dans l'interface utilisateur.
Si vous en avez vraiment besoin, vous pouvez modifier le nom du serveur tel qu'il apparaîtra dans l'interface utilisateur en définissant le paramètre nom d'hôte = paramètre dans le fichier de configuration: /etc/newrelic/nrsysmond.cfg. Vous devrez redémarrer le démon pour que cela prenne effet. Vous pouvez également modifier le nom du serveur directement dans l'interface utilisateur, sans affecter le démon..
La première chose que vous voyez lorsque vous cliquez sur le Les serveurs lien à gauche est un instantané de tous vos serveurs et les mesures clés pour chacun d'eux (CPU, disque, mémoire, entrées / sorties).
Cette page peut vous permettre de voir si une ou plusieurs de vos boîtes se comportent mal. Ici, vous pouvez également renommer un serveur ou y ajouter des balises, si nécessaire..
Si nous cliquons sur l'un des serveurs, nous arrivons au tableau de bord du serveur principal:
Il y a six métriques principales ici:
Cela vous donnera un aperçu rapide d'un serveur particulier. Vous pouvez explorer chacun des graphiques pour obtenir plus d'informations. Par exemple, vous pouvez explorer le graphique de la CPU pour voir quels processus utilisent la CPU:
Vous pouvez aussi explorer le graphique du disque pour voir votre taux d'E / S, une ventilation des lectures et des écritures, ainsi qu'une estimation du temps qu'il vous faudra avant que votre disque soit plein..
La meilleure partie est que vous pouvez utiliser les mêmes opérations sur tous ces graphiques que sur les graphiques au niveau de l'application. Vous pouvez donc effectuer un zoom avant sur une fenêtre de cinq minutes pour examiner de plus près une pointe de l'utilisation du processeur, ou consulter une tendance de l'utilisation de la mémoire sur sept jours..
La meilleure partie est que les graphiques sont simples à comprendre, vous n'êtes pas submergé de statistiques et vous pouvez comparer des zones similaires les unes aux autres. Cela peut vous aider à diagnostiquer 99% des problèmes courants que vous êtes susceptible de rencontrer avec votre infrastructure..
New Relic a récemment beaucoup travaillé pour améliorer ses capacités d'alerte. Les stratégies d’alerte correspondent à ce qu’elles ont imaginé sur l’ensemble du système (par exemple, il existe des stratégies d’alerte pour les applications et les règles du serveur pour les boîtes). Cela peut paraître un peu déroutant au début, mais c’est assez simple une fois que vous avez compris le principe. Il existe deux concepts principaux, les politiques et les canaux. En termes d'alertes serveur, cela fonctionne comme ceci:
Nous établissons une politique et lui attribuons des serveurs:
Vous créez également un canal (e-mail, webhook, par exemple) auquel des alertes peuvent être envoyées:
Vous affectez ensuite un canal à une politique. À partir de ce moment, en fonction des paramètres du canal (par exemple, premier événement critique, tous les événements critiques, temps d'indisponibilité uniquement). Vous recevrez des notifications sur ce canal.
Le seul élément déroutant à propos des politiques d'alerte est l'endroit où les trouver. Ils vivent sous Outils-> Stratégies d'alerte:
Vous devez ensuite cliquer sur Les serveurs dans le menu en haut, pour trouver les politiques d'alerte du serveur.
Si vous utilisez déjà une solution de surveillance d'infrastructure telle que Nagios et que cela fonctionne bien pour vous, la surveillance du serveur New Relic ne vous apportera peut-être pas beaucoup plus (bien que les graphiques et les tendances historiques soient excellents). Toutefois, si vous ne surveillez pas du tout votre infrastructure ou si votre solution actuelle ne fonctionne pas pour vous, essayez certainement New Relic. Pour moi, c'est devenu le premier outil auquel je m'adresse quand je soupçonne que quelque chose ne va pas avec mes serveurs. Et assez souvent, cela me permettra de savoir que des problèmes se préparent avant que la situation ne devienne critique. En tant que développeurs, c'est le genre d'outils que nous voulons tous dans notre arsenal.
Accentsconagua