La detección de anomalías le brinda a su equipo un monitoreo flexible y adaptable para el comportamiento inusual en sus sistemas. En lugar de depender de umbrales fijos, aprende los patrones normales de sus datos y se ajusta automáticamente, lo que reduce las falsas alarmas y el exceso de alertas. Puede ajustar la sensibilidad, agregar contexto personalizado a las notificaciones de alerta y dejar que New Relic aprenda sus tendencias de línea de base automáticamente, o establecer las suyas.
Guía de inicio rápido
- Cuándo usar la detección de anomalías
- Cómo funciona la detección de anomalías
- Configurar umbrales
- Configuración de estacionalidad
- Dirección de la anomalía
- Comprenda cuándo se activan las alertas
- Condiciones de múltiples señales
- Ajuste los umbrales usando datos de señales
- Solucionar problemas comunes
Cuándo usar la detección de anomalías frente a los umbrales estáticos
Los umbrales estáticos están fijados a números fijos. La detección de anomalías evalúa el comportamiento matemático esperado de una señal a lo largo del tiempo. Use esta tabla para elegir el modelo adecuado para su métrica:
| Guión | Tipo recomendado | Por qué |
|---|---|---|
| Patrones naturales o estacionales (horario comercial, ciclos semanales, picos de compras estacionales) | Anomalía | Aprende las líneas de base cíclicas para que los picos programados no desencadenen tormentas de alertas |
| Sistemas dinámicos donde lo "normal" cambia con el tiempo | Anomalía | Se adapta automáticamente a medida que el sistema crece, sin reajustes manuales |
| Métricas nuevas o altamente volátiles | Estático (temporalmente) | La detección de anomalías necesita de 1-4 semanas de historial para crear una línea de base estable, y las métricas volátiles pueden producir bandas demasiado anchas para ser útiles |
| Límites estrictos de capacidad (espacio en disco, memoria, límites de conexión) | Estático | Los límites físicos críticos necesitan acción inmediata independientemente de las tendencias de los patrones pasados |
| SLA u objetivos de cumplimiento (por ejemplo, tiempo de respuesta < 2 segundos) | Estático | Ideal cuando debe garantizar un límite de rendimiento fijo |
| Estados binarios (servicio activo/inactivo, fallas de pago) | Estático | Estos no son patrones — cualquier falla importa |
Cómo funciona la detección de anomalías
New Relic evalúa las tendencias históricas para construir una línea de base predicha y una zona de variación aceptable (la banda gris) a su alrededor:
- Fase de aprendizaje: New Relic observa sus datos durante 1-4 semanas y aprende patrones como "los lunes siempre hay mucha actividad" o "el tráfico cae a las 6 p. m.".
- Predicción: el sistema predice cuál debería ser su próximo punto de datos, basándose en patrones históricos.
- Zona de variación (banda gris): una banda de variación aceptable rodea la predicción. Piense en ello como una carretera con barandillas — mantenerse dentro de las barandillas es normal.
- Desencadenador de alerta: una alerta se activa solo cuando sus datos reales salen de la zona de variación y permanecen allí durante la duración especificada.
New Relic también ajusta estas predicciones automáticamente:
- Coherencia de datos: las métricas que se mantienen en un rango estrecho y predecible obtienen bandas más estrechas. Las métricas ruidosas o impredecibles obtienen bandas más anchas, para evitar falsas alarmas.
- Fluctuaciones cíclicas: el algoritmo busca patrones recurrentes de menos de una semana (como un despliegue el miércoles a la 1 p. m. o trabajos por lotes nocturnos) y ajusta las predicciones para que coincidan.
- Antigüedad de los datos: New Relic calcula las predicciones utilizando 1-4 semanas de historial, dependiendo de la disponibilidad de los datos (las consultas que utilizan la cláusula
FACETno se entrenan con datos almacenados y comienzan a aprender desde cero). Cuanto menos historial tenga una señal, más fluctuará su línea de base. La precisión mejora a medida que se acumulan más datos, y New Relic da más peso a los datos recientes.
Configurar umbrales
Los umbrales de sensibilidad de anomalía controlan la facilidad con la que se activan sus alertas. Una mayor sensibilidad detecta cambios más pequeños, pero puede crear más falsas alarmas. Una menor sensibilidad solo alerta sobre problemas más grandes, pero podría pasar por alto problemas sutiles.
Comprender el gráfico de detección de anomalías

