Queueに溜まり監視ができなくなる
お世話になります。
FreeBSD 8.0上でportsからZabbix 1.8.1をインストールしDBとしてpostgreSQLを利用しています。
SNMPv1を8個、監視項目約1200、SNMPv2を14、監視項目2800程度の監視をしています。
監視開始後、1-2時間では、Queueをみると5sec以内に10-50位たまり、順調にはけるのですが、感覚的に1日前後監視を行っていると10分以上のDelayに600個程度(SNMPv2)たまり、その後、一切監視をしているように見えません。
Latest Dataを見ても更新されません。
このような状態に陥ってしまうと、agent/serverの再起動を行うしかないよなのです。
Pollerは16個設定しています。
どなたか似た様な状況に陥った方はいませんか?
kodai - 投稿数: 1341
こんにちは。
データベースのパフォーマンスが出ていないのかもしれないですね。
色々原因は考えられるのですが、ひとまずZabbixサーバのログには何か関連しそうなログは出ていないでしょうか。
peyon - 投稿数: 38
すみません。
以前、下記のスレッドを立てましたがこのスレッドと同じ現象です。
更新されるアイテムのキューが溜まってしまう(一部の監視が突然監視しなくなる)
http://www.zabbix.jp/modules/newbb/viewtopic.php?topic_id=395&forum=8
Pollerは5に設定しています。
関連しそうなログですが、1秒毎に実行しているSQLのログがありました。
mod(i.itemid,5)=0
mod(i.itemid,5)=1
mod(i.itemid,5)=2
mod(i.itemid,5)=3
mod(i.itemid,5)=4
mod(i.itemid,5)=0
mod(i.itemid,5)=1
mod(i.itemid,5)=2
mod(i.itemid,5)=0
mod(i.itemid,5)=1
mod(i.itemid,5)=2
mod(i.itemid,5)=0
mod(i.itemid,5)=1
mod(i.itemid,5)=2
mod(i.itemid,5)=4
mod(i.itemid,5)=4
mod(i.itemid,5)=0
mod(i.itemid,5)=1
mod(i.itemid,5)=2
mod(i.itemid,5)=4
mod(i.itemid,5)=0
mod(i.itemid,5)=2
mod(i.itemid,5)=4
mod(i.itemid,5)=0
mod(i.itemid,5)=2
mod(i.itemid,5)=4
mod(i.itemid,5)=1
mod(i.itemid,5)=0
mod(i.itemid,5)=1
mod(i.itemid,5)=2
mod(i.itemid,5)=4
mod(i.itemid,5)=0
mod(i.itemid,5)=1
mod(i.itemid,5)=2
mod(i.itemid,5)=4
初めは0〜4まで実行していますが、途中でmod(i.itemid,5)=3であるSQLが実行されなくなっています。
何か原因わかりますでしょうか?
KAZ - 投稿数: 1085
peyonさん
調査したのに私事が忙しくて返信遅れました。
すいません。
重たい監視がプロセス3で実行されていると思われます。
調べたところ、プロセス0-4の5つにitemid単位に処理を割り振っています。プロセス3に割あたる監視に重い物があり、そこでqueueが溜まっていると思います。
itemidを5で割って3が余るitemidを調べ重たい監視を止めれば取り敢えず、queueはたまらなくなるかと思います。
peyon - 投稿数: 38
ありがとうございます。
スクリプトによる外部チェックが重そうな監視かなと思いました。
スクリプトの処理の一部です。
重そうなのがあれば教えて下さい。
■ fsockopenを使った監視
// タイムアウトは30秒
$fp = @fsockopen($host,$port,$errno,$errstr,30);
if(!$fp){
/* 接続エラーなどの処理 */
}else{
/* 結果取得処理 */
}
■ 不正中継チェック(実際にメールを送信してみる)
require_once("Mail.php");
...
$ret = $mail -> send($recipients,$headers,$body);
■ パケットロスの取得
$ret = shell_exec("ping -q -n -c 10 xxx.xxx.xxx.xxx | grep 'packet loss'");
// $retからパケットロスを取得する
...
お願いします。
KAZ - 投稿数: 1085
peyonさん
itemsテーブルのitemidを5で割って3余るのが重い処理なのでそれが下記の3個と言うことでしょうか?
スクリプトの最初と最後に時間をログ出力するようにしてかかった事項時間出せば、どれが遅いかわかると思いますけど。
また、あるかたまり単位に監視を有効にしてQueueが溜まる処理を見つけるのが確実だと思いますよ。
スクリプトとかは実行環境によって動作じたい左右されると思いますので、聞かれても返答し辛い様な…
kodai - 投稿数: 1341
zabbix_server.confのTimeoutは何秒に設定されているでしょう?以前、重い監視処理がある場合に毎回タイムアウトになってしまいキューに溜まることがありました。ただ、その場合でもキューに溜まるのは重い監視だけで、後続のアイテムが次々溜まるということはありませんでしたが。
また、監視データをデータベースに保存する処理が追いつかなくてもキューに溜まることがあります。PostgreSQLでzabbixを使ったことがないのですが、データベースの負荷具合はどうでしょうか?
peyon - 投稿数: 38
Timeoutは30秒です。
私も毎回タイムアウトになってしまうアイテムはキューに溜まることがありましたが、今回は後続のアイテムが次々溜まっています。
データベースはMySQLを使っています。
負荷具合は問題無いと思います。
peyon - 投稿数: 38
追加ですみません。
単純な質問ですが、プロセスが強制終了してしまう原因て何が考えられますでしょうか?
KAZ - 投稿数: 1085
peyonさん
すいませんが、1スレ1質問で御願いします。
また、「プロセスが強制終了してしまう」と言うのは何のプロセスが強制終了する事を聞きたいのですか?
KAZ - 投稿数: 1085
peyonさん、kodaiさん
何個か前に書きましたが、1.8はitemidを5で割ったあまりの単位に処理を割り当てているので、同じプロセスに割り当たった物はqueueに溜まるはずです。
例えば、itemidが3,8,13の処理でどれかが重ければその他もqueueに溜まるはずです。
kodai - 投稿数: 1341
なるほど。まだソースを読めていないのですが、上記の処理だと1つの外部チェックの処理が重くて毎回タイムアウトすると、後続のポーリング監視もキューに溜まりますね。
KAZさんが言われている通り、外部チェックで実行しているスクリプトがタイムアウトしていないかどうか確認をされた方が良いですね。
あと、Zabbixサーバの監視タイムアウトの最大値が30秒なので、スクリプト側のタイムアウトを30秒よりも短くした方が良いです。スクリプト側でタイムアウトになる前にZabbix側のタイムアウトが来てしまうとリトライが発生してキューが溜まる原因になります。
peyon - 投稿数: 38
監視ができなくなるのはitemsテーブルのitemidを5で割った余りが3のアイテムだけが監視できなくわけではなく、1の時もあれば2の時もあります。
上記の3つはスクリプトの基本的な処理です。
これをzabbixサーバーに置いて、50台ほど外部チェックにより監視しています。
KAZ - 投稿数: 1085
peyonさん
下記の話を前提にしていたのですが…
3つのスクリプトですが、手動実行するとどのくらいの時間で処理が帰ってくるのですか?また、全てのホストで実行速度はある程度一定ですか?
あまり遅いようなら、cronでスクリプト実行し結果をログに出力してzabbixでログを監視するようにした方が良いのではないですか?