アプリケーション エージェントのノードプロパティ（B ～ C）

このプロパティを使用してバイトコードトランスフォーマーログ（BCTログ）を構成します。このログは、どのAppDynamicsがインストゥルメント化を行い、どのクラスがJVMにロードされたかを示します。最初のファイル（0.log）はサーバ起動のコンテキストを保持するために保存され、ロールオーバーされません。それ以降のファイルはローテーションされます。ファイル名のフォーマットは、ByteCodeTransformer.<timestamp>.<N>.log. タイムスタンプは YYYY_MM_DD_HH_mm_ss と表示されます。Nはゼロから増えていきます。

Examples

ByteCodeTransformer.2012_09_12_20_17_57.0.log

ファイルサイズは15秒ごとにチェックされるため、ロールオーバーされる前のファイルは、指定されたしきい値よりやや大きくなることがあります。

生成された最初のログファイルは、次のように名前が付けられます。 ByteCodeTransformer.<timestamp>.0.log

このプロパティ値のフォーマットをデフォルト値 20,5,4 で説明します。それぞれの数字のセグメントには次のような意味があります。

• 20 は最初のログファイル（.0 バージョン）のサイズで、MB 単位
• 5は2番目以降の各ローリングファイルのサイズで、MB単位
• 4はキープするByteCodeTransformerログファイルの数

バイトコードの再変換を無効または有効にします。デフォルトでは、Java エージェントの Sun および JRockit バリアントは、JVM に再起動せずに、新しい POJO ルールなどのバイトコード再変換が必要な設定変更を適用します。エージェントが自動再変換を実行してこのようなルールを適用しないようにするには、bciengine-disable-retransformation を true に設定します。

trueに設定すると、Glassfish AMX MBeansのサポートを有効にします。Glassfish サーバサポートの詳細については、「GlassFishスタートアップ設定」を参照してください。

このノードのコールグラフの粒度を指定します。このプロパティが使用されていると、グローバル構成は無視されます。adaptive-callgraph-granularityプロパティがtrueに設定されている場合は、この値は無視されます。デフォルト値のゼロは、[Configuration > Instrumentation > Call Graph Settings] からグローバル設定が使用されることを意味します。再起動は必要ありません。 

このプロパティは404エラーの原因となるURLの取得を無効または有効にします。そのURLは15分ごとにERRORイベントとして報告され、イベントビューアで表示できます。JVMバージョンの再変換がサポートされていない場合、JVMを再起動する必要があります。

通常、404 エラーは、アプリケーションコードが実行されないことを意味します。その結果、スナップショット内でキャプチャされることはありません。このプロパティを true に設定することで、404 エラーに関するインサイトを得ることができます。404 エラーの原因となったすべての URL が報告されます。

capture-404-urls ノードプロパティは、AppDynamics v. 3.6 で廃止され、capture-error-urls に置き換えられています。

このプロパティは、以下のHTTPエラーのキャプチャを有効または無効にします。

• 401 - Unauthorized
• 500 - 内部サーバ エラー
• 404 - Page Not Found
• その他すべてのエラーコードは、一般的なHTTPエラーコードバケットに入ります。

これら4つのカテゴリについては、エージェントが毎分カテゴリあたり25個までURLを収集し、5分ごとにイベントを送信します。

Troubleshoot > Errors > Exceptions タブ > HTTP Error Codeをクリックし、エラーコードをドリルダウンするとこれらのURLが表示されます。

capture-raw-sql が有効な場合、動的パラメータ（疑問符パラメータなど）を持つ SQL コールはエージェントによりキャプチャされ、ランタイムの値にバインドされた動的パラメータとともにコントローラ UI に表示されます。 

Examples

たとえば、次のようにSQLコールを構成するJavaコードを見てみましょう。 

stmt = new PreparedStatement("select * from user where ssn = ?")
stmt.bind(1, "123-123-1234")
stmt.execute()

capture-raw-sqlが有効な場合、AppDynamicsは次の形式でSQLコールをキャプチャします。

select * from user where ssn = '123-123-1234'

capture-raw-sql が無効な場合、SQL コールは、値にバインドされていない疑問符パラメータとともに表示されます。 

capture-raw-sql を無効にし、SQL プリペアドステートメントで疑問符パラメータを使用すると、機密データがコントローラ UI に表示されなくなります。 

重要な点としては、上記のように、SQL ステートメントの元のプリペアドステートメント形式で、機密の値をパラメータ化する必要があることに注意してください。次のステートメントでは、capture-raw-sql の有効または無効にかかわらず、UI に表示される潜在的に機密性の高い情報（ssn 値）が生成されます。   

stmt = new PreparedStatement("select * from user where ssn ='123-123-1234'")

IBM JVMを使用する環境でこのノードプロパティを変更した場合、JVMを再起動する必要があります。この機能には特定のJDBCクラスの再変換が必要ですが、IBMエージェントではそれができないためです。

オプションをエージェントプロパティとして設定すると、ノードのSQLキャプチャモードに影響を与えます。コールグラフ設定 にある [Capture Raw SQL] オプションを使用すると、すべてのノードの動作を設定できます。

WebサービスがsetStatus()を使用してエラーを送り返している場合に、エラーをキャプチャするようエージェントに指示します。デフォルトでは、エージェントによって sendError() のみがインストゥルメント化されます。

クラスが複数の Spring bean 名にマッピングされると、デフォルトで最初に発見された Spring Bean 名のみが表示されます。これは誤解を招く可能性があります。これは、Web サービス B の Spring Bean を持つ Web サービス A のコールグラフを表示する時などに、誤解を招くことがあります。このプロパティを false に設定すると、これらの競合が発生した場合クラス名のみが表示され、Spring Bean 名は表示されません。

Java と.NET エージェントがルールを評価するデフォルトの順番を逆にします。true の場合、除外ルールは一致ルールの前に評価されます。 

診断POJOデータコレクタから同期的にユーザーデータを収集します。再起動の必要はありません。

リークの評価についてコレクションがキャプチャされたサーバーの再起動以降の分単位の合計間隔。プロパティはノード再起動後に有効になります。