Cómo usar una herramienta de APM para monitorear el rendimiento de las aplicaciones

El monitoreo del rendimiento de aplicaciones (APM) permite llevar un seguimiento de las métricas y los eventos clave del software, lo que te permite descubrir información valiosa de todo tipo: desde la velocidad de carga de la página y los cuellos de botella del rendimiento hasta las interrupciones y los errores del servicio. Con una solución de APM moderna, puedes corregir problemas en tu aplicación de manera proactiva al reducir al mínimo el bucle de análisis y permitir la identificación rápida y la resolución de problemas a la vez que reduces los riesgos de seguridad beneficiando a los usuarios finales y la rentabilidad.

Convertir el APM en una práctica diaria puede parecer abrumador al principio, de modo que es importante dividir el proceso en pasos manejables para que puedas enfocarte en estrategias de monitoreo eficaces y así alcanzar todo el potencial del APM. Este artículo describe los pasos básicos para implementar una solución de APM moderna: desde concebir un plan y preparar los equipos de ingeniería para la instrumentación de tus servicios hasta configurar alertas para los incidentes, así como crear dashboards para monitorear el rendimiento de las aplicaciones. Si deseas más información sobre APM y por qué se necesita para monitorear el rendimiento de tus aplicaciones, consulta ¿Qué es APM?

También aprenderás a dar los primeros pasos con la herramienta New Relic APM en cuestión de minutos. La cuenta gratuita te otorga 100 GB de ingesta de datos gratis al mes, un usuario de acceso completo y un número ilimitado de usuarios Basic gratis. Esta imagen muestra un dashboard de APM en New Relic que ilustra las transacciones que consumen más tiempo en una aplicación:

Paso 1: Trazar un plan para la estrategia de monitoreo

Primero tienes que decidir qué es lo que vas a monitorear. ¿Quieres comenzar poco a poco y enfocarte en monitorear un solo servicio? ¿O tienes la intención de monitorear todo en tu aplicación? Ambos enfoques tienen sus ventajas, pero te convendría trabajar para tener un monitoreo completo de todos tus servicios para garantizar que conseguirás la observabilidad completa de todos los sistemas.

Con aplicaciones altamente distribuidas, es importante que tomes en cuenta todos los servicios que estás usando, desde los proveedores en la nube hasta los servidores on-prem pasando por las API y más. Las aplicaciones que son más pequeñas o las que usan una arquitectura monolítica serán más fáciles de instrumentar y monitorear.

Comienza poco a poco: monitorea un solo servicio

Monitorear un solo servicio te permitirá probar una solución de APM con un mínimo de riesgo y costo. Por ejemplo, una cuenta de New Relic te permite probar el APM y otras características del producto de manera gratuita, y con los 100 GB mensuales de ingesta de datos, podrás analizar una cantidad importante de datos de telemetría. También te dará la oportunidad de aprender a utilizar una herramienta de APM líder en la industria y decidir cuál es el siguiente paso para integrar datos de una amplia variedad de fuentes de telemetría para gozar de una perspectiva más holística de tu stack tecnológico. Este enfoque también puede ser eficaz si necesitas convencer a un gerente o ejecutivo de que es una buena idea implementar el monitoreo del rendimiento de aplicaciones (APM) de manera generalizada. Por último, comenzar a usar una solución de APM en pequeña escala puede ser una forma eficaz de monitorear y depurar un servicio problemático sin preocuparse del aprovisionamiento a gran escala.

Paso 2: Instrumentar la aplicación

Después de auditar tus servicios y tener claro qué es lo que vas a monitorear, te conviene instrumentar la aplicación. La instrumentación es el proceso de instalar un agente en el entorno de la aplicación. Un agente monitorea los datos que fluyen a través de tu aplicación y los envía a la solución de APM. A estos datos también se les conoce como telemetría.

Los servicios se pueden instrumentar de muchas maneras, dependiendo de la solución de APM que se use y los servicios que se instrumenten.

Instalación guiada de una solución de APM

Algunas soluciones de APM ofrecen instalaciones guiadas para que puedas instrumentar automáticamente tu aplicación. Estas instalaciones normalmente ofrecen asistencia paso a paso para configurar y desplegar agentes de APM dentro de una aplicación, lo que hace que el proceso sea más accesible a las personas interesadas (tanto técnicas como no técnicas). 

