健康チェック
GitLabはサービスの健全性と必要なサービスへの到達可能性を示すために、Liveness ProbeとReadiness Probeを提供しています。これらのプローブは、データベース接続、Redis接続、ファイルシステムへのアクセスのステータスをレポーターします。これらのエンドポイントをKubernetesのようなスケジューラに提供することで、システムの準備が整うまでトラフィックを保持したり、必要に応じてコンテナを再起動したりすることができます。
IP許可リスト
監視リソースにアクセスするには、要求元のクライアント IP を allowlist に含める必要があります。詳細は、監視エンドポイントの許可リストにIPを追加する方法を参照してください。
ローカルでのエンドポイントの使用
デフォルトの allowlist 設定では、以下の URL を使用して localhost からプローブにアクセスできます：
GET http://localhost/-/health
GET http://localhost/-/readiness
GET http://localhost/-/liveness
健康
アプリケーション・サーバーが稼動しているかどうかを確認します。データベースやその他のサービスが稼働しているかどうかは確認しません。このエンドポイントはRails Controllersを回避し、リクエスト処理のライフサイクルのかなり早い段階で追加のミドルウェアBasicHealthCheck として実装されます。
GET /-/health
リクエストの例
curl "https://gitlab.example.com/-/health"
応答例
GitLab OK
準備
Readinessプローブは、GitLabインスタンスがRailsコントローラ経由でトラフィックを受け入れる準備ができているかどうかをチェックします。デフォルトではインスタンスチェックのみを行います。
all=1 パラメータを指定すると、依存するサービス (Database、Redis、Gitaly など) もチェックし、それぞれのステータスを表示します。
GET /-/readiness
GET /-/readiness?all=1
リクエストの例
curl "https://gitlab.example.com/-/readiness"
応答例
{
"master_check":[{
"status":"failed",
"message": "unexpected Master check result: false"
}],
...
}
失敗すると、エンドポイントは503 HTTP ステータス・コードを返します。
このチェックは Rack Attack の対象外です。
ライブネス
アプリケーションサーバが起動しているかどうかをチェックします。このプローブは、Railsコントローラがマルチスレッドによってデッドロックしていないかどうかを知るために使われます。
GET /-/liveness
リクエストの例
curl "https://gitlab.example.com/-/liveness"
応答例
成功すると、エンドポイントは200 HTTP ステータスコードと、以下のようなレスポンスを返します。
{
"status": "ok"
}
失敗すると、エンドポイントは503 HTTP ステータス・コードを返します。
このチェックは Rack Attack の対象外です。
Sidekiq
Sidekiqヘルスチェックの設定方法について説明します。