本文へ移動
Telemetry
API の信頼性 SQL レシピ

API 429 レート制限回復の測定

すべての再試行を新しいリクエストとして扱うことなく、レート制限されたリクエストが後の試行で回復する頻度を測定します。

中級者api_attempt_eventsレビュー済み 2026-07-28テスト済み アパッチ DataFusion 45.2.0

レビュー者 Telemetry 製品チーム . SQL の互換性、イベント コントラクト、合成出力、および操作上の注意事項. 基準と所有権を確認する

質問に回答しました

HTTP 429 を受信したリクエストは、再試行後に正常に回復しますか?

試行レベルのテレメトリにより、再試行の嵐が要求のように見える可能性があります。このパターンでは、最初に試行を 1 つのリクエスト結果にまとめてから、最終的に回復したレート制限リクエストの数を測定します。

イベント契約

クエリが期待するフィールド

フィールド種類なぜ存在するのか
timestamp_utcTimestamp試行完了時刻 (UTC)。
route_templateUtf8安定したルート テンプレート。
request_idUtf8最初の試行と再試行で共有される識別子。
attempt_numberInt641 ベースの試行シーケンス。
status_codeInt64試行に対して HTTP ステータスが返されました。
retry_after_msInt64適用される再試行遅延 (ミリ秒単位)。
environmentUtf8導入環境。
DataFusion SQL

クエリをコピーする

sql
WITH request_outcomes AS (
  SELECT
    route_template,
    request_id,
    COUNT(*) AS attempts,
    MAX(CASE WHEN status_code = 429 THEN 1 ELSE 0 END) AS was_rate_limited,
    MAX(CASE WHEN status_code BETWEEN 200 AND 299 THEN 1 ELSE 0 END) AS succeeded
  FROM api_attempt_events
  WHERE timestamp_utc >= now() - INTERVAL '24 hours'
    AND environment = 'production'
  GROUP BY route_template, request_id
)
SELECT
  route_template,
  COUNT(*) AS requests,
  SUM(was_rate_limited) AS rate_limited_requests,
  SUM(CASE
    WHEN was_rate_limited = 1 AND succeeded = 1 THEN 1
    ELSE 0
  END) AS recovered_requests,
  100.0 * SUM(CASE
    WHEN was_rate_limited = 1 AND succeeded = 1 THEN 1
    ELSE 0
  END) / NULLIF(SUM(was_rate_limited), 0) AS recovery_rate_pct
FROM request_outcomes
GROUP BY route_template
ORDER BY rate_limited_requests DESC, route_template;

この読み取り専用クエリは、空の型付きテーブルに対して計画され、実行されます。 アパッチ DataFusion 45.2.0。決定論的なサンプル出力は合成され、個別にレビューされます。フィールド タイプ、しきい値、ビジネス定義を独自のデータと照合して検証します。 テスト方法を読んでください。

クエリ結果

レート制限されたリクエストの回復

検索では、レート制限された 3 つのリクエストのうち 2 つが回復されます。エクスポートは、観察されたウィンドウ内では回復しません。

route_templaterequestsrate_limited_requestsrecovered_requestsrecovery_rate_pct
/api/search43266.67
/api/export2100

合成出力例。運用上の決定に使用する前に、独自のイベント スキーマとしきい値に対してクエリを実行します。

Rate-limited request recovery: Measure API 429 Rate-Limit Recovery 結果例からの合成 recovery_rate_pct 値の静的チャート
決定論的な出力例のインデックス可能な SVG。記事、ランブック、または出典を明示した設計レビューのためにダウンロードしてください。

例を再現する

パブリックフィクスチャをダウンロードする

JSON バンドルには、型付きイベント コントラクトが含まれています。 reproducible 入力行、正確な SQL、予想される出力、レビューメモ、およびエンジンのバージョン。 CSV には、表示された結果が含まれます。

SQL の仕組み

  1. 1最初の CTE は論理リクエストごとに 1 つのレコードを作成し、再試行によるリクエスト量の増大を防ぎます。
  2. 2リクエストは、429 試行と成功した試行の両方が含まれている場合にのみ、回復されたものとしてカウントされます。
  3. 3レート制限されたリクエスト数をパーセンテージの横に維持すると、少量の結果が表示されます。

決定すべきエッジケース

  • 再試行後も存続する冪等性または論理リクエスト識別子を使用してください。
  • レポートウィンドウの後に完了したリクエストに永続的に「失敗」というラベルが付けられないように、再試行シーケンスを制限しました。
  • クライアントのキャンセルを再試行の枯渇とは別に記録します。

推奨されるダッシュボード

  • バー: ルート別 recovery_rate_pct
  • トレンド: rate_limited_requests および recovered_requests
  • 表: 試行回数と再試行遅延を含む枯渇したリクエスト

アラートガイダンス

レート制限された量が重要であり、回復がいくつかのバケットについてルートのレビューされた目標を下回っている場合にアラートを送信します。

アラート設定を読む

レシピを活用する

関連する機器とガイド

分析を続ける

実際のイベントで実行する

テーブルを作成し、フィールドを調整して、結果を保存します

無料で始めて、構造化されたイベントを送信し、クエリ結果をグラフ、共有ダッシュボード ウィジェット、またはアラート入力として使用します。

API キーを取得する