Мониторинг параметров smart

[Jimson]

Слажали вы когда не захотели доку прочитать.

HDA и HDA[] разные ключи вообще то, объявлять ключ с параметрами надо как HDA[*] и к параметрам обращаться как $1 $2 и тд

во вторых скрипт должен вернуть ОДНО значение, и ничего больше, вывод smartctl.exe вам прийдется чем то парсить

делать "& echo" не надо, выйдет лажа, возможно в итем будет возвращаться всегда exitcode, а не то что вы ожидаете, впрочем см. выше про значение пользовательского скрипта и про документацию

[Sergeylo]

>C:\Program Files\
>smartctl.exe
>/dev/sda
О, боги, мне страшно.
Предыдущий оратор прав - данные нужно парсить и отдавать в очищенном виде. PowerShell с этой задачей справляется.

[dimugric]

Ну конечно ...
Делал по статейке http://dyrik.ru/bez-rubriki/zabbix-m...s-m-a-r-t.html (как раз об этом вы и говорите)
однако, не вышло ничего, потому и устрашил многоуважаемого Sergeylo

[Egor4ik]

С видами на Обнаружение

Предлагаю возобновить общение в данной ветке по поводу мониторинга винчестеров с помощью SMART.

Начнём с входных данных:
1) Zabbix v 2.0.X
2) Админ - очень ленивый, и забивать руками 80 хардварных хостов не станет.
3) Программа для мониторинга smartmontools
4) OS Linux - Zabbix_agent 1.4 - 1.6 - 1.8 - 2.0
5) OS Windows - SNMP

Для детекции винтов придумалось такое правило:

ls -L /dev/disk/by-id/|grep -vE "\-part"

Дальнейшую фильтрацию ввода ожидаю совершать в сервере Zabbix регулярками
Пока что TRUE:
^(scsi|cciss)
всё остальное - виртуальные винчестеры.

Собственно возник вопросец про ваши варианты Хардварных винтов.

И второй вопросец про параметны для мониторинга SMART. Собственно выцапарал из старого 1.8 древние наработки по триггерам:

HDD: Count of reallocated sectors increasing!

{physical-HWnode-template:hddsmart[sda,5].max(60000)}-{physical-HWnode-template:hddsmart[sda,5].min(60000)}>1 | {physical-HWnode-template:hddsmart[sdb,5].max(60000)}-{physical-HWnode-template:hddsmart[sdb,5].min(60000)}>1

Число операций переназначения секторов. Когда диск обнаруживает ошибку чтения/записи, он помечает сектор «переназначенным» и переносит данные в специально отведённую резервную область. Вот почему на современных жёстких дисках нельзя увидеть bad-блоки — все они спрятаны в переназначенных секторах. Этот процесс называют remapping, а переназначенный сектор — remap. Чем больше значение, тем хуже состояние поверхности дисков. Поле raw value содержит общее количество переназначенных секторов.
Рост значения этого атрибута может свидетельствовать об ухудшении состояния поверхности блинов диска.

HDD: Count of remap operations increasing!

{physical-HWnode-template:hddsmart[sda,196].max(36000)}-{physical-HWnode-template:hddsmart[sda,196].min(36000)} >2 | {physical-HWnode-template:hddsmart[sda,196].max(36000)}-{physical-HWnode-template:hddsmart[sda,196].min(36000)}>2

Число операций переназначения. В поле «raw value» атрибута хранится общее число попыток переноса информации с переназначенных секторов в резервную область. Учитываются как успешные, так и неуспешные попытки.

HDD: Count of retry of spin start attempts increasing!

{physical-HWnode-template:hddsmart[sda,10].max(36000)}-{physical-HWnode-template:hddsmart[sda,10].min(36000)} >2 | {physical-HWnode-template:hddsmart[sda,10].max(36000)}-{physical-HWnode-template:hddsmart[sda,10].min(36000)}>2

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

продолжение дальше....

