正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

ヘルスチェック

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab Self-Managed

GitLabは、サービスのヘルスチェックと、必要なサービスへの到達可能性を示すために、活性度と準備状況のプローブを提供します。これらのプローブは、データベース接続、Redis接続、およびファイルシステムへのアクセス状況をレポートします。これらのエンドポイントは、システムが準備できるまでトラフィックを保持したり、必要に応じてコンテナを再起動したりするために、Kubernetesなどのスケジューラに提供できます。

ヘルスチェックのエンドポイントは通常、ロードバランサーや、トラフィックのリダイレクト前にサービスの可用性を判断する必要がある他のKubernetesスケジューリングシステムで使用されます。

大規模なKubernetesデプロイで有効なアップタイムを判断するために、これらのエンドポイントを使用しないでください。そうすると、ポッドがオートスケール、ノードの失敗、またはその他の通常動作で中断を伴わない運用上のニーズによって削除された場合に、偽陰性を示す可能性があります。

大規模なKubernetesデプロイでアップタイムを判断するには、UIへのトラフィックを確認します。これは適切にバランスが取れてスケジュールされているため、有効なアップタイムのより良い指標となります。サインインページ/users/sign_inエンドポイントをモニタリングすることもできます。

GitLab.comでは、PingdomなどのツールとApdex測定を使用して、アップタイムを判断します。

IP許可リスト

モニタリングリソースにアクセスするには、リクエスト元のクライアントIPを許可リストに含める必要があります。詳細については、IPをモニタリングエンドポイントの許可リストに追加する方法を参照してください。

エンドポイントをローカルで使用する

デフォルトの許可リスト設定では、次のURLを使用して、localhostからプローブにアクセスできます:

GET http://localhost/-/health
GET http://localhost/health_check
GET http://localhost/-/readiness
GET http://localhost/-/liveness

ヘルス

アプリケーションサーバーが実行されているかどうかを確認します。データベースや他のサービスが実行されていることは検証しません。このエンドポイントは、Railsコントローラーを回避し、リクエストの処理ライフサイクルの非常に早い段階で追加のミドルウェアBasicHealthCheckとして実装されます。

GET /-/health

リクエスト例:

curl "https://gitlab.example.com/-/health"

レスポンス例:

GitLab OK

包括的なヘルスチェック

**/health_checkロードバランシングまたはオートスケールにはコードを使用しないでください。**このエンドポイントは、バックエンドサービス（データベース、Redis）を検証し、これらのサービスの速度が遅いか利用できない場合、アプリケーションが適切に機能している場合でも失敗します。これにより、正常なアプリケーションノードがロードバランサーから不必要に削除される可能性があります。

/health_checkエンドポイントは、データベース接続、Redisの可用性、およびその他のバックエンドサービスを含む包括的なヘルスチェックを実行します。これはhealth_check gemによって提供され、アプリケーションスタック全体を検証します。

このエンドポイントは以下に使用します:

  • 包括的なアプリケーションモニタリング
  • バックエンドサービスのヘルスチェック検証
  • 接続性のイシューのトラブルシューティング
  • モニタリングダッシュボードとアラート
GET /health_check
GET /health_check/database
GET /health_check/cache
GET /health_check/migrations

リクエスト例:

curl "https://gitlab.example.com/health_check"

レポートのコード例（成功）:

success

レポートのコード例（失敗）:

health_check failed: Unable to connect to database

使用可能なチェック:

  • database - データベース接続
  • migrations - データベース移行ステータス
  • cache - Redisキャッシュ接続
  • geo（EEのみ）- Geoレプリケーションステータス

準備完了

準備状況プローブは、GitLabインスタンスがRailsコントローラー経由でトラフィックを受け入れる準備ができているかどうかを確認します。チェックではデフォルトでインスタンスチェックのみが検証されます。

all=1パラメータが指定されている場合、チェックは依存サービス（データベース、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から除外されます。

活性度

GitLab 12.4では、活性度チェックのレポート本文が以下の例と一致するように変更されました。

アプリケーションサーバーが実行されているかどうかを確認します。このプローブは、マルチスレッドが原因でRailsコントローラーがデッドロックしていないかどうかを確認するために使用されます。

GET /-/liveness

リクエスト例:

curl "https://gitlab.example.com/-/liveness"

レスポンス例:

成功すると、エンドポイントは200 HTTPステータスを返し、以下のようなレポートを返します。

{
   "status": "ok"
}

失敗すると、エンドポイントは503 HTTPステータスを返します。

このチェックは、Rack Attackから除外されます。

Sidekiq

Sidekiqヘルスチェックの構成方法について説明します。