webappをデプロイするシステムのヘルスチェックの範囲はどのくらいですか？

今日、Webアプリを展開するオーケストレーションシステムである長期実行サービスの「ヘルスチェックを記述する」タスクがありました。

私はそのようなヘルスチェックの範囲が何であるかを決定しようとしていますが、ヘルスチェックの範囲に関連するこれらの質問を思いつきました：

1. オーケストレーションシステムがタスクの実行を報告している場合、サービスが正常であると考えるのに十分ですか？
2. または、各サービスを手動でpingする必要がありますか？
3. または、さらに進んで、Webページを表示するなど、Webアプリケーションが本来行うべきことを確実に実行しようとする必要がありますか？
4. ヘルスチェックでは、いくつかの依存サービスも実行されていることも確認する必要がありますか？データベースまたはオーケストレーションシステム自体のように。または、それは別のヘルスチェックの責任ですか？
5. そして最後に、依存サービスの1つが停止し、その後Webアプリが失敗した場合、WebアプリはWebアプリの障害ではないため、健康状態が悪い、または健康状態を報告する必要がありますか？

これらは5つの個別の質問であることがわかっていますが、これらはすべて、Webアプリを展開する長期実行サービスのヘルスチェックの範囲に関連しているため、1つの質問にグループ化しておく方が理にかなっていると思いました。

健康なものの定義や、このようなものの標準的な健康チェックがどのように見えるべきかがわからないため、これを実装するのは困難です。

この特定のサービスのヘルスチェックには何を含める必要がありますか？

健全なものの定義のため、これは実装が困難です

ここで自分の質問に答えました。健康状態はさまざまであるため、ヘルスチェックの定義もさまざまです。また、ヘルスチェックの発行内容にも依存します。

自問すべき良い質問は、「質問者の観点から、チェックされたサービスは期待どおりに機能していますか？」です。これがあなたなら、あなたはそれを定義することができます。それが別のチーム/サービスである場合、ヘルスチェックの標準/仕様を特定する必要があります。

大規模な組織では、ヘルスチェックで何をすべきかについて何らかの基準があります。それを把握します。

具体的には、webappの例は、webappが正常ではないため、正常に戻らないことを意味します。しかし、「健康」の定義には、これを「OK」として含めることができます。これは、上記の要件の説明の一部です（これは、独自のコードであっても）。

他の場所で指定されていないことを前提とする私の推奨事項は、さまざまな障害に関連付けられた何らかのステータスコードを持つことです。webappをクエリすると、「依存サービスが停止している」というエラーが返される場合があるため、クライアント（またはヘルスチェックを実行しているもの）が理由を知ることができますます。

編集した質問の場合：

オーケストレーションシステムがタスクの実行を報告している場合、サービスが正常であると考えるのに十分ですか？

いいえ、プロセスが実行されているからといって、ハングしていない、まったく機能していない、またはその他のさまざまな可能性があるわけではありません。

または、各サービスを手動でpingする必要がありますか？

これは、アプリケーションの機能の範囲によっては機能する場合があります。サービスが「生きていますか？」に応答することを確認する場合 pingを実行すると、これで十分な場合があります。ただし、サービスが簡単に「アライブで応答するが、実際には機能しない」場合は、おそらく他のことも確認する必要があります。

または、さらに進んで、Webページを表示するなど、Webアプリケーションが本来行うべきことを確実に実行しようとする必要がありますか？

ヘルスチェックでは、期待される必要な機能が期待どおりに機能することを確認する必要があります。

アプリが「正常」を返し、必要な処理を実行できない場合、ヘルスチェック全体を削除することもできます。これは、誤検知を引き起こすためです（言うまでもなく、問題をデバッグしようとする人々の混乱を混乱させます。ウェブサーバーが正常に表示されているのに、なぜページが表示されないのですか？）。

ヘルスチェックでは、いくつかの依存サービスも実行されていることも確認する必要がありますか？データベースまたはオーケストレーションシステム自体のように。または、それは別のヘルスチェックの責任ですか？

これは多少異なります。サービスが別のサービスに依存している場合、その対話の性質は、アプリで送信され、ヘルスチェックに組み込まれるAPI /ネットワークコールに反映される必要があります。

たとえば、データベースから読み取るWebサーバーには、データベースに関するステータス情報が組み込まれている必要があります。そうでない場合、API呼び出しが失敗すると、Webアプリは単純にクラッシュします。これらの呼び出しを簡単に変更して、ヘルスチェックに組み込むことができます。

ただし、サービスが検証なしでリッスンするコンシューマーにイベントを送信している場合、コンシューマーが生きていることはアプリの機能にとってそれほど重要ではありません。アプリの「正常」は、実際にメッセージを受信するのではなく、メッセージを送信することです。

基本的に、サービスが他のサービスと通信して、とにかくそれらのヘルスを確認する必要がある場合、サービスのヘルスチェックのために少なくともこれに基本レベルのチェックを入れることが理にかなっています。これは、アプリケーションがすでにこれを処理している（またはランダムにクラッシュしているように思える）ので、私がちょうど言ったことを考えると、概念的に意味があります。

そして最後に、依存サービスの1つが停止し、その後Webアプリが失敗した場合、WebアプリはWebアプリの障害ではないため、健康状態が悪い、または健康状態を報告する必要がありますか？

これは基本的に上記の回答です。私の推奨事項は、この情報を提供するコード/メッセージ/その他をヘルスチェックに返すことです。両方の情報が重要である：あなたのサービスを必要とする依存サービスが死んでいると、結果として期待どおりにサービスが動作しないこと。

一般的に、ヘルスチェックは「生きているか、応答しているか」を意味します。それ以上のチェックは高度に専門化されており、システムの使用に完全に依存しています。システムがリクエストを正しく処理していることを確認するために余分な距離を移動するかどうかはあなた次第ですが、最初に基本を実行する必要があります-そこにあることを確認し、リクエストを受信できることを確認し、応答を返します。

ヘルスチェックを実装する最も簡単な方法は、サービスが他のコマンドが使用するのと同じメカニズムを使用して処理するコマンドを記述することです。それは活気を示し、システムが応答を受信して​​処理していることを示します。

依存システムのチェックはヘルスチェックの一部ではありません。シンプルで自己完結型である必要があります。各依存サービスに順番にヘルスチェックを追加します。そうすれば、稼働中の健全なシステムのリストを取得し、どれが悪いのか、どれが悪いのかを簡単に知ることができます！

私の経験では、重要なサービスには次の機能がある傾向があります。

ハートビート

サービスが定期的に実行されている場合、これは、ログファイルなどにタイムスタンプとともに行を書き込むだけで、特定の時間にサービスボディが起動されたことを示します。

パン粉

上記と同様に、パンくずは通常、サービスが期待どおりにサービス本体を処理していることと、フロー内の行方を示すメソッド名（および場合によってはパラメーター）の単なるダンプです。これらはより多くの出力を生成できるため、これらは一般に設定ファイルなどによって制御されるため、サービスが組み込まれた後にオフにできます。

さまざまなサーバー、サービス、データベースなどの状態など、他の多くのものを追加するのは魅力的です。これは間違いなく価値がありますが、あまりにも大規模なものを書くことはお勧めしません。これらはあなた自身の心の安らぎに役立つかもしれませんが、そのようなセーフガードは、様々なタッチポイントを担当する当事者が彼らがそこにいることを知ると虐待される傾向があります。あなたがそれを知る前に、あなたは会社全体のための診断アプリを書いているかもしれません。