[Egor4ik]

...продолжение

HDD: To many urecoverable r/w errors.

{physical-HWnode-template:hddsmart[sda,198].last(0)}>20 | {physical-HWnode-template:hddsmart[sdb,198].last(0)}>20

Число некорректируемых (средствами диска) секторов. В случае увеличения числа ошибок велика вероятность критических дефектов поверхности и/или механики накопителя.

Писались очень давно на скорую руку, и нет уверенности что они правильно работали. Номерочки смартов смотрите: http://ru.wikipedia.org/wiki/S.M.A.R.T.
Может у кого есть элемены и триггеры свеженькие для мониторинга?

Что я вижу в Windows:
Problem Indicators
1) Failed Recovey Reads
2) SCSI Bus Faults
3) Other timeouts

Failure Indicators
1) Spinup Errors
2) Format Errors
3) Not Ready errors
4) Fail Recovery Writes
5) Aborted Commands
6) Media Failures
7) Hardware Errors
8) Bad Target Errors

Как всё это выдать в SNMP вWindows без малейшего понятия - я Linux админ. Надеюсь найдутся знатоки.

[Egor4ik]

Определились некоторые проблемы с определением типа винчестера, которые привели к некоторым даже результатам:

1) smartctl отказался автоматически обнатуживать тип устройства:

# ls -ls /dev/disk/by-id/
total 0
0 lrwxrwxrwx 1 root root  9 Jun  5 14:16 scsi-SATA_Hitachi_HTS5450100115PB4K061SE3LU4M -> ../../sda


# smartctl -i /dev/disk/by-id/scsi-SATA_Hitachi_HTS5450100115PB4K061SE3LU4M
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Smartctl: please specify device type with the -d option.

Use smartctl -h to get a usage summary

2) Хотя:

# smartctl -i /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model:     Hitachi HTS545016B9A300
Serial Number:    100115PB4K061SE3LU4M
Firmware Version: PBBOC60N
User Capacity:    160,041,885,696 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  Not recognized. Minor revision code: 0x28
Local Time is:    Thu Jun 13 18:21:50 2013 EEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

3) Поэтому готовое обнаружение:

#!/bin/bash 

set -o nounset
/usr/bin/perl <<'EOF'
$first = 1;

print "{\n";
print "\t\"data\":[\n\n";

for (`ls -L /dev/disk/by-id/|grep -v part`)
{
    ($hddid) = m/(\S+)/;
    $hddpath = `/bin/readlink -fn /dev/disk/by-id/$hddid`;
    print "\t,\n" if not $first;
    $first = 0;
    print "\t{\n";
    print "\t\t\"{#HDDPATH}\":\"$hddpath\",\n";
    print "\t\t\"{#HDDID}\":\"$hddid\"\n";
    print "\t}\n";
}
print "\n\t]\n";
print "}\n";
EOF

причина для embeded perl есть.

[v.goncharov]

По поводу обнаружения:

smartctl --scan

Работает и в Win, и в nix

По поводу парсинга выдачи сделал проще.
В агент вписал такие строки:

#S.M.A.R.T.
UserParameter=smarttest[*],sudo smartctl $1 $2
UserParameter=smart.discovery,smartctl --scan

Ну, или для Win:

UserParameter=smart.discovery,"C:\Program Files\smartmontools\bin\smartctl.exe" --scan
UserParameter=smarttest[*],"C:\Program Files\smartmontools\bin\smartctl.exe" $1 $2

На сервере скрипт внешней проверки, в котором есть обнаружение и опрос метрик.
Метрики с сервера запрашиваю вида: zabbix_get -s $HOSTIP -k smarttest["$HDD",-A] и пишу их в кеш.
+ (т.е. если опрос данных раз в 15 минут, то smart запрашивается 1 раз за 15 минут, и данные для всех метрик берутся из этого кеша).
Потом из кеша уже делаю парсинг.

