APM en Node.js: métricas, transacciones y alertas en tiempo real

Si estás desarrollando proyectos backend y los tienes en producción, en algún momento vas a necesitar monitorizarlos. Y para eso existe un concepto que muchos desarrolladores no conocen: APM, o Application Performance Monitoring.

La idea es simple: añades una biblioteca extra a tu proyecto de backend y, a partir de ahí, cada acción se monitoriza. Cada petición que se ejecuta, si el servidor se cayó, si hay consumo extra de CPU o de red. Empezar a usarlo es relativamente sencillo, pero casi nadie lo hace.

En este artículo te explico qué es APM y cómo usarlo paso a paso desde ManageEngine Applications Manager, montando una API de Node.js desde cero.

🔥 Contenido patrocinado por ManageEngine

Este artículo es parte de una colaboración pagada con ManageEngine. La instalación, las pruebas y las observaciones son mías, incluyendo las limitaciones que encontré.

👉 Pruébalo con 30 días gratis: ManageEngine Applications Manager

¿Qué es APM?

El funcionamiento es directo. Tienes una aplicación cliente que le pide algo a un servidor, y ese servidor responde. Pero esas respuestas no siempre funcionan, porque en producción nunca hay un solo cliente: hay muchos, y todos al mismo tiempo.

Cuando hablamos de una aplicación en producción hay que tener en cuenta ese tipo de peticiones, no una sola. Y ahí aparecen las formas de monitorizar qué está pasando.

La forma básica: logs

A medida que usas el servidor, este va escribiendo registros en algún archivo. Cuando a futuro necesitas saber por qué falló algo, entras y lo revisas.

Funciona. Pero implica entrar al VPS, buscar archivos y leerlos a mano.

La forma avanzada: delegarlo a una plataforma

Aquí es donde entra APM. En tu código de servidor llamas a un paquete adicional —una biblioteca del lenguaje que uses— y esa biblioteca comunica tu servidor con una plataforma externa.

A partir de ese momento, cada petición a tu servidor se registra en esa plataforma. Ya no revisas archivos sueltos dentro de un VPS: entras a tu cuenta y ahí están todos los registros. Peticiones, caídas del servidor, qué rutas tomaron más tiempo en responder.

Qué edición de Applications Manager te toca

ManageEngine es una plataforma completa enfocada en operaciones de IT: hay aplicaciones para monitoreo de todo tipo, gestión de seguridad y analíticas avanzadas. La que nos interesa aquí es Applications Manager, que permite monitorizar aplicaciones y se integra con más de 150 tecnologías.

En el video mencioné dos ediciones, pero en realidad son tres, y la que falta es relevante:

Dato importante que no mencioné en el video: el trial de 30 días es completo, sin restricciones de monitores. Y cuando se acaba, la instalación se convierte automáticamente en la edición Free si no aplicas una licencia comercial. No se te apaga ni pierdes lo instalado: te quedas con 5 monitores para siempre. Para un proyecto personal eso puede ser suficiente.

También conviene saber que APM Insight es un módulo con precio propio en la página pública de precios, separado del monitoreo base. Si vas a evaluarlo en serio, revisa el desglose antes de asumir un costo.

APM en la práctica

Paso 1: instalar Applications Manager

Este es un producto autoalojado, lo cual es parte de su propuesta: los datos de monitoreo se quedan en infraestructura que tú controlas.

Te registras con el trial de 30 días y descargas el instalador. Hay versión de Windows (64 bits) y de Linux. En mi caso usé Windows, pero los pasos son exactamente los mismos si lo vas a ejecutar en un servidor, que es lo que harías en producción.

La instalación es siguiente-siguiente. Puedes elegir español. Al final se levanta la aplicación en el puerto 9090, se abre el navegador, te pide usuario, registras una contraseña nueva, y ya estás dentro del panel.

Paso 2: crear la API

Para tener algo que monitorizar, monté una API desde cero usando Cursor. Creé una carpeta —ecommerce-api— la abrí con el agente y le pedí:

Crea una REST API para un e-commerce con productos, categorías,
usuarios y demás datos. Incluye un seed de datos.

El seed es simplemente datos de ejemplo, para que la API tenga algo que devolver.

En segundos tenía el proyecto corriendo en localhost. Consultando /api/products desde el navegador ya se veía el arreglo completo de información. Después le pedí también documentación con Swagger, que va bien para tener las rutas a la vista.

Paso 3: añadir el monitor en APM Insight

En el panel de Applications Manager vas a APM → Add New Monitor y eliges el lenguaje. En este caso, Node.js.

Ahí la plataforma te da los pasos a ejecutar. El primero es descargar el agente, que es la aplicación que se une a tu backend para comunicarlo con la plataforma de monitoreo.

Paso 4: instalar el agente

