La detección de anomalías es una función algorítmica que identifica cuando una métrica se comporta de forma diferente a como lo ha hecho en el pasado y tiene en cuenta las tendencias, el día de la semana específico y los patrones de horas del día. Es adecuada para métricas con tendencias marcadas y patrones recurrentes, difíciles de monitorizar mediante alertas con umbrales.
Por ejemplo, la detección de anomalías te puede ayudar a detectar cuando el tráfico de tu web es inusualmente bajo en un día laborable, por ejemplo por la tarde, pero luego se normaliza por la noche. O piensa por ejemplo en una métrica que pueda medir el número de accesos a tu sitio web en constante crecimiento. Dado que ese número aumenta a diario, cualquier umbral quedaría obsoleto, mientras que la detección de anomalías puede avisarte si se produce un descenso inesperado, lo que podría indicar un problema con el sistema de inicio de sesión.
Para crear un monitor de anomalías en Datadog utiliza la navegación principal: Monitors –> New Monitor –> Anomaly (Monitores > Nuevo monitor > Anomalía).
Cualquier métrica que informe a Datadog está disponible para monitores. Para obtener más información, consulta la página Monitor de métricas.
Nota: La función para anomalies utiliza el pasado para predecir lo que se espera en el futuro, por lo que su uso en una métrica nueva podría no dar buenos resultados.
Después de definir la métrica, el monitor de detección de anomalías proporciona dos gráficos de vista previa en el editor:
La Vista del historial te permite explorar la consulta monitorizada en diferentes escalas temporales, para comprender mejor por qué los datos pueden considerarse anómalos o no anómalos.
La Vista previa de evaluación es más extensa que la ventana de alertas y ofrece una visión de lo que el algoritmo de anomalías tiene en cuenta al calcular los límites.
Activa una alerta si los valores han estado above or below, above o below de los límites durante los últimos 15 minutes, 1 hour, etc. o custom para establecer un valor entre 15 minutos y 24 horas. Ejecuta una recuperación si los valores están dentro de los límites durante al menos 15 minutes, 1 hour, etc. o custom para establecer un valor entre 15 minutos y 24 horas.
Detección de anomalías
con la opción por defecto (above or below), una métrica se considera anómala si está fuera del rango gris de anomalías. También puedes especificar si los rangos se consideran anómalos cuando los valores sólo están above o below.
Ventana de activación
la cantidad de tiempo necesario para que la métrica sea anómala antes de que se active la alerta. Nota: Si la ventana de alertas es demasiado corta, podrías recibir falsas alarmas generadas por falsos ruidos.
Ventana de recuperación
la cantidad de tiempo necesario para que la métrica deje de considerarse anómala, permitiendo la recuperación de la alerta. Se recomienda configurar la Ventana de recuperación con el mismo valor que la Ventana de activación.
Nota: El rango de valores aceptados para la Ventana de Recuperación depende de la Ventana de activación y del Umbral de Alerta, para asegurar que el monitor no cumpla la condición de recuperación y la de alerta al mismo tiempo.
Ejemplo:
Threshold: 50%
Trigger window: 4h
El rango de valores aceptados para la ventana de recuperación oscila entre 121 minutos (4h*(1-0.5) +1 min = 121 minutes) y 4 horas. Configurar una ventana de recuperación de menos de 121 minutos podría dar lugar a un marco temporal de 4 horas con un 50% de puntos anómalos y los últimos 120 minutos sin puntos anómalos.
Otro ejemplo:
Threshold: 80%
Trigger window: 4h
El rango de valores aceptados para la ventana de recuperación oscila entre 49 minutos (4h*(1-0.8) +1 min = 49 minutes) y 4 horas.
Datadog analiza automáticamente la métrica elegida y establece varios parámetros. Sin embargo, puedes editar las opciones en Advanced Options (Opciones avanzadas).
Desviaciones
el ancho del rango gris. Equivale al parámetro de límites utilizado en la función para anomalías.
temporalidad (hourly, daily o weekly) del ciclo para que el algoritmo agile o robust analice la métrica.
Cambio de horario estacional
disponible para la detección de anomalías agile o robust con temporalidad weekly o daily. Para obtener más información, consulta Detección de anomalías y zonas horarias.
el algoritmo espera que el mismo minuto después de la hora en punto se comporte como los minutos anteriores después de sus respectivas horas en punto. Por ejemplo, 5:15 se comporta como 4:15, 3:15, etc.
Diario
el algoritmo espera que la misma hora de hoy se comporte como la hora de los días pasados. Por ejemplo la hora 17:00 de hoy se comporta como la hora 17:00 de ayer.
Semanal
el algoritmo espera que un determinado día de la semana se comporte como los días de las semanas anteriores. Por ejemplo, este martes se comporta como los martes anteriores.
Historial de datos requerido para el algoritmo de detección de anomalías: los algoritmos de machine learning requieren al menos el triple de tiempo de datos históricos que el tiempo de temporalidad elegido para calcular la línea de base.
Por ejemplo:
La temporalidad semanal requiere al menos tres semanas de datos
La temporalidad diaria requiere al menos tres días de datos
La temporalidad horaria requiere al menos tres horas de datos
Todos los algoritmos temporales pueden utilizar hasta seis semanas de datos históricos a la hora de calcular el rango de comportamiento normal esperado para la métrica. Al utilizar una cantidad significativa de datos pasados, los algoritmos evitan dar demasiada importancia a los comportamientos anómalos que puedan haberse producido en un pasado reciente.
se utilizan cuando las métricas no tienen un patrón de temporalidad repetitivo. Los algoritmos básicos utilizan un simple cálculo de cuantiles móviles retardados para determinar el intervalo de valores esperados. Utilizan pocos datos y se ajustan rápidamente a las condiciones cambiantes, pero no conocen el comportamiento temporal ni las tendencias a más largo plazo.
Ágiles
se utilizan cuando cuando las métricas son temporales y se espera que cambien. Los algoritmos se ajustan rápidamente a los cambios de nivel de las métricas. Se trata de una versión robusta del algoritmo SARIMA, que incorpora el pasado inmediato en sus predicciones, lo que permite actualizaciones rápidas para los cambios de nivel, a expensas de ser menos robusto frente a las anomalías recientes de larga duración.
Robustos
se utilizan cuando se espera que las métricas temporales sean estables, y los cambios de nivel lentos se consideran anomalías. Un algoritmo de descomposición de tendencias temporales es estable y las predicciones permanecen constantes, incluso en caso de anomalías de larga duración, a expensas de tardar más en responder a los cambios de nivel previstos (por ejemplo, si el nivel de una métrica cambia debido a un cambio de código).
En este ejemplo, basic identifica con éxito los picos de anomalías fuera del rango normal de valores, pero no incorpora el patrón temporal repetitivo a su rango de valores previstos. Por el contrario, robust y agile reconocen el patrón temporal y pueden detectar anomalías más matizadas; por ejemplo, si la métrica se estabiliza cerca de su valor mínimo. La tendencia también muestra un patrón horario, por lo que la temporalidad horaria funciona mejor en este caso.
En este ejemplo, la métrica muestra un cambio de nivel repentino. Agile se ajusta más rápidamente al cambio de nivel que robust. Además, la amplitud de los límites de robust aumenta para reflejar una mayor incertidumbre tras el cambio de nivel; la amplitud de los límites de agile permanece invariable. Basic no se ajusta bien a este escenario, en el que la métrica muestra un fuerte patrón temporal semanal.
Este ejemplo muestra cómo reaccionan los algoritmos ante una anomalía de una hora de duración. Robust no ajusta los límites de la anomalía en este escenario, ya que reacciona más lentamente ante los cambios bruscos. Los demás algoritmos empiezan a comportarse como si la anomalía fuera la nueva normalidad. Agile identifica incluso el regreso de la métrica a su nivel original como una anomalía.
Los algoritmos tratan a las escalas de forma diferente. Basic y robust son insensibles a las escalas, mientras que agile no lo es. Los gráficos abajo a la izquierda muestran que agile y robust señalan el cambio de nivel como anómalo. A la derecha, se añade 1000 a la misma métrica y agile deja de señalar el cambio de nivel como anómalo, mientras que robust sigue haciéndolo.
Este ejemplo muestra cómo cada algoritmo trata una métrica nueva. Robust y agile no muestran ningún límite durante las primeras temporalidades (semanales). Basic empieza a mostrar límites poco después de que aparece la métrica por primera vez.
Para obtener instrucciones detalladas sobre las opciones avanzadas de alerta (resolución automática, periodo de espera para la evaluación, etc.), consulta la página de configuración de monitores. Para la opción de ventana de datos de métricas completa, consulta la página Monitor de métricas.
Los clientes con un plan de empresa pueden crear monitores de detección de anomalías utilizando el endpoint de la API create-monitor. Datadog recomienda encarecidamenteexportar el JSON de monitor para crear la consulta para la API. Al utilizar la página de creación de monitores en Datadog, los clientes se benefician del gráfico de vista previa y del ajuste automático de parámetros para ayuda a evitar una mala configuración del monitor.
Nota: Los monitores de detección de anomalías sólo están disponibles para clientes con un plan de empresa. Los clientes con un plan profesional, que estén interesados en los monitores de detección de anomalías, deben ponerse en contacto con sus representantes de atención al cliente o enviar un correo electrónico al equipo de facturación de Datadog.
Los monitores de anomalías se gestionan utilizando la misma API que otros monitores. Estos campos son exclusivos para monitores de anomalías:
un marco temporal como last_4h o last_7d. La ventana temporal que se muestra en los gráficos de las notificaciones debe ser al menos tan grande como la alert_window y se la recomienda por ser unas 5 veces la alert_window.
metric_query
una consulta de métricas estándar de Datadog (por ejemplo, sum:trace.flask.request.hits{service:web-app}.as_count()).
algorithm
basic, agile o robust.
deviations
un número positivo; controla la sensibilidad de la detección de anomalías.
direction
la direccionalidad de las anomalías que debe activar una alerta: above, below o both.
alert_window
el marco temporal que debe verificarse para buscar anomalías (por ejemplo, last_5m, last_1h).
interval
un número entero positivo que representa el número de segundos del intervalo de rollup. Debe ser menor o igual a un quinto de la duración de la alert_window.
count_default_zero
utiliza true para la mayoría de los monitores. Utiliza false sólo para enviar una métrica de recuento en la que la falta de un valor no debe interpretarse como un cero.
seasonality
hourly, daily o weekly. Excluye este parámetro cuando utilices el algoritmo basic.
threshold
número positivo no superior a 1. Fracción de puntos en la alert_window que deben ser anómalos para que se active una alerta crítica.
A continuación se muestra un ejemplo de consulta de monitor de detección de anomalías, que envía alertas cuando el promedio de CPU del nodo Cassandra se encuentra tres desviaciones estándar por encima del valor ordinario en los últimos 5 minutos:
La mayoría de las propiedades de options en el cuerpo de la solicitud son las mismas que para otras alertas de consulta, excepto thresholds y threshold_windows.
thresholds
los monitores de anomalías admiten umbrales critical, critical_recovery, warning y warning_recovery. Los umbrales se expresan como números de 0 a 1 y se interpretan como la fracción de la ventana asociada que es anómala. Por ejemplo, un valor de umbral critical de 0.9 significa que se activa una alerta crítica cuando al menos el 90% de los puntos en la trigger_window (descrita a continuación) son anómalos. O, un valor de warning_recovery de 0 significa que el monitor se recupera del estado de alerta sólo cuando el 0% de los puntos en la recovery_window son anómalos.
El threshold``critical debe coincidir con el threshold utilizado en la query.
threshold_windows
los monitores de anomalías tienen una propiedad threshold_windows en options. threshold_windows debe incluir las dos propiedades, trigger_window y recovery_window. Estas ventanas se expresan en forma de cadenas de marco temporal, como last_10m o last_1h. La trigger_window debe coincidir con la alert_window de la query. La trigger_window es el rango de tiempo que se analiza en busca de anomalías cuando se evalúa si un monitor debe activarse. La recovery_window es el rango de tiempo que se analiza en busca de anomalías cuando se evalúa si un monitor activado debe recuperarse.
La configuración estándar de umbrales y de ventanas de umbrales tiene el siguiente aspecto:
