[カスタム構成] タブでは、エージェント機能のスイッチやサンプリングポリシーなどの共通設定を調整できます。
ARMS API を使用してこれらの設定を構成する方法については、「SaveTraceAppConfig」をご参照ください。
前提条件
アプリケーションに ARMS エージェントがインストールされていること。
アプリケーション監視は、新しい課金モードを有効にしたユーザー向けに、新しいアプリケーション詳細ページを提供します。
新しい課金モードを有効にしていない場合は、[アプリケーションリスト] ページで [新バージョンに切り替え] をクリックして、新しいアプリケーション詳細ページを表示します。
機能へのアクセス
ARMS コンソールにログインします。左側のナビゲーションウィンドウで、 を選択します。
上部のナビゲーションバーで、 を選択します。
カスタム構成パラメーターを設定し、[保存] をクリックします。
サンプリング設定
[サンプリング設定] セクションでは、インターフェイスをフルサンプリングするためのサンプリングポリシー、サンプルレート、および機能を設定できます。 また、低トラフィックサンプリングを有効化または無効化することもできます。 詳細については、「V3.2.8 以降のエージェント用のトレースサンプリングモードを選択する」をご参照ください。
エージェントスイッチ設定
[エージェントスイッチ設定] セクションでは、アプリケーション監視を有効化または無効化し、使用したいプラグインを選択できます。
アプリケーション監視の有効化または無効化は、アプリケーションを再起動しなくてもすぐに有効になります。アプリケーション監視を無効にすると、アプリケーションの監視が停止します。操作は慎重に行ってください。プラグインスイッチの変更を有効にするには、アプリケーションを手動で再起動する必要があります。

スレッドプロファイリング設定
[スレッドプロファイリング設定] セクションでは、スレッドプロファイリングのメインスイッチを有効または無効にできます。
アプリケーションログの関連付け設定
[アプリケーションログの関連付け設定] セクションでは、アプリケーションに関連付けるログソースを設定し、ログに TraceId と SpanId を自動的に挿入するかどうかを指定できます。詳細については、「ログ分析」をご参照ください。

TraceId と SpanId を自動入力:この機能を有効にすると、Trace ID と Span ID が自動的にログに挿入されます。ログ設定ファイルを手動で変更する必要はありません。
効果:
次の図に示すように、log4j、log4j2、および logback は、ログ設定ファイルを変更することなく、ログに Trace ID と Span ID を自動的に出力します。

ログ MDC での traceId の追加をサポート:デフォルトでは、V4.x のエージェントは
org.slf4j.MDC.get(“EagleEye-TraceID”)メソッドを使用した TraceId の取得をサポートしていません。このメソッドを引き続き使用する必要がある場合は、このスイッチを有効にできます。
URL 収束設定
「[URL 収束設定]」セクションでは、収束を有効または無効にし、収束のしきい値と収束ルールを指定できます。URL 収束は、類似した URL を単一のオブジェクトとして表示します。たとえば、`/service/demo/` をプレフィックスとして持つ URL は、オブジェクトとして表示されます。収束のしきい値は、URL 収束をトリガーできる URL の最小数です。たとえば、しきい値が 100 に設定されている場合、URL 収束は、少なくとも 100 個の URL がルールの正規表現に一致した場合にのみトリガーされます。詳細については、「ARMS 収束ポリシー」をご参照ください。

Arthas 監視
[Arthas モニタリング] セクションでは、Arthas 診断機能を有効または無効にできます。また、Arthas 診断を実行する IP アドレスを指定することもできます。詳細については、「Arthas 診断」をご参照ください。

継続的プロファイリング設定
[継続的プロファイリング設定] セクションでは、メインスイッチと、CPU ホットスポット、メモリホットスポット、および [コードホットスポット] のスイッチを有効または無効にできます。また、設定を適用する IP アドレスまたは CIDR ブロックを指定することもできます。詳細については、「Java アプリケーションの継続的プロファイリング」をご参照ください。

