У меня проблема с тем, что некоторые триггеры zabbix не срабатывают из-за того, что EnableRemoteCommands не был включен на определенных хостах. Я попытался решить эту проблему, добавив триггер, специально проверяющий, установлено ли для EnableRemoteCommands значение 1 в конфигурации агента zabbix:
{Template OS Linux:system.run["cat /etc/zabbix/zabbix_agentd.conf | grep EnableRemoteCommands=1"].str(EnableRemoteCommands=1)}=0
Но, конечно, сам этот триггер полагается на удаленные команды, поэтому не будет работать на хостах, на которых они отключены.
По какой-то причине, если zabbix не может запустить удаленную команду, он оставляет триггер со статусом «ОК». Есть ли способ заставить это переключиться в статус "ПРОБЛЕМА"?
Использовать UserParameter который работает без EnableRemoteCommands включен:
UserParameter=<key>,<command>
В твоем случае:
UserParameter=zabbix.remotecommands, egrep 'EnableRemoteCommands.*=.*1' /etc/zabbix/zabbix_agentd.conf
Затем создайте предмет zabbix.remotecommands с типом Zabbix Agent и следующее утверждение для проверки:
{Template OS Linux:zabbix.remotecommands.strlen()}=0
Он сработает, если элемент ничего не вернет, например EnableRemoteCommands выключен. Пожалуйста, не используйте system.run когда вам это абсолютно не нужно, по умолчанию он отключен специально - вы можете делать что угодно, используя другие способы, которые предлагает Zabbix.
Если основная конфигурация агента выполняется только в одном файле, мы, вероятно, могли бы использовать vfs.file.regexp элемент (или vfs.file.regmatch) здесь. Например:
vfs.file.regexp[{$AGENT_CONFIG},^EnableRemoteCommands=1]
Это не идеально, потому что он ищет только в основном файле конфигурации EnableRemoteCommands параметр, но этот параметр можно переопределить во включенном файле.