Comment utiliser New Relic avec PHP et WordPress

Nous avons déjà expliqué comment configurer l'application New Relic pour une application Rails et passé beaucoup de temps à étudier l'utilisation de l'interface utilisateur de New Relic. Et tandis que l'interface utilisateur est très similaire quels que soient le langage et le framework que vous utilisez, la configuration de New Relic peut être radicalement différente. Aujourd'hui, nous verrons comment surveiller une application PHP à l'aide de New Relic. Plus précisément, nous allons configurer une installation WordPress de base et obtenir des données de performance à ce sujet dans les tableaux de bord New Relic..

La mise en place d’une nouvelle relique pour Ruby est très agnostique en matière d’environnement. Nous ajoutons simplement la gemme d'agent à notre application. Peu importe la manière dont nous déployons notre application (Passenger + Apache, Thin + Nginx, etc.), la gemme effectuera le reste du travail pour nous assurer d'obtenir nos indicateurs de performance. Avec la version PHP de l'agent, l'environnement est beaucoup plus important, car l'agent est installé et réside sur le boîtier où l'application sera déployée, plutôt que de faire partie d'une application particulière.. 

Configurons un bac à sable pour nous (avec une instance EC2) et obtenons une installation WordPress de base.

Mise en place de notre bac à sable

Nous n'entrerons pas dans les détails ici car la plupart des choses que nous devons faire sont bien documentées ailleurs. Mais, voici un aperçu de base.

Nous devons lancer une instance EC2 avec Ubuntu Server 12.04 LTS dessus. Si vous ne souhaitez pas configurer une instance EC2, vous pouvez simplement créer une machine virtuelle à l'aide de VirtualBox (ou de l'outil de votre choix de machine virtuelle). Si vous configurez une instance EC2, vous devez vous rappeler de procéder comme suit:

  • téléchargez votre clé (si vous en avez créée une au cours du processus de configuration), de sorte que vous puissiez SSH dans votre instance
  • ajouter une règle supplémentaire à tout groupe de sécurité que vous attribuez à votre instance pour autoriser les connexions HTTP à l'instance (afin que nous puissions accéder à notre blog WordPress via le navigateur ultérieurement)

En dehors de cela, tout le reste devrait être assez simple et vous devriez vous retrouver avec une instance en cours d'exécution (ou une machine virtuelle) prête pour la prochaine étape..

Nous devons maintenant installer Apache, PHP et MySQL. Avec Ubuntu Server, il suffit de lancer les commandes suivantes:

sudo apt-get installer tasksel sudo tasksel installer lamp-server

Vous devrez sélectionner LAMP dans l'interface utilisateur et vous devrez également entrer votre mot de passe MySQL lorsque vous y serez invité (je le laisse juste en blanc, car nous ne nous soucions pas de la sécurité de cette boîte de dialogue). Une fois l’installation terminée, nous pouvons exécuter quelques commandes pour nous assurer que tout est installé sans problème.. 

Commencez par vérifier qu'Apache est installé:

ubuntu @ ip-10-145-246-196: ~ $ apache2 -V Version du serveur: Apache / 2.2.22 (Ubuntu) Version du serveur: 12 juillet 2013 13:37:10 Numéro magique du module du serveur: 20051115: 30 Serveur chargé: APR 1.4.6, APR-Util 1.3.12 Compilé à l'aide de: APR 1.4.6, APR-Util 1.3.12 Architecture: Serveur MPM 64 bits: Préfork threaded: non forké: oui (nombre de processus variable)… 

Deuxièmement, vérifiez que nous avons PHP:

ubuntu @ ip-10-145-246-196: ~ $ php -i phpinfo () Version PHP => 5.3.10-1ubuntu3.10 Système => Linux ip-10-145-246-196 3.2.0-58- virtual # 88-Ubuntu SMP Mardi Dec 3 17:58:13 UTC 2013 x86_64 Date de construction => 28 février 2014 23:13:16 API du serveur => Interface de ligne de commande Prise en charge du répertoire virtuel => fichier de configuration désactivé (chemin d'accès) => / etc / php5 / cli Fichier de configuration chargé => /etc/php5/cli/php.ini… 

Et puis vérifiez que nous avons MySQL:

ubuntu @ ip-10-145-246-196: ~ $ mysql --version mysql Ver 14.14 Distrib 5.5.35, pour debian-linux-gnu (x86_64) à l'aide de readline 6.2

Nous devrons peut-être aussi vérifier que PHP est bien activé dans notre configuration Apache, mais depuis que nous avons installé lampe serveur en utilisant tâches on peut en être sûr (et on peut toujours faire un rapide phpinfo () script si nous voulons vraiment vérifier).

Nous pouvons maintenant installer WordPress. Avant de le télécharger, nous devons mettre en place une base de données. Nous pouvons simplement suivre les instructions du Codex:

ubuntu @ ip-10-145-246-196: ~ $ mysql Bienvenue sur le moniteur MySQL. Les commandes se terminent par; ou \ g. Votre identifiant de connexion MySQL est 103 Version du serveur: 5.5.35-0ubuntu0.12.04.2 (Ubuntu) Tapez 'help;'; ou '\ h' pour obtenir de l'aide. Tapez '\ c' pour effacer l'instruction d'entrée actuelle. mysql> CREATE DATABASE myblog1; Requête OK, 1 ligne affectée (0.00 sec) mysql> DONNEZ TOUS LES PRIVILÈGES SUR myblog1. * TO "myblog1_user" @ "localhost" IDENTIFIÉ PAR "abc123"; Requête OK, 0 ligne affectée (0.00 sec) mysql> FLUSH PRIVILEGES; Requête OK, 0 lignes affectées (0.01 sec) mysql> EXIT Bye

Je vais appeler notre nouvelle installation myblog1 (ainsi la base de données pour elle est aussi nommée myblog1). Nous devons maintenant exécuter les commandes suivantes pour que notre blog fonctionne (n'oubliez pas de sudo quand c'est nécessaire):

cd / var / www wget http://wordpress.org/latest.tar.gz tar -xzvf latest.tar.gz mv wordpress myblog1 cd myblog1 mv wp-config-sample.php wp-config.php

