Monitoreo de infraestructura vs. monitoreo de rendimiento de aplicaciones (APM) — ¿cuál es la diferencia real en lo que cada uno te dice?
Uno te dice si la máquina está sana, el otro si la petición está sana — confundirlos es un error clásico durante un incidente.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
Monitoreo de infraestructura vs. monitoreo de rendimiento de aplicaciones (APM) — ¿cuál es la diferencia real en lo que cada uno te dice?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#Dos preguntas que suenan parecidas pero no lo son
"¿La máquina está sana?" y "¿la petición está sana?" son preguntas distintas, respondidas por herramientas distintas, y confundirlas es un error común de nivel junior que suele aparecer en la respuesta a incidentes. El monitoreo de infraestructura responde la primera. El monitoreo de rendimiento de aplicaciones (APM) responde la segunda.
El monitoreo de infraestructura vigila los recursos sobre los que corre tu aplicación: uso de CPU, uso de memoria, I/O de disco, espacio en disco, throughput de red, y si un host o contenedor siquiera es alcanzable. Se recolecta mediante agentes como el node_exporter de Prometheus, el agente de infraestructura de Datadog, o herramientas nativas de la nube como las métricas de EC2 en AWS CloudWatch. No sabe nada de tu código — no tiene concepto de "endpoint", "consulta a la base de datos" o "petición de usuario". Solo conoce la máquina (o el pod, o el nodo) donde el código resulta estar corriendo.
APM vigila lo que ocurre dentro de una petición mientras fluye por tu código: qué endpoint se invocó, cuánto tardó, si falló, qué llamadas downstream hizo (consulta a base de datos, búsqueda en caché, otro servicio) y cuánto de la latencia total consumió cada una de esas llamadas. Herramientas como Datadog APM, New Relic, Elastic APM o una configuración de trazado basada en OpenTelemetry instrumentan tu código de aplicación (a menudo mediante librerías de auto-instrumentación) para capturar esto.
#Una analogía que fija la distinción
#Comparación lado a lado
| Monitoreo de infraestructura | APM | |
|---|---|---|
| Unidad de observación | Host, VM, contenedor, nodo, clúster | Transacción / petición individual |
| Métricas típicas | % de CPU, memoria, I/O de disco, throughput de red, uptime | Latencia de petición (p50/p95/p99), tasa de errores, throughput por endpoint |
| Responde | "¿Un recurso está cerca de agotarse?" | "¿Qué ruta de código está lenta o fallando, y por qué?" |
| Granularidad | Gruesa — por máquina o contenedor | Fina — por endpoint, por función, por consulta a base de datos |
| Herramientas de ejemplo | Prometheus + node_exporter, CloudWatch, Datadog Infrastructure | Datadog APM, New Relic, Elastic APM, Jaeger/Tempo (vía OpenTelemetry) |
| Alerta típica | "Uso de disco del nodo superior al 90%" | "Latencia p99 en /checkout superó los 2s" |
#Dónde se solapan y por qué necesitas ambos
Los dos son complementarios, no competidores. Imagina que se dispara una alerta: la CPU de un nodo acaba de subir a 95%. El monitoreo de infraestructura te dice que ocurrió y dónde (qué nodo, qué pod). No puede decirte por qué. APM es lo que te muestra que un único endpoint empezó a hacer una serialización JSON costosa e innecesaria en cada petición después de un despliegue reciente, y que ese endpoint por sí solo es responsable del pico de CPU — el flame graph de la traza hace visible el span costoso al instante, span por span.
También ocurre lo inverso: APM puede mostrar que una consulta específica a la base de datos se vuelve más lenta durante la última hora sin ningún cambio de código, y el monitoreo de infraestructura en el host de la base de datos es lo que confirma que la saturación de I/O de disco es la causa raíz real, no la lógica de la aplicación.
Una configuración de guardia (on-call) madura trata esto como lentes distintos sobre el mismo incidente, no como alternativas: monitoreo de infraestructura para "qué recurso está bajo presión", APM para "qué ruta de código lo está causando", y los logs (un tercer pilar, cubierto en otra lección de este módulo) para "qué ocurrió exactamente, en las propias palabras de la aplicación, en el momento en que algo salió mal".
🧠 Check your understanding
0/2 · 0/2 answered1. Un dashboard muestra que la latencia p99 de un servicio se dispara específicamente en el endpoint /search, mientras otros endpoints en el mismo host no se ven afectados. ¿Qué herramienta es la más adecuada para explicar *por qué* este endpoint en particular está lento?
2. ¿Qué afirmación describe mejor la relación entre el monitoreo de infraestructura y APM?