Cómo elegir una plataforma APM sin atarte a un proveedor

Elegir una plataforma APM suele ser una decisión de varios años. Una vez desplegados los agentes, construidos los paneles, definidas las alertas y entrenados los equipos, cambiar de herramienta es costoso. Por eso la evaluación merece más rigor que una demo bien preparada y una comparación de funcionalidades en una hoja de cálculo.

Este artículo propone criterios neutrales para evaluar cualquier plataforma, sea Dynatrace, Datadog u otra, y una estrategia para que la decisión de hoy no limite las opciones de mañana. No hay una plataforma correcta en abstracto: hay una plataforma adecuada para tu stack, tu modelo operativo y tus obligaciones regulatorias.

Empieza por las preguntas, no por la demo

Las demos muestran lo mejor de cada producto con datos preparados. Antes de verlas, conviene escribir qué necesita resolver tu organización. Recomendamos partir de tres insumos:

• El inventario del stack: lenguajes y entornos de ejecución, bases de datos, middleware, mensajería, nubes, contenedores, mainframe o sistemas heredados si los hay, y aplicaciones de terceros que no puedes modificar.
• Los incidentes recientes: qué tipos de incidentes tardaron más en diagnosticarse y qué información faltó. Esa lista es el mejor guion para una prueba de concepto.
• Las restricciones: requisitos regulatorios sobre datos, políticas de seguridad, presupuesto, capacidades del equipo y herramientas con las que debe integrarse.

Con esos insumos, la evaluación deja de ser "qué tiene cada herramienta" y pasa a ser "cuál resuelve mejor nuestros problemas con nuestras restricciones".

Seis criterios para una evaluación neutral

1. Cobertura del stack

Verifica, tecnología por tecnología, qué se instrumenta de forma automática, qué requiere configuración y qué no está soportado. Presta atención a los extremos: sistemas heredados, aplicaciones empaquetadas, componentes de red y servicios gestionados de la nube. Una plataforma muy completa para microservicios puede quedarse corta en el núcleo transaccional que más importa.

2. Soporte de OpenTelemetry

Dynatrace y Datadog, como otras plataformas comerciales, aceptan hoy datos de OpenTelemetry. La pregunta útil no es si lo soportan, sino cómo: si reciben las tres señales (trazas, métricas y logs) por OTLP, si los datos de OpenTelemetry tienen el mismo tratamiento que los de su agente propio en análisis, paneles y alertas, y si respetan las convenciones semánticas sin traducciones que pierdan información.

3. Modelo de datos, retención y costo

Los modelos de licenciamiento varían: por host o unidad de cómputo, por volumen ingerido, por volumen retenido o consultado, por usuario, o combinaciones de estos. Sin entrar en precios, que cambian y dependen de cada negociación, lo importante es entender qué variable de tu operación hace crecer la factura. Pide un cálculo con tu volumen real de logs, trazas y métricas personalizadas, y proyéctalo con el crecimiento esperado. Revisa también la retención por señal y el costo de conservar datos más tiempo por exigencias de auditoría.

4. Análisis de causa raíz

Todas las plataformas prometen análisis de causa raíz asistido. Evalúalo con tus incidentes, no con los de la demo. Pregunta cómo correlaciona eventos, cómo usa la topología, cómo explica sus conclusiones y qué hace cuando la causa está en un componente que no monitorea. Un diagnóstico automático que no puedes verificar no reduce el tiempo de resolución; lo traslada.

5. Control de acceso y residencia de datos

En banca, seguros y salud, este criterio suele ser eliminatorio. Revisa la granularidad del control de acceso (por equipo, aplicación o tipo de dato), la integración con tu proveedor de identidad, el enmascaramiento de datos sensibles antes de almacenarlos, la auditoría de accesos y las regiones donde se alojan los datos. Ambos proveedores mencionados ofrecen su servicio SaaS en varias regiones; confirma en la documentación vigente cuáles están disponibles y qué opciones de despliegue existen para tu caso. Contrasta todo con la normativa de tercerización y nube aplicable en cada país donde operas, junto con tus áreas de Cumplimiento y Riesgo.

6. Integración con ITSM y automatización

Una alerta que no se convierte en un incidente bien categorizado, asignado y con contexto genera trabajo manual. Evalúa la integración bidireccional con tu herramienta ITSM (por ejemplo, ServiceNow), la deduplicación de alertas, la posibilidad de disparar automatizaciones de remediación y la exposición de APIs para que tus propios flujos consuman los datos.