Las instalaciones guiadas también ayudan a los equipos a definir y configurar indicadores de nivel de servicio (SLI) y objetivos de nivel de servicio (SLO), para asegurar que el APM se adapte a las métricas de rendimiento más importantes para el negocio. 

Al seguir los procedimientos de instalación guiada, los equipos pueden hacer seguimiento de los datos de rendimiento y visualizarlos, además de identificar cuellos de botellas y ocuparse de manera proactiva de asuntos que podrían perjudicar la experiencia del usuario.

Instrumentación personalizada

También puedes utilizar la instrumentación personalizada y los SDK para instrumentar los servicios. La instrumentación personalizada se puede utilizar para monitorear frameworks no compatibles y también para agregar monitoreo a las transacciones que tu solución de APM no monitorea automáticamente.

A diferencia de las soluciones listas para usar, la instrumentación personalizada ofrece la flexibilidad de definir y capturar métricas que son únicas para la arquitectura y los requisitos de una aplicación. Por lo general, este proceso implica agregar fragmentos de código o configuraciones de agente APM para monitorear las transacciones de negocio críticas, las interacciones de los usuarios u otros eventos propios de las aplicaciones. La instrumentación personalizada es útil cuando las soluciones listas para usar podrían no dar abasto a todas las sutilezas de una aplicación compleja o altamente especializada. 

Al invertir en la instrumentación personalizada, obtendrás información precisa sobre el rendimiento de funciones específicas, podrás detectar problemas a tiempo y optimizar la experiencia del usuario en función de sus objetivos y prioridades particulares. Este nivel de flexibilidad da a los equipos lo que necesitan para tomar decisiones basadas en los datos y mejorar de manera proactiva el rendimiento y la fiabilidad de su aplicación.

Si ninguna de las dos funciona, prueba el reenvío de logs

Habrá veces en que no podrás instrumentar un servicio. En este caso, podrás usar el reenvío de logs para reenviar los logs de ese servicio a la solución de APM.

Al reenviar logs de la aplicación a un sistema de APM, tu equipo puede monitorear eventos y errores específicos de la aplicación, aun en entornos distribuidos o contenerizados. 

Recomendamos usar este método cuando se integra el APM con aplicaciones o sistemas heredados que podrían no ser compatibles con la instrumentación nativa. A través del reenvío de logs, se puede extraer contexto importante de los logs para usarlo en el análisis de rendimiento y la resolución de problemas.

Omitir la instrumentación por completo

Por último, siempre se puede optar por no instrumentar los servicios, lo que algunas veces puede ser motivo de preocupación con servicios que manejan datos confidenciales. Sin embargo, la solución de APM siempre debe satisfacer los requisitos más exigentes en relación a la seguridad, la privacidad y el cumplimiento. 

Si tienes dudas sobre si tu solución de APM se ajusta al cumplimiento que necesitas, es hora de considerar otra solución. Las soluciones como la de New Relic dan prioridad al cumplimiento y a la privacidad. New Relic cumple con las normas para las leyes de protección de datos alrededor del mundo, e incluso puedes solicitar que tu cuenta sea compatible con HIPAA.

Para instrumentar tu aplicación con New Relic, consulta Instalar APM.

Paso 3: Auditar los servicios

Ya sea que quieras ir poco a poco o que quieras monitorear el mayor número de servicios posible, el siguiente paso tiene que ser auditar el estado de tus servicios: cambios de despliegue, transacciones clave, objetos de nivel de servicio (SLO), estado de la infraestructura, disponibilidad de los proveedores en la nube, tiempo de respuesta de las aplicaciones y más. Tener un panorama completo de tu stack tecnológico te puede ayudar a priorizar cuáles servicios deseas monitorear o, mejor aún, te puede ayudar a garantizar un monitoreo completo para tus aplicaciones.

Las plataformas de APM modernas como New Relic pueden facilitar este proceso porque descubren automáticamente las aplicaciones, la infraestructura y las fuentes de logs que se están ejecutando en tu entorno. New Relic también ayuda a cerrar las brechas de instrumentación al recomendar lo que debería instrumentarse, con lo que se hace mucho más fácil configurar y desplegar el monitoreo del rendimiento de aplicaciones (APM) en todos los sistemas.

