Introducción al APM: Monitorización y mejora del rendimiento de aplicaciones
Descubre qué es APM y cómo utilizarlo para monitorizar el rendimiento de tus aplicaciones en tiempo real. Aprende sus conceptos clave —transacciones, spans y trazas—, cómo analizar métricas como latencia y tasa de errores, y cómo configurar alertas para anticiparte a problemas antes de que impacten al usuario.
Artículo elaborado por:
Contenidos
- Introducción
- Fundamentos de APM
- Explorando la interfaz de APM
- Buenas prácticas
- Conclusiones
1. Introducción
¿Por qué mi aplicación va lenta?
¿Ese servicio que funcionaba bien ahora lanza errores?
¿La última actualización mejoró el rendimiento… o lo empeoró?
Cuando una aplicación crece, estas preguntas dejan de ser anecdóticas y se convierten en parte del día a día. Resolver incidencias es solo la mitad del trabajo: necesitamos saber si el problema está realmente solucionado, si podemos optimizar procesos y, sobre todo, si podemos anticiparnos antes de que afecte a los usuarios.
Para eso no basta con logs. Necesitamos visibilidad completa del comportamiento de la aplicación. Aquí es donde entra el APM (Application Performance Monitoring). En este artículo veremos qué es el APM, cómo funciona y cómo puede ayudarnos a detectar cuellos de botella, anticipar problemas y garantizar que cada cambio mejora la experiencia del usuario.
2. Fundamentos de APM
2.1. ¿Qué es APM?
APM es una solución de monitorización en tiempo real que permite observar el rendimiento de nuestras aplicaciones. Construido sobre Elastic Stack, APM recopila información clave como:
- Peticiones recibidas
- Tareas planificadas
- Tiempos de respuesta
- Errores
- Consultas a bases de datos y llamadas a otros servicios
Con estos datos, es posible identificar problemas antes de que afecten al usuario final. En la Figura 1 se observa una vista general del panel del APM.
2.2. ¿Cómo funciona?
APM se basa en agentes que se integran en el código de la aplicación. Estos agentes recolectan datos y los envían a ElasticSearch, donde pueden ser analizados a través de Kibana. La configuración es sencilla y consta de tres pasos independientemente de la tecnología empleada (Java, .NET, Node.js, Python, etc.):
- Instalar el agente. El método de instalación varía según la tecnología.
- Configurar propiedades (nombre del servicio, entorno o environment, muestreo…).
- Arrancar el agente. Normalmente, cuando se arranca la aplicación, el agente se pondrá en marcha. Ya podemos empezar a ver los datos recolectados. En el siguiente apartado se muestra cómo hacerlo.
La información relacionada con la instalación y configuración se puede encontrar aquí.
3. Explorando la interfaz de APM
Una vez configurado el agente y enviando datos a Elastic, el siguiente paso es aprender a interpretar la información en la interfaz del APM.
Para abrir el APM, debemos ir a Kibana, abrir el menú de hamburguesa (1) y luego, desde “Observability” (2), clicar en “Applications”(3). Allí podemos buscar nuestro servicio (4), el cual podemos seleccionar (5) (ver Figura 2).
NOTA: En versiones anteriores, el APM, en lugar de llamarse “Applications” en el menú, se llama “APM”.
3.1. Environment
Dentro de la interfaz del APM de nuestro servicio, tal como indica la Figura 3, podemos seleccionar el entorno (environment) que queremos observar. Este valor se define en las propiedades del agente y es fundamental porque condiciona la interpretación de los datos. No es lo mismo analizar métricas en producción, donde buscamos detectar incidencias reales bajo carga, que en un entorno de test, donde el objetivo es validar nuevas funcionalidades.
Filtrar por environment en Kibana permite segmentar la información y comparar métricas entre entornos, evitando que los datos de pruebas interfieran en el análisis de producción y facilitando decisiones más precisas.
3.2. Transactions, Spans y Traces
Otro punto importante en la interfaz es la pestaña de “Transactions”, seleccionada tal como muestra la Figura 4. Aquí podemos observar las operaciones de nuestro servicio, lo que tardan y la tasa de errores que tienen (ver Figura 5).
Para interpretarlas, hay que conocer estos tres conceptos:
3.2.1. Transaction
Es una unidad de trabajo lógico dentro de una aplicación. Representa el ciclo completo de una solicitud o tarea en la aplicación, como una llamada a una API o el procesamiento de una tarea en segundo plano. Las transacciones permiten rastrear el tiempo total que tarda la solicitud en ejecutarse y desglosar ese tiempo en componentes más pequeños.
3.2.2. Span
Es una operación individual dentro de una transacción. Un span representa una acción específica, como una llamada a una base de datos, una solicitud HTTP a otro servicio o la ejecución de un método. Los spans permiten desglosar el tiempo de una transacción en pasos más detallados, proporcionando una visión granular de las operaciones que componen una transacción completa (ver Figura 6).
3.2.3. Trace
Una traza (en inglés, trace) está compuesta por una transacción que agrupa otras transacciones. Esto nos permite ver el recorrido end‑to‑end de una petición a través de varios servicios (ver Figura 7). Para ver el interior de cada salto, todos los servicios implicados deben tener el agente APM. Si alguno no lo tiene, ese tramo aparecería como un span opaco (una “caja negra”). Sabríamos lo que tarda, pero no el por qué.
Una traza agrupa transacciones y spans correlacionados por el mismo trace‑id que describen el recorrido distribuido de una solicitud a través de varios servicios. Si un servicio que recibe la llamada está instrumentado con APM, crea su propia transacción enlazada a esa misma traza; si no lo está, el tramo aparece como span opaco (vemos el tiempo, pero no el detalle).
Por último, dependiendo de la tecnología, APM no solo captura spans y transacciones automáticamente, sino que también permite crearlos de forma manual en el código. Esto resulta útil para instrumentar operaciones críticas o añadir contexto adicional en procesos que no se detectan por defecto.
3.3. Metadatos y contexto
Además del tiempo invertido, cada transacción y span en APM incluye metadatos que describen el contexto en el que se ejecuta la operación. Entre ellos se encuentran datos generados por el propio agente, como el nombre y la versión del servicio, el entorno, detalles HTTP (método, URL, código), el stacktrace e información sobre consultas a bases de datos. Esto último puede observarse en la Figura 8. Estos metadatos permiten analizar qué ocurrió y en qué condiciones.
Además, es posible añadir información personalizada mediante tres mecanismos:
- Labels: pares clave-valor definidos por el desarrollador, indexables y filtrables en Kibana. Se utilizan para segmentar por atributos como cliente, dominio funcional o versión lógica.
- Custom context: espacio para incluir información adicional no filtrable, útil para aportar contexto específico.
- User context: datos del usuario (ID, email, nombre), que sí son filtrables y permiten analizar el impacto en perfiles concretos.
Tanto los metadatos automáticos como los definidos por el desarrollador pueden emplearse en consultas y filtros en Kibana, lo que facilita localizar transacciones relacionadas con un servicio, una versión o un conjunto concreto de condiciones. La Figura 9 muestra cómo se ven los metadatos de una transacción, incluyendo los propios del APM y los personalizados.
3.4. Métricas y análisis comparativo
Con los conceptos claros, podemos hablar de las tres métricas más importantes en APM que permiten evaluar el rendimiento:
- Throughput (rendimiento): Nos indica la cantidad de transacciones que procesa nuestra aplicación en un periodo de tiempo. Se mide en transacciones por minuto y nos puede servir para conocer la carga que maneja nuestro servicio. Suele utilizarse junto a la latencia.
- Latency (latencia): tiempo (en milisegundos) en completar una transacción. Indica velocidad.
- Failed Transaction Rate (FTR): Porcentaje de transacciones que acaban en error (excepción o HTTP 5xx). Indica calidad/estabilidad.
Estas métricas se representan en la interfaz mediante gráficos que permiten analizar su evolución temporal, como se aprecia en la Figura 10, donde se muestran la latencia, el throughput y el FTR en una sola vista. Esta disposición facilita la comparación entre métricas y la detección de anomalías en periodos específicos.
3.4.1. Ordenación de transacciones
En la interfaz del APM es posible ordenar las transacciones por estas métricas, lo que permite, por ejemplo, identificar las transacciones más lentas o aquellas con mayor tasa de fallos. Esta funcionalidad facilita priorizar esfuerzos de optimización en los puntos con mayor impacto, como se muestra en la Figura 11, donde se destacan las columnas que permiten ordenar por latencia, throughput, tasa de fallos e impacto. Este último se tratará en artículos posteriores.
3.4.2. Comparación temporal
Otra funcionalidad relevante es que mediante las gráficas de estas métricas es posible comparar el rango temporal actual con un periodo anterior (por ejemplo, el mismo día con el anterior o la semana previa). Esta superposición facilita:
- Detectar anomalías o comportamientos atípicos (picos de latencia asociados a caídas de servicios, saturación de BBDD o incidencias puntuales).
- Contrastar versiones tras un despliegue, observando si la nueva versión mejora o degrada latencia y FTR respecto a su línea base.
En la Figura 12 se muestra un ejemplo de esta comparación, donde la línea azul oscuro representa el periodo actual y la línea azul claro el día anterior, permitiendo identificar diferencias significativas en la latencia.
3.5. Muestreo y correlaciones
Las comparativas temporales comentadas en el apartado de métricas permiten detectar anomalías y entender cómo evolucionan los cambios en el tiempo. No obstante, se trata de métricas agregadas. Para profundizar en el análisis resulta conveniente descender al nivel de trazas individuales, observar cómo se distribuye la latencia dentro de cada transacción (ver Figura 13) y detectar patrones que no afloran en la agregación. En este punto entran en juego el muestreo y las correlaciones.
Elastic APM no almacena todas las trazas por razones de volumen y coste. En su lugar, selecciona un porcentaje representativo de transacciones y sus trazas asociadas. Este enfoque permite:
- Navegar por las trazas capturadas (ver Figura 13) y analizar su desglose (cascada de spans), como se aprecia en la Figura 6 y en la Figura 7.
- Filtrar por trazas que fallan o que se sitúan en percentiles altos de latencia (p95/p99), centrando el estudio en los casos más relevantes.
- Identificar correlaciones entre comportamientos (latencia elevada, FTR alto) y distintos metadatos disponibles, como se muestra en la Figura 14.
Estas correlaciones ayudan a identificar patrones que pueden ser indicios de los factores implicados. Ejemplos habituales:
- Latencia elevada asociada a una versión concreta del servicio (por ejemplo, tras un despliegue).
- FTR concentrada en determinados pods o máquinas.
- Problemas que afectan solo a un grupo de usuarios o a una funcionalidad determinada.
Nota metodológica: la correlación no implica causalidad. Las correlaciones constituyen pistas sólidas para formular hipótesis y priorizar el análisis, pero requieren validación posterior en el detalle de transacciones y spans (revisando consultas a BBDD, stacktraces y tiempos de dependencias).
3.6. Gestión de errores
Con el muestreo y las correlaciones es posible identificar patrones relacionados con la latencia y la tasa de fallos. Sin embargo, cuando el objetivo es centrarse únicamente en los errores, la vista adecuada es la pestaña “Errores”.
Esta sección ofrece una visión detallada de los fallos registrados en el servicio. Muestra qué errores se están produciendo y con qué frecuencia, agrupándolos por stacktrace y asignando un identificador de grupo. La interfaz permite filtrar por metadatos. Por ejemplo, es posible seleccionar únicamente los errores del tipo NullPointerException o los asociados a una versión determinada:
error.exception.type : "java.lang.NullPointerException"
service.version : "2-33-20250923"
En la Figura 15 se observa la vista general, que incluye gráficos de ocurrencias y tasa de fallos, junto con la lista de errores agrupados. Al seleccionar un error concreto, se accede a información detallada, como se muestra en la Figura 16: mensaje, stacktrace y contexto adicional. También se muestran las trazas en las que se produjo el fallo, lo que permite analizar el desglose completo y localizar el punto exacto en el que ocurrió.
En esta misma vista es posible comparar la frecuencia actual del error con la de periodos anteriores, lo que ayuda a comprobar si un problema ha aumentado tras un cambio o si una corrección ha reducido su aparición.
3.7. Alertas y reglas
El análisis manual en APM resulta muy útil para detectar problemas en revisiones periódicas o cuando se reporta un problema, ya que permite identificar rápidamente la causa. Sin embargo, APM también incorpora mecanismos que automatizan la detección de inconvenientes y facilitan la prevención: las reglas.
En APM se pueden definir reglas que combinan una condición y una acción. Cuando la condición se cumple, se ejecuta la acción configurada, que normalmente consiste en enviar una notificación (alerta) al canal definido, como correo electrónico o un sistema de mensajería corporativa.
Existen 16 tipos de reglas, pero se abordarán cuatro:
- Tres basadas en umbrales: errores, latencia y FTR.
- Una basada en anomalías, que utiliza Machine Learning para detectar comportamientos inusuales.
3.7.1. Reglas basadas en umbrales
La primera regla que considerar es la de “Error Count”. Su interfaz, visible en la Figura 17, permite configurar parámetros como:
- Environment: entorno al que aplica la regla.
- Is above: umbral numérico que dispara la acción.
- Error grouping key: define si la regla se aplica a todos los errores o a un grupo específico.
- For the last: intervalo temporal sobre el que se evalúa la condición.
A partir de estos parámetros surgen cuestiones que no tienen una única respuesta y dependen del contexto del proyecto:
- ¿Conviene incluir errores de QA, de producción o de ambos?
QA permite anticiparse, pero puede generar falsos positivos por proyectos automatizados. Además, en QA es habitual que se postergue la atención porque no se percibe la misma urgencia que en producción. Si se reciben demasiadas notificaciones, existe el riesgo de ignorarlas. Una opción es activar la regla solo en producción y habilitarla en QA únicamente durante periodos de actualización.
En producción, surge otra cuestión: ¿Cómo actuamos ante la alerta si no es posible corregir el error de inmediato? Entre el cambio y el despliegue pueden pasar varios días, lo que implica recibir notificaciones continuas.
- ¿Qué hacer con errores solucionados?
¿Actualizar la regla para excluirlos o mantenerla activa para detectar recurrencias? Esta decisión está relacionada con la pregunta anterior y depende del nivel de criticidad y del coste de mantenimiento.
- ¿Qué tipo de errores interesa vigilar?
¿Todos los errores o solo los críticos? Si se incluyen todos, ¿aporta valor real? Un volumen elevado puede ocultar errores nuevos y relevantes cuando estos ocurren con poca frecuencia, además de generar un exceso de alertas que puede terminar siendo ignorado.
Cuando se conocen errores concretos, puede ser útil configurar la regla para un groupId específico. Si no se dispone de esa información, siempre es posible filtrar por familias de errores que se sabe que son críticas, utilizando KQL. Por ejemplo, centrarse en NullPointerException permite vigilar un patrón que históricamente causa incidencias graves, sin necesidad de conocer el identificador exacto del error.
- ¿Cuál debe ser el umbral en “Is above”?
Depende del tipo de error y de su impacto. Antes de definirlo, conviene revisar si existen errores que no deberían considerarse como tales (por ejemplo, eventos controlados registrados con log.error que no son bloqueantes). En esos casos, puede ser más efectivo reclasificarlos antes de configurar la regla.
También es importante considerar que un error crítico puede requerir acción inmediata incluso con pocas ocurrencias.
Las reglas de latencia y FTR comparten una interfaz similar a la de errores, por lo que muchos razonamientos anteriores se aplican aquí también. La diferencia es que, además de definir el umbral, se puede indicar:
- Transacciones específicas
- Tipos de transacción a monitorizar.
Esto plantea nuevas preguntas que dependen del contexto:
¿Es preferible una alerta genérica o centrarse en procesos críticos? Dependiendo del caso, puede ser suficiente vigilar operaciones clave que impactan directamente en la experiencia del usuario. Sin embargo, si la versión que se va a desplegar introduce cambios significativos, como una modificación completa de la API REST, la estrategia cambia: en ese escenario, conviene ampliar el alcance y monitorizar todas las transacciones relacionadas con el API, no solo las más críticas.
¿Qué se considera “lento”? No existe un valor universal. Depende del producto y de la experiencia esperada por el usuario. Si el umbral se fija demasiado bajo, se generará un exceso de alertas, especialmente en sistemas con procesos que, por naturaleza, son más costosos. Esto puede provocar saturación de notificaciones y pérdida de efectividad.
¿Qué tasa de error es aceptable? La respuesta también depende del tipo de operación. No es lo mismo un fallo en una operación crítica que en una funcionalidad secundaria. En algunos casos, incluso un pequeño porcentaje puede ser inaceptable, mientras que en otros se tolera cierta variabilidad.
3.7.2. Reglas de anomalías
La APM Anomaly Rule permite detectar comportamientos anómalos sin depender de umbrales fijos. Estas anomalías se identifican mediante jobs que analizan las métricas agregadas recogidas por APM (latencia, throughput, FTR) aplicando técnicas de Machine Learning.
El sistema asigna a cada anomalía un nivel de severidad (0 a 100), calculado en función de varios factores:
- Histórico de valores. Cuanto más inusual sea el comportamiento respecto a datos anteriores, mayor será la severidad.
- Duración y tamaño de la anomalía. Anomalías pequeñas suelen deberse a datos atípicos, mientras que anomalías prolongadas son más relevantes y requieren atención.
- Relación con otras anomalías. Si aparece una anomalía con severidad muy alta, las demás reducen su puntuación para priorizar la más crítica.
Este modelo implica que la severidad es dinámica: si una anomalía grave no se atiende, su puntuación puede disminuir con el tiempo al aparecer otras más urgentes. El objetivo es priorizar y evitar que todas las alertas tengan la misma importancia.
En la interfaz (ver Figura 18), las anomalías detectadas se presentan con información como:
- Fecha y hora.
- Severidad asignada.
- Métrica afectada.
- Servicio y transacción implicados.
Es importante destacar que los jobs necesitan un periodo de aprendizaje suficiente para generar resultados fiables. Cuanto mayor sea el histórico, más precisas serán las detecciones.
4. Buenas prácticas
El valor de APM no está únicamente en detectar errores, sino en anticiparse a ellos y garantizar que los cambios no introducen degradaciones. Para ello, se recomienda aplicar las siguientes buenas prácticas:
Revisar entornos QA/Pre:
- Antes de generar una versión para producción, asegurando estabilidad.
- Al final de cada sprint, para validar nuevas funcionalidades.
Comprobar métricas antes y después de un despliegue en Producción:
- Latencia (p95/p99).
- Throughput (carga procesada).
- Failed Transaction Rate
Analizar errores con criterio:
- Cuestionar si un error lo es realmente o si debiera reclasificarse para reducir ruido.
- Verificar si un error se ha corregido comparando periodos antes y después del cambio.
Estas prácticas permiten validar la estabilidad de cada release y reducir el riesgo de incidencias en entornos críticos.
5. Conclusiones
APM nos da visibilidad de extremo a extremo mediante agentes que envían datos a Elastic/Kibana, permitiendo interpretar environments, transacciones, spans, trazas y metadatos para entender el comportamiento real de los servicios. Las métricas de latencia, throughput y tasa de transacciones fallidas (FTR), junto con comparaciones temporales, gestión de errores por stacktrace y reglas (umbrales y anomalías) convierten los síntomas en diagnósticos accionables.
Para maximizar el valor, conviene usar estas métricas como criterios operativos, ajustar el muestreo para analizar trazas representativas, definir etiquetas con criterio (evitando valores únicos que añadan ruido) y automatizar verificaciones pre y post despliegue para detectar empeoramientos cuanto antes.