Применимость: Solaris, OmniOS, OpenIndiana
Слова для поиска: fmadm, troubleshooting
Контроль состояния системы с уведомлением о неполадках и т.п.
В Solaris есть встроенная система определения неполадок. Служба svc:/system/fmd:default следит за тем, что вышло из строя и рассылает предупреждения об этом.
В основе этой системы механизм вывода устройств из эксплуатации, позволяющий архитектуре управления процессом устранения отказов (FMA) изолировать устройство как неисправное. Благодаря этой функции возможна автоматическая и безопасная деактивация неисправных устройств в целях недопущения потери или повреждения данных либо аварийного завершения работы и простоя системы. Процесс вывода из эксплуатации выполняется безопасным образом, с учетом обеспечения стабильности системы после отключения устройства.
Критически важные устройства никогда не изымаются из эксплуатации. Если требуется вручную заменить отключенное устройство, после замены устройства в дополнение к процедуре замены устройства вручную следует воспользоваться командой fmadm repair для информирования системы о произведенной замене.
Управление отказами в Solaris обслуживается расширяемым фреймворком, который объединяет в себе обработку всех ошибок. На нижнем уровне, Solaris определяет протокол событий для записи ошибок. Участвующие компоненты (обычно драйверы) создают сообщения об ошибках (ereports) в формате протокола событий, когда что-то идёт не так. Эта информация считывается демоном Fault Management Daemon (FMD).
Демон fmd получает телеметрическую информацию о проблемах, обнаруженных системой, диагностирует эти проблемы и инициирует мероприятия для самовосстановления, например отключение неисправных компонентов.
В консоли будет выведено общее сообщение о выводе устройства из эксплуатации, которое также записывается в файл /var/adm/messages .
Пример:
Aug 9 18:14 starbug genunix: [ID 751201 kern.notice] NOTICE: One or more I/O devices have been retired
Демон FMD рассматривает проблемы на основе сообщений об ошибках и определяет диагноз отказа. Можно считать, что сообщения об ошибках являются симптомами проблемы. Не обязательно есть однозначное соответствие между симптомом и диагнозом. Часто множество ошибок объясняются одним единственным отказом.
FMD представляет собой общий фреймворк для подключаемых модулей. Эти модули реализуют алгоритмы для диагностирования проблем и принятия решений по их исправлению. Существует два типа модулей: средства диагностики и агенты. Средства диагностики определяют проблему, тогда как агенты принимают меры по её устранению или сообщают о ней администратору.
Solaris имеет несколько модулей-агентов, включая следующие:
Каждый случай отказа имеет универсальный идентификатор UUID (Universal Unique Identifier). Случай обычно отвечает одному диагнозу. Каждый диагноз имеет уникальный идентификатор, например ZFS-8000-D3 (http://illumos.org/msg/ZFS-8000-D3) Статьи на этом сайте называются Knowledge Articles.
Команда fmadm предоставляет администратору контроль над FMD. Наиболее полезной опцией является faulty, которая выводит ресурсы, которые на данный момент работают неправильно.
Вы можете использовать fmadm config для вывода списка загруженных модулей:
fmadm config MODULE VERSION STATUS DESCRIPTION cpumem-retire 1.1 active CPU/Memory Retire Agent disk-transport 1.0 active Disk Transport Agent eft 1.16 active eft diagnosis engine ext-event-transport 0.2 active External FM event transport fabric-xlate 1.0 active Fabric Ereport Translater fmd-self-diagnosis 1.0 active Fault Manager Self-Diagnosis io-retire 2.0 active I/O Retire Agent sensor-transport 1.1 active Sensor Transport Agent ses-log-transport 1.0 active SES Log Transport Agent software-diagnosis 0.1 active Software Diagnosis engine software-response 0.1 active Software Response Agent sysevent-transport 1.0 active SysEvent Transport Agent syslog-msgs 1.1 active Syslog Messaging Agent zfs-diagnosis 1.0 active ZFS Diagnosis Engine zfs-retire 1.0 active ZFS Retire Agent
Команда fmadm позволяет вам вручную загружать и выгружать модули и производить другие действия с FMD. Обычно вам это не понадобится; если же такая необходимость возникла, обратитесь к документации fmadm(1M).
Для проверки текущего состояния системы нужно выполнить команду
fmadm faulty
Пример обнаруженной ошибки:
--------------- ------------------------------------ -------------- ---------
TIME EVENT-ID MSG-ID SEVERITY
--------------- ------------------------------------ -------------- ---------
мая 09 14:37:00 93118f23-acd4-e212-d73b-df6636a90000 ZFS-8000-D3 Major
Host : ad999
Platform : X9DRE-TF+-X9DR7-TF+ Chassis_id : 0123456789
Product_sn :
Fault class : fault.fs.zfs.device
Affects : zfs://pool=abd54ca08636cc03/vdev=4435daa62c7fbe00
out of service, but associated components no longer faulty
Problem in : zfs://pool=abd54ca08636cc03/vdev=4435daa62c7fbe00
not present
Description : A ZFS device failed. Refer to http://illumos.org/msg/ZFS-8000-D3
for more information.
Response : No automated response will occur.
Impact : Fault tolerance of the pool may be compromised.
Action : Run 'zpool status -x' and replace the bad device.
Сообщение содержит информацию о конкретном устройстве или службе:
--------------- ------------------------------------ -------------- ---------
TIME EVENT-ID MSG-ID SEVERITY
--------------- ------------------------------------ -------------- ---------
июн 03 09:29:47 942a01c9-7706-e9a9-f509-8cd9e6e011bf SMF-8000-YX major
Host : ad998
Platform : X9DRE-TF+-X9DR7-TF+ Chassis_id : 0123456789
Product_sn :
Fault class : defect.sunos.smf.svc.maintenance
Affects : svc:///application/network/vivaldiframework:MSMFramework
ok and in service
Problem in : svc:///application/network/vivaldiframework:MSMFramework
repair attempted
Description : A service failed - the instance is restarting too quickly.
Refer to http://illumos.org/msg/SMF-8000-YX for more information.
Response : The service has been placed into the maintenance state.
Impact : svc:/application/network/vivaldiframework:MSMFramework is
unavailable.
Action : Run 'svcs -xv
svc:/application/network/vivaldiframework:MSMFramework' to
determine the generic reason why the service failed, the location
of any logfiles, and a list of other services impacted.
В поле Action есть рекомендации по отладке этого сбоя.
Команда fmstat предоставляет статистику модулей обработки отказами:
fmstat module ev_recv ev_acpt wait svc_t %w %b open solve memsz bufsz cpumem-retire 0 0 0,0 0,0 0 0 0 0 0 0 disk-transport 0 0 0,0 1,5 0 0 0 0 32b 0 eft 0 0 0,0 0,0 0 0 0 0 1,3M 0 ext-event-transport 1 0 0,0 0,0 0 0 0 0 46b 0 fabric-xlate 116832 0 0,0 0,4 0 0 0 0 0 0 fmd-self-diagnosis 122 0 0,0 0,0 0 0 0 0 0 0 io-retire 0 0 0,0 0,0 0 0 0 0 0 0 sensor-transport 0 0 0,0 0,1 0 0 0 0 32b 0 ses-log-transport 0 0 0,0 0,1 0 0 0 0 40b 0 software-diagnosis 1 0 0,0 0,1 0 0 0 0 316b 0 software-response 0 0 0,0 0,0 0 0 0 0 316b 0 sysevent-transport 0 0 0,0 3,0 0 0 0 0 0 0 syslog-msgs 0 0 0,0 0,0 0 0 0 0 0 0 zfs-diagnosis 15 0 0,0 21,5 0 0 0 0 0 0 zfs-retire 15 0 0,0 0,3 0 0 0 0 168b 0
Колонка ev_recv показывает число событий, обработанных этим модулей; колонка ev_acpt показывает число принятых (англ.: accepted) событий; и так далее.
Вы можете получить статистику по конкретному модулю при помощи опций -m и -a, как показано ниже:
fmstat -m zfs-diagnosis
NAME VALUE DESCRIPTION
dev_drops 0 ereports dropped (dev during open)
import_drops 0 ereports dropped (during import)
old_drops 7 ereports dropped (from before load)
resource_drops 8 resource related ereports
vdev_drops 0 ereports dropped (weird vdev types)
Или более подробно командой:
fmstat -m zfs-diagnosis -a
Команда fmdump позволяет изучать сообщения об ошибках напрямую из журналов ошибок. fmdump без опций показывает однострочную запись для каждого диагноза ошибки:
fmdump TIME UUID SUNW-MSG-ID Apr 07 16:09:32.1724 c870f49c-d6b9-c3b4-e4ac-d6db0eaf2cc5 ZFS-8000-D3 Apr 11 15:06:09.9541 00ef1a80-6f5f-44cd-ef4f-fb0e7265963c INTEL-8000-PR
Вы можете изучить диагноз для ZFS более детально, указав его UUID с опцией -v:
# fmdump -v -u c870f49c-d6b9-c3b4-e4ac-d6db0eaf2cc5 TIME UUID SUNW-MSG-ID Apr 07 16:09:32.1724 c870f49c-d6b9-c3b4-e4ac-d6db0eaf2cc5 ZFS-8000-D3 100% fault.fs.zfs.device Problem in: zfs://pool=c8e108872ea709c3/vdev=39d1cbdfa50ff878 Affects: zfs://pool=c8e108872ea709c3/vdev=39d1cbdfa50ff878 FRU: - Location: -Заметьте, что этот диагноз также появляется в системном журнале.
Чтобы рассмотреть журнал ошибок, которые привели к отказу, используйте опцию -e:
fmdump -e
Для просмотра всего события, используйте опцию -V. Используйте опцию -c для обозначения конкретного класса событий:
fmdump -V -e -c ereport.fs.zfs.vdev.open_failed
В этом примере используется опция -e для поиска только тех ошибок, которые являлись частью конкретной проблемы:
fmdump -e -t 15:06 TIME CLASS Apr 11 15:06:08.9454 ereport.cpu.intel.l0icache_uc Apr 11 15:06:09.9499 ereport.cpu.intel.l0icache_uc Apr 11 15:06:10.9597 ereport.cpu.intel.l0icache_uc
Для подробного вывода используйте опцию -V.
Для определения конкретных выведенных из эксплуатации устройств можно воспользоваться командой prtconf.
Пример:
# prtconf
.
.
.
pci, instance #2
scsi, instance #0
disk (driver not attached)
tape (driver not attached)
sd, instance #3
sd, instance #0 (retired)
scsi, instance #1 (retired)
disk (retired)
tape (retired)
pci, instance #3
network, instance #2 (driver not attached)
network, instance #3 (driver not attached)
os-io (driver not attached)
iscsi, instance #0
pseudo, instance #0
Подробнее можно будет изучить информацию в выводе команды:
prtconf -v | less
После устранения неисправности выполните сброс отказа командой:
fmadm repair <EVENT-ID>
Затем снова выполните команду fmadm faulty для подтверждения сброса отказа. Если все прошло успешно, то информация об отказе отображаться не будет. Увидеть все отказы, актуальные и сброшенные можно командой fmadm faulty -a
Для этого нужно будет поставить и настроить службу уведомлений fmadm командами:
pkg install service/fault-management/smtp-notify
После установки надо указать куда слать уведомления (на alerts3@colobridge.net)
svccfg setnotify problem-diagnosed mailto:alerts3@colobridge.net
Проверить текущие значения:
svccfg listnotify problem-diagnosed
Event: problem-diagnosed (source: svc:/system/fm/notify-params:default)
Notification Type: smtp
Active: true
reply-to: root@localhost
to: alerts3@colobridge.net
Notification Type: snmp
Active: true
Notification Type: syslog
Active: true
Актуальность: 2013/07/08 16:46