Tabla de evaluación

La tabla sirve como base para una matriz de evaluación. Recomendamos asignar un peso a cada criterio según tus prioridades antes de ver las demos, para que el resultado no dependa de la última presentación.

Criterio	Qué preguntar	Señal de alerta
Cobertura del stack	¿Qué tecnologías de nuestro inventario se instrumentan sin cambios de código?	Respuestas genéricas sin matriz de compatibilidad por versión
OpenTelemetry	¿Se ingieren trazas, métricas y logs por OTLP con el mismo nivel de análisis que el agente propio?	Funciones clave disponibles solo con el agente propietario
Costo y retención	¿Qué variable hace crecer la factura y cuánto costaría con nuestro volumen real?	Imposibilidad de estimar el costo antes de ingerir datos
Causa raíz	¿Cómo explica sus conclusiones y cómo se comporta con nuestros incidentes pasados?	Conclusiones sin evidencia trazable
Acceso y residencia	¿Dónde se alojan los datos, quién accede y cómo se enmascaran los datos sensibles?	Región o enmascaramiento no configurables
ITSM y automatización	¿La integración es bidireccional y conserva el contexto del problema?	Integración solo por correo o webhook sin estado
Salida	¿Cómo exportamos datos, paneles y configuración si cambiamos de plataforma?	Sin exportación documentada ni formatos abiertos

OpenTelemetry como seguro contra el lock-in

La forma más efectiva de no quedar atado a un proveedor es separar la instrumentación del análisis. Si tu código se instrumenta con la API de OpenTelemetry y la telemetría pasa por un OpenTelemetry Collector antes de llegar a la plataforma, cambiar de destino es, en buena medida, un cambio de configuración del Collector, no un proyecto de reinstrumentación.

El Collector aporta además control propio sobre los datos: puedes filtrar, enmascarar atributos sensibles, muestrear y enviar la misma telemetría a dos destinos en paralelo durante una migración o una prueba de concepto.

Conviene ser realista sobre lo que OpenTelemetry no resuelve. Seguirán atados a la plataforma los paneles, las definiciones de alertas, las consultas escritas en su lenguaje propio (por ejemplo, DQL en Dynatrace) y las funcionalidades exclusivas de cada agente. Para reducir ese costo de salida:

• Versiona como código los paneles y alertas, cuando la plataforma lo permita.
• Mantén un catálogo propio de SLO, indicadores y umbrales, independiente de la herramienta.
• Usa atributos y nombres según las convenciones semánticas de OpenTelemetry, no los de una plataforma concreta.
• Documenta qué funcionalidades exclusivas usas y por qué, para saber qué perderías al cambiar.

En sectores regulados, esta estrategia también responde a una exigencia creciente: la capacidad de salir de un proveedor crítico de forma ordenada. En la Unión Europea, el Reglamento DORA (Reglamento (UE) 2022/2554) exige a las entidades financieras gestionar el riesgo de proveedores de TIC, incluidas estrategias de salida. Aunque operes fuera de Europa, el principio es buena práctica.

Cómo correr una prueba de concepto útil

Una prueba de concepto bien diseñada reemplaza opiniones por evidencia. Recomendamos estos pasos:

1. Define el alcance: dos o tres aplicaciones representativas, incluida al menos una con tecnología heredada o de terceros.
2. Instrumenta con OpenTelemetry donde sea posible: envía los mismos datos a todas las plataformas evaluadas mediante un Collector, para comparar análisis con datos idénticos.
3. Reproduce incidentes reales: usa los incidentes recientes del inventario inicial y mide cuánto tarda cada plataforma en llevar al equipo a la causa.
4. Prueba los criterios eliminatorios: control de acceso, enmascaramiento, región de datos e integración con ITSM, con tus áreas de Seguridad y Cumplimiento presentes.
5. Mide el costo con tu volumen: registra el volumen real ingerido durante la prueba y pide la proyección anual.
6. Puntúa con la matriz ponderada: aplica los pesos definidos antes de empezar y documenta la decisión.

Recuerda el límite de cualquier plataforma: hará observable tu infraestructura, pero la causa raíz de los incidentes de negocio depende también de que tu software esté escrito para ser observable. La mejor elección de herramienta rinde poco si la aplicación no emite contexto de negocio.