Состояние Zabbix SSD, настроенное для обнаружения низкого уровня
Дома я использую Zabbix для мониторинга своих серверов, он имеет множество интересных функций и может быть значительно расширен с помощью параметров пользователя.
В этом посте я расскажу о Low Level Discovery (LLD). Если вас интересует только конечный результат, зайдите в раздел Заключение, вы можете скачать мой шаблон, содержащий все правила!
Обнаружение низкого уровня (LLD)
LLD — это функция для автоматического обнаружения некоторых свойств отслеживаемого хоста и создания элементов, триггеров и графиков.
По умолчанию Zabbix поддерживает три типа обнаружения элементов:
- Монтируемые файловые системы
- Сетевой интерфейс
- OID SNMP
Первые два очень полезны, так как они по умолчанию предоставят вам, например, свободное место каждой смонтированной файловой системы или пропускную способность, входящую и выходящую из каждого сетевого интерфейса. Поскольку я наблюдаю только за серверами Linux, я не использую последний, но в конечном итоге он заинтересует других людей.
Еще одна очень интересная особенность этой функции заключается в том, что вы можете расширить ее, обнаружив больше предметов. В этой статье я покажу, как обнаружить процессоры, ядра и жесткий диск.
Наиболее важной частью пользовательского обнаружения является создание сценария на отслеживаемых машинах, который может «обнаружить» что-то. Это может быть любой исполняемый файл, важно только то, что он выводит данные в правильном формате. Я должен сказать, что формат довольно уродливый, но это, вероятно, не очень важно. Вот вывод моего сценария обнаружения жесткого диска:
|
01
02
03
04
05
06
07
08
09
10
11
|
{"data":[ {"{#DISKNAME}":"/dev/sda","{#SHORTDISKNAME}":"sda"}, {"{#DISKNAME}":"/dev/sdb","{#SHORTDISKNAME}":"sdb"}, {"{#DISKNAME}":"/dev/sdc","{#SHORTDISKNAME}":"sdc"}, {"{#DISKNAME}":"/dev/sdd","{#SHORTDISKNAME}":"sdd"}, {"{#DISKNAME}":"/dev/sde","{#SHORTDISKNAME}":"sde"}, {"{#DISKNAME}":"/dev/sdf","{#SHORTDISKNAME}":"sdf"}, {"{#DISKNAME}":"/dev/sdg","{#SHORTDISKNAME}":"sdg"},]} |
Вы можете иметь столько ключей для каждого обнаруженного элемента, но формат должен оставаться прежним. В прототипах элементов, триггеров и графиков вы будете использовать {#DISKNAME} или {#SHORTDISKNAME} для использования обнаруженных значений.
После того, как вы создали свои скрипты, вы должны зарегистрировать его в конфигурации zabbix как пользовательский параметр. Например, если вы используете демон zabbix, вам нужны эти строки в /etc/zabbix/zabbix_agentd.conf:
|
1
2
3
4
5
|
EnableRemoteCommands=1...UnsafeUserParameters=1...UserParameter=discovery.hard_disk,/scripts/discover_hdd.sh |
Теперь, когда вы создадите правило обнаружения, вы можете использовать discovery.hard_disk в качестве ключа.
Правило обнаружения само по себе полезно без прототипов, вы можете создавать три типа прототипов:
- Прототип предмета: это создаст новый предмет для каждой обнаруженной сущности
- Прототип триггера: это создаст новый триггер для каждой обнаруженной сущности.
- График Прототип: Это создаст график для каждой обнаруженной сущности.
Наиболее полезными являются, безусловно, предмет и триггеры-прототипы. Самая большая проблема с графиками заключается в том, что вы не можете создать сводный график для каждого обнаруженного элемента. Например, если вы записываете температуру ядер вашего процессора, вы не можете автоматически создать график с температурой каждого обнаруженного ядра. Для этого вам нужно создать график на каждом хосте. Что делает, имхо, графические прототипы довольно бесполезными. Так или иначе…
В следующем разделе я покажу, как я создал правила обнаружения для жесткого диска, процессорных и процессорных ядер.
Откройте для себя жесткий диск
Сценарий обнаружения действительно прост:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
|
#!/bin/bashdisks=`ls -l /dev/sd* | awk '{print $NF}' | sed 's/[0-9]//g' | uniq`echo "{"echo "\"data\":["for disk in $disksdo echo " {\"{#DISKNAME}\":\"$disk\",\"{#SHORTDISKNAME}\":\"${disk:5}\"},"doneecho "]"echo "}" |
Он просто перечисляет все устройства / dev / sdX, удаляет номер раздела и удаляет дубликаты, чтобы в конце был только жесткий диск.
Я создал несколько прототипов предметов для каждого жесткого диска. Вот несколько примеров использования SMART (вы можете скачать шаблон со всеми элементами в разделе Заключение):
- Необработанная частота чтения
- Время раскрутки
- SSD Life Left
- температура
- …
Вы можете заметить, что некоторые из них имеют смысл только для SSD (SSD Life Left), а некоторые другие не имеют никакого смысла для SSD (Spin Up Time). Это не проблема, поскольку они будут помечены как не поддерживаемые Zabbix.
Все эти данные собираются с помощью утилиты smartctl.
Я также создал триггер, чтобы указать на предстоящий сбой жесткого диска:
- Срок службы SSD оставлен слишком низким
- Количество перераспределенных секторов слишком мало
- …
Я только что использовал пороговое значение, сообщаемое smartctl, они могут отличаться от одного производителя диска к другому. Я не очень доверяю этим значениям, так как диск обычно выходит из строя перед переходом к порогу, но в любом случае это может быть хорошим показателем.
Откройте для себя процессоры
Вот скрипт для обнаружения процессоров:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
|
#!/bin/bashcpus=`lscpu | grep "CPU(s):" | head -1 | awk '{print $NF}'`cpus=$(($cpus-1))echo "{"echo "\"data\":["for cpu in $(seq 0 $cpus)do echo " {\"{#CPUID}\":\"$cpu\"},"doneecho "]"echo "}" |
Он просто использует lscpu и анализирует свои выходные данные, чтобы найти номер ЦП, а затем создает запись для каждого ЦП.
У меня есть только один элемент для каждого процессора: загрузка процессора.
Я не создал здесь никакого триггера.
Откройте для себя ядра процессора
Непосредственно перед этим мы обнаружили процессоры, но также интересно обнаружить ядра. Если у вас нет Hyperthreading, результат будет таким же. Особенно интересно узнать температуру каждого ядра. Вот сценарий:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
|
#!/bin/bashcores=`lscpu | grep "Core(s) per socket:" | awk '{print $NF}'`cores=$(($cores-1))echo "{"echo "\"data\":["for core in $(seq 0 $cores)do echo " {\"{#COREID}\":\"$core\"},"doneecho "]"echo "}" |
Он работает так же, как и предыдущий скрипт.
Я создал только один прототип элемента, чтобы получить температуру каждого ядра с помощью lm_sensors.
Заворачивать
Вот весь UserParameter, необходимый для открытия и работы элементов:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
|
### System Temperature ###UserParameter=system.temperature.core[*],sensors|grep Core\ $1 |cut -d "(" -f 1|cut -d "+" -f 2|cut -c 1-4### DISK I/O###UserParameter=custom.vfs.dev.read.ops[*],cat /proc/diskstats | egrep $1 | head -1 | awk '{print $$4}'UserParameter=custom.vfs.dev.read.ms[*],cat /proc/diskstats | egrep $1 | head -1 | awk '{print $$7}'UserParameter=custom.vfs.dev.write.ops[*],cat /proc/diskstats | egrep $1 | head -1 | awk '{print $$8}'UserParameter=custom.vfs.dev.write.ms[*],cat /proc/diskstats | egrep $1 | head -1 | awk '{print $$11}'UserParameter=custom.vfs.dev.io.active[*],cat /proc/diskstats | egrep $1 | head -1 | awk '{print $$12}'UserParameter=custom.vfs.dev.io.ms[*],cat /proc/diskstats | egrep $1 | head -1 y| awk '{print $$13}'UserParameter=custom.vfs.dev.read.sectors[*],cat /proc/diskstats | egrep $1 | head -1 | awk '{print $$6}'UserParameter=custom.vfs.dev.write.sectors[*],cat /proc/diskstats | egrep $1 | head -1 | awk '{print $$10}'UserParameter=system.smartd_raw[*],sudo smartctl -A $1| egrep $2| tail -1| xargs| awk '{print $$10}'UserParameter=system.smartd_value[*],sudo smartctl -A $1| egrep $2| tail -1| xargs| awk '{print $$4}'### Discovery ###UserParameter=discovery.hard_disk,/scripts/discover_hdd.shUserParameter=discovery.cpus,/scripts/discover_cpus.shUserParameter=discovery.cores,/scripts/discover_cores.sh |
(это должно быть установлено в zabbix_agentd.conf)
Вы также должны дать zabbix право использовать sudo с smartctl. Для этого вам нужно отредактировать файл / etc / sudoers и добавить следующую строку:
|
1
|
ALL ALL=(ALL)NOPASSWD: /usr/sbin/smartctl |
Вывод и загрузка
Я надеюсь, что это поможет некоторым людям использовать обнаружение низкого уровня в своей установке Zabbix Monitoring.
LLD значительно облегчает создание нескольких элементов обнаружения для хостов с различным оборудованием или конфигурацией. Однако у него есть некоторые проблемы, для которых я еще не нашел правильного решения. Во-первых, вы должны продублировать клиентские скрипты на каждом хосте (или, по крайней мере, иметь их на общем ресурсе, доступном для каждого из них). Затем конфигурация каждого агента также дублируется в конфигурации каждого хоста. Самой большой проблемой, я думаю, является тот факт, что вы не можете автоматически создавать граф с сгенерированными элементами каждой обнаруженной сущности. Например, мне пришлось создать график температуры процессора на каждом моем хосте. Если у вас мало хостов, как у многих, это приемлемо, но если у вас сотни хостов, вы просто не делаете этого.
Все сценарии и файл экспорта шаблонов доступны в репозитории zabbix-lld . Чтобы все работало, вам нужны утилиты lscpu, lm_sensors и smartmontools.
Если у вас есть какие-либо вопросы или если что-то не работает (я не даю никаких гарантий, но это должно работать на большинстве последних машин с Linux), не стесняйтесь комментировать этот пост.