.NET .NET Aspire 상태 점검
상태 검사는 앱에 대한 가용성 및 상태 정보를 제공합니다. 상태 검사는 종종 HTTP 엔드포인트로 노출되지만 앱에서 내부적으로 로그를 작성하거나 현재 상태에 따라 다른 작업을 수행하는 데 사용할 수도 있습니다. 상태 검사는 일반적으로 외부 모니터링 서비스 또는 컨테이너 오케스트레이터와 함께 사용되어 앱의 상태를 확인합니다. 상태 검사에서 보고된 데이터는 다양한 시나리오에 사용할 수 있습니다.
- 컨테이너 오케스트레이터, 부하 분산 장치, API 게이트웨이 및 기타 관리 서비스의 결정에 영향을 줍니다. 예를 들어, 컨테이너화된 앱에 대한 상태 검사가 실패하면 트래픽을 라우팅하는 부하 분산 장치에서 해당 트래픽이 건너뛰어질 수 있습니다.
- 데이터베이스 또는 캐시와 같은 기본 종속성을 사용할 수 있는지 확인하고 적절한 상태 메시지를 반환합니다.
- 앱이 예상대로 응답하지 않을 때 경고 또는 알림을 트리거합니다.
상태 점검 엔드포인트 .NET.NET Aspire
.NET
.NET Aspire는 Program.cs 파일에서 AddServiceDefaults 및 MapDefaultEndpoints 메서드를 호출할 때 개발 환경에서 두 개의 기본 상태 검사 HTTP 엔드포인트를 노출합니다.
/health엔드포인트는 앱이 요청을 받을 준비가 된 곳에서 정상적으로 실행되고 있는지를 나타냅니다. 앱이 시작된 후 트래픽을 수락할 준비가 되었다고 간주되려면 모든 상태 검사가 통과해야 합니다.GET /health/health엔드포인트는 앱이 건강한때 HTTP 상태 코드 200과text/plainHealthy 값을 반환합니다./alive앱이 실행 중인지 또는 충돌했는지를 나타내며 다시 시작해야 합니다. 라이브 태그가 지정된 상태 검사는 앱이 활성 상태로 간주되기 위해 반드시 통과해야 합니다.GET /alive/alive엔드포인트는 앱이 활성 상태인때 HTTP 상태 코드 200과text/plainHealthy 값을 반환합니다.
또한 AddServiceDefaults 및 MapDefaultEndpoints 메서드는 OpenTelemetry 및 서비스 검색 구성과 같은 상태 검사 외에 앱에 다양한 구성을 적용합니다.
비개발 환경
비개발 환경에서는 기본적으로 /health 및 /alive 엔드포인트가 비활성화됩니다. 사용하도록 설정해야 하는 경우 호스트 필터링 및/또는 권한 부여와 같은 다양한 라우팅 기능을 사용하여 이러한 엔드포인트를 보호하는 것이 좋습니다. 자세한 내용은 상태 검사 항목을 ASP.NET Core에서 참조하세요.
또한 이러한 엔드포인트에 대한 요청 시간 제한 및 출력 캐싱을 구성하여 남용 또는 서비스 거부 공격을 방지하는 것이 유리할 수 있습니다. 이렇게 하려면 다음과 같은 수정된 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();
자세한 내용은 요청 시간 제한 미들웨어를 ASP.NET Core에서, 그리고 출력 캐싱 미들웨어를 ASP.NET Core에서 참조하세요.
통합 상태 검사
.NET
.NET Aspire 통합은 앱에 대한 추가 상태 검사를 등록할 수도 있습니다. 이러한 상태 검사는 /health 및 /alive 엔드포인트의 반환된 상태에 기여합니다. 예를 들어 .NET AspirePostgreSQL 통합은 상태 검사를 자동으로 추가하여 다음 조건을 확인합니다.
- 데이터베이스 연결을 설정할 수 있습니다.
- 데이터베이스 쿼리를 성공적으로 실행할 수 있습니다.
이러한 작업 중 하나가 실패하면 해당 상태 검사도 실패합니다.
상태 검사 구성
사용 가능한 구성 옵션 중 하나를 사용하여 지정된 통합에 대한 상태 검사를 사용하지 않도록 설정할 수 있습니다. .NET .NET Aspire 통합은 Microsoft.Extensions.Configurations을 지원하여 appsettings.json같은 구성 파일을 통해 설정을 적용합니다.
{
"Aspire": {
"Npgsql": {
"DisableHealthChecks": true,
}
}
}
인라인 대리자를 사용하여 상태 검사를 구성할 수도 있습니다.
builder.AddNpgsqlDbContext<MyDbContext>(
"postgresdb",
static settings => settings.DisableHealthChecks = true);
참고
.NET Aspire