web-dev-qa-db-ja.com

Icingaバージョン2でリモートの「https」を監視する方法は?

VirtualBox内のubuntu 14.04.3にicinga 2.3.11があります。ここでは「 https://mail.google.com 」のように「https」ポート443を監視しようとしています。以下は、デフォルトのHost.confファイルからのスニペットです。

object Host "mailserver-01" {
    import "generic-Host"
    address = "74.125.136.17"    /* ip for mail.google.com */ 
    vars.os = "Linux"
    vars.http_vhosts["http"] = {
        http_uri = "/"
    }
    vars.http_ssl = "1"
    vars.http_warn_time = "5"
    vars.http_critical_time = "10"

    vars.notification["mail"] = {
        groups = [ "icingaadmins" ]
    }
}

以下は、デフォルトのservices.confファイルからの抜粋です

apply Service "httpS" {
    import "generic-service"
    check_command = "http"
    assign where Host.name == "mailserver-01"
}

Icingaweb2ダッシュボードにOK /緑色が表示されますが、正しい方法かどうかわかりません

9
satch_boogie

ホストはカスタム属性 "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"
}

httpCheckCommandのコマンドパラメータとして使用されるすべてのカスタム属性は、ドキュメントで見つけることができます: http://docs.icinga.org/icinga2/latest/doc/ module/icinga2/chapter/plugin-check-commands#plugin-check-command-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 ruleの中で起こります:辞書のキーはサービス名になります。辞書の値はネストされた辞書であり、キーとして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条件を使用することもできます。または、関数を使用して、たとえば期間に基づいて動的しきい値を定義します。

10
dnsmichi

私はググって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ダッシュボードにどのように表示されるか enter image description here

例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"
}
2
satch_boogie