ログとメトリクスのためにコード書き直しを止める方法
想像してみてください：本番環境で10個程度のJavaマイクロサービスが動作しています。ある時点で、そのうちの一つが「遅延」し始めます。ログを開いても何も見つかりません — 標準的なメッセージでは、リクエストがどの段階で止まっているのか理解するには不十分です。馴染み深い話ですよね？通常、この時点で開発者はコードに手を入れ、メソッドにアノテーションを付与し、tracingの依存関係を追加し、プロジェクトを再ビルドして再度デプロイします。そして、異なるフレームワークで書かれた数百のサービスがある場合はどうでしょうか？
OpenTelemetryエコシステムには、この問題をエレガントに解決するプロジェクトがあります。そして特に素晴らしいのは、ほとんど手を動かさずに使えるということです。それがopentelemetry-java-instrumentationです。これは特殊なJavaエージェントで、アプリケーションに「リアルタイム」でアタッチし、新しいコードを一行も書かずにテレメトリを収集できます。
このエージェントとは何か、なぜ必要なのか
本質的には、JVMの起動時にアタッチするJARファイルです。動的なバイトコードインジェクションを使用します。アプリケーションが一般的なライブラリ（Spring、Hibernate、gRPC、Kafkaなど）のクラスをロードすると、エージェントはspanの作成とメトリクスの収集のためのロジックを丁寧に注入します。
これは2つのシナリオに最適な選択肢です。1つは、手を加えるのが怖いレガシープロジェクトに素早くオブザーバビリティを追加する必要がある場合です。2つは、各チームに手動でSDKを設定させることなく、社内のデータ収集を標準化したい場合です。
生活を楽にする3つの素晴らしい機能
箱から出してすぐに使える自動の魔法
このエージェントは多数のライブラリをサポートしています。Spring BootとPostgreSQLとRedisという標準的なスタックを使っているなら、を設定する必要は一切ありません。単にエージェントをアタッチすれば、モニタリングシステム（例えばJaegerやZipkin）でコールツリーが得られます：受信したHTTPリクエストからデータベースクエリ、キャッシュレスポンスまで。
ログへのコンテキスト伝播（MDC）
日常的なデバッグで最も便利な機能の一つは、Trace IDのログへの自動挿入です。エージェントは自らの力でロガー（Logback、Log4j2）を見つけ、現在のtraceの識別子をMDCに追加できます。これで、ログでエラーを見つけたとき、IDをコピーするだけで、そのリクエストの全サービスにわたるパスを見つけられます。もう、どのユーザーがあのNullPointerExceptionを引き起こしたのか推測する必要はありません。
再ビルド不要の柔軟な設定
データの送信先、サンプリング頻度、spanに追加する属性など、すべてのパラメータは環境変数またはJavaシステムプロパティで渡されます。つまり、アプリケーションの同じバイナリを、開発環境ではコンソールに、本番環境では重いOpenTelemetry Collectorクラスタにデータを送信できます。
動作させる方法
設定プロセスは驚くほどシンプルです。まず、リリースページから最新のJARファイルをダウンロードします。次に、アプリケーションの起動コマンドに1つのフラグを追加します：
デフォルトでは、エージェントはOTLPプロトコルでデータを受け取るコレクタがlocalhost:4317で実行されていることを期待しています。別のもの（例えばZipkin）を使用したい場合は、1つのフラグで変更できます：
内部動作と拡張性
興味深いことに、このプロジェクトは「自動化」に限定しません。組み込み機能で足りない場合は、拡張メカニズムを使用できます。カスタム計装ルールや会社固有の属性を追加する独自のJARファイルを作成できます。
エージェントの魔法を全く信用しない人のために、同じ計装ライブラリが別途提供されています。通常の依存関係として追加して手動で構成できますが、そうするとコードを変更する必要があることを受け入れる必要があります。
使う価値はあるか
Javaエージェントはアプリケーションを遅くする「ブラックボックス」だという意見をよく耳にします。これにはある程度の真実があります：エージェントは起動時にバイトコード変換のリソースを消費し、リクエスト実行時に小さなオーバーヘッドを追加します。しかし、分散システムでバグを追うときに得られる利益と比較すると、このオーバーヘッドの95%は微不足道です。
特に向いている人は：
- マイクロサービスに移行中で、tracingなしでは困っているチーム。
- 古いモノリスがなぜ遅いのか「昨日中に」理解する必要があるサポート担当。
- 統一されたモニタリング標準を実装しているアーキテクト。
まだJavaプロジェクトでOpenTelemetryを試したことがないなら、このエージェントは始めるのに最も速く、最も痛みが少ない方法です。ローカルで実行して、負荷をかけたときにコードの動作についてどれほど興味深いことが学べるか、ぜひ試してみてください。
関連プロジェクト