detección de valor atípico

La detección de valores atípicos de New Relic es una función avanzada diseñada para identificar automáticamente las entidades que se comportan de manera significativamente diferente a sus pares. A diferencia de la detección de anomalías tradicional, que busca patrones inusuales a lo largo del tiempo, la detección de valores atípicos se centra en las desviaciones dentro de un grupo en un momento específico.

Esta funcionalidad le ayuda a identificar proactivamente problemas potenciales, tales como:

Un solo servidor que experimenta un alto uso de CPU en comparación con otros en su clúster
Un broker de Kafka que no procesa mensajes correctamente

Al identificar estos "valores atípicos", puede encontrar rápidamente los sistemas descendentes relacionados e inferir la probabilidad de falla, reduciendo así el Tiempo medio de detección (MTTD) y el Tiempo medio de recuperación (MTTR).

Conceptos clave

Comprender estos conceptos fundamentales le ayudará a configurar la detección de valores atípicos de manera efectiva:

DBSCAN: Un algoritmo de agrupamiento basado en densidad que agrupa puntos que están muy próximos entre sí, mientras identifica como valores atípicos a los puntos que no pertenecen a ningún grupo.
Epsilon (Eps): Define la distancia máxima entre dos puntos para que se consideren parte de la misma vecindad. Un valor menor crea clústeres más compactos, mientras que un valor mayor crea clústeres más dispersos.
Puntos mínimos (MinPts): El número mínimo de puntos requeridos para formar un clúster. Se recomienda un valor mayor que 3 para la mayoría de los casos de uso.
Grupos de evaluación: Permite segmentar el análisis de valores atípicos mediante diferentes facetas (como entorno, región o aplicación) para que los valores atípicos se detecten dentro de cada grupo por separado, en lugar de hacerlo en todo el conjunto de datos. Esto garantiza que los valores atípicos se detecten dentro de cada grupo por separado, reduciendo la necesidad de múltiples condiciones de alerta.

Modo automático vs. manual

Tiene dos modos distintos para configurar los parámetros principales, lo que garantiza que obtenga la alerta adecuada para sus datos:

Auto mode es la manera más rápida de configurar su alerta de valores atípicos. Le permite omitir los detalles técnicos del algoritmo, liberándolo de la necesidad de entender complejos parámetros de aprendizaje automático.

En lugar de configurar parámetros técnicos, ajusta un sencillo control deslizante de sensibilidad. El sistema utiliza estimaciones automáticas para calcular instantáneamente los valores óptimos de Épsilon (Eps) y Puntos mínimos (MinPts) correspondientes a su nivel de sensibilidad seleccionado.

Para verificar si las estimaciones automáticas son correctas para sus datos, observe la visualización de datos. Si las señales marcadas como valores atípicos en el gráfico coinciden con su sentido común de una anomalía, el modo automático está funcionando eficazmente.

Manual mode es para usuarios avanzados o situaciones en las que las estimaciones automáticas del sistema no se ajustan del todo a las características únicas de sus datos. Cambiar al modo manual le permite controlar directamente los parámetros de DBSCAN.

Debe cambiar al modo manual si los resultados del modo automático son inexactos:

El sistema marca señales como valores atípicos que visualmente aún son parte de un clúster.
El sistema no logra marcar una señal que está claramente distante del clúster de datos principal.
Mover el control deslizante de Sensibilidad a lo largo de todo su rango produce poco o ningún cambio significativo en los valores atípicos detectados.

Crear una condición de alerta de detección de valores atípicos

Siga estos pasos para crear una condición de alerta con detección de valores atípicos:

En su cuenta de New Relic, vaya a one.newrelic.com > All capabilities > Alerts > Alert Conditions.
Haga clic en + Nueva condición de alerta y seleccione Usar modo guiado o el modo Consulta **. Independientemente del modo que elija, establece los umbrales para su condición de alerta en la página de establecer umbrales.
Siga los pasos hasta llegar a la página de establecer umbrales.
Seleccione outliers.
Seleccione el modo de algoritmo:
- Si selecciona el modo Auto, ajuste el control deslizante de sensibilidad para afinar la detección. En este modo, el sistema determina automáticamente los parámetros internos óptimos (como Epsilon y puntos mínimos para DBSCAN) basándose en sus datos históricos.
- Si elige el modo Manual, puede especificar los valores de Epsilon y Puntos mínimos usted mismo.
Opcionalmente, configure un grupo de evaluación.
Complete el resto de la configuración de la condición de alerta.

Mejores prácticas de configuración

Elección de valores épsilon

Comience con los valores predeterminados y ajuste según las características de sus datos.
Monitoree las tasas de falsos positivos y ajuste según corresponda.
Épsilon más pequeño para una detección más sensible.
Épsilon más grande para una detección menos sensible.

Configuración de puntos mínimos

Use valores mayores que 3 para la mayoría de los escenarios.
Los valores más altos reducen el ruido, pero pueden pasar por alto valores atípicos sutiles.
Considere los tamaños de grupo típicos al configurar este valor.

Uso efectivo de grupos de evaluación

