log[]キーアイテム取得不可ステータスについて
お世話になります。
アイテムのステータス変化＆動作について、ご存知の方いましたらご教授いただきたいです。
Agentを再起動後から一部ログ監視アイテム状態が取得不可に変化してしまい、有効化するも数分で不可に変化し監視不能になりました。
翌日ログローテ後に正常になったので秒間行数チェックに引っかかったと思うのですが、ログ監視するにあたり、zabbix_agentd.confのMaxLinexPerSecond、
又はlog[]キーのmaxlinesで設定した行数×監視間隔以上の行数が出力された場合の動作は管理サーバへ送信しないだけだと思っていましたが、
＋して該当アイテムの状態が取得不可へ変化するが正しい動作になるのでしょうか？
この辺りの動作に詳しい方、ご教授いただけますでしょうか
よろしくお願いいたします。
TNK - 投稿数: 4671
行数が多いだけであれば、取得不可にはならなかったと思います。
Webフロントエンドでアイテムの一覧を表示させ、取得不可になった
アイテムの×マークにマウスポインタを持って行って取得不可にな
った原因のメッセージを確認するか、エージェント側のログを確認
してみてください。
ファイルのパーミッションとか何らかの原因がわかると思います。
あと、質問をされるときは、Zabbixのバージョンやプラットフォー
ムに関する情報も記載頂いた方が良いと思います。
Qoo - 投稿数: 10
情報足らずで申し訳ありません。
追加情報記入します。
【環境】
(管理マネージャ)
OS=centos6.1 64bit
zabi-server&frontend=1.8.2
(エージェント)
OS=redhat-el6 64bit
zabi-agent=1.8.2
サーバ側に出力された取得不可エラーログは
対象アイテムのbecame not supported: ZBX_NOTSUPPORTED
エージェント側に出力されたエラーログは
cannot set position to [.*] for [/log/httpd/access]: [22] Invalid argument
Active check [log["/log/httpd/access","HTTP/1.[01]\" 500","UTF-8",]] is not supported. Disabled.
アクセスログと同じ階層にあるエラーログ＆他ノード上にある同じパスのログは正常に監視できているので
アクセス権限、アイテム設定内容による不備は考えにくいところです。
以上のことから何か不可になる他原因ってどんなことが考えられますでしょうか？
本来はdebugレベルを4にあげて調査したいのですが、ログ出力が非常に多いうえにサービス機なのでできなくて調べられないところです。
fripper - 投稿数: 495
log アイテムでは、前回のチェック時に記録したファイルサイズ位置へシークして、そこから続きを読もうとします
”cannot set position to ‥”というログが出ていることから、その位置へシーク出来なかった
（つまりローテートされたことによりファイルサイズが小さくなった）ということだと思います
このエラーにより、「not supported」へと状態が変化します
＃参照：src/zabbix_agent/active.c / src/zabbix_agent/logfiles.c
ソースを見ている限りは、シークを試す前段階の処理として、現在の実ファイルサイズを取得して、
実ファイルサイズのほうが小さければ、「前回チェック時のファイルサイズ値」を０にするような処理が
実行されているようですので、一時的に not supported になったとしても、その次以降の
チェック処理において、正常に動作するはずです
また、1.8.14 にて、2GB超のファイルサイズに対する修正が入っています
現在お使いの版はかなり古いので、最新版への更新をお奨めします
TNK - 投稿数: 4671
既にfripperさんから回答して頂いていますが、私も書いていたの
でご参考までに投稿しておきます。
というメッセージから推測するに、ログファイルのどこまでチェッ
クしたかを示す「lastlogsize」の値がおかしくなっていると思わ
れます。
通常であれば、position toの次のカギ括弧内には数値が入ります。
この値は、エージェント側からキーであるlog[]の引数で指定した
条件で指定していたログを検知してサーバに送る際に、同時にログ
ファイルの何バイト目まで読み込んだかを示す値としてサーバに送
るようになっています。
そして、サーバ側では、その値を受け取ってDB上に保存し、次のア
クティブチェックリストをエージェント側から求められた時に、そ
のファイル内の位置以降のログを読んでチェックするようにエージ
ェント側に指示するようになっています。
この値が、正常にエージェント側から送られていないか、サーバ側
で正しく保存できていないか、それともzabbix_senderなどを利用
して強制的にサーバ側に別のデータを送ったりしていないかなどの
問題が考えられます。
ちなみに、このlastlogsizeの値よりもファイルサイズが小さかっ
た場合は、ファイルが作成されなおしたと判断して、lastlogsize
の値を0に設定して、ファイルの先頭から読み込むようになってい
たはずです。
まずは、このアイテムに対してトリガーはどのように設定されてい
ますか？
もしくは、zabbix_senderなどを利用して、エージェントからのロ
グ送信以外に、同じキーに対して値をサーバに送ったりしていませ
んか？
他にも、利用されているのが、Zabbix 1.8.2とまだまだ安定してい
ない時期のバージョンを利用されているようですので、Zabbixエー
ジェントやZabbixサーバ自体の不具合の可能性も十分考えられます。
1.8系のより新しいバージョンを利用されることもご検討ください。
KAZ - 投稿数: 1085
Qooさん
すいませんが、アイテムの設定の詳細をお教え頂けますか？
アイテムの設定方法がわからないとアイテムの設定が悪いのか環境が悪いのかわからないんですが…A(^^;
なお、"Cannot set position to 〜"がログに出力されるのはシークエラーのみです。
なぜ、エラーになるかはこれだけの情報ではわかりませんが…
また、以下の認識で良いですか？
誤：zabbix_agentd.confのMaxLinexPerSecond
正：zabbix_agentd.confのMaxLinesPerSecond
MaxLinesPerSecondを設定しているならconfもお教え願えませんか？A(^^;
1.8のマニュアル見ると下記になってます。
log[file,<regexp>,<encoding>,<maxlines>,<mode>]
log["/log/httpd/access","HTTP/1.[01]\" 500","UTF-8",]
最後のカンマ不要じゃないですか？
また、細かいですが正規表現そのままだと…
「HTTP/1@1"500」とかもヒットしますよ？
「"HTTP/1\.[01]\" 500"」ではないかと…A(^^;
2014/05/14 06:40 誤記修正
Qoo - 投稿数: 10
fripperさん TNKさん KAZさん
皆様忙しい中ご教授ありがとうございます。
お伝えしたしたバージョン情報に誤りがありました。
1.8.2.ではなく正しくは1.8でした。混乱させてすいません。
■>>fripperさん
>一時的に not supported になったとしても、その次以降のチェック処理において、正常に動作するはずです
そう思っていたのですが、不可→手動で有効化→数分後不可→手動で有効化を繰り返しても状態が変化せずで混乱しているところです。
>また、1.8.14 にて、2GB超のファイルサイズに対する修正が入っています
無知うえよくわかりませんが、ログサイズなどで不具合や制約があったりするのでしょうか？
と言うのも監視ログが非常に大きなサイズで日あたり4GB位になります。
■>>TNKさん
>通常であれば、position toの次のカギ括弧内には数値が入ります。
カギ括弧内の数値が何を表すのか認識できていなかったので[.*]と表記してました。
正しくは以下のように正しく位置パラメタは取れていたようです。
「cannot set position to [-928739383] for [/log/httpd/access]: [22] Invalid argument」
>まずは、このアイテムに対してトリガーはどのように設定されていますか？
>もしくは、zabbix_senderなどを利用して、エージェントからのログ送信以外に、同じキーに対して値をサーバに送ったりしていませんか？
アイテム＆トリガは以下のように設定しており、他のキー(snmptraps)に対してzabbix_senderは使用していますが、それ以外が使用していません。
同アイテムでサーバ4台から値を集めており、負荷分散の関係でログ出力の少ないサーバは正常に値収集でき、出力の多いサーバだけは不可に状態遷移してしまっています。
アイテム:(監視周期：60秒)
log["/log/httpd/access","HTTP/1.[01]\" 500","UTF-8",]
トリガー:
{node01:log["/log/httpd/access","HTTP/1.[01]\" 500","UTF-8",].iregexp(@exclude-list)}=1
■>>KAZさん
>また、以下の認識で良いですか？
>誤：zabbix_agentd.confのMaxLinexPerSecond
>正：zabbix_agentd.confのMaxLinesPerSecond
>MaxLinesPerSecondを設定しているならconfもお教え願えませんか？A(^^;
正しくは[zabbix_agentd.confのMaxLinesPerSecond]です。
デフォルト100→500へ変更しています。MaxLinesPerSecond=100 → MaxLinesPerSecond=500
監視対象のログを調べたところ、アイテム監視周期(60秒)毎の出力量が平均2万行位あったので余裕持って500へ変更しました。
他の設定部分はデフォルトから基本部分(hostname：server)を抜いてLogRemoteCommandとAllowroot部分しか変更していません。
>また、細かいですが正規表現そのままだと…
>「HTTP/1@1"500」とかもヒットしますよ？
>「"HTTP/1\.[01]\" 500"」ではないかと…A(^^;
ご指摘のとおり記述ミスです（汗）
fripper - 投稿数: 495
取り急ぎ私宛で頂いた部分について
>>一時的に not supported になったとしても、その次以降のチェック処理において、正常に動作するはずです
>そう思っていたのですが、不可→手動で有効化→数分後不可→手動で有効化を繰り返しても状態が変化せずで混乱しているところです。
「ここまで読込完了しました」の値がうまく更新されておらず、同じ処理へ陥ってしまっているのではないかと想像します
>>また、1.8.14 にて、2GB超のファイルサイズに対する修正が入っています
>無知うえよくわかりませんが、ログサイズなどで不具合や制約があったりするのでしょうか？
>と言うのも監視ログが非常に大きなサイズで日あたり4GB位になります。
前回チェック時の「ここまで読込完了」の位置情報と、今回チェック時点でのサイズ値との比較段階で
32bit signed integer の値として比較してしまっているソースコードがあり、2GB を超えた時点で
マイナス値として扱われてしまい、正常な比較処理ができなかった、という不具合があって
1.8.14 にて、その動作に対する対策が施された、ということになります
ログチェック関連、ご利用されている 1.8 初版から、現行 1.8 系最新版までの間に
かなりの改修が入っています
現時点で、ログファイルのサイズもかなり大きいようですし、複数の改修の結果、動作が改善されている
可能性が大きいです
1.8 初版のままで、うまく動作しない、とご報告戴いても、「どこが悪いのか」「最新版にすれば改善するのか」など
私自身も保証はできかねます
ただ、「最新版にしたけれど、こういう条件下で、こういう現象が起こる」がはっきりすれば、本家開発チームへ
改善要望、バグ報告等もできると思いますので、ぜひ、最新版にしてください
Qoo - 投稿数: 10
■>>fripperさん
解りやすい解説ありがとうございました。
今一度値の格納検証してlastlogsizeの変化など見てもう少し被疑箇所の当たりつけてみます。
1.8版内だけでもかなり改修されているようなので、やはり少しずつでもアップデートする方向で検討進めてみます。
fripper - 投稿数: 495
先ほどの投稿時に、全部見ておらず、見落としていました
＞「cannot set position to [-928739383] for [/log/httpd/access]: [22] Invalid argument」
前回の投稿時点で「．＊」と書かれていた部分、マイナス値になっているようなので、
やはり、1.8.14 にて対応されたログサイズ2GB超時の不具合に引っ掛かっているのだと思います
最新は 1.8.20 がリリースされていますので、こちらを採用してみることをお奨めします
KAZ - 投稿数: 1085
Qooさん、fripperさん
■>>fripperさん
また、1.8.14 にて、2GB超のファイルサイズに対する修正が入っています
現在お使いの版はかなり古いので、最新版への更新をお奨めします
↓これでしょうか？
[ZBX-5027] ログファイルが2GB以上だった場合にエラーを返すようにログ監視にファイルサイズのチェック処理を追加
バグレポート見てきましたが以下の対応になってます。
But this doesn't matter.The problem is indeed atoi().We decided to fix agent.1.8 agent will always fail and return ZBX_NOTSUPPORTED if log file size is over 2 GB.
■>>Qooさん
2GB以上のログ監視ができるのはZabbix2.0からのようです。
[ZBXNEXT-1220] 2GB以上のログファイルの監視をサポート
Qoo - 投稿数: 10
fripperさん KAZさん
原因＆解決策がわかったので大変助かりました。
アップデートするまでは zabbix[items_unsupported] と vfs.file.size キーなどで工夫して監視するようにしてみます。
本当に長々お付き合いいただきありがとうございました。
fripper - 投稿数: 495
>KAZ さん
＞[ZBX-5027] ログファイルが2GB以上だった場合にエラーを返すようにログ監視にファイルサイズのチェック処理を追加
はい、ご指摘の issue です
＞バグレポート見てきましたが以下の対応になってます。
＞But this doesn't matter.The problem is indeed atoi().We decided to fix agent.1.8 agent will always fail and return ZBX_NOTSUPPORTED if log file size is over 2 GB.
申し訳ありません、てっきり修正されたものだと思い込んでおりました
「1.8系では修正不能、2.0系以降にて正式対応」という対応になっていたのですね
改めてソースコードを追いかけてみたところ、負の値になってしまった時には、
従来、負であるにも関わらず比較し、「Invalid argument」のエラーがログに記録されるような
処理となってしまったうえで、誤動作した結果として「NOTSUPPORTED」となっていたところ
正しく「負の値である」とチェックされたうえで、「NOTSUPPORTED」になるようなカタチに
修正が入っていただけのようです
これを「NOTSUPPORTED」にならないようにするには、agent 側を 2.0 系以降にするしか
方法は無さそうですね‥
KAZ - 投稿数: 1085
Qooさん
vfs.file.sizeも2GBはZabbix2.0から対応のようです。
[ZBX-3151] vfs.file.size[]アイテムが2GB以上のファイルの監視をサポート
Qoo - 投稿数: 10
KAZさん
追加情報ありがとうございました。
[ZBX-3151] 自分でも確認してみました。（泣
早急にアップデートするよう調整してみます。