JetBrainsは、Igor Kulakovが執筆した記事で、IntelliJ IDEA 2026.2内でLogpointを使用して実行中のJavaアプリケーションのエラーを診断する実践的な方法を紹介しています。この考え方は、プログラムにprintln文を追加することに似ていますが、コードの変更、アプリケーションの再ビルド、再デプロイは必要なく、実行も停止しません。そのため、ローカル、Dockerコンテナー内、またはリモートホストで動作しているサービスの調査に適しています。
この例で扱う問題
この例では、gRPCを介して通信するクライアントとサーバーを使用します。サーバーは一部のテナントに対して誤った割引値を返します。テナントがJetBrains、地域がEMEAであるリクエストを送信すると、コンソールにはdiscount_bps=0で価格が100.00ドルと表示されますが、期待される値はdiscount_bps=2000で80.00ドルです。
サーバーは、リスニングポートとデバッグ用ポートを公開した状態でDockerを使用して起動され、クライアントは定期的にリクエストを送信します。サーバーとクライアントの起動後、ローカルのデバッグセッションから開始されていない場合でも、開発者はIntelliJ IDEAのデバッガーをプロセスにアタッチできます。説明によれば、デバッガーはローカル、分離された環境、リモートホストのいずれの場合もソケットを介して通信するため、Javaプロセスの実行場所が変わってもアタッチの原則は変わりません。
Logpointでエラーの原因を明らかにする方法
IntelliJ IDEA 2026.2では、実行可能な2つの行の間にあるエディターのガターをクリックし、記録したい式を入力することで、より迅速にLogpointを作成できます。開発者はリクエスト処理の開始時点から情報の記録を始め、リクエストが到着し続ける間に、段階的にポイントを追加したり変更したりします。
呼び出しチェーンを追跡すると、discountBpsFor()関数にたどり着きます。出力から、テナント名がJetBrainsという形式で渡されている一方、比較ロジックはjetbrainsという値を想定していることが分かります。また、出力は割引が適用されていないことも示しており、2,000ベーシスポイントの値を返すコード分岐が実行されていないことを意味します。この例では、equalsIgnoreCaseを使用して比較を修正し、その後、期待される動作をテストすることを提案しています。
利点はコンソールにテキストを表示することだけではありません。出力の行をクリックすると、IntelliJ IDEAはLogpoint、または関連するコード部分へ移動できます。このナビゲーションは、プロセスがIntelliJ IDEAのデバッガー下で動作している場合、println文でも機能します。
printlnやブレークポイントより優れているのはどのような場合か？
この記事では、Logpointはコードを汚さず、本番環境に誤って送られる可能性のあるデバッグ用文を残さないと説明しています。また、何をいつ記録するかを変更でき、繰り返し発生するイベントのサンプリング、依存関係内へのログ記録の追加、高コストな再デプロイの回避も可能です。
一方、従来のブレークポイントは、サービスを停止すること自体が問題の一部である場合には適さないことがあります。この例では、クライアントがgRPCリクエストにタイムアウトを設定し、そのタイムアウトがサーバーに伝播する可能性があります。デバッガーがサーバーを停止すると、タイムアウトが発生してリクエストはキャンセル経路へ移行するため、開発者はエラーにつながった状態を確認できなくなります。その場合、ブレークポイントを使用するには、リクエストを1件ずつ送信し、タイムアウト時間内で作業する必要があります。
これに対して、Logpointはサーバーを停止せずに情報を提供するため、実行中のリクエストを監視し、タイムアウトによって発生するキャンセル経路の有効化を回避できます。
実行中に一時的に動作を変更する
この記事では、修正やプログラムの動作変更の効果を一時的にテストするためにもLogpointを使用しています。ただし、Logpointは本来、アプリケーションを変更するためではなく、ログを記録するために設計されていると注意を促しています。副作用のある式を使用すれば、実行中にgRPCライブラリ内のタイムアウト値を変更できます。この例では、timeoutNanosを5分のタイムアウトに変更します。
この変更の影響を抑えるため、Debugヘッダーを持つリクエストに限定し、それ以外のリクエストには通常のタイムアウトを維持できます。この例には、ヘッダーを読み取り、その値が一致した場合にのみタイムアウトをリセットする複数行のロジックが含まれており、分岐が実行されたことを確認するためにTimeout resetというメッセージを表示します。
何に注意すべきか？
JetBrainsは、ホットパスに重い計算を配置しないよう注意を促しています。ログ記録用の式は仮想マシン自体の内部で実行され、時間的なコストがないわけではないためです。IntelliJ IDEA 2026.2はinstrumentationによってデバッガーが引き起こすオーバーヘッドを除去すると説明していますが、それによって式や大量のログ記録にかかるコストがなくなるわけではありません。
また、この記事では、Logpointの式フィールドから任意のオブジェクトにアクセスするためにMark Object機能を使用できることや、タイムアウトの読み取り位置を特定し、テスト用リクエストを対象とする式を作成できる、付属のAIエージェントスキルij-debuggerについても触れています。この方法は手作業による理解の代替となるものであり、一時的な変更がすべての環境で安全であることを示すものではありません。
certi.newsによる編集部の見解
ここでの実用的な価値は、単に新しい種類のログメッセージを追加することではなく、実行中に変更可能な層へ診断を移すことにあります。これは、特にリモートサービス、競合状態のあるサービス、または時間制限のあるサービスにおいて重要です。実行を停止すると、問題そのものが隠れてしまう可能性があるためです。一方で、この方法には式の選択とそのコストの監視における規律が求められます。また、副作用を利用した動作変更は、明確で一時的なデバッグシナリオに限定すべきであり、ソースコードの修正に代わるものになってはなりません。