Комментарии 12
yum -y install git; git clone github.com/zabbix/zabbix.git
Для скачивания с Github не обязательно тащить git, можно просто wget'ом/curl скачать github.com/zabbix/zabbix/archive/master.zip
Ну и стиль написания команд в шел привели бы к единому виду, а то где-то в 1 строке по 2 команды через; а где-то построчно. ИМХО более наглядно и удобно когда 1 команда 1 строка.
ПРИМЕЧАНИЕ
Если PostgreSQL установлен из репозитория PGDG, добавьте путь к pg_isready в переменную среды PATH для пользователя zabbix.
Как вариант:
ln -s /usr/pgsql-12/bin/pg_isready /usr/bin/pg_isready
То есть не освоили/осилили как добавить в PATH для zabbix-agent?
Ну тогда подскажу, для CentOS/RHEL/OracleLinux в файл /etc/sysconfig/zabbix-agent добавить
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/pgsql-12/bin
А в /usr/lib/systemd/system/zabbix-agent.service добавить
User=zabbix
потом сделать
systemctl daemon-reload
systemctl restart zabbix-agent
и проверить
xargs -0 -L1 -a /proc/$(cat /var/run/zabbix/zabbix_agentd.pid)/environ
Спасибо за замечания.
В чем преимущество вашего примера перед ln -s /usr/pgsql-12/bin/pg_isready /usr/bin/pg_isready?
Для меня симлинк — это костыль.
Если у вас на сервере 2-3....10 экземпляров Pg, то в моем случае можно запустить 2-3...10 zabbix-agent на сервере, каждый со своим unit файлом и со с своим EnvironmentFile, а HOME со скриптами будет один. Таким образом каждый агент будет использовать нужную версию psql и pg_isready из своего экземпляра Pg. Да, такая ситуация редкость, но бывает.
Хотя можно все 10 экземпляров Pg с одного агента мониторить, но тут придется надеяться что psql будет присутствовать в системном PATH, но в какой-то момент она может оттуда исчезнуть и… приехали.
Если у вас на сервере 2-3....10 экземпляров Pg, то в моем случае можно запустить 2-3...10 zabbix-agent на сервере, каждый со своим unit файлом и со с своим EnvironmentFile, а HOME со скриптами будет один. Таким образом каждый агент будет использовать нужную версию psql и pg_isready из своего экземпляра Pg. Да, такая ситуация редкость, но бывает.
Хотя можно все 10 экземпляров Pg с одного агента мониторить, но тут придется надеяться что psql будет присутствовать в системном PATH, но в какой-то момент она может оттуда исчезнуть и… приехали.
А в /usr/lib/systemd/system/zabbix-agent.service добавить
Лучше использовать systemctl edit --full zabbix-agent.service
Таким образом изменения в юните сохранятся и после установки обновлений.
А в /etc/profiles.d/postgres не лучше? Тогда для всех пользователей обновится path и админы заходя на сервак не будут ломать голову. Это кстати работает на всех дистрибутивах, в отличии от вашего решения.
А в чем принципиальное отличие этого мониторинга от mamonsu?
Спасибо за статью!
Требуется ли обновление самих заббикс-агентов на серверах до новой go-шной версии?
Или со старыми агентами (работавшими с libzbxpgsql например) всё подхватится?
Требуется ли обновление самих заббикс-агентов на серверах до новой go-шной версии?
Или со старыми агентами (работавшими с libzbxpgsql например) всё подхватится?
Требуется как минимум zabbix-server 4.4, а zabbix-agent может быть и 3-й версии.
zabbix-agent2 на Go тут не нужен.
И libzbxpgsql тут наверно будет более интересен, т.к. это сишный модуль, который работает быстрее, кушает меньше ресурсов и наверно будет более гибок, хотя тут нужно смотреть что Вам проще — писать кастомные sql запросы для libzbxpgsql или правила препроцессинга для zabbix-server 4.4
zabbix-agent2 на Go тут не нужен.
И libzbxpgsql тут наверно будет более интересен, т.к. это сишный модуль, который работает быстрее, кушает меньше ресурсов и наверно будет более гибок, хотя тут нужно смотреть что Вам проще — писать кастомные sql запросы для libzbxpgsql или правила препроцессинга для zabbix-server 4.4
Тет все метрики через psql -f somefile.sql тянутся. Мне кажется агентов не обязательно обновлять.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настраиваем официальный шаблон PostgreSQL на Zabbix 4.4