Я считаю, что я успешно настроил Icinga 2 на Debian 9 (Stretch), используя стандартные пакеты Debian с режимом «Синхронизация конфигурации сверху вниз» в качестве описанный в документации Icinga.
Я установил icinga2 и monitoring-plugins-basic на клиентах и могу добавлять удаленные проверки, используя check_apt и т.д. мне даже удалось добавить свой CheckCommands через механизм "глобальных шаблонов", которые автоматически отправляются клиентам и попадают в /var/lib/icinga2/api/zones/global-templates/_etc/
У меня есть несколько собственных проверочных скриптов (написанных на оболочке и Python), которые я также хотел бы запустить. Я положил их в /etc/icinga2/zones.d/global-templates тоже, и они также отправляются клиентам. Однако по пути они теряют свой бит выполнения, поэтому я вынужден явно предоставлять интерпретатор при их запуске. Это работает, но немного некрасиво.
Есть ли лучший способ отправить мои проверочные скрипты от мастера к клиентам? Если нет, есть ли способ сохранить бит выполнения с помощью этого метода?
Не делай этого. Синхронизация конфигурации кластера предназначена только для простых файлов конфигурации.
В то время как сценарию может потребоваться просто исполняемый бит, двоичные файлы с другой архитектурой и зависимостями библиотек представляют собой большую проблему.
Путь к синхронизированной конфигурации тоже может измениться, надежного способа зависеть от этого нет.
Развертыванию таких сценариев можно помочь с помощью инструментов управления (жизненным циклом), таких как Puppet, Ansible и т. Д. Решению зависимостей сценариев может помочь полное создание пакета из ваших сценариев, доступных в репозитории программного обеспечения.
На моей предыдущей работе у меня был центральный репозиторий плагинов, который регулярно проверялся на клиентах.