Комментарии 11
Не понимаю, а чем это отличается от любых других кастомных метрик? Ну и кстати можно было бы сразу выложить xml-конфиг темплейтов? По кнопочкам тыкать не так удобно, а вставить xml-ку запросто, особенно учитывая тот факт, что различатся будет только UserParameter:)
не нашел собранной в кучу статьи как прикрутить к zabbix мониторинг какой-либо температуры
вот не верю ваще ни разу, ради интереса набрал в гугле «zabbix температура процессора» и по первой же ссылке попал к себе в блог где расписано всё то что вы тут написали ещё аж 22 авг 2011 :DDD
По поводу температуры хардов — man hddtemp и не надо никаких извращений с кроном, скриптами и временными файлами.
hddtemp также требует прав рута. Но тем не менее, sudoers + EnableRemoteCommands=1 в конфиге агента, и system.run[sudo hddtemp -n /dev/sda] в заббиксе действительно избавляют от лишнего геморроя
Особенно когда серверов много, и следить за зоопарком скриптов нет никакого желания
Особенно когда серверов много, и следить за зоопарком скриптов нет никакого желания
Ну да, sudoers и в путь, для того и придумано. Я собственно так и делал. Тока с конфигом агента немного по другому действовал
UserParameter=sensor.sda_temp,sudo hddtemp -nq /dev/sda
Для отсылки значений в заббикс из кронов и прочих внешних источников есть zabbix_sender и тип элемента данных Trapper в самом заббиксе.
Команда в кроне будет выглядеть примерно так
smartctl --all /dev/sda | grep Temperature_Celsius | sed «s/^[[:space:]]*\(.*\)[[:space:]]*$/\1/» | cut -d " " -f 10 | xargs zabbix_sender -c /etc/zabbix/zabbix_agentd.conf -k temp[sda] -o
А вообще тема статьи подробно раскрыта в документации
Команда в кроне будет выглядеть примерно так
smartctl --all /dev/sda | grep Temperature_Celsius | sed «s/^[[:space:]]*\(.*\)[[:space:]]*$/\1/» | cut -d " " -f 10 | xargs zabbix_sender -c /etc/zabbix/zabbix_agentd.conf -k temp[sda] -o
А вообще тема статьи подробно раскрыта в документации
О боже! Товарищ! Это лишь дополнительная метрика! Давайте мы будем отделять мух от котлет! Метрики должны хранится в части системы мониторинга. И настройка в UserParameter наилучшее для этого место!
Я помню как занимался аналитикой СМ отдной фирмы. И когда там был такой винегрет, часть метрик в конфиге заббикса, часть где-то в кроне, часть где-то еще. Не делайте так, UserParameter был спецально для этого сделан.
Я помню как занимался аналитикой СМ отдной фирмы. И когда там был такой винегрет, часть метрик в конфиге заббикса, часть где-то в кроне, часть где-то еще. Не делайте так, UserParameter был спецально для этого сделан.
Лично я стараюсь не использовать UserParameter вообще, за исключением того, когда длина команды перестает влезать в system.run[] — серверов много, и писать в конфиг каждого сервера нужные только для него параметры — неудобно.
Однако, есть события, которые генерируются внешними сервисами, скриптами — и заниматься опросом или тем паче, отгребанием их в логах — не самая лучшая идея.
Однако, есть события, которые генерируются внешними сервисами, скриптами — и заниматься опросом или тем паче, отгребанием их в логах — не самая лучшая идея.
Можно сделать отедльные пакеты в репозитории, которые будут иметь набор кастомных метрик в виде шелл-скриптов. Тогда соотв, имея множество серверов нужно будет просто набрать sudo apt-get install zabbix-metric-harddisk и bash скрипты появтся в системе. Дальше нужно обновить конфиг агента, всего-лишь добавив вызов этого шел. скрипта, и длина вызова будет не большой. Ровно также метрики можно обновлять, и это будет на всем кластере.
Делаете отдельный пакет для MySQL, PHP, Oracle, Java App, обновляете на всем кластере, обновляете данные в морде заббикса. Вот и все.
>Однако, есть события, которые генерируются внешними сервисами, скриптами — и заниматься опросом или тем паче, отгребанием их в логах — не самая лучшая идея.
В этом случае да, но hddtemp не генерирует событий. Мухи отдельно, котлеты отдельно. Если мне JVM скажет «МНЕ ПЛОХО», то да, такую метрику/событие лучше обрабатывать через zabbix_sender.
Делаете отдельный пакет для MySQL, PHP, Oracle, Java App, обновляете на всем кластере, обновляете данные в морде заббикса. Вот и все.
>Однако, есть события, которые генерируются внешними сервисами, скриптами — и заниматься опросом или тем паче, отгребанием их в логах — не самая лучшая идея.
В этом случае да, но hddtemp не генерирует событий. Мухи отдельно, котлеты отдельно. Если мне JVM скажет «МНЕ ПЛОХО», то да, такую метрику/событие лучше обрабатывать через zabbix_sender.
Если случилось такое, что кому-то плохо, то zabbix-sender может уже и не отработать. Я к тому, что инструмент хороший, но лучше использовать комбинированные механизмы.
И, кстати, что плохого собрать вообще все скрипты в один пакет, как например делает ZTC и ставить все разом, одним пакетом. Скрипты лежат, кушать не просят, а неразберихи меньше.
И, кстати, что плохого собрать вообще все скрипты в один пакет, как например делает ZTC и ставить все разом, одним пакетом. Скрипты лежат, кушать не просят, а неразберихи меньше.
Кстати говоря, в заббиксе есть штатный шаблон для снятия температуры сервера (исключая харды) через IPMI
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Прикручиваем мониторинг параметров smart или какой-либо температуры (cpu, motherboard) к Zabbix