Related pages:

このページでは、アプリケーション分析の特定のシナリオにおける展開の問題と回避策に関する一般的なトラブルシューティング手法について説明します。 

一般的なトラブルシューティングの問題

分析の展開で問題が発生した場合は、ログでエラーおよび警告がないか確認します。

これらのログは次の場合に役立ちます。

  • Analytics Dynamic Service が有効か無効かを確認する。 
  • Analytics Dynamic Service が分析エージェントにメッセージを送信する際にエラーが発生していないかどうかを確認する。たとえば、無効な接続設定が原因で、Analytics Dynamic Service が Analytics エージェントと通信できない場合などです。
  • 内部バッファがいっぱいになっているために、Analytics Dynamic Service によってメッセージがドロップされていないかどうかを確認する。
  • スタートアップ時に使用される設定を確認する。

次のコンポーネントによって、ログ情報が書き込まれます。

  • Analytics エージェント：Analytics エージェントは、ディレクトリ <analytics_agent_home>/logs にあるファイルにログメッセージを書き込みます。 
  • イベントサービス：イベントサービスは、ディレクトリ <events_service_home>/logs にあるファイルにログメッセージを書き込みます。この analytics-api-store.log ファイルは、トラブルシューティングに役立つことがあります。 
  • Java エージェント：Analytics Dynamic Service は Java エージェントに組み込まれ、アプリケーション エージェントと同じファイルにログを書き込みます。ログは <application_home>/<app_agent_home>/logs ディレクトリにあります。 
    • トラブルシューティングに使用するプライマリログファイルは、agent.<timestamp>.log という名前のファイルです。ファイル内を検索して、Analytics Dynamic Service によって書き込まれたメッセージを見つけます。 
  • .NET エージェント：.NET エージェントは、ディレクトリ %ProgramData%\AppDynamics\DotNetAgent\Logs にあるファイルにログメッセージを書き込みます。デフォルトでは、.NET エージェントは com.appdynamics.ee.service.analytics.Analytics ロガーから Analytics ログを書き込み、Analytics Dynamic Service が有効か無効かを判断し、起動時に設定を表示します。エラーは warnfile に記録されます。
    • com.appdynamics.CONFIG.AnalyticsDynamicServiceConfigListener ロガーは、コントローラから Analytics Dynamic Service 構成の詳細を収集します。eventServiceURL がコントローラからのものであることを確認します。
    • com.appdynamics.analytics.EventsServiceSink ロガーは、.NET エージェントとイベントサービスの間の通信に関する情報を提供します。 
    ロガーの追加情報については、「Windows 上の .NET エージェントのロギング」を参照してください。

設定の問題

構成設定が必要なアカウント名とキーを使用して適切に設定されていることを確認します。アカウント名とキー値のスラッシュはエスケープする必要があります。

Analytics エージェントの起動に関する問題

Analytics エージェントのインスタンスが終了し、プロセス ID ファイル（PID ファイル）が残されると、次のエージェントの起動は、以下のエラーにより失敗します。

java.lang.RuntimeException: Unable to create file [D:\AppDynamics\analytics-agent\analytics-agent.id] to store the process id because it already exists. Please stop any currently running process and delete the process id file
CODE

4.3 よりも前のバージョンのエージェントでは、この問題に対処するために、古いプロセス ID ファイルを削除し、エージェントを再起動する必要がありました。

バージョン 4.3 以降では、エージェントの起動時に -f フラグオプションを使用できます。このオプションを使用すると、既存のプロセス ID ファイルが削除されます。Windows サービスとしてエージェントを起動する場合、このフラグは不要です。 

-f フラグは次のように使用します。

  • UNIX タイプ OS：start -f
  • Windows CLI：start -f

-f フラグオプションは、スタンドアロンの Analytics エージェントでのみ機能します。このオプションは、マシンエージェントに組み込まれた Analytics エージェントでは機能しません。マシンエージェントのバージョン 20.6 以降では、バンドルされている Analytics エージェントが PID ファイルをドロップしなくなりました。

マシンエージェント内（組み込みモード）で実行されている Analytics エージェントの場合は、マシンエージェントを 20.6 にアップグレードします。エージェントがクラッシュしていた以前の実行から PID ファイルを削除する必要がなくなりました。

