Manera simple de identificar algorítmicamente un pico en los errores registrados

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 solo si alguien es consciente del problema ...

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

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

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 sea bastante sensible, aunque sabemos que podemos esperar algunos falsos positivos.

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

Han pasado 5 meses desde que hizo esta pregunta, y espero que haya resuelto algo. Voy a hacer algunas sugerencias diferentes aquí, con la esperanza de que les sirva de algo en otros escenarios.

Para su caso de uso, no creo que necesite mirar algoritmos de detección de picos.

Así que aquí va: comencemos con una imagen de los errores que ocurren en una línea de tiempo:

Lo que desea es un indicador numérico, una "medida" de la rapidez con que se producen los errores. Y esta medida debería ser susceptible de umbral: sus administradores de sistemas deberían poder establecer límites que controlen con qué errores de sensibilidad se convierten en advertencias.

Medida 1

Usted mencionó "picos", la forma más fácil de obtener 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, la mayoría de los errores tolerables en un intervalo de 20 minutos.

(En este punto usted puede preguntarse si esa longitud de ventana de 20 minutos no se puede ajustar. 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 con este método para su escenario particular? Bueno, su variable es un número entero, probablemente menor que 3. No establecería su umbral en 1, ya que eso solo significa "cada error es una advertencia" que no requiere un algoritmo. Por lo tanto, sus opciones para el umbral serán 2 y 3. Esto no le da a sus administradores de sistemas un control exhaustivo.

Medida 2

En lugar de contar los errores en una ventana de tiempo, realice un seguimiento de la cantidad de minutos entre el error actual y el último. Cuando este valor se vuelve demasiado pequeño, significa que sus errores se vuelven demasiado frecuentes y que debe generar una advertencia.

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

Esta medida proporciona más flexibilidad. A diferencia de la Medida 1, para la cual había un pequeño conjunto de valores con los que podía trabajar, ahora tiene una medida que proporciona unos buenos 20-30 valores. Por lo tanto, sus administradores de sistemas tendrán más posibilidades de ajuste.

Consejo amistoso

Hay otra forma de abordar este problema. En lugar de mirar las frecuencias de error, es posible predecir los errores antes de que ocurran.

Usted mencionó que este comportamiento estaba ocurriendo en un solo servidor, que se sabe que tiene problemas de rendimiento. Puede monitorear ciertos indicadores clave de rendimiento en esa máquina y hacer que le digan cuándo ocurrirá un error. Específicamente, vería el uso de la CPU, el uso de la memoria y los KPI relacionados con la E / S de disco. Si el uso de su CPU supera el 80%, el sistema se ralentizará.

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

Y para las personas que vinieron aquí con la esperanza de encontrar algo sobre la detección de picos en una serie temporal:

Detección de picos en una serie temporal

$x_1, x_2,...$

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

$\alpha$$x_k$

Si su nuevo valor se ha alejado demasiado del promedio móvil, por ejemplo

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

entonces haces una advertencia.

Los promedios móviles son buenos cuando se trabaja con datos en tiempo real. Pero supongamos que ya tiene una gran cantidad de datos en una tabla y solo desea ejecutar consultas SQL para encontrar los picos.

Yo sugeriría:

1. Calcule el valor medio de su serie temporal
2. $\sigma$
3. $2\sigma$

Más cosas divertidas sobre series de tiempo

1. Muchas series temporales del mundo real exhiben un comportamiento cíclico. Existe un modelo llamado ARIMA que lo ayuda a extraer estos ciclos de su serie temporal.

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

+1 para el control estadístico del proceso, aquí hay información útil sobre la detección de pasos .

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

Simplemente haga un USP en el servidor SQL que iterará a través de un conjunto de datos y haga ping a cada punto contra las reglas usando sus puntos vecinos. Quizás sume la cantidad 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

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

Más información ubicada en stackoverflow: Peak Dection de la señal medida

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

Es posible que desee ver el control estadístico del proceso. O monitoreo de series de tiempo. Hay toneladas de trabajo en esta dirección, y la respuesta óptima probablemente depende mucho de lo que esté haciendo exactamente (¿necesita filtrar las estacionalidades anuales o semanales en la carga antes de detectar anomalías, etc.).