宜しくお願いします。
デフォルトのトリガーに以下がありました。
Template ICMP Ping:icmpping.max(#3)}=0
こちらは、ICMP Pingアイテムで拾ってきた値の直近3個の最大値が０（異常終了）の場合トリガーですか？
max（#3）=0
＃の解釈として、「等しくない」とでてきたので、同いう意味か混乱しました。
追加のご質問です。
そもそも、直近3回の最大値が異常の場合とは、結局は、監視時点で異常があればトリガーすると同じだと思うのですが、 なぜ、このように3回の最大値を見るものがデフォルト（一般的な最適値と解釈しています）となっているのでしょうか？
例えば、直近3回の監視結果中、2回が異常ならトリガーなどだと、監視時点の一時的な不通状態でトリガーさせない甘めの監視 になりますし、この場合、復旧時には、直近の正常値を一旦保留する動作もとれるなど、動きとしては多様な監視になるとは推測 できるので、何か意味を感じられそうですが。
しかし、max（#3）にしている意味がよくわからない状態です。
以上、宜しくお願い致します。
こんにちは。
＞Template ICMP Ping:icmpping.max(#3)}=0 ＞こちらは、ICMP Pingアイテムで拾ってきた値の直近3個の最大値が０（異常終了）の場合トリガーですか？
そうですね。「三回連続で失敗したときに障害」ということになります。 # は、関数の引数で使うときは「過去何回分」、外でトリガーの比較演算子として使うときは「等しくない」、ということです。
＞例えば、直近3回の監視結果中、2回が異常ならトリガーなどだと、監視時点の一時的な不通状態でトリガーさせない甘めの監視になりますし、
それをもう少し甘くしたかったんだと思います。ネットワークが不安定なところなら二回ぐらい連続で失敗することも多かったりするのかもしれません（よく知りませんが）。 まあ、甘いか厳しいかは環境や許容範囲にもよるので、個人的には、最初から用意されているテンプレートは「一般的な最適値」というより「ちょっとお手軽に使うときに便利なもの」とか「ありがちな例のサンプル設定」程度に思っています。
hozumiさん
試してませんが…
こちらは、ICMP Pingアイテムで拾ってきた値の直近3個の最大値が０（異常終了）の場合トリガーですか？ 合っているかと…
＃の解釈として、「等しくない」とでてきたので、同いう意味か混乱しました。 分かりにくいですよね。A(^^; 英語版のマニュアルだと「sec or #num」となっているので、まだ分かりやすいのですが…
そもそも、直近3回の最大値が異常の場合とは、結局は、監視時点で異常があればトリガーすると同じだと思うのですが、 なぜ、このように3回の最大値を見るものがデフォルト（一般的な最適値と解釈しています）となっているのでしょうか？ どうしてなのかは作ったZabbix SIAさん(本家)の方に聞かないと分からないですね。A(^^; 一応、ZABBIX-JPはZabbix SIAの下部組織ではなく独立した組織なので…
ただ、3回中1回でも成功すればエラーではなくなりますので「監視時点で異常があればトリガーすると同じ」ではないです。
尚、私の見てきた環境では5回pingして全部だめだったら障害検知というような環境もありました。 その環境は時折ネットに負荷がかかってpingがタイムアウトするときがあったんです。 でも、それは障害じゃないので検知しちゃいけないんですよ。A(^^;
そう言う時には使えそうなテンプレートかなと…A(^^;
heya さん、KAZさん ありがとうございます！
＞ただ、3回中1回でも成功すればエラーではなくなりますので「監視時点で異常があればトリガーすると同じ」ではないです。
あ、なるほど。復旧時点で監視結果が正常（１）になると、直近3回のMAX値が１になってトリガーされないということですね。 なるほど、この設定だと一般的な環境では使われなさそうですね。
ZABBIXではping監視の一般的にはどのような設定になるのでしょうか？
アドバイスお願いします。
hozumiさんの想定されている一般的というのが、どのような状態を イメージされているのかわかりません。
サンプルの3回連続でping失敗したら障害とみなすというトリガー でも、さほど特殊な環境ではないと思います。
規模が大きくなったり、ネットワーク構成が複雑になったり、時間 帯によって大量なトラフィックが発生したりするような環境によっ ては、まれにpingの応答が想定した時間内に返却されない場合があ って、icmppingの値が0になる場合があります。
そのような環境では、たまたま失敗したからといって、すぐに障害 とは判定せずに、2回もしくは3回連続して失敗したら障害とみなす ように設定することもあるでしょう。
正常に稼働していれば、絶対にpingで1回も失敗することがないと いう環境であるのならば、直接、icmppingの値自体を判定するトリ ガーの条件式を設定されてはいかがでしょうか。
TNKさん
いつもながら素早い… 返信かいてら、TNKさんがもう書いてた…A(^^;
なるほど、この設定だと一般的な環境では使われなさそうですね。 監視要件次第かなと… pingが一回でもと売らないと障害とする環境では合いませんが、時折ネットの負荷があがるのでpingがタイムアウトしがちだけど通信的には問題ないのでpingをある一定回数実行して全てエラーなら障害とするならまさしくこれです。
なので監視対象によよっては一般的にも使われるかな？
ZABBIXではping監視の一般的にはどのような設定になるのでしょうか？ 一般的というキーワードにどう答えればよいのかが難しいですね。 一般的なping監視の監視要件？とZabbixの設定方法という認識で合ってますか？A(^^; あくまで参考例としてです。(2と3は今の環境で試してないです。)
1)ping実行し一回でもエラーの場合、障害と判断 icmpping.last(0)=0
2)指定回数(例えば3回)のping実行がエラーの場合、障害と判断 icmpping.max(#3)=0
3)一定期間(60秒)でpingがタイムアウトまたは、応答が遅い(例えば100ms)以上 icmppingsec.max(60)=0 | icmppingsec.max(60)>0.1
手元の環境(社内用小規模インフラ監視)では1番使ってます。 監視対象が複雑じゃないネット構成で、サーバも物理と仮想サーバが10台以下、NASとプリンタが少々と言うこじんまりとした構成なので…
DCセンターとかの監視は2番とかを使う時多いです。 まぁ、これはうちのお客さんの監視要件がそうだからなんですが…A(^^;
という訳で、一般的と言われると… 難しいですね。
監視したい対象の監視要件に合う監視するのが正しいと思いますので、テンプレートにこだわる必要無いとおもいますよー
アカウント名 hozumi
本名 hozumi tatsuya
Zabbix関連
hozumi - 投稿数: 23
追加のご質問です。
そもそも、直近3回の最大値が異常の場合とは、結局は、監視時点で異常があればトリガーすると同じだと思うのですが、
なぜ、このように3回の最大値を見るものがデフォルト（一般的な最適値と解釈しています）となっているのでしょうか？
例えば、直近3回の監視結果中、2回が異常ならトリガーなどだと、監視時点の一時的な不通状態でトリガーさせない甘めの監視
になりますし、この場合、復旧時には、直近の正常値を一旦保留する動作もとれるなど、動きとしては多様な監視になるとは推測
できるので、何か意味を感じられそうですが。
しかし、max（#3）にしている意味がよくわからない状態です。
以上、宜しくお願い致します。
heya - 投稿数: 319
こんにちは。
＞Template ICMP Ping:icmpping.max(#3)}=0
＞こちらは、ICMP Pingアイテムで拾ってきた値の直近3個の最大値が０（異常終了）の場合トリガーですか？
そうですね。「三回連続で失敗したときに障害」ということになります。
# は、関数の引数で使うときは「過去何回分」、外でトリガーの比較演算子として使うときは「等しくない」、ということです。
＞例えば、直近3回の監視結果中、2回が異常ならトリガーなどだと、監視時点の一時的な不通状態でトリガーさせない甘めの監視になりますし、
それをもう少し甘くしたかったんだと思います。ネットワークが不安定なところなら二回ぐらい連続で失敗することも多かったりするのかもしれません（よく知りませんが）。
まあ、甘いか厳しいかは環境や許容範囲にもよるので、個人的には、最初から用意されているテンプレートは「一般的な最適値」というより「ちょっとお手軽に使うときに便利なもの」とか「ありがちな例のサンプル設定」程度に思っています。
KAZ - 投稿数: 1085
hozumiさん
試してませんが…
こちらは、ICMP Pingアイテムで拾ってきた値の直近3個の最大値が０（異常終了）の場合トリガーですか？
合っているかと…
＃の解釈として、「等しくない」とでてきたので、同いう意味か混乱しました。
分かりにくいですよね。A(^^;
英語版のマニュアルだと「sec or #num」となっているので、まだ分かりやすいのですが…
そもそも、直近3回の最大値が異常の場合とは、結局は、監視時点で異常があればトリガーすると同じだと思うのですが、
なぜ、このように3回の最大値を見るものがデフォルト（一般的な最適値と解釈しています）となっているのでしょうか？
どうしてなのかは作ったZabbix SIAさん(本家)の方に聞かないと分からないですね。A(^^;
一応、ZABBIX-JPはZabbix SIAの下部組織ではなく独立した組織なので…
ただ、3回中1回でも成功すればエラーではなくなりますので「監視時点で異常があればトリガーすると同じ」ではないです。
尚、私の見てきた環境では5回pingして全部だめだったら障害検知というような環境もありました。
その環境は時折ネットに負荷がかかってpingがタイムアウトするときがあったんです。
でも、それは障害じゃないので検知しちゃいけないんですよ。A(^^;
そう言う時には使えそうなテンプレートかなと…A(^^;
hozumi - 投稿数: 23
heya さん、KAZさん ありがとうございます！
＞ただ、3回中1回でも成功すればエラーではなくなりますので「監視時点で異常があればトリガーすると同じ」ではないです。
あ、なるほど。復旧時点で監視結果が正常（１）になると、直近3回のMAX値が１になってトリガーされないということですね。
なるほど、この設定だと一般的な環境では使われなさそうですね。
ZABBIXではping監視の一般的にはどのような設定になるのでしょうか？
アドバイスお願いします。
TNK - 投稿数: 4769
hozumiさんの想定されている一般的というのが、どのような状態を
イメージされているのかわかりません。
サンプルの3回連続でping失敗したら障害とみなすというトリガー
でも、さほど特殊な環境ではないと思います。
規模が大きくなったり、ネットワーク構成が複雑になったり、時間
帯によって大量なトラフィックが発生したりするような環境によっ
ては、まれにpingの応答が想定した時間内に返却されない場合があ
って、icmppingの値が0になる場合があります。
そのような環境では、たまたま失敗したからといって、すぐに障害
とは判定せずに、2回もしくは3回連続して失敗したら障害とみなす
ように設定することもあるでしょう。
正常に稼働していれば、絶対にpingで1回も失敗することがないと
いう環境であるのならば、直接、icmppingの値自体を判定するトリ
ガーの条件式を設定されてはいかがでしょうか。
KAZ - 投稿数: 1085
TNKさん
いつもながら素早い…
返信かいてら、TNKさんがもう書いてた…A(^^;
KAZ - 投稿数: 1085
hozumiさん
なるほど、この設定だと一般的な環境では使われなさそうですね。
監視要件次第かなと…
pingが一回でもと売らないと障害とする環境では合いませんが、時折ネットの負荷があがるのでpingがタイムアウトしがちだけど通信的には問題ないのでpingをある一定回数実行して全てエラーなら障害とするならまさしくこれです。
なので監視対象によよっては一般的にも使われるかな？
ZABBIXではping監視の一般的にはどのような設定になるのでしょうか？
一般的というキーワードにどう答えればよいのかが難しいですね。
一般的なping監視の監視要件？とZabbixの設定方法という認識で合ってますか？A(^^;
あくまで参考例としてです。(2と3は今の環境で試してないです。)
1)ping実行し一回でもエラーの場合、障害と判断
icmpping.last(0)=0
2)指定回数(例えば3回)のping実行がエラーの場合、障害と判断
icmpping.max(#3)=0
3)一定期間(60秒)でpingがタイムアウトまたは、応答が遅い(例えば100ms)以上
icmppingsec.max(60)=0 | icmppingsec.max(60)>0.1
手元の環境(社内用小規模インフラ監視)では1番使ってます。
監視対象が複雑じゃないネット構成で、サーバも物理と仮想サーバが10台以下、NASとプリンタが少々と言うこじんまりとした構成なので…
DCセンターとかの監視は2番とかを使う時多いです。
まぁ、これはうちのお客さんの監視要件がそうだからなんですが…A(^^;
という訳で、一般的と言われると…
難しいですね。
監視したい対象の監視要件に合う監視するのが正しいと思いますので、テンプレートにこだわる必要無いとおもいますよー