APRENDER. PRATICAR. EVOLUIR.O que uma sonda observa
AddHealthChecks com MapHealthChecks torna possível responder num endpoint de saúde. Sem registos adicionais, a resposta não inclui verificação da base de dados, da fila ou do fornecedor remoto. Healthy significa que a aplicação conseguiu responder naquele âmbito.
Se a aceitação exige consultar uma dependência, essa condição precisa de um check deliberado, com custo e limite de tempo adequados. Evita transformar a sonda numa operação pesada que compete com o tráfego que pretende proteger.
Prontidão e reinício
Uma instância pode estar viva enquanto prepara dados necessários para servir pedidos. Uma readiness negativa deve impedir a admissão de tráfego conforme o contrato do consumidor; não significa automaticamente que reiniciar resolve a situação.
Se a inicialização normalmente demora 60 segundos, um ready negativo aos 20 segundos pode ser esperado. Define também um prazo para investigar inicialização que não termina. A sonda live pode excluir esses checks, distinguindo capacidade de responder da prontidão funcional.
Filtro e significado do HTTP
As etiquetas de registo só se tornam um filtro quando o Predicate do endpoint as consulta. Um Predicate sempre false exclui todos os checks e não escolhe o mais rápido. O mapeamento HTTP também precisa de corresponder ao consumidor: Healthy e Degraded devolvem 200 por predefinição, enquanto Unhealthy devolve 503.
Se o balanceador deve retirar uma instância Degraded, altera explicitamente esse mapeamento ou usa um consumidor que interprete o estado com o mesmo contrato.
Atualidade e ação externa
Um corpo Healthy guardado num proxy representa uma observação anterior, não a capacidade atual da instância. Por predefinição, o middleware acrescenta cabeçalhos para impedir cache da resposta. AllowCachingResponses=true apenas deixa de modificar esses cabeçalhos; não implementa uma cache nem garante revalidação.
No exemplo, MapHealthChecks publica sinais, mas não impede chamadas a /about. É o consumidor externo, configurado para essas sondas, que decide a admissão de tráfego.
Logs com finalidade definida
Para analisar estados e duração, não é necessário registar automaticamente todos os cabeçalhos e corpos. Seleciona os campos úteis e limita o acesso aos registos. Nas opções de HTTP logging, permitir um nome de cabeçalho permite registar o seu valor; incluir Authorization pode expor a credencial.
Limites de corpo reduzem volume, mas um segredo pode aparecer nos primeiros bytes. Redação e classificação exigem configuração própria e não devem ser presumidas a partir de um limite de tamanho.
Dimensões de métricas
A duração HTTP pode ser analisada por rota, estado e categorias adicionais. Usa conjuntos limitados para essas categorias: web, mobile e other são mais controláveis do que um ID diferente em cada pedido. Dimensões sem limite criam muitas combinações e podem exceder os limites de recolha.
Ao enriquecer através de IHttpMetricsTagsFeature, verifica a existência da feature; ela depende de haver observação da métrica. A ausência de enriquecimento não demonstra uma falha funcional do pedido.
A população por trás do indicador
Um histograma dominado por sondas rápidas pode dar uma imagem enganadora da duração dos pedidos de negócio. Identifica a população que pretende responder à pergunta operacional. DisableHttpMetrics no endpoint permite excluir sondas dessa métrica, preservando a função de saúde.
Isso não desativa necessariamente todos os logs nem toda a monitorização. No registo de diagnóstico, conserva a janela temporal, os endpoints incluídos e a versão ativa para comparar observações com o mesmo significado.
// ASP.NET Core 10 Program.cs reading example.
// Simulated readiness from startup configuration; no dependency is contacted.
using Microsoft.AspNetCore.Diagnostics.HealthChecks;
using Microsoft.AspNetCore.HttpLogging;
using Microsoft.Extensions.Diagnostics.HealthChecks;
var builder = WebApplication.CreateBuilder(args);
string readiness = builder.Configuration["Training:Readiness"] ?? "starting";
builder.Services.AddHealthChecks().AddCheck("training-readiness", () =>
readiness switch
{
"ready" => HealthCheckResult.Healthy(),
"degraded" => HealthCheckResult.Degraded(),
_ => HealthCheckResult.Unhealthy()
}, tags: new[] { "ready" });
builder.Services.AddHttpLogging(options =>
{
options.LoggingFields = HttpLoggingFields.ResponseStatusCode |
HttpLoggingFields.Duration;
});
var app = builder.Build();
app.UseHttpLogging();
app.MapHealthChecks("/health/live", new HealthCheckOptions
{
Predicate = _ => false
}).DisableHttpMetrics();
app.MapHealthChecks("/health/ready", new HealthCheckOptions
{
Predicate = check => check.Tags.Contains("ready"),
ResultStatusCodes =
{
[HealthStatus.Degraded] = StatusCodes.Status503ServiceUnavailable
}
}).DisableHttpMetrics();
app.MapGet("/about", () => Results.Ok(new { purpose = "probe-reading-example" }));
app.Run();Interpreta Training:Readiness como um estado sintético capturado no arranque. Com starting, live responde Healthy e ready Unhealthy; com degraded, ready devolve 503 por configuração explícita. O exemplo não carrega um índice, não consulta uma base e não bloqueia /about: retirar tráfego depende do consumidor externo configurado.
Alterar a configuração depois do arranque não modifica a variável capturada.
Armadilhas comuns
Um 200 de uma sonda básica não valida dependências. Degraded usa 200 por predefinição. Um limite de bytes não anonimiza um corpo. Etiquetas com IDs únicos podem produzir séries excessivas. Desativar uma métrica de sonda não desativa a própria sonda.
Tópicos relacionados: Âmbito de testes e evidência de integração · Entrega, proxies e recuperação
Escolhe primeiro a decisão operacional e depois a condição observável. Confirma o filtro, o mapeamento HTTP, a atualidade e a população medida antes de aceitar a conclusão.
Referência: Basic probe boundary · ASP.NET Core 10.0 / .NET 10 / C# 14