Entrez maintenant le nom de votre base de données, votre nom d’utilisateur et votre mot de passe dans le fichier de configuration (le nom d’hôte est localhost qui est là par défaut). À ce stade, vous devriez pouvoir accéder à votre navigateur et cliquer sur la bonne URL (dans mon cas, http://ec2-107-20-122-116.compute-1.amazonaws.com/myblog1) et WordPress fera son travail (redémarrer Apache avant de faire ça redémarrage du service sudo apache2).

Notre bac à sable est maintenant terminé et nous pouvons commencer à installer New Relic..

Installer une nouvelle relique

Comme je l'ai mentionné précédemment, l'agent PHP New Relic réside sur la boîte. Il est donc logique que vous puissiez l'installer à l'aide du gestionnaire de paquets du système d'exploitation (apt-get depuis que nous utilisons 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'

À ce stade, nous pouvons utiliser la norme apte commandes pour installer l'agent:

sudo apt-get mise à jour sudo apt-get installer newrelic-php5

Cela récupère le package d'agent PHP du référentiel et place le script d'installation de l'agent sur le système. Le script s'appelle newrelic-install et il vit dans / usr / bin, vous devriez donc pouvoir courir de n'importe où. Le script porte aussi malheureusement un nom, car vous pouvez l’utiliser pour installer et désinstaller New Relic de votre système. Pour installer New Relic, nous devons exécuter:

newrelic-install install

Le script est interactif et vous demandera de saisir votre clé de licence. Vous pouvez le trouver en appuyant sur le bouton gros bouton rouge lorsque vous configurez une nouvelle application PHP dans l'interface utilisateur de New Relic.

Si vous avez plus d’une installation PHP sur votre système, il vous demandera également de choisir l’installation pour laquelle New Relic doit être installé (vous pouvez choisir un nombre illimité d’installations, y compris toutes les installations). Si vous ne possédez que le seul PHP sur votre système, le script ne l'utilisera que. Il est à noter que si votre version de PHP est antérieure à la version 5.2, le script sera suspendu car les versions antérieures ne sont pas prises en charge..

Si tout se passe bien, vous devriez voir le message suivant:

New Relic est maintenant installé sur votre système. Toutes nos félicitations!

Le script affichera ensuite des informations supplémentaires pour vous, notamment l'emplacement des fichiers journaux:

/var/log/newrelic/newrelic-daemon.log /var/log/newrelic/php_agent.log

En plus du fait que vous devez redémarrer votre serveur Web (et PHP-FPM si vous l'utilisez).

Si vous redémarrez votre serveur et réduisez le journal du démon, vous devriez voir quelque chose comme ceci:

ubuntu @ ip-10-145-246-196: / var / www / myblog1 $ cat /var/log/newrelic/newrelic-daemon.log 2014-03-23 ​​05: 30: 41.063 (2008 / main) attention: actuel limite de fichier de 1024 est trop basse - tentative d'augmentation 2014-03-23 ​​05: 30: 41.064 (2008 / main) info: augmentation de la limite de fichiers à 2048 2014-03-23 ​​05: 30: 41.064 (2008 / main) info : New Relic 4.6 (release build 40 - "quetzalcoatlus" - "e3d29c5a2e5dc1ee455e831d589ecf5e18c7d6f0") [travailleurs = 1 écoutez = "/ tmp / .newrelic.sock" pid = 2008 ppid = 2007 uid = 0 euid = 0 euid = 0 backtrace = no os = "Linux" rel = "3.2.0-58-virtual" mach = "x86_64" ver = "# 88-Ubuntu SMP mar 3 déc 17" node = "ip-10-145-246-196" démarrage = agent] 2014-03-23 ​​05: 30: 41.069 (2008 / main) info: config RPM: proto = "https" collector = "collector.newrelic.com" proxy = "none" certfile = "/ etc / ssl /certs/ca-certificates.crt "certdir =" / etc / ssl / certs "2014-03-23 ​​05: 35: 14.928 (2008 / connector) info: ['Application PHP'] 'Rattaché à: https: // rpm.newrelic.com/accounts/232928/applications/3262356 '

Quelque chose nommé Application PHP rapporte. C'est un peu générique et ne ressemble pas du tout à notre blog WordPress, mais c'est un bon début. Cela signifie que toutes les applications de votre serveur Web s'exécutent et sont signalées comme la même application à New Relic. Cette application a un nom par défaut de Application PHP

Dans notre cas, comme nous n'exécutons qu'une seule application (notre installation WordPress), nous pourrions en fait accéder à l'interface utilisateur de New Relic et obtenir des statistiques raisonnables pour notre blog. Mais, bien sûr, nous voulons donner à notre blog un meilleur nom et, au cas où, nous voulons que notre serveur serve plus d'une application. Nous voulons également voir comment séparer les applications les unes des autres. Nous verrons bientôt comment procéder, mais avant cela, voyons ce qui constitue un agent PHP..

À quoi ressemble une installation saine

L'agent PHP New Relic comprend deux parties. Le premier est une extension PHP, c'est un objet partagé appelé newrelic.so. Si nous regardons le fichier de configuration de l'agent:

/etc/php5/cli/conf.d/newrelic.ini

Nous pouvons le voir énuméré tout en haut:

; Ce fichier contient les différents paramètres de l'agent New Relic PHP. Là ; Il existe de nombreuses options, qui sont toutes décrites en détail à l’URL suivante: https://newrelic.com/docs/php/php-agent-phpini-settings; ; Si vous utilisez un chemin complet vers l'extension, vous vous isolez du; Le répertoire d'extension change si vous modifiez les installations ou les versions de PHP. ; Si vous n'utilisez pas de chemin absolu, le fichier doit être installé dans le répertoire; répertoire d'extension de la configuration active. extension = "newrelic.so"

C’est la chose qui collectera les statistiques de vos applications, mais elle n’enverra pas les statistiques à New Relic, c’est le travail du démon proxy..

Le démon de l'agent est un proxy entre l'extension PHP et les serveurs New Relic. Pour l’essentiel, l’extension PHP va donner les données qu’elle recueille au démon et celui-ci va faire des choses comme le mettre en lot et déterminer le moment de l’envoyer au serveur. Vous devez toujours vous assurer que le démon est en cours d'exécution, sinon aucune donnée ne sera envoyée à New Relic. Heureusement, par défaut, chaque fois que vous redémarrez votre serveur, l’extension PHP essaiera de détecter si le démon est en cours d’exécution et le lancera, si ce n’est pas le cas..

Un démon proxy en cours d'exécution a 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. Si celui-ci décède, quel qu'en soit le motif, il en génère un nouveau. Vous pouvez arrêter le démon en lançant:

/etc/init.d/newrelic-daemon stop

Ce qui enverra un signal d'arrêt au processus de surveillance. Le processus de surveillance va alors tuer le processus de travail, puis se fermer. Si vous avez besoin de tuer le démon manuellement, assurez-vous de terminer le processus de surveillance avant de tuer le travailleur (sinon, un nouveau travailleur sera créé - évidemment)..

Configuration de l'agent (et du démon proxy)

Nous avons déjà vu le fichier de configuration de l'agent New Relic PHP /etc/php5/cli/conf.d/newrelic.ini. L'agent et le démon sont configurés à l'aide de ce fichier..

Ce fichier est très bien documenté avec toutes les options et leurs valeurs par défaut répertoriées. Parlons du format de ce fichier. L'agent New Relic Ruby peut être configuré via YAML, un format bien connu. L'agent PHP est simplement un fichier texte, mais nous avons besoin d'un peu de structure. Chaque variable du fichier a l'un des quatre types (chaîne, booléen, nombre, durée). La chaîne et le nombre vont de soi, les valeurs booléennes peuvent être vrai, sur ou 1 pour indiquer la véracité et faux, hors ou 0 pour indiquer la fausseté. Les durées sont des chaînes avec un format particulier, par exemple: "1w3d23h10m" indique une semaine, trois jours, 23 heures et dix minutes. Les valeurs des durées peuvent être aussi granulaires que des microsecondes..

Toutes les variables du fichier ont également une "portée". Il y a trois portées possibles: SYSTEM, PERDIR et SCRIPT. Les variables qui ont une portée SYSTEM ne peuvent être définies que dans le fichier de configuration global. Les variables avec une étendue PERDIR peuvent être définies dans le fichier de configuration globale et peuvent également être remplacées par répertoire. Les variables avec une étendue de script peuvent être globales, par répertoire, et peuvent également être remplacées par programme.

Par exemple, la variable de configuration la plus courante est 'newrelic.appname'. Cette variable est un type String, sa valeur par défaut est Application PHP (Nous savons maintenant pourquoi nous avons vu cette valeur dans le fichier journal après avoir installé l'agent et redémarré le serveur). La portée de cette variable est PERDIR, ce qui nous donne une idée de la façon de remplacer le nom de l'application pour notre blog WordPress.. 

Il existe de nombreuses autres variables qui contrôlent des éléments tels que l'emplacement des fichiers journaux, le fait que les requêtes SQL soient enregistrées ou non, le niveau de journalisation de la sortie du journal, etc. Je vous encourage à étudier le newrelic.ini fichier pour vous familiariser avec les options.

Configuration d'une application distincte pour notre blog WordPress 

Nous souhaitons voir une application distincte dans l'interface utilisateur de New Relic pour notre blog WordPress. Voyons donc comment nous pouvons y arriver. Vos options pour la configuration par répertoire sont différentes selon votre pile. Si vous utilisez PHP-FPM, les étapes sont différentes de celles utilisées si vous utilisez Nginx. Dans notre cas, puisque nous courons directement avec Apache, nous avons deux options.

Tout d'abord, si nous avons un hôte virtuel pour notre application, nous pouvons insérer un IfModule bloquer dans notre bloc hôte virtuel et modifier le nom de l'application ici:

 php_value newrelic.appname "Mon blog 1" 

Mais je n’ai pas d’hôte virtuel spécial juste pour le blog, l’autre option est d’utiliser un .htaccess fichier. Assurez-vous que vous autorisez réellement .htaccess fichiers, en ajoutant les éléments suivants à votre hôte virtuel principal:

 Options Index FollowSymLinks MultiViews AllowOverride All Ordre autoriser, refuser autoriser de tous 

Nous pouvons maintenant mettre un .htaccess fichier dans le répertoire de niveau supérieur de notre blog et mettez-y le texte suivant:

php_value newrelic.appname "Mon blog 1"

Le format est exactement le même que si je le mettais dans le IfModule bloc. Il ne reste plus qu’à faire rebondir notre serveur. Si nous suivons les journaux du démon au redémarrage du serveur, nous verrons ce qui suit:

ubuntu @ ip-10-145-246-196: / var / www / myblog1 $ cat /var/log/newrelic/newrelic-daemon.log 2014-03-23 ​​05: 30: 41.063 (2008 / main) attention: actuel limite de fichier de 1024 est trop basse - tentative d'augmentation 2014-03-23 ​​05: 30: 41.064 (2008 / main) info: augmentation de la limite de fichiers à 2048 2014-03-23 ​​05: 30: 41.064 (2008 / main) info : New Relic 4.6 (release build 40 - "quetzalcoatlus" - "e3d29c5a2e5dc1ee455e831d589ecf5e18c7d6f0") [travailleurs = 1 écoutez = "/ tmp / .newrelic.sock" pid = 2008 ppid = 2007 uid = 0 euid = 0 euid = 0 backtrace = no os = "Linux" rel = "3.2.0-58-virtual" mach = "x86_64" ver = "# 88-Ubuntu SMP mar 3 déc 17" node = "ip-10-145-246-196" démarrage = agent] 2014-03-23 ​​05: 30: 41.069 (2008 / main) info: config RPM: proto = "https" collector = "collector.newrelic.com" proxy = "none" certfile = "/ etc / ssl /certs/ca-certificates.crt "certdir =" / etc / ssl / certs "2014-03-23 ​​05: 35: 14.928 (2008 / connector) info: ['Application PHP'] 'Rattaché à: https: // rpm.newrelic.com/accounts/232928/applications/3262356 '2014-03-23 ​​06: 07: 58.768 (2008 / connecteur) i nfo: ['Mon blog 1'] '' Reportant à: https://rpm.newrelic.com/accounts/232928/applications/3262424 '

le Application PHP est toujours là, mais maintenant il a un ami qui est notre blog WordPress. Et le voici dans l'interface utilisateur:

Nous allons maintenant recevoir des mesures au fur et à mesure de la navigation sur notre blog, tant pour l'interface frontale que pour l'interface d'administration. Puisque New Relic prend en charge WordPress dès la livraison, les métriques doivent être divisées de manière judicieuse (lorsqu'un framework n'est pas pris en charge, les métriques ont tendance à être regroupées)..

Mise à jour de l'agent et du démon

New Relic est un logiciel complexe qu'il est bon de garder à jour, les bugs corrigés régulièrement et de nouvelles fonctionnalités ajoutées. Depuis que nous avons tout installé en utilisant apt-get, Garder les choses à jour est facile. Nous faisons simplement la même chose que nous avons fait pour l'installer:

apt-get update apt-get installer newrelic-php5

Si nous n’avons pas installé un autre PHP sur le système, nous devons simplement redémarrer notre serveur et nous serons à jour. S'il y a un nouveau PHP, il faudra peut-être relancer le newrelic-install scénario.

Il n'y a qu'une mise en garde à tout cela. Dans certaines situations, vous pouvez exécuter le démon proxy New Relic séparément de l'agent, ce qui signifie que le redémarrage du serveur ne lance pas automatiquement le démon s'il n'en est pas un (mode démon externe). Cela peut être dû à plusieurs raisons. Par exemple, vous pouvez souhaiter qu'un utilisateur différent soit propriétaire du processus démon afin que les journaux ne soient visibles que par cet utilisateur. Dans cette situation, vous devez vous rappeler de redémarrer le serveur et de redémarrer le démon proxy. Si vous ne le faites pas, vous verrez des erreurs «incompatibilité de protocole» dans les journaux.

Conclusion

Comme vous pouvez le constater, la configuration de New Relic pour une application PHP est très différente de celle de Ruby; votre application réelle ne prend même pas en compte le processus, alors que l'environnement dans lequel vous déployez est central. Heureusement, cela signifie que si vous utilisez un framework PHP pris en charge, le processus de configuration de New Relic est exactement le même. Outre WordPress, la plupart des frameworks PHP populaires sont pris en charge, notamment Cake, Symphony et Laravel (version 4 et ultérieure). Il est également possible d’utiliser New Relic avec un framework non supporté, mais vous devrez faire un effort sérieux pour que les métriques aient un sens..