Как отслеживать удаленный https с помощью Icinga версии 2?

Ваш хост определяет настраиваемый атрибут «http_vhosts» как словарь, но он никогда не используется (не применяется правило, определенное для итерации по этому словарю и объектам службы geberating).

Вместо этого правило применения службы (без цикла for) просто применяет службу «httpS». Случайно установлен настраиваемый атрибут хоста http_ssl - он должен читать правда как логическое значение вместо числа как строки (это всегда верно).

Вероятно, вы захотите проверить несколько URI, а не только /.

Мое предложение (2 решения):

1) Исправьте правило применения службы и удалите настраиваемые атрибуты http_ * из определения объекта хоста. Вместо этого добавьте их в правило применения службы:

apply Service "httpS" {
  import "generic-service"
  check_command = "http"
  vars.http_uri = "/"
  vars.http_ssl = true
  assign where host.name == "mailserver-01"
}

Вы можете найти все настраиваемые атрибуты, используемые в качестве параметров команды для http CheckCommand в документации: http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/plugin-check-commands#plugin-check-command-http

2) Вместо этого используйте службу «применить для правила» и переберите словарь http_vhosts, определенный на хосте.

vars.http_vhosts["https /"] = {
  http_ssl = true
  http_uri = "/"
}

Обратите внимание на название: «https /» будет сгенерированным именем службы. http_ssl и http_uri - это те же имена, что и обязательные настраиваемые атрибуты http CheckCommand.

Волшебство происходит внутри правила подачи заявки: ключом словаря будет имя службы. Значение словаря является вложенным словарем и содержит ключи http_uri и http_ssl. В примере, который называется «config». Этот словарь конфигурации имеет точно такую ​​же структуру, что и атрибут "vars", поэтому мы можем просто добавить его в службу заявки для определения.

apply Service for (servicename => config in host.vars.http_vhosts) {
  import "generic-service"
  check_command = "http"
  vars += config
}

Проверьте конфигурацию, используя демон icinga2 -C а затем просмотрите сгенерированные сервисные объекты, чтобы увидеть, какие настраиваемые атрибуты созданы (список объектов icinga2).

Одна хорошая вещь - все хосты, для которых определен настраиваемый атрибут http_vhosts, будут генерировать эти служебные объекты, нет необходимости в выражении extea «assign where» (возможно, лучше добавить ignore where для исключений). При правильной стратегии вы напишете приложение для правил только один раз, а в будущем добавите только новые хосты с соответствующим пользовательским словарем атрибутов :-)

http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/monitoring-basics#using-apply-for

Хотя решение 2) требует глубоких знаний о языке конфигурации icinga 2 и его ключевых словах, типах значений и фокусах. Тем не менее, мы думаем, что такие методы и передовые практики помогают сократить длительное обслуживание, связанное с принятием и изменением файлов.

Вы также можете пойти дальше и использовать условия if-else для разных порогов в зависимости от имени хоста. Или используйте функции для определения динамических пороговых значений, например, на основе периодов времени.

Я googledd и нашел команду http в

/usr/share/icinga2/include/command-plugins.conf

В этом примере я попытался отслеживать https://mail.google.com Ниже находится /etc/icinga2/conf.d/hosts.conf

object Host "www.google.com" {
address = "74.125.136.84"
check_command = "http"
vars.http_vhost = "mail.google.com"
vars.http_ssl = "1"
}

Вот как это выглядит на панели управления icingaweb2

Пример2

object Host "secure.example.com" {
    address = "14.28.83.22"
    check_command = "http"
    vars.http_vhosts["secure.example.com"] = {
    http_uri = "/merchant/login.aspx"    
    }
        vars.notification["mail"] = {
        groups = [ "icingaadmins" ]
        }
    vars.http_ssl="1"
}