情報マスキング設定
[情報非表示化設定] セクションでは、非表示化ルールを設定して、データ収集中に JVM システムパラメーター、K8s YAML、メソッド入力パラメーター、Arthas 環境変数、システム変数などのコンテンツを非表示化できます。 ルール内の要素はカンマで区切られ、各要素は大文字と小文字を区別しない正規表現を表します。 たとえば、password は正規表現 .*password.* と同等です。
エージェントがデータを収集する際、これらの式に基づいてデータキーをフィルタリングします。キーが式に一致する場合、対応する値は機密データと見なされ、マスキングされます。次の図に示すように、マスキングルールが licenseKey に設定されている場合、キー -Darms.licenseKey の値はマスキングされます。
次の図は、IP マスキングを有効にした後の効果を示しています:
インターフェイス呼び出し設定
[インターフェイス呼び出し設定] セクションでは、低速呼び出しのしきい値や、例外ホワイトリスト、HTTP ステータスコードホワイトリスト、無効なインターフェイス呼び出しのフィルタリングポリシーを設定できます。

低速呼び出しのしきい値:デフォルト値は 500 です。インターフェイスの応答時間がこのしきい値を超えると、そのインターフェイスは低速呼び出しとしてマークされます。
HTTP ステータスコードホワイトリスト:
デフォルトでは、400 以上の HTTP ステータスコードはエラー呼び出しとして分類されます。特定のステータスコードをエラーとして分類したくない場合は、ホワイトリストに追加してこのタイプのエラーを無視できます。
これは、アプリケーション監視でサポートされている HTTP フレームワークにのみ影響します。
影響を受けるデータ:HTTP サーバー側またはクライアントのエラー数メトリック (arms_http_requests_error_count、arms_http_client_requests_error_count、および arms_app_requests_error_count) と span ステータス。
影響を受ける機能: [概要]、[提供サービス]、[依存関係] タブのエラー数、および [トレースエクスプローラー] ページのスパンステータスとエラー数アラート。
コンテンツ形式:単一のステータスコードを入力します。複数のステータスコードはカンマ (,) で区切ります。あいまい一致はサポートされていません。
例:
403,502デフォルト値:空
無効なインターフェイス呼び出しのフィルタリング:
提供されたサービス タブで特定の呼び出しを表示したくない場合は、フィルターするインターフェイスの名前を入力できます。エージェントはこれらのインターフェイスの可観測性データを報告しなくなるため、インターフェイス呼び出しページに表示されなくなります。
説明V4.2.0 より前の Java エージェントの場合、この機能は [提供されたサービス] タブに表示されるインターフェイスに対してのみ有効です。
V4.2.0 以降の Java エージェントの場合、この機能は任意の LocalRootSpan に対して有効です。
影響を受けるデータ:インターフェイスに対応するすべてのメトリックと span が無視されます。
影響を受ける機能: [概要]、[提供サービス]、および [依存関係] タブにおいてインターフェイスに対応するすべてのメトリック、ならびに [トレースエクスプローラー] ページにおけるスパン数、インターフェイスへの呼び出し数、エラー数、および低速呼び出しアラート。
コンテンツ形式:文字列または AntPath 式を使用して、無効なインターフェイスの完全名を照合します。複数のルールはカンマ (,) で区切ります。デフォルト値の AntPath 式は、既存データとの互換性のためのものです。削除しないことを推奨します。新しい構成は既存のルールの後に追加してください。
例:
/api/test/*,/api/playground/createデフォルト値:
/**/*.jpg,/**/*.png,/**/*.js,/**/*.jpeg,/**/*.pdf,/**/*.xlsx,/**/*.txt,/**/*.docs,/**/*.gif,/**/*.csvインターフェイス呼び出しメトリックに上流インターフェイス名を記録 および インターフェイス呼び出しメトリックに上流アプリケーション名を記録:
構成目的:このインターフェイスを呼び出す上流アプリケーションと上流インターフェイスをインターフェイスメトリックに記録するかどうかを制御します。これは主に、[提供サービス] タブの上流および下流トレースのデータが存在するかどうかに影響します。アプリケーションに多数の上流アプリケーションがある場合、この情報を記録すると、レポートされるメトリックの量が大幅に増加し、コストが高くなる可能性があります。
構成効果:図に示すように、インターフェイスメトリックでの上流アプリケーションとインターフェイスの記録を無効にすると、対応するデータは 0 に低下します。

インターフェイス呼び出しメトリックに元のステータスコードを記録:
構成目的:HTTP インターフェイス関連のメトリックに元の応答コードを記録します。
構成効果:

