net.tcp.service[]のタイムアウト
Zabbix1.8.14でLinuxサーバを監視しております。
net.tcp.service[smtp]等が時折「障害(=0)」となり、実際には動作している各サービスの状況を誤認しております。
net.tcp.service[]のタイムアウトが固定値であり、変更できれば回避できそうである、という問題と認識しておりますが、間違いありませんでしょうか？
環境の再構築等は無理な状況ですので、出来ればトリガーの作り方で回避したいと考えています。
この問題を承知した上で、net.tcp.service[]を使って適切に各サービスの状況を把握するためにはどのようなトリガーを用意すべきでしょう？
1. 更新間隔を半分にして{hoge:net.tcp.service[smtp].count(#2,0)}=2
2. 更新間隔以上の時間を指定して{hoge:net.tcp.service[smtp].nodata(60)}=1
みたいな感じかと思っておりますが、試しにサービス止めて挙動を確かめる訳にも行かず…。
1.は同じ状況が連発すると結局誤認ですね。
更新間隔以下でnodata()を使って死を見ました。
更新直後のnodata()だけが=0で、その後のnodata()は全て変化無し=データ無し=1、と？
使いこなせる日は来るのでしょうか。: (
kodai - 投稿数: 1341
net.tcp.service[smtp]が障害状態になる場合は0が帰ってきますので、データ自体は存在していて、0になっている状態かと思います。nodata()は一定期間に監視データがあるかないかを判断するので、この場合は利用できません。
そのため、方法としては(1)になるかと思います。count()の1つめのパラメータで判定するデータの個数をある程度大きく取ることで障害検知に幅を持たせることができるので、システムにあわせて適切なしきい値を見つけていただくのが良いかと思います。
例:
30分以内に0(疎通不可)が4回以上ある場合に障害: count(1800,0)>3
3回連続疎通不可になった場合: count(#3,0)=3
finger5 - 投稿数: 5
返信有難うございます。
監視対象サーバでzabbix_agentd -t net.tcp.service[smtp]等の値は常に1であり、各サービスのログを確認しても停止した形跡は見当たりませんでした。
故にタイムアウト等でもサーバにて0となるものと考えてしまいました。
やはり0を返している、サービスが停止している、という事なのでしょうか、引き続き調べたいと思います。
とりあえずはcount()で対処していきます。
有難うございました。
finger5 - 投稿数: 5
監視対象サーバのcronでzabbix_agentd -t net.tcp.service[smtp]を記録しましたが、数日間常に1でありました。
エージェントのBufferSendを大きく、サーバもエージェントもTimeoutを大きく、とすると多少改善（しているような気がします）。
count()も、長い時間を設定すると、本当に停止した場合の検知が遅れますし、痛し痒しです…。
halchiyo - 投稿数: 19
はじめまして、サーバのタイムアウトは最大にして、
net.tcp.service.perf[service,,]
を利用するやり方もあります。
この場合も、最大のタイムアウトを越せば0になりますが、レイテンシのベースラインが取れますので、状況把握や設定見直しの選択肢はひろがります。
ご検討ください。