web監視について
どなたか基本的な事ですがいくつかご教示いただけないでしょうか。
zabbix2.4にてURL監視を行おうと思っています。(エージェントなし)
試験的にapache2.2でwebサーバを用意していて、サーバは単純(HTML)な静的コンテンツを返すようにしています。
◾︎web監視のリトライについて
web監視のシナリオの設定にてリトライ設定があると思うのですが、うまく動作しません。
リトライ機能は、「ネットワーク障害（タイムアウト、接続なしなど）」が起こった場合に
ステップを再試行するとマニュアルに記載があったのですが、こちらはApacheを停止させた場合はリトライ機能が動作しない認識でよろしいでしょうか？また、タイムアウトや接続なしを再現できる方法が何かないかご教示いただけないでしょうか？
(Zabbixは、レスポンスコードが違う、または要求された文字列との不一致という理由でステップを繰り返すことはしません。とマニュアルに記載あり。)
▪️URL監視失敗時のアクションについて
上記の監視環境にて、URLの監視が失敗したらzabbixサーバ側で自身の/var/log/messageにloggerでログ出力をさせています。
対象URLの監視設定は要求ステータスコードとして200-207,304を設定しているのですが、例えば、監視対象URLが要求ステータスコード以外を返した際にその返したステータスコードをloggerで出力することは可能でしょうか？
・設定しているlogger
「logger -p user.notice DOWN {TRIGGER.NAME}{TRIGGER.URL} -t '[zabbix]’」
上記について、不明点等あれば教えてください。
以上、よろしくお願いします。
wakaba - 投稿数: 228
広瀬です。
・Web監視リトライについて
Apache等が落ちている場合は、名前解決またはIPレベルの通信は出来るが80番ポートが稼働していない状態と
判断した場合には、リトライせず、即時落ちします。これは内部処理としてlibcurlを利用しているため、Zabbixとい
うよりもlibcurlの仕様ですのでリトライはしません。
また、IP指定のURL記載の場合と、FQDN指定時でも挙動が変わります＜あくまでもネットワーク障害時を想定
・IP指定の場合指定したリトライ、タイムアウト間隔待ちます
・FQDN指定時は、名前解決がそもそも出来ない場合にはリトライはしますがタイムアウトはほぼ無視します
これらはcurlコマンドで同様な再現が可能です。試してみてください
・レスポンスコードの出力
2017/03/14 17:08:50 403 ←Forbiddenの場合
2017/03/14 17:07:23 0 ←エラーの場合のステータスコード
2017/03/14 17:06:14 200
どのようにレスポンスコードをmessagesに吐いているか分りませんが(アクションでリモートコマンドかな？)、
URL監視の結果(Response code for step scenario)を{ITEM.VALUE}でリモートコマンドの引数として渡せば可能かと
思います。
TNK - 投稿数: 4769
接続してテストする対象のApache HTTP Serverが停止していた場合
は、接続しようとして接続不可の状態となるので、設定した試行回
数分、再度接続のリトライが行われます。
# Zabbix 3.0.7 + CentOS 7.3.1611で確認
# FQDNではなくIPアドレスのみで確認
リトライは行うのですが、HTTPのリクエストを送る前の処理の部分
でのリトライです。
ですので、Apache HTTP Serverを停止すれば、接続不可のテストに
なると思います。
タイムアウトは、PHPやその他の何らかの言語を使用して、そのペ
ージにアクセスした時に、そのスクリプト内でsleepなどを使用し
て時間のかかる処理を行わせればよいでしょう。
ネットワーク障害としては他にも、Firewallでの接続制限やルーテ
ィングの設定不備なども考えられると思いますので、使用されてい
る環境上で発生しうる障害を検討してみてください。
トリガーの条件式にステータスコードが含まれていれば、
{ITEM.VALUE1}
{ITEM.VALUE2}
などを使用して参照できるのですが、そうではない場合は、
{host:key.func(param)}
を使用して、ホストやキーを指定して値を参照することが必要にな
ると思います。
例：(ただしテストはしていません)
{ホスト名:web.test.rspcode[Scenario,Step].last(0)}
mtar0024 - 投稿数: 6
広瀬さん(wakabaさん)
ご回答ありがとうございます。
>Apache等が落ちている場合は、名前解決またはIPレベルの通信は出来るが80番ポートが稼働していない状態と
>判断した場合には、リトライせず、即時落ちします。これは内部処理としてlibcurlを利用しているため、Zabbixとい
>うよりもlibcurlの仕様ですのでリトライはしません。
→上記、承知しました。
>また、IP指定のURL記載の場合と、FQDN指定時でも挙動が変わります＜あくまでもネットワーク障害時を想定
>
> ・IP指定の場合指定したリトライ、タイムアウト間隔待ちます
> ・FQDN指定時は、名前解決がそもそも出来ない場合にはリトライはしますがタイムアウトはほぼ無視します
>
>これらはcurlコマンドで同様な再現が可能です。試してみてください
→こちらは実際に試してみようと思います。
>・レスポンスコードの出力
>
>2017/03/14 17:08:50 403 ←Forbiddenの場合
>2017/03/14 17:07:23 0 ←エラーの場合のステータスコード
>2017/03/14 17:06:14 200
>どのようにレスポンスコードをmessagesに吐いているか分りませんが(アクションでリモートコマンドかな？)、
>URL監視の結果(Response code for step scenario)を{ITEM.VALUE}でリモートコマンドの引数として渡せば可能かと
>思います
→ご推察のとおり、リモートコマンド(loggerを実行してmessageに出力)を実行させています。
上記を参考にさせていただきます。
以上、よろしくお願いいたします。
mtar0024 - 投稿数: 6
TNKさん
ご回答ありがとうございます。
>接続してテストする対象のApache HTTP Serverが停止していた場合
>は、接続しようとして接続不可の状態となるので、設定した試行回
>数分、再度接続のリトライが行われます。
># Zabbix 3.0.7 + CentOS 7.3.1611で確認
># FQDNではなくIPアドレスのみで確認
→zabbix2.4とは動きが違うのでしょうか？こちらで確認した限りでは
リトライを試みずに即時トリガー発動→アクション実行を確認しました。
>リトライは行うのですが、HTTPのリクエストを送る前の処理の部分
>でのリトライです。
→TCP3ウェイハンドシェイクのことでしょうか？
>タイムアウトは、PHPやその他の何らかの言語を使用して、そのペ
>ージにアクセスした時に、そのスクリプト内でsleepなどを使用し
>て時間のかかる処理を行わせればよいでしょう。
→こちらは上記のsleepを参考にしたいと思います。ありがとうございます、
>・URL監視失敗時のアクションについて
>
>トリガーの条件式にステータスコードが含まれていれば、
>
> {ITEM.VALUE1}
> {ITEM.VALUE2}
>
>などを使用して参照できるのですが、そうではない場合は、
>
> {host:key.func(param)}
>
>を使用して、ホストやキーを指定して値を参照することが必要にな
>ると思います。
>
>例：(ただしテストはしていません)
>{ホスト名:web.test.rspcode[Scenario,Step].last(0)}
現在設定しているトリガー条件式は、
{ホスト名:web.test.fail[テスト監視].last()}<>0 としていますが
変更を試みて検証してみたいと思いますが、トリガーは複数設定可能なのでしょうか？
またこちらのweb監視シナリオの設定で要求ステータスコードを200-207.304としているのですが問題ないでしょうか？
以上、ご確認よろしくお願いいたします。
TNK - 投稿数: 4769
Web監視のシナリオ設定内のリトライ指定によるリトライの機能を
シナリオ全体実行のリトライと勘違いされていませんか？
Web監視の設定画面で設定するリトライは、「ネットワーク障害（
タイムアウト、接続なしなど）」が起こって応答が得られなかった
時に、再度接続しなおしたりHTTPのリクエストを投げるのを再試行
する設定であって、シナリオ全体を再試行するものではないようで
す。
そうです。
サーバー自体は起動していて、IPアドレスが有効である状態でHTTP
サーバーが起動していない時には、HTTPサーバーに接続しようとす
ると、Zabbixサーバー側から送ったSYNに対して、RST,ACKが返却さ
れます。
この部分で、リトライが行われるわけです。
同じアイテムにトリガーは複数設定できますし、条件式内に複数の
アイテムを使用してandやorで組み合わせた条件式を指定すること
ができます。
もしかして、シナリオ全体のリトライと考えられているのであれば、
1度のシナリオ実行で失敗もしくは障害であったときにアクション
を実行するのではなく、複数回シナリオを実行して、連続して失敗
もしくは障害であった時にアクションを実行されたいということで
しょうか？
そうであるならば、
web.test.fail[]
の最新値だけを条件式で判定するのではなく、過去の値も含めて障
害と判断するような条件式にする必要があります。
例：3回連続で失敗した場合
{ホスト名:web.test.fail[テスト監視].min(#3)}>0
最後に、2.4はすでにサポートが終了しています。
不具合や脆弱性の問題があっても、今後公式に修正されたバージョ
ンは公開されませんのでご注意ください。