Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Web Development
Code

Cómo Usar New Relic Con PHP y WordPress

by
Difficulty:BeginnerLength:LongLanguages:
This post is part of a series called Performance Monitoring With New Relic.
Using New Relic to Monitor Your Android App
Optimizing Application Performance with New Relic for iOS
Sponsored Content

This sponsored post features a product relevant to our readers while meeting our editorial guidelines for being objective and educational.

Spanish (Español) translation by RRGG (you can also view the original English article)

Anteriormente, hemos explicado cómo configurar New Relic para una aplicación de Rails, y hemos dedicado mucho tiempo a ver cómo usar la interfaz de usuario de New Relic. Y si bien la interfaz de usuario es muy similar, independientemente del idioma y el marco que esté utilizando, realmente conseguir la configuración de New Relic puede ser radicalmente diferente. Hoy veremos cómo controlar una aplicación PHP utilizando New Relic. Más específicamente, configuraremos una instalación básica de WordPress y obtendremos algunos datos de rendimiento sobre ella, en los paneles de New Relic.

Conseguir que New Relic esté configurado para Ruby es muy poco acorde con el entorno. Simplemente agregamos la gema agente a nuestra aplicación y en ese momento, sin importar cómo implementamos nuestra aplicación (Passenger + Apache, Thin + Nginx, etc.), la gema hará el resto del trabajo para garantizar que obtengamos nuestras métricas de rendimiento. Con la versión PHP del agente, el entorno es mucho más importante, ya que el agente está instalado y vive en la caja donde se implementará la aplicación, en lugar de ser parte de una aplicación en particular.

Vamos a configurar un sandbox para jugar (usando una instancia EC2) y obtener una instalación básica de WordPress en funcionamiento.

Configurando Nuestro Sandbox

No vamos a entrar en demasiados detalles aquí ya que la mayoría de las cosas que debemos hacer están bien documentadas en otros lugares. Pero, aquí hay un esquema básico.

Necesitamos lanzar una instancia EC2 con Ubuntu Server 12.04 LTS en ella. Si no desea configurar una instancia de EC2, puede simplemente crear una máquina virtual en su lugar usando VirtualBox (o su herramienta de VM). Si está configurando una instancia de EC2, debe recordar hacer lo siguiente:

  • descargue su clave (si ha creado una nueva durante el proceso de configuración), para que pueda SSH en su instancia
  • agregue una regla adicional a cualquier grupo de seguridad que le dé a su instancia para permitir conexiones HTTP a la instancia (para que podamos acceder a nuestro blog de WordPress a través del navegador más adelante)

Aparte de eso, todo lo demás debería ser bastante directo y deberías terminar con una instancia en ejecución (o máquina virtual) que esté lista para el próximo paso.

Ahora necesitamos instalar Apache, PHP y MySQL. Con Ubuntu Server, debería ser una simple cuestión de ejecutar los siguientes comandos:

Deberá seleccionar LAMP en la interfaz de usuario y también deberá ingresar su contraseña de MySQL cuando se le solicite (lo dejo en blanco, ya que no nos importa que este cuadro sea seguro de ninguna manera). Una vez que la instalación esté completa, podremos ejecutar algunos comandos para asegurarnos de que todo esté instalado sin problemas.

Primero compruebe que Apache está instalado:

En segundo lugar, compruebe que tenemos PHP:

Y luego compruebe que tenemos MySQL:

También es posible que necesitemos verificar que PHP esté realmente habilitado en nuestra configuración de Apache, pero desde que instalamos lamp-server usando tasksel podemos estar bastante seguros de que lo es (y siempre podemos hacer un script rápido de phpinfo () si realmente queremos comprobar).

Ahora podemos instalar WordPress. Antes de que realmente lo descarguemos, necesitamos configurar una base de datos para ello. Solo podemos seguir las instrucciones del Codex:

Voy a llamar a nuestra nueva instalación myblog1 (por lo que la base de datos también se llama myblog1). Ahora necesitamos ejecutar los siguientes comandos para ejecutar nuestro blog (no olvide sudo cuando sea necesario):

