ln-774-healthcheck-setup

ln-774-healthcheck-setup

タイプ： L3 Worker カテゴリ： 7XX Project Bootstrap

Kubernetes のプローブとモニタリング用のヘルスチェックエンドポイントを設定します。

---

概要

項目	詳細
入力	ln-770 の Context Store
出力	ヘルスチェックエンドポイントと Kubernetes プローブ設定
スタック	.NET（AspNetCore.Diagnostics.HealthChecks）、Python（FastAPI ルート）

---

フェーズ 1：コンテキストの受信と依存関係の特定

Context Store を受け取り、監視対象の依存関係をスキャンします。

必須コンテキスト：

• STACK：.NET または Python
• PROJECT_ROOT：プロジェクトディレクトリのパス

冪等性チェック：

• .NET：AddHealthChecks または MapHealthChecks を検索します
• Python：/health ルートを検索します
• 見つかった場合：{ "status": "skipped" } を返します

依存関係の検出：

依存関係	.NET での検出方法	Python での検出方法
PostgreSQL	csproj 内の Npgsql	requirements 内の psycopg2 または asyncpg
MySQL	csproj 内の MySql.Data	requirements 内の mysql-connector-python
Redis	csproj 内の StackExchange.Redis	requirements 内の redis
RabbitMQ	csproj 内の RabbitMQ.Client	requirements 内の pika または aio-pika
MongoDB	csproj 内の MongoDB.Driver	requirements 内の pymongo

---

フェーズ 2：ヘルスチェック戦略の設計

Kubernetes のベストプラクティスに従って、3 種類のヘルスエンドポイントを定義します。

エンドポイントの種類

エンドポイント	プローブの種類	目的	チェック内容
/health/live	Liveness	アプリは稼働しているか？	アプリが応答する（依存関係のチェックなし）
/health/ready	Readiness	アプリはトラフィックを処理できるか？	すべての依存関係が正常
/health/startup	Startup（K8s 1.16+）	アプリの初期化は完了しているか？	初期ウォームアップの完了

各プローブが失敗した場合

プローブ	失敗時のアクション	Kubernetes の動作
Liveness	コンテナーを再起動	kubelet がコンテナーを再起動
Readiness	サービスから除外	トラフィックを停止し、再起動はしない
Startup	他のプローブを遅延	Liveness／Readiness を一時停止

---

フェーズ 3：ヘルスチェックのパターンを調査

最新のドキュメントを MCP ツールで確認します。

.NET の場合：

MCP ref: "ASP.NET Core health checks Kubernetes probes"
Context7: /dotnet/aspnetcore

Python の場合：

MCP ref: "FastAPI health check endpoint Kubernetes"
Context7: /tiangolo/fastapi

調査する主なパターン：

1. データベースのヘルスチェック（接続プール）
2. Redis の接続チェック
3. カスタムヘルスチェックの実装
4. ヘルスチェックのレスポンスライターのカスタマイズ

---

フェーズ 4：Kubernetes プローブの設定

アプリケーションの特性に基づいて、プローブのタイミングを決定します。

プローブの設定

パラメーター	Liveness	Readiness	Startup
initialDelaySeconds	10	5	0
periodSeconds	10	5	5
timeoutSeconds	5	3	3
failureThreshold	3	3	30
successThreshold	1	1	1

Startup プローブの計算：

Max startup time = initialDelaySeconds + (periodSeconds × failureThreshold)
Default: 0 + (5 × 30) = 150 seconds

---

フェーズ 5：実装の生成

.NET の出力ファイル

ファイル	目的
Extensions/HealthCheckExtensions.cs	ヘルスチェックの登録
HealthChecks/StartupHealthCheck.cs	カスタム起動チェック

生成手順：

1. 現行の ASP.NET Core ヘルスチェック API について、MCP ref を使用します
2. 次の内容を含む HealthCheckExtensions を生成します。
   • AddHealthChecks の登録
   • データベースのヘルスチェック（検出された場合）
   • Redis のヘルスチェック（検出された場合）
   • カスタム StartupHealthCheck
3. 適切なタグを設定して、3 つのエンドポイントを構成します

