Мы используем графит, чтобы отслеживать историю использования диска с течением времени. Наша система оповещения смотрит на данные из графита, чтобы предупредить нас, когда свободное пространство становится ниже определенного количества блоков.
Я хочу получать более умные оповещения - что я действительно заботиться о том, "сколько времени у меня есть, прежде чем я должен что-то сделать со свободным пространством?", например если тенденция показывает, что через 7 дней у меня закончится место на диске, то выведите предупреждение, если меньше 2 дней, то выведите ошибку.
Стандартный интерфейс панели управления Graphite может быть довольно умным с производными инструментами и полосами уверенности Холта Уинтерса, но пока я не нашел способа преобразовать это в эффективные показатели. Я также хорошо обрабатываю числа другими способами (просто извлеките необработанные числа из графита и запустите для этого скрипт).
Одна из сложностей заключается в том, что график не является гладким - файлы добавляются и удаляются, но общая тенденция со временем состоит в том, что использование дискового пространства увеличивается, поэтому, возможно, есть необходимость посмотреть на локальный минимум (если смотреть на метрику «диск свободен» ) и нарисуйте тренд между впадинами.
Кто-нибудь это делал?
Честно говоря, «Дни до полного» в любом случае - действительно паршивая метрика - файловые системы становятся ДЕЙСТВИТЕЛЬНО ТУПОЙ, когда они приближаются к 100% использованию.
Я действительно рекомендую использовать традиционные пороговые значения 85%, 90%, 95% (предупреждение, сигнал тревоги и критическое-вам-действительно-нужно-исправить-СЕЙЧАС, соответственно) - это должно дать вам много времени для предупреждений на современных дисках (скажем, диск емкостью 1 ТБ: 85% терабайта по-прежнему оставляет вам много места, но вы знаете о потенциальной проблеме, на 90% вам следует планировать расширение диска или какое-либо другое смягчение последствий, а на 95% терабайта у вас осталось 50 ГБ и, черт возьми, исправление должно быть в движении).
Это также гарантирует, что ваша файловая система функционирует более или менее оптимально: в ней достаточно свободного места для создания / изменения / перемещения больших файлов.
Если ваши диски несовременны (или ваша модель использования включает в себя большое количество данных, которые помещаются на диск), вы можете легко настроить пороговые значения.
Если вы по-прежнему настроены использовать метрику «дней до полного заполнения», вы можете извлечь данные из графита и провести с ними некоторые вычисления. Инструменты мониторинга IBM реализуют метрики за несколько дней до получения полной информации. который может дать вам представление о том, как его реализовать, но в основном вы берете скорость изменения между двумя точками истории.
Ради вашего здравомыслия вы можете использовать производную от Graphite (которая даст вам скорость изменения с течением времени) и использовать ее в проекте, но если вам ДЕЙСТВИТЕЛЬНО нужны «умные» предупреждения, я предлагаю использовать дневную и еженедельную скорость изменения (рассчитанную на основе пикового использования в течение дня / недели).
Конкретный прогноз, который вы используете (наименьшая скорость изменения, наибольшая скорость изменения, средняя скорость изменения, средневзвешенное значение и т. Д.), Зависит от вашей среды. Инструменты IBM предлагают так много разных представлений, потому что действительно сложно найти универсальный шаблон.
В конце концов, ни один алгоритм не будет очень хорош для выполнения тех вычислений, которые вам нужны. Использование диска определяется пользователями, и пользователи являются противоположностью модели Rational Actor: все ваши прогнозы могут выпасть из окна, если один сумасшедший решит, что сегодня тот день, когда они собираются выполнить полный дамп системной памяти в свою домашний каталог. Да просто так.
Недавно мы развернули для этого специальное решение с использованием линейной регрессии.
В нашей системе основным источником исчерпания дискового пространства являются ненужные файлы журналов, которые не обновляются.
Поскольку они растут очень предсказуемо, мы можем выполнить линейную регрессию использования диска (например, z = numpy.polyfit(times, utilization, 1)), затем рассчитайте оценку 100% с учетом линейной модели (например, (100 - z[1]) / z[0])
Развернутая реализация выглядит как этот с использованием ruby и GSL, хотя numpy тоже работает неплохо.
Загрузка этих недельных данных о среднем использовании с 90-минутными интервалами (112 баллов) позволила выявить вероятных кандидатов на исчерпание дискового пространства без особого шума.
Класс в сущности заключен в класс, который извлекает данные из scout, оповещает о резерве и отправляет некоторую телеметрию времени выполнения в statsd. Я оставлю это в стороне, поскольку это относится к нашей инфраструктуре.
Для этой цели мы сохраняем показатель «среднее время до полного» или «среднее время до отказа», используя статистический тренд и его стандартное отклонение, чтобы добавить более разумную (менее глупую) логику к простому статическому порогу.
Самое простое предупреждение: Просто произвольный порог. Не рассматривает ничего общего с фактическим использованием дискового пространства.
Простой TTF: Немного умнее. Вычислите неиспользованный процент минус буфер и разделите на нулевую защищенную скорость. Не очень статистически надежный, но несколько раз спасал мою задницу, когда мои пользователи загружали корпус своих кошачьих видео (реальная история).
Лучше TTF: Но я хотел избежать предупреждений для статических томов, доступных только для чтения, на 99% (если они когда-либо не были изменены), и я хотел более проактивное уведомление для шумных томов и для обнаружения приложений с неуправляемыми следами дискового пространства. Да, и случайные отрицательные значения в Simple TTF меня просто беспокоили.
Я все еще держу статический буфер в 1%. Как стандартное отклонение, так и скорость потребления увеличиваются при ненормальном использовании, что иногда компенсирует. На языке graphana или alertmanager вы получите довольно дорогие подзапросы. Но я получил более плавные таймсерии и менее шумные оповещения, которые искал.
clamp_min((100 - 1 - stddev_over_time(usedPct{}[12h:]) - max_over_time(usedPct{}[6h:])) / clamp_min(deriv(usedPct{}[12:]),0.00001), 0)Более тихие диски обеспечивают очень плавное оповещение.
Более длинные диапазоны укрощают даже самые шумные публики.