Если интересно - приложу скрипт.

Но огромная просьба!! Помогите с триггерами на S.M.A.R.T.!!! Пытаюсь понять, какие данные туда класть...

[gescheit]

Имхо, в винде можно так-же как в линукс - читать exit status и смотреть какие биты установлены. Это намного проще чем парсить вывод.

[Egor4ik]

По поводу обнаружения:

smartctl --scan

Работает и в Win, и в nix

На такие "Грабли" я уже наступил:

# smartctl --scan
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=======> UNRECOGNIZED OPTION: scan

Use smartctl -h to get a usage summary

По поводу парсинга выдачи сделал проще.
В агент вписал такие строки:

#S.M.A.R.T.
UserParameter=smarttest[*],sudo smartctl $1 $2
UserParameter=smart.discovery,smartctl --scan

Так писать не годится. Просто даже работать не начнёт:

UserParameter=smarttest[*],sudo smartctl $1 $2

нужны полные пути.

UserParameter=smarttest[*],/usr/bin/sudo /usr/sbin/smartctl $1 $2

На сервере скрипт внешней проверки, в котором есть обнаружение и опрос метрик. + внешнюю проверку сделал с кешем (т.е. если опрос данных раз в 15 минут, то smart запрашивается 1 раз за 15 минут, и данные для всех метрик берутся из этого кеша).

Если интересно - приложу скрипт.

Но огромная просьба!! Помогите с триггерами на S.M.A.R.T.!!! Пытаюсь понять, какие данные туда класть...

Аналогично по триггерам, собирать данные не проблема... Скрипт сбора ща будет.

[v.goncharov]

[QUOTE=Egor4ik;133835]На такие "Грабли" я уже наступил:

# smartctl --scan
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=======> UNRECOGNIZED OPTION: scan

Use smartctl -h to get a usage summary

У меня

#smartctl -V
smartctl 5.43 2012-06-30 r3573 [x86_64-linux-3.9.4-1.el6.elrepo.x86_64] (local build)
Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net

Работает "--scan" на всех серверах поголовно (и Win, и Nix)
Проблемы возникли только с RAID Adaptec, но там я вообще до смарта достучаться не смог.


Данные у меня собираются успешно. А вот триггеров пока нет
Да и может, у кого есть опыт, как с этим всем красивый комплексный экран сделать?

[Egor4ik]

Часть сборщика данных по smart

Предположим файл будет называтся /opt/zsmart.sh
zsmart.zip

Ставится в zabbix_agentd.conf:

UserParameter=zsmart[*],/opt/zsmart.sh $1 $2

В /etc/sudoers.d/zabbix:

Cmnd_Alias      SMART = /usr/sbin/smartctl

zabbix ALL=NOPASSWD: SMART

Шаблоны обнаружения в процессе....
Идей как мониторить данные триггерами пока не приходит.

[v.goncharov]

Скрипт обнаружения и опроса метрик
(размещается на zabbix-сервере)

В агенте два ключа, как писалось выше:
smarttest[*],smartctl $1 $2
smart.discovery,smartctl --scan
Больше на стороне проверяемого сервера ничего не требуется, все остальное только на стороне сервера.

