LoginSignup
14
13

More than 5 years have passed since last update.

mackerelでログ監視を試してみた

Last updated at Posted at 2015-11-06

mackerelは2015/11/06、公式プラグインでログ監視ができるようになった。

待ちに待った機能なので、早速試してみた。

インストール

わざわざ書くまでもないが、mackerel-agentをyum/aptで入れている環境であればmackerel-check-pluginsの一部としてインストールされる。

$ yum install mackerel-check-plugins

最初に挙動を確認してみる

実装の確認

gitリポジトリで実装を見る限り、Nagiosのcheck_log系プラグインと同様に、毎回プロセスが起動し直すタイプの動作のようだ。
前回読んだ場所を覚えていて、そこまでseekする挙動となっている。

check-log.go
    if skipBytes > 0 && stat.Size() >= skipBytes {
        f.Seek(skipBytes, 0)
    }

こういう動作のログ監視はtail系と違って負荷が気になる。

動作試験

ちょうど良く300MBほどのログファイルがあったので、読み込ませてみた。
実装からすると、こんな挙動が推測される。

  • 初回起動はログファイル全読込で重い
  • 2回目以降は速い(CPU使用率は高いかもしれない)

初回実行

1回目はとにかく重いはず。

$ time /usr/local/bin/check-log --file XXX.log --pattern 'error'
LOG OK: 0 warnings, 0 criticals for pattern error.
10.60user 0.43system 0:10.45elapsed 105%CPU (0avgtext+0avgdata 6496maxresident)k
0inputs+8outputs (0major+438minor)pagefaults 0swaps

予想通りCPUは1core分(100%)まるまる持って行ってしまった。
が、10秒程度で処理が終わった。

ちなみに、速いことで有名なfgrepと比較するとこんな感じだ。

$ time fgrep 'error' XXX.log
0.19user 0.06system 0:00.26elapsed 99%CPU (0avgtext+0avgdata 2608maxresident)k
0inputs+0outputs (0major+192minor)pagefaults 0swaps

0.19秒・・・ 格が違う。
ちなみに検証環境は物理マシン。間違いなく実行時間はI/O速度に依存する。

2回目実行

再度実行してみる。

$ time /usr/local/bin/check-log --file XXX.log --pattern 'error'
LOG OK: 0 warnings, 0 criticals for pattern error.
0.00user 0.00system 0:00.00elapsed 50%CPU (0avgtext+0avgdata 6048maxresident)k
0inputs+16outputs (0major+397minor)pagefaults 0swaps

さすがに速い。
CPU使用率は高めだが、それは仕方ないだろう。

試験まとめ

初回実行の挙動を見る限り負荷は決して軽いとは言えないが、エージェントがcheck-logを実行するのが1分間隔であることを前提とすると、1分間のログ量が多いログファイルでなければ十分に使えそうである。

こういった文字列監視の主な用途は、システムログやエラーログの監視であろうから、簡単に実装できるということにメリットがある。

設定してみる

実装例

よくある実装パターンは、/var/log/messagessegfaultを検知するものだろう。
ルールとしてはこんな感じのものをmackerel-agent.confに書けば良い。

mackerel-agent.conf
[plugin.checks.log_messages]
command = '/usr/local/bin/check-log --file /var/log/messages --pattern "segfault" -c 2'

ポイントは-c 2のオプションで、これにより

  • 2回発見まではWarning
  • 3回以上発見した場合Critical

という条件となる。「より大きい(>)」条件であることに注意。
同様にWaring条件を制限する-wオプションもあるが、この例では設定していない。

動作確認

普段は当然OKになる。

$ check-log --file /var/log/messages --pattern "segfault" -c 2
LOG OK: 0 warnings, 0 criticals for pattern segfault.

2回まではWarningで良しとする。(作業影響とかもありうるので)

$ logger -t test -p user.err "segfault at XXXXX"
$ check-log --file /var/log/messages --pattern "segfault" -c 2
LOG WARNING: 1 warnings, 1 criticals for pattern segfault.

3回以上発生した時はCritical。

$ logger -t test -p user.err "segfault at XXXXX"
$ logger -t test -p user.err "segfault at XXXXX"
$ logger -t test -p user.err "segfault at XXXXX"
$ check-log --file /var/log/messages --pattern "segfault" -c 2
LOG CRITICAL: 3 warnings, 3 criticals for pattern segfault.

最後に

負荷に関して問題ないとは言い切れない点、エラー検知した時のメッセージが少し不自然な気がする点は気になるものの、mackerelという便利なサービスでログ監視もできるようになったことは大変ありがたい。

14
13
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
14
13