Analytics エージェントを使用しないトランザクション分析（エージェントレス分析）の問題

このセクションでは、エージェントレス分析に関する既知の問題について説明します。 

既知の問題

  • Windows では、Analytics エージェントがファイルからログデータを収集している間、del コマンドを使用してログファイルを削除できません。
  • CPU の高使用率を防ぐため、AppDynamics では、Java エージェントバージョン 20.3 以降（または必要に応じて 4.5.19）をお勧めします。 
  • .NET エージェントで CPU とメモリの使用率が高いかどうかを確認します。
  • Windows でファイルを移動する場合、robocopy/move コマンドは使用しないでください。代わりに、move コマンドを使用することをお勧めします。
  • Analytics エージェントを JRE 1.8.0_171 以降を使用してマシンエージェントの拡張機能として実行している場合、暗号化されたログイン情報を使用して Analytics エージェントを起動することはできません。暗号化を無効にするか、または JRE 1.8.0_162 を使用してマシンエージェントを実行してください。

.NET アプリケーションで Analytics エージェントを使用しないトランザクション分析の有効化

コントローラ、ノード/階層、およびエージェントレベルで、エージェントレス トランザクション分析を有効にできます。 

デフォルトでは、.NET エージェントのエージェントレス分析は無効になっています。エージェントレス分析を有効にすると、展開がエージェントレス分析モードに変更されます。 

コントローラでの有効化

コントローラレベルでエージェントレス分析を有効にするには、次の手順に従います。

  1. http://<localhost:port>/controller/private/ControllerFlagsServlet に移動します。
  2. appdynamics.analytics.features.agentless.enabled を true に設定します。
  3. .NET エージェントが自動的に構成を取得します。

コントローラの全体で機能を無効にするには、次に示すようにプロパティを domain.xml ファイルに渡します。

<jvm-options>-Dappdynamics.analytics.features.agentless.enabled=true</jvm-options>
XML

特定の階層またはノードでのエージェントレス分析の有効化

階層またはノードレベルで機能を有効にするには、agentless-analytics-disabled プロパティを追加し、false に設定します。false に設定すると、このノードプロパティによって階層またはノードがエージェントレス分析モードに変更されます。ノードプロパティを追加するには、「アプリケーションエージェントのノードプロパティ」を参照してください。 

エージェントレス分析の無効化

エージェントレス分析を無効にするには、上記のプロパティを削除するか、agentless-analytics-disabled の値を true に設定します。

既存の Analytics エージェント

コントローラとエージェントを最小バージョンへアップグレードすると、既存の Analytics エージェントはデータの報告を停止します。エージェントレス分析では、Analytics エージェントからのデータは重複しません。コントローラに [Transaction Analytics] が表示された場合、ログ分析を使用していない限り、Analytics エージェントをアンインストールできます。

Java アプリケーションで Analytics エージェントを使用しないトランザクション分析の無効化

コントローラ、ノード/階層、およびエージェントレベルで、エージェントレス トランザクション分析を無効にできます。 

デフォルトでは、Java エージェントのエージェントレス分析は有効になっています。エージェントレス分析を無効にすると、展開が Analytics エージェントモードに戻ります。 

コントローラでの無効化

コントローラレベルでエージェントレス分析を無効にするには、次の手順に従います。

  1. http://<localhost:port>/controller/private/ControllerFlagsServlet に移動します。
  2. appdynamics.analytics.features.agentless.enabled を false に設定します。
  3. Java エージェントを再起動するか、コントローラの設定を更新します。

コントローラの全体で機能を無効にするには、次に示すようにプロパティを domain.xml ファイルに渡します。

<jvm-options>-Dappdynamics.analytics.features.agentless.enabled=false</jvm-options>
XML

特定の階層またはノードでのエージェントレス分析の無効化

階層またはノードレベルで機能を無効にするには、agentless-analytics-disabled プロパティを追加し、true に設定します。true に設定すると、このノードプロパティによって階層またはノードが Analytics エージェントモードに戻ります。ノードプロパティを追加するには、「アプリケーションエージェントのノードプロパティ」を参照してください。 

エージェントレス分析の再有効化

エージェントレス分析を再度有効にするには、上記のプロパティを削除するか、agentless-analytics-disabled の値を false に設定します。

