ログ監視処理について
お世話になっております。
とりあえず環境は前からさほど変わっていませんが、書き連ねます。
OS:Asianux3 SP2
zabbix 1.8.1 (ソース)
Apache 2.2.14
php 5.3.1
mysql 5.0.90
mem:512MBのVMサーバ
監視対象サーバ:5サーバ(自分含む)
監視アイテム総数：395(有効:281無効:114)
1サーバあたりの監視数：70or85
上記の状態で監視を行っていたところmysqlのプロセスが
CPUリソースを食い潰すという事象が発生しました。
原因を調べていたら
「大量にログ吐く/var/log/messagesの監視」
が原因と分かりました。
そこで必要ないログをフィルタしようかと考えたのですが、
zabbixでは、hobbitみたいなログのフィルタリストみたいな事
は可能なのでしょうか。
もしくは検知に必要なログを、同じログファイルに対して複数個
監視アイテムとして正規表現で記述するべきなのでしょうか。
現状のログアイテムは下記のようになっております。
キー：log[/var/log/messages]
ヒストリ:7日
監視間隔:300秒
ところでもう一つ質問ですが、/var/log/messagesを週1回
でローテートしている場合、ヒストリの保存期間は7日以上は必要ないですよね…
また、障害が起こったときは、デフォルトの設定だと
そのログが365日保存されるという認識でいるのですが
合っていますでしょうか。
KAZ - 投稿数: 1085
kugu_kuguさん
下記でフィルタリングできますよ。
<code>
キー：log[/var/log/messages,収集キーワード]
</code>
複数の場合はパイプで繋げて下さい。
<code>
キー：log[/var/log/messages,収集キーワード1|収集キーワード2]
</code>
kugu_kugu - 投稿数: 19
追加質問で申し訳ないのですが、否定条件でも可能でしょうか？
つまり「一致したキーワードは収集から除外する」という感じです。そのキーワードも１つ２つじゃなく、20前後あるのですが。
KAZ - 投稿数: 1085
kugu_kuguさん
どちらも、やったことありません。A(^^;
ちなみに、否定でor(論理和)使うと全て許容することになるかと…なので、|(パイプ)は使えませんね。
私がやっている中で一番長いのが↓です。
<code>
log[/var/log/messages,crash|Drive Array Device|FATAL|panic|error|segfault]
</code>
実際は「FATAL : なんとか」「FATAL : こんとか」「なんとか error うんたら」「なんとか error かんたら」とかを引っかけてます。
パフォーマンスが落ちない程度にログが読めれば良いと割り切ってみるのも手かと…
ちなみに、色々なアプリのログをsyslogで集めてるんでしょうか？
それとも１つのアプリの出力が２０前後のキーワードがあるんでしょうか？
いろんなアプリのログだったらsyslog.confで出力先分けるのは運用的にダメなのでしょうか？
kugu_kugu - 投稿数: 19
サーバの標準として
ハードウェアのログ等のサーバによって環境が違うものを
全て/var/log/messagesに出力をしてしまってるので
アプリ毎にsyslog.confで出力をという運用は難しいです。
となると、否定条件のorができないとなると、
トリガーの条件＋「error」、「Fail」、「fatal」
みたいなパターンで、肯定条件＋パイプのorでつなげるしかな
さそうですね。
あと小ネタですが「FATAL」と「fatal」の大文字小文字で2パターンがあった場合、２つ条件を連ねるしかないのでしょうか。英字の
大小を無視するというオプションがあったりしますでしょうか。
KAZ - 投稿数: 1085
kugu_kuguさん
試したことないですが、正規表現が通じるかもしれません。
下記は私見としてなので読み飛ばして頂いて結構です。
うーん、そのログを監視するのはかなりのリソースを食いそうですね…A(^^;
syslogはlocal0-7位でしか分割できませんし…
syslog-ngならキーワードでログが分割できますけど…
できるだけログは分割した方が色々とパフォーマンスは良くなると思います。
また、業務用アプリとサポートが受けれるミドルウェアのログは分けていた方がサポートに出す時にログを分割しないで済むので運用が楽になるのかなとも思います。
「ログからとあるアプリのとある時間のログを抽出して下さい。」なんて言われる時があるのですが、秒間数100行以上でているログから選び抜く作業は脱力ものですし…
javaやphpのアプリはLog4系のログ出力ライブラリがあるので、もし使用しているならmessagesにログを出力しない方が後で便利かと思います。(日時付きファイルの扱いは1.6系では困りものですが…)
kodai - 投稿数: 1341
こんにちは。
もし、I/O負荷が高くない状態でMySQLがリソースを食いつぶしているようでしたら、MySQLのチューニングで改善できる可能性があります。というより、OSに付属しているMySQLそのままでは割当メモリが少ないため実用的ではないと思います。
Zabbixは監視したログデータをMySQLに溜めるので、ログの保存場所として使うという意味では長期間保存しても良いと思います。障害検知としてだけ利用するならヒストリの保存期間は1日でも問題ありません。
アイテムの設定だけではあまり複雑なことはできないので、
1. アイテムであらかじめエラー文字列が含まれている行だけをデータベースに取り込むようにフィルタする
2. トリガーで除外条件やより詳細な障害条件を設定する
といったようにトリガーも組み合わせて設定を考えた方が良いと思います。
ちなみに、1.8からは複雑な文字列マッチ条件を設定できる「正規表現」機能が追加されています。これを利用すれば、ログ監視の際の複雑な文字列検知の条件を作成できるようになります。
kugu_kugu - 投稿数: 19
kodaiさん、KAZさん
返答ありがとうございました。頂いたお返事を元に
約9万行、9M程度の/var/log/messagesを対象に
下記アイテムでフィルタしようかと試みたのですが
やっぱりmysqlのCPUリソースを食い潰してしまいました。
大半のログはフィルタの条件に一致しないのでログは収集されない
はずなのですが…
キー：log["/var/log/messages","CRITICAL|WARNING|Fail|fail|shutdown"]
ヒストリ:7日
監視間隔:300秒
mysqlの設定を見返したのですが、問題があるであろう
箇所は見当たらず、ログ処理以外は普通にこなせており、
行数が少ないログについては、ログ監視も問題無かったです。
ひょっとして、新たにログアイテムを追加した際に、ログファイルの内容にフィルタをかける為、
DB上で全て読み込もうとしてしまう仕様等にはなっていないのでしょうか。
という事で、現状は/var/log/messagesに対するログの種類を
解析し、不必要なログをなるべく出さないように設定し、
ローテート後、再度ログ監視させるように設定しようと思っています。
(最初からそうすればいいと言われれば、それまでなのですが。)
(そうなると元ファイルの行数や容量が多いログファイルの監視はリソースを大量にとらないとできない、
ではかなり困ってしまうので質問させていただきました。)
正規表現というのは
http://www.zabbix.com/documentation/1.8/manual/config/regexps
に書かれているものでよろしいでしょうか。となると例えば「message_exp」という正規表現項目を作り
キー：log["/var/log/messages",@message_exp]
とすると、複雑なフィルタも可能になるという事でしょうか。
とりあえず試した方がよさそうですかね･･･
KAZ - 投稿数: 1085
kugu_kuguさん
DBのタイプはInnoDBでしょうか？
通常MySQLのデフォルトはMyISAMで、Zabbix的にはInnoDBの方がパフォーマンスが(圧倒的に)良いです。
最初っから読み直しが入るかも知れませんが、DBには読み込まないです。確か、Zabbixエージェントからデータも送られてこなくなるような…
kugu_kugu - 投稿数: 19
お早い返事ありがとうございます。
DBはinnoDBです。念の為show table statusや、裏にphpmyadmin等を入れて確認しました。Apacheやwebフロントエンドも同時に動いてるので多少自重していますが、innodbバッファも総容量の1/4以上のメモリを与えてます。やっぱVMサーバのメモリ512MBというのに無理がありますかねぇ･･･
何をDB内で処理しているのかなと、CPU使用率が100％時に「show processlist」で確認したら、下記のようなクエリを大量に処理していました。(XXXXXは流石に伏せさせてください)
select value from history_log where itemid=XXXXX order by id desc limit 1;
KAZ - 投稿数: 1085
kugu_kuguさん
innodb_file_per_tableは有効になっていて、テーブル単位にファイルが分割されている状態でしょうか？
そうじゃないとInnoDBでもパフォーマンスが悪いです。
かなり厳しいかと。
特にログ監視がいっぱいあると厳しいですね。
kugu_kugu - 投稿数: 19
innodb_file_per_tableは有効になってません。data1に512MB,data2に128M毎extendですね。
現状/var/log/messagesのログ監視が5サーバ分だけなのですが…
それでもログ監視はパワーを喰うってところですかね。
KAZ - 投稿数: 1085
kugu_kuguさん
それはパフォーマンス悪いかと。
下記のスレッドを参考にすると良いかも知れません。
[url=http://www.zabbix.jp/modules/newbb/viewtopic.php?topic_id=127&forum=2&post_id=581#forumpost581]zabbix速度チューニング[/url]
ログ監視はログの量も問題かと。
また、一度history_logテーブルに大量にログが登録された状態になっていると、その後ログを読みこまない設定にしても大量のログが保存期間過ぎるまでは、重たいままかと。
できるならヒストリの削除を一回した方が良いかも知れません。
kodai - 投稿数: 1341
MySQLの設定ですが、InnoDBを利用することは大前提で、メモリが512Mですと
innodb_file_per_table
innodb_buffer_pool_size=64M
innodb_log_file_size=16M
くらいは設定しておいた方がよいと思います。MySQLのメモリ関連のパラメータはOSやZabbixサーバのメモリが足りずにswapが発生しない程度まで増やすことでパフォーマンスが改善できると思います。
各パラメータの詳細はいろいろなサイトやブログで解説されていますので検索してみてください。