Lección 2 de 210 min
APM y monitorización comercial: Dynatrace
Seguir cada petición de punta a punta, monitorizar usuarios reales y el estándar OpenTelemetry.
Con Prometheus y Grafana montas tu propia observabilidad pieza a pieza: tú decides qué medir, instrumentas el código y diseñas los paneles. Es potente, pero lleva tiempo. Las herramientas comerciales de APM prometen lo contrario: instalas un agente y, en minutos, ves cada servicio, cada petición y cada consulta lenta sin tocar una línea.
En esta lección verás qué es el APM y cómo lo resuelve Dynatrace, una plataforma muy extendida en grandes empresas; cómo se mide la experiencia de los usuarios reales frente a la de usuarios simulados, y por qué OpenTelemetry se ha convertido en el estándar que conecta todas estas herramientas.
APM y Dynatrace
Dynatrace es una plataforma comercial de observabilidad que se usa sobre todo como servicio en la nube. Sus piezas clave son un agente que instrumenta por su cuenta, trazas de cada petición, un mapa de dependencias que se dibuja solo y un motor de IA que lo cruza todo.
APM (Application Performance Monitoring)
Monitorizar el rendimiento desde dentro de la aplicación, petición a petición.
- Ejemplos:
- Dynatrace, Datadog, New Relic
La monitorización de infraestructura te dice que un servidor está al 90 % de CPU. El APM (monitorización del rendimiento de aplicaciones) mira desde dentro del código: cuánto tarda cada endpoint, qué porcentaje falla, qué consultas SQL y llamadas a otros servicios hace cada petición y en qué línea saltó una excepción.
Para conseguirlo, un agente se engancha al proceso de tu aplicación (la máquina virtual de Java, el runtime de Node.js o de .NET) e instrumenta automáticamente los frameworks y librerías conocidos. Los datos van a una plataforma que los guarda y los relaciona. Además de Dynatrace, en este mercado están Datadog, New Relic o Elastic, entre otros.
Úsalo cuando
Cuando necesitas ver el rendimiento de muchas aplicaciones con poco esfuerzo, o cuando el equipo de operaciones tiene que diagnosticar código que no ha escrito.
Ten en cuenta
Un agente añade algo de sobrecarga al proceso, y las plataformas comerciales suelen cobrar según el volumen de datos o el número de máquinas, así que el coste crece con el sistema. Revisa también qué captura: parámetros de consultas o cabeceras pueden contener datos personales.
Servicio: pedidos-api (Node.js) últimos 30 min
Peticiones 1.240 /min
Tiempo medio 85 ms p95 410 ms
Fallos 0,8 %
Endpoints más lentos
POST /pedidos p95 1,9 s ← llama a inventario
GET /pedidos/:id p95 120 ms
Excepción más frecuente
TimeoutError: inventario no respondió en 1500 ms
at reservarStock (src/stock.js:42)OneAgent: instrumentación automática
Un único agente por máquina que detecta e instrumenta solo los procesos que encuentra.
- Instalación:
- Una por host
En Dynatrace no instalas un agente por lenguaje: instalas OneAgent una vez en cada host (o lo despliega un operador en Kubernetes) y él descubre los procesos que corren en la máquina, ya sean Java, .NET, Node.js, PHP, Go, servidores web o bases de datos. Inyecta la instrumentación en ellos al arrancar, sin cambios en el código.
Además de las trazas de cada petición, recoge métricas del host y de los procesos, logs y, en las aplicaciones web, puede inyectar automáticamente en las páginas que sirves el JavaScript que mide a los usuarios reales. Por eso una instalación nueva muestra datos útiles en minutos.
Úsalo cuando
Cuando tienes muchos servicios en lenguajes distintos y quieres visibilidad completa sin pedir a cada equipo que instrumente su código.
Ten en cuenta
Para instrumentar un proceso que ya estaba en marcha normalmente hay que reiniciarlo. Y la instrumentación automática no conoce tu negocio: si quieres el importe de cada pedido o el tipo de cliente, tendrás que añadir atributos tú, por ejemplo con OpenTelemetry.
import express from "express";
import { pool } from "./db.js";
const app = express();
app.get("/pedidos/:id", async (req, res) => {
const { rows } = await pool.query("SELECT * FROM pedidos WHERE id = $1", [req.params.id]);
const stock = await fetch(`http://inventario/stock/${req.params.id}`);
res.json({ pedido: rows[0], stock: await stock.json() });
});
app.listen(3000);
// Con OneAgent en la máquina, esta ruta aparece como parte de un servicio,
// con sus tiempos, la consulta SQL y la llamada a inventario.Trazas distribuidas (PurePath)
Cada petición seguida de punta a punta, del navegador a la base de datos.
Dynatrace llama PurePath a sus trazas distribuidas. Como OneAgent está en todos los procesos, puede seguir una petición desde el clic del usuario en el navegador, a través de cada servicio, hasta la consulta SQL final, y mostrarla como una cascada de pasos con su duración.
Sobre esas trazas calcula los tiempos de respuesta y los fallos de cada servicio y endpoint, y te deja analizar dónde se concentra el tiempo o qué cambió tras un despliegue. Es la misma idea de traza y span que viste en la lección anterior, pero capturada de forma automática.
Úsalo cuando
Para encontrar el cuello de botella de una petición lenta concreta, o qué servicio de la cadena provoca los errores.
Ten en cuenta
La traza solo es completa si cubre todos los saltos: un servicio sin agente o un sistema de terceros aparece como una caja negra al final de la cadena. Y con mucho tráfico la plataforma tampoco conserva cada detalle: aplica algún tipo de muestreo.
GET /pedidos/42 pedidos-api 812 ms
├─ middleware de autenticación pedidos-api 4 ms
├─ SELECT * FROM pedidos … postgresql 12 ms
├─ GET http://inventario/stock/42 inventario-api 760 ms ← aquí
│ └─ SELECT stock FROM almacen … postgresql 748 ms
│ (falta un índice: lee la tabla entera)
└─ serializar respuesta pedidos-api 3 msDavis: el motor de IA de Dynatrace
Detecta anomalías y, apoyándose en el mapa de dependencias, propone la causa raíz.
Davis es el motor de inteligencia artificial de Dynatrace. Aprende el comportamiento normal de cada servicio (su línea base de tiempos y errores según la hora y el día) y detecta cuándo algo se sale de lo habitual sin que tengas que fijar umbrales a mano.
Su punto fuerte es el análisis de causa raíz: cuando la base de datos se ralentiza y diez servicios empiezan a fallar, no te manda diez alertas, sino un único problema que agrupa todos los eventos y señala el origen probable. Para distinguir la causa de los síntomas recorre las dependencias reales que describe Smartscape, en lugar de buscar solo coincidencias en el tiempo.
Úsalo cuando
En sistemas grandes, donde una sola avería desata una avalancha de alertas y la persona de guardia pierde tiempo buscando el origen.
Ten en cuenta
La causa que propone es una hipótesis muy bien informada, no una verdad absoluta: compruébala en las trazas y los logs. Y solo ve lo que está monitorizado; si el origen está en un sistema sin agente, señalará el último punto que sí ve.
Problema · Tasa de fallos elevada en checkout
Impacto 1.240 usuarios reales, 3 aplicaciones, 9 servicios
Causa raíz inventario-api: tiempo de respuesta 12 veces mayor
tras el despliegue de la versión 2.3.1
Eventos 37, agrupados en este problema
Estado abierto desde hace 14 minSmartscape: el mapa de dependencias
La topología de todo el entorno, descubierta y actualizada sola en tiempo real.
Smartscape es el mapa que Dynatrace construye con lo que observa OneAgent: qué aplicaciones web hay, a qué servicios llama cada una, en qué procesos corren esos servicios, en qué hosts y en qué centro de datos o nube. Descubre solas tanto las relaciones verticales (este servicio corre en este proceso, en este host) como las horizontales (este servicio llama a aquel).
Sirve para entender un sistema que nadie tiene completo en la cabeza, y es la base sobre la que razona Davis: si un host se queda sin memoria, Smartscape sabe qué procesos, servicios y usuarios dependen de él.
Úsalo cuando
Para responder «¿quién depende de esto?» antes de migrar una base de datos o apagar un servidor, o para descubrir dependencias que nadie había documentado.
Ten en cuenta
Solo muestra lo que ve: las llamadas a sistemas sin instrumentar aparecen como servicios externos o no aparecen. No sustituye a la documentación de arquitectura, pero sí la contrasta con la realidad.
Aplicación tienda.ejemplo.com
↓ llama a
Servicios checkout-api → pagos-api → pasarela externa
↘ inventario-api → postgresql
↓ corren en
Procesos node (checkout-api), java (pagos-api)
↓ corren en
Hosts web-07, web-08
↓ están en
Nube región eu-westAgente propietario y estándar abierto no son rivales
OneAgent te da visibilidad inmediata, con los datos en el formato de Dynatrace. OpenTelemetry, al final de esta lección, te da independencia del proveedor. Dynatrace acepta ambos y muchos equipos los combinan: el agente para lo automático y OpenTelemetry para los datos de negocio.
Usuarios reales y usuarios simulados
El APM mide el servidor, pero el usuario percibe también la red, su dispositivo y el JavaScript que corre en su navegador. Hay dos formas complementarias de medir ese lado: observar a los usuarios reales o simular uno.
RUM (Real User Monitoring)
Mide la experiencia de cada visitante real, desde su propio navegador o app.
- Datos de:
- Usuarios reales
Un pequeño script en la página (o un SDK en la app móvil) mide lo que vive cada usuario real: cuánto tardó en cargar la página, qué acciones hizo, qué errores de JavaScript saltaron, con qué navegador, dispositivo y país. Incluye las Core Web Vitals de Google: LCP (cuánto tarda en verse el contenido principal), INP (cuánto tarda la página en responder a una interacción) y CLS (cuánto se mueve el diseño mientras carga).
Como cada sesión puede enlazarse con su traza en el servidor, pasas de «los usuarios con móvil y conexión lenta tardan 6 segundos en pagar» a la consulta exacta que lo provoca. Dynatrace inyecta el script de forma automática con OneAgent, pero también puedes medir las Web Vitals por tu cuenta, como en el ejemplo.
Úsalo cuando
Para saber cómo vive tu web la gente de verdad, con sus redes lentas y sus móviles antiguos, y para priorizar arreglos según a cuántos usuarios afectan.
Ten en cuenta
Solo hay datos si hay visitas: de madrugada, o en una página nueva que nadie ha abierto todavía, no detecta nada. Y recoge datos de personas: infórmalo en tu política de privacidad y, según la normativa que te aplique, pide consentimiento.
import { onCLS, onINP, onLCP } from "web-vitals";
function enviar(metrica) {
// sendBeacon envía los datos aunque el usuario cierre la pestaña
navigator.sendBeacon("/rum", JSON.stringify({
nombre: metrica.name, // "LCP", "INP" o "CLS"
valor: metrica.value,
pagina: location.pathname,
}));
}
onLCP(enviar);
onINP(enviar);
onCLS(enviar);Monitorización sintética
Robots que repiten un recorrido cada pocos minutos desde distintos lugares.
- Datos de:
- Scripts programados
Un monitor sintético es un script que simula a un usuario: abre la web, inicia sesión, añade un producto al carrito y llega al pago. La plataforma lo ejecuta a intervalos fijos (cada 5 o 15 minutos, por ejemplo) desde varias ubicaciones del mundo y avisa si falla o tarda más de la cuenta. Los más sencillos solo comprueban que una URL o una API responde.
Como las condiciones son siempre las mismas (mismo navegador, misma red, mismo recorrido), los resultados se comparan bien entre sí. Es ideal para detectar que el último despliegue ha hecho más lenta una página, o que el login está caído aunque sea de madrugada y no haya nadie conectado.
Úsalo cuando
Para vigilar las 24 horas los recorridos críticos (login, pago), comprobar la disponibilidad desde otras regiones y vigilar APIs de terceros de las que dependes.
Ten en cuenta
Mide un recorrido ideal, no la variedad real de dispositivos y redes. Y cuidado con los efectos secundarios: un monitor que compra cada cinco minutos debe usar una cuenta de prueba y un pago simulado.
import { test, expect } from "@playwright/test";
test("un cliente puede llegar al carrito", async ({ page }) => {
await page.goto("https://tienda.ejemplo.com");
await page.getByRole("link", { name: "Ofertas" }).click();
await page.getByRole("button", { name: "Añadir al carrito" }).first().click();
await page.getByRole("link", { name: "Carrito" }).click();
await expect(page.getByRole("heading", { name: "Tu carrito" })).toBeVisible();
});OpenTelemetry: el estándar abierto
Durante años cada proveedor de APM tuvo su propio agente y su propio formato, así que cambiar de herramienta suponía volver a instrumentarlo todo. OpenTelemetry nació para acabar con eso.
OpenTelemetry
Un estándar abierto y neutral para generar y enviar trazas, métricas y logs.
- Fundación:
- CNCF
- Protocolo:
- OTLP
- Desde:
- 2019
OpenTelemetry (OTel) es un proyecto de la CNCF, la fundación que acoge Kubernetes y Prometheus, nacido en 2019 de la unión de OpenTracing y OpenCensus. Define una API y unos SDKs para casi todos los lenguajes, un protocolo de envío llamado OTLP y unas convenciones semánticas que fijan cómo se llaman los atributos (service.name, http.request.method…) para que todas las herramientas los entiendan igual.
Instrumentas una vez y envías los datos a cualquier backend compatible: Dynatrace, Grafana (con Tempo, Loki y Mimir), Datadog, New Relic, Jaeger… Muchos lenguajes tienen además instrumentación automática para frameworks y librerías populares, y la API te deja añadir tus propios spans y atributos de negocio.
Úsalo cuando
En proyectos nuevos, cuando no quieres atarte a un proveedor o cuando necesitas añadir datos de negocio a las trazas.
Ten en cuenta
OpenTelemetry no guarda ni muestra nada: necesitas un backend. Y no todas sus piezas avanzan al mismo ritmo; revisa en la documentación el estado (estable o en desarrollo) de cada señal en tu lenguaje.
import { trace, SpanStatusCode } from "@opentelemetry/api";
const tracer = trace.getTracer("tienda");
export async function cobrar(pedido) {
return tracer.startActiveSpan("cobrar-pedido", async (span) => {
span.setAttribute("pedido.importe", pedido.total);
try {
return await pasarela.cobrar(pedido);
} catch (error) {
span.recordException(error);
span.setStatus({ code: SpanStatusCode.ERROR });
throw error;
} finally {
span.end();
}
});
}OpenTelemetry Collector
Un intermediario que recibe la telemetría, la procesa y la reparte a sus destinos.
- Puertos OTLP:
- 4317 (gRPC), 4318 (HTTP)
El Collector es un servicio que se coloca entre tus aplicaciones y los backends. Se configura como una tubería: receivers que reciben datos (OTLP, Prometheus, Jaeger…), processors que los transforman (agrupar en lotes, añadir etiquetas, borrar datos sensibles, muestrear) y exporters que los envían a su destino.
Así tus aplicaciones solo saben enviar OTLP a un sitio cercano, y cambiar o añadir un backend es un cambio de configuración, no de código. Tanto Dynatrace como Grafana aceptan OTLP directamente y ofrecen su propia distribución del Collector; la de Grafana se llama Alloy.
Úsalo cuando
En cuanto tengas varios servicios: centraliza la configuración, protege los tokens del backend y te deja enviar los mismos datos a dos herramientas durante una migración.
Ten en cuenta
Es una pieza más que operar y vigilar: si se cae o se satura, pierdes telemetría. Dale recursos suficientes y, en producción, despliégalo con más de una réplica.
receivers:
otlp:
protocols:
grpc: # puerto 4317
http: # puerto 4318
processors:
batch:
exporters:
otlphttp/dynatrace:
endpoint: https://TU-ENTORNO.live.dynatrace.com/api/v2/otlp
headers:
Authorization: "Api-Token ${env:DT_API_TOKEN}"
otlp/tempo:
endpoint: tempo:4317
tls: { insecure: true } # red interna, sin TLS
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/dynatrace, otlp/tempo]Pruébalo
En una app de Node.js puedes probar la instrumentación automática sin tocar el código: instala @opentelemetry/api y @opentelemetry/auto-instrumentations-node, y arranca con node --require @opentelemetry/auto-instrumentations-node/register app.js. Con las variables OTEL_SERVICE_NAME y OTEL_EXPORTER_OTLP_ENDPOINT le dices cómo se llama el servicio y a qué Collector enviar los datos.
Interactivo
APM, RUM y monitorización sintética
Activa o desactiva opciones para compararlas cara a cara.
| Característica | APM | RUM | Sintética |
|---|---|---|---|
| Qué mide | Servicios, endpoints, consultas y excepciones | La experiencia de cada visitante real | Un recorrido guionizado y repetido |
| De dónde salen los datos | Un agente o SDK en tus procesos | Un script en el navegador o un SDK en la app | Robots programados en varias ubicaciones |
| ¿Funciona sin tráfico? | No: necesita peticiones | No: necesita visitas | Sí: se ejecuta siempre |
| Pregunta que responde | ¿Qué parte del backend falla o va lenta? | ¿Cómo lo están viviendo mis usuarios? | ¿Funciona el recorrido crítico ahora mismo? |
| Punto débil | No ve la red ni el navegador del usuario | Sin visitas no hay datos | No refleja la variedad real de usuarios |
Ponlo en práctica
Saber qué es cada cosa es la mitad del trabajo. La otra mitad es reconocer cuándo usarla.
Interactivo
¿Qué usarías?
Lee cada situación y elige la opción que mejor la resuelve. Fallar aquí no cuenta: es para practicar.
Tu tienda apenas tiene visitas de madrugada, pero quieres enterarte antes de que abran las oficinas si el login o el pago se han roto durante la noche.
Para recordar
- El APM mide el rendimiento desde dentro de la aplicación: endpoints, consultas, llamadas entre servicios y excepciones.
- Dynatrace combina OneAgent (instrumentación automática), las trazas PurePath, el mapa Smartscape y el motor Davis, que agrupa los síntomas en un problema con su causa probable.
- RUM y monitorización sintética se complementan: usuarios reales con toda su variedad frente a robots constantes que vigilan aunque no haya tráfico.
- OpenTelemetry es el estándar neutral para instrumentar una vez y enviar a cualquier backend; el Collector recibe, procesa y reparte la telemetría.
Comprueba lo aprendido
Cuestionario
Responde las 5 preguntas para completar la lección.
1.¿Cuál es la diferencia principal entre RUM y monitorización sintética?
2.¿Qué distingue a OneAgent de instrumentar a mano?
3.¿Por qué Davis puede señalar una causa raíz en lugar de mandar una alerta por cada síntoma?
4.¿Qué afirmación sobre OpenTelemetry es correcta?
5.Tus 20 servicios envían trazas por OTLP a un Collector y quieres añadir un segundo backend. ¿Qué tienes que cambiar?