| Elemento gráfico | Lo que muestra |
|---|---|
| 1. Línea verde (señal) | Sus datos reales de su consulta NRQL — lo que realmente está sucediendo |
| 2. Línea de puntos negra (línea de base) | Predicción de New Relic basada en patrones históricos |
| 3. Banda gris claro (interior) | Umbral crítico — cuanto más estrecha sea la banda, más sensible será |
| 4. Banda gris oscuro (exterior) | Umbral de advertencia (opcional) — cuanto más ancha sea la banda, menos sensible será |
| 5. Áreas rojas | Eventos de alerta — su señal estuvo fuera de la banda gris durante la duración especificada |
Configuración del comportamiento del gráfico:
- Ventana de agregación: aumentarla hace que la línea de base sea más estable y reduce la variación de la señal. Disminuirla da como resultado una señal con más picos.
- Duración de la ventana: las duraciones más altas crean una línea de señal más uniforme. Las duraciones más bajas dan como resultado una señal con más picos y más sensible.
Control de sensibilidad: bandas más estrechas frente a más amplias
Esto controla directamente cuántas alertas recibe:
- Bandas más estrechas (área gris más pequeña): más cerca de la línea de base = más eventos de alerta, porque sus datos tienen menos margen para la variación normal.
- Bandas más amplias (área gris más grande): más lejos de la línea de base = menos eventos de alerta, porque sus datos pueden variar más antes de activar alertas.
Ejemplo: si su CPU normalmente funciona al 50 %:
- Banda más estrecha: alertas cuando la CPU alcanza el 55 % (más sensible)
- Banda más holgada: alertas cuando la CPU alcanza el 70 % (menos sensible)
Puede crear umbrales de sensibilidad de anomalía desde una condición de alerta. Algunos consejos para configurar umbrales de anomalía:
- Establezca la estacionalidad para especificar un patrón de estacionalidad conocido.
- Establezca la dirección de la anomalía para monitorear los eventos de alerta que ocurren por encima o por debajo de la anomalía.
- Utilice la barra deslizante para ajustar el umbral de sensibilidad de Critical, representado en el gráfico de vista previa por el área gris claro alrededor de la señal. Cuanto más estrecha sea la banda alrededor de la señal, más sensible será y más eventos de alerta generará.
- Opcionalmente, agregue un umbralWarning (el área gris más oscura alrededor de la señal) para recibir notificaciones tempranas antes de que los problemas se vuelvan críticos. Esto le da tiempo para investigar los problemas antes de que activen la alerta principal.
Siga estos pasos para crear una condición de alerta de detección de anomalías:
Vaya a one.newrelic.com > All capabilities > Alerts > Alert Conditions.
Haga clic en + New alert condition > Use guided mode (o en el modo de consulta más avanzado).
Siga los pasos guiados hasta llegar a Set thresholds.
Seleccione Anomaly.

