すべてのプロダクト
Search
ドキュメントセンター

Application Real-Time Monitoring Service:ビジネストレースのベストプラクティス

最終更新日:Apr 25, 2025

このトピックでは、eコマースプラットフォームのシナリオに焦点を当て、開発と運用保守の両方の観点から、ビジネストレース分析機能を使用して問題を効果的に対処する方法についての洞察を提供します。

サンプルシナリオ

ある e コマースプラットフォームは、エンドツーエンドの監視機能を実現するために、ビジネスシステム全体を Application Real-Time Monitoring Service (ARMS) と完全に統合し、日々の運用におけるパフォーマンス監視、障害診断、およびキャパシティ分析をサポートしています。来たるジュエリーの大規模プロモーションに向けて、技術保証チームは特別会議を開催してサポート計画を展開し、既存の監視システムにおける以下の重要な問題を特定しました。

  • ビジネスディメンション監視の欠如

    R&D チームが注文配置インターフェイスの監視の詳細を確認していたところ、現在のシステムはインターフェイスレベルのメトリック集約(QPS、応答時間、エラー率など)のみをサポートしており、ジュエリー、アパレル、3C などのビジネスカテゴリ別のトラフィック層別分析を実行できないことを発見しました。この結果、以下のようになります。

    • プロモーション期間中に、ジュエリー固有のトラフィックが急増した場合、システムリソースの真の消費量を正確に特定することができません。

    • アラート構成では、ジュエリー固有のトランザクショントレースに特化した独立したしきい値を設定できません。

    image.png

  • 不十分なキャパシティ評価機能

    運用保守チームがサービストポロジーアーキテクチャを分析したところ、既存の依存関係トポロジーは静的なサービス呼び出し関係のみを表示でき、動的なビジネストラフィックをマッピングする機能が不足していることがわかりました。具体的には、以下のとおりです。

    • ジュエリー固有のビジネストラフィックの実際の負荷を、さまざまなマイクロサービスコンポーネント全体で定量化することができません。

    • スケーリングの決定にはデータサポートがなく、注文サービスや在庫サービスなどのコアモジュールのスケーリング比率を科学的に評価することができません。

    image.png

ビジネストレース分析

前述の問題は、ビジネストレース分析機能によって効果的に解決できます。

  1. ビジネスエントリのマーキング:ジュエリー固有のトランザクションを処理するビジネスエントリアプリケーション(注文サービスエントリゲートウェイなど)を識別してマーキングします。

  2. 完全自動トレース:分散トレーシング技術に基づいて、エントリアプリケーションから支払い、在庫などのダウンストリームサービスまでの完全なトレースに沿ってビジネストラフィックをインターフェイスレベルの粒度まで自動的に分析し、ジュエリー固有のタグ付けを適用して差別化します。

  3. インテリジェントアラート構成:ジュエリー固有のディメンションに基づいた独立したアラートポリシーをサポートします(たとえば、ジュエリー固有の支払トレースのレイテンシがしきい値を超えた場合に特定のアラートをトリガーします)。

ステップ 1:ビジネスパラメータを抽出する

ビジネスパラメータ抽出ルールを構成することにより、システムはリクエストパラメータからビジネスディメンション識別子を自動的に解析できます。ジュエリーカテゴリの注文配置インターフェイスを例にとると、「カテゴリ」情報は入力パラメータから取得され、サンプルコードでは、注文カテゴリ情報は CommonRequestBody オブジェクトにあります。

@RequestMapping(value = "/order", produces = "application/json", method = RequestMethod.POST)
    public CommonResult<?> order(@RequestBody CommonRequestBody requestBody) throws Exception {
        bizO11yHandleService.syncCall(requestBody);
        return CommonResult.succeeded(new CommonData("Cache",
                "{\"param1\":\"value1\",\"resultCode\":" + requestBody.getCode() + "}",
                "succeeded.", requestBody.getCode()));
    }

注文配置インターフェイスのCommonRequestBody では、ビジネスカテゴリ識別子category は、リクエスト本文のネストされたオブジェクトextraInfo に格納されています。

CommonRequestBody

@Data
public class CommonRequestBody {

    private String requestId;

    private int code;

    private boolean needDetail;

    private Map<String, String> extraInfo;
}

CommonRequestBody JSON リクエスト本文

{
  "code": 200,
  "needDetail": true,
  "requestId": "req-32413",
  "extraInfo": {
    "orderNumber": "ord-xxxxx",
    "level": "vip",
    "arms": "good",
    "source": "app",
    "category": "jewelry"
  }
}

カテゴリ情報を見つけたら、エントリアプリケーションの [構成] > [ビジネスパラメータ抽出ルール] ページで、非侵入型でジュエリーカテゴリのカテゴリ属性を抽出できます。詳細については、「ビジネスパラメータを抽出する」をご参照ください。

image

パラメータ

説明

ルール名

カスタムルール名。

カテゴリ

属性名

ルールによって抽出された値に対応するスパン内の属性の名前。

category

パラメータ抽出タイプ

抽出するパラメータのタイプ。

HTTP サーバーリクエスト

パラメータルール構成

  • 有効なインターフェイス(HTTP タイプ):このルールが適用される HTTP インターフェイスの範囲。ARMS エージェントは、正常に一致したインターフェイスからのみ対応するパラメータを抽出します。

  • テキストエンコーディングタイプ:抽出するパラメータテキストのエンコーディングタイプ。

  • パラメータ抽出ルール:

    • パラメータソース:抽出するパラメータが存在する実際のキャリアソース。

    • パラメータ処理ステップ:パラメータキャリアから最終的なパラメータ値を段階的に解析するために使用される一連のストリーミング処理ステップ。

  • 有効なインターフェイス:/api/v1/biz/order と等しい

  • テキストエンコーディングタイプ:UTF-8

  • パラメータ抽出ルール:

    • パラメータソース:本文

    • Ognl:extraInfo

    • JsonPath:category

