ssh接続監視が働かない？
いつも大変お世話になっております。
Zabbix version 2.0.6
以前こちらでssh接続の監視について教えて頂きました。
アイテムには、net.tcp.service[ssh] を設定しています。
トリガーには、{hostname:net.tcp.service[ssh].last(0)}#1 を設定しました。
その後にサーバーを1台止める事になったので、sshの接続でアラートが飛ぶかなと思い
確認の為あえて無効にせずにいたのですが、サーバーが止まっても障害にはなりませんでした。
zabbix_get -s xxx.xxx.xx.xx. -k net.tcp.service[ssh] で確認すると
Get value error: cannot connect to [[xxx.xxx.xx.xx]:10050]: [113] No route to host のエラーは確認しました。
何故か、agentに5分間繋がらない のトリガーアラートは正常に出ています。
agent自体に繋がらない場合は、agent系の障害しか発生せず という事なのでしょうか？？
何か凡ミスを犯していそうな気もします…
お忙しい所申し訳ありませんが、知恵をお貸しください。
TNK - 投稿数: 4753
net.tcp.service[ssh]を指定されたアイテムのタイプが「Zabbixエ
ージェント」になっていませんか？
「Zabbixエージェント」であった場合は、サーバをシャットダウン
した時点で、エージェント経由でのSSHチェックができませんので、
対象のサーバのエージェントが利用可能になるまでSSHのチェック
は不可となります。
エージェント経由でのチェックが不可ですので、アイテムとしての
値の変化も起こらないため、last()の値でのチェックは行われず、
トリガーも発生しないでしょう。
アイテムのタイプとして、
agent.pingが「Zabbixエージェント」
net.tcp.serviceでは「シンプルチェック」
を利用した場合は、それぞれ別にチェックを行いますので、例えば、
zabbix-agentのみを停止しても、SSHでのチェックは継続されます。
サーバのシャットダウンを行うと、両方のトリガーが障害と判定さ
れるようになります。
アイテムで利用するタイプによって、動作は異なります。
何をどう監視したいかや、ネットワーク構成などの要件に合わせて
タイプを選択してください。
fripper - 投稿数: 495
TNKさんの補足です
アイテムのタイプによって、監視動作が変わります
Zabbixエージェント → エージェント自身が情報収集を行い、サーバへその結果を報告します
今回の事例（net.tcp.service[ssh]）の場合、エージェントが対象ホストへの SSH接続を行います
シンプルチェック → 監視サーバ自身が情報収集を行います
今回の事例（net.tcp.service[ssh]）の場合、監視サーバが対象ホストへの SSH接続を行います
前者の場合、エージェントが動作しているホスト→エージェントが動作しているホストのSSHサービス、という接続になります
よって、TNKさんのコメントにあるとおり
＞エージェント経由でのチェックが不可ですので、アイテムとしての
＞値の変化も起こらないため、last()の値でのチェックは行われず、
＞トリガーも発生しないでしょう。
といったことになります
後者の場合、監視サーバが動作しているホスト→エージェントが動作しているホストのSSHサービス、という接続になります
この場合には、エージェントが停止していても、SSHサービスのチェックは継続され、
＞サーバのシャットダウンを行うと、両方のトリガーが障害と判定さ
＞れるようになります。
となります
この動作の違いを利用して、面白い監視‥というか、バリエーションに富んだ監視をさせることができます
双方とも、net.tcp.service[service,ip,port] といった書式が指定できますので、それを利用して‥
・net.tcp.service[ssh] ＠zabbix エージェント
エージェント自身に localhost への SSH 接続をチェック → ssh デーモンの状態監視とみなせる
・net.tcp.service[service, 111.22.33.44] ＠シンプルチェック
サーバから、エージェント動作ホストの「サービス提供IP」への接続をチェック → SSH デーモンの状態だけでなく、WAN 側のネットワーク途中経路の断線まで検知可能
間にインターネットを挟むとか、NAT されているとか、そういった複雑なネットワークでない限りは
あまり用途はないかもしれませんが‥、動作の違いを利用した監視が可能です
ortan - 投稿数: 29
TNKさん fripperさん ご回答ありがとうございます！
仰るとおり、タイプの概念を理解していないと言う愚かな結末でした…
同じzabbixエージェント設定なのに、agent.ping のトリガーだけ正常に動いていたのは、lastではなくnodataだったからですね。
また、それを応用して監視経路まで考えることが出来ると、設定1つで色々監視が出来そうですね！
今回対象となっているサーバはそこそこの頻度で、立ち上げたり落としたりするサーバなので、agent側で監視すれば立ち上がっている時だけ
監視されるので良さそうです。
と思っていたのですが、お二方の助言から考えてみれば、タイプがエージェントだと外部からの接続監視ではなく、内部から外部接続(zabbisサーバ)への監視ですよね？
これでは似たような意味合いではあるが、実際は違うんじゃないかとふと思いました。
サーバが立ち上がっている時だけ監視したいけど、タイプはシンプルチェック(zabbixサーバからagentへの接続監視)したい場合は
{hostname:agent.ping.last(0)}=1 #1
の様な組み合わせトリガー設定になりますかね？
fripper - 投稿数: 495
トリガーの組み合わせで、判定式内に２つのアイテムを組み合わせるのも１つの方法だと思います
別の方法として、トリガーの依存関係を使う方法があります
「SSH接続」のアイテムに関するトリガーの依存トリガーとして、「ホスト停止」のトリガーを指定することで
「ホスト停止」が検知している間は「SSH接続」のトリガーが発動しなくなります
TNK - 投稿数: 4753
トリガーに関しては、fripperさんがすでに書かれていますが、1つ
だけ補足させて頂きます。
トリガーの式を1つにまとめてしまった場合、エージェントとSSHの
どちらかのみ障害となった場合に検知できないと思われますのでご
注意ください。
あと、
に関しては、先にfripperさんが書かれていらっしゃるように、タ
イプが「Zabbixエージェント」で、キーが「net.tcp.service[ssh]」
ですと、監視対象のサーバ上で、そのサーバ内部でのZabbixエージ
ェントプロセスからlocalhost(127.0.0.1)へのSSHでの接続確認に
なります。
外部のサーバから監視対象のサーバにSSHで接続可能かを確認する
という意味であれば、タイプとしては「シンプルチェック」を利用
することで、SSHへの接続確認は、Zabbixサーバ上から確認される
ため、確認したいことにより近い確認になるのではないでしょうか。
ortan - 投稿数: 29
TNKさん fripperさん 毎度丁寧なご回答ありがとうございます！
なるほど、依存関係を利用と言う手もありましたか。
まずはシンプルチェックにして、止まっているサーバから {hostname:net.tcp.service[ssh].last(0)}#1 でエラーが起こる事を確認し
その後に後学の為にも依存関係を利用して、{hostname:agent.ping.nodata(5m)}=1 に紐付けて、止まっていたら監視しないようにしてみます。
また、エージェントの勘違いについてもご指摘ありがとうございました。
agentからserverへのsshではなくて、ローカル内で自分に対してsshですね…
おかげさまで監視も正しい設定で出来そうですし、zabbixの勉強にもなりました！