Llevas meses leyendo notebooks, ejemplos de DQL y tutoriales de Grail. Llegas a un entorno Managed —un ayuntamiento, un banco, un hospital, cualquier organización con la obligación de tener los datos en sus propios centros— y nada de eso existe. No hay botón de Notebooks. No hay barra de DQL. El menú lateral se parece al Dynatrace de hace cinco años. Durante un rato piensas que es un problema de permisos, o que tu versión está desactualizada. No lo es: simplemente Grail no está ahí, y según la propia hoja de ruta de Dynatrace, no va a estarlo.
Es una sorpresa habitual entre quienes migran de un proyecto a otro. Se acostumbran a resolver el día a día con DQL —explorar logs, construir un dashboard rápido, cruzar trazas y eventos en una sola consulta— y reservan la API REST para lo verdaderamente puntual: ese informe mensual de resumen ejecutivo que no merece la pena automatizar como query. Al llegar a Managed, esa relación se invierte por completo: la API REST deja de ser el recurso ocasional y se convierte en la única vía de acceso a los datos, para todo.
Por qué Grail no es «una función pendiente de llegar»
La ausencia de Grail en Managed no es una cuestión de calendario, es de arquitectura. Grail es un data lakehouse de procesamiento masivamente paralelo (MPP), diseñado para escalar a miles de nodos en infraestructura cloud. Los clústeres Managed, en cambio, suelen moverse en rangos de 3, 12 o como mucho 30 nodos, porque están pensados para desplegarse en centros de datos físicos con recursos finitos y controlados por el propio cliente.
Esa diferencia de escala no es un detalle menor: es justo lo que hace viable a Grail. Su capacidad de servir cualquier consulta sobre cualquier dato sin reindexar ni rehidratar depende de un volumen de cómputo distribuido que no tiene sentido —ni es físicamente práctico— replicar en un clúster on-premises de unas pocas decenas de nodos.
Dynatrace lo ha confirmado de forma explícita en su comunidad oficial: el soporte de Grail no figura en el roadmap de Dynatrace Managed, porque Grail se diseñó específicamente para SaaS y para procesamiento masivamente paralelo. Managed sigue siendo, eso sí, una opción de primer nivel para organizaciones con requisitos obligatorios de despliegue on-premises —pero sin Grail, hoy y, según todo lo que sabemos, también mañana.
El mapa real: API v1, API v2 y Grail no son intercambiables
Antes de decidir qué usar conviene desmontar una idea extendida: que «v2 ha sustituido a v1» y que «Grail ha sustituido a la API REST». Ninguna de las dos cosas es cierta sin matices.
v1 y v2 conviven, recurso por recurso. La documentación oficial de la Environment API v2 lo dice sin rodeos: los recursos ahí presentes generalmente sustituyen a los de v1, la migración está en curso, y si echas en falta algo, la recomendación es seguir usando v1. Es decir, v2 no es un reemplazo completo, sino un proceso incremental con piezas concretas:
- Events API v1 → v2 (deprecada desde la versión 1.243)
- Problems API v1 → v2 (deprecada desde la versión 1.243)
- Tokens API v1 → Access tokens API
- Timeseries API v1 → Metrics API v2 (fin de vida anunciado para finales de 2025; a fecha de hoy la documentación oficial sigue listándola como deprecada sin confirmar su retirada efectiva, así que conviene comprobar el estado en tu propia instancia antes de asumir que ya no funciona)
- Log Monitoring API v1 → Logs on Grail API (si hay Grail) o Log Classic API (si no la hay)
Otras configuraciones —credenciales de Kubernetes, contexto de seguridad de management zones— se han movido directamente al framework Settings 2.0, fuera ya del esquema v1/v2 clásico. El resto de recursos sigue dependiendo de v1 porque v2 todavía no los cubre.
Grail no sustituye a la API REST: sustituye a una parte de su uso. En entornos SaaS con Grail habilitado, la propia documentación desaconseja usar la API REST clásica para consultas analíticas pesadas: por ejemplo, para Logs v2 se indica explícitamente que no se recomienda ejecutar consultas de Grail a través de esa API, y que conviene usar la API de Grail (DQL) directamente. Pero la API REST sigue siendo necesaria en SaaS para configuración, gestión de tokens, entidades, settings y todo lo que Grail no almacena ni consulta.
Entonces, en Managed: ¿conviene usar la API o es la única opción?
Las dos cosas a la vez. No es una cuestión de preferencia ni de buenas prácticas opcionales: en Managed, la API REST v1/v2 es la única vía estructural para extraer datos, generar informes y automatizar cualquier flujo de trabajo. No hay DQL al que migrar progresivamente, ni notebooks que sustituyan al scripting. Lo que en SaaS es «una opción más, recomendada solo para ciertos casos», en Managed es la columna vertebral completa de cualquier integración.
Esto tiene consecuencias prácticas que conviene tener en cuenta si gestionas un entorno Managed:
La inversión en dominar bien la API REST tiene más retorno aquí que en SaaS. Paginación eficiente con nextPageKey, uso correcto de entity selectors y problem/event selectors, gestión de scopes de token granulares: en SaaS estas técnicas resuelven una minoría de casos de uso (todo lo que no cubre DQL); en Managed resuelven el cien por cien.
Los límites de acceso son los mismos que en SaaS, y conviene diseñar con ellos en mente desde el principio. Dynatrace no cobra por lectura —el acceso de lectura a la API es gratuito bajo un modelo de uso razonable— pero sí aplica limitación de peticiones (throttling): cada entorno dispone de un pool de hilos limitado con cola de espera, y al saturarse devuelve un código 429.. El payload de cada petición está limitado a 1 MB, con excepciones específicas para subida de símbolos móviles, extensiones, plugins o ingesta de logs y telemetría OpenTelemetry. El diseño está pensado para permitir muchas peticiones baratas sin penalización, mientras protege el entorno frente a peticiones caras y masivas — justo el patrón que conviene seguir cuando no existe la alternativa de resolver una consulta compleja en una sola llamada DQL.
No hay un «DQL ligero» al que recurrir para prototipar rápido. En SaaS, cuando una idea de informe no está clara, se puede explorar con una query DQL en minutos antes de decidir si merece la pena automatizarla. En Managed esa fase de exploración rápida no existe: cualquier prototipo pasa por construir la llamada a la API, paginar, y procesar la respuesta en tu propio código. Vale la pena invertir en herramientas intermedias —un cliente bien estructurado, notebooks Python propios, dtctl para tareas administrativas— que reduzcan esa fricción.
Si existe la posibilidad de migrar a SaaS en el futuro, una parte del trabajo de extracción de datos no es portable tal cual. Las consultas DQL no tienen equivalente directo en la API REST clásica, así que cualquier diseño orientado a «algún día migraremos» debería separar con cuidado la capa de extracción (que cambiará) de la capa de procesamiento y reporting (que puede reutilizarse).
La conclusión incómoda
No es que la API REST sea peor que DQL y haya que conformarse con ella en Managed. Es que ambas resuelven problemas distintos, y la confusión surge porque buena parte de la documentación, los ejemplos de la comunidad y los propios posts técnicos del sector dan por hecho un mundo con Grail que, para una porción nada pequeña de organizaciones —especialmente en sector público y entornos regulados, donde Managed sigue siendo la opción obligada— simplemente no existe ni va a existir. Entender esa diferencia desde el primer día ahorra bastante frustración la primera vez que se aterriza en un entorno así.
Fuentes consultadas
- Classic Environment v2 — Dynatrace Developer
- Migration guides for deprecated APIs — Dynatrace Docs
- Migrate from Events API v1 to Events API v2 — Dynatrace Docs
- Migrate from Problems API v1 to Problems API v2 — Dynatrace Docs
- Grail and Dynatrace Managed — Dynatrace Community
- What is Dynatrace Grail? — Dynatrace Docs
- Dynatrace API – Access limit — Dynatrace Docs
