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

シナリオ

ある E コマースプラットフォームでは、エンドツーエンドのパフォーマンスモニタリング、障害診断、キャパシティ分析のために Application Real-Time Monitoring Service (ARMS) を使用しています。大規模なジュエリープロモーションの準備を進める中で、技術保証チームはサポートプランを展開するための特別会議を開き、2 つの課題を特定しました。

ビジネスディメンションのモニタリングができない。注文受付インターフェイスは、すべての製品カテゴリにわたる集計メトリックをレポートするため、業務カテゴリ (ジュエリー、アパレル、3C など) ごとのトラフィック階層化分析を実行できません。プロモーション期間中：

• ジュエリーのトラフィックが急増しても他のカテゴリと区別できず、ジュエリー固有のリソース消費量を測定することができません。

• アラートルールでジュエリーのトランザクションを個別に対象とすることができません。

動的なキャパシティモデリングが不十分。サービストポロジーは静的な呼び出し関係を示しますが、ビジネスレベルのトラフィック分散は示しません。

• ジュエリーのトラフィックが各マイクロサービスコンポーネントにかける実際のロードが不明です。

• 注文サービスや在庫サービスなどのコアモジュールのスケーリング決定にデータサポートがありません。

ビジネストレース分析の仕組み

ビジネストレース分析は、3 つの機能でこれらの課題の両方に対処します。

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

2. トレースの自動伝播。ARMS は、エントリーアプリケーションからダウンストリームサービス (決済、在庫など) へのビジネストラフィックをインターフェイスレベルで自動的に追跡し、各スパンに業務カテゴリをタグ付けします。この伝播は分散トレーシングに基づいており、追加のインストルメンテーションは不要です。

3. カテゴリ固有のアラート機能。特定のビジネストレースを対象としたアラートルールを設定します。例えば、ジュエリー決済のレイテンシーがしきい値を超えた場合にアラートをトリガーします。

以下の手順では、ジュエリーカテゴリを例として使用します。

前提条件

開始する前に、以下を確認してください。

• ARMS アプリケーション監視と統合された E コマースアプリケーション

• エントリーアプリケーションに ARMS エージェントバージョン 4.3.0 以降がインストールされていること

• リクエストボディでビジネスパラメーターを受け入れる HTTP エントリーインターフェイス

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

ビジネスパラメーター抽出機能を使用すると、ARMS はコードを変更することなく、リクエストペイロードからビジネス識別子を解析できます。抽出された属性はスパンにアタッチされ、ダウンストリームでのフィルタリングやトレース定義が可能になります。

ジュエリーのシナリオでは、注文受付インターフェイスはリクエストボディの extraInfo オブジェクト内にある category フィールドを受け取ります。

注文受付エンドポイント：

@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()));
    }

@Data
public class CommonRequestBody {

    private String requestId;

    private int code;

    private boolean needDetail;

    private Map<String, String> extraInfo;
}

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

category の値 ("jewelry") が、抽出するビジネス識別子です。

抽出ルールの作成

エントリ アプリケーションで [設定] > [ビジネスパラメーター抽出ルール] に移動し、以下の設定でルールを作成します。 詳細については、「ビジネスパラメーターを抽出する」をご参照ください。

パラメーター	説明	例
ルール名	この抽出ルールのカスタム名です。	カテゴリ
属性名	抽出された値を格納するスパン属性名です。	category
パラメーター抽出タイプ	パラメーターソースのタイプです。	HTTP サーバーリクエスト
パラメーター ルール設定	スコープと解析ロジックを定義します。
	- 有効なインターフェイス：このルールが適用される HTTP インターフェイスです。ARMS エージェントは、一致したインターフェイスからのみパラメーターを抽出します。	次と等しい /api/v1/biz/order
	- テキストエンコーディングタイプ：パラメーターテキストのエンコーディングです。	UTF-8
	- パラメーターソース：リクエスト内でパラメーターが存在する場所です。	ボディ
	- パラメーター処理ステップ：パラメーターソースから最終的なパラメーター値を段階的に解析するために使用される一連のストリーミング処理ステップです。
	- Ognl：ネストされたオブジェクトへのパスです。	extraInfo
	- JsonPath：オブジェクト内のフィールド名です。	category
有効化ステータス	このルールを有効にするかどうか。	はい

ルールを保存すると、ARMS エージェントは一致するスパンに category 属性のアタッチを開始します。この属性は、次のステップで定義するビジネストレースの基盤となります。

ステップ 2: ビジネストレースの定義

category 属性がスパンで利用可能になったので、ジュエリー関連のトラフィックをフィルタリングするビジネストレースを作成します。

[ビジネストレースリスト] ページに移動し、以下の設定でビジネストレースを作成します。 詳細については、「ビジネストレースの作成」をご参照ください。

ビジネストレースの検証

ビジネストレースを作成すると、ARMS エージェントが一致するトラフィックを自動的に識別します。[サービスリンク分析] ページに移動し、[ジュエリー注文] をクリックしてトレース詳細を開きます。詳細については、「ビジネストレース詳細」をご参照ください。

ジュエリー注文のトラフィックは、フルスケールの注文トレースから分離され、専用のモニタリングビューに表示されるようになります。

トポロジーグラフには以下が表示されます。

• ジュエリー注文トレースの完全な依存関係

• トレースパス上のアプリケーションとインターフェイス

• エントリーポイントから各ダウンストリームアプリケーションへのリクエスト量

このデータを使用して、プロモーションのアーキテクチャ上の依存関係やスケーリング比率について、的を絞った意思決定を行います。

ステップ 3: アラート機能の設定

ジュエリー注文トレースが分離されたので、このビジネスディメンションに特化したアラートを設定します。

PromQL アラートルールの作成

メトリックのベースとなる PromQL 文を取得するには、モニタリング詳細パネルの アイコンをクリックします。詳細については、「クエリ文」をご参照ください。

ベースとなる文には、$__range プレースホルダーが含まれています。

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. $__range を 1m のような固定タイムウィンドウに置き換えます。

2. or vector(0) を削除します。

3. >1 のようなしきい値条件を追加します。

結果として得られるアラートルールは次のとおりです。

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

この例では、ジュエリー注文のリクエスト数が 1 分間のウィンドウ内で 1 を超えるとアラートがトリガーされます。

説明

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

次のステップ

• ビジネスパラメーターの抽出 -- 追加の抽出タイプと高度なパラメータールール。

• ビジネストレース詳細 -- トポロジーとメトリックを含む、ビジネストレースの完全なモニタリングビュー。

• Prometheus インスタンスのアラートルールを作成する -- PromQL による高度なアラートルール。

• イベント分析 -- ビジネストレースのアラートイベント分析。