Paso 4: Monitorear toda la aplicación para obtener información valiosa diariamente

Si bien el riesgo de comenzar poco a poco es mínimo a corto plazo, a la larga, es necesario cerrar las brechas en la cobertura del monitoreo para comprender el impacto de los problemas en sentido ascendente y descendente, descubrir tendencias emergentes y obtener la información necesaria para evitar problemas potenciales. Si no cuentas con una cobertura completa, te enfrentarás a un tiempo medio de detección (MTTD) y un tiempo medio de resolución (MTTR) más prolongados, lo que consumirá valiosos recursos de ingeniería y potencialmente minará la moral del equipo y retrasará la innovación. También habrá mayores riesgos en la rentabilidad y la posibilidad de que los usuarios finales dejen de usar tu aplicación. Identifica los sistemas clave y prioriza los esfuerzos para cerrar las brechas de instrumentación que te acercan más a un panorama completo de todo tu stack.

Paso 5: Elegir las métricas y personalizar los dashboards

Una vez que hayas instrumentado tu aplicación, los datos de telemetría comenzarán a fluir hacia tu solución de APM. Una buena solución de APM genera algunas métricas automáticamente —tiempo de respuesta, rendimiento, tasa de errores, uso del CPU y otras— y las presenta por medio de dashboards y visualizaciones. Estas métricas ofrecen un buen punto de partida, pero seguramente habrá otras métricas que querrás monitorear en función de los KPI y objetivos de tu equipo. En el caso de New Relic, puedes usar llamadas API para reportar los datos de telemetría personalizados.

Personalización de los dashboards de APM

También puedes personalizar los dashboards para que muestren las métricas más relevantes. Puedes elegir qué métricas mostrar y crear visualizaciones personalizadas para tener una mejor idea del rendimiento de tu aplicación.

La siguiente captura de pantalla muestra el número de personas en distintas ciudades que están viendo New Relic dentro de una organización. La visualización personalizada utiliza la nueva interfaz de línea de comando (CLI) de New Relic y un diagrama de árbol de la biblioteca Recharts.

Paso 6: Crear una comprensión común del estado del sistema

Después de implementar una solución de APM, debes considerar las capacidades y restricciones de los equipos y usuarios que monitorean tus servicios para impulsar la adopción generalizada y sacar el máximo valor de tu práctica de APM. Puede ser que quieras que los ingenieros de DevOps y los de fiabilidad del sitio (SRE) tengan acceso a algunos dashboards, y que los equipos de desarrollo y los gerentes de software tengan acceso a otros. Los equipos deben tener acceso a los dashboards relacionados con su trabajo, pero también es importante promover la colaboración entre todos los equipos y evitar que se formen silos porque los problemas de las aplicaciones pueden afectar a muchos servicios y equipos.

Algunas soluciones de APM también tienen tipos de usuarios con distintos precios y distintos accesos a las características. En el caso de New Relic, puedes tener todos los usuarios Core que quieras gratis. Sin embargo, hay un costo adicional de $49/usuario en los planes New Relic Standard, Pro y Enterprise.

El siguiente video muestra cómo otorgar roles de acceso a los usuarios en New Relic.

Paso 7: Configurar las alertas

Una vez que hayas identificado las métricas más importantes, conviene configurar alertas para notificar a los equipos tan pronto como ocurran problemas o se alcancen umbrales críticos. Para configurar alertas, debes responder las siguientes preguntas:

• ¿Qué condiciones deben activar alertas? Por ejemplo, puede ser que quieras activar alertas cuando el tiempo de carga promedio de la página de un determinado producto caiga por debajo de cierto umbral.
• ¿Cómo se define el umbral para cada alerta? Si el umbral se establece muy alto, tus equipos no recibirían alertas durante incidentes críticos. Si, por el contrario, se define muy bajo, tus equipos recibirían alarmas falsas. Eso puede ocasionar un exceso de alertas y también generar muchas alertas sobre incidentes sin importancia y ocultar las alertas críticas que sí necesitan atención inmediata. En el caso de New Relic, también puedes usar la inteligencia aplicada para crear umbrales dinámicos. Por ejemplo, puedes establecer alertas de rendimiento con distintos umbrales, según si tu aplicación se encuentra en un periodo de uso intenso o en un periodo de uso reducido, como en medio de la noche.
• ¿Qué equipos deben recibir las alertas? ¿Tienes un equipo que administra y clasifica todas las alertas? ¿O tienes que notificar a distintos equipos según el servicio que se vea afectado? Por cada política de alertas que configures, tienes que decidir qué equipos deben recibir las alertas.
• ¿Qué canales usas para las alertas? Las soluciones de APM como New Relic ofrecen distintas maneras de alertar a los equipos, entre ellas, Slack, PagerNow y correo electrónico.

El video que sigue describe cómo navegar de un incidente de alerta a una causa raíz en New Relic.

Paso 8: Sentar las bases de colaboración entre los equipos

Cuando ocurre un incidente crítico, es posible que varios equipos se apresuren a buscar la causa raíz del problema. ¿Dónde se origina el problema: en la infraestructura, el código, el proveedor de la nube o algo más? Identificar y corregir un problema generalmente implica la colaboración de distintos equipos, pero si tus equipos están aislados, el MMTD y el MTTR serán más lentos. Lo ideal es que la solución de APM que utilices incluya características que promuevan una mejor colaboración entre los equipos.

Por ejemplo, Errors Inbox en New Relic permite que los equipos se comuniquen entre ellos directamente en la solución de APM. Puedes usar Slack y Errors Inbox para compartir y discutir rápidamente sobre el importante contexto relacionado con los problemas a medida que se presentan.

La siguiente imagen muestra los errores agrupados en Errors Inbox.

Paso 9: Simplificar el flujo de trabajo y seguir las mejores prácticas

Puedes reducir el MTTD y el MTTR aún más si continúas simplificando tu flujo de trabajo y siguiendo las mejores prácticas de APM. Las ventajas que esto trae van más allá de la reducción del MTTR ya que tus equipos podrán contar con más tiempo para trabajar en los proyectos que más les interesan. Además, eliminar la fricción de los flujos de trabajo puede contribuir a reducir el agotamiento y el desánimo. A continuación describimos algunas mejores prácticas:

• Estandarizar las convenciones de nombres. Tu solución de APM debe incluir nombres descriptivos para las aplicaciones con agentes. De lo contrario, será más difícil identificar los servicios monitoreados, especialmente si tus aplicaciones crecen y necesitas monitorear más servicios. 
• Etiquetar los datos. También puedes etiquetar los datos para que sea más fácil filtrar y clasificar datos a un nivel alto. Usa pares clave-valor ("key-value") para agregar metadatos importantes como la región y el entorno.
• Combinar la solución de APM con CI/CD. Si estás usando un proceso de integración continua/entrega continua (CI/CD), puedes usar una herramienta de APM para monitorear la canalización de tu despliegue. Herramientas como el inicio rápido de CircleCI de New Relic te permiten ver los datos analíticos relacionados con los trabajos de integración continua.
• Documentar el flujo de trabajo de monitoreo. La documentación es un elemento importante para garantizar que todos los equipos que usan el monitoreo del rendimiento de aplicaciones (APM) comprendan cómo funciona el producto. También es útil para la integración de los ingenieros nuevos en los procesos.
• Reducir el cambio de contexto de una herramienta a otra. Por ejemplo, puede ser que tengas que cambiarte entre los dashboards de APM, el editor de código y varias otras herramientas para la comunicación, el control de versiones y la documentación. Tener que cambiarse de un contexto a otro quita tiempo y supone una carga mental adicional. En el caso de New Relic, puedes usar la integración de New Relic CodeStream para cambiarte fácilmente del APM al IDE y viceversa. Puedes seleccionar un error en un dashboard de New Relic e ir directamente a la línea que está causando el error en el editor de código. Con CodeStream, también puedes planificar, revisar y depurar código con colaboradores directamente en el IDE, lo que te permite poder contar con revisores adicionales para actualizar o revertir el código cuando sea necesario.

La siguiente imagen muestra cómo usar New Relic CodeStream para comunicarte con otras personas en relación al código.