Prosty sposób na algorytmiczną identyfikację wzrostu zarejestrowanych błędów

Potrzebujemy systemu wczesnego ostrzegania. Mam do czynienia z serwerem, o którym wiadomo, że ma problemy z wydajnością pod obciążeniem. Błędy są rejestrowane w bazie danych wraz ze znacznikiem czasu. Istnieje kilka kroków ręcznej interwencji, które można podjąć w celu zmniejszenia obciążenia serwera, ale tylko wtedy, gdy ktoś jest świadomy problemu ...

Biorąc pod uwagę, ile razy wystąpiły błędy, jak mogę zidentyfikować początek gwałtownego wzrostu błędów (w czasie rzeczywistym)? Możemy obliczyć okresowo lub przy każdym wystąpieniu błędu.

Nie przejmujemy się sporadycznymi błędami, ale nie mamy określonego progu. Mógłbym po prostu powiadomić kogoś za każdym razem, gdy otrzymamy powiedzmy trzy błędy w ciągu pięciu minut, ale jestem pewien, że jest lepszy sposób ...

Chciałbym móc dostosować czułość algorytmu na podstawie informacji zwrotnych od sysadmins. Na razie chcieliby, aby była dość wrażliwa, chociaż wiemy, że możemy spodziewać się fałszywych trafień.

Nie jestem statystykiem, co z pewnością jest oczywiste, a implementacja tego musi być stosunkowo prosta dzięki naszym istniejącym narzędziom: SQL Server i oldschoolowej ASP JScript. Nie szukam odpowiedzi w kodzie, ale jeśli wymaga dodatkowego oprogramowania, prawdopodobnie nie będzie dla nas działać (choć z zadowoleniem przyjmuję niepraktyczne, ale idealne rozwiązania jako komentarz, z własnej ciekawości).

Minęło 5 miesięcy, odkąd zadałeś to pytanie i mam nadzieję, że coś wymyśliłeś. Przedstawię tutaj kilka różnych sugestii, mając nadzieję, że znajdziesz je w innych scenariuszach.

W twoim przypadku użycia nie sądzę, że musisz patrzeć na algorytmy wykrywania szczytów.

A więc oto: Zacznijmy od zdjęcia błędów występujących na osi czasu:

To, czego chcesz, to wskaźnik numeryczny, „miara” szybkości nadchodzących błędów. I ta miara powinna być podatna na progowanie - Twoi administratorzy powinni być w stanie ustalić granice, które kontrolują, z jakimi błędami czułości zamieniają się w ostrzeżenia.

Środek 1

Wspomniałeś o „skokach”, najłatwiejszym sposobem na uzyskanie skoków jest narysowanie histogramu co 20 minut:

Twoi administratorzy ustawiliby czułość w oparciu o wysokości słupków, tj. Najwięcej błędów tolerowanych w odstępie 20 minut.

(W tym momencie możesz zastanawiać się, czy nie można dostosować tej 20-minutowej długości okna. Można, i możesz myśleć o długości okna jako o definicji słowa razem w błędach pojawiających się razem .)

Jaki jest problem z tą metodą w twoim konkretnym scenariuszu? Cóż, twoja zmienna jest liczbą całkowitą, prawdopodobnie mniejszą niż 3. Nie ustawisz swojego progu na 1, ponieważ oznacza to po prostu, że „każdy błąd jest ostrzeżeniem”, który nie wymaga algorytmu. Wybory dla progu będą wynosić 2 i 3. Nie daje to administratorom całego systemu drobiazgowej kontroli.

Środek 2

Zamiast zliczać błędy w oknie czasowym, śledź liczbę minut między bieżącym a ostatnim błędem. Gdy ta wartość staje się zbyt mała, oznacza to, że twoje błędy stają się zbyt częste i musisz zgłosić ostrzeżenie.

