Analista em Computação/Ênfase em Programação de Sistemas na Tecnologia Microsoft
Em um servidor ASP.NET Core, deseja-se fazer a captura global de exceções correlação de logs por requisição. Qual configuração segue as recomendações oficiais?
AA ordem dos middlewares é sempre irrelevante por definição da plataforma, pois o runtime intercepta uniformemente exceções, autenticação, compressão e roteamento independentemente da posição no pipeline.
BUseDeveloperExceptionPage em produção para máxima visibilidade com stack trace ao usuário final.
CILogger <T> não é thread-safe, exigindo implementação própria para concorrência.
DNão há suporte a logging estruturado, sendo necessário serializar objetos manualmente.
EUseExceptionHandler configurado no topo do pipeline e logging estruturado com scopes/identificadores de correlação (Correlation IDs), preservando contexto por requisição.
Revelar gabarito e comentário▾
GabaritoE — UseExceptionHandler configurado no topo do pipeline e logging estruturado com scopes/identificadores de correlação (Correlation IDs), preservando contexto por requisição.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
ASP.NET Core: Middleware e Logging Estruturado
Gabarito: letra E. A configuração que segue as recomendações oficiais do ASP.NET Core é aquela que posiciona o middleware de tratamento de exceções (UseExceptionHandler) no início do pipeline e emprega logging estruturado com scopes e Correlation IDs para correlacionar logs por requisição. Essa prática garante que exceções não tratadas sejam capturadas globalmente e que o contexto da requisição seja preservado nos logs.
Prática
Recomendação Oficial
Descrição
Tratamento de exceções
UseExceptionHandler no topo do pipeline
Captura exceções globalmente, antes de outros middlewares
Logging estruturado
Suporte nativo com scopes e Correlation IDs
Agrupa logs por requisição usando HttpContext.TraceIdentifier
Ambiente de desenvolvimento
UseDeveloperExceptionPage
Exibe stack trace detalhado (apenas em dev)
Thread safety do ILogger<T>
Thread-safe por design
Não requer implementação própria para concorrência
1UseExceptionHandler
2Autenticação
3Autorização
4Roteamento
5Endpoint
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
A ordem dos middlewares no ASP.NET Core é relevante. O pipeline é sequencial; por exemplo, o middleware de tratamento de exceções deve ser registrado primeiro para capturar exceções de todos os middlewares subsequentes. A afirmação de que a ordem é irrelevante contradiz a documentação oficial da plataforma.
Alternativa B — ❌ Incorreta
UseDeveloperExceptionPage é recomendado apenas em ambiente de desenvolvimento, pois exibe detalhes internos (stack trace, query strings) que não devem ser expostos ao usuário final. Em produção, deve-se usar UseExceptionHandler para exibir uma página de erro amigável e logar a exceção.
Alternativa C — ❌ Incorreta
ILogger<T> é thread-safe por design no ASP.NET Core. O framework garante que chamadas concorrentes ao logger sejam seguras, não sendo necessária implementação própria para concorrência.
Alternativa D — ❌ Incorreta
O ASP.NET Core oferece suporte nativo a logging estruturado. Os provedores como Console, Debug, EventSource, e bibliotecas como Serilog e NLog permitem logging com objetos e escopos (scopes), sem necessidade de serialização manual.
Alternativa E — ✅ Correta ⟵ GABARITO
A prática recomendada consiste em:
Registrar UseExceptionHandler no início do pipeline (antes de outros middlewares) para capturar exceções globalmente.
Utilizar logging estruturado com scopes e Correlation IDs (ex.: gerados a partir do HttpContext.TraceIdentifier) para que todos os logs de uma mesma requisição sejam agrupados e identificados, facilitando a correlação e análise.
Essa combinação está alinhada com as melhores práticas da Microsoft para ASP.NET Core, garantindo resiliência e observabilidade da aplicação.