Подсчет дней до заполнения диска

9

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

Я хотел бы получать более умные оповещения - что меня действительно волнует, так это «сколько у меня есть времени, прежде чем я смогу что-то сделать с свободным пространством?», Например, если тенденция показывает, что через 7 дней у меня закончится диск пробел, затем выдать предупреждение, если это менее чем за 2 дня, то поднять ошибку.

Стандартный интерфейс панели управления Graphite может быть довольно умным с производными и полосами доверия Холта Уинтерса, но до сих пор я не нашел способа преобразовать это в действенные метрики. Я также хорошо справляюсь с обработкой чисел другими способами (просто извлеките необработанные числа из графита и запустите сценарий для этого).

Одна сложность заключается в том, что график не является гладким - файлы добавляются и удаляются, но общая тенденция с течением времени заключается в увеличении использования дискового пространства, поэтому, возможно, необходимо взглянуть на локальный минимум (если смотреть на показатель «без диска»). ) и нарисуйте тренд между впадинами.

Кто-нибудь делал это?

Амос Шапира
источник
какая у тебя инфраструктура? например, если вы работаете с vmware, вы можете взглянуть на их продукты Operations Manager, которые делают такое прогнозное представление дискового пространства.
Chopper3
The volume of crap people have to store will expand to fill the disk available.- Аксиома старого сисадмина
voretaq7
Наши серверы разделены между VMware VM, использующими IBM XIV для дисков, и KVM, использующими локальные SD. Я не уверен, что у нас есть доступ к такой информации (моя команда не управляет VMware или XIV) и предпочел бы решение, не зависящее от продукта.
Амос Шапира

Ответы:

8

Честно говоря, «Дни до полного» - это действительно паршивая метрика, так как файловые системы становятся ОЧЕНЬ глупыми, когда приближаются к 100% -ной загрузке.
Я действительно рекомендую использовать традиционные пороги 85%, 90%, 95% (предупреждение, аварийный сигнал и критические значения, которые вам действительно нужно исправить, СЕЙЧАС, соответственно) - это должно дать вам много времени для предупреждения на современных дисках (скажем, диск объемом 1 ТБ: 85% терабайта все еще оставляет вам много места, но вы знаете о потенциальной проблеме, на 90% вы должны планировать расширение диска или какое-либо другое смягчение, а при 95% терабайта у вас осталось 50 ГБ, и вам, черт побери, следует исправить это в движении).

Это также гарантирует, что ваша файловая система функционирует более или менее оптимально: у нее достаточно свободного места для создания / изменения / перемещения больших файлов.

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


Если вы все еще используете метрику «дней до полного», вы можете извлечь данные из графита и выполнить некоторые математические расчеты. Инструменты мониторинга IBM реализуют метрики от нескольких дней до полной, которые могут дать вам представление о том, как их реализовать, но в основном вы берете на себя скорость изменения между двумя точками в истории.

Ради вашего здравого смысла вы можете использовать производную от Graphite (которая даст вам скорость изменения во времени) и проектировать с ее использованием, но если вы ДЕЙСТВИТЕЛЬНО хотите получать «более умные» оповещения, я предлагаю использовать ежедневную и еженедельную скорость изменения (рассчитанную на основе пикового использования за день / неделю).

Конкретный используемый вами прогноз (наименьшая скорость изменения, наибольшая скорость изменения, средняя скорость изменения, средневзвешенная величина и т. Д.) Зависит от вашей среды. Инструменты IBM предлагают так много разных представлений, потому что действительно сложно найти шаблон, который подходит всем.


В конечном счете, ни один алгоритм не будет очень хорош в выполнении того расчета, который вы хотите. Использование диска определяется пользователями, а пользователи являются противоположностью модели Rational Actor: все ваши прогнозы могут выйти за рамки, когда один сумасшедший решит, что сегодня это день, когда они собираются выполнить полный дамп системной памяти для своих пользователей. домашний каталог. Да просто так.

voretaq7
источник
Спасибо за ваши идеи. Я вижу ваши очки. Я все еще думаю, что постоянные пороги просто пытаются отразить "как долго я должен исправляться?" и чувствую себя несколько оправданным вашим комментарием "скорректировать свои пороги". Простые производные графита не работают, потому что исходный граф не является гладким. Спасибо за указатель на инструменты IBM, то, что вы описываете, похоже на то, о чем я начал думать (извлеките последние два минимума и рассчитайте из них наклон).
Амос Шапира
Несомненно, смысл метрики «дней до полного» заключается в том, что при статических порогах 85/90/95 вы не представляете, как быстро заполняется диск? Конечно, вы знаете о потенциальной проблеме, но как узнать, есть ли у вас дни для ее решения или недели / месяцы?
Мне действительно интересно, что у вас будет такое мнение. Позвольте мне сформулировать это следующим образом: в вашей компании идет процесс закупок, который занимает около 6 недель между первоначальным запросом дополнительных жестких дисков и тем днем, когда эти жесткие диски фактически устанавливаются в коробки, и перераспределение нагрузки начинает происходить. Учитывая тот 6-недельный срок, на какой диск% вы должны получать уведомления, чтобы иметь возможность своевременно установить диск? 80%? 75%? В том-то и дело, что вы не знаете, если не приложите усилий для расчета темпов роста.
JHixson
2

Недавно мы разработали специальное решение для этого с использованием линейной регрессии.

В нашей системе основным источником исчерпания диска являются файлы блуждающих журналов, которые не вращаются.

Так как они растут очень предсказуемо, мы можем выполнить линейную регрессию использования диска (например, z = numpy.polyfit(times, utilization, 1)), а затем рассчитать 100% отметку, учитывая линейную модель (например, (100 - z[1]) / z[0])

Развернутые выглядит как реализация этого с помощью рубина и GSL, хотя Numpy работает довольно хорошо тоже.

Подавая данные о средней загрузке за неделю с 90-минутными интервалами (112 баллов), мы смогли выбрать вероятных кандидатов на исчерпание диска без особых помех.

Класс в Gist заключен в класс, который извлекает данные из разведчика, предупреждает об ослаблении и отправляет некоторую телеметрию во время выполнения в statsd. Я оставлю это немного, так как это специфично для нашей инфраструктуры.

matschaffer
источник
Я обновил ответ, добавив некоторую информацию, когда он у нас появился.
matschaffer
1
Просто нашел забавную ошибку с таким подходом. У нас также есть 90% сигналов тревоги. Один из наших хостов рос настолько медленно, что достигал 90% и вызвал эту тревогу, несмотря на то, что до срабатывания 100% у него оставалось больше недели, поэтому предупреждающее предупреждение никогда не срабатывало;) Думаю, я должен использовать (90 - z[1]) / z[0]вместо этого.
matschaffer