Архив метки: monitoring

Debian: Установка и настройка NET-SNMP

http://pro-voip.com.ua net-snmpЗдесь все манипуляции проводятся на Debian Wheezy.

Установка net-snmp

root@deb# apt-get install snmp snmpd

snmp — SNMP (Simple Network Management Protocol) applications
snmpd — SNMP (Simple Network Management Protocol) agents

snmpd.conf — конфигурационный файл для Net-SNMP SNMP агента.

Редактируем файл /etc/snmp/snmpd.conf:

root@deb# nano /etc/snmp/snmpd.conf

Рестартуем демон snmpd:

root@deb# service snmpd restart

Проверяем (например):

root@deb# snmpwalk -v2c -c public localhost

Контроль доступа к snmpd можно организовать двумя способами:

  • Traditional Access Control — традиционный контроль доступа
  • VACM Configuration — View-Based Access Control Model

 

SNMPv1 и SNMPv2c

 

Традиционный контроль доступа

Создание read-only и read-write community:

rocommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
rwcommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]

Создать read-only комьюнити с именем public, дать доступ ко всему дереву OID’ов, не ограничивая доступ к snmpd:

rocommunity public

Создать read-only комьюнити с именем public, дать доступ ко всему дереву OID’ов, разрешив доступ к snmpd только localhost:

rocommunity public localhost

Создать read-only комьюнити public, разрешить доступ с localhost’а к ветке .1.3.6.1.2.1.1:

rocommunity public localhost .1.3.6.1.2.1.1

Если нам нужно объединить несколько разных веток дерева OID’ов для одного community, используем именованые «view»:

view systemview included .1.3.6.1.2.1.1
view systemview included .1.3.6.1.2.1.2

rocommunity public localhost -V systemview

Если нужна более гибкое управление доступом к SNMP, следует использовать другую модель управления — VACM.

 

Контроль доступа VACM

Для того, чтобы настроить доступ к snmpd по модели VACM, необходимо определить 4 директивы:

  • com2sec
  • group
  • view
  • access

com2sec определяет некое имя (security name), к нему привязываются ip-адрес и комьюнити, с которыми можно получить доступ к snmpd:

com2sec  [-Cn CONTEXT] SECNAME SOURCE COMMUNITY

SECNAME — security name;
SOURCE — имя хоста, ip-адрес хоста, или подсеть в формате ip/mask, с которого разрешен доступ к snmpd;
COMMUNITY — строка community;
CONTEXT — используется в SNMPv3

group определяет группу, к которой привязываются ранее созданные secname:

group GROUP {v1|v2c|usm|tsm|ksm} SECNAME

view определяет ветки дерева MIB, к которым будем давать доступ:

view VNAME TYPE OID [MASK]

VNAME — произвольное имя вьюшки. Имена могут повторятся, таким образом создается вьюшка в набором «веток» дерева OID’ов;
TYPE — included или excluded — действие: включить или исключить ветку с view;
OID — определенный OID или ветка;

access даем ранее созданной группе права на доступ к просмотру/записи определенной вьюшки — связка group — view:

access GROUP CONTEXT {any|v1|v2c|usm|tsm|ksm} LEVEL PREFX READ WRITE NOTIFY

GROUP — имя группы, определенное в шаге 2;
CONTEXT — default context —  «»

Пример:

«Пользователь» local — это пользователь локалхоста с комьюнити secret33, который входит в группу rwgroup. Пользователи группы rwgroup имеют read-write права на view с названием all. Вьюшке all соответствует дерево .1.

«Пользователь» rouser1 может получить доступ с сети 10.10.10.0/24, а «пользователь» rouser2 — с ip-адреса 11.11.11.11/32. Комьюнити — public. «Пользователи» rouser1 и rouser2 входят в группу rogroup. Группа rogroup имеет read-only права на view с названием systemview, в которую входят такие ветки дерева — 1.3.6.1.2.1.1, 1.3.6.1.2.1.2, 1.3.6.1.2.1.25:

###############################################################################
# Access Control - VACM
###############################################################################

####
# First, map the "community name" into a "security name"
#          sec.name    source            community
com2sec    local       localhost         secret33
com2sec    rouser1     10.10.10.0/24     public
com2sec    rouser2     11.11.11.11/32    public