Agrupe por límites lógicos (ambiente, región, servicio).
Evite la segmentación excesiva, que puede reducir la efectividad.
Considere la estacionalidad y los patrones de negocio al agrupar.

Manejo de datos retrasados y timestamps más antiguos

La detección de valores atípicos funciona comparando métricas de múltiples entidades en el mismo momento. Para hacer una comparación justa, todas las entidades deben reportar datos para la misma ventana de tiempo.

El problema con los timestamps retrasados

Imagine que está monitoreando el uso de CPU en tres servidores a las 2:00 p. m.:

Servidor A reporta 45 % de CPU con timestamp 2:00 PM
El servidor B reporta 50 % de CPU con timestamp 2:00 PM
Servidor C reporta 95 % de CPU con timestamp 1:30 PM

Los datos del servidor C tienen un timestamp más antiguo (1:30 p. m. en lugar de 2:00 p. m.). El sistema no puede comparar los datos de la 1:30 p. m. con los datos de las 2:00 p. m. —es como comparar peras con manzanas. Como resultado, el servidor C queda excluido por completo del análisis de valores atípicos. Aunque el servidor C está experimentando claramente un problema, no recibirá una alerta porque nunca fue evaluado.

Esto ocurre cuando una entidad reporta datos constantemente con timestamp más antiguos que la ventana de tiempo actual que se está analizando.

Causas comunes

Sondeo de proveedores de la nube: AWS CloudWatch y servicios similares recopilan métricas de forma programada, y luego New Relic las sondea más tarde. Por ejemplo, una métrica que representa las 2:00 p. m. podría no llegar a New Relic hasta las 2:05 p. m., lo que crea un retraso de 5 minutos.
Transacciones de larga duración: los trabajos en segundo plano reciben un timestamp cuando comienzan, no cuando terminan. Un trabajo que comienza a la 1:30 p. m. y se ejecuta durante 30 minutos tendrá un timestamp de la 1:30 p. m. cuando sus datos lleguen a las 2:00 p. m.
Datos en búfer: los problemas de red o la configuración del agente pueden hacer que los datos se pongan en cola localmente. Cuando se restablece la conectividad, todos los datos almacenados en búfer llegan con sus timestamps originales.

Identificación de entidades excluidas

Para ver qué entidades se están excluyendo y por qué, consulte el evento NrAiSignal:

FROM NrAiSignal
SELECT *
WHERE conditionId = 1234
  AND outlierProcessingSkippedReason IS NOT NULL

Reemplace 1234 con el ID de su condición de alerta. Campos clave a examinar:

outlierProcessingSkippedReason: por qué se excluyó la señal (normalmente muestra LATE para datos retrasados)
outlierProcessingSkippedTimeDelta: la diferencia de tiempo en segundos entre el timestamp de los datos y la ventana de evaluación actual

Resolver el problema

Si ve una advertencia en el editor de condiciones que indica que se están excluyendo señales:

Opción 1: dividir la condición (recomendado)

Cree condiciones de alerta independientes para entidades con diferentes comportamientos de reporte:

Una condición para servidores de aplicaciones en tiempo real
Otra condición para los recursos sondeados en la nube (como las métricas de AWS CloudWatch)

Esto garantiza que la ventana de agregación de cada condición coincida con la forma en que sus entidades realmente reportan los datos.

Opción 2: aumentar la ventana de agregación

Expande tu ventana de agregación para admitir retrasos. Por ejemplo, si sus datos llegan constantemente con 3-5 minutos de retraso, use una ventana de agregación de 5 minutos en lugar de 1 minuto.

Compensación: las ventanas más grandes suavizan los picos a corto plazo y aumentan el tiempo antes de que se active una alerta. Un servidor que registra un pico a las 2:00 p. m. podría no activar una alerta hasta las 2:05 p. m. o más tarde.

Casos de uso y ejemplos

Brokers de Kafka desequilibrados: Identifique rápidamente los brokers con tiempos de espera de E/S de CPU anormales, lo que permite a los administradores reequilibrar proactivamente las cargas de trabajo antes de que el rendimiento se vea afectado.
Valores atípicos de utilización de recursos: Identifique los recursos que están consistentemente subutilizados o sobreutilizados. Esto permite una mejor planificación de la capacidad y evita el desperdicio o posibles cuellos de botella.
Identificación de "vecinos ruidosos": Detecte entidades que acaparan recursos y consumen una cantidad desproporcionada de recursos compartidos. Esto permite tomar medidas correctivas para equilibrar la asignación de recursos.
Problemas de memoria en aplicaciones Java: Detección temprana de máquinas virtuales de Java (JVM) con tasas anormales de errores de falta de memoria (OOM), lo que permite una intervención oportuna para evitar fallas generalizadas de la aplicación.
Monitoreo específico del entorno: Utilice grupos de evaluación para monitorear los entornos de staging y producción por separado, asegurando que los valores atípicos en un entorno no interfieran con la detección en otro.

Te ofrecemos esta traducción automática para facilitar la lectura.

Conceptos clave .css-21sua1{background:none;border:none;width:0;padding:0;}