Simple Log Service:MetricStore HTTP API の戻り値

リトライポリシー

リトライポリシーは、エラー発生時のクライアントのリトライ動作をガイドします。これにより、ユーザーエクスペリエンスを低下させる可能性のある効果のないリトライを防ぎます。

状態コードと推奨される操作

成功したリクエスト

{
    "status": "success",
    "data": {
        "resultType": "matrix",
        "result": [
            {
                "metric": {},
                "values": [
                    [
                        1673798460,
                        "11111111"
                    ],
                    [
                        1673799060,
                        "22222222"
                    ],
                    [
                        1673799660,
                        "33333333"
                    ]
                ]
            }
        ]
    }
}

返された部分データ

クエリが不完全な場合、部分的なデータが返されます。この場合、slsStatus フィールドには詳細なエラーメッセージとリトライポリシーが含まれます。

{
	"status": "success",
	"slsStatus": {
		"retryPolicy": "Once",
		"errorCode": "ShardResourceExceed",
		"errorMessages": ["sls response error 1 task data", "sls response drop 1 task data"]
	},
	"data": {
		"resultType": "vector",
		"result": [{
			"metric": {
				"__name__": "up",
			},
			value: [
				1747807789.37,
				"1"
			]
		}]
	},
	"warnings": ["sls response error 1 task data", "sls response drop 1 task data"]
}

返されたエラー

例 1

{
	"status": "error",
	"slsStatus": {
		"errRetryPolicy": "None",
		"errCode": "EngineResourceExceed",
		"errMessages": ["too many time Series or items"]
	},
	"data": {
	},
	"error": "too many time Series or items"
}

例 2

{
	"status": "error",
	"slsStatus": {
		"retryPolicy": "None",
		"errorCode": "BadDataError",
		"errorMessages": ["vector cannot contain metrics with the same labelset"]
	},
        "data": {
	},
	"error": "vector cannot contain metrics with the same labelset"
}

フロントエンド表示

MetricStore は、組み込みのメトリック可視化機能を備え、ダッシュボードの構築をサポートし、Grafana と互換性があります。クエリが異常な場合、組み込みの可視化ソリューションは関連情報をチャートに自動的に表示します。

• より良い警告メッセージを表示するには、Grafana 10.0 以降を使用してください。

MetricStore Prometheus API に基づいてカスタム可視化ソリューションを構築する場合、次のポリシーに基づいて例外を処理します。

1. HTTP ステータスコードが 200 の場合、チャートは正常にレンダリングされます。

   1. slsStatus フィールドが存在する場合、チャートに警告メッセージを表示し、RetryPolicy に基づいてソリューションを提供します。

2. HTTP ステータスコードが 200 でない場合、エラーメッセージをチャートに直接表示し、RetryPolicy に基づいてソリューションを提供します。

二次データ計算シナリオ

MetricStore は、Scheduled SQL を使用して集計データを定期的に計算することをサポートしています。MetricStore の Prometheus API に基づいてカスタムの二次計算シナリオを構築する場合、次のポリシーに従って異常を処理することをお勧めします。

1. 状態コードが 200 の場合:

   1. slsStatus フィールドが存在しない場合は、データを保存し、次のスケジュールされたジョブに進みます。

   2. slsStatus フィールドが存在する場合は、次のように RetryPolicy に基づいて例外を処理します。

      1. None: 一度リトライします。ポリシーがまだ None の場合は、タスクを失敗としてマークし、次のスケジュールされたジョブに進みます。

      2. Once: 一度リトライします。ポリシーがまだ Once の場合は、タスクを失敗としてマークし、次のスケジュールされたジョブに進みます。

      3. Continuous: アニーリング戦略を使用してリトライします。リトライが一定期間 (10 〜 30 分を推奨) 続く場合は、タスクを失敗としてマークし、次のスケジュールされたジョブに進みます。

2. 状態コードが 200 でない場合:

   1. slsStatus フィールドが存在しない場合、エラーは通常ネットワークの問題が原因です。継続的なリトライが推奨されます。

   2. slsStatus フィールドが存在する場合は、次のように RetryPolicy に基づいて例外を処理します。

      1. None: 一度リトライします。ポリシーがまだ None の場合は、タスクを失敗としてマークし、次のスケジュールされたジョブに進みます。

      2. Once: 一度リトライします。ポリシーがまだ Once の場合は、タスクを失敗としてマークし、次のスケジュールされたジョブに進みます。

      3. Continuous: アニーリング戦略を使用してリトライします。リトライが一定期間 (10 〜 30 分を推奨) 続く場合は、タスクを失敗としてマークし、次のスケジュールされたジョブに進みます。

• 失敗したタスクのデータを別の LogStore に書き込み、必要に応じてアラートを設定することをお勧めします。詳細については、「スケジュールされた SQL タスクのアラートを設定する」をご参照ください。

リアルタイムアラートシナリオ

SLS を使用すると、MetricStore で直接アラートを作成できます。ただし、MetricStore の Prometheus API に基づいてカスタムのリアルタイムアラートシステムを構築する場合、次のポリシーを使用して異常を処理できます。

1. 状態コードが 200 の場合:

   1. slsStatus フィールドが存在しない場合は、アラート条件を正常にモニターします。

   2. slsStatus フィールドが存在する場合は、次のように RetryPolicy に基づいて例外を処理します。

      1. None: 現在のアラート実行を失敗としてマークし、次のスケジュールされた実行に進みます。

      2. Once: 一度リトライします。ポリシーがまだ Once の場合は、現在のアラート実行を失敗としてマークし、次のスケジュールされた実行に進みます。

      3. Continuous: アニーリング戦略を使用してリトライします。リトライが一定期間 (1 分以内を推奨) 続く場合は、現在のアラート実行を失敗としてマークし、次のスケジュールされた実行に進みます。

2. 状態コードが 200 でない場合:

   1. slsStatus フィールドが存在しない場合、エラーは通常ネットワークの問題が原因です。継続的なリトライが推奨されます。

   2. slsStatus フィールドが存在する場合は、次のように RetryPolicy に基づいて例外を処理します。

      1. None: 現在のアラート実行を失敗としてマークし、次のスケジュールされた実行に進みます。

      2. Once: 一度リトライします。ポリシーがまだ Once の場合は、現在のアラート実行を失敗としてマークし、次のスケジュールされた実行に進みます。

      3. Continuous: アニーリング戦略を使用してリトライします。リトライが一定期間 (1 分以内を推奨) 続く場合は、現在のアラート実行を失敗としてマークし、次のスケジュールされた実行に進みます。

• 推奨事項:

  • 合計リトライ時間は、スケジュールされたアラートの間隔を超えないようにしてください。たとえば、アラート間隔が 1 分で、合計リトライ時間が 1 分を超える場合は、現在の実行をスキップして次の実行に進みます。そうしないと、新しくより重要なデータのアラートを見逃す可能性があります。

  • 失敗したアラート実行のデータを別の LogStore に書き込み、必要に応じてアラートを設定することをお勧めします。詳細については、「アラートログのカスタム分析」をご参照ください。