Application Real-Time Monitoring Service:ログ分析

XML 設定を変更すると、ログの関連付けが失敗するのはなぜですか？

SLS でログをクエリするときにこの問題が発生した場合は、まず、ログが SLS に報告されていること、および ARMS コンソールで正しいプロジェクトと Logstore を関連付けていることを確認します。

SLS にデータが存在することを確認した後、次の 2 つのシナリオに基づいて問題をトラブルシューティングします。

• どのログもトレース ID と関連付けられていない。この問題には、いくつかの原因が考えられます。

  • エージェントが正常にアタッチされていない。

    ARMS コンソールですべてのメトリクスが正しく表示されるかを確認することで、これを検証できます。

  • エージェントのメインスイッチが無効になっているか、Tomcat プラグインなどの特定のプラグインがオフになっている。

    これは、[Custom configurations] ページの [Agent switch settings] セクションで確認できます。

  • サーバー側のフレームワークがサポートされていない。たとえば、サポートされていない Web コンテナ、RPC フレームワーク、スケジュールされたタスクフレームワーク、またはメッセージングフレームワークを使用している可能性があります。サポートされているフレームワークのリストについては、「アプリケーションモニタリングでサポートされている Java コンポーネントとフレームワーク」をご参照ください。

  • Log4j、Log4j2、または Logback 以外のロギングフレームワークを使用しているか、これらのフレームワークを大幅に変更している。

  • ログの XML 設定が正しくない。

    以下の手順で調査します。

    • エージェントバージョン 4.1.6 以降を使用している場合は、トレース ID の自動挿入機能を有効にします。トレース ID が関連付けられる場合、これはログの XML 設定にエラーがあることを示します。

    • ARMS SDK for Java をインポートし、ログを出力するときに手動でトレース ID を取得します。以下はサンプルコードです。

      Span span = Tracer.builder().getSpan();   // これは新しいスパンを作成しません。
      String traceId = span.getTraceId();
      logger.warn("traceId={} this is your log message", traceId)

      トレース ID を取得できる場合、これはログの XML 設定にエラーがあることを示します。

    • 両方の方法が失敗した場合は、してください。

• 一部のログがトレース ID と関連付けられていない。これは、ログにトレースコンテキストがないことが原因である可能性があります。

  通常、ログが書き込まれるときにはトレースコンテキストがありません。トレースコンテキストは通常、HTTP インターフェイス、RPC インターフェイス、スケジュールされたタスク、またはメッセージを消費する処理コードなど、リクエストのエントリポイントで出力されるログにのみ存在します。

  サンプルシナリオ：

  • アプリケーションが HTTP リクエストを受信した後、データベースクエリを実行し、その後ログを出力します。この場合、トレースコンテキストが存在し、ログはトレース ID と正常に関連付けられます。

  • アプリケーションが HTTP リクエストを受信し、非同期タスクをスレッドプールに送信してデータベースクエリを実行し、その後ログを出力します。

    • エージェント v3.x の場合、エージェントはトレースコンテキストの自動的な非同期伝播をサポートしていないため、ログをトレース ID と関連付けることはできません。非同期スレッドにはトレースコンテキストがありません。

    • エージェント v4.x の場合、エージェントはトレースコンテキストの自動的な非同期伝播をサポートしているため、ログをトレース ID と関連付けることができます。非同期スレッドにはトレースコンテキストがあります。

  • 起動後、アプリケーションは JDK スレッドプールを使用して周期的にデータベースクエリを実行し、各クエリの後にログを出力します。この場合、トレースコンテキストは存在せず、ログをトレース ID と関連付けることはできません。

  ログを書き込んだスレッドの名前を確認することで、特定のシナリオを特定できます。

  例：

  • Tomcat を Web コンテナとして使用する場合、http-nio- で始まるスレッド名は、通常、HTTP リクエストを処理するスレッドを表します。これらのスレッドによって出力されたログは、トレース ID と関連付けることができます。

  • Dubbo を RPC フレームワークとして使用する場合、DubboServerHandler- で始まるスレッド名は、通常、Dubbo リクエストを処理するスレッドを表します。これらのスレッドによって出力されたログは、トレース ID と関連付けることができます。

  他のフレームワークも同様に動作します。問題がこれらのどのシナリオにも当てはまらない場合は、してください。

トレースエクスプローラーでログが空になるのはなぜですか？

以下のトラブルシューティング手順に従ってください。

1. アプリケーションのログがどれもトレース ID と関連付けられていないかどうかを確認します。その場合は、「XML 設定を変更すると、ログの関連付けが失敗するのはなぜですか？」のトラブルシューティング手順をご参照ください。そうでない場合は、次のステップに進みます。

2. 1 つ以上の特定のインターフェイスで、トレース ID に対応するログが見つからない場合、通常はそのインターフェイスがログを一切出力しなかったことを意味します。

3. 上記のどのシナリオにも当てはまらない場合は、してください。

Logstore を関連付けた後に空になるのはなぜですか？

SLS ドキュメントに従って、Logstore のログ収集を設定する必要があります。ARMS は自動的にログを Logstore に収集しません。

ゲートウェイログでトレース ID の関連付けが失敗するのはなぜですか？

v3.x エージェントには、Spring Cloud Gateway のインストルメンテーションに既知の不具合があります。v4.x エージェントにアップグレードすると、この問題は解決されます。

TraceCallable.wrap() を使用するとトレース ID の関連付けが失敗するのはなぜですか？

これは、メソッドが誤って使用されていることを示します。コードを変更せずに非同期シナリオを処理する v4.x エージェントへのアップグレードを推奨します。

自動挿入でトレース ID の関連付けが失敗するのはなぜですか？

この問題は通常、2 つの状況で発生します。

• どのログもトレース ID と関連付けられていない：これは通常、設定がエージェントに正常に適用されなかったことを示します。「Java アプリケーションモニタリングのネットワーク設定」をご参照のうえ、Application Configuration Management (ACM) サーバーへの接続を確認してください。

• 一部のログがトレース ID と関連付けられていない：「XML 設定を変更すると、ログの関連付けが失敗するのはなぜですか？」のトラブルシューティング手順をご参照ください。

ARMS は SLS の代わりになりますか？

いいえ。ARMS と SLS は異なる目的を果たし、互いに置き換えるのではなく補完し合います。

• ARMS は、トレース分析、API モニタリング、およびアプリケーションパフォーマンス分析に焦点を当てた Application Performance Monitoring (APM) 製品です。ARMS のログ分析機能は、関連付けた SLS プロジェクトと Logstore からログをクエリするため、ログストレージバックエンドとして SLS を使用します。ARMS は、ユーザーの代わりに Logstore にログを収集しません。

• SLS は、ログの収集、保存、分析のための汎用サービスであり、複数のデータソースからのデータ取り込みをサポートしています。

ARMS のログ分析機能を使用するには、このトピックのステップ 1: ビジネスログの関連付けの説明に従って、SLS プロジェクトと Logstore を関連付けます。 次に、上部のナビゲーションバーでシナリオ分析 > ログ分析を選択して、ログをクエリおよび分析します。