インターフェイスの HTTP メソッド名を記録: このスイッチを有効にすると、[インターフェイス呼び出し] ページに表示されるインターフェイス名に HTTP リクエストメソッド名が含まれます。たとえば、名前が
/api/v1/use/{userId}からGET /api/v1/use/{userId}に変更されます。
データベース呼び出し設定
[データベース呼び出し設定] セクションでは、低速 SQL 文のしきい値と、収集される SQL 文の最大長を指定できます。また、SQL 文の変数バインディング値と定数値を表示するかどうか、および MySQL クエリの戻り値のサイズを記録するかどうかを指定することもできます。

SQL の変数バインディング値を表示:PreparedStatement パラメーターにバインドされた変数の値をキャプチャします。この構成は、アプリケーションを再起動しなくても有効になります。
PreparedStatement パラメーターにバインドされた変数の値は、対応するデータベースアクセス span の属性として記録および保存されます。これらの属性では、キーは db.bindvalue で、値はカンマで区切られた変数値のリストです。この構成は、アプリケーションを再起動しなくても有効になります。
この設定は、現在 ARMS でサポートされているすべての JDBC ベースのフレームワークでサポートされています。
この設定では、次のデータベース変数タイプがサポートされています:Boolean、Byte、Short、Int、Long、Float、Double、BigDecimal、および Date。
このスイッチを有効にすると、追加のオーバーヘッドが発生します。これは、SQL 文の変数数に正比例します。公式ストレステストシナリオ (変数が 1 つの場合) では、この機能を有効にすると、CPU オーバーヘッドが 0.5% 未満増加し、メモリオーバーヘッドはごくわずかです。
次の図は、このスイッチを有効にした後の実際の効果を示しています:

SQL の定数値を表示:この設定は、追加の処理なしで SQL 文の定数値を表示します。この構成は、アプリケーションを再起動しなくても有効になります。このオプションを有効にすると、定数値が異なる SQL 文は別個の文として扱われます。これにより、それらが正しく収束されなくなり、
{ARMS_OTHERS}の下にグループ化される可能性があります。このオプションは無効にしておくことを推奨します。
トレースコンテキスト伝播プロトコル設定
[トレースコンテキスト伝播プロトコル設定] セクションでは、要件に基づいて トレースコンテキスト伝播プロトコルを選択できます。

デフォルトでは、ARMS エージェントは、リクエストヘッダーに指定されたプロトコルヘッダーが含まれているかどうかに基づいて、トレースコンテキスト伝播プロトコルを選択します。詳細については、「ARMS トレースコンテキスト伝播プロトコル選択ポリシー」をご参照ください。
このページで任意のプロトコルを優先プロトコルとして選択できます。プリファレンスを選択して保存すると、ARMS は選択されたプロトコルのリクエストヘッダーのチェックを優先します。たとえば、次の構成では、リクエストを受信すると、ARMS エージェントは Jaeger、EagleEye、W3C、SkyWalking、Zipkin の順にプロトコルコンテキストをチェックします。

特定のプロトコルの使用を強制することもできます。たとえば、次の構成では、リクエストを受信すると、ARMS エージェントは Jaeger プロトコルで定義されたリクエストヘッダーの存在のみをチェックします。これらのヘッダーが検出されない場合、他のプロトコルはチェックされません。代わりに、新しいトレースコンテキストが生成されます。

構成目的:
この機能は、優先または強制されるトレースコンテキスト伝播プロトコルの選択をサポートします。一般的なシナリオは次のとおりです:
リクエストに複数の形式のトレースコンテキストが含まれており、デフォルトの解析順序が要件を満たしていない。優先するプロトコルを指定したい。たとえば、リクエストに W3C と Zipkin の両方のトレースコンテキストが含まれている場合、デフォルトでは W3C トレースコンテキストが優先的に解析されます。伝播プロトコルを Zipkin に設定して、Zipkin プロトコルを優先させることができます。
リクエストにトレースプロトコルヘッダーが含まれているが、それを再利用したくない。別のプロトコルを使用して新しいトレースコンテキストを生成したい。たとえば、リクエストに Zipkin トレースコンテキストが含まれている場合、デフォルトでは Zipkin トレースコンテキストが解析されます。伝播プロトコルを W3C に設定し、伝播モードを [強制] に変更すると、システムは Zipkin トレースコンテキストを無視し、新しい W3C 準拠のコンテキストを生成します。伝播モードを [強制] に変更しない場合、システムは優先される W3C コンテキストの解析に失敗した後、依然として Zipkin トレースコンテキストの解析を試みることに注意してください。
構成効果:
構成後、トレース内の各 LocalRootSpan には、キーが trace.protocol.type で、値が現在のトレースのトレースプロトコルを示す属性が含まれます。