Ahora complete el nombre de su base de datos, nombre de usuario y contraseña en el archivo de configuración (el nombre de host es localhost, que está allí por defecto). En este punto, debe poder ir a su navegador, presionar la URL correcta (en mi caso http://ec2-107-20-122-116.compute-1.amazonaws.com/myblog1) y WordPress hará su cosa (no estaría mal reiniciar Apache antes de hacer este reinicio del servicio sudo apache2).

Nuestro sandbox ahora está completo y podemos comenzar con la instalación de New Relic.

Instalando New Relic

Como mencioné anteriormente, el agente PHP New Relic reside en la caja, por lo tanto, tiene sentido que pueda instalarlo usando el administrador de paquetes del sistema operativo (apt-get ya que estamos usando Ubuntu). Lo primero que debe hacer es importar la clave del depósito New Relic:

Ahora agregamos el repositorio de New Relic al sistema:

En este punto, podemos usar los comandos apt estándar para instalar el agente:

Esto obtiene el paquete del agente PHP del repositorio y coloca el script de instalación del agente en el sistema. El script se llama newrelic-install y vive en / usr / bin, por lo que debería poder ejecutar desde cualquier lugar. La secuencia de comandos también tiene un nombre desafortunado, ya que puede usarlo tanto para instalar como para desinstalar New Relic de su sistema. Para instalar New Relic, necesitamos ejecutar:

El script es interactivo y le pedirá que ingrese su clave de licencia. Puede encontrar esto presionando el botón rojo grande cuando está configurando una nueva aplicación PHP dentro de la interfaz de usuario de New Relic.

Si tiene más de una instalación de PHP en su sistema, también le pedirá que elija para qué instalación instalar New Relic (puede elegir cualquier cantidad de instalaciones, incluidas todas). Si solo tiene un PHP en su sistema, el script simplemente usará ese. Vale la pena señalar que si su versión de PHP es anterior a 5.2, la secuencia de comandos se rescatará ya que las versiones anteriores no son compatibles.

Si todo va bien, debería ver el siguiente mensaje:

El script luego imprimirá información adicional para usted, incluida la ubicación de los archivos de registro:

Además del hecho de que necesita reiniciar su servidor web (y PHP-FPM si lo está usando).

Si reinicia su servidor y sigue el registro del daemon, debería ver algo como esto:

Algo denominado Aplicación PHP está informando. Esto es algo genérico y no se parece en nada a nuestro blog de WordPress, pero es un buen comienzo. Lo que esto significa es que todas las aplicaciones en su servidor web se ejecutan e informan como la misma aplicación a New Relic. Esta aplicación tiene un nombre predeterminado de Aplicación PHP.

En nuestro caso, dado que solo estamos ejecutando una aplicación (nuestra instalación de WordPress), podríamos saltar a la interfaz de usuario de New Relic y obtener estadísticas razonables para nuestro blog. Pero, por supuesto, queremos darle un nombre mejor a nuestro blog y, por si acaso, queremos que nuestro servidor sirva más de una aplicación. También queremos ver cómo separar aplicaciones entre sí. Veremos cómo hacerlo en breve, pero antes de hacerlo, veamos qué hace realmente un agente de PHP.

Como Se Ve Una Instalación Saludable

Hay dos partes para el agente New Relic PHP. La primera es una extensión PHP, es un objeto compartido llamado newrelic.so. Si miramos el archivo de configuración del agente:

Podemos verlo listado en la parte superior:

Esto es lo que realmente recopilará las estadísticas de sus aplicaciones, pero no enviará las estadísticas a New Relic, este es el trabajo del daemon proxy.

El daemon del agente es un proxy entre la extensión de PHP y los servidores de New Relic. Básicamente, la extensión de PHP dará los datos que recopila al daemon y el daemon hará cosas como prepararlos y determinar cuándo enviarlos al servidor. Debe asegurarse siempre de que el daemon se esté ejecutando; de lo contrario, no se enviarán datos a New Relic. Afortunadamente, de forma predeterminada, cada vez que reinicie su servidor, la extensión de PHP intentará detectar si el daemon se está ejecutando y lo iniciará, si no es así.

Un demonio proxy en ejecución tiene dos procesos. Uno es un proceso de monitoreo y el segundo es el trabajador. El trabajador realmente hace el trabajo de comunicarse con los servidores de New Relic, el proceso de monitoreo simplemente observa al trabajador y si el trabajador muere, por el motivo que sea, generará uno nuevo. Puede detener al daemon ejecutando:

Lo cual enviará una señal de apagado al proceso de monitoreo. El proceso de monitoreo matará el proceso de trabajo y luego se apagará. Si alguna vez necesita matar al daemon manualmente, asegúrese de finalizar el proceso de monitoreo antes de matar al trabajador (de lo contrario, se generará un nuevo trabajador, obviamente).

Configurando el Agente (y el Proxy Daemon)

Ya hemos visto el archivo de configuración del agente New Relic PHP /etc/php5/cli/conf.d/newrelic.ini. Tanto el agente como el daemon se configuran utilizando este archivo.

Este archivo está muy bien documentado con todas las opciones y sus valores predeterminados en la lista. Vamos a hablar sobre el formato de este archivo. El agente New Relic Ruby se puede configurar a través de YAML, que es un formato bien conocido. El agente de PHP es simplemente un archivo de texto, pero necesitamos un poco de estructura. Cada variable en el archivo tiene uno de cuatro tipos (String, Boolean, Number, Duration). La cadena y el número son autoexplicativos, los valores booleanos pueden ser verdaderos, en o 1 para indicar la veracidad y falso, apagado o 0 para indicar falsedad. Las duraciones son cadenas con un formato particular, por ejemplo: "1w3d23h10m" indica una semana, tres días, 23 horas y diez minutos. Los valores para duraciones pueden ser tan granulares como microsegundos.

Todas las variables en el archivo también tienen un 'alcance'. Hay tres posibles ámbitos: SYSTEM, PERDIR y SCRIPT. Las variables que tienen alcance del SISTEMA solo se pueden establecer en el archivo de configuración global. Las variables con un alcance PERDIR pueden establecerse en el archivo de configuración global y también pueden anularse por directorio. Las variables con alcance de script pueden ser globales, por directorio, y también pueden sobrescribirse mediante programación.

Por ejemplo, la variable de configuración más común es `newrelic.appname`. Esta variable es un tipo de cadena, tiene un valor predeterminado de Aplicación PHP (ahora sabemos por qué vimos ese valor en el archivo de registro después de que instalamos el agente y reiniciamos el servidor). El alcance de esta variable es PERDIR, que nos da una idea sobre cómo sobrescribir el nombre de la aplicación para nuestro blog de WordPress.

Hay muchas otras variables que controlan cosas como la ubicación de los archivos de registro, si se registran consultas SQL o no, el nivel de registro de la salida de registro y demás. Lo invito a estudiar el archivo newrelic.ini para familiarizarse con las opciones.

Configurando una Aplicación Separada para su Blog de WordPress

Queremos ver una aplicación separada en la interfaz de usuario de New Relic para nuestro blog de WordPress, así que veamos cómo podemos lograrlo. Sus opciones para la configuración por directorio son diferentes dependiendo de su pila, si está utilizando PHP-FPM, los pasos son diferentes que si está usando Nginx. En nuestro caso, dado que corremos directamente con Apache, tenemos dos opciones.

En primer lugar, si tenemos un host virtual para nuestra aplicación, podemos insertar un bloque IfModule en nuestro bloque de host virtual y modificar el nombre de la aplicación allí:

Pero no tengo un host virtual especial solo para el blog, entonces la otra opción es usar un archivo .htaccess. Asegúrese de permitir realmente archivos .htaccess, volcando lo siguiente en su host virtual principal:

Ahora podemos poner un archivo .htaccess en el directorio de nivel superior de nuestro blog y poner lo siguiente en él:

El formato es exactamente el mismo que si lo estuviera colocando en el bloque IfModule. Ahora solo debemos botar nuestro servidor. Si alineamos los registros de daemon cuando el servidor se reinicia, veremos lo siguiente:

La Aplicación PHP todavía está allí, pero ahora tiene un amigo que es nuestro blog de WordPress. Y aquí está en la interfaz de usuario:

Ahora recibiremos métricas mientras navegamos por nuestro blog, tanto para el front-end como para la interfaz de administración. Debido a que New Relic es compatible con WordPress desde el primer momento, las métricas deberían dividirse sensiblemente (cuando un marco no es compatible, las medidas tenderán a agruparse).

Actualizando el Agente y Daemon

New Relic es una pieza compleja de software y es bueno mantenerlo actualizado ya que los errores se solucionan regularmente y se agregan nuevas características. Ya que instalamos todo usando apt-get, mantener las cosas al día es fácil. Simplemente hacemos lo mismo que hicimos para instalarlo:

Si no hemos instalado otro PHP en el sistema, ahora solo necesitamos reiniciar nuestro servidor y estaremos actualizados. Si hay un nuevo PHP, es posible que necesitemos volver a ejecutar el script newrelic-install.

Solo hay una advertencia para todo esto. En determinadas situaciones, puede ejecutar el daemon proxy New Relic por separado del agente, lo que significa que reiniciar el servidor no inicia automáticamente el daemon si no se está ejecutando (esto se llama modo daemon externo). Puede haber varias razones por las que desea hacer esto, por ejemplo, es posible que desee que un usuario diferente sea el propietario del proceso del daemon para que los registros solo sean visibles para ese usuario. En esta situación, debe recordar reiniciar el servidor y reiniciar el daemon proxy. Si no lo hace, verá errores de "falta de coincidencia de protocolo" en los registros.

Conclusión

Como puede ver, configurar New Relic para una aplicación PHP es muy diferente de configurarlo para Ruby, su aplicación real ni siquiera tiene en cuenta el proceso, mientras que el entorno en el que se implementa es central. Afortunadamente, esto significa que si está utilizando cualquier marco PHP compatible, el proceso para configurar New Relic es exactamente el mismo. Además de WordPress, la mayoría de los marcos de PHP populares son compatibles, incluyendo Cake, Symphony y Laravel (versión 4 y superior). También es posible utilizar New Relic con un marco no admitido, pero deberá hacer un esfuerzo serio para que las medidas tengan sentido.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.