Saboteur

/var/log может содержать логи с небезопасной информацией. Поэтому давать доступ группе надо только если все кто в группе доверенные лица.
Или запускай скрипт от рута.

Даже по названию папки понятно откуда она так называется. public слово понятно, html понятно.
Дефолтные настройки веб сервера для персональных страничек пользователей.
При включении они доступны по адресу www.site/~username

grafana. Обычно она уже идет с influxDB, можно метрики слать напрямую в influxDB через его АПИ

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

Нужно понимать как работает многозадачность и распределение процессорного времени по ядрам.
В Линукс довольно сложно посчитать реальную занятость процессора.
В сам свитчинг ничего упираться не может, точнее нет каких-то специальных лимитов. Это обычная процессорная занятость, относящаяся наверное к system cpu usage, но это неточно. Чем быстрее процессор, тем быстрее он может выполнять свитчинг и тем больше свитчингов в секунду может быть выполнено, это просто выполнение инструкций процессора вне рамках процессов, а внутри ядра системы, точнее process scheduler.

Но проблема в том, как именно распределяется процессорное время. process scheduler в ядре линукса выделяет слайсы примерно по 10-15 милисекунд на процесс, потом переключает на другой. Для процессов, которые что-то активно вычисляют (например архивация), после анализа деятельности может быть выделен более длинный слайс или несколько подряд, то есть уменьшается свитчинг. При этом оценка времени, которая нужна на сам свитчинг - она довольно сложная, ведь для подсчета количество потраченного cpu нужно потратить cpu, и эти 10-15% может на самом деле не существовать.

Если парралельных процессов очень много и все хотят что-то делать (чекнуть load average), то машина просто не успевает обработать их все, и тратить на переключение приличное количество ресурса, вместо того чтобы непосредственно выполнять код ваших программ.
Таким образом какого-то определенного лимита на context switching нет, это просто еще одна метрика, которая может подсказать что слишком много одновременно запускаете, можно попробовать оптимизировать.

Ну или просто не хватает CPU, а система ошибочно показывает свободные ресурсы, которых на самом деле нет.

Линукс на самом деле не так уж детально может посчитать точное количество ресурсов. Там выполняется все очень просто - на входе в контекст засекается timestamp, на выходе из контекста засекается таймстамп, и потраченное время дописывается в метаданные процесса (для каждого ядра, если процесс многопоточный). Исторические значения не записываются, в метаданных процесса есть только вот это - сколько всего cpu usage с момента старта процесса.
Если запустить какой-нить top, он будет каждые 1-2 секунды бегать по списку процессов, сравнивать этот параметр и показывать результат загруженности за последние 1-2 секунды, но вот уточнить процесс занял свои 25% cpu плавно в течение секунды, или он занимал 100% cpu первую четверть секунды или третью - вы уже не сможете.

Ну и само ядро считает свои внутренние потоки так же само.
И только активность самого process scheduler (то есть cpu затраченное на анализ и переключения процессов) не может быть красиво подсчитана.

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

Что-то непонятно у вас с текстом.
Приведите несколько строк из файла с alb.ingress.kubernetes
там перевода строк нет, или как?
sed не умеет работать с мультистроковыми регулярками, он считывает текст построчно и затем сравнивает с паттерном, при этом в считанной строке символа перевода строки собственно даже и не будет.
Можно попробовать работать с мультилайн через наполнение pattern space, правда там будет конструкция посложнее.

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

для валидного JSON (а ваш пример невалидный, плюс кавычка во втором айпишнике не закрыта", можно было бы заюзать так

jq '[.[][][].addr]|.[1]'

Здравствуйте.

На Ubuntu server после ввода команды bg <номер процесса> ничего не происходит, просто возвращается строка на ввод.

Так и должна просто возвращаться строка на ввод. Во первых если процесс уже был запущен и работал в фоне, то вы ничего не делаете. Если он был приостановлен, он просто должен перейти в running.
Но для того, чтобы вам помочь, было бы неплохо чтобы вы привели лог своей консоли, как вы выполняете jobs, как вы указываете номер процесса. То есть выполнить jobs, bg номер, jobs

При вводе команды bg <номер процесса> на экране начинает отображается вывод этого процесса, при этом окно терминала наглухо зависает и я ничего не могу сделать, даже остановить процесс (ctr+C)

Как докажете что окно терминала именно зависает?
для начала, если вы запустили процесс в фоновом режиме, то Ctrl+C естественно не может его остановить. Он же в фоне выполняется. Скорее всего вы не понимаете, что вам доступен терминал, в котором вы можете вводить другие команды.
Фоновый процесс просто может писать текст в терминал.
Напишите вслепую clear, например, проверьте что экран очистился ненадолго.
И запускать процессы в фон, которые шлют много текста в терминал - в общем случае бессмысленно

все очень просто.
1. Бэкапы.
2. УПС.

И не искать себе выдуманное решение с файловыми системами.
* Файловые системы не заботятся о пользовательских данных.
* Целостность файловой системы это о том, что структура будет целая, то есть два файла не занимают один кластер, нет незавершенных операций, когда что-то недописано, или какой-то кластер считается занятым, а на самом деле нет и уже неконсистентность.
* Эти проблемы решаются простым способом - все что криво удалить, и все. Не восстановить.
* Второй момент - софт может просто записать кривые данные, и тут как бы от файловой системы не зависит. Вплоть до какого-нить криптера, который сделает совершенно корректные файловые операции и все пошифрует.
* Если же глючит хард, то там все еще хуже.

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

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

16 tb это довольно большой размер. Не так часто файлы его достигают.
Я бы разбил мониторинг на две части.

Первая часть - find всех файлов которые больше 10 tb, например, и занесение их в базу. Раз в сутки, например.
Вторая - stat по файлам из базы, выбрать частоту, которая устраивает.

Базой может быть банально текстовый csv файл с timestamp, absolute path, size с каким-то разделителем.
Или, например, influxdb с графаной.. на выбор

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

руками залогинься на сервер и закинь публичный ключ в ~/.ssh/authorized_keys

еще почитай про файл ~/.ssh/config
там можно настроить все опции для ssh подключений независимо от команды

Адаптируй эту команду.

mkdir "folder$(( $(ls -1d ./folder* 2>/dev/null |wc -l) + 1 ))"

Или эта понадежнее будет:

mkdir "folder$(( $(ls -1d folder* | cut -c 7- | sort -n | tail -n1) + 1))"