Desde el menú desplegable Calculate seasonality, elija con qué frecuencia se repiten sus patrones de datos. Para obtener más detalles, consulte Estacionalidad.
Desde el menú desplegable Threshold direction, elija cuándo activar las alertas. Para obtener más detalles, consulte Dirección de la anomalía.
Eventos de alerta abiertos con un severity level. Elija del desplegable:
- Critical: para problemas urgentes que requieren atención inmediata (banda gris oscuro)
- Warning: para problemas menos urgentes que necesitan monitoreo (banda gris claro, opcional)
Una alerta de anomalía se activa cuando la señal (línea verde) se aleja de la línea de base (línea de puntos negra) por un número específico de desviaciones estándar. El área de la banda gris representa su rango de umbral.
Importante
Concepto crítico: la señal debe permanecer en infracción durante la duración especificada antes de crear un evento de alerta — un breve pico que se autocorrige no activará uno. Consulte Comprender cuándo se activan las alertas para obtener la cronología completa de cómo se abre y se cierra una alerta.
Configure los ajustes de umbrales:
Elija reglas de tiempo:
- For at least - La señal debe permanecer fuera de la banda durante todo el período de tiempo antes de alertar. Reduce las falsas alarmas.
- At least once in - Alerta cuando la señal sale de la banda dentro de la ventana de tiempo. Detección más rápida.
Establecer la duración de la infracción: elija en el desplegable cuánto tiempo (en minutos) debe permanecer la señal fuera del umbral:
- Menor duración = más eventos de alerta (incluso las infracciones breves activan alertas)
- Mayor duración = menos eventos de alerta (solo las infracciones sostenidas desencadenan alertas)
Establecer el nivel de sensibilidad (desviaciones estándar): utilice el control deslizante para controlar la rigidez de la banda:
- Banda más estrecha (hacia "más eventos de alerta") = la señal tiene menos espacio para la desviación, más alertas
- Banda más amplia (hacia "menos eventos de alerta") = la señal tiene más espacio para la desviación, menos alertas
Puede agregar un umbral más haciendo clic en + Add threshold para crear niveles de advertencia y críticos con diferentes ajustes de sensibilidad.
Agregue los detalles de la condición de alerta y haga clic en Save condition.
Configuración de estacionalidad
La estacionalidad ayuda a la detección de anomalías a distinguir entre los cambios esperados (como un mayor tráfico durante el horario laboral o las ralentizaciones de los fines de semana) y los problemas reales (como las interrupciones del sistema).
| Su patrón | Elija |
|---|---|
| No está seguro, es mixto o es un entorno complejo (microservicios, aplicaciones globales) | Cálculo de New Relic (recomendado) |
| La métrica debe mantenerse plana — cualquier pico es un problema (errores, eventos de seguridad) | Ninguno |
| Actividad en horario laboral (herramientas internas, aplicaciones corporativas) | A diario |
| Días laborables ocupados, fines de semana tranquilos (aplicaciones B2B, servicios basados en la oficina) | Semanalmente |
| Trabajos programados regulares (procesamiento por lotes por hora) | Cada hora |
Dirección de la anomalía
Puede elegir si desea que la condición busque un comportamiento que supere el valor predicho ("superior"), que esté por debajo del valor predicho ("inferior") o ambos. Esto se elige con el selector de dirección de predicción, para cualquier condición — de señal única o de múltiples señales.
Casos de uso de ejemplo para esto:
- Puede usar la configuración Superior para una fuente de datos como tasa de errores, porque generalmente solo le preocupa si sube y no si baja.
- Puede utilizar la configuración Inferior para una fuente de datos como el rendimiento, porque las fluctuaciones repentinas ascendentes son bastante comunes, pero una gran caída repentina indicaría un problema.
A continuación se muestran ejemplos de cómo se tratarían las grandes fluctuaciones en sus datos según las diferentes configuraciones de dirección de anomalías. Las áreas rojas representan eventos de alerta.

Comprenda cuándo se activan las alertas
Las alertas de detección de anomalías no se activan en el momento en que sus datos tocan la banda gris del umbral. El momento depende de su configuración de duración y de cuánto tiempo persista la infracción.
Esto es lo que experimentan muchos clientes:
Expectativa de los clientes: "mi CPU se disparó al 90 % y salió del área gris, entonces, ¿por qué no recibí una alerta?"
Realidad: si su pico dura solo 2 minutos pero su duración está configurada en 5 minutos, no se creará ninguna alerta — a pesar de que los datos claramente salieron de las bandas grises.
Sugerencia
Concepto erróneo común: la duración controla cuánto tiempo debe persistir un problema antes de alertar, no qué tan rápido se le notificará. Establecer la duración en 5 minutos no significa "notificarme en 5 minutos" — significa "solo notificarme si la anomalía dura 5 minutos". Una duración menor significa que las alertas se activan antes, pero es posible que vea más falsas alarmas.
Condiciones de múltiples señales
Dependiendo de cómo haya definido su consulta NRQL al crear la condición de alerta, es posible que esté monitoreando muchas señales, no solo una. Al trabajar con NRQL, estas consultas usan la cláusulaFACET . Tenga en cuenta lo siguiente:
- Límite de señales: una sola condición de alerta de anomalía puede monitorear hasta 20 000 señales individuales.
- Evaluación independiente: cada señal se rastrea y evalúa frente a su propia línea de base histórica. Una anomalía en una señal desencadena un incidente sin que el comportamiento normal de otra señal lo sesgue o lo oculte.
- Configuración uniforme: la configuración de umbral que especifique se aplica por igual a todas las señales que monitorea esta condición, aunque las líneas de base se calculen por señal.
- Vista previa del gráfico: mostramos un máximo de 500 señales en el gráfico de vista previa. No mostramos la señal predicha ni las bandas de umbral cuando hay más de una señal en el gráfico — seleccione una sola serie temporal de la leyenda para aislar su línea de base y los límites de umbral.
Ajuste los umbrales usando datos de señales
Una vez que una condición ha estado evaluando datos durante unos días o más, no adivine un umbral. Cada evaluación de condición de anomalía publica un evento NrAiSignal que contiene el valor real, el valor predicho y la desviación estándar del error de predicción (numberOfDeviations). Consulte estos eventos para ver exactamente cómo funciona su umbral y para graficar su señal y predicciones en ventanas de tiempo más largas de lo que permite el gráfico de vista previa del editor de condiciones.
Sugerencia
Cada consulta en esta página necesita el ID de su condición. Encuéntrelo en la URL de la condición de alerta en la UI de New Relic (el número después de /conditions/), o ejecute FROM NrAiSignal SELECT uniques(conditionId) SINCE 1 week ago para enumerar los ID de condición que reportan datos en su cuenta.
Importante
Estas consultas filtran solo por conditionId. Para una condición de múltiples señales, que combina las desviaciones de cada señal en lugar de aislar una, por lo que los resultados no le dirán mucho sobre ninguna señal individual. Para analizar una señal dentro de una condición facetada, también deberá filtrar o facetar estas consultas por el atributo de identificación de esa señal.
Encuentre su rango típico de desviaciones
Un histograma de numberOfDeviations durante una semana o más muestra el rango típico de desviaciones para su señal, lo que le ayuda a elegir un umbral inicial:
FROM NrAiSignal SELECT histogram(numberOfDeviations, start: -10, width: 20, buckets: 40) WHERE conditionId = YOUR_CONDITION_ID SINCE 1 week ago
Comparar desviaciones con un umbral candidato a lo largo del tiempo
Grafique las mismas desviaciones como una serie temporal junto a una línea de umbral candidata, para ver con qué frecuencia, y por cuánto, la señal la habría infringido:
FROM NrAiSignal SELECT max(abs(numberOfDeviations)), 5 AS criticalValue WHERE conditionId = YOUR_CONDITION_ID SINCE 1 week ago TIMESERIES 28 minutesReemplace 5 con su umbral candidato. Establezca la ventana TIMESERIES en un múltiplo de la ventana de agregación de la condición y evite TIMESERIES MAX para esta comparación.

