外部チェック(独自スクリプト)による監視とエージェントによる監視をしているのですが、たまに一部の監視だけ突然監視しなくなり、監視データタブの概要の画面でトリガがグレーになってしまいます。
データを確認するとデータを取得していませんでした。
設定タブのアイテム画面を確認しましたが、ステータスは有効になっていました。
監視しなくなるアイテムはタイプに限らず、発生します。
またそのホストの他のアイテムは問題なく監視されています。
原因や解決法などあれば教えて下さい。
ちなみに取得不可アイテムの更新間隔(秒)は60秒に設定しています。
TNK - 投稿数: 4734
取得できていない時にエージェント側のログに何か出力されていませんか?
また、利用されているZABBIXのバージョンや監視しなくなるアイテムの具体例も挙げて頂けませんでしょうか?
よろしくお願い致します。
peyon - 投稿数: 38
ありがとうございます。
バージョンは1.6.8です。
1.4の時も同じ現象が起きてました。
監視しなくなった辺りのzabbix_server.logに
Executing housekeeper
Deleted 0 records from history and trends
がありました。
アイテムはzabbixエージェントはsystem.cpu.loadやproc.numやsystem.runで外部チェックはスクリプトによる監視です。
現象はどちらの監視でも起きています。
また、あるエージェントのログには
In send_buffer('xxx.xxx.xxx.xxx','10051')
Values in the buffer 0 Max 100
Sleeping for 1 seconds
とあります。
zabbix_server.confの設定がおかしいのでしょうか。
peyon - 投稿数: 38
[管理タブ] >> [キュー] >> [詳細]で更新されるアイテムのキューに監視が止まっているアイテムが表示されていました。(溜まっていた)
何かが原因で「次のチェック」の日時に更新されなかった(監視されなかった)のだと思われます。
「次のチェック」の日時が通常は次に更新する日時(未来の日時)が表示されると思いますが、現在時刻より前の日時が表示されています。
この原因やキューが溜まらないようにするにはどうすれば良いですか?
TNK - 投稿数: 4734
デフォルトでは、サーバ上で1時間ごとにhousekeeperという古い監視データの削除が実行されます。
その処理が重くて監視データが欠ける場合があるようです。
サーバ側でも負荷を軽減するチューニングが必要になるとは思いますが、1.6.8であれば、zabbix_agentdの設定で、
・BufferSend
・BufferSize
というパラメータが設定できるようになっています。これらの値を調整することで改善できるかもしれません。
BufferSendは、設定されている値以上の秒数はバッファ内にデータをキープしないという設定で、BufferSizeは、バッファ内に何個データを保存するかという設定のようです。
あくまでも仮定ですが、サーバ側のhousekeeperの処理の負荷が高くてエージェントからのデータを受け取れず、サーバが受け取る前にバッファにキープしておける時間を超過し、データが破棄されてしまったことが考えられます。
デフォルト値は、BufferSendが5秒、BufferSizeが100個に設定されているようですので、まずは、BufferSendの値を、30秒とか伸ばしてみてはいかがでしょうか?
30秒に指定する場合は、zabbix_agentd.confに
<code>
BufferSend=30
</code>
と記述するようです。
peyon - 投稿数: 38
ありがとうございます。
ZABBIX Serverのメモリを監視したところ、1時間ごとのhousekeeper実行時間辺りにFree Memoryが少なくなっていることを確認しました。
zabbix_server.logを見たところ
Executing housekeeper
Deleted 0 records from history and trends
がありました。
「Deleted 0 records from history and trends」というのはヒストリもトレンドも削除されなかったということだと思いますが、削除されなかった(古いデータはなかった)場合でも処理による負荷は高いものなのでしょうか?
古いデータを抽出する処理が負荷が高いのですかね?
peyon - 投稿数: 38
すみません。
実行SQLを調べましたところ、
select ・・・
from hosts h, items i where i.nextcheck<=1265703629 and h.hostid=i.hostid and h.status=0 and i.status in (0,3) and ((h.disable_until<=1265703624 and h.errors_from=0 and i.type in (0,1,4,6)) or i.type in (3,5,8,10,11)) and (h.proxy_hostid=0 or i.type in (5,8)) and ★mod(i.itemid,5)=4★ and i.key_ not in ('status','icmpping','icmppingsec','zabbix[log]') order by i.nextcheck
上記のSQL文の★で囲んだ部分、mod(i.itemid,5)=4とありますが、この部分を
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
というように実行しており、
正常な場合は、0、1、2、3、4(順不同)というように0〜4まで全て実行されてるようですが、キューが溜まっている状態の場合は0、1(順不同)しか実行されていませんでした。
データを調べると監視していないアイテムのitemidを5で割った余りは全て2か3か4でした。
余りが0か1のアイテムは監視されていました。
どうすれば良いですか?
KAZ - 投稿数: 1085
peyonさん
ソースを少々見てみました。
<code>
上記のSQL文の★で囲んだ部分、mod(i.itemid,5)=4とありますが、この部分を
</code>
上記は下記の様なソースになってます。
<code>
ZBX_SQL_MOD(i.itemid,%d) "=%d
</code>
最初の%dは「CONFIG_POLLER_FORKS」、最後の%dは「poller_num-1」でした。
CONFIG_POLLER_FORKSはzabbix_server.confのpollerの起動数かと。
推測になりますが、itemidをpollerの起動数で割った余りの値をがどのpollerで対象のアイテムを監視するのか割り当ててあるのかと。
つまり、監視で2,3,4に割あたっている物に重い監視が割あたっているんじゃないかと…