ヘルスチェックの失敗にはどのHTTPステータスコードを使用すればよいですか？
データベース内のデータに対してサニティチェックを行う/_status/エンドポイントを実装しています。
たとえば、測定値を収集しており、最新の測定値が1時間以上経過している場合、ステータスは「不良」になるはずです。
PingdomにこのURLを指定して、アラートインフラストラクチャを活用し、問題が発生したときに通知したいと思います。
「良好」ステータスでは、HTTP 200 OKステータスのHTMLページを提供します。しかし、「悪い」の場合、適切なHTTPステータスコードは何でしょうか。または、ステータスコードではなくHTMLコンテンツを介してこの情報を伝える方が正しいでしょうか？
ありがとう！
ええと...これは古い質問ですが、私はここに行き着いたので、ここに2セントを与えると思いました：すべてがOKの場合は2xxを返す必要があることはかなり明らかなようです
正常性に問題がある場合は、5xxの結果が返されるはずです（4xxは、要求でクライアントに障害があることについて話します。2xxと3xxはすべてある程度成功しています）。
これはサービス全体の状態について答える特別なリクエストなので、5xxは正しいと思います。また、ほとんどのロードバランサーは応答コードに基づいて活性チェックを提供し、すべてがより複雑なペイロードを解析する方法を提供するわけではないため（おそらくチェックを脆弱にする可能性があるRegExp一致以外）。
私は@Julienに同意し、500（具体的には）は適切ではないと思われるため、503 Service Unavailableに決定しました。
503は、いくつかの理由で適合しているようです。
- これは、サーバー側で何かが起こっていることを示す5xxファミリの結果コードです。
- 一時的な性質があり、回復する可能性があることを示しています。
サービスに障害が発生したためにデータが「不良」である場合（バックエンドジョブが失敗した場合でも）、HTTP500は有効な応答のように見えます。それは何か、どこかが壊れていることを示しています。
それはあまり具体的ではありません、あなたは肩をすくめて言っています：
500（内部サーバーエラー）ステータスコードは、サーバーが予期しない状態に遭遇したために要求を実行できなかったことを示します。
正常性を要求し、サーバーの状態が正常でない場合、「リソースの現在の状態の競合のために要求を処理できなかったことを示す」409Conflictに部分的です。
返答できればリクエストを処理できると反対する人もいるかもしれませんが、私は同意しません。すべてのエラーメッセージは応答です。サーバーはリソースセマンティクスを定義します。良いニュースリソースを要求し、サーバーが「ここに悪いニュースがあります」と応答した場合、そのリソースで提供されたと定義されているものは提供されませんでした。
実際には、2 ** = "up" 4 ** = "down"と言う方がはるかに簡単であり、パイプリクエストは可用性メトリックにカウントされ、ロードバランサーが応答コードに基づいてサーバーをプールから削除します。 「ねえ、私たちはあなたに何かを言ったので、200 OK」と主張する方法を考え出すことは、私には木の森を逃しているように思えます。