分析の問題のトラブルシューティング

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

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

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

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

• Analytics エージェント：Analytics エージェントは、<analytics_agent_home>/logs ディレクトリにあるファイルにログメッセージを書き込みます。
• イベントサービス：イベントサービスは、<events_service_home>/logs ディレクトリにあるファイルにログメッセージを書き込みます。events-service-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 エージェントのロギング」を参照してください。

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

Windows では、Analytics エージェントがファイルからログデータを収集している間、del コマンドでログファイルを削除できません。

Windows では、robocopy コマンドを使用してファイルを移動しないでください。Splunk AppDynamics では、代わりに move コマンドを使用することを推奨しています。

Analytics エージェントを JRE 1.8.0_171 以降を使用してマシンエージェントの拡張機能として実行している場合、暗号化されたログイン情報を使用して Analytics エージェントを起動することはできません。回避策は次のとおりです。

• マシンエージェントで暗号化を無効にする
• 暗号化を有効にしたスタンドアロン Analytics エージェントを使用する
• JRE 1.8.0_162 を使用して、暗号化を有効にしたマシンエージェントを実行する

PID ファイル

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

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

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

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

トランザクション分析ライセンスの制限に達すると、古い Java エージェントで CPU 使用率が高くなることがあります。Splunk AppDynamics では、Java エージェントバージョン 20.3 以降にアップグレードすることを推奨しています。.NET エージェントで CPU とメモリの使用率が高いかどうかを確認します。

Clock Management

Splunk AppDynamics recommends maintaining clock-time consistency throughout your monitored environment. If Analytics metrics are consistently reporting zero, confirm that clocks are synchronized across the application, Controller, and Events Service nodes.

Timestamps

There are potentially four time zones involved with Log Analytics:

1. The timestamp and time zone from the log file.
2. The event timestamp and pickup timestamp time zones can be different from those in the log for a number of reasons:
   1. When the time zone is overridden.
   2. The time zone is not provided correctly in the log.
   3. The timestamp and time zone parsing goes awry.
   4. When no time zone is specified in the log timestamp, then local time is assumed.
3. The Events Service time zone and the Events Service stores all timestamps in UTC time.
4. The browser used to view the Analytics data in the Controller UI (such as the Event Timestamp column in the UI search results or the Time Picker widget) converts all timestamps to the browser's local time.

Environment Variables

If you are not seeing or only seeing partial Analytics data in the Controller, configure the following environment variables.

ソースルール設定に従い表示される予定のフィールドがログ分析データにない場合、またはフィールド抽出で正規表現（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.

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

設定へのアクセスについては、「2023-10-19_05-04-05_管理コンソールへのアクセス」を参照してください。

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

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

  CODECopy

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

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

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

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

Java エージェントの Analytics コンポーネントは、パフォーマンスメトリックをレポートします。これらのメトリックを使用して、エージェントおよびノードのトランザクション分析レポートの正常性をモニタできます。メトリックブラウザでこれらのメトリックは、Agent|Analytics|<Metric Name> パスの下に表示されます。

Transaction Analytics without an Analytics Agent requires a connection between the Java/.NET Agent and the Events Service. If you have a firewall that blocks requests from the Java/.NET Agent to the SaaS or on-premises Events Service, you need to open the firewall to avoid gaps in Analytics data. See Port Settings and Agent-to-Controller Connections.

For SaaS-based installations, configure the Analytics endpoint by modifying the http.event.endpoint setting in the \conf\analytics-agent.properties file (as described in Install Agent-Side Components). For example, http.event.endpoint=http://analytics.api.appdynamics.com:443.

If your firewall rules require you to use specific IP addresses, rather than hostnames, note the following information. If you are unable to see Transaction Analytics data collected as expected (even after configuring your firewall rules) and you see repetitive Connection Reset messages in the logs similar to the following, your firewall rules may not include the correct IP addresses.

[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}->https://analytics.api.appdynamics.com:443: Connection reset

Your firewall rules may not include the correct IP addresses.

In SaaS environments, analytics.api.appdynamics.com, fra-ana-api.saas.appdynamics.com, and syd-ana-api.saas.appdynamics.com are round-robin DNS aliases and may resolve to multiple DNS (54. vs 52.) in the following examples.

Name: analytics.api.appdynamics.com Address: 54.213.173.141 Name: analytics.api.appdynamics.com Address: 52.88.111.157

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

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>

Amazon Web Services (AWS) controls the IPs used, so they may change from time to time. AWS publishes its current IP address ranges in JSON format, so if you are unable to open firewalls to hostnames, you can download the AWS IP address ranges. If you want to be notified whenever there is a change to the AWS IP address ranges, you can subscribe to receive notifications using Amazon SNS.

See Analytics IP Ranges for the AWS regions for the SaaS Analytics environments. You can view the AWS IP Ranges for each listed region.