Descomprimes la carpeta del agente, abres una terminal en tu proyecto y ejecutas:

npm install /ruta/a/la/carpeta/del/agente

También existe la vía directa desde el registro público:

npm i apminsight --save

Esto crea un directorio apminsight dentro de node_modules.

Paso 5: importar la biblioteca

La biblioteca tiene que añadirse al inicio del archivo de arranque. Esto no es un detalle estético: el agente necesita instrumentar los módulos antes de que tu aplicación los cargue.

Según cómo esté escrito tu proyecto:

// CommonJS
require('apminsight');

// ECMAScript Modules
import apminsight from 'apminsight';

// TypeScript
import AgentAPI from 'apminsight';
AgentAPI.config();

Puedes copiar y pegar la versión que corresponda en tu agente de IA y pedirle que la añada:

Añade esta línea de código para monitorizar el proyecto usando
ManageEngine Application Manager: [pegas el snippet]

Un truco que ahorra pasos: pásale también la URL del panel (está en localhost, en la misma máquina). Cursor puede navegar ahí, leer la documentación y terminar de configurarlo solo. En el video mostré el paso a paso manual para que se entienda qué está pasando por debajo, pero en la práctica se puede delegar casi todo.

Dos advertencias que están en la documentación oficial y conviene no saltarse:

• El agente es incompatible con otras herramientas de profiling, incluido correr Node en modo debugger con --inspect. Si lo tienes activo, desactívalo.
• Si tu aplicación usa el módulo cluster, el require tiene que estar tanto en el proceso master como en los workers. Si no, solo vas a ver una parte del tráfico.

Paso 6: el archivo de configuración y la licencia

El siguiente paso es descargar el archivo de configuración —apminsightnode.json— y añadirle tu clave de licencia. Tiene esta forma:

{
  "licenseKey": "APMI_tu_clave_aqui",
  "appName": "ecommerce-api",
  "port": "3000",
  "apmHost": "localhost",
  "apmPort": "8443"
}

La clave la copias desde el panel con el botón de copiar al portapapeles.

Mantén esa clave segura y no la compartas, porque es la forma en que tu aplicación se conecta a tu plataforma. Si se te escapa, se puede regenerar, así que tampoco es el fin del mundo.

Si prefieres no tener el archivo, los mismos valores se pueden pasar como variables de entorno, que es lo recomendable en producción:

APMINSIGHT_LICENSE_KEY=...
APMINSIGHT_APP_NAME=...
APMINSIGHT_APP_PORT=...

Último paso: reiniciar la API. Eso es todo.

Qué ves en el panel

Volviendo a la sección APM, ya aparece la aplicación detectada corriendo en el puerto 3000. Al principio no hay métricas porque nadie ha pedido nada aún, así que hay que generar tráfico:

Crea un test de todas las rutas para que el APM muestre métricas

Y ahí sí empiezan los gráficos.

El resumen

• Tiempo de respuesta promedio — en mi prueba, 8 ms
• Cantidad de peticiones y cuántas fallaron — 5,2% de error en mi caso
• Desglose de errores entre 4xx y 5xx
• Throughput — la salida de datos, qué tan rápido sirve el contenido

El gráfico de detalle es donde está el valor real. Yo veía una respuesta de 8 ms en un momento y de 1 ms un poco antes. Puedes analizar el porqué de esa caída, y como tienes la marca de tiempo exacta, puedes decirle a tu equipo que revise los logs justo en ese momento.

Transacciones

Entrando a una de las tarjetas ves las transacciones: las operaciones que se hacen desde cada ruta del backend, con su tiempo individual.

En una API de demo con rutas de items, carrito, cupones y usuarios esto no parece muy útil. Pero en una aplicación real es una de las mediciones que más vale la pena. Es lo que te dice qué características necesitan optimización de verdad. Si una ruta crítica —pagos, reservas de producto— está lenta, aquí es donde se ve.

Trazas, excepciones y mapa de servicios

• Seguimientos (traces) — las operaciones ejecutadas. En mi prueba había un 401 en un POST al login, un intento de obtener un producto inexistente, etcétera.
• Excepciones — cuando el backend lanza algún error.
• Mapa del servicio — cuántas instancias hay. En una app sencilla es solo una, pero en arquitecturas distribuidas es donde ves las dependencias.

Por qué la sección de base de datos salía vacía

Aquí pasó algo que vale la pena explicar bien, porque es el tipo de detalle que te hace perder una tarde.

APM Insight también mide las operaciones de base de datos, pero en mi proyecto esa sección estaba vacía. La razón: el proyecto usaba SQLite, y SQLite funciona desde archivo, no por red.

Los agentes de APM instrumentan drivers de bases de datos que se comunican por red. Esto es lo que está oficialmente soportado por el agente de Node.js:

SQLite no está, y no es un olvido: es una consecuencia de cómo funciona.