Java エージェントの場合は、Java アプリケーションのトランザクション分析を手動で無効にしてから再度有効にする必要があります。

  1. コントローラ UI で、[Analytics] > [Configuration] に移動します。 
  2. [Transaction Analytics - Configuration] タブに移動し、目的のアプリケーションを見つけます。 
  3. アプリケーションをオフにします。処理を数分待ちます。 
  4. アプリケーションを再チェックしてから、ビジネストランザクションを選択します。エージェントが情報を受信するまで数分待ちます。

既存の Analytics エージェント

コントローラとエージェントを最小バージョンへアップグレードすると、既存の Analytics エージェントはデータの報告を停止します。エージェントレス分析では、Analytics エージェントからのデータは重複しません。コントローラに [Transaction Analytics] が表示された場合、ログ分析を使用していない限り、Analytics エージェントをアンインストールできます。

分析データの問題

クロック管理

AppDynamics では、監視環境全体でクロックタイムを一貫させることが推奨されています。分析メトリックで常にゼロが報告される場合は、アプリケーション、コントローラ、およびイベントサービスノード間でクロックが同期していることを確認します。 

タイムスタンプ

ログ分析では、4 つのタイムゾーンが関連する場合があります。

  1. ログファイルからのタイムスタンプとタイムゾーン。
  2. イベントタイムスタンプおよびピックアップタイムスタンプのタイムゾーンは、次のいくつかの理由により、ログのタイムゾーンとは異なる場合があります。
    1. タイムゾーンが上書きされている。
    2. ログでタイムゾーンが正しく提示されていない。
    3. タイムスタンプとタイムゾーンの解析が失敗した。
    4. ログタイムスタンプでタイムゾーンが指定されていない場合、ローカル時刻が前提となる。
  3. イベント サービス タイムゾーンおよびイベントサービスは、すべてのタイムスタンプを UTC 時間で保存します。
  4. （UI 検索結果または [Time Picker] ウィジェットに表示される [Event Timestamp] 列など）コントローラ UI で分析データを表示するために使用されるブラウザは、すべてのタイムスタンプをブラウザのローカル時刻に変換します。

環境変数

コントローラで分析データが表示されない、または一部のみ表示される場合は、次の環境変数を設定します。

環境変数説明
appdynamics.analytics.agent.send.attempt.maxAPM エージェントで実行されているダイナミックサービスが通信障害後に分析データの送信を試行する最大回数。
appdynamics.analytics.agent.send.attempt.pauseMillis通信障害後に分析データを Analytics エージェントに送信するまでの待機時間。
appdynamics.analytics.numOfSinkWriterTasksAPM エージェントで実行されているダイナミックサービスが Analytics エージェントにデータを送信するために使用するシンクの数。デフォルトの数は 2 で、必要に応じて増やすことができます。

ログ分析の欠落フィールドの抽出に関する問題

ソースルール設定に従い表示される予定のフィールドがログ分析データにない場合、またはフィールド抽出で正規表現（grok パターンを含む）を使用している場合は、パフォーマンスの保護が発生している可能性があります。

正規表現パターンとログ行の照合が 5 秒よりも長くかかる場合、フィールドの抽出試行は終了します。抽出されたフィールドを必要とする後続の処理は行われません。その結果、一部のフィールドが、そのログ行をコントローラで表示したときに欠落する場合があります。この場合、次のエラーメッセージが Analytics エージェントのログに表示されます。

[ERROR ] java.util.concurrent.TimeoutException: The current regex has spent 5 seconds attempting to match the log line, further processing has been stopped for this log line.
CODE

フィールドが欠落するもう 1 つの理由は、ログ行に、パターンで定義されているとおりに抽出されるフィールドが含まれていない場合です。 

カスタム分析メトリックの問題

保存した検索から作成したメトリックに問題がある場合、またはそれらのメトリックのアラートパフォーマンスに問題がある場合は、クエリのバッチサイズを増やしてみてください。[Controller Settings ] > [ Controller Configurations] で analytics.scheduledqueries.batch.size コントローラ設定を使用してサイズを増やすことができます。この設定のデフォルト値は 5 です。 

Controller Configurations

設定へのアクセスについて詳しくは、「Access the Administration Console」を参照してください。  

ビジネス トランザクション イベントの制限

Analytics Dynamic Service は、要求本文がイベントセグメントの配列であるメッセージをイベントサービスに送信します。ビジネス トランザクション イベントは、ビジネストランザクションの requestGUID によって相互に関連付けられる 1 つ以上のセグメントで構成されます。次のようなメッセージに関連する取り込みの制限があります。

  • イベント（セグメント）サイズ：Analytics Dynamic Service によって収集される個々のビジネス トランザクション セグメントの最大サイズは 1 MB です。この制限は、appdynamics.analytics.message.maxSizeBytes Java システムプロパティによって定義されます。この値を変更するには、Java エージェントが起動したときに、コマンドラインでシステムプロパティとして値を渡します。次に例を示します。

    '-Dappdynamics.analytics.message.maxSizeBytes=1024000'
    CODE

  • 要求あたりのイベント数：要求あたりのセグメントの最大数は、appdynamics.analytics.agent.send.batch.items.max Java システムプロパティによって定義されます。このプロパティのデフォルト値は 16 です。この値を変更するには、Java エージェントが起動したときに、コマンドラインでシステムプロパティとして値を渡します。  

  • メッセージサイズ：この制限は、イベントサービスに送信される単一の要求本文のサイズの制限です。要求本文は、通常、イベントセグメントの配列です。すべてのイベントタイプのパブリッシュ要求は 1 MB に制限されます。制限を超えると、エージェントのログファイルとイベントサービスログのメッセージで例外が示されます。 

ファイアウォールの考慮事項

Analytics エージェントを使用しないトランザクション分析では、Java/.NET エージェントとイベントサービス間の接続が必要です。Java/.NET エージェントから SaaS またはオンプレミスのイベントサービスへのリクエストをブロックするファイアウォールがある場合は、分析データのずれを回避するためにファイアウォールを開く必要があります。「接続ポート」と「エージェントとコントローラの接続」を参照してください。

SaaS ベースのインストールでは、（「Installing Agent-Side Components」で説明されているように）\conf\analytics-agent.properties ファイルで http.event.endpoint 設定を変更することで分析エンドポイントを設定します。たとえば、http.event.endpoint=http://analytics.api.appdynamics.com:443 のようになります。 

ファイアウォールルールにより、ホスト名ではなく特定の IP アドレスを使用する必要がある場合は、次の情報に注意してください。（ファイアウォールルールを設定した後でも）収集されたトランザクション分析データを予定どおりに表示できず、ログに次のような Connection Reset メッセージが繰り返し表示される場合は、ファイアウォールルールに正しい IP アドレスが含まれていない可能性があります。

[2015-12-18T16:08:39,907-06:00] [INFO ] [AD Thread Pool-Global0] [o.a.http.impl.execchain.RetryExec] I/O exception (java.net.SocketException) caught when processing request to {s}-&gt;https://analytics.api.appdynamics.com:443: Connection reset
CODE

ファイアウォールルールに正しい IP アドレスが含まれていない可能性があります。

SaaS 環境では、analytics.api.appdynamics.com, fra-ana-api.saas.appdynamics.com, と syd-ana-api.saas.appdynamics.com がラウンドロビン DNS エイリアスであり、次の例のように複数の DNS（54. と 52.）に解決される場合があります。

Name: analytics.api.appdynamics.com
Address: 54.213.173.141
Name: analytics.api.appdynamics.com
Address: 52.88.111.157
CODE 
Name: fra-p-con-2.saas.appdynamics.com
Address: 52.28.42.67
Name: fra-p-con-2.saas.appdynamics.com
Address: 52.57.96.225
CODE 
Name: syd-p-con-1.saas.appdynamics.com
Address: 54.153.248.179
Name: syd-p-con-1.saas.appdynamics.com
Address: 54.153.246.219
CODE

Amazon Web Services（AWS）は、使用される IP を制御します。そのため、それらの IP は随時変更される可能性があります。AWS は現在の IP アドレス範囲を JSON 形式でパブリッシュするため、ホスト名に対してファイアウォールを開くことができない場合は、AWS IP アドレス範囲をダウンロードできます。AWS IP アドレス範囲が変更されるたびに通知を受けるようにするには、Amazon SNS を使用して通知を受信するように登録します。 

SaaS 分析環境の AWS リージョンについては、「分析 IP の範囲」を参照してください。リストされている各リージョンの AWS IP 範囲を確認できます。