Server Admin Авторский блог системного администратора
всем день добрый!
решил поделится одним полезным приемом
он не будет откровением для опытных админов, но начинающим безусловно пойдет в "копилку
знаний" :)
я его не сам придумал, увидел в шаблоне мониторинга апача, не помню где, и сразу стал использовать и в других случаях
пример на bash, конечно можно реализовать эту же логику и под Windows, но у меня в этом нет нужды
скрипт простой, подробных пояснений не требует
итак, часто нам необходимо снимать много параметров с каждого объекта, к примеру с жестких
дисков, и дисков у нас бывает тоже штук 5-6 на одном сервере, снимаем мы например с каждого диска штук 10 параметров утилитой smartctl, итого получатся 50-60 запусков smartctl за раз, и каждый запуск блокирует диск, что не хорошо отражается на производительности дисков, график iowait time получается "шумным", рисуя "пилу" с зубьями 6-8%, замыливая реальную нагрузку и излишне нагружая дисковую подсистему сервера
что же делать?
часто советуют осторожно применять подобный мониторинг, учитывать что большое количество отслеживаемых параметров может тормозить сервер
но есть и другой выход - кэшировать результаты на клиенте и при очередном запросе, читать данные из кэша
это совсем не сложно реализовать при помощи bash скрипта
предполагаемый алгоритм кеширования:
1) при запуске smartctl для какого-нибудь диска, проверяем есть ли для него кэш (файл с выводом
команды)
2) определяем его возраст
3) если возраст нормальный, то берем данные из кэша, если нет, создаем новый файл
4) заодно отслеживаем общую частоту запуска smartctl для всех дисков, по поиску самого старого файла кэша (без фильтра по диску), чтоб слишком часто его не запускать
в итоге "пила" падает до долей процента
сам скрипт:
#!/bin/bash
if [ -z "$1" ]; then
exit 1
fi
##### PARAMETERS #####
nHDD="$1"
CACHE_TTL="55"
CACHE_FILE="/tmp/smartctl.`echo ${nHDD} | md5sum | cut -d" " -f1`.cache"
EXEC_TIMEOUT="5"
NOW_TIME=`date '+%s'`
LAST_FILE=`find /tmp/smartctl* -type f -printf '%TY-%Tm-%Td %TT %p\n' | sort -r | head -n1 | sed 's/\s\+/,/g' | cut -f3 -d,`
##### RUN #####
if [ -s "${CACHE_FILE}" ]; then
DATACACHE=$(cat "${CACHE_FILE}")
CACHE_TIME=`stat -c"%Y" "${LAST_FILE}"`
else
CACHE_TIME=0
fi
DELTA_TIME=$((${NOW_TIME} - ${CACHE_TIME}))
if [ ${DELTA_TIME} -lt ${EXEC_TIMEOUT} ]; then
sleep $((${EXEC_TIMEOUT} - ${DELTA_TIME}))
elif [ ${DELTA_TIME} -gt ${CACHE_TTL} ]; then
DATACACHE=`smartctl -a /dev/"${nHDD}" 2>&1`
echo "" >> "${CACHE_FILE}" # !!!
echo "${DATACACHE}" > "${CACHE_FILE}" # !!!
chmod 640 "${CACHE_FILE}"
fi
echo "$DATACACHE"
exit 0
соответственно параметр в конфигурации выглядит так:
UserParameter=uHDD.temp[*],sudo /etc/zabbix/disksmart.sh $1 | grep "194 Temp"| sed 's/\s\+/,/g' | cut -f10 -d,
Довольно таки интересное решение ! Появится немного времени попробую по-экспериментировать! Спасибо Вам!
А в чем смысл конкретно с smartctl в кэшировании? Его не обязательно часто запускать. Я где-то раз в час дергаю, чтобы снимать метрики. В данном случае в кэше не вижу смысла. Допустим, ты снял метрики раз в 10 минут и каждую минуту дергаешь заббиксом кэш, не нагружая диски. Но и данные ты берешь одни и те же из кэша. Какой в этом смысл?
Кэш имеет смысл использовать, чтобы собирать метрики, требующие длительных отрезков времени, чтобы получить данные. Например, подсчет размера большой директории, или анализ большого лог файла. Тогда имеет смысл скриптом по cron собирать данные в отдельный файл, а в zabbix передавать уже готовые значения.
у меня разные ключи с разным интервалом настроены, температура раз в 10 минут, перенаправленные сектора раз в 20 минут, статус - раз в полчаса и т.д. (как-то в один месяц вышли из строя три диска в серверах, с тех пор перестраховываюсь)
но когда дисков много, это все равно дает скачки на графике (IOwait time), именно в "нулевые" минуты и при небольшой рабочей нагрузке, в значительной степени ее "смазывает", ну и заставляет "экономить" с интервалами опроса
т.е. смысл в том чтобы избежать многократного запуска smartctl в один момент времени, скрипт играет роль менеджера очередей
это может быть актуально для любых программ которые выгружают все параметры в файл (или на стандартный вывод), и мы потом их оттуда берем, чтобы не запускать программу для каждого параметра и не создавать "толкучки"
у меня разные ключи с разным интервалом настроены, температура раз в 10 минут, перенаправленные сектора раз в 20 минут, статус - раз в полчаса и т.д. (как-то в один месяц вышли из строя три диска в серверах, с тех пор перестраховываюсь)
но когда дисков много, это все равно дает скачки на графике (IOwait time), именно в "нулевые" минуты (я очень не сразу понял откуда эти скачки, долго грешил на кроны разработчиков) и при небольшой рабочей нагрузке, в значительной степени ее "смазывает", ну и заставляет "экономить" с интервалами опроса
т.е. смысл в том чтобы избежать многократного запуска smartctl в один момент времени, скрипт играет роль менеджера очередей
обращение к диску через smartctl гораздо сильнее тормозит диск, чем обращение к файлу на этом диске
это может быть актуально для любых программ которые выгружают все параметры в файл (или на стандартный вывод), и мы потом их оттуда берем, чтобы не запускать программу для каждого параметра и не создавать "толкучки"
то что данные взятые из кэша могут быть неактуальны, это да, есть такой момент
в данном случае, выставлено время жизни кэша 55 сек и интервал запроса ключа 5 сек
для параметров запрашиваемых от 10 минут, до 2 часов вполне нормально
это даже нормально для апача, потому что там смысл не актуальность данных в секундах, а увидеть продолжительное изменение нагрузки, когда воркеры и количество запросов растут, при парсинге например