追加するパッケージ：

• AspNetCore.HealthChecks.NpgSql（PostgreSQL の場合）
• AspNetCore.HealthChecks.Redis（Redis の場合）
• AspNetCore.HealthChecks.MySql（MySQL の場合）

登録コード：

builder.Services.AddHealthCheckServices(builder.Configuration);
// ...
app.MapHealthCheckEndpoints();

Python 出力ファイル

ファイル	目的
routes/health.py	ヘルスチェックルーター
services/health_checker.py	依存関係のヘルスチェック

生成プロセス：

1. FastAPI のヘルスチェックパターンについて MCP のリファレンスを使用します
2. 次の機能を備えたヘルスチェックルーターを生成します：
   • /health/live エンドポイント（シンプル）
   • /health/ready エンドポイント（依存関係のチェック付き）
   • /health/startup エンドポイント
3. 依存関係を検証する health_checker サービスを生成します

登録コード：

from routes.health import health_router
app.include_router(health_router)

Kubernetes マニフェストのスニペット

deployment.yaml に含めるために生成します：

livenessProbe:
  httpGet:
    path: /health/live
    port: 5000
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /health/ready
    port: 5000
  initialDelaySeconds: 5
  periodSeconds: 5
  timeoutSeconds: 3
  failureThreshold: 3

startupProbe:
  httpGet:
    path: /health/startup
    port: 5000
  periodSeconds: 5
  failureThreshold: 30

---

フェーズ 6：検証

検証手順：

1. 構文チェック：

   • .NET：dotnet build --no-restore
   • Python：python -m py_compile routes/health.py

2. エンドポイントのテスト：

   curl http://localhost:5000/health/live
   curl http://localhost:5000/health/ready
   curl http://localhost:5000/health/startup
   

3. レスポンス形式の確認：

   {
     "status": "Healthy",
     "checks": {
       "database": { "status": "Healthy", "duration": "00:00:00.0234" },
       "redis": { "status": "Healthy", "duration": "00:00:00.0012" }
     },
     "totalDuration": "00:00:00.0250"
   }
   

4. 依存関係の障害テスト：

   • データベースを停止します
   • /health/ready が 503 を返すことを確認します
   • /health/live が引き続き 200 を返すことを確認します

---

コーディネーターに返す

{
  "status": "success",
  "files_created": [
    "Extensions/HealthCheckExtensions.cs",
    "HealthChecks/StartupHealthCheck.cs"
  ],
  "packages_added": [
    "AspNetCore.HealthChecks.NpgSql"
  ],
  "registration_code": "builder.Services.AddHealthCheckServices(configuration);",
  "message": "Configured health checks with liveness, readiness, and startup probes"
}

---

参考リンク

• ASP.NET Core ヘルスチェック
• Kubernetes プローブ
• AWS EKS ヘルスチェックのベストプラクティス

---

重要なルール

• 3 つの独立したエンドポイント — Kubernetes のベストプラクティスに従い、/health/live、/health/ready、/health/startup を使用します
• Liveness では依存関係をチェックしないでください — アプリが稼働していることだけを確認します（連鎖的な再起動を防ぎます）
• Readiness ではすべての依存関係をチェックします — DB、Redis、RabbitMQ への接続を検証します
• プロジェクトファイルから依存関係を自動検出します — csproj/requirements をスキャンし、既知のパッケージを特定します
• べき等性 — AddHealthChecks/MapHealthChecks または /health ルートがすでに存在する場合は、status: "skipped" を返します

完了の定義

• コンテキストストアを受信済み（スタック、プロジェクトルート）
• 依存関係を検出済み（PostgreSQL、MySQL、Redis、RabbitMQ、MongoDB）
• 検出されたスタック向けのヘルスチェックエンドポイント（live、ready、startup）を生成済み
• 適切なタイミングパラメーターを設定した Kubernetes プローブのマニフェストスニペットを生成済み
• 構文を検証済み（dotnet build または py_compile）
• 構造化 JSON レスポンスを ln-770 コーディネーターに返却済み

---

バージョン： 2.0.0 最終更新日： 2026-01-10