####
# Second, map the "security name" into a "group name":
#        groupName    securityModel    securityName
group    rwgroup      v2c              local
group    rogroup      v2c              rouser1
group    rogroup      v2c              rouser2

####
# Third, create a view for us to let the group have rights to:
#       name          incl/excl   subtree             mask(optional)
view    all           included    .1
view    systemview    included    .1.3.6.1.2.1.1
view    systemview    included    .1.3.6.1.2.1.2
view    systemview    included    .1.3.6.1.2.1.25

####
# Finally, grant the groups access to the view:
#         group        context    sec.model    sec.level    prefix    read            write    notif
access    rwgroup      ""         any          noauth       exact     all             all      none
access    rogroup      ""         any          noauth       exact     systemview      none     none

# -----------------------------------------------------------------------------

 

SNMPv3

 

В SNMPv3 главным действующим «лицом» выступает не community, а user. Поэтому перед манипуляциями с контролем доступа, нужно сначала создать пользователя. При создании пользователя, мы также определяем уровень безопасности.

В SNMPv3 предусмотрено три уровня безопасности:

  • noAuthNoPriv — без аутентификации, без шифрования
  • authNoPriv — с аутентификацией (SHA|MD5), без шифрования
  • authPriv — с аутентификацией (SHA|MD5),с шифрованием (DES|AES)

Тип аутентификации — MD5 или SHA; Алгоритм шифрования — DES или AES;
SHA-аутентификация и DES/AES-шифрование используют OpenSSL — OpenSSL должен быть установлен, snmpd должен иметь поддержку OpenSSL.

Узнать, с какими опциями был собран net-snmp можно с помощью следующей команды:

root@deb# net-snmp-config --configure-options

Если —with-openssl в выводе есть, значит net-snmp собран с поддержкой openssl, если кто не догадался.

MD5 не использует OpenSSL.

 

Создание пользователя snmpv3

Для этого используется следующая команда:

net-snmp-config  —create-snmpv3-user [-ro] [-A authpass] [-X privpass] [-a MD5|SHA] [-x DES|AES] [username]

Минимальная длина authpass и privpass — 8 символов.

Сначала останавливаем демон snmpd:

root@deb# service snmpd stop

Затем создаем пользователя, например, rouserv3:

root@deb# net-snmp-config --create-snmpv3-user -ro -A testtest -X testtest -a MD5 -x DES rouserv3
adding the following line to /var/lib/snmp/snmpd.conf:
   createUser rouserv3 MD5 "testtest" DES testtest
adding the following line to /usr/share/snmp/snmpd.conf:
   rouser rouserv3

При этом создается 2 записи в двух дефолтных конфигурационных файлах, о чем и пишет net-snmp-config в своем выводе. Если вы, не запуская snmpd, посмотрите на файл /var/lib/snmp/snmpd.conf, то в конце файла вы действительно увидите там строку «createUser rouserv3 MD5 «testtest» DES testtest». При запуске демона snmpd эта строка удаляется, появляется вместо нее ключ.

Запись «rouser rouserv3» в файле /usr/share/snmp/snmpd.conf — это настройка контроля доступа. Мало ведь создать пользователя, нужно дать ему какие-то права. Запись «rouser rouserv3» можно перенести в /etc/snmp/snmpd.conf (что я и делаю), а дальше использовать либо традиционный контроль доступа (оставив эту строку «rouser rouserv3»), либо VACM (по аналогии, как это настраивалось выше с SNMPv2c, только там были rocommunity и rwcommunity, а здесь rouser и rwuser).

 

Традиционный контроль доступа

Создание read-only и read-write-пользователя:

rouser USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]
rwuser USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]

noauth, auth, priv — помним про три уровня безопасности? было описано выше. Как по мне, так тут не хватает опции SOURCE, как в варианте в SNMP v1 и v2c с комьюнити. Для ограничения доступа с определенных ip-адресов нужно будет использовать фаервол. Ну и дальше примеры.

Дать пользователю rouser1 read-only права на ветку .1.3.6.1.2.1.1, без аутентификации и без шифрования:

rouser    rouser1    noauth    .1.3.6.1.2.1.1

Проверка:

root@deb# snmpwalk -v3 -u rouser1 -l noAuthNoPriv localhost

