REST API の稼働時間と応答時間を監視する方法

REST API を監視することは、Web サイトを監視することと同じではありません。API から HTTP 200 が返ってきた場合でも、応答が正しいこと、応答時間が許容範囲内であること、認証がまだ機能していることが保証されるわけではありません。このガイドでは、API 監視が実際に確認すべき事項、早期に問題を検出しながらノイズを避けるしきい値、および単純な ping チェックが見逃すサイレント障害モードについて説明しています。

API 監視が確認すべき 4 つのこと

有用な API 監視は、プローブごとに 4 つのことをチェックします。それぞれが他では見逃す異なるクラスの障害をキャッチします。

ステータスコード: API は 200 を返しましたか、それとも 500、502、503 を返しましたか？応答時間: API は許容範囲内に応答しましたか？ボディコンテンツ: 応答には予期されるフィールドが含まれていますか？認証状態: API は昨日受け入れていた認証情報をまだ受け入れていますか？4 つすべてをチェックする監視は、単一のチェックでは見逃すであろう誤動作をキャッチします。

監視する価値のあるエンドポイント

すべての API エンドポイントに監視が必要なわけではありません。3 つのカテゴリでほとんどの実際の価値をカバーします。

• ヘルスエンドポイント: 通常は /health または /status です。データベース接続と重要な依存関係を確認する小さな JSON ペイロードで 200 を返す必要があります。プローブが軽量で、問題がある場合に迅速に失敗します。
• 最も使用されている実エンドポイント: トラフィックの最大シェアを占めるエンドポイントです。/users/me エンドポイントがリクエストの 80% を処理している場合は、直接監視してください。動作を停止した場合、顧客はすぐに気づきます。
• 最も収益性の高い実エンドポイント: 支払い、サブスクリプション、またはお金に直接変換されるすべてを処理するエンドポイントです。同じ監視、より高い警告優先度。

誤った警告なしに応答時間のしきい値を設定する

応答時間アラートは、ノイズの多い監視を作成する最も簡単な方法です。デプロイ中の単一の遅いプローブはシグナルではありません。連続して 10 個の遅いプローブがあればそうです。機能するしきい値戦略は、絶対値ベースではなくパーセンタイルベースです。

通常の 1 週間にわたってエンドポイントの p95 応答時間を測定します。アラートしきい値を p95 の 2 倍に設定します。連続する 3 つのプローブがそれを超える場合にのみアラートします。結果は、通常の変動を無視しながら実際の低下をキャッチする監視です。最初の月にかけて乗数としきい値カウントを調整してから、そのままにしておきます。

単純な ping チェックが見逃すサイレント障害モード

API は HTTP 200 を返すことができ、それでも壊れている可能性があります。4 つの一般的なサイレント障害が実際のインシデントに表れます。

• Cached error responses: APIが500を一度だけ返して、CDNでキャッシュされ、その後は陳旧したエラーボディを含む200で提供され続ける場合。
• Wrong content type: デバッグミドルウェアが有効なままのため、APIがJSONではなくHTMLを返すケース。ステータスは200ですが、ボディは解析不可能です。
• Empty success: マイグレーション中に基盤となるクエリがジョインを失ったため、APIが空の結果セットで200を返すケース。
• Authentication drift: レート制限が未認証リクエストを適切に処理するため、APIは200を返しますが、ボディには「ログインしてください」というメッセージが含まれているケース。

認証情報を漏洩させずに行う認証付きモニタリング

多くのAPIはすべてのエンドポイントで認証を必要とします。モニターには認証情報が必要です。2つのパターンは良く機能していますが、1つの一般的なパターンは重大なセキュリティリスクです。

良い方法：最小限のスコープを持つ専用の読み取り専用APIキーを使用し、四半期ごとにローテーションし、モニタリングツール内で暗号化して保存する。さらに良い方法：ベアラートークンではなく、ウェブフックシグネチャまたはHMACを使用する。そうすれば、モニターはユーザーになりすますことができません。悪い方法：本番環境の管理者ユーザーのための長寿命のベアラートークンをモニター設定に貼り付ける。3番目のパターンは、モニターの認証情報が漏洩したときに独自のインシデントを引き起こします。

APIの初期設定

APIごとに3つのモニターを追加してください。60秒の頻度でレスポンスタイム閾値500msの/healthモニター。最も使用されている実エンドポイント上で60秒の頻度でボディコンテンツをアサーションするモニター。最も売上に関連するエンドポイント上で30秒の頻度で同じボディアサーションとより厳しいレスポンスタイム閾値を持つモニター。モニター総数：3個。カバレッジ：重要な部分のほとんど。実インシデントで出現する場合のみエッジケース向けの具体的なモニターを追加してください。先制的には追加しないでください。