El monitoreo del rendimiento de aplicaciones (APM) permite llevar un seguimiento de las métricas y los eventos clave de una aplicación, otorgando 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 buena solución de APM, puedes corregir problemas en tu aplicación de manera proactiva beneficiando a los usuarios finales y la rentabilidad.

Comenzar a trabajar con APM puede parecer abrumador, y por eso es importante dividir el proceso en pasos manejables y adoptar las mejores prácticas. Este artículo describe los pasos básicos para implementar una solución de APM: desde concebir un plan y preparar a los equipos hasta instrumentar los servicios y configurar alertas para los incidentes.  Si deseas más información sobre APM y por qué es importante, 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:

Concebir un plan

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 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 APIs y más. Las aplicaciones que son pequeñas o las que usan una arquitectura monolítica serán más fáciles de monitorear.

Comenzar en pequeña escala 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 estándar en la industria y decidir si es la solución adecuada para tu caso particular. 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.

Si bien comenzar poco a poco tiene un riesgo mínimo a corto plazo, a largo plazo, querrás evitar brechas en tu cobertura de monitoreo. Si no cuentas 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. También habrá mayores riesgos en la rentabilidad y la posibilidad de que los usuarios finales dejen de usar tu aplicación. 

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 los servicios: servidores, infraestructura, proveedores en la nube, aplicaciones y más. Tener un panorama completo de tus servicios te puede ayudar a priorizar cuáles servicios deseas monitorear o, mejor aún, puede ayudar a asegurarte de contar con monitoreo completo para tus aplicaciones.

Las herramientas 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. Entonces New Relic recomienda qué 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.

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.

Algunas soluciones de APM ofrecen instalaciones guiadas para que puedas instrumentar automáticamente tu aplicación. Pero 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.

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.

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.

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.

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.

Otorgar acceso a APM

Después de implementar una solución de APM, debes decidir quién tendrá acceso a ella. Eso significa que debes considerar las capacidades y restricciones de los equipos y usuarios que monitorean los servicios. 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 Basic que quieras gratis, mientras que los usuarios Full y Core tienen un costo asociado.

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

Configurar 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.

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 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.

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.