Una forma sencilla de identificar algorítmicamente un pico de errores registrados

Question

Necesitamos un sistema de alerta temprana. Estoy tratando con un servidor que se sabe que tiene problemas de rendimiento bajo carga. Los errores se registran en una base de datos junto con una marca de tiempo. Hay algunos pasos de intervención manual que se pueden tomar para disminuir la carga del servidor, pero sólo si alguien es consciente del problema...

Dado un conjunto de veces que se produjeron errores, ¿cómo puedo identificar el comienzo de un pico de errores (en tiempo real)? Podemos calcularlo periódicamente o en cada ocurrencia de errores.

No nos preocupan los errores ocasionales, pero no tenemos un umbral específico. Podría notificar a alguien cada vez que tengamos, por ejemplo, tres errores en cinco minutos, pero estoy seguro de que hay una forma mejor...

Me gustaría poder ajustar la sensibilidad del algoritmo en función de los comentarios de los administradores de sistemas. Por ahora, les gustaría que fuera bastante sensible, aunque sabemos que podemos esperar algunos falsos positivos.

No soy un estadístico, lo cual seguro que es obvio, y la implementación de esto tiene que ser relativamente sencilla con nuestras herramientas existentes: SQL Server y ASP JScript de la vieja escuela. No estoy buscando una respuesta en código, pero si requiere software adicional, probablemente no funcionará para nosotros (aunque doy la bienvenida a soluciones poco prácticas pero ideales como comentario, por mi propia curiosidad).

Answer 1

Han pasado 5 meses desde que hiciste esta pregunta, y espero que hayas averiguado algo. Voy a hacer algunas sugerencias diferentes aquí, con la esperanza de que encuentres algún uso para ellos en otros escenarios.

Para tu caso de uso no creo que necesites buscar algoritmos de detección de picos.

Así que aquí va: Empecemos con una imagen de los errores que se producen en una línea de tiempo:

Lo que quiere es un indicador numérico, una "medida" de la rapidez con la que se producen los errores. Y esta medida debe ser susceptible de umbrales - sus administradores de sistemas deben ser capaces de establecer límites que controlen con qué sensibilidad los errores se convierten en advertencias.

Medida 1

Has mencionado los "picos", la forma más fácil de conseguir un pico es dibujar un histograma en cada intervalo de 20 minutos:

Sus administradores de sistemas establecerían la sensibilidad en función de las alturas de las barras, es decir, el mayor número de errores tolerables en un intervalo de 20 minutos.

(Llegados a este punto, te estarás preguntando si la duración de esa ventana de 20 minutos no puede ajustarse. Sí se puede, y se puede pensar en la longitud de la ventana como la definición de la palabra juntos en la frase errores que aparecen juntos .)

¿Cuál es el problema de este método para su escenario particular? Bueno, tu variable es un número entero, probablemente inferior a 3. No establecerías tu umbral en 1, ya que eso sólo significa que "cada error es una advertencia", lo que no requiere un algoritmo. Así que tus opciones para el umbral van a ser 2 y 3. Esto no le da a sus administradores de sistemas un control muy fino.

Medida 2

En lugar de contar los errores en una ventana de tiempo, lleve la cuenta del número de minutos entre el error actual y el último. Cuando este valor se hace demasiado pequeño, significa que tus errores se están haciendo demasiado frecuentes y necesitas lanzar una advertencia.

Sus administradores de sistemas probablemente establecerán el límite en 10 (es decir, si los errores se producen con menos de 10 minutos de diferencia, es un problema) o 20 minutos. Tal vez 30 minutos para un sistema menos crítico.

Esta medida proporciona más flexibilidad. A diferencia de la medida 1, para la que había un pequeño conjunto de valores con los que se podía trabajar, ahora tiene una medida que proporciona unos buenos 20-30 valores. Por tanto, los administradores del sistema tendrán más margen de maniobra para realizar ajustes.

Consejos amistosos

Hay otra forma de enfocar este problema. En lugar de observar las frecuencias de los errores, puede ser posible predecirlos antes de que se produzcan.

Usted mencionó que este comportamiento estaba ocurriendo en un solo servidor, que se sabe que tiene problemas de rendimiento. Usted podría monitorear ciertos Indicadores clave de rendimiento en esa máquina, y que te digan cuándo se va a producir un error. Específicamente, usted miraría el uso de la CPU, el uso de la memoria y los KPIs relacionados con la E/S del disco. Si el uso de la CPU supera el 80%, el sistema se va a ralentizar.

(Sé que dijiste que no querías instalar ningún software, y es cierto que podrías hacerlo usando PerfMon. Pero hay herramientas gratuitas que lo hacen por ti, como Nagios y Zenoss .)

Y para la gente que vino aquí esperando encontrar algo sobre la detección de picos en una serie temporal:

Detección de picos en una serie temporal

Lo más sencillo es empezar por calcular un media móvil de sus valores de entrada. Si su serie es $x_1, x_2,...$ entonces se calcularía una media móvil después de cada observación como:

$M_k = (1 - \alpha) M_{k-1} + \alpha x_k$

donde el $\alpha$ determinaría el peso que se le da al último valor de $x_k$ .

Si su nuevo valor se ha alejado demasiado de la media móvil, por ejemplo

$\frac{x_k - M_k}{M_k} > 20\%$

entonces se levanta una advertencia.

Los promedios móviles son buenos cuando se trabaja con datos en tiempo real. Pero supongamos que ya tenemos un montón de datos en una tabla, y sólo queremos ejecutar consultas SQL contra ellos para encontrar los picos.

Yo sugeriría:

1. Calcule el valor medio de sus series temporales
2. Calcule el desviación estándar $\sigma$
3. Aislar los valores que son más de $2\sigma$ por encima de la media (es posible que tenga que ajustar ese factor de "2")

Más cosas divertidas sobre las series temporales

1. Muchas series temporales del mundo real presentan un comportamiento cíclico. Existe un modelo llamado ARIMA que le ayuda a extraer estos ciclos de sus series temporales.

2. Medias móviles que tienen en cuenta el comportamiento cíclico: Holt y Winters

Answer 2

+1 para el control estadístico de procesos, hay información útil aquí sobre Detección de pasos .

Para el SPC no es demasiado difícil escribir una implementación del Normas de Western Electric o el Reglas de Nelson .

Solo hay que hacer un USP en SQL server que itere a través de un conjunto de datos y haga ping a cada punto contra las reglas usando sus puntos vecinos. Tal vez sumar el número de errores por hora (dependiendo de sus necesidades).

---

Esto se relaciona con una pregunta que publiqué en Stack Overflow hace un tiempo (acabo de escribir una respuesta rápida si ayuda): Gráficos de control de procesos estadísticos en SQL Server 2008 R2

Answer 3

Una búsqueda de Algoritmos de detección en línea sería un comienzo.

Más información en stackoverflow: Dección de pico de la señal medida

Una implementación en python de una rutina ingenua de detección de picos se encuentra en github

Answer 4

Tal vez le interese el control estadístico de procesos. O el control de series temporales. Hay montones de trabajos en este sentido, y la respuesta óptima probablemente dependa mucho de lo que esté haciendo exactamente (¿necesita filtrar las estacionalidades anuales o semanales de la carga antes de detectar anomalías, etc.).