レイテンシの最大値が60sになる(last()>=60s)という条件か、あるいはレイテンシの10分平均が20s以上になる条件。(avg(10m)}>=20s)
このようなトリガー条件にしているのですが、あまり適切でないと言われました。
適切でないというのが何が適切でないのか、分からないのですが、一般的に、どのあたりが適切でないかご意見いただけないでしょうか？
値の大きさが適切でない？最大値と平均のor条件というのが適切でない？
よろしくお願いします。
lastやavgの元となっているアイテムが、仰っている「レイテンシの数値」を 監視・取得しているアイテムなのだと推察します
しかし、何のレイテンシを示す数値なのかが示されておらず、 そのトリガー条件（障害と判断する基準）が一般的なのか、適切なのか、を 正しく把握できず、回答できません
より具体的なアイテム値の意味合いや、正常時・障害時における値の遷移の傾向など、 以下「蛇足」に挙げるような要素を書いていただければ、意見が集まるかと思います
以下、蛇足です ネットワーク通信の遅延を監視するのに良く用いられる ping 到達時間等でも 非常に安定した構内のLAN回線において「近傍に設置した機器間での通信での遅延発生を監視」する目的なのか、 LTE等、ただでさえ遅延の大きいインフラを経由したうえで、さらに広域 VPN 接続等を経由した場合のような 「遠隔地にある機器との通信の遅延発生を監視」する目的なのかで、しきい値や判定条件は 大きく変わってくると思います
実際、LAN内であれば、大半の場合は「数ms以内の値」となるはずが、混雑時は「数十ms程度の値」まで 遅延が増えることもあるでしょう
LTE回線などを経由してしまうと、「数100ms程度」が通常値でしょうけれど、時折「数秒程度」まで 増えることもあるはずです。
値の変動が発生する頻度や傾向も、状況によって大きく異なるはずです LTE等の場合であれば、時折発生する「数秒程度」を毎度毎度検知していては、 障害通知も対応も追いつかなくなるので、 「数秒程度‥の異常状態が、数分間以上、安定的に継続していた場合」などというトリガー判断条件に なるのではないかと思います
このような事例をベースに、どのような値を、どのように検出されたいのかをお示し願えますでしょうか？
広瀬です
私からも補足的な扱いで意見述べさせてもらいます。
①最大値が60sになるlast()>=60s ②10分平均が20s以上になる条件。avg(10m)>=20s
どちらの条件に関してもケースバイケースだと思います。 それぞれのトリガーの発動条件が少し異なる事はご存じの上だと思います。
※前者は閾値超えたら即時発動、後者は平均時間中に閾値を超えたらという違い
レイテンシに限定した話ではありませんが、値の揺らぎ（グラフ化すると上下動）が大きい場合ですが、前者の①側ですと
48 61 57 90 30 71
上記だと、3回はイベント発動しますね。これは負荷が特に集中する時間帯などには不向きな設定と言えます。 CPU使用率などでもヒステリシスなトリガーを使う場合がありますが、それを避ける為で使われますね
②の条件は、①に比べて10分間の平均なので、瞬間瞬間の値が20s超えても問題は無いですが、結構くせ者 で、その平均時間で極端に値が大きかった場合でしょうか。 1分間隔毎に監視していて、概ね毎回の取得値が10sだったとします。その値の中で1回でも110sが発生すれ ば即時アウトです。これは、揺らぎ幅の傾向を考慮に入れていない場合だと顕著だと思います。
※1分間隔監視として、結果が(10s × 9 + 110s)/10という単純な計算の場合です
こちらは負荷集中時間でも同じ事が言えますし、傾向を分析していない場合には不向きとも言えます。 とは行っても傾向自体は計ってみない事には解らないので、最初は20sで傾向が見えてきたら閾値を変えて いくというのが一般論でしょう。
「適切では無い」という指摘は監視対象の性質なので、当方からは何とも言えませんがモノの見方、傾向により 変わってきますので、そこを斟酌しないとダメだという事を言いたいのではないでしょうか。
ご回答ありがとうございます。
何のレイテンシかというと、AWSサービス（ＥＬＢ）のレイテンシになります。 LTE回線ではなく、AWSなのでクラウドですかね？社内LANです。（変なことを言ってましたらすみません）
「Latency Average」の月平均は205ms、「Latency Maximum」の月最大は2m53sのようです。
「Latency Maximum」の方が引っ掛かったかもしれないですが、場合によっては平均の方にも引っ掛かり、二重に発生したのが 問題と言われたのかもしれません。
最大値の瞬間ではなく、３回超えたとか、平均値がいくつかを超えたとかにした方が良いですか？ たまたま瞬間的に跳ね上がるくらいなら問題ないだろうという考えで・・・。
専門知識が不足しており申し訳ありませんが、よろしくお願いします。
お示し頂いた数値（月平均と月最大）では、広瀬様の仰っているような「値の傾向」までが 見えないため、具体例としては示しづらいです また、数値の対象となっている期間が「月」となっており、非常に長い期間のため、 短期的な障害検知のしきい値を決めるための参考情報としては、参考にしづらいです
・実測値(月平均)は 205ms ・実測値(月最大)は 2m53s
Amazon Web Services/Classic Load Balancer (AWS/ELB) を利用されており、 それに関する CloudWatch のメトリクスとして提供されている「Latency」の値で得られる 「Average」や「Maximum」の値を zabbix へ取り込んで利用されている‥ということで よろしいでしょうか？ http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-cloud...
ここで得られるレイテンシ値は、クライアントからのリクエストを ELB が受けたあとに、 内部の実サーバ群へ「リクエスト転送してから」 内部の実サーバ群で処理が完了して、「応答のレスポンスヘッダが ELB へ戻ってくるまで」の 時間を示している様子ですね
どのようなサーバが稼働していて、どのような処理をしているのかによっても、得られる レイテンシの値が変わると思いますので、「一般論」という観点で当てはめるのは 難しいかと思います
むしろ、監視する側として「どのような事象が発生したら異常とみなすべきか」を少しずつ煮詰めて トリガー検知の条件を決定・変更していくのが良いかと思います
例えば‥
仮定１．大半の応答時間は ～300ms 程度に収まっている →このようなリクエストは全て「正常」として無視して良いと決める 仮定２．軽度のアクセス集中でもせいぜい10sec程度にしかならない →このようなリクエストは、１日あたりで数回～数100回レベルで発生している →「検索」や「保存」のような重いリクエストの場合には、この程度になることも 十分考えられる範疇なので、この程度は無視して良いと決める 仮定３．日次処理や月次処理など、特定の時間帯にはバックエンドで負荷の高い処理が実施される →この時間帯については、60sec 程度まで応答が遅延することが起こりうる →単発での「検索」や「保存」のような重いリクエストの場合には、致し方ないため この時間帯についてはこの程度まで無視して良いと決める 仮定４．想定外のアクセス集中が発生した場合の検出 →定期処理の時間帯を除く通常運用時間帯において、平均応答時間が 30sec を超えるような 状態が、一定時間 (10分程度) 継続してしまった場合には、必ず「障害」として検知したい
などなど‥
ある程度想像がつく範囲で、「絶対に検出させたい異常な状況」と「無視してよい状況」を ピックアップしていったうえでトリガーの条件を決めるのが良いと思います
そのうえで、運用していくうちに「想定外の状態変化が検出できなかった事例」が出てくると 思いますので、その折に、収集されたアイテム側のデータを分析して、 さらに「トリガー条件」を再検討する‥
具体的な提案としてはお力になれず、申し訳ありません
ひとまず、一日の平均が1mを超えたら、で様子を見ることにしました。 ありがとうございました
アカウント名 hyde4272
Zabbix関連
fripper - 投稿数: 495
lastやavgの元となっているアイテムが、仰っている「レイテンシの数値」を
監視・取得しているアイテムなのだと推察します
しかし、何のレイテンシを示す数値なのかが示されておらず、
そのトリガー条件（障害と判断する基準）が一般的なのか、適切なのか、を
正しく把握できず、回答できません
より具体的なアイテム値の意味合いや、正常時・障害時における値の遷移の傾向など、
以下「蛇足」に挙げるような要素を書いていただければ、意見が集まるかと思います
以下、蛇足です
ネットワーク通信の遅延を監視するのに良く用いられる ping 到達時間等でも
非常に安定した構内のLAN回線において「近傍に設置した機器間での通信での遅延発生を監視」する目的なのか、
LTE等、ただでさえ遅延の大きいインフラを経由したうえで、さらに広域 VPN 接続等を経由した場合のような
「遠隔地にある機器との通信の遅延発生を監視」する目的なのかで、しきい値や判定条件は
大きく変わってくると思います
実際、LAN内であれば、大半の場合は「数ms以内の値」となるはずが、混雑時は「数十ms程度の値」まで
遅延が増えることもあるでしょう
LTE回線などを経由してしまうと、「数100ms程度」が通常値でしょうけれど、時折「数秒程度」まで
増えることもあるはずです。
値の変動が発生する頻度や傾向も、状況によって大きく異なるはずです
LTE等の場合であれば、時折発生する「数秒程度」を毎度毎度検知していては、
障害通知も対応も追いつかなくなるので、
「数秒程度‥の異常状態が、数分間以上、安定的に継続していた場合」などというトリガー判断条件に
なるのではないかと思います
このような事例をベースに、どのような値を、どのように検出されたいのかをお示し願えますでしょうか？
wakaba - 投稿数: 228
広瀬です
私からも補足的な扱いで意見述べさせてもらいます。
①最大値が60sになるlast()>=60s
②10分平均が20s以上になる条件。avg(10m)>=20s
どちらの条件に関してもケースバイケースだと思います。
それぞれのトリガーの発動条件が少し異なる事はご存じの上だと思います。
※前者は閾値超えたら即時発動、後者は平均時間中に閾値を超えたらという違い
レイテンシに限定した話ではありませんが、値の揺らぎ（グラフ化すると上下動）が大きい場合ですが、前者の①側ですと
48
61
57
90
30
71
上記だと、3回はイベント発動しますね。これは負荷が特に集中する時間帯などには不向きな設定と言えます。
CPU使用率などでもヒステリシスなトリガーを使う場合がありますが、それを避ける為で使われますね
②の条件は、①に比べて10分間の平均なので、瞬間瞬間の値が20s超えても問題は無いですが、結構くせ者
で、その平均時間で極端に値が大きかった場合でしょうか。
1分間隔毎に監視していて、概ね毎回の取得値が10sだったとします。その値の中で1回でも110sが発生すれ
ば即時アウトです。これは、揺らぎ幅の傾向を考慮に入れていない場合だと顕著だと思います。
※1分間隔監視として、結果が(10s × 9 + 110s)/10という単純な計算の場合です
こちらは負荷集中時間でも同じ事が言えますし、傾向を分析していない場合には不向きとも言えます。
とは行っても傾向自体は計ってみない事には解らないので、最初は20sで傾向が見えてきたら閾値を変えて
いくというのが一般論でしょう。
「適切では無い」という指摘は監視対象の性質なので、当方からは何とも言えませんがモノの見方、傾向により
変わってきますので、そこを斟酌しないとダメだという事を言いたいのではないでしょうか。
hyde4272 - 投稿数: 48
ご回答ありがとうございます。
何のレイテンシかというと、AWSサービス（ＥＬＢ）のレイテンシになります。
LTE回線ではなく、AWSなのでクラウドですかね？社内LANです。（変なことを言ってましたらすみません）
「Latency Average」の月平均は205ms、「Latency Maximum」の月最大は2m53sのようです。
「Latency Maximum」の方が引っ掛かったかもしれないですが、場合によっては平均の方にも引っ掛かり、二重に発生したのが
問題と言われたのかもしれません。
最大値の瞬間ではなく、３回超えたとか、平均値がいくつかを超えたとかにした方が良いですか？
たまたま瞬間的に跳ね上がるくらいなら問題ないだろうという考えで・・・。
専門知識が不足しており申し訳ありませんが、よろしくお願いします。
fripper - 投稿数: 495
お示し頂いた数値（月平均と月最大）では、広瀬様の仰っているような「値の傾向」までが
見えないため、具体例としては示しづらいです
また、数値の対象となっている期間が「月」となっており、非常に長い期間のため、
短期的な障害検知のしきい値を決めるための参考情報としては、参考にしづらいです
・実測値(月平均)は 205ms
・実測値(月最大)は 2m53s
Amazon Web Services/Classic Load Balancer (AWS/ELB) を利用されており、
それに関する CloudWatch のメトリクスとして提供されている「Latency」の値で得られる
「Average」や「Maximum」の値を zabbix へ取り込んで利用されている‥ということで
よろしいでしょうか？
http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-cloud...
ここで得られるレイテンシ値は、クライアントからのリクエストを ELB が受けたあとに、
内部の実サーバ群へ「リクエスト転送してから」
内部の実サーバ群で処理が完了して、「応答のレスポンスヘッダが ELB へ戻ってくるまで」の
時間を示している様子ですね
どのようなサーバが稼働していて、どのような処理をしているのかによっても、得られる
レイテンシの値が変わると思いますので、「一般論」という観点で当てはめるのは
難しいかと思います
むしろ、監視する側として「どのような事象が発生したら異常とみなすべきか」を少しずつ煮詰めて
トリガー検知の条件を決定・変更していくのが良いかと思います
例えば‥
仮定１．大半の応答時間は ～300ms 程度に収まっている
→このようなリクエストは全て「正常」として無視して良いと決める
仮定２．軽度のアクセス集中でもせいぜい10sec程度にしかならない
→このようなリクエストは、１日あたりで数回～数100回レベルで発生している
→「検索」や「保存」のような重いリクエストの場合には、この程度になることも
十分考えられる範疇なので、この程度は無視して良いと決める
仮定３．日次処理や月次処理など、特定の時間帯にはバックエンドで負荷の高い処理が実施される
→この時間帯については、60sec 程度まで応答が遅延することが起こりうる
→単発での「検索」や「保存」のような重いリクエストの場合には、致し方ないため
この時間帯についてはこの程度まで無視して良いと決める
仮定４．想定外のアクセス集中が発生した場合の検出
→定期処理の時間帯を除く通常運用時間帯において、平均応答時間が 30sec を超えるような
状態が、一定時間 (10分程度) 継続してしまった場合には、必ず「障害」として検知したい
などなど‥
ある程度想像がつく範囲で、「絶対に検出させたい異常な状況」と「無視してよい状況」を
ピックアップしていったうえでトリガーの条件を決めるのが良いと思います
そのうえで、運用していくうちに「想定外の状態変化が検出できなかった事例」が出てくると
思いますので、その折に、収集されたアイテム側のデータを分析して、
さらに「トリガー条件」を再検討する‥
具体的な提案としてはお力になれず、申し訳ありません
hyde4272 - 投稿数: 48
ひとまず、一日の平均が1mを超えたら、で様子を見ることにしました。
ありがとうございました