Si vas a probar esto, usa PostgreSQL o MySQL desde el principio para ver la parte de base de datos funcionando. Es justamente la sección que más te va a servir cuando tengas consultas lentas en producción.

Alertas y umbrales

El monitoreo sin alertas es un panel que nadie mira. En la parte superior, en acciones de controlador, puedes habilitar alertas a partir del historial o configurar umbrales propios.

En umbrales asociados para atributos defines sobre qué quieres ser notificado:

• Tiempo de respuesta por encima de cierto valor
• Utilización de CPU
• Consumo de red o ancho de banda
• Disponibilidad — es decir, si tu aplicación se cae, te llega una notificación

Cuando la condición llega a crítica, puedes invocar comandos. Ese es el punto donde el monitoreo deja de ser pasivo.

Es el paso que más gente se salta y el que más valor tiene: no necesitas estar pendiente, la plataforma lo está por ti.

Dónde más puedes usarlo

No tiene que ser estrictamente una aplicación de backend puro.

Next.js funciona, pero con un matiz que conviene entender: la lista oficial de frameworks soportados es Express, Koa y Hapi. Si tu Next.js tiene Express por debajo sirviendo el backend, el agente lo instrumenta. Next.js como tal no aparece en la lista de soporte oficial, así que si vas a depender de sus API routes nativas, pruébalo antes de asumir que va a capturar todo.

Los entornos donde se puede ejecutar el agente sí son amplios:

• Docker — con la instalación del agente dentro del Dockerfile
• Kubernetes — con detección automática de nombre de aplicación y soporte de auto-escalado
• AWS Elastic Beanstalk, y detección de entornos AWS y Azure
• PM2 en Kubernetes, vía la variable NODE_OPTIONS

Precisiones sobre el video

Tres cosas que revisé después de grabar:

1. Son tres ediciones, no dos. Existe una edición Free permanente de hasta 5 monitores, y cuando termina el trial de 30 días la instalación se convierte en esa edición en lugar de dejar de funcionar.
2. Ojo con la versión mínima de Node. La página de descripción del producto todavía dice "Node.js versión 4 y superior", pero las notas de versión del agente lo contradicen: desde la 4.8.0 el mínimo subió a v16.20.2, y desde la 5.4.1 (mayo de 2026) el mínimo es Node 18. Guíate por las notas de versión, no por la página de overview.
3. Next.js no está en la lista oficial de frameworks soportados. Funciona cuando hay Express por debajo, que es el caso que mencioné, pero no es lo mismo que soporte nativo.

Preguntas frecuentes

¿Qué diferencia hay entre APM y revisar logs? Los logs te dicen lo que tú decidiste escribir. El APM instrumenta automáticamente cada petición, mide tiempos, correlaciona transacciones y te alerta. Son complementarios: el APM te dice dónde mirar, los logs te dicen qué pasó exactamente ahí.

¿Afecta el rendimiento de mi aplicación? Todo agente de APM tiene algún costo. El impacto es bajo y se compensa con lo que ganas en visibilidad, pero es algo que conviene medir en tu propio caso antes de subirlo a producción.

¿Por qué mi sección de base de datos está vacía? Lo más probable es que uses una base de datos no soportada o basada en archivo, como SQLite. Los agentes instrumentan drivers que hablan por red: MySQL, PostgreSQL, SQL Server, MongoDB y Oracle.

¿Tengo que dejar el servidor de monitoreo corriendo en la misma máquina? No. En el artículo lo instalé localmente para mostrar el flujo, pero en producción el Applications Manager corre en su propio servidor y los agentes apuntan a él mediante apmHost y apmPort.

¿Sirve si solo tengo un proyecto pequeño? La edición Free de 5 monitores no caduca, así que sí. La pregunta real no es el tamaño del proyecto sino si está en producción con usuarios reales.

¿Qué hago si tengo la app en cluster o con PM2? En cluster, el require va tanto en el master como en los workers. Para PM2 en Kubernetes existe soporte vía la variable de entorno NODE_OPTIONS.

Conclusión

Empezar con APM es más sencillo de lo que suena: añades una biblioteca a tu backend y las métricas empiezan a llegar solas mientras el proyecto corre.

Lo que ganas con eso es lo importante. Dejas de adivinar qué rutas hay que optimizar, y si el proyecto se cae o pasa algo raro con tu backend, la plataforma te avisa sin que tengas que estar pendiente.

Si tienen dudas sobre APM o sobre cómo aplicarlo a su stack, déjenlas en los comentarios.

Recursos

• ManageEngine Applications Manager (LATAM)
• Documentación de APM Insight para Node.js
• Instalación del agente Node.js
• Notas de versión del agente
• Comparativa de ediciones

¿Tienes dudas sobre tu stack o quieres una asesoría personalizada? Encuéntrame en fazt.dev.