Calcular la desviación promedio y del percentil
Para obtener una vista más holística, calcule el promedio y la desviación estándar del percentil durante un período más largo. Por ejemplo, esta señal de latencia tiene un pico de aproximadamente 120 ms:

En ese mismo momento, la desviación estándar es de aproximadamente 30.43:

Ejecute esta consulta para comparar la desviación estándar promedio y del percentil con su umbral actual:
SELECT average(deviations) AS 'avg', percentile(deviations, 75) AS 'p75', percentile(deviations, 95) AS 'p95' FROM (FROM NrAiSignal SELECT max(abs(numberOfDeviations)) AS 'deviations' WHERE conditionId = YOUR_CONDITION_ID TIMESERIES 1 hour LIMIT MAX) SINCE 1 week ago COMPARE WITH 2 weeks ago FACET string(7) AS 'Current Threshold'
En este ejemplo, un umbral entre 10 y 17 sería más adecuado que el umbral actual de 7.
Verifique el comportamiento del modelo
Grafique la señal real, el valor predicho y el umbral calculado juntos para ver si el modelo está bien entrenado y el umbral está bien calibrado:
FROM NrAiSignal SELECT latest(signalValue), latest(predictedValue), latest(predictedValue + (standardDeviation * {condition_threshold})) AS 'Upper Threshold' WHERE conditionId = {condition_id} SINCE 1 week ago TIMESERIES 30 minutes- signalValue: el valor real de la señal de la condición.
- predictedValue: la línea de base calculada del modelo, que cambia con el tiempo a medida que aprende las tendencias semanales e históricas.
- Umbral superior/inferior: el límite alto o bajo calculado a partir del umbral de desviación estándar de la condición.

Esta tendencia muestra una condición bien ajustada:
- La señal no está consistentemente por encima del umbral superior, por lo que es probable que el umbral de desviación estándar esté configurado correctamente.
- El valor predicho sigue la señal real bastante de cerca, por lo que el modelo está bien entrenado.
Utilice esto para diagnosticar problemas:
- Si la señal está consistentemente por encima del umbral superior, o por debajo del umbral inferior, el umbral de desviación estándar necesita un ajuste.
- Si la tendencia del valor predicho varía mucho de la señal real, el modelo necesita más tiempo para aprender. Proporcione más datos antes de seguir ajustando.
Sugerencia
Para un umbral inferior, reemplace el término del umbral superior con predictedValue - (standardDeviation * {condition_threshold}). Para un umbral bilateral, incluya ambos términos en la misma consulta para trazar las líneas de umbral superior e inferior juntas.