Elastic Algorithm Service (EAS) を使用すると、ご利用のサービスコードからカスタムメトリックをレポートし、それらのメトリックをモニタリングダッシュボードや Auto Scaling ルールで使用できます。これは、組み込みメトリックではビジネスニーズのシグナル (例: 状態コード別のリクエストエラー率や1秒あたりの例外数など) を捕捉できない場合に役立ちます。
仕組み
ご利用のサービスコードにレポート呼び出しを追加します。定義したスケジュールで、コードはメトリックデータを組み込みエンドポイント
http://localhost:8080/api/builtin/realtime_metricsに POST します。ご利用のサービスの JSON 構成でメトリックを宣言します。EAS はデプロイメント時にこの宣言を読み取り、メトリックのモニタリングダッシュボードを構築します。
デプロイメント後、[サービス監視] タブでメトリックを表示できます。データは報告されてから 1 分以内に表示され、分単位で正確です。メトリックデータは 1 週間保持されます。
オプションで、Auto Scaling ルールでカスタムメトリックを使用します。
制限事項
metricsフィールドは、カスタムイメージまたはカスタムプロセッサを使用してデプロイする場合にのみサポートされます。Auto Scaling は、スケーリングトリガーとして QPS (クエリ/秒) と CPU 使用率のみをサポートします。
前提条件
開始する前に、以下を確認してください。
ステップ1: サービスコードからのメトリックレポート
ご利用のサービスコードに、メトリックデータを組み込み API エンドポイントに POST する定期的な呼び出しを追加します。
POST http://localhost:8080/api/builtin/realtime_metricsリクエストボディは JSON 配列です。各要素は1つのメトリックサンプルを表します。
[
{
"name": "qps",
"tags": {
"status": "200"
},
"value": 20
},
{
"name": "qps",
"tags": {
"status": "400"
},
"value": 13
}
]| フィールド | 必須 | 説明 |
|---|---|---|
name | はい | メトリック名です。サービスの JSON 構成で宣言された name と一致する必要があります。 |
value | はい | このサンプルのメトリック値です。 |
tags | いいえ | メトリックにディメンションを追加するキーと値のペアです。タグを使用すると、1 つのメトリックを複数のシリーズに分割できます。たとえば、各 HTTP ステータスコードの QPS を個別に追跡できます。オートスケーリングルールでタグ付きメトリックを参照する場合は、custom[<name>]@<tag-key>[<tag-value>] のフォーマットを使用します。 |
メトリックをディメンションで分割する必要がない場合は、tags を省略します。
[
{
"name": "qps",
"value": 20
}
]ステップ2: サービス構成でのメトリック宣言
metrics フィールドをサービスの JSON 構成ファイルに追加します。EAS はこの宣言を読み取り、モニタリングダッシュボードを初期化します。
以下の例では、status タグを使用する qps メトリックを持つカスタムイメージを使用してサービスをデプロイします:
{
"name": "metrics_test",
"containers": [
{
"image": "registry-vpc.cn-chengdu.aliyuncs.com/eas/eas-image-****:metrics",
"command": "python3 -u /image.py",
"port": 5000
}
],
"metrics": [
{
"name": "qps",
"tags": "status"
}
],
"metadata": {
"instance": 1,
"cpu": 2,
"memory": 1000
}
}「image」の値を、ご自身のカスタムイメージ URL に置き換えます。「metrics」フィールドのパラメーター:
| パラメーター | 必須 | 説明 |
|---|---|---|
name | はい | メトリック名です。EAS はこの名前を使用してモニタリングダッシュボードを作成し、オートスケーリングルールでは custom[<name>] として参照されます。 |
tags | いいえ | メトリックを系列に分割するために使用するタグキー名です。たとえば、"tags": "status" を指定すると、status=200 と status=400 の値を個別にレポートし、オートスケーリングルールで custom[<name>]@status[<value>] として個別に参照できます。 |
その他のすべての構成パラメーターについては、「JSON デプロイメントパラメーター」をご参照ください。
構成の準備ができたら、サービスをデプロイします。
[サービスデプロイ] ページに移動します。詳細については、「PAI コンソールを使用したモデルのサービスデプロイ」をご参照ください。
「[構成エディター]」セクションで、「[JSON デプロイメント]」をクリックし、JSON 構成を貼り付けます。
クリック [デプロイ]。
ステップ3: カスタムメトリックデータの表示
デプロイメント後、ご利用のサービスはメトリックデータのレポートを開始します。データは1分以内に収集および表示され、自動的にクリアされるまで1週間保持されます。
メトリックを表示するには:
[EAS-Online モデルサービス] ページで、サービス名をクリックして、[サービスの詳細] ページを開きます。
「[サービス監視]」タブで、左上隅のドロップダウンリストからカスタムメトリックを選択します。
ダッシュボードには以下が表示されます。
サービス内のすべてのインスタンスの平均メトリック値
個々のインスタンスのメトリック値

ステップ4: Auto Scaling の設定
組み込みメトリックを使用するのと同じ方法で、Auto Scaling ルールでカスタムメトリックを使用します。ルール内のメトリック名形式は、タグを構成したかどうかによって異なります。
Auto Scaling を有効にするための完全な手順については、「水平 Auto Scaling」をご参照ください。
Auto Scaling メトリック名の構文
| 構成 | 形式 | 例 |
|---|---|---|
| タグなし | custom[<metric-name>] | custom[qps] |
| タグあり | custom[<metric-name>]@<tag-key>[<tag-value>] | custom[qps]@status[200] |
構文の内訳: custom[qps]@status[200]=3
custom[qps]—qpsという名前のカスタムメトリック@status[200]— タグキーstatusの値が200のデータポイントをフィルターします=3— スケーリングしきい値。平均値が3を超えると EAS はスケールアウトし、3を下回るとスケールインします
eascmd の使用
手順については、「水平 Auto Scaling 機能の有効化または無効化」の「方法2: クライアントを使用した水平 Auto Scaling 機能の管理」セクションをご参照ください。
タグなし — 平均 QPS がしきい値3を超えたときにスケールします。
eascmd autoscale service_name -Dmin=1 -Dmax=10 -Dstrategies.custom[qps]=3タグ付き — status=200 の場合の QPS に基づいてスケーリング:
eascmd autoscale service_name -Dmin=1 -Dmax=10 -Dstrategies.custom[qps]@status[200]=3コンソールの使用
手順については、「水平 Auto Scaling 機能の有効化または無効化」の「方法1: コンソールでの水平 Auto Scaling 機能の管理」セクションをご参照ください。
[Auto Scaling 設定] ダイアログボックスで、[カスタムスケーリングメトリクス] セクションに移動し、以下を入力します。
タグなし: メトリック名を
custom[qps]に、メトリック値を3に設定します。
タグありの場合: メトリック名を
custom[qps]@status[200]に、メトリック値を3に設定します。
次のステップ
水平 Auto Scaling — 組み込みメトリックまたはカスタムメトリックを使用してスケーリングポリシーを構成します。
カスタムイメージ — 独自のコンテナイメージを使用してサービスをビルドおよびデプロイ
カスタムプロセッサ — カスタム処理ロジックで EAS 推論を拡張します。