このトピックでは、eコマースプラットフォームのシナリオに焦点を当て、開発と運用保守の両方の観点から、ビジネストレース分析機能を使用して問題を効果的に対処する方法についての洞察を提供します。
サンプルシナリオ
ある e コマースプラットフォームは、エンドツーエンドの監視機能を実現するために、ビジネスシステム全体を Application Real-Time Monitoring Service (ARMS) と完全に統合し、日々の運用におけるパフォーマンス監視、障害診断、およびキャパシティ分析をサポートしています。来たるジュエリーの大規模プロモーションに向けて、技術保証チームは特別会議を開催してサポート計画を展開し、既存の監視システムにおける以下の重要な問題を特定しました。
ビジネスディメンション監視の欠如
R&D チームが注文配置インターフェイスの監視の詳細を確認していたところ、現在のシステムはインターフェイスレベルのメトリック集約(QPS、応答時間、エラー率など)のみをサポートしており、ジュエリー、アパレル、3C などのビジネスカテゴリ別のトラフィック層別分析を実行できないことを発見しました。この結果、以下のようになります。
プロモーション期間中に、ジュエリー固有のトラフィックが急増した場合、システムリソースの真の消費量を正確に特定することができません。
アラート構成では、ジュエリー固有のトランザクショントレースに特化した独立したしきい値を設定できません。

不十分なキャパシティ評価機能
運用保守チームがサービストポロジーアーキテクチャを分析したところ、既存の依存関係トポロジーは静的なサービス呼び出し関係のみを表示でき、動的なビジネストラフィックをマッピングする機能が不足していることがわかりました。具体的には、以下のとおりです。
ジュエリー固有のビジネストラフィックの実際の負荷を、さまざまなマイクロサービスコンポーネント全体で定量化することができません。
スケーリングの決定にはデータサポートがなく、注文サービスや在庫サービスなどのコアモジュールのスケーリング比率を科学的に評価することができません。

ビジネストレース分析
前述の問題は、ビジネストレース分析機能によって効果的に解決できます。
ビジネスエントリのマーキング:ジュエリー固有のトランザクションを処理するビジネスエントリアプリケーション(注文サービスエントリゲートウェイなど)を識別してマーキングします。
完全自動トレース:分散トレーシング技術に基づいて、エントリアプリケーションから支払い、在庫などのダウンストリームサービスまでの完全なトレースに沿ってビジネストラフィックをインターフェイスレベルの粒度まで自動的に分析し、ジュエリー固有のタグ付けを適用して差別化します。
インテリジェントアラート構成:ジュエリー固有のディメンションに基づいた独立したアラートポリシーをサポートします(たとえば、ジュエリー固有の支払トレースのレイテンシがしきい値を超えた場合に特定のアラートをトリガーします)。
ステップ 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"
}
}カテゴリ情報を見つけたら、エントリアプリケーションの ページで、非侵入型でジュエリーカテゴリのカテゴリ属性を抽出できます。詳細については、「ビジネスパラメータを抽出する」をご参照ください。

パラメータ | 説明 | 例 |
ルール名 | カスタムルール名。 | カテゴリ |
属性名 | ルールによって抽出された値に対応するスパン内の属性の名前。 | category |
パラメータ抽出タイプ | 抽出するパラメータのタイプ。 | HTTP サーバーリクエスト |
パラメータルール構成 |
|
|
有効化ステータス | このルールを有効にするかどうかを指定します。 | はい |
ステップ 2:ビジネストレースを構成する
抽出されたcategory ビジネスパラメータに基づいて、ビジネス トレース リスト ページでこのビジネスパラメータのトレースを構成します。

パラメータ | 説明 | 例 |
ビジネス名 | ビジネストレースのカスタム名。 | ジュエリー注文 |
ビジネスコード | 一意のトレース識別子。メトリックに関連付けられてトレースをマークします。 | jewelry_order |
入力アプリ | ビジネスのエントリアプリケーションを選択します。エントリアプリケーションの ARMS エージェントバージョンは 4.3.0 以降である必要があります。 | biz-trace-demo |
入力インターフェイス | ビジネスのエントリインターフェイスを選択します。現在、HTTP インターフェイスのみがサポートされています。 | /api/v1/biz/order |
特性パラメータ | エントリインターフェイスに基づいて入出力パラメータを構成して、よりきめ細かいマッチングを実行します。このセクションの設定はオプションです。 | - |
特性構成 |
| 同時に、次のルールが満たされます |
ルールパラメータ |
| カテゴリ に「jewelry」が含まれる |
トレースの詳細を表示する
ビジネストレースが作成されると、ARMS エージェントはそれを自動的に識別します。 前提条件注: ページで、 をクリックしてビジネストレースの詳細を表示します。図に示すように、ジュエリー固有の注文配置トレースは元のフルスケールの注文配置トレースから分離され、専用の監視ビューが形成されます。

ビジネストレース分析機能を使用することで、運用保守チームは、トポロジーグラフでジュエリー固有の注文配置トレースの完全な依存関係、主要なアプリケーションとインターフェイス、およびエントリトラフィックからさまざまなアプリケーションへのリクエストを直接観察できます。上記のデータに基づいて、運用保守チームは、このプロモーションに必要なアーキテクチャの依存関係とスケーリング比率に関する的を絞った洞察を提供できます。
ステップ 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]))>1Prometheus アラートルールを作成する方法については、「Prometheus インスタンスのアラートルールを作成する」をご参照ください。

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

たとえば、次の 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アラート通知を表示する
アラートが構成されると、一致するトラフィックが着信したときにアラートがトリガーされます。さらに、大規模なプロモーションイベントのエラー率やレイテンシなどのメトリックに基づいてアラートルールをカスタマイズすることもできます。
ビジネストレースの [イベント分析] ページで、生成されたすべてのアラートイベントを表示できます。