Дать пользователю rouser1 read-only права на ветку .1.3.6.1.2.1.1, с аутентификацией, но без шифрования:

rouser    rouser1    auth    .1.3.6.1.2.1.1

Проверка:

root@deb# snmpwalk -v3 -u rouser1 -l authNoPriv -a MD5 -A testtest localhost

Дать пользователю rouser1 read-only права на ветку .1.3.6.1.2.1.1, с аутентификацией и с шифрованием:

rouser    rouser1    priv    .1.3.6.1.2.1.1

Проверка:

root@deb# snmpwalk -v3 -u rouser1 -l authPriv -a MD5 -A testtest -x DES -X testtest localhost

 

Контроль доступа VACM

В варианте с SNMP v1 и v2c для настройки VACM нужно было использовать 4 директивы: com2sec, group, view и access. В варианте с SNMP v3 — только три, com2sec использовать не нужно, у нас уже создан snmpv3-пользователь (он уже и есть «security name»), которого можно добавить в группу.

###############################################################################
# Access Control - VACM for SNMPv3
###############################################################################

####
# First, создаем snmpv3-пользователей, как было описано выше.

####
# Second, map the "security name" into a "group name":
#        groupName    securityModel    securityName
group    rwgroup      usm              rwuser1
group    rogroup      usm              rouser1

####
# Third, create a view for us to let the group have rights to:
#       name          incl/excl   subtree             mask(optional)
view    all           included    .1
view    systemview    included    .1.3.6.1.2.1.1
view    systemview    included    .1.3.6.1.2.1.2
view    systemview    included    .1.3.6.1.2.1.25

####
# Finally, grant the groups access to the view:
#         group        context    sec.model    sec.level    prefix    read            write    notif
access    rwgroup      ""         any          noauth       exact     all             all      none
access    rogroup      ""         any          priv         exact     systemview      none     none

Отличие от настройки VACM в SNMP v1 и v2c — это указание securityModel — usm в директве group и указани sec.level в директиве access (sec.level может быть noauth, auth или priv)

snmpwalk

Опрос оборудования с помощью утилиты snmpwalk для SNMPv3:

# snmpwalk -v3 -l authPriv -u username-SNMPv3 -a SHA -A authpassword -x AES -X encryptionpassword 10.10.10.10

Debian: Как узнать температуру процессора?

http://pro-voip.com.ua debianlm-sensors — набор утилит для считывания значений датчиков температуры, вольтажа и оборотов куллеров. С помощью этих утилит можно ответить себе на вопрос «Какая сейчас температура у моего процессора?» Итак, что мы делаем…

1.Устанавливаем lm-sensors:

apt-get install lm-sensors

2. Определяем наличие датчиков в системе:

sensors-detect

3. Догружаем недостающие драйвера:

modprobe <недостающие модули>

4. И все, смотрим значения датчиков:

sensors

 

Установка lm-sensors на Debian Wheezy

root@deb# apt-cache search lm-sensors
...
lm-sensors - utilities to read temperature/voltage/fan sensors
...
root@deb# apt-get install lm-sensors

 

Определение датчиков в системе

Перед запуском команды sensors для считывания показаный с датчиков, нужно сначала определить, какие есть датчики в системе, и указать, показания каких из датчиков мы хотим увидеть в выводе команды sensors. С этим нам поможет утилита sensors-detect. Это интерактивная программа, запускаем ее на выполнение, читаем и отвечаем на вопросы. Рекомендуется оставить ответы по умолчанию (по умолчанию ответ Yes, просто нажимаем Enter)

