Комментарии 20
Если я не ошибаюсь, то с 4.4 он из коробки может брать инфу с prometheus_exporter, потому ваш пост ок, но можно проще.
Я пытался написать пост о мониторинге Zabbix'ом в принципе, а не о мониторинге Zabbix'ом Redis'а. Получилось вот так. Может быть можно и проще.
PS: поднимите zabbix 4.4 в контейнерах и попробуйте вариант с prometheus_exporter — это будет будущее zabbix так или иначе.
Вы несколько неправильно поняли посыл моей публикации. Я пытался написать, как при помощи Zabbix'а мониторить что угодно уже сейчас. Я не считаю более простым способ подключить "что угодно" к prometheus_exporter, который подключен к Zabbix, чем способ подключить "что угодно" напрямую к Zabbix. Особенно, если меня интересует только сбор параметров мониторинга, их визуализация в графиках и нотификация в случае наступления некоторых событий (тот функционал, что предоставляется Zabbix'ом на стороне сервера).
т.к. каждый желающий костыляет велосипеды.
Вот в этом-то и есть посыл моей публикации. Zabbix настолько просто расширяется, что каждый может накостылят свой велосипед уже сейчас, не ожидая, пока где-то кто-то выпустит "официальный шаблон". Я не считаю костыляние велосипедов грехом, скорее даже наоборот. Особенно, если на нём можно ехать. Так что это сильная сторона Zabbix'а.
это будет будущее… так или иначе
Я столько раз вступал в будущее, которое становилось "иначе", чем было, когда я в него вступал, что предпочитаю обождать, пока будущее не станет настоящим.
P.S.
ничего не имею против prometheus_exporter — я вообще про него только сегодня узнал :)
Почему вы так решили, что "grep" — это антипаттерн? Оккам завещал не множить сущности без необходимости.
Тем более для (no)sql
Вот тут я вообще сильно потерялся. Не вижу связи.
grep и shell-скрипты доступны на любом linux-хосте. "вообще костыль" — так сейчас многие называют дешёвые и эффективные решения. Любой компонент (скрипт, программа, библиотека, модуль и т.п.) зависит от его автора и может что-нибудь вывести, а может не вывести вообще.
Очень многие недооценивают возможностей shell-скриптов в linux'е. Но практически всё, что вы можете выполнить в консольном режиме, вы также можете выполнить и при помощи shell-скрипта. А в linux'е в консольном режиме можно выполнить вообще всё.
Вот, например, код для мониторинга размера таблицы tbl_name в MySQL базе db_name:
UserParameter=my.table.size,/usr/bin/mysql --login-path=www -e "show table status from db_name like 'tbl_name'" | grep -P "tbl_name\t" | cut -d$'\t' -f7Поместите этот код в файл /etc/zabbix/zabbix_agentd.d/userparameter_mytable.conf, рестартаните агента, добавьте элемент данных my.table.size на Zabbix-сервере для соответствующего хоста и собирайте данные.
На всё про всё не больше получаса с поиском информации в сети, как пользоваться grep, cut и mysql. Вы называете это "костылём", а я — работающим решением.
А вот вы сможете привести описание настройки мониторинга размера таблицы db_name.tbl_name в MySQL при помощи "json,snmp, трапперы, прометеус" в пределах одного поста?
И таких вариантов, когда нужно собирать нужную конкретно мне информацию (не разрабам шаблонов Zabbix'а, не другим пользователям MySQL'а, Redis'а, а именно — мне) — может быть over, чем много.
Я не против использования SNMP, prometheus и прочих современных технологий вместе с shell-скриптами. Я против использования их вместо shell-скриптов. Потому что это уже религия, а не инженерия. А я, как человек искренне верующий в разумное начало этой версии Вселенной, религиозных, мягко говоря, недолюбливаю.
В идеале само приложение должно уметь отдавать джейсон с метриками, или использовать питон/гоу. Генерить джейсон на шеле так себе удовольствие.
Т.е., вы предлагаете ставить на хост дополнительно python/go, чтобы сгенерировать JSON, вместо того, чтобы извлечь одно число средствами shell'а.
"Тот, у кого из орудий имеется лишь молоток, склонен на любую проблему смотреть как на гвоздь." © Abraham Maslow
Ваше знакомство с shell'ом не выходит за рамки шапочного. Вы просто не умеете его использовать.
- Python в большинстве дистрибутивов доступен из коробки. Ничего дополнительно устанавливать не требуется.
- Можно обойтись только функционалом Zabbix — получать сырые данные и использовать препроцессинг для их обработки.
ОК, покажите, пожалуйста, как, используя только функционал Zabbix, получить сырые данные по скорости работы дисковой подсистемы? У меня как раз стоит такая проблема — хостер утверждает, что виртуальный сервер стоит на SSD, а я измеряю скорость чтения/записи, и её даже для хорошего HDD не всегда хватает. Средствами shell это делается так (нужно ещё анализатор вывода через grep/cut добавить, но это уже мелочи):
$ dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; rm -f /tmp/outputИ не используйте, пожалуйста, в своём решение Python. Я согласен, что он есть из коробки, но мы же не будем множить сущности без необходимости, раз нам хватает только Zabbix'а, не так ли?
Извините, дружище, но вы за 3 дня так и не смогли подтвердить свои слова, что "можно обойтись только функционалом Zabbix" в ответ на мою просьбу продемонстрировать, каким образом можно мониторить скорость работы дисковой подсистемы. Пришлось делать самому через shell-скрипты:
# /etc/zabbix/zabbix_agentd.d/userparameter_own.conf
UserParameter=own.disk.speed,/usr/lib/zabbix/externalscripts/own_disk_speed.sh# /usr/lib/zabbix/externalscripts/own_disk_speed.sh
#!/bin/bash
FILE_OUT="/tmp/disk_speed_data"
DATA=$(dd if=/dev/zero of=${FILE_OUT} conv=fdatasync bs=384k count=1000 2>&1)
BYTES=$(echo ${DATA} | cut -d' ' -f 7)
SEC=$(echo ${DATA} | cut -d' ' -f 14)
EXP=" ${BYTES} / ${SEC} "
bc <<< ${EXP}Почему-то ваш коммент заставил меня вспомнить о русской пословице "Главное — прокукарекать, а там хоть не рассветай".
Не извиняю.
Во-первых, я не обязан сидеть целыми днями и мониторить комментарии. Когда смог — тогда и ответил.
Во-вторых, аналогичный результат можно получить без 2 дополнительных файлов.
Используем что-то вроде "system.run[dd if=/dev/zero of=/var/lib/zabbix/output conv=fdatasync bs=384k count=1k]"
Получаем результат:
1024+0 records in
1024+0 records out
402653184 bytes (403 MB, 384 MiB) copied, 2.4547 s, 164 MB/sНа а дальше препроцессинг: регулярным выражением получаем требуемое значение.
Спасибо за ответ. Хоть я и остался непрощённым, зато я узнал про "system.run" и понял, что имелось в виду под "получать сырые данные функционалом zabbix" ;) На конце висят те же самые shell-команды, только постпроцессинг вынесен на сам zabbix. Согласен, что ваш вариант в некоторых (во многих?) случаях будет удобнее (если объём передаваемых данных невелик, плюс отлаживать команды проще всё-таки в консоли), чем создание отдельного shell-скрипта на target host'е.
Хотел бы сказать, что сожалею, что пришлось вытаскивать ответ клещами, но нет — не сожалею.
Писать статью о том как извлечь одно число через шелл это как раз удел новичков. "Я тут быстро скачал какойто скрипт, собрал на коленке мониторинг… нужно написать статью"
Zabbix: мониторим всё подряд (на примере Redis'а)