メッセージキュー設定
[メッセージキュー設定] セクションでは、コンシューマー情報をカスタマイズできます。

カスタム RabbitMQ コンシューマー:カスタムコンシューマーのクラス名または匿名内部コンシューマーのクラス名を指定して、コンシューマーのトレースを表示できます。複数のコンシューマーはカンマ (,) で区切ります。
カスタム Kafka 消費メソッド:カスタム消費メソッドを指定して、ネイティブ Kafka SDK を使用してメッセージを消費するときのトレースとメトリックを表示できます。
Kafka メッセージの自動コンテキストパススルー:メッセージが送信されると、複数のヘッダーが自動的に Kafka メッセージに追加され、送信トレースと消費トレースが関連付けられます。
エージェント収集設定
[エージェント収集設定] セクションでは、エージェントが 1 秒あたりに収集するトレースの最大数、エージェントが処理できる最大 QPS しきい値、およびエージェントのログレベルを設定できます。
トレースの収集:トレースデータがレポートされるかどうかを制御します。この機能はデフォルトで有効になっています。無効にすると、トレースデータはレポートされなくなります。
エージェントが 1 秒あたりに収集するトレースの最大数:エージェントが 1 秒あたりにレポートできる span の数。パフォーマンス上の理由から、実際の有効なしきい値は、ユーザーが構成したしきい値から最大 5% の偏差を持つ場合があります。この制限を超える span はレポートされません。
エージェントが処理できる最大 QPS しきい値:エージェントが 1 秒あたりに処理できるリクエストの数。パフォーマンス上の理由から、実際の有効なしきい値は、ユーザーが構成したしきい値から最大 5% の偏差を持つ場合があります。このしきい値を超えるリクエストは監視されません。つまり、これらのリクエストに対して span やメトリックは生成されず、ログと TraceId を関連付ける機能も有効になりません。
エントリなしの内部呼び出しデータを収集:ARMS では、アプリケーションが提供する HTTP サービスおよび RPC サービス、アプリケーションによってトリガーされるスケジュールされたタスク、およびメッセージ消費がエントリと見なされます。これらのエントリのビジネスロジック内で送信されるデータベース呼び出しおよび HTTP リクエストは、エントリありの内部呼び出しと見なされます。逆に、Java 開発キット (JDK) スレッドプールを使用して開始されるスケジュールされた HTTP 呼び出し、データベース呼び出し、NoSQL 呼び出し、メッセージ送信、および RPC 呼び出しは、エントリなしの内部呼び出しと見なされます。V4.2.2 以降のエージェントは、このデータをワンクリックでフィルタリングするオプションを提供します。次の図に示すように、Lettuce フレームワークでは、Redis サーバー側との正常な接続を確保するためにコマンドが定期的に実行されます。このような呼び出しは、エントリなしの内部呼び出しです。図に示す時点でエントリなしの内部呼び出しデータの収集を無効にすると、関連データは収集されなくなります。

エージェントのログレベル:トラブルシューティングに役立つエージェントのログレベルを調整します。
エージェントログのレポート:迅速なトラブルシューティングのために、エージェントがその操作ログを ARMS サーバー側にレポートすることを許可するかどうかを指定します。通常の状況では、1 分あたりにレポートされるログはごく少量です。
デフォルトのメトリック収集フィルター:指定されたタイプのメトリックのレポートをフィルタリングします。次のサポートされているタイプから複数のタイプを選択できます:
custom_entry:メソッド監視用のカスタムメトリック
http:HTTP サーバー側のメトリック
http_client:HTTP クライアントのメトリック
rpc:RPC 呼び出しサーバー側のメトリック
rpc_client:RPC 呼び出しクライアントのメトリック
sql:データベースサービスアクセスに関連するメトリック
nosql:NoSQL サービスアクセスに関連するメトリック
cache:キャッシュサービスアクセスに関連するメトリック
producer:メッセージ送信に関連するメトリック
consumer:メッセージ消費に関連するメトリック
schedule:スケジューリングサービスに関連するメトリック
カスタムメトリック収集構成:OpenTelemetry SDK によって定義された収集対象のメトリックを構成します。詳細については、「OpenTelemetry Java SDK を使用したメトリックのカスタマイズ」をご参照ください。
Baggage 収集リスト:ビジネスで baggage を使用する場合、この設定は特定の baggage を span 属性に書き込み、特定のトレースの取得を容易にします。
高度な例外フィルタリング設定
[高度な例外フィルタリング設定] セクションでは、例外収集ルールを設定できます。

