Webアプリをデプロイするシステムのヘルスチェックのスコープは何ですか？
今日、私は、Webアプリをデプロイするためのオーケストレーションシステムである、長時間実行されるサービスの「ヘルスチェックを作成する」というタスクを持っていました。
私はそのようなヘルスチェックのスコープが何であるかを決定しようとしています、そしてヘルスチェックのスコープに関連するこれらの質問を思いつきました：
- オーケストレーションシステムがタスクが実行中であると報告した場合、サービスが正常であると見なすのに十分ですか？
- または、手動で各サービスにpingする必要がありますか？
- それとも、さらに進んで、WebアプリがWebページを表示するなど、想定されていることを実行することを確認する必要がありますか？
- ヘルスチェックは、いくつかの依存サービスも実行されていることを確認する必要がありますか？データベースやオーケストレーションシステム自体のようなものです。それとも別の健康診断の責任ですか？
- そして最後に、依存するサービスの1つが停止し、その後Webアプリが失敗した場合、Webアプリは正常でないことを報告しますか、それともWebアプリの障害ではないので正常ですか？
これらは5つの個別の質問であることはわかっていますが、すべてWebアプリケーションをデプロイする長期実行サービスのヘルスチェックのスコープに関連しているため、1つの質問にまとめておく方が理にかなっていると思いました。
これが私にとって実装が難しいのは、何が正常であるか、またはこのようなものの標準的なヘルスチェックがどのように見えるかについての定義がわからないためです。
この特定のサービスのヘルスチェックには何を含める必要がありますか？
何が健康であるかの定義のため、これは実装が困難です
ここであなた自身の質問に答えました。健康診断の定義はさまざまです。何が健康かはさまざまだからです。それは、ヘルスチェックを発行しているものにも依存します。
「質問者の観点から見ると、checkedサービスは期待どおりに機能していますか？」これがあなたなら、それを定義することができます。別のチーム/サービスの場合は、ヘルスチェックの標準/仕様を特定する必要があります。
おそらく大規模な組織では、ヘルスチェックが何をすべきかについて、ある種の標準があります。それを理解してください。
具体的には、ここでは、webappの例は、webappが正常ではないため、正常に戻らないことを意味します。しかし、おそらく「健康」の定義には、「大丈夫」としてこれが含まれるでしょう。これは、上記の要件の説明の一部です（これも、自分のコードだけの場合でも）。
他の場所で指定されていないことを前提とした私の推奨事項は、さまざまな障害に関連付けられたある種のステータスコードを持つことです。 Webアプリケーションにクエリを実行すると、「依存サービスが停止している」というエラーが返される場合があるため、クライアント（またはヘルスチェックを実行しているもの）は理由クライアントが停止していることを認識できます。
編集された質問の場合：
オーケストレーションシステムがタスクが実行中であると報告した場合、サービスが正常であると見なすのに十分ですか？
いいえ、プロセスが実行されているからといって、ハングしていない、完全に機能していない、その他のさまざまな可能性があるわけではありません。
または、手動で各サービスにpingする必要がありますか？
これは、アプリケーションの機能の範囲によっては機能する場合があります。サービスを確認すると、「あなたは生きていますか？」 pingすると、これで十分な場合があります。しかし、サービスが簡単に「生きていて応答性は高いが実際には機能しない」可能性がある場合は、おそらく他のことも確認する必要があります。
それとも、さらに進んで、WebアプリがWebページを表示するなど、想定されていることを実行することを確認する必要がありますか？
ヘルスチェックでは、期待される必要な機能が期待どおりに機能することを確認する必要があります。
アプリが「正常」を返し、必要な処理を実行できない場合は、誤検知が発生するため、ヘルスチェック全体を排除することもできます（言うまでもありませんheck問題をデバッグする-「ちょっと私たちのウェブサーバーは健康を示しています、なぜ私たちはページを見ることができないのですか？」）.
ヘルスチェックでは、いくつかの依存サービスも実行されていることを確認する必要がありますか？データベースやオーケストレーションシステム自体のようなものです。それとも別の健康診断の責任ですか？
これは多少異なります。サービスが別のサービスに依存している場合、その相互作用の性質は、アプリで送信されたAPI /ネットワーク呼び出しに反映され、ヘルスチェックに組み込まれる必要があります。
たとえば、データベースから読み取るウェブサーバーには、データベースに関するステータス情報が組み込まれている必要があります。そうしないと、API呼び出しが失敗すると、ウェブアプリがクラッシュします。これらの呼び出しを簡単に変更して、ヘルスチェックに組み込むことができます。
ただし、サービスが検証を行わずにリッスンするコンシューマーにイベントを送信している場合、コンシューマーが生きていることはアプリのfunctionalityにとってそれほど重要ではありません。アプリの「正常」とは、メッセージを実際に受信するのではなく送信することです。
基本的に、サービスが他のサービスと通信して正常性を確認する必要がある場合は、サービスのヘルスチェック用に少なくとも基本レベルのチェックを行うことが理にかなっています。これは、アプリケーションがすでにこれを処理している（またはランダムにクラッシュする）ため、私が言ったことを考えると、概念的には理にかなっているはずです。
そして最後に、依存するサービスの1つが停止し、その後Webアプリが失敗した場合、Webアプリは正常でないことを報告しますか、それともWebアプリの障害ではないので正常ですか？
これは基本的に上記で回答されています。私の推奨事項は、ヘルスチェックにこの情報を提供するコード/メッセージ/何でも返すようにすることです。両方の情報が重要です。サービスに必要な依存サービスが停止していることand結果として、サービスが期待どおりに機能しないことを示します。
一般的に、ヘルスチェックは「生きているか、応答しているか」を意味します。それ以上のチェックは高度に専門化されており、システムの使用に完全に依存しています。システムがリクエストを正しく処理していることを確認するためにさらに努力するかどうかはあなた次第ですが、最初に基本を実行する必要があります-そこにあることを確認してください。
ヘルスチェックを実装する最も簡単な方法は、サービスが他のコマンドが使用するのと同じメカニズムを使用して処理するコマンドを記述するだけで、確認応答を返すだけです。これにより、活気があり、システムが応答を受信して処理していることがわかります。
依存システムのチェックはヘルスチェックの一部ではありません。シンプルで自己完結型に保つ必要があります。依存関係のある各サービスに順番にヘルスチェックを追加します。こうすることで、実行中の正常なシステムのリストを取得し、どれが故障したかを簡単に知ることができます。
私の経験では、重要なサービスには次の機能がある傾向があります。
ハートビート
サービスが定期的に実行されている場合は、タイムラインとともにログファイルなどに1行を書き込むだけで、サービス本体が特定の時間に開始されたことを示します。
ブレッドクラム
上記と同様に、ブレッドクラムは通常、メソッド名（および場合によってはパラメーター）の単なるダンプであり、サービスがサービス本体を期待どおりに処理していることと、フロー内の所在を示しています。これらはより多くの出力を生成できるため、これらは一般に設定ファイルなどで制御されるため、サービスが組み込まれるとオフにすることができます。
さまざまなサーバー、サービス、データベースの状態など、他の多くの要素を追加するのは魅力的です。これは間違いなく価値がありますが、あまりにも多くのことを書くことはお勧めしません。これらはあなた自身の心の安らぎのために役立つかもしれませんが、様々なタッチポイントを担当する当事者が彼らがそこにいることを知ったら、そのようなセーフガードは乱用される傾向があります。あなたがそれを知る前に、あなたは会社全体のための診断アプリを書いているかもしれません。