有効化ステータス

このルールを有効にするかどうかを指定します。

はい

ステップ 2:ビジネストレースを構成する

抽出されたcategory ビジネスパラメータに基づいて、ビジネス トレース リスト ページでこのビジネスパラメータのトレースを構成します。

image.png

パラメータ

説明

ビジネス名

ビジネストレースのカスタム名。

ジュエリー注文

ビジネスコード

一意のトレース識別子。メトリックに関連付けられてトレースをマークします。

jewelry_order

入力アプリ

ビジネスのエントリアプリケーションを選択します。エントリアプリケーションの ARMS エージェントバージョンは 4.3.0 以降である必要があります。

biz-trace-demo

入力インターフェイス

ビジネスのエントリインターフェイスを選択します。現在、HTTP インターフェイスのみがサポートされています。

/api/v1/biz/order

特性パラメータ

エントリインターフェイスに基づいて入出力パラメータを構成して、よりきめ細かいマッチングを実行します。このセクションの設定はオプションです。

-

特性構成

  • 同時に、次のルールが満たされます:AND ロジックを使用します。複数のルールの場合は、すべてのルールを満たすリクエストまたはトラフィックフローのみが、対応するビジネストレースに属するものとして識別されます。

  • 次のルールのいずれかを満たします:OR ロジックを使用します。複数のルールの場合は、いずれかの単一のルールに一致するリクエストまたはトラフィックフローが、対応するビジネストレースに属するものとして識別されます。

同時に、次のルールが満たされます

ルールパラメータ

  • ビジネスパラメータルールは、エントリアプリケーションで構成されたビジネスパラメータ抽出ルールから選択できます。

  • マッチングルールは現在、「含む」をオプションとしてサポートしています。

  • 複数のルール値を選択できます。報告されていない値は、カスタム入力で追加できます。

カテゴリ に「jewelry」が含まれる

トレースの詳細を表示する

ビジネストレースが作成されると、ARMS エージェントはそれを自動的に識別します。 前提条件注: ページで、 をクリックしてビジネストレースの詳細を表示します。図に示すように、ジュエリー固有の注文配置トレースは元のフルスケールの注文配置トレースから分離され、専用の監視ビューが形成されます。

image.png

ビジネストレース分析機能を使用することで、運用保守チームは、トポロジーグラフでジュエリー固有の注文配置トレースの完全な依存関係、主要なアプリケーションとインターフェイス、およびエントリトラフィックからさまざまなアプリケーションへのリクエストを直接観察できます。上記のデータに基づいて、運用保守チームは、このプロモーションに必要なアーキテクチャの依存関係とスケーリング比率に関する的を絞った洞察を提供できます。

ステップ 3:アラートを構成する

ジュエリー固有の注文配置トレースを分離したら、このトレース専用のアラートを構成できます。

ビジネストレース監視のデータソースは、デフォルトで Managed Service for Prometheus に統合されており、対応するインスタンス名は metricstore-apm-metrics-custom_<regionId>_default-cms-<userId>-<region> です。PromQL ステートメントを作成することで、カスタムアラート構成を完了できます。

たとえば、注文リクエスト数が 1 を超えた場合にアラートをトリガーする場合、対応する PromQL ステートメントは次のようになります。

sum(sum_over_time_lorc(arms_biz_app_requests_count_raw{_biz_code="jewelry_order",serverIp=~".*",callKind=~"http|rpc|custom_entry|server|consumer|schedule",pid="ckv8e2vzfj@f17de22dde9bd19",rpc=~"/api/v1/biz/order",source="apm",}[1m]))>1
説明

Prometheus アラートルールを作成する方法については、「Prometheus インスタンスのアラートルールを作成する」をご参照ください。

image.png

PromQL ステートメントを作成する

監視詳細パネルの image アイコンをクリックして、対応する PromQL ステートメントを表示します。詳細については、「クエリステートメント」をご参照ください。

image

たとえば、次の PromQL ステートメントについて考えてみます。

sum(sum_over_time_lorc(arms_biz_app_requests_count_raw{_biz_code="jewelry_order",serverIp=~".*",callKind=~"http|rpc|custom_entry|server|consumer|schedule",pid="ckv8e2vzfj@f17de22dde9bd19",rpc=~"/api/v1/biz/order",source="apm",}[$__range])) or vector(0)

プレースホルダーを削除し、アラート条件を追加します。この例では、リクエスト数を 1 より大きく設定します。変更された PromQL ステートメントは次のようになります。

sum(sum_over_time_lorc(arms_biz_app_requests_count_raw{_biz_code="jewelry_order",serverIp=~".*",callKind=~"http|rpc|custom_entry|server|consumer|schedule",pid="ckv8e2vzfj@f17de22dde9bd19",rpc=~"/api/v1/biz/order",source="apm",}[1m]))>1

アラート通知を表示する

アラートが構成されると、一致するトラフィックが着信したときにアラートがトリガーされます。さらに、大規模なプロモーションイベントのエラー率やレイテンシなどのメトリックに基づいてアラートルールをカスタマイズすることもできます。

ビジネストレースの [イベント分析] ページで、生成されたすべてのアラートイベントを表示できます。