BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース 実行後ロギングを提供するChronon 2.0

実行後ロギングを提供するChronon 2.0

ブックマーク

原文(投稿日:2011/10/12)へのリンク

Chronon SystemsはJVM上の実行後のロギングをサポートするレコーディングJVMデバッガのバージョン2を発表した。

Chrononは運用中のシステムを監視し、実行中のシステムの内部の状態を記録するJVMデバッガだ。記録した後、バグの原因を正確に狙ってアプリケーションの流れを再生できる。Chrononのタイムトラベリングデバッガは以前にInfoQで紹介した

この新バージョンは実行後ロギングをサポートする。この機能を使えば、プログラマはアプリケーションを実行したにロギング処理をコード"挿入"できる。Chrononは実際にアプリケーションを実行しないが、アプリケーションの状態をある状態から次の状態へ遷移させるので、実行後ロギングは従来のロギングと比べて利点がある。結果もすぐにわかる。5時間実行しているプログラムの4時間くらい経ったときに実行される行にロギング処理を設定した場合でも、Chrononはすぐに結果を返す。ロギングを起動する処理を待つ必要はない。

普通、実行中のJavaアプリケーションのロギングレベルは事前に定義され、バインドされている。実行中のシステムのロギングレベルを変えたとしても、その変更が適用されるのは変更後のロギング処理からだ。ロギングレベルが高すぎるときにバグが見つかっても、不完全なログしか手に入らない。したがって、プログラマはプログラムのほとんどの状態を把握するために過剰なロギングをするしかない。普通、アプリケーションは最大のログレベル(例えば、TRACE)で配置され、そのアプリケーションが成熟してプログラマが自信を持ち始めると、冗長なログレベルを少し下げる(例えばINFO)。

しかし、この方法は運用環境の性能に影響を与えてしまう。大規模な業務アプリケーションでのロギングは性能に大きな影響を与えてしまう可能性がある。また、最悪の場合、深刻なエラーの兆候が表れても、ログレベルを下げてしまっている(例えばWARN)ので、開発者が全く手がかりを見つけられないこともある。この場合、またロギングレベルを変更して、運用環境で問題を発生させて有意義な情報を取得しなければならない。

しかし、実行後ロギングを使えば、プログラマは特定のログレベルに制限される必要はない。すべてのロギング処理を排除するという極端な方法を採用して性能を最大に保てるようにしているからだ。

InfoQはPrashant Deva氏(CTOでありファンダ)に連絡し、このデバッガについて話を聞いた。

Chrononは実行中の環境を記録し始めてからの、どの時点の状態でも完全に把握してます。この記録を使ってChrononはコード上のメソッドや行を見つけ、実行された正確な時間を知らせます。ある行に実行前ロギングを設定すると、Chrononはその行が実行された時間と実行された時のプログラムの状態を把握します。そして、ロギング処理の中に書いた変数や式を計算します。複数の行にロギング処理を設定できるので、各行のロギング処理の結果が求まったら、その結果を時系列に並べるだけです。まるでプログラムにロギング処理を直接書いているのと同じように完全なログ出力を手に入れられます。

Chrononの出力は、コード上にロギング処理を直接書いてある一定期間ログを採取した時に出力される情報と同等だ。この方法はプログラマに強力な柔軟性を提供する。どこにでもロギング処理を挿入できるからだ。問題が起こったとき、追加の情報が欲しい場合、アプリケーションの再配置やロギング処理のコーディングをせずに新しい情報の取得を行える。

氏は下記のように明確に説明する。

何の仕掛けもありません。設定したロギング処理はまるで実際にコード上に書いているように動作します。例えば、ロギング処理を実行したスレッドも検出できます。'if'ブロック内の行にロギング処理を設定して、その行が10回中5回実行された場合、5回分のログが出力されます。

Chrononの詳細は公式FAQで確認できる。

この記事に星をつける

おすすめ度
スタイル

BT