Спустя шесть с половиной лет с момента формирования ветки 3.x представлена (https://lkml.org/lkml/2017/1/9/856) новая значительная версия пакета mdadm 4.0 (http://git.kernel.org/cgit/utils/mdadm/mdadm.git/), включающего в себя набор инструментов для управления программными RAID-массивами в Linux. Значительный выпуск связан с передачей управления разработкой новому мэйнтейнеру - Neil Brown передал свои полномочия Jes Sorensen, который теперь возглавил проект. Из функциональных изменений отмечается поддержка режима failfast (https://en.wikipedia.org/wiki/Fail-fast) и большая порция исправлений, связанных с поддержкой кластерных RAID и IMSM RAID (Intel Matrix Storage Manager). Для IMSM добавлена поддержка устройств с размером сектора 4k.URL: https://lkml.org/lkml/2017/1/9/856
Новость: https://www.opennet.ru/opennews/art.shtml?num=45835
Подскажите, может есть годная статья по организации мониторинга и периодической проверки md-raid ?
> Подскажите, может есть годная статья по организации мониторинга и периодической проверки
> md-raid ?в Icinga/Nagios вполне работает NRPE и check_raid (https://github.com/glensc/nagios-plugin-check_raid)
> Подскажите, может есть годная статья по организации мониторинга
> и периодической проверки md-raid ?Поищите скрипт checkarray, если он ещё не входит в применяемый пакет mdadm. Ну и mdadm --monitor для текущего (опять же, его может уметь прилично приготовленный инитскрипт, как у нас).
спасибо за ответ.> может уметь прилично приготовленный инитскрипт, как у нас
Немного не понимаю - где этот скрипт? Вот тут https://packages.altlinux.org/ru/Sisyphus/srpms/mdadm/spec&n...всё стоковое, если глаза не врут. Куда смотреть?
>> может уметь прилично приготовленный инитскрипт, как у нас
> Немного не понимаю - где этот скрипт?
> Вот тут https://packages.altlinux.org/ru/Sisyphus/srpms/mdadm/spec
> всё стоковое, если глаза не врут. Куда смотреть?https://packages.altlinux.org/ru/Sisyphus/srpms/mdadm/gear -> http://git.altlinux.org/people/shaba/packages/?p=mdadm.git;a... -> http://git.altlinux.org/people/shaba/packages/?p=mdadm.git;a...
Дистрибутив назовите. Возможно у вас все уже есть.
Void Linux, CentOS 7
> Подскажите, может есть годная статья по организации мониторинга и периодической проверки
> md-raid ?mdadm --monitor --scan --syslog
syslog на email.
В файл mdadm.conf впишите адрес, куда отправлять письма с проблемами
MAILADDR admin@domain.tld
Это не профессиональный подход к делу.
Необходимо все критичные syslog алерты слать на почту.
> Это непрофессиональный подход к делу.
> Необходимо все критичные syslog алерты слать на почту.Это малограмотный подход к делу, увы -- в случае условного пожара почтой захлебнёт.
Профессиональный подход к этому самому делу включает в себя выявление корневой причины -- например, не "недоступна файловая система" + "сдох массив целиком", а "сдох массив целиком"; аналогично со взаимозависимыми сервисами или цепочками свичей/маршрутизаторов.
Вот только так гораздо сложней уметь...
PS: если всё-таки копать от логов, то http://loganalyzer.adiscon.com в паре с rsyslogd -- неплохая штука; а если их *много* и надо что-то с этим делать, то я бы смотрел в сторону http://edgeofsanity.net/article/2012/06/17/central-logging-w...
PPS: ещё в своё время пришёл к подходу "пассивный удалённый мониторинг плюс активный локальный".
Ваш профессионализм в мониторинге состояния системы вызывает у меня сомнение.
Если вы считаете, что критичное предупреждение не заслуживает внимания, то вам лучше не заниматься системным администрированием и сервисной поддержкой серверов.
На почту должны сыпаться все критичные алерты, если хотите дальше разбираться, то настраивайте сборщик syslog и snmp трапов на удаленной системе и парсите данные, как вам нужно.
> Ваш профессионализм в мониторинге состояния системы вызывает у меня сомнение.А мне, простите, пофиг на Вашу оценку после предложения ссыпать всё в почту. Даже если разгребать её procmail+mutt, когда-то да накроет с головой...
Т.е. в качестве разумной меры для нормального случая -- да, согласен, приветствую. Просто стоит понимать, что это уровень не мастерства, а хороший ремесленнический (и в этом плохого ничего нет, но они разные).
PS: ещё хорошей практикой оказался лог-сервер, у которого на подсеть открыт только [r]syslog на приём, а по ssh доступен с белого списка хостов.
https://github.com/zalora/nixsap/blob/master/modules/pkgs/ch...
> https://github.com/zalora/nixsap/blob/master/modules/pkgs/ch...Странный скрипт: болтливый -- в почту засунуть можно, но спам будет усыплять (хотя для архива и такое бывает полезно, но это ещё фильтровать...), при этом не годится для раскидывания по умолчанию -- т.к. вопит почём зря на хосте без mdraid:
if [ ! -e "$stat" ]; then
echo "WARNING: $stat does not exist"
exit 1
fi
В общем, штатный mdmon и дебиановский checkarray лично мне куда более симпатичны. :)
А вы, коллега, не натравливайте его на машины без рейдов. Это "скритп" для исинги, а там уж и емейл, и слак, и аейжердьюти, и все другие ништяки.
> А вы, коллега, не натравливайте его на машины без рейдов.Ладно :)
смотри в сторону zabbix + graylog. И будет счастье
Ребята, я не абы какой крутой админ, но юзая zabbix делаю так. Добавляю скрипты необходимые для авто-обнаружения массивов и элементы данных для их мониторинга на хост, который будем мониторить. Со стороны заббикса имею шаблон и прототипами элементов данных и триггирами.Может кому-то пригодится, а может кто-то даст дельный совет, буду рад в любом случае.
Сами скрипты:
1. /etc/zabbix/zabbix_agentd.conf.d/md.conf
#Старый-добрый алерт выдающий количество массивов со сбойными дисками
UserParameter=system.md.state,egrep "\[.*_.*\]" /proc/mdstat | wc -l#Тут мы добавляем элементы данных для обнаружения устройств входящих в программные массивы и мониторинга их состояния
UserParameter=system.md.device.discovery,/usr/local/sbin/discovery_md_devices.py
UserParameter=system.md.device.state[*],cat /sys/block/md*/md/dev-$1/state#А здесь скрипт для обнаружения самих массивов и элементы данных для их мониторинга
UserParameter=system.md.array.discovery,/usr/local/sbin/discovery_md_arrays.py
UserParameter=system.md.array.state[*],cat /sys/block/$1/md/array_state
UserParameter=system.md.sync.state[*],cat /sys/block/$1/md/sync_actionДалее оба скрипта, мне было проще написать их на питоне
2. /usr/local/sbin/discovery_md_arrays.py
#!/usr/bin/python
import os,sysfirst_out = True
f = os.popen( 'ls /sys/block | grep md' )
lines = f.readlines();sys.stdout.write( '{\n\t "data":\n\t[\n' )
for line in lines:
t = line.split()
md_array = t[0]if not first_out:
sys.stdout.write( ',\n' )first_out = False
sys.stdout.write( '\t\t{{ "{{#MD_ARRAY}}": "{0}" }}'.format(md_array) )
sys.stdout.write( '\n\t]\n}' )sys.stdout.write( '\n' )
3. /usr/local/sbin/discovery_md_devices.py
#!/usr/bin/python
import os,sysfirst_out = True
f = os.popen( 'ls /sys/block/md*/md/ | grep dev-' )
lines = f.readlines();sys.stdout.write( '{\n\t "data":\n\t[\n' )
for line in lines:
t = line.split()
md_disk = t[0]
md_disk = md_disk.replace( 'dev-', '' )
if not first_out:
sys.stdout.write( ',\n' )first_out = False
sys.stdout.write( '\t\t{{ "{{#MD_DEVICE}}": "{0}" }}'.format(md_disk) )
sys.stdout.write( '\n\t]\n}' )
sys.stdout.write( '\n' )
P.S. За сумбурность простите, через 20 мин сына будить и в садик везти, zabbix-шаблон сюда не выкладываю, там много букв, xml как ни как.
egrep ".*_.*" /proc/mdstat|wc -l
Тогда уж просто
grep -c _ /proc/mdstat
А как этот failfast конкретно работает? Просветите
это просто термин.
что за кластерные райды в mdadm?