アプリケーションでトラフィックの不均一、インスタンスの障害、インターフェースの速度低下などの問題が発生した場合、トレースエクスプローラーを使用して、障害のあるコードをすばやく特定できます。トレースエクスプローラーは、サービストラフィック統計とカナリアリリースの監視にも役立ちます。このトピックでは、5つのシナリオでトレースエクスプローラーを使用する方法について説明します。
背景情報
Application Real-Time Monitoring Service（ARMS）のトレース技術を使用すると、トレースに基づいて単一のリクエストのエラーをトラブルシューティングし、事前に集計されたトレースメトリックをサービスの監視とアラートに使用できます。さらに、トレースエクスプローラー機能は、集計後のトレースデータを分析するのに役立ちます。トレースと事前に集計された監視チャートと比較して、トレースエクスプローラーは、より効率的かつ柔軟な方法で問題を特定し、カスタム診断を実装します。
トレースエクスプローラーを使用すると、保存されている完全なトレースデータに基づいて、リアルタイム分析のためにフィルター条件と集計ディメンションを組み合わせることができます。これは、さまざまなシナリオでのカスタム診断要件を満たすことができます。たとえば、3秒以上かかる低速呼び出しの時系列チャート、異なるインスタンスでの無効なリクエストの分布、またはVIP顧客のトラフィックの変化を表示できます。
シナリオ1：トラフィック分布の不均一
SLBが一部のインスタンスに他のインスタンスよりも多くのトラフィックをルーティングするのはなぜですか？どうすれば修正できますか？
サーバーロードバランサー（SLB）は、無効なSLB構成、レジストリエラーによるノードの再起動の失敗、分散ハッシュテーブル（DHT）の負荷係数エラーなど、さまざまな理由により、一部のインスタンスに他のインスタンスよりも多くのトラフィックをルーティングします。トラフィック分布の不均一により、サービスが利用できなくなる可能性があります。
トラフィックの不均一が発生すると、サービスの速度が低下し、エラーが返されます。これらのケースで一般的な問題をトラブルシューティングする場合、問題を時間内に特定できない場合があります。
トレースエクスプローラーを使用すると、リクエストが分散されているインスタンスや、問題発生後のトラフィック分散の変化など、IPアドレス別にグループ化されたトレースデータを表示できます。多数のリクエストが1つまたは少数のインスタンスに集中している場合、これはトラフィックの不均一が原因である可能性があります。トラフィック分散の変化に基づいて問題をトラブルシューティングし、時間内にロールバックできます。
トレースエクスプローラーページで、トレースデータをIPアドレス別にグループ化します。次の図に示すように、トラフィックの大部分はopentelemetry-demo-frontend-XXインスタンスに集中しています。
シナリオ2：インスタンスの障害
インスタンスの障害をどのようにトラブルシューティングしますか？
ネットワークインターフェースコントローラーの損傷、CPUのオーバーコミット、ディスク使用量の過負荷などのインスタンスの障害は、いつでも発生する可能性があります。インスタンスの障害は、深刻なサービスの利用不能を引き起こすことはありません。ただし、少数のリクエストの失敗またはタイムアウトが発生し、ユーザーエクスペリエンスに継続的に影響を与え、テクニカルサポートのコストが増加します。インスタンスの障害を特定した場合は、できるだけ早く修正する必要があります。
インスタンスの障害は、ホストの障害とコンテナの障害の2つのタイプに分けられます。Kubernetes環境を使用している場合、インスタンスの障害には、ノードの障害とポッドの障害が含まれます。CPUのオーバーコミットやハードウェアの損傷はホストの障害であり、すべてのコンテナに影響します。ディスク使用量の過負荷やメモリリークなどのコンテナの障害は、単一のコンテナにのみ影響します。したがって、ホストIPアドレスとコンテナIPアドレスに基づいて、インスタンスの障害をトラブルシューティングできます。
インスタンスの障害が発生しているかどうかを確認するには、トレースエクスプローラーを使用して、失敗したリクエストまたはタイムアウトしたリクエストをクエリし、ホストIPアドレスまたはコンテナIPアドレスに基づいて集計分析を実行します。無効なリクエストが単一のインスタンスに集中している場合は、別のインスタンスを使用して迅速に回復するか、ディスク使用量やCPUスティール時間などのインスタンスのシステムパラメータを確認できます。無効なリクエストが複数のインスタンスに分散している場合は、これはインスタンスの障害ではありません。ダウンストリームサービスまたはプログラムロジックにエラーがある可能性があります。
トレースエクスプローラーページで、失敗したリクエストまたはタイムアウトしたリクエストをクエリし、リクエストをIPアドレス別にグループ化します。これらのリクエストが特定のインスタンスに集中している場合、そのインスタンスは障害している可能性があります。
シナリオ3：低速なインターフェース
アプリケーションをリリースしたり、プロモーションを実施したりする前に、低速なインターフェースをどのようにクエリしますか？
アプリケーションをリリースしたり、プロモーションを実施したりする前に、包括的なパフォーマンス最適化が必要です。まず、パフォーマンスのボトルネックを特定し、低速なインターフェースのリストと頻度をクエリする必要があります。
低速なインターフェースをトラブルシューティングするには、トレースエクスプローラーを使用して、特定の値よりも多くの時間を消費するインターフェースをクエリし、名前でグループ化します。
次に、トレース、メソッドスタック、スレッドプールに基づいて、低速なインターフェースの理由を分析できます。低速なインターフェースは、次の理由で発生する可能性があります。
データベースまたはマイクロサービスの接続プールが小さすぎて、多数のリクエストが接続を待機しています。接続プールの最大スレッド数を増やすことができます。
外部リクエストと内部リクエストが同時に送信されます。これらのリクエストをマージして、ネットワーク伝送に費やす時間を短縮できます。
単一のリクエストに大量のデータが含まれています。この場合、ネットワーク伝送とデシリアライゼーションに時間がかかり、フルガベージコレクション（GC）が発生する可能性があります。フルクエリをページクエリに置き換えることができます。
同期ロギングの効率が低い。同期ロギングを非同期ロギングに置き換えることができます。
トレースエクスプローラーページで、5秒以上かかる低速なインターフェースをクエリし、IPアドレス別にグループ化します。
シナリオ4：サービストラフィック統計
主要な顧客または店舗のトラフィックの変化とサービス品質をどのように分析しますか？
サービスは複雑で洗練されています。サービスを分析する必要がある場合は、カテゴリ、店舗、ユーザーなど、さまざまなディメンションを考慮する必要がある場合があります。たとえば、実店舗の場合、注文の誤りやPOSマシンの故障により、広報（PR）危機が発生する可能性があります。実店舗は、オンラインストアよりも高いサービスレベルアグリーメント（SLA）要件を備えています。したがって、実店舗のトラフィックの変化とサービス品質を監視する必要がある場合があります。
属性をフィルター条件として設定することにより、トレースデータをクエリおよび分析できます。たとえば、オフライン注文の属性{"attributes.channel": "offline"}を指定できます。また、他の属性を指定して、店舗、ユーザー、カテゴリを区別することもできます。attributes channelがオフラインに設定されているトレースをクエリし、リクエスト数、時間、エラー率別にトレースをグループ化できます。このようにして、顧客または店舗のトラフィックの変化とサービス品質を分析できます。
シナリオ5：カナリアリリースの監視
500個のインスタンスを10バッチでリリースしたいと考えています。最初のバッチ後にエラーをどのように特定しますか？
アプリケーションの安定性を確保するために、カナリアリリース、監視、ロールバックを実装できます。カナリアリリースは、アプリケーションの安定性を確保するための重要な方法です。少数のバッチのインスタンスをリリースした後にエラーが特定された場合は、リリースをロールバックする必要があります。効果的なカナリアリリース監視がないと、サービス障害が発生する可能性があります。
たとえば、マイクロサービスのレジストリに障害が発生した場合、再起動またはリリースする必要のあるインスタンスにマイクロサービスを登録できません。ただし、カナリアリリース監視がないため、エラーを特定できません。これは、サービスの全体的なトラフィックまたは期間に予期しない変更がないためです。すべてのバッチのインスタンスにマイクロサービスを登録することはできません。この場合、サービスは利用できなくなります。
前の例では、異なるバージョンのインスタンスに属性{"attributes.version": "v1.0.x"}を指定し、トレースエクスプローラーを使用してattributes.versionでトレースをクエリできます。このようにして、リリース前後の異なるインスタンスバージョンのトラフィックの変化とサービス品質を区別できます。したがって、カナリアリリースをリアルタイムで監視できます。
制限事項
トレースエクスプローラーは、さまざまなシナリオでのカスタム診断の要件を満たすことができます。ただし、次の制限があります。
詳細なトレースデータに基づく分析のコストは高くなります。
分析の精度を確保するには、完全なトレースデータをトレースエクスプローラーにアップロードする必要があります。ただし、これにより、高いストレージコストが発生する可能性があります。特にネットワーク全体で発生するストレージコストを削減するために、ユーザーのクラスターにエッジノードをデプロイして、データを一時的にキャッシュおよび処理できます。また、サーバー上のホットデータとコールドデータを個別に保存することもできます。次に、トレースエクスプローラーを使用してホットデータを分析します。コールドデータの場合は、低速で無効なトレースのみを分析できます。
集計後分析は、パフォーマンスのオーバーヘッドが高く、並行性が低いため、アラートには適していません。
トレースエクスプローラーは、完全なデータをスキャンし、リアルタイムで統計を生成します。クエリのパフォーマンスオーバーヘッドは、事前に集計された統計よりもはるかに大きくなります。したがって、トレースエクスプローラーは、高い並行性を必要とするアラートには適していません。メトリックをカスタマイズし、クライアントで集計後分析ステートメントを実行して、トレース統計を生成する必要があります。このようにして、アラートとダッシュボードをカスタマイズできます。
トレースエクスプローラーでは、属性を手動で指定する必要があります。
トレースエクスプローラーは、アプリケーション監視の一般的な事前に集計されたメトリックとは異なります。ビジネスシナリオを区別し、正確な分析を実行するには、さまざまな属性を手動で指定する必要があります。
参照
1つ以上のインターフェースのアラートを構成できます。このようにして、例外が発生したときに、アラート通知がO＆Mチームに送信されます。詳細については、「アプリケーション監視のアラートルール」を参照してください。