.NET .NET Aspire のヘルスチェック
正常性チェックは、アプリに関する可用性と状態情報を提供します。 多くの場合、正常性チェックは HTTP エンドポイントとして公開されますが、アプリ内でログを書き込んだり、現在の正常性に基づいて他のタスクを実行したりするためにも使用できます。 通常、正常性チェックは、アプリの状態を確認するために、外部監視サービスまたはコンテナー オーケストレーターと組み合わせて使用されます。 正常性チェックによって報告されるデータは、さまざまなシナリオで使用できます。
- コンテナー オーケストレーター、ロード バランサー、API ゲートウェイ、およびその他の管理サービスによって行われる決定に影響を与えます。 たとえば、コンテナー化されたアプリの正常性チェックが失敗した場合、ロード バランサーのルーティング トラフィックによってスキップされる可能性があります。
- データベースやキャッシュなど、基になる依存関係が使用可能であることを確認し、適切なステータス メッセージを返します。
- アプリが期待どおりに応答していないときにアラートまたは通知をトリガーします。
.NET .NET Aspire の正常性チェックエンドポイント
.NET
.NET Aspire では、Program.cs ファイルから AddServiceDefaults メソッドと MapDefaultEndpoints メソッドが呼び出されたときに、Development 環境で 2 つの既定の正常性チェック HTTP エンドポイントが公開されます。
/healthエンドポイントは、要求を受信する準備ができているアプリが正常に実行されているかどうかを示します。 アプリが開始後にトラフィックを受け入れる準備ができていると見なされるためには、すべての正常性チェックに合格する必要があります。GET /healthエンドポイントは、アプリが正常なである場合に、HTTP 状態コード 200 と の 値 返します。 /aliveは、アプリが実行中かクラッシュしたかを示し、再起動する必要があります。 アプリが生存と見なされるためには、live タグでタグ付けされた正常性チェックのみが合格する必要があります。GET /aliveエンドポイントは、HTTP 状態コード 200 と、アプリが有効な状態 場合に の 値を返します。
AddServiceDefaults と MapDefaultEndpoints の方法では、OpenTelemetry や サービス検出 構成など、正常性チェックだけでなく、さまざまな構成もアプリに適用されます。
非開発環境
開発環境以外では、/health エンドポイントと /alive エンドポイントは既定で無効になります。 これらを有効にする必要がある場合は、ホストのフィルター処理や承認など、さまざまなルーティング機能を使用してこれらのエンドポイントを保護することをお勧めします。 詳細については、
さらに、これらのエンドポイントの要求タイムアウトと出力キャッシュを構成して、不正使用やサービス拒否攻撃を防ぐのが有利な場合があります。 これを行うには、次の変更された AddDefaultHealthChecks メソッドを検討してください。
public static IHostApplicationBuilder AddDefaultHealthChecks(this IHostApplicationBuilder builder)
{
builder.Services.AddRequestTimeouts(
configure: static timeouts =>
timeouts.AddPolicy("HealthChecks", TimeSpan.FromSeconds(5)));
builder.Services.AddOutputCache(
configureOptions: static caching =>
caching.AddPolicy("HealthChecks",
build: static policy => policy.Expire(TimeSpan.FromSeconds(10))));
builder.Services.AddHealthChecks()
// Add a default liveness check to ensure app is responsive
.AddCheck("self", () => HealthCheckResult.Healthy(), ["live"]);
return builder;
}
上記のコード:
-
HealthChecksという名前のポリシーを使用して、正常性チェック要求に 5 秒のタイムアウトを追加します。 -
HealthChecksという名前のポリシーを使用して、正常性チェック応答に 10 秒のキャッシュを追加します。
次に、更新された MapDefaultEndpoints メソッドを検討します。
public static WebApplication MapDefaultEndpoints(this WebApplication app)
{
var healthChecks = app.MapGroup("");
healthChecks
.CacheOutput("HealthChecks")
.WithRequestTimeout("HealthChecks");
// All health checks must pass for app to be
// considered ready to accept traffic after starting
healthChecks.MapHealthChecks("/health");
// Only health checks tagged with the "live" tag
// must pass for app to be considered alive
healthChecks.MapHealthChecks("/alive", new()
{
Predicate = static r => r.Tags.Contains("live")
});
return app;
}
上記のコード:
- 正常性チェック エンドポイントを
/パスの下にグループします。 - 出力をキャッシュし、対応する
HealthChecksポリシーを使用して要求時間を指定します。
更新された AddDefaultHealthChecks メソッドと MapDefaultEndpoints メソッドに加えて、要求タイムアウトと出力キャッシュの両方に対応するサービスを追加する必要があります。
適切に使用するアプリのエントリ ポイント (通常は Program.cs ファイル) に、次のコードを追加します。
// Wherever your services are being registered.
// Before the call to Build().
builder.Services.AddRequestTimeouts();
builder.Services.AddOutputCache();
var app = builder.Build();
// Wherever your app has been built, before the call to Run().
app.UseRequestTimeouts();
app.UseOutputCache();
app.Run();
詳細については、「
統合の正常性チェック
.NET
.NET Aspire 統合を使用して、アプリの追加のヘルスチェックを登録することもできます。 これらの正常性チェックは、/health と /alive エンドポイントの返された状態に影響します。 たとえば、.NET AspirePostgreSQL 統合では、正常性チェックが自動的に追加され、次の条件が確認されます。
- データベース接続が確立される可能性がある
- データベース クエリが正常に実行される可能性がある
これらの操作のいずれかが失敗した場合、対応する正常性チェックも失敗します。
ヘルスチェックを設定する
使用可能な構成オプションのいずれかを使用して、特定の統合の正常性チェックを無効にすることができます。
{
"Aspire": {
"Npgsql": {
"DisableHealthChecks": true,
}
}
}
インライン デリゲートを使用して、正常性チェックを構成することもできます。
builder.AddNpgsqlDbContext<MyDbContext>(
"postgresdb",
static settings => settings.DisableHealthChecks = true);
参照先
- C# でアプリの正常性チェックを
する - ASP.NET Core での正常性チェック
.NET Aspire