您的主机将自定义属性“ http_vhosts”定义为字典,但从未使用过(没有适用于在该字典上进行迭代的规则定义和对服务对象的整合)。
相反,服务应用规则(无for循环)仅应用服务“ httpS”。偶然地设置了主机自定义属性“ http_ssl”,该属性应以布尔值而非字符串的形式读为true(始终为true)。
您可能要检查多个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- 命令-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”表达式(也许在异常情况下添加忽略位置)。使用正确的策略,您只需编写一次即可申请规则,并且将来仅添加具有匹配的自定义属性字典的新主机:-)
http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/monitoring-basics#using-apply-for
尽管解决方案2)需要有关icinga 2配置语言及其关键字,值类型和魔术的高级知识。但是我们认为,这种方法和最佳做法有助于减少采用和更改文件的长期维护。
您还可以根据主机名,对不同的阈值使用if-else条件。或使用函数根据时间周期定义动态阈值。