Простий спосіб алгоритмічно визначити сплеск записаних помилок

Нам потрібна система раннього попередження. Я маю справу з сервером, який, як відомо, навантажує проблеми з продуктивністю. Помилки реєструються в базі даних разом із часовою позначкою. Є кілька кроків вручну, які можна вжити для зменшення навантаження сервера, але лише якщо хтось знає про проблему ...

З огляду на набір разів, коли траплялися помилки, як я можу визначити початок спайка помилок (в режимі реального часу)? Ми можемо обчислювати періодично або за кожним випадком помилки.

Ми не стурбовані випадковими помилками, але не маємо конкретного порогу. Я міг би просто повідомити когось, коли ми отримаємо, скажімо, три помилки за п’ять хвилин, але я впевнений, що є кращий спосіб ...

Я хотів би мати можливість налаштувати чутливість алгоритму на основі зворотного зв’язку системних адміністраторів. Наразі вони хотіли б, щоб він був досить чутливим, хоча ми знаємо, що можна очікувати помилкових позитивних результатів.

Я не статистик, що я впевнений, що це очевидно, і реалізувати це потрібно порівняно просто з нашими існуючими інструментами: SQL Server та старою школою ASP JScript. Я не шукаю відповіді в коді, але якщо він потребує додаткового програмного забезпечення, він, ймовірно, не буде працювати для нас (хоча я вітаю непрактичні, але ідеальні рішення як коментар, для власної цікавості).

Минуло 5 місяців, як ви задали це питання, і, сподіваємось, ви щось зрозуміли. Я збираюся зробити декілька різних пропозицій тут, сподіваючись, що ви знайдете для них певне використання в інших сценаріях.

Для вашого використання я не думаю, що вам потрібно дивитися на алгоритми виявлення шипів.

Отже, далі: Почнемо з картини помилок, що трапляються на часовій шкалі:

Те, що ви хочете, - це числовий показник, «міра» того, як швидко з’являються помилки. І ця міра повинна піддаватися встановленню порогових значень - ваші системні адміністратори повинні мати можливість встановлювати межі, які контролюють, які помилки чутливості перетворюються на попередження.

Захід 1

Ви згадали про "шипи", найпростіший спосіб отримати шип - намалювати гістограму через кожні 20-хвилинний інтервал:

Ваші sysadmins встановили б чутливість на основі висоти барів, тобто найбільш помилок, допустимих за 20-хвилинний інтервал.

(На даний момент вам може бути цікаво, чи не можна скоригувати цю 20-хвилинну довжину вікна. Це може бути, і ви можете вважати довжину вікна як визначення слова разом у помилках фрази, що з’являються разом .)

У чому проблема цього методу для вашого конкретного сценарію? Ну, ваша змінна ціле число, ймовірно, менше 3. Ви б не встановили поріг у 1, оскільки це означає лише "кожна помилка - попередження", що не вимагає алгоритму. Тож ваш вибір порогового значення буде 2 та 3. Це не дає вашим системним адміністраторам великої кількості дрібнозернистого контролю.

Захід 2

Замість того, щоб рахувати помилки у часовому вікні, слідкуйте за кількістю хвилин між поточною та останньою помилками. Коли це значення стає занадто малим, це означає, що ваші помилки стають занадто частими, і вам потрібно підвищити попередження.

Ваші sysadmins, ймовірно, встановлять ліміт у 10 (тобто якщо помилки трапляються менше 10 хвилин, це проблема) або 20 хвилин. Можливо, 30 хвилин для менш критичної місії системи.

Цей захід забезпечує більшу гнучкість. На відміну від міри 1, для якої був невеликий набір значень, з якими ви могли працювати, тепер у вас є міра, яка забезпечує хороші 20-30 значень. Таким чином, ваші сисадміни матимуть більше можливостей для тонкої настройки.

Дружні поради

Є ще один спосіб підійти до цієї проблеми. Замість того, щоб дивитись на частоти помилок, можливо передбачити помилки ще до їх виникнення.

Ви згадали, що така поведінка відбувалася на одному сервері, який, як відомо, має проблеми з продуктивністю. Ви можете відстежувати певні ключові показники продуктивності на цій машині і їх повідомляти, коли відбудеться помилка. Зокрема, ви подивитесь на використання процесора, використання пам'яті та KPI, що стосуються вводу-виводу диска. Якщо використання процесора перевищує 80%, система сповільниться.

(Я знаю, ви сказали, що не хочете встановлювати жодне програмне забезпечення, і це правда, що ви могли це зробити за допомогою PerfMon. Але там є безкоштовні інструменти, які зроблять це для вас, як Nagios і Zenoss .)

А для людей, які приїхали сюди, сподіваючись знайти щось про виявлення шипів у часовій серії:

Виявлення шипа в часовій серії

Найпростіше, з чого слід почати, - це обчислити ковзну середню вхідних значень. Якщо ваша серія , ви обчислите ковзну середню після кожного спостереження як:$x_1, x_2,...$

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

де визначає, яка вага дає останнє значення .$\alpha$$x_k$

Наприклад, якщо ваше нове значення зайшло занадто далеко від ковзного середнього

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

то ви піднімаєте попередження.

Рухомі середні показники приємні під час роботи з даними в режимі реального часу. Але припустимо, у вас вже є маса даних у таблиці, і ви просто хочете запустити проти неї SQL-запити, щоб знайти шипи.

Я б запропонував:

1. Обчисліть середнє значення часового ряду
2. Обчисліть стандартне відхилення $\sigma$
3. Виділіть ті значення, які на перевищують середнє (можливо, вам знадобиться відрегулювати цей коефіцієнт "2")$2\sigma$

Більше цікавих матеріалів про часові ряди

1. Багато реальних часових рядів демонструють циклічну поведінку. Існує модель під назвою ARIMA, яка допомагає витягти ці цикли зі свого часового ряду.

2. Рухомі середні показники, що враховують циклічну поведінку: Холт і Зінтерс

+1 для статистичного контролю процесів, тут є корисна інформація про визначення кроків .

Для SPC не надто важко написати виконання Західних електричних правил або Нельсонових правил .

Просто зробіть USP на SQL-сервері, який буде повторювати набір даних і відслідковувати кожну точку проти правил, використовуючи сусідні точки. Можливо підсумуйте кількість помилок за годиною (залежно від ваших потреб).

Цей тип стосується питання, яке я опублікував на стеку Overflow на деякий час назад (щойно я написав швидку відповідь, якщо це допомагає): Статистичні графіки управління процесами в SQL Server 2008 R2

Пошук алгоритмів виявлення в Інтернеті стане початком.

Більше інформації, розміщеної на stackoverflow : Пікове значення вимірюваного сигналу

У Github можна знайти пітонну реалізацію наївного піку

Ви можете подивитися статистичний контроль над процесами. Або моніторинг часових рядів. У цьому напрямку працюють багато тонн, і оптимальна відповідь, ймовірно, багато в чому залежить від того, що саме ви робите (чи потрібно фільтрувати щорічні або щотижневі сезони навантаження перед виявленням аномалій тощо).