root@deb# sensors-detect
# sensors-detect revision 6031 (2012-03-07 17:14:01 +0100)
# System: Supermicro X8SIL [0123456789]

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): yes
Module cpuid loaded successfully.
Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   No
AMD Family 10h thermal sensors...                           No
AMD Family 11h thermal sensors...                           No
AMD Family 12h and 14h thermal sensors...                   No
AMD Family 15h thermal sensors...                           No
AMD Family 15h power sensors...                             No
Intel digital thermal sensor...                             Success!
(driver `coretemp')
Intel AMB FB-DIMM thermal sensor...                         No
VIA C7 thermal sensor...                                    No
VIA Nano thermal sensor...                                  No
...

Вывод дальнейший опущен, но, думаю, и так все понятно. Например, здесь был найден «Intel digital thermal sensor«, для которого необходимо будет догрузить драйвер coretemp.

...
To load everything that is needed, add this to /etc/modules:
#----cut here----
# Chip drivers
coretemp
jc42
w83627ehf
#----cut here----
If you have some drivers built into your kernel, the list above will
contain too many modules. Skip the appropriate ones!

Do you want to add these lines automatically to /etc/modules? (yes/NO)Y
Successful!

В конце своей работы sensors-detect укажет, какие драйвера необходимы и предложит их добавить в /etc/modules, чтобы они автоматически подгружались при загрузке/перезагрузке системы. Соглашаемся. Но нужно проверить, есть ли у вас эти модули вообще.

Подгружаем недостающие модули

root@deb# modprobe coretemp
root@deb# modprobe jc42
FATAL: Module jc42 not found.
root@deb# modprobe w83627ehf

jc42 — не найден, скорее всего, нужно обновить ядро… jc42 нужен для считывания данных темературного сенсора ST STTS2002 DIMM. Обновиться я сейчас не могу, а какая температура памяти как-то не особо важно, поэтому просто уберу его с /etc/modules

Просмотр значений

Вывод всех значений:

root@deb# sensors

Посмотреть значения датчиков в сыром неотформатированном виде:

root@deb# sensors -u

 

Viel Spaß!

Monitord: Автоматический перезапуск демона

freebsd2В мире постоянно работающих систем с «слушающими» отзывчивыми демонами, бывает, случается неприятность — в силу каких-либо причин демон перестает быть отзывчивым и прекращает свою работу. В итоге получаем неработающий сервис. Неприятность может застать нас в любое время и в любом месте. И даже если предусмотрительно настроенная нами система мониторинга шлет  об этом тревожные письма и смс, побуждая к вполне закономерным действиям — сделать сервису start и разбираться, что случилось, — не всегда есть для того возможности. Банально, может не быть никаких «электронно-вычислительных машин» под рукой.

Делаем выводы с вышесказанного и решаем, что нужно «что-то», что будет следить за демонами и стартовать их автоматически, если те прикажут долго жить*. Кто-то для таких целей пишет свой скрипт и кидает его в cron, кто-то пользуется готовыми решениями, настраивая их под себя. Одним из таких решений и есть monitord — не самое лучшее, корявое, но, на мой взгляд, самое простое и лично мне подходящее.

 

Установка

На текущую дату — 07.04.2015 — порт monitord помечен как Broken:

# cd /usr/ports/sysutils/monitord
# make config
===> No options to configure

# make install
===> monitord-0.4.1_3 is marked as broken: No public distfiles.
*** Error code 1

Stop.
make: stopped in /usr/ports/sysutils/monitord

Игнорируем этот факт и все-таки устанавливаем порт (запускаем make с ключом -D, устанавливая переменную NO_IGNORE):

# make -DNO_IGNORE install clean

...

=============================================================
Monitord requires procfs(5). Add this line to your fstab(5):
proc /proc procfs rw 0 0
=============================================================

===>&nbsp; Cleaning for monitord-0.4.1_3

 

После установки в системе появляются 3 файла:

  • /usr/local/etc/rc.d/monitord — стартовый скрипт;
  • /usr/local/sbin/monitord — бинарник;
  • /usr/local/etc/monitord.conf.sample — пример конфигурационного файла.

 

Структура конфигурационного файла

/usr/local/etc/monitord.conf.sample:

############################################################################
############################################################################
##
## Monitord Configuration file
##
############################################################################
############################################################################

# You MUST set your email address and the email server to use when sending
# out notices. It will be used if you use the "alert" option below.

email = this@is.your.email.address
smtp-server = this@is.your.email.server

# When specifying options, make sure that they are comma-separated and do NOT
# have any spaces.
#
# user options delay service start script parameters

#root auto,alert 10 inetd   /usr/sbin/inetd -wW
#root auto       10 syslogd /usr/sbin/syslogd
#root auto       10 cron    /usr/sbin/cron
#root auto       20 httpd   /usr/local/etc/rc.d/apache.sh
#root auto,alert 10 sshd    /usr/local/sbin/sshd

 

Одна строка в conf-файле отвечает за один сервис, и поделена на 6 столбцов:

  • user — от имени какого пользователя производить запуск;
  • options — как реагировать, если сервис потух:

auto —  запускать сервис автоматически;
alert — отсылать письмо на почту об инциденте (здесь у меня возникли проблемы, ниже опишу какие);
noauto — не запускать сервис автоматически (имеет смысл при указании этой опции вместе с опцией alert — т.е. просто для уведомлений);

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

  • delay — задержка запуска (секунды);
  • service — имя сервиса;
  • script — скрипт запуска сервиса;
  • parameters — аргументы, передаваемые скрипту запуска.

 

Настройка и запуск

Создаем или копируем с monitord.conf.sample конфигурацинный файл monitord.conf:

# cd /usr/local/etc/
# cp monitord.conf.sample monitord.conf
# ee monitord.conf

Например, для мониторинга apache24, по образу и подобию добавляем строку:

root auto 10 httpd    /usr/local/sbin/apache24 start

Добавляем monitord в автозагрузку и запускаем:

# ee /etc/rc.conf

# MONITORD
monitord_enable="YES"

# /usr/local/etc/rc.d/monitord start

 

Проблемы с отправкой уведомлений

При использовании опции alert необходимо предварительно указать, через что эти алерты слать. Monitord предлагает указать только email получателя и MTA, который доставит alert-письмо этому получателю:

email = admin@provoip.in.ua
smtp-server = mx.provoip.in.ua

К сожалению, править какие-то другие заголовки для отправки уведомлений нельзя. И если уже с неменяемой темой и телом пиcьма смириться можно, то критично важно было бы отредактировать адрес отправителя, потому как сам Monitord туда подставляет следующее:

monitord-notification@www, где www — это у меня имя хоста.

А мой МТА настроен на проверку адреса-отправителя и получив от monitord такое вот письмо, отказывается его дальше передавать:

sender verify fail for <monitord-notification@www>: Unrouteable address

Лично для меня это не критично, поскольку уведомлениями занимается нагиос. Alert’ы я отключаю и пользуюсь только возможностью слежки за демонами и их автоматического старта/рестарта.

HDD: Smartmontools

! Работает с жесткими дисками, которые поддерживают технологию SMART !

smartmontools состоит из двух утилит:

  • smartctl — (Control and Monitor Utility for SMART Disks) — так сказать, интерактивная часть;
  • smartd — (SMART Disk Monitoring Daemon) — демон.

 

smartctl

Справка smartctl:

smartctl -h

Сканировать и вывести список дисков и их тип:

smartctl --scan

Получить информацию о диске, такую как модель, серийный номер:

smartctl -i /dev/ada0

Краткая общая информация о здоровье диска:

smartctl -H /dev/ada0

Посмотреть всю информацию об устройстве:

smartctl -x /dev/ada0

Посмотреть всю SMART-информацию:

smartctl -a /dev/ada0

Посмотреть SMART-атрибуты диска:

smartctl -A /dev/ada0

 

SMART-тесты

Работа с тестами самодиагностики.

В один момент времени может выполняться только один тест. Тесты не пересекаются с деятельностью диска, поэтому можно их запускать на рабочей системе.

Запуск короткого теста (длится пару минут):

smartctl -t short /dev/ada0

Запуск длинного теста (десятки минут, до часа):

smartctl -t long /dev/ada0

Отменить тест:

smartctl -X

Просмотр результата теста:

smartctl -l selftest /dev/ada0

 

SMART-атрибуты
# smartctl -A /dev/ada0

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   100   253   021    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       1
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       121
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       1
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       0
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       2
194 Temperature_Celsius     0x0022   111   109   000    Old_age   Always       -       32
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

Поля атрибутов SMART

ID — идентификатор атрибута, однозначно определяет атрибут.
ATTRIBUTE_NAME — имя атрибута, расшифровка ID.
VALUE — текущее значение атрибута. Чем меньше — тем хуже. Измеряется в «попугаях». Сравнивается со значением TRESHOLD:

  • VALUE > TRESHOLD — диск считает, что он здоров;
  • VALUE < или = TRESHOLD  — бьем тревогу;
  • VALUE не достиг уровня TRESHOLD, но упорно уменьшается — атрибут деградирует — тоже пора задуматься о замене диска.

WORST — наихудшее значение VALUE атрибута за всю жизнь диска. Измеряется в «попугаях».
TRESHOLD — пороговое (критическое) значение VALUE для атрибута. Измеряется в «попугаях».
TYPE — тип атрибута:

  • Pre-fail — критичный
  • Old_age — некритичный

WHEN_FAILED — «когда выйдет из строя»:

  • «FAILED_NOW» — опасно;
  • » — » — с атрибутом все в порядке.

RAW_VALUE — реальное значение атрибута (не в «попугаях») — в зависимости от атрибута значение:

  • текущее (например, температура -Temperature_Celsius);
  • накапливающее (какой-либо счетчик, например, Power_Cycle_Count).

VALUE вычисляется исходя из RAW_VALUE по определенным алгоритмам, которые задает производитель.

Атрибуты SMART

* жирным шрифтом выделены атрибуты, требующие особого внимания

  • (1) Raw_Read_Error_Rate — содержит частоту возникновения ошибок при чтении с диска по вине аппаратной части накопителя;
  • (3) Spin_Up_Time — содержит время разгона шпинделя диска из состояния покоя до номинальной скорости (например, от 0 до 7200 об/мин);
  • (4) Start_Stop_Count — полное число запусков/остановов диска;
  • (5) Reallocated_Sector_Ct — содержит кол-во секторов, переназначенных диском в резервную область — операция Remapping — считаются только удачные попытки. Ключевой параметр в оценке состояния диска;
  • (7) Seek_Error_Rate — частота появления ошибок позиционирования БМГ; указывает на проблемы в механике диска;
  • (9) Power_On_Hours — число часов проведенных во включенном состоянии (накапливающий);
  • (10) Spin_Retry_Count — число попыток старта шпинделя диска, если первая попытка была неудачной;
  • (11) Calibration_Retry_Count — число попыток рекалибровки накопителя — сброс состояния диска и установка головок на нулевую дорожку;
  • (12) Power_Cycle_Count — число полных циклов включения-отключения диска;
  • (192) Power-Off_Retract_Count — для разных винчестеров либо суммарное кол-во парковок БМГ в аварийных ситуациях, либо суммарное кол-во включения-выключения питания диска (в WD, Hitachi);
  • (193) Load_Cycle_Count — кол-во полных циклов парковки БМГ;
  • (194) Temperature_Celsius — температура диска;
  • (196) Reallocated_Event_Count — кол-во операций переназначения — Remapping — учитываются удачные и неудачные попытки;
  • (197) Current_Pending_Sector — текущее кол-во нестабильных секторов — кандидаты на Remapping;
  • (198) Offline_Uncorrectable — параметр изменяется только при offline-тестировании, которое диск запускает при простое; содержит секторы-кандидаты на Remapping;
  • (199) UDMA_CRC_Error_Count — кол-во ошибок при передаче по интерфейсному кабелю в режиме UltraDMA от материнской платы контроллеру диска; Причины — некачественный шлейф, плохой контакт  в SATA-разъеме;
  • (200) Multi_Zone_Error_Rate — частота появления ошибок при записи данных;

 

smartd

Конфигурационный файл:

/usr/local/etc/smartd.conf

Автоматическое сканирование системы в поисках ATA и SCSI:

DEVICESCAN

может запускаться с набором нужных директив, которые будут применены ко всем найденым дискам. Например:

DEVICESCAN -I 194 -I 231 -I 9

Описание директив конфигурационного файла smartd можно найти в smartd.conf.sample и в ‘man smartd.conf’.

Многие люди предпочитают вручную указывать диски, которые хочется мониторить. Для этого необходимо закоментировать DEVICESCAN и указать диски.

Пример:

/dev/ada0 -a -o on -S on -s (S/../.././02|L/../../6/03) -I 194 -W 4,45,55 -R 5 -m admin@provoip.in.ua
/dev/ada1 -a -o on -S on -s (S/../.././02|L/../../6/03) -I 194 -W 4,45,55 -R 5 -m admin@provoip.in.ua

В данном примере указаны два жестких диска — ada0 и ada1. Используемые директивы:

-a Default: то же, что и набор директив «-H -f -t -l error -l selftest -C 197 -U 198»:

-H — мониторинг SMART Health Status, сообщает если статус FAILED;
-f  — мониторинг на ошибки (FAILED) любого из используемых атрибутов (поле SMART-атрибута WHEN_FAILED);
-t — то же, что и набор директив «-p -u»:

-p рассказывать об изменениях в «Pre-fail»-атрибутах;
-u рассказывать об изменениях в «Old_age»-атрибутах;

-l error — мониторить SMART-логи error;
-l selftest — мониторить SMART-логи selftest;

-C 197 — «197» — это ID атрибута — RAW_VALUE Current_Pending_Sector — сообщать при ненулевом значении;
-U 198 — «198» — это ID атрибута — RAW_VALUE Offline_Uncorrectable — сообщать при ненулевом значении;

-o on — enable автоматические offline-тесты;
-S on — enable attribute autosave;

-s (S/../.././02|L/../../6/03) — стартовать selftest’ы, когда выполняется регулярное выражение. В данном примере заданы несколько выражений, разделенных условием «или», поэтому ставим круглые скобки.

Регулярное выражение представляет собой следующую конструкцию:
T/MM/DD/d/HH
T — тип теста — Short, Long, Conveyance или Offline, MM — месяц, DD — день, d — день недели, HH — час.
S/../.././02 — запускать короткий (S) тест каждый день после 2-х часов ночи;
L/../../6/03 — запускать длинный (L) тест каждую субботу (день недели — 6) после 3-х часов ночи.

-I 194 — игнорировать изменения атрибута 194 — Temperature_Celsius;
-W 4,45,55 — мониторинг изменения температуры на 4 градуса, 45 — informal лимит, 55 — критический лимит;
-R 5 — отследить изменения в атрибуте 5 — Reallocated_Sector_Ct;

-m admin@provoip.in.ua — отправить warning email на admin@provoip.in.ua для -H, -l error, -l selftest, и -f

Другие директивы для smartd.conf:

* взято из /usr/local/etc/smartd.conf.sample

 -d TYPE Set the device type: ata, scsi, marvell, removable, 3ware,N, hpt,L/M/N
 -T TYPE set the tolerance to one of: normal, permissive
 -o VAL Enable/disable automatic offline tests (on/off)
 -S VAL Enable/disable attribute autosave (on/off)
 -n MODE No check. MODE is one of: never, sleep, standby, idle
 -H Monitor SMART Health Status, report if failed
 -l TYPE Monitor SMART log. Type is one of: error, selftest
 -f Monitor for failure of any 'Usage' Attributes
 -m ADD Send warning email to ADD for -H, -l error, -l selftest, and -f
 -M TYPE Modify email warning behavior (see man page)
 -s REGE Start self-test when type/date matches regular expression (see man page)
 -p Report changes in 'Prefailure' Normalized Attributes
 -u Report changes in 'Usage' Normalized Attributes
 -t Equivalent to -p and -u Directives
 -r ID Also report Raw values of Attribute ID with -p, -u or -t
 -R ID Track changes in Attribute ID Raw value with -p, -u or -t
 -i ID Ignore Attribute ID for -f Directive
 -I ID Ignore Attribute ID for -p, -u or -t Directive
 -C ID Report if Current Pending Sector count non-zero
 -U ID Report if Offline Uncorrectable count non-zero
 -W D,I,C Monitor Temperature D)ifference, I)nformal limit, C)ritical limit
 -v N,ST Modifies labeling of Attribute N (see man page)
 -a Default: equivalent to -H -f -t -l error -l selftest -C 197 -U 198
 -F TYPE Use firmware bug workaround. Type is one of: none, samsung
 -P TYPE Drive-specific presets: use, ignore, show, showall
# Comment: text after a hash sign is ignored
# \ Line continuation character
# Attribute ID is a decimal integer 1 <= ID <= 255
# except for -C and -U, where ID = 0 turns them off.
# All but -d, -m and -M Directives are only implemented for ATA devices
#
# If the test string DEVICESCAN is the first uncommented text
# then smartd will scan for devices /dev/hd[a-l] and /dev/sd[a-z]
# DEVICESCAN may be followed by any desired Directives.

 

Sources:

man smartctl
man smartd.conf
http://www.ixbt.com/storage/hdd-smart-testing.shtml
http://rtfm.co.ua/s-m-a-r-t-proverka-hdd-opisanie-atributov-znachenie-atributov-utility-parametry/
http://www.wandmagic.ru/news/178.html
http://www.lexpr.ru/node/336