プラグイン例外の収集:プラグイン例外を収集するかどうかを指定します。
類似の例外を区別するためのスタック深度:デフォルト値は 2 です。このスタック深度は、類似タイプの例外を識別するために使用されます。この構成を変更すると、予期しない統計的動作が発生する可能性があります。操作は慎重に行ってください。
例外フィルタリングホワイトリスト:
「例外分析」タブにこれらの例外を表示したくない場合は、無視する例外の完全修飾クラス名を入力できます。これにより、これらの例外は「例外分析」ページで非表示になります。
影響を受けるデータ:例外数メトリック (arms_exception_requests_count_raw および arms_exception_requests_seconds_raw) と span 内の例外情報。
影響を受ける特徴:[例外分析] タブ上の対応する例外のメトリクス。
コンテンツ形式:フィルタリングする必要がある例外を識別するために、完全修飾クラス名を使用します。複数の例外はカンマ (,) で区切ります。
例:
java.lang.InterruptedException,java.lang.IndexOutOfBoundsExceptionデフォルト値:なし
親クラス継承の例外フィルタリング:このスイッチを有効にすると、例外が例外フィルタリングホワイトリストで構成されている例外クラスの子クラスである場合も、その例外はフィルタリングされます。
構成効果:フィルタリング基準を満たす例外は ARMS コンソールに表示されません。
例外メッセージフィルタリング:この機能が構成されると、指定されたタイプの例外は、そのメッセージフィールドが構成された条件に一致する場合にもフィルタリングされます。
例外名:フィルターが適用される例外を指定します。
メッセージ条件:例外メッセージの条件。値は startsWith、endsWith、または contains のいずれかです。
メッセージキーワード:キーワード文字列。
構成効果:フィルタリング基準を満たす例外は ARMS コンソールに表示されません。
プーリング監視設定
[プーリング監視設定] セクションでは、スレッドプールと接続プールの収集ルールを設定できます。

スレッドプールと接続プールの監視:Tomcat、Dubbo、High-speed Service Framework (HSF) などのフレームワークのスレッドプールメトリックを監視するかどうかを指定します。この機能を有効にするには、エージェントを最新バージョンにアップグレードする必要があります。
スレッドプールのスレッド名パターンの抽出ポリシー:この機能は、デフォルトで、スレッドプール内で実行中の任意のスレッドのスレッド名に含まれるすべての数字を
*に置き換えます。また、スレッド名の末尾の文字のみを*に置き換えるように調整することもできます。複数の Dubbo プロバイダーが開始され、これらのプロバイダーが異なるリスニングポートを持つアプリケーションでは、デフォルトの戦略が適用されると、抽出されたスレッド名テンプレートが同一であるため、2 つの Dubbo プロバイダーからの 2 つのスレッドプールが 1 つのスレッドプールに集約される可能性があります。この場合、戦略を調整することで、2 つのスレッドプールを区別するのに役立ちます。構成効果:一般的な Tomcat スレッドプールの場合、表示されるスレッドプールのスレッド名はデフォルトで
http-nio-*-exec-*です。調整後、スレッド名はhttp-nio-9099-exec-*になります。
スレッドプールの使用シナリオフィルタリング および スレッドプールのスレッド名パターンフィルタリング:特定のスレッドプールのメトリックは、その使用シナリオとスレッド名パターンに基づいてレポートから除外できます。
説明この構成は、V4.2.0 以降の Java エージェントに対してのみ有効です。
スレッドプールの使用シナリオ:スレッドが使用されるシナリオ。現在、Tomcat、Vert.x、Undertow、Dubbo、Jetty、AliyunJavaAgent、および default がサポートされています。AliyunJavaAgent はエージェントが使用するスレッドプールを表し、default は他の未分類のスレッドプールを表します。
スレッドプールのスレッド名パターン:スレッドプール内のスレッド名が処理された後に得られるパターン。たとえば、http-nio-*-exec-* は通常、実際のスレッド名の数字部分を * に置き換えることによって得られます。
影響を受けるデータ:スレッドプールメトリック
影響を受ける機能:[スレッドプールモニタリング] タブ、およびスレッドプールモニタリングメトリックに基づいて設定されたアラート。
コンテンツ形式:
スレッドプールの使用シナリオフィルタリング:[スレッドプール監視] タブに表示される使用シナリオ。複数の使用シナリオはカンマ (,) で区切ります。
スレッドプールのスレッド名パターンフィルタリング:[スレッドプール監視] タブに表示されるスレッド名パターン。複数の使用シナリオはカンマ (,) で区切ります。照合方法は完全一致です。ルールベースの照合はサポートされていません。
例:
スレッドプールの使用シナリオフィルタリング:
AliyunJavaAgent,Jettyスレッドプールのスレッド名パターンフィルタリング:
Catalina-utility-*,DubboServerHandler-*-thread-*
これは、AliyunJavaAgent シナリオのすべてのスレッドプールデータがレポートされないことを示します。他のシナリオでは、スレッドプールパターン名が
Catalina-utility-*の場合、データもレポートされません。デフォルト値:なし
Span 属性設定

