механизм определения неполадок fmadm

Применимость: 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

FMD представляет собой общий фреймворк для подключаемых модулей. Эти модули реализуют алгоритмы для диагностирования проблем и принятия решений по их исправлению. Существует два типа модулей: средства диагностики и агенты. Средства диагностики определяют проблему, тогда как агенты принимают меры по её устранению или сообщают о ней администратору.

Solaris имеет несколько модулей-агентов, включая следующие:

  • cpumem-retire и io-retire: агенты CPU/Memory Retire и I/O Retire отвечают за отключение отказавшего оборудования.
  • syslog-msgs: записывает диагноз ошибки в системный лог
  • snmp-trapgen: создаёт SNMP trap
  • zfs-retire: агент ZFS Retire заботится об автоматическом восстановлении ZFS.

База знаний ошибок

Каждый случай отказа имеет универсальный идентификатор UUID (Universal Unique Identifier). Случай обычно отвечает одному диагнозу. Каждый диагноз имеет уникальный идентификатор, например ZFS-8000-D3 (http://illumos.org/msg/ZFS-8000-D3) Статьи на этом сайте называются Knowledge Articles.

fmadm

Команда 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 предоставляет статистику модулей обработки отказами:

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 без опций показывает однострочную запись для каждого диагноза ошибки:

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.

Пример:

# 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

Уведомления на email

Для этого нужно будет поставить и настроить службу уведомлений 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

Смотрите также: