Простой способ алгоритмически идентифицировать всплеск зарегистрированных ошибок

Нам нужна система раннего предупреждения. Я имею дело с сервером, который, как известно, имеет проблемы с производительностью под нагрузкой. Ошибки записываются в базу данных вместе с отметкой времени. Есть некоторые шаги ручного вмешательства, которые могут быть предприняты, чтобы уменьшить нагрузку на сервер, но только если кто-то знает о проблеме ...

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

Мы не обеспокоены случайными ошибками, но не имеем определенного порога. Я мог бы просто уведомить кого-нибудь в любое время, скажем, о трех ошибках за пять минут, но я уверен, что есть лучший способ ...

Я хотел бы иметь возможность настроить чувствительность алгоритма на основе обратной связи от системных администраторов. На данный момент они хотели бы, чтобы это было довольно чувствительным, хотя мы знаем, что можем ожидать некоторые ложные срабатывания.

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

Прошло 5 месяцев с тех пор, как вы задали этот вопрос, и, надеюсь, вы что-то поняли. Я собираюсь сделать несколько разных предложений здесь, надеясь, что вы найдете их для использования в других сценариях.

Для вашего случая использования я не думаю, что вам нужно смотреть на алгоритмы обнаружения пиков.

Итак, начнем: Давайте начнем с картины ошибок, происходящих на временной шкале:

Вам нужен числовой индикатор, «мера» того, как быстро появляются ошибки. И эта мера должна поддаваться пороговому значению - ваши системные администраторы должны иметь возможность устанавливать пределы, которые определяют, какие ошибки чувствительности превращаются в предупреждения.

Мера 1

Вы упомянули «спайки», самый простой способ получить спайк - это нарисовать гистограмму через каждые 20 минут:

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

(В этот момент вы можете задаться вопросом, не может ли быть изменена эта 20-минутная длина окна. Это возможно, и вы можете думать о длине окна как об определении слова вместе в ошибках фразы, появляющихся вместе .)

В чем проблема с этим методом для вашего конкретного сценария? Ну, ваша переменная является целым числом, вероятно, меньше 3. Вы не установили бы свой порог равным 1, поскольку это просто означает, что «каждая ошибка - это предупреждение», что не требует алгоритма. Таким образом, ваш выбор для порога будет 2 и 3. Это не дает вашим системным администраторам много детального контроля.

Мера 2

Вместо подсчета ошибок во временном окне следите за количеством минут между текущей и последней ошибками. Когда это значение становится слишком маленьким, это означает, что ваши ошибки становятся слишком частыми, и вам нужно выдать предупреждение.

Ваши системные администраторы, вероятно, установят ограничение в 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\sigma$

Более забавные вещи о временных рядах

1. Многие реальные временные ряды демонстрируют циклическое поведение. Существует модель под названием ARIMA, которая помогает вам извлечь эти циклы из ваших временных рядов.

2. Скользящие средние, которые учитывают циклическое поведение: Холт и Уинтерс

+1 для статистического контроля процесса, здесь есть некоторая полезная информация об обнаружении шагов .

Для SPC не так уж сложно написать реализацию Западных электрических правил или Правил Нельсона .

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

Этот вид относится к вопросу, который я опубликовал в Stack Overflow некоторое время назад (только что написал быстрый ответ, если это поможет): Статистические контрольные диаграммы процесса в SQL Server 2008 R2

Поиск онлайн-алгоритмов обнаружения будет началом.

Более подробная информация находится в стеке потока: пиковое значение измеренного сигнала

Реализация наивной процедуры обнаружения пиков на python находится на github.

Возможно, вы захотите взглянуть на статистический контроль процесса. Или мониторинг временных рядов. В этом направлении проделана огромная работа, и оптимальный ответ, вероятно, во многом зависит от того, что именно вы делаете (нужно ли отфильтровывать ежегодные или еженедельные сезонные нагрузки перед обнаружением аномалий и т. Д.).