OTel Spec 規約属性の記録:OpenTelemetry 仕様では、各プラグインタイプによって生成される span に含めるべき属性が規定されています。ただし、データレポート量を削減するため、ARMS エージェントはデフォルトでこれらの属性を span に記録しません。必要に応じてこの機能を有効にできます。この機能を有効にした後、さまざまなフレームワークによって追加される追加の属性については、「OpenTelemetry 仕様」をご参照ください。
次の例は、HTTP サーバーの span を示しています。赤いボックス内の属性は、このスイッチを有効にした後に追加される属性です。

スパン関連付けアプリケーションラベルの構成: この設定は、どのスパンにアプリケーションラベルをアタッチするかを制御します。アプリケーションラベルは、[アプリケーション] ページで構成されます。デフォルトでは、すべてのスパンにアプリケーションラベルが含まれます。データボリュームを削減するには、エントリスパンにのみアプリケーションラベルをアタッチできます。エントリスパンには、通常、HTTP サーバー、RPC サーバー、MQ メッセージ消費、およびスケジュールされたタスクが含まれます。
次の図は、ラベルをエントリスパンにアタッチするように構成した後の効果を示しています。たとえば、アプリケーションには
test1:value1のようなアプリケーションラベルのペアが含まれています。
エントリスパンの場合、対応するラベルの属性を確認できます。