Twoi administratorzy prawdopodobnie ustawią limit na 10 (tj. Jeśli błędy występują mniej niż 10 minut od siebie, to problem) lub 20 minut. Może 30 minut na mniej krytyczny system.

Ten środek zapewnia większą elastyczność. W przeciwieństwie do miary 1, dla której istniał mały zestaw wartości, z którymi można pracować, teraz masz miarę, która zapewnia dobre 20-30 wartości. W związku z tym sysadmins będą mieli więcej możliwości dostrajania.

Przyjazna rada

Istnieje inny sposób rozwiązania tego problemu. Zamiast patrzeć na częstotliwości błędów, możliwe jest przewidywanie błędów przed ich wystąpieniem.

Wspomniałeś, że takie zachowanie występowało na jednym serwerze, o którym wiadomo, że ma problemy z wydajnością. Możesz monitorować niektóre kluczowe wskaźniki wydajności na tym komputerze i informować ich, kiedy wystąpi błąd. W szczególności przyjrzymy się wykorzystaniu procesora, pamięci i kluczowych wskaźników wydajności związanych z dyskowymi operacjami we / wy. Jeśli użycie procesora przekroczy 80%, system zwolni.

(Wiem, że powiedziałeś, że nie chcesz instalować żadnego oprogramowania, i to prawda, że ​​możesz to zrobić za pomocą PerfMon. Ale są dostępne darmowe narzędzia, które zrobią to za Ciebie, takie jak Nagios i Zenoss .)

A dla ludzi, którzy tu przybyli, mając nadzieję znaleźć coś na temat wykrywania kolców w szeregu czasowym:

Wykrywanie skoków w szeregu czasowym

$x_1, x_2,...$

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

$\alpha$$x_k$

Jeśli na przykład twoja nowa wartość odeszła zbyt daleko od średniej ruchomej

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

wtedy podnosisz ostrzeżenie.

Średnie kroczące przydają się podczas pracy z danymi w czasie rzeczywistym. Ale przypuśćmy, że masz już sporo danych w tabeli i chcesz po prostu uruchomić zapytania SQL, aby znaleźć wartości szczytowe.

Sugerowałbym:

1. Oblicz średnią wartość szeregu czasowego
2. $\sigma$
3. $2\sigma$

Więcej zabawy o szeregach czasowych

1. Wiele szeregów czasowych w świecie rzeczywistym wykazuje cykliczne zachowanie. Istnieje model o nazwie ARIMA, który pomaga wyodrębnić te cykle z szeregów czasowych.

2. Średnie kroczące uwzględniające zachowanie cykliczne: Holt i Winters

+1 do statystycznej kontroli procesu, tutaj jest kilka użytecznych informacji na temat Wykrywania kroków .

W przypadku SPC napisanie implementacji zasad Western Electric lub zasad Nelsona nie jest zbyt trudne .

Wystarczy wykonać USP na serwerze SQL, który będzie iterował przez zestaw danych i pingował każdy punkt przeciwko regułom, używając swoich sąsiadujących punktów. Może zsumuj liczbę błędów według godziny (w zależności od potrzeb).

Ten rodzaj odnosi się do pytania, które zamieściłem na Przepełnienie stosu jakiś czas temu (właśnie napisałem szybką odpowiedź, jeśli to pomaga): Wykresy kontroli procesu statystycznego w SQL Server 2008 R2

Rozpoczęcie poszukiwania algorytmów detekcji online .

Więcej informacji znajduje się w przepełnieniu stosu : Wykrywanie piku mierzonego sygnału

Implementacja Pythona naiwnej procedury wykrywania pików znajduje się na github

Możesz przyjrzeć się statystycznej kontroli procesu. Lub monitorowanie szeregów czasowych. W tym kierunku jest mnóstwo pracy, a optymalna odpowiedź prawdopodobnie zależy w dużej mierze od tego, co dokładnie robisz (czy musisz odfiltrowywać sezonowe lub roczne ładunki przed wykryciem anomalii itp.).