В шаблоне одно обнаружение (внешняя проверка), SMART.sh[{HOST.IP}]
Все элементы данных с тем же ключем SMART.sh, но параметры:
SMART.sh[{HOST.IP},{#HDD},METRIC,необязательный параметр на получение RAWdata]

[Egor4ik]

Скрипт обнаружения и опроса метрик
(размещается на zabbix-сервере)

В агенте два ключа, как писалось выше:
smarttest[*],smartctl $1 $2
smart.discovery,smartctl --scan
Больше на стороне проверяемого сервера ничего не требуется, все остальное только на стороне сервера.

В шаблоне одно обнаружение (внешняя проверка), SMART.sh[{HOST.IP}]
Все элементы данных с тем же ключем SMART.sh, но параметры:
SMART.sh[{HOST.IP},{#HDD},METRIC,необязательный параметр на получение RAWdata]

Зачем размещать на сервере обнаружение? Пусть уж лучше конечная нода сама себя детектит, тем более, что в скрипте всё равно запрашиваются данные у агента

На стороне проверяемого сервера ещё требуется настройка sudo, установка smartmontools.

Пожалуй вот тут старые данные:

smarttest[*],smartctl $1 $2
smart.discovery,smartctl --scan

поскольку агент не "пережуёт" многострочный результат.

Опять таки что же делать если smartmontools старый. Решение с --scan не универсальное. Хотя идея про определение поддержки SMART винтом и при условии TRUE добавлении его в автообнаружение понравилась. Только опять таки в случае с --scan не понятно зачем))) и так ведь определена поддержка.

[v.goncharov]

Зачем размещать на сервере обнаружение? Пусть уж лучше конечная нода сама себя детектит, тем более, что в скрипте всё равно запрашиваются данные у агента

На стороне проверяемого сервера ещё требуется настройка sudo, установка smartmontools.

Пожалуй вот тут старые данные:

поскольку агент не "пережуёт" многострочный результат.

Опять таки что же делать если smartmontools старый. Решение с --scan не универсальное. Хотя идея про определение поддержки SMART винтом и при условии TRUE добавлении его в автообнаружение понравилась. Только опять таки в случае с --scan не понятно зачем))) и так ведь определена поддержка.

1. Это низкоуровневое обнаружение. Он просто создает элементы данных для КАЖДОГО жесткого диска. т.е. получается один шаблон и на сервер с одним HDD, и на сервер с 5 HDD.

2. Zabbix-agent отлично передает многостраничные данные. Ему вообще плевать, что передавать. А принимаю я эти данные не заббикс-сервером, а скриптом внешней проверки через zabbix_get. Сделано это для того, чтобы не городить несколько скриптов под разные ОС. Т.е. парсинг осуществляется на стороне сервера.

3. Опция проверки поддержки smart винтом потому, что, например, для массивов raid вывод будет примерно таким:
zabbix_get -s 127.0.0.1 -k 'smart.discovery'
/dev/sda -d scsi # /dev/sda, SCSI device
/dev/csmi1,1 -d ata # /dev/csmi1,1, ATA device
/dev/csmi1,3 -d ata # /dev/csmi1,3, ATA device

При этом /dev/sda ссылается на

=== START OF INFORMATION SECTION ===
Vendor: Intel
Product: Raid 1 Volume

А вот остальные - уже на реальные жесткие диски

[Egor4ik]

1. Это низкоуровневое обнаружение. Он просто создает элементы данных для КАЖДОГО жесткого диска. т.е. получается один шаблон и на сервер с одним HDD, и на сервер с 5 HDD.

2. Zabbix-agent отлично передает многостраничные данные. Ему вообще плевать, что передавать. А принимаю я эти данные не заббикс-сервером, а скриптом внешней проверки через zabbix_get. Сделано это для того, чтобы не городить несколько скриптов под разные ОС. Т.е. парсинг осуществляется на стороне сервера.

3. Опция проверки поддержки smart винтом потому, что, например, для массивов raid вывод будет примерно таким:
zabbix_get -s 127.0.0.1 -k 'smart.discovery'
/dev/sda -d scsi # /dev/sda, SCSI device
/dev/csmi1,1 -d ata # /dev/csmi1,1, ATA device
/dev/csmi1,3 -d ata # /dev/csmi1,3, ATA device

При этом /dev/sda ссылается на


А вот остальные - уже на реальные жесткие диски

Ну окей, не будем углублятся в реализацию мониторинга, а то это может затянутся.

А вот можно мне ваш вывод команды:

ls -L /dev/disk/by-id/ | grep -v part

На сервере с винтами /dev/csmi1 спрятаными за Intel Raid.