ホストはカスタム属性「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)代わりにservice apply for ruleを使用し、ホストで定義されたhttp_vhosts辞書をループします。
vars.http_vhosts["https /"] = {
http_ssl = true
http_uri = "/"
}
ここでの命名に注意してください。「https /」が生成されたサービス名になります。http_sslおよびhttp_uriは、http CheckCommandで必要なカスタム属性とまったく同じ名前です。
魔法は、apply forルールの内部で発生します。ディクショナリキーはサービス名になります。辞書値はネストされた辞書であり、キーとして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オブジェクトリスト)。
1つの良い点-http_vhostsカスタム属性が定義されているすべてのホストがこれらのサービスオブジェクトを生成します。extea "assign where"式は必要ありません(例外の場合は、ignore whereを追加する可能性があります)。適切な戦略を使用して、ルールの適用を1回だけ記述し、今後は一致するカスタム属性ディクショナリを持つ新しいホストのみを追加します:-)
http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/monitoring-basics#using-apply-for
ソリューション2)には、icinga 2構成言語とそのキーワード、値タイプ、手品についての高度な知識が必要です。しかし、そのような方法とベストプラクティスは、ファイルの採用と変更による長期的なメンテナンスの削減に役立つと考えています。
さらに進んで、ホスト名に基づいてさまざまなthreshokdsにif-else条件を使用することもできます。または、関数を使用して、たとえば期間に基づいて動的しきい値を定義します。