Modo semplice per identificare algoritmicamente un picco di errori registrati

Abbiamo bisogno di un sistema di allarme rapido. Ho a che fare con un server che ha problemi di prestazioni sotto carico. Gli errori vengono registrati in un database insieme a un timestamp. Esistono alcuni passaggi di intervento manuale che possono essere adottati per ridurre il carico del server, ma solo se qualcuno è a conoscenza del problema ...

Dato un numero di volte in cui si sono verificati errori, come posso identificare l'inizio di un picco di errori (in tempo reale)? Possiamo calcolare periodicamente o al verificarsi di ogni errore.

Non ci preoccupiamo degli errori occasionali, ma non abbiamo una soglia specifica. Potrei semplicemente avvisare qualcuno ogni volta che otteniamo, diciamo, tre errori in cinque minuti, ma sono sicuro che c'è un modo migliore ...

Mi piacerebbe poter regolare la sensibilità dell'algoritmo in base al feedback degli amministratori di sistema. Per ora, vorrebbero che fosse abbastanza sensibile, anche se sappiamo che possiamo aspettarci dei falsi positivi.

Non sono uno statistico, il che è certo ovvio, e l'implementazione deve essere relativamente semplice con i nostri strumenti esistenti: SQL Server e ASP JScript di vecchia scuola. Non sto cercando una risposta nel codice, ma se richiede software aggiuntivo, probabilmente non funzionerà per noi (anche se accolgo con favore le soluzioni impraticabili ma ideali come commento, per la mia curiosità).

Sono passati 5 mesi da quando hai fatto questa domanda, e spero che tu abbia capito qualcosa. Ho intenzione di dare alcuni suggerimenti diversi qui, sperando che tu possa trovare un qualche uso per loro in altri scenari.

Per il tuo caso d'uso, non penso che tu abbia bisogno di esaminare gli algoritmi di rilevamento dei picchi.

Quindi ecco: iniziamo con un'immagine degli errori che si verificano su una sequenza temporale:

Quello che vuoi è un indicatore numerico, una "misura" di quanto velocemente arrivano gli errori. E questa misura dovrebbe essere suscettibile di soglia: i tuoi amministratori di sistema dovrebbero essere in grado di impostare limiti che controllano con quali errori di sensibilità si trasformano in avvisi.

Misura 1

Hai citato "punte", il modo più semplice per ottenere una punta è disegnare un istogramma su ogni intervallo di 20 minuti:

I vostri amministratori di sistema imposteranno la sensibilità in base alle altezze delle barre, ovvero agli errori più tollerabili in un intervallo di 20 minuti.

(A questo punto ti starai chiedendo se la lunghezza della finestra di 20 minuti non può essere regolata. Può, e puoi pensare alla lunghezza della finestra come a definire la parola insieme negli errori di frase che appaiono insieme .)

Qual è il problema con questo metodo per il tuo particolare scenario? Bene, la tua variabile è un numero intero, probabilmente inferiore a 3. Non imposteresti la soglia su 1, poiché ciò significa semplicemente "ogni errore è un avvertimento" che non richiede un algoritmo. Quindi le tue scelte per la soglia saranno 2 e 3. Questo non darà ai tuoi amministratori di sistema un controllo molto accurato.

Misura 2

Invece di contare gli errori in una finestra temporale, tenere traccia del numero di minuti tra l'errore corrente e l'ultimo. Quando questo valore diventa troppo piccolo, significa che i tuoi errori stanno diventando troppo frequenti e devi emettere un avviso.

I tuoi amministratori di sistema probabilmente imposteranno il limite su 10 (cioè se si verificano errori a meno di 10 minuti di distanza, è un problema) o 20 minuti. Forse 30 minuti per un sistema meno critico.

Questa misura offre maggiore flessibilità. A differenza della Misura 1, per la quale c'era un piccolo insieme di valori con cui potevi lavorare, ora hai una misura che fornisce un buon 20-30 valori. I vostri amministratori di sistema avranno quindi maggiori possibilità di perfezionamento.

Consiglio amichevole

C'è un altro modo di affrontare questo problema. Invece di guardare le frequenze degli errori, potrebbe essere possibile prevedere gli errori prima che si verifichino.

Hai detto che questo comportamento si stava verificando su un singolo server, che è noto per avere problemi di prestazioni. È possibile monitorare alcuni indicatori chiave di prestazione su quella macchina e farti sapere quando si verificherà un errore. In particolare, dovresti esaminare l'utilizzo della CPU, l'utilizzo della memoria e gli indicatori KPI relativi all'I / O del disco. Se l'utilizzo della CPU supera l'80%, il sistema rallenterà.

(So ​​che hai detto che non volevi installare alcun software, ed è vero che potresti farlo usando PerfMon. Ma ci sono strumenti gratuiti là fuori che lo faranno per te, come Nagios e Zenoss .)

E per le persone che sono venute qui sperando di trovare qualcosa sul rilevamento di picchi in una serie temporale:

Rilevamento di picchi in una serie temporale

La cosa più semplice che dovresti iniziare facendo è calcolare una media mobile dei tuoi valori di input. Se la tua serie è , dopo ogni osservazione calcoleresti una media mobile come:$x_1, x_2,...$

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

dove determinerebbe quanto peso darebbe l'ultimo valore di .x $\alpha$$x_k$

Ad esempio, se il tuo nuovo valore si è spostato troppo lontano dalla media mobile

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

poi fai un avvertimento.

Le medie mobili sono utili quando si lavora con dati in tempo reale. Supponiamo che tu abbia già un sacco di dati in una tabella e desideri semplicemente eseguire query SQL su di esso per trovare i picchi.

Suggerirei:

1. Calcola il valore medio delle tue serie storiche
2. Calcola la deviazione standard $\sigma$
3. Isolare quei valori che sono più di sopra la media (potrebbe essere necessario regolare quel fattore di "2")$2\sigma$

Altre cose divertenti sulle serie storiche

1. Molte serie storiche del mondo reale mostrano un comportamento ciclico. Esiste un modello chiamato ARIMA che ti aiuta a estrarre questi cicli dalle tue serie storiche.

2. Medie mobili che tengono conto del comportamento ciclico: Holt e Winters

+1 per il controllo statistico del processo, ci sono alcune informazioni utili qui su Step Detection .

Per SPC non è troppo difficile scrivere un'implementazione delle Western Electric Rules o delle Nelson Nelson .

Basta creare un USP in un server SQL che eseguirà l'iterazione attraverso un set di dati e eseguirà il ping di ciascun punto rispetto alle regole utilizzando i punti vicini. Magari riassumi il numero di errori all'ora (a seconda delle tue esigenze).

Questo tipo di relazione riguarda una domanda che ho pubblicato su Stack Overflow qualche tempo fa (ho appena scritto una risposta rapida se aiuta): Grafici di controllo del processo statistico in SQL Server 2008 R2

Una ricerca di algoritmi di rilevamento online sarebbe un inizio.

Ulteriori informazioni su StackOverflow: Dection di picco del segnale misurato

Un'implementazione di Python di un'ingenua routine di rilevamento dei picchi si trova su github

Potresti voler esaminare il controllo statistico del processo. O monitoraggio delle serie temporali. Ci sono tonnellate di lavoro in questa direzione e la risposta ottimale probabilmente dipende molto da cosa stai facendo esattamente (devi filtrare le stagionalità annuali o settimanali in carico prima di rilevare anomalie ecc.).