非エントリスパンの場合、
test1:valueの属性は含まれません。
詳細設定
[詳細設定] セクションでは、フィルタリングしたいインターフェイスやメソッドスタックの最大長などの詳細設定を構成できます。
分位数統計:分位数統計を有効または無効にできます。
メソッドスタックの最大保持長:デフォルト値は 128、最大値は 400 です。
トレース圧縮:for ループなどの繰り返し呼び出しを簡略化するかどうかを指定します。
リクエスト入力パラメーターの最大表示長:デフォルトの長さは 512 文字、最大長は 2,048 文字です。
非同期パススルースキャンパッケージ名:非同期タスクを監視するには、アプリケーション構成に非同期伝播用のスキャンパッケージを追加できます。`Runnable`、`Callable`、または `Supplier` オブジェクトが作成されると、指定されたスキャンパッケージ内のメソッドが現在のスレッドのトレースコンテキストを自動的にキャプチャします。このキャプチャされたコンテキストは、非同期タスクが実行されるときに新しいスレッドに伝播されます。
HTTP 応答に TraceId を含める:HTTP リクエストの応答ヘッダーに eagleeye-traceid フィールドを返すかどうかを指定します。
JVM GC トリガーの根本原因: Java 仮想マシン (JVM) の GC トリガーの根本原因を収集するかどうかを指定します。モニタリング詳細は、JVM モニタリングページで表示できます。GC トリガーの根本原因については、「GC 関連のメトリック」をご参照ください。
他のアプリケーションに設定をコピー
他のアプリケーションで同じ設定を同期するには、対応する設定を他のアプリケーションにコピーできます。
単一の設定を他のアプリケーションにコピー
設定のセクションで、[保存して他のアプリケーションに一括コピー] をクリックします。
[現在の設定は保存されていません] ダイアログボックスが表示された場合は、[OK] をクリックして現在のアプリケーションの設定を保存し、再度 [保存して他のアプリケーションに一括コピー] をクリックします。
表示されたダイアログボックスで、設定を適用するアプリケーションを選択し、[OK] をクリックします。
すべての設定を他のアプリケーションにコピー
ページの下部で、[保存して他のアプリケーションに一括コピー] をクリックします。
[現在の設定は保存されていません] ダイアログボックスが表示された場合は、[OK] をクリックして現在のアプリケーションの設定を保存し、再度 [保存して他のアプリケーションに一括コピー] をクリックします。
表示されたダイアログボックスで、設定を適用するアプリケーションを選択し、[OK] をクリックします。
グローバルデフォルト構成
現在の設定をグローバルデフォルト構成として保存できます。新しいアプリケーションを作成すると、これらの設定がデフォルトで使用されます。
ページの下部で、[現在のアプリ設定をグローバルデフォルト構成として保存] をクリックします。
[現在の設定は保存されていません] ダイアログボックスが表示された場合は、[OK] をクリックして現在のアプリケーションの設定を保存し、再度 [現在のアプリ設定をグローバルデフォルト構成として保存] をクリックします。
表示されたダイアログボックスで、[確認] をクリックします。
よくある質問
アプリケーションのスイッチ設定が有効にならないのはなぜですか?
変更したい設定項目に、特定のエージェントバージョン以降でスイッチがデフォルトで有効または無効になるなどのバージョン要件があるかどうかを確認してください。
ある場合は、現在のエージェントバージョンが要件を満たしているかどうかを確認してください。満たしていない場合は、[保存] をクリックして手動で変更を適用する必要があります。満たしている場合は、エージェントログで構成リスニング関連のログを確認してください。
ない場合は、エージェントログで構成リスニング関連のログがあるかどうかを確認してください。
V3.x エージェントの場合、キーワード
[Diamond] receiveを検索します。次の図に示す内容が表示された場合、構成は期待どおりにプッシュされています。
V4.x エージェントの場合、キーワード
config updateを検索します。次の図に示すログが表示された場合、構成は期待どおりにプッシュされています。
調整したサンプルレートが有効にならないのはなぜですか?
アプリケーションのサンプルレートは、このアプリケーションをエントリとして使用するトレースがサンプリングされるかどうかにのみ影響します。リクエストにトレースコンテキストが含まれている場合、アプリケーションはこのトレースコンテキストを使用し、サンプリングの決定はそのコンテキスト内のサンプリングフラグに基づきます。
非同期パススルースキャンパッケージを構成した後、ラムダ式がサポートされないのはなぜですか?
エージェントを V4.x にアップグレードすることを推奨します。このバージョンは、追加のコード変更や構成変更を必要とせずに、自動的な非同期コンテキストパススルーをサポートします。
新しいアプリケーションでグローバルデフォルト構成が有効にならない
アプリケーション A の現在の設定をグローバルデフォルト構成として保存すると、アプリケーション A の現在の設定のスナップショットのみが保存されます。その後のアプリケーション A の設定変更は、グローバルデフォルト構成には同期されません。更新された設定を再度グローバルデフォルト構成として保存して有効にする必要があります。
/error インターフェイスの構成が有効にならないのはなぜですか?
V3.2.0 より前のエージェントでは、インターフェイス呼び出しが最初にアプリケーションに入るときにインターフェイスフィルタリングが実行されます。ただし、/error インターフェイスは、インターフェイス呼び出しがエラーを報告したときに一様に /error ページにディスパッチされます。この時点ではフィルタリングは実行されないため、インターフェイスフィルタリングは有効になりません。この問題は、V3.2.0 以降のエージェントで修正されています。
URL 収束を無効にしても URL が収束するのはなぜですか?
[カスタム構成] タブの [URL 収束設定] は、V3.x エージェントに対してのみ有効です。V4.x エージェントの場合は、 ページに移動して設定を構成してください。
この問題は、Spring MVC を使用し、エージェントが V3.x より前のアプリケーションで発生します。この問題を解決するには、エージェントを V3.x 以降にアップグレードしてください。