La proliferación de alertas irrelevantes puede degradar seriamente la efectividad de cualquier estrategia de observabilidad. Con Dynatrace DQL, es posible construir consultas precisas que reduzcan falsos positivos y ayuden a los equipos a focalizar su atención en incidentes reales. Este artículo explica cómo aplicar DQL sobre logs y métricas de manera práctica.
Introducción
En entornos complejos, los equipos de operaciones suelen enfrentarse a un problema recurrente: el exceso de alertas. Muchas de ellas son notificaciones irrelevantes, redundantes o directamente falsas. Este “ruido” puede provocar fatiga operativa y retrasar la respuesta ante incidentes críticos.
La Dynatrace Query Language (DQL) surge como una herramienta poderosa para filtrar, correlacionar y transformar datos observables —logs, métricas, trazas y eventos— directamente desde el backend de Dynatrace. Con ella, es posible diseñar consultas personalizadas que identifican patrones reales y minimizan los falsos positivos en las alertas.
En este artículo exploraremos:
- Qué es DQL y por qué es diferente de un simple filtro.
- Cómo aplicar consultas sobre logs y métricas.
- Ejemplos prácticos para reducir el ruido de alertas.
- Buenas prácticas y recomendaciones finales.
Qué es DQL y por qué importa
Un lenguaje de consultas pensado para observabilidad
DQL (Dynatrace Query Language) es un lenguaje declarativo, inspirado en conceptos familiares para quienes conocen SQL o Splunk SPL, pero optimizado para datos observacionales. Permite:
- Consultar logs, métricas y eventos.
- Realizar agregaciones en tiempo real.
- Correlacionar señales procedentes de distintas fuentes.
- Aplicar funciones de enriquecimiento y transformación.
Su objetivo no es solo “buscar” datos, sino generar insights directamente explotables para decisiones de monitoreo.
Diferencias con filtros tradicionales
Un filtro clásico en un panel o alerta simplemente excluye o incluye datos según condiciones básicas (ej. status=error). DQL, en cambio, permite aplicar lógica condicional avanzada, uniones, ventanas temporales y cálculos que ayudan a determinar si un patrón realmente representa un incidente.
Por ejemplo:
- Un pico puntual de errores 500 puede ser irrelevante si desaparece en segundos.
- Un aumento sostenido de latencia en dos servicios correlacionados sí podría indicar un problema real.
Consultando logs con DQL
Estructura básica de una consulta de logs
Una consulta típica sobre logs en DQL sigue esta estructura:
fetch logs
| filter loglevel == "ERROR" and contains(message, "timeout")
| summarize count() by bin(timestamp, 1m)
Explicación paso a paso:
fetch logs: indica que queremos trabajar con el dataset de logs.filter: aplica condiciones sobre el nivel de log y el contenido del mensaje.summarize count() by bin(timestamp, 1m): agrega los resultados por intervalos de 1 minuto, útil para detectar patrones sostenidos.
Reducción de falsos positivos
Muchos falsos positivos provienen de errores transitorios. Podemos atenuarlos con una condición temporal:
fetch logs
| filter loglevel == "ERROR" and contains(message, "timeout")
| summarize errors_per_min = count() by bin(timestamp, 1m)
| filter errors_per_min > 5
Aquí solo consideramos incidentes si se registran más de 5 errores por minuto. Esto reduce notificaciones innecesarias por eventos aislados.
Ejemplo: correlación entre dos servicios
Imagina un escenario con dos microservicios que fallan en cascada. Podemos correlacionarlos:
fetch logs
| filter (service.name == "checkout" or service.name == "payment")
| filter loglevel == "ERROR"
| summarize total_errors = count() by service.name, bin(timestamp, 1m)
| filter total_errors > 10
Este tipo de consulta permite alertar solo cuando ambos servicios muestran un patrón anómalo real, no ante un error puntual.
Consultando métricas con DQL
Métricas y su contexto
La potencia de DQL (Dynatrace Query Language) reside en su integración directa con métricas y series temporales.
Por ejemplo, si queremos analizar la latencia media de un servicio con resolución de un minuto, podemos escribir:
timeseries avg_latency = avg(dt.service.request.response_time,
filter:{ service.name == "checkout" }),
interval: 1m
Este bloque genera una serie temporal con la media por minuto del tiempo de respuesta del servicio checkout.
El parámetro interval: 1m agrupa automáticamente los datos en ventanas de un minuto, sin necesidad de definir columnas adicionales.
💡 Consejo: puedes ajustar el intervalo (
5m,30s,1h, etc.) según la granularidad que necesites, evitando falsos positivos por picos puntuales.
Trabajando con logs
Del mismo modo, los logs pueden convertirse en series temporales mediante la función makeTimeseries.
Así es posible, por ejemplo, contar el número de errores (loglevel == "ERROR") por minuto en un servicio concreto:
fetch logs
| filter loglevel == "ERROR" and service.name == "checkout"
| makeTimeseries errors = count(), interval: 1m
Este comando genera una serie en la que cada punto representa el número de errores por minuto del servicio checkout.
Puedes visualizarla directamente como un gráfico de líneas dentro de un Notebook para detectar fácilmente picos de actividad o momentos anómalos.
Correlacionando logs y métricas
Una de las capacidades más potentes de DQL es poder correlacionar diferentes fuentes de datos —por ejemplo, errores en logs y métricas de latencia— en una misma consulta.
El siguiente ejemplo une ambas series por su ventana de tiempo (1 min):
// Errores por minuto (logs)
fetch logs
| filter loglevel == "ERROR" and service.name == "checkout"
| makeTimeseries error_count = count(), interval: 1m
// Unión con la latencia media por minuto del mismo servicio
| join [
timeseries avg_latency = avg(dt.service.request.response_time,
filter:{ service.name == "checkout" }),
interval: 1m
]
// Filtro de correlación
| filter error_count > 10 and avg_latency > 2000
Este patrón permite detectar condiciones compuestas: por ejemplo, minutos en los que coinciden más de 10 errores y una latencia media superior a 2 s (2000 ms).
Es una técnica eficaz para reducir el ruido y enfocar las alertas solo en situaciones realmente relevantes.positivos en entornos complejos.
Buenas prácticas con DQL
1. Usar agregaciones en ventanas temporales
Las condiciones basadas en promedios o recuentos por minuto ayudan a evitar alertas por picos breves. Ajusta la ventana temporal según el comportamiento normal de tu aplicación.
2. Correlacionar múltiples señales
Combinar logs con métricas —e incluso con trazas— mejora la fiabilidad de las alertas. DQL facilita esta correlación en una sola consulta.
3. Filtrar en la fuente, no en el panel
Evita sobrecargar paneles con lógica compleja. Haz la depuración directamente en la consulta DQL, reduciendo así la complejidad aguas abajo.
4. Documentar y versionar las consultas
Trata tus consultas DQL como código: documenta su objetivo, parámetros y umbrales, y guárdalas en repositorios versionados.
5. Validar las consultas con datos históricos
Antes de automatizar una alerta, prueba tu DQL sobre periodos históricos para asegurarte de que la lógica realmente discrimina ruido de incidentes.
Ejemplo práctico: detección de errores sostenidos en checkout
Escenario: un equipo de e-commerce quiere evitar alertas cada vez que un cliente experimenta un error puntual al pagar.
Objetivo: alertar solo si hay un patrón sostenido de fallos.
Consulta DQL:
fetch logs
| filter service.name == "checkout" and loglevel == "ERROR" and contains(message, "payment failed")
| summarize error_count = count() by bin(timestamp, 1m)
| filter error_count > 20
- Si hay más de 20 errores en un minuto, la alerta se activa.
- Si solo hay 1 o 2 errores aislados, se ignoran.
Resultado: menos falsos positivos, más foco en incidentes reales.
Conclusión
La reducción de falsos positivos no depende únicamente de mejores umbrales: requiere inteligencia en la consulta de datos.
Con DQL, los equipos de observabilidad pueden construir condiciones sofisticadas que capturen patrones significativos y filtren el ruido operativo.
Esto no solo mejora la eficacia de los equipos de operaciones y SRE, sino que también contribuye a:
- Mayor confiabilidad en las alertas.
- Menor tiempo de respuesta ante incidentes reales.
- Menos desgaste y fatiga de alerta.
📈 CTA: Si aún no estás usando DQL activamente, empieza por identificar las alertas con más falsos positivos en tu entorno y construye una consulta DQL que las refine. Unas pocas líneas bien escritas pueden transformar tu estrategia de observabilidad.