毎週土曜日の3時にCPU使用量が増える
CentOS5
Zabbix 1.8.8を使用しています。
このZabbixが毎週土曜日の3時になるとCPU使用量が増加し、
Webコンソール画面が応答しなくなる事象が発生しています。
1時間ほどで自動復旧します。
Zabbixインターナルで「zabbix[process,"unreachable poller",avg,busy]を設定し、
状況を確認すると、該当時間帯は100％になっています。
→/var/log/messagesには特にエラーなし
→/var/log/zabbix/zabbix_server.logにも特にエラーなし（debugレベルは3です）
→tcpdumpコマンドでパケットキャプチャをしたのですが、特に異常と思われる状態には見えない
Zabbixのプロセスだけ100％になっているので、
Zabbixで何かが起きていることだけは分かっているのですが、それ以上が
分からない状態になっているので、なんとか解明したいのですが・・・
考えられること
・Zabbixのデータベースで何か内部処理を週１回実施していないか
・アイテムがたまたま週１回重なる
ログのデバッグレベルを４にして状況を見るしかないかなと思ってますが、
他に何か思い当ることがあればアドバイスいただければと思います。
TNK - 投稿数: 4671
Zabbix自体には週1回処理を行うような機能はありません。
1.8.8でデフォルトの設定であれば、1時間に1回Housekeeperという
主に保存期間を過ぎた古い情報を削除する処理が動くようになって
います。
zabbix_server.logに開始と終了のタイミングでログが出力されて
いるはずです。
もし、この処理で問題になっているようであれば、その時間帯の削
除件数が大量となっている場合が考えられなくはないのですが、ロ
グ上の削除件数とかは、他の時間帯との大きな差はありますか？
ZabbixのHousekeeperの処理時の影響でないのであれば、何らかの
別の処理をその時間に行うように設定されていないかを再度ご確認
ください。
ちなみに、CentOS 5のデフォルトであれば、毎週日曜日の4:22に、
/etc/cron.weekly
以下のスクリプトの実行が行われるように設定されていると思いま
すが、同様の設定が土曜日の3時に設定されていませんでしょうか？
/etc/crontabなどの内容や/var/log/cronなどのログも確認してみ
てください。
その処理内容によっては、Zabbixの値取得の処理でタイムアウトが
発生してリトライが多く発生したり、他の処理でのディスクのI/O
の増加によって、データベースのレスポンスが低下するような場合
にも、Zabbix自体のパフォーマンスが影響されることがあります。
tomi12120321 - 投稿数: 105
ご回答ありがとうございます。
Housekeeperの処理が実行されていることが確認できましたが、
件数は他の時間帯とは大きな違いはありませんでした。
※実行タイミングも毎時40分頃だった為、時間が少しずれていました。
ご回答いただいた
/etc/cron.weeklyや/var/log/cronも確認しましたが、特に他の時間帯と
異なることはされていませんでした。
※設定はデフォルトでした
ということはZabbixサーバ上ではなく、監視対象サーバ側の要因なのでしょうか。
・Agent応答がない→キューが溜まる→Agent復旧後に大量処理→CPU上昇
メンテナンス時間がいくつかのサーバで設定されていました。
土曜日に全部で4つ設定されていたのですが、開始時間がずれているのでこれは関係ないですよね。
メンテナンス時間から逆算して何かするなんてことはないですよね。
開始時間 時間
5:00 59分
4:30 29分
4:00 1H59分
4:30 29分
大変お手数ですがご確認いただけますでしょうか。
KAZ - 投稿数: 1085
tomi12120321さん
TNKさんも指摘してますが…
/var/log/cronとそのローテーションしているログで土曜日のその時間に動いているのありませんか？
tomi12120321 - 投稿数: 105
KAZさん
ご連絡ありがとうございます。
その時間帯に動いている処理はあるのですが、他時間帯にも動作しているので
土曜日AM3:00だけZabbixのCPU使用率が上昇することと結びつかないかなと考えています。
TF0814 - 投稿数: 49
>Zabbixインターナルで「zabbix[process,"unreachable poller",avg,busy]を設定し、
>状況を確認すると、該当時間帯は100％になっています。
横槍すいません。
的外れな事を言ってるかもしれませんが、この一文が引っかかったので・・・。
そもそも、unreachable pollerのbusy率を確認しようとするということは、
その負荷が上昇する時間帯に、監視対象ホストがダウン等することを
分かっていて設定されていませんか・・・？
土曜日の3時に監視対象ホストを、定期メンテ等で停止させてるとか・・・？
unreachable pollerのbusy率が上がるということは、監視対象ホストからの
応答がなく、リトライするような処理？でbusy率が上がるという認識です。
もしそういう定期メンテの運用があるのであれば、
該当時間をメンテナンス時間として設定すれば良いのではないでしょうか。
tomi12120321 - 投稿数: 105
TF0814さん
ご連絡ありがとうございます。
ご指摘いただいた点ですが、、すいません、理解しておりませんでした。
内容を見ると仰る通りですね。
状況的に対象ホストを選定するのは難しいので、（チャレンジはしますが）
Poller数をあげて様子を見てみようと思います。
KAZ - 投稿数: 1085
unreachableのログはログレベル=3で出るはずです。
Zabbixサーバのログをgrepするとunreachableのホスト分かるかと…
tomi12120321 - 投稿数: 105
KAZさん
ありがとうございます。
確認してみたのですが、「host unavailable」は見つかりませんでした・・・
ということは、、agent監視ではないホストでしょうか。
zabbix[process,"unreachable poller",avg,busy]以外に各pollerの状態をみれば
何かわかりますでしょうか。
poller/http poller/icmp pinger/self-monitoring/trapper
KAZ - 投稿数: 1085
tomi12120321さん
1.8.8のソース確認しました。
「host unavailable」は2.0以降みたいです。
1.8.8では「Disabilng xxxx host [xxxxx]」と出るみたいです。
すいません。