Как стать автором
Обновить

Комментарии 11

LA надо ловить сразу, а не раз в минуту. Можно всё пропустить.
Но зачем? Есть же, например, atop, который умеет гораздо больше и настраивается куда гибче.
Да и в целом систем мониторинга 100500. Чем ваш скрипт лучше (за исключением устранения NIH)?

зы. Для скриптов есть github. Лучше делиться с сообществом скриптами через него. Глядишь, кто-нибудь и pull-request зашлёт с фиксом.
Такую диагностику можно вызывать не через cron, а через тот же monit — там и параметров мониторинга побольше, и с длительностью/частотой событий поиграться можно, и отправка на мыло есть.

Ну это не говоря уже о других системах мониторинга.
Чего только люди не делают лишь бы мониторинг не настраивать. Особенно «удобно» через вот такие костыли смотреть динамику и строить графики, а отловить тенденцию вообще раз плюнуть, чего там сгребти все письма за пол года и выстроить на временном графике. ИМХО — бесполезный костыль написанный от незнания принятых в отрасли средств.
Да уж, двумя awk'ами выгребать одно значение. Моветон.

Моя конструкция выполняется в 3(!) раза быстрее:
F5M=`cut -f1 -d' ' /proc/loadavg` && F5M=${F5M%.*}

Да, можете кидаться помидорами, что разница между одной и тремя тысячными секунды — это фигня. Но так закладывается более правильный подход к программированию на баше. Так, например, для гигабайта входных данных разница час vs 3 часа будет ощутимо заметнее.

Конкретно по сабжу мало что могу сказать. У меня были случаи высокого LA в реалтайме. Ну выжрал мускул всю память и начал свопиться на диск. И шо? Попробуй понять, что его так нагрузило. Это и есть проблема.
Вопрос оптимизации бесконечен…
Если уж играть в shell golf, то можно и вовсе cut -d. -f1 /proc/loadavg ;)
Согласен.
Да ладно вам придираться… :)
Хотя сейчас мне самому весело смотреть на это.
Уже не помню, скорее всего двухэтажный awk остался в скрипте от какой то предыдущей небрежной конструкции контроля порога срабатывания. Это неважно.

sledopit, спасибо за cut -d. -f1 /proc/loadavg

И прошу прощения, что не объяснил ясно как я понимаю назначение этого скрипта.
Мне важно было провести диагностику в момент выявления аномального состояния, в данном случае это load average выше заданного порога.
В вашем случае контрольный параметр может быть другим и могут быть другие диагностические процедуры.
Это индивидуально, потому пока не увидел особого смысла скрипт выкладывать на github, но вероятно выложу.

Данный скрипт не является универсальным инструментом, он не интерпретирует результаты тестов, но вы можете это добавить. Например если нагрузку создал mysql, то запустить скрипты диагностики для него.
Если, например, проблема с процессом внутри гостя, то напустить vzpid на PID и т.д.
Вариантам нет числа. Я не стал перегружать скрипт. Каждый пусть свое добавит сам если необходимо.

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

Я хотел получить срез состояния системы, процессов и приложений в момент проблем, увидеть проблему с привязкой к процессу виновнику (крысе) и установить его принадлежность. Правильнее будет назвать скрипт не ratskill.sh, а ratcatcher.sh

Вполне хорошая идея интегрировать подобный скрипт с zabbix или monit, можно добавить диагностику dtrace и многое другое.
Это от вашей фантазии зависит.
но мне сразу важно знать что было ночью.
Вы таки почитайте про atop. Он кучу информации в более детальном виде складывает в /var/log/atop. По умолчанию собирает он информацию раз в 10 секунд.
Правильнее будет назвать скрипт не ratskill.sh, а ratcatcher.sh
Первый вариант забавнее. Rat Skill :)
Что люди не делают, лишь бы zabbix не ставить…
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории