TL;DR
監視する側が特定のエンドポイント（/health など）をポーリングして、サーバが稼働しているかを確かめること。
なぜ必要か
ヘルスチェック用のエンドポイントは、デプロイのときに、アプリケーションまでネットワークが疎通しているかを確かめるのにも使える。開発の最初に実装しておくと、デプロイパイプラインが正しく動いているか、サーバの設定が正しいかを、早い段階から確かめられる。
仕組み
AWS の Network Load Balancer のドキュメントによると、ロードバランサはアクティブなヘルスチェックで、ターゲットがリクエストを処理できるかを判断する。ヘルスチェックの連続失敗回数がしきい値を超えると、そのターゲットを異常と見なしてサービスから外す。連続成功回数がしきい値を超えると、正常な状態に戻す。新しく登録したターゲットには、最初のヘルスチェックに合格してからリクエストを送り始める。
HTTP や HTTPS のヘルスチェックでは、チェックするパス、間隔、タイムアウト、正常と見なすステータスコードの範囲（デフォルトは 200〜399）を設定できる。
例
AWS では、ロードバランサ（ALB など）が、設定した間隔でエンドポイントにリクエストを送り続ける機能を持っている。
注意点
同じドキュメントによると、Network Load Balancer では、すべてのターゲットが同時にヘルスチェックに失敗すると、状態にかかわらずすべてのターゲットに通信を流す（フェイルオープン）。また、ヘルスチェックは複数のノードから分散して行われるので、ターゲットは設定した回数より多くのチェックを受ける。HTTP のヘルスチェックの負荷を抑えるには、静的な HTML ファイルのような単純な送信先を使うか、TCP のヘルスチェックに切り替える。