LINUX.ORG.RU
ФорумAdmin

Как предугадать и не допустить переполнение диска?

 


0

2

Поставили мне такую задачу: есть у нас директория X, которая периодически растет. Чтобы не допустить переполнения, необходимо настроить оповещение, будущее предупреждать нас за ~2 часа до достижения пороговых значений (до окончания свободного на диске места). Правил роста директории мне не рассказали. Известно лишь, что это директории под кэш и лог Nginx.

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

Что сделал сейчас: запустил скрипт, логирующий динамику роста директории, которую планирую впоследствии использовать для прогноза критического объема диска.



Последнее исправление: alekseipa5 (всего исправлений: 1)

Считай среднюю скорость прироста для двух интервалов:

  • «Длинный», условно, средняя за сутки.
  • «Короткий», условно, средняя за последний час.

Затем используй максимальное значение из этих двух и на его основе делай вывод, пора ли уже слать оповещение.

Это поможет на случай резких скачков.

Также возможно стоит настроить проверку, что если резко (за несколько минут) залито данных свыше некоторого порога, то слать уведомление чтобы админ проверил причину аномальной активности.

wandrien ★★
()

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

antech
()
Ответ на: комментарий от antech

Не поверишь, но именно об этом я и подумал, когда писал.

С такими нечёткими заданиями как раз отлично справилась бы сеть.

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

wandrien ★★
()
Ответ на: комментарий от wandrien

читаю и удивляюсь, этож надо детектить аномальную активность по изменению темпа прироста лога. А сам лог никак нельзя анализировать на наличие аномальной активности и внесением в бан например?

antech
()

хрустальный шар, говорят, здорово помогает.

ну или гадание на внутренностях жертвенных животных.

но если нужно непременно с налетом технологичности, как сейчас модно, тогда берем минимальный статистически значимый интервал времени(такой, при котором обязательно случается статистически значимое увеличение объема данных), минуту например. далее 5 минут, пол-часа и искомые два часа. таким образом получаем целых 4 оракула, предрекающих нам будущее. на основе актуальных данных высчитываем когда наступит час Ч, для всех указанных интервалов.

оракул номер один, минутный - самый нервный. оракул номер четыре - непробиваемый, как бригадный генерал на пенсии.

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

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

удачи.

olelookoe ★★★
()
Ответ на: комментарий от olelookoe

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

antech
()

необходимо настроить оповещение, будущее предупреждать нас за ~2 часа до достижения пороговых значений
Правил роста директории мне не рассказали.

«Хачу харчо». Ну удачи им, надеюсь вы им сказали что вашу бабушку звали не Ванга?

anc ★★★★★
()

Задача решается элементарно. Максимальная скорость записи диска умножаем на 2 часа. Если места меньше – сигнализация админу. А по факту задача поставлена не корректно, отказаться выполнять.

azsx
()

необходимо настроить оповещение, будущее предупреждать нас за ~2 часа до достижения пороговых значений

Глупость какая-то. Просто предупреждать при пересечении порогового значения, которое поставить около 80%.

за ~2 часа до достижения пороговых значений (до окончания свободного на диске места)

Это за два часа до 100%? Типа админы дежурят круглосуточно, без выходных, как пожарники, только вместо системы мониторинга велосипедный скрипт)

goingUp ★★★★★
()

Делай замеры с частотой 5 минут, делай прогноз по последним 2-3 замерам предполагая что рост будет линейным. Будет не хуже чем прогрессбар установщика у винды.

slowpony ★★★★★
()
Ответ на: комментарий от goingUp

дада, сначало ты ставишь алерт на 70 он всех задалбывает, тебе говорят поменяй на 80, он снова всех задалбливает, говорят меняй на 90 )))))))) а потом КАК ЭТО место кончилось? а почему нас не предупредили

antech
()

Вообще странное задание «сообщать за 2 часа до достижения 100% объема диска».


  • 1. Директорию в которую пишутся логи лучше сделай как точку монтирования для псевдодиска.
  • 2. Задать «мягкую» квоту на использование места на псевдодиске, при ее превышении отправляется уведомление по почте, а после периода отсрочки, который по умолчанию составляет 7 дней, мягкая квота становится жесткой.
  • 3. Все это потестить, запросить премию.
splinter ★★★★★
()
Последнее исправление: splinter (всего исправлений: 1)
Ответ на: комментарий от wandrien

Также возможно стоит настроить проверку, что если резко (за несколько минут) залито данных свыше некоторого порога, то слать уведомление чтобы админ проверил причину аномальной активности.

Это все легко делается на каком-нибудь check_mk безо всяких нейросетей

pekmop1024 ★★★★★
()
Ответ на: комментарий от user13

ИМХО, если бы от ТС просили присылать уведомление при 70% или другом проценте заполнения ФС, он бы это сделал, без темы на ЛОР.

А от ТС просят непойми что — как-то определить скорость роста логов/кеша и дать прогноз. Причём, наверное, у них уже не раз логи забивали всё, раз такая задача стоит. Но данных по объёмам/скорости роста с прошлых моментов нет. Или ТС не внимательно слушал ТЗ.

mky ★★★★★
()

А какие действия должны будут приняты в течени 2 часов после аллерта? Может правильно было бы установить порог, к примеру 80% и автоматизировать дальнейшие предпринимаемые действия?

julixs ★★★
()
Ответ на: комментарий от ya-betmen

Тут вопрос стоит интереснее - что будет, если ПО предупреждение выдаст, а диск заполнится через 2 часа и 15 минут...

Притянут за растрату и разбазаривания имущества?

shTigrits ★★★
()

Правильный ответ тут такой:

а) уведомление по пороговому значению и не трахать мозг.

б) хранить и анализировать логи на специально отведённом для того сервере (Opensearch подойдёт).

ugoday ★★★★★
()

Мысли в слюх


  • Найти и воспользоваться готовой хренью из коробки (системы/репозитория) фиг знает какой, лимиты там, фичи ФС и прочее.

  • Узнать максимальную скорость записи на диск (можно произвести программный тест во время запуска программы следилки)

  • На основе этого вычислить за какое время при текущем объёме диска он будет забит и исходя из этого времени сделать ALARM! смело положив болт на требование в неадекватные 2 часа.

  • Итого

    • не смотреть на директории смотреть на объём пространства в ФС в целом
    • не смотреть на 2 часа, а
      • вычислить скорость записи
      • вычислить текущий объём
      • посчитать забьётся ли при диск при максимальной записи быстрее чем за два часа
      • и если да послать АХТУНГ и ВНИМАНИЕ сразу же
      • пока не стало уже поздно.

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


Но есть нюанс. Кто-то может внезапно создать несколько огромных, но пустых файлов и всё сломается (наверное) =))))))))))))
Типа man truncate но надо проверить оно прям резервирует место у фс или куда.

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 3)
  1. Для директории выделить отдельный volume, чтобы занимаемое место узнавать дешёвым df, а не du

  2. Поставить кубернетес (опционально)

  3. Поставить node_exporter, prometheus, alertmanager, grafana

  4. node_exorter будет сливать инфу в прометея, от него будут работать alertmanager, grafana

  5. Написать promql-ки, там всё есть.

Делов на полгода максимум.

vbr ★★★★
()

Снова привет. Для всех дебатирующих выше отвечу - я часть компании, которая сапортит различные веб-проекты (магазины, например).

Задачу принес такой, какой ее сформулировал клиент.

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

В 90% случаев проще предпринять какие-то действия и:

  1. все сделать красиво, хорошо и прелестно - в точности, как сформулировано в задаче - и все счастливы
  2. все сделать так, как получится (но при этом действительно стараясь выполнять все грамотно) и практически доказать клиенту, что задача поставлена некорректно, и ее выполнение требует переформулировки либо смены подхода

Сейчас я пытаюсь сделать все

красиво, хорошо и прелестно - в точности, как сформулировано в задаче

чтобы

все <были> счастливы

alekseipa5
() автор топика

Что сделал сейчас: запустил скрипт, логирующий динамику роста директории, которую планирую впоследствии использовать для прогноза критического объема диска.

Есть такая штука: collectd. Там, кажется, оповещения тоже есть.

AS ★★★★★
()