Partilhar via


Criação e redirecionamento de registos no IIS

Observação

Esta não é a versão mais recente deste artigo. Para a versão atual, consulte a versão .NET 10 deste artigo.

Advertência

Esta versão do ASP.NET Core não é mais suportada. Para obter mais informações, consulte a Política de suporte do .NET e do .NET Core. Para a versão atual, consulte a versão .NET 10 deste artigo.

O Módulo ASP.NET Core redireciona a saída da consola stdout e stderr para o disco, se os atributos stdoutLogEnabled e stdoutLogFile do elemento aspNetCore estiverem definidos. Quaisquer pastas no stdoutLogFile caminho são criadas pelo módulo quando o ficheiro de registo é criado. O pool de aplicativos deve ter acesso de escrita ao local onde os registos são guardados (usar IIS AppPool\{APP POOL NAME} para fornecer permissão de escrita, onde {APP POOL NAME} é o nome do pool de aplicativos).

Os registos não são rotacionados, a menos que haja reciclagem/reinício de processos. É responsabilidade do hoster limitar o espaço em disco que os registos consomem.

Usar o registo stdout é apenas recomendado para resolver problemas de arranque de aplicações ao hospedar no IIS ou ao usar suporte em tempo de desenvolvimento para IIS com o Visual Studio, não durante a depuração local e a execução da aplicação com o IIS Express.

Não uses o log STDOUT para o registo geral de aplicações. Para registos rotineiros numa aplicação ASP.NET Core, use uma biblioteca de registos que limite o tamanho dos ficheiros de registo e rode os registos. Para mais informações, consulte provedores de registo de terceiros.

Um carimbo temporal e uma extensão do ficheiro são adicionados automaticamente quando o ficheiro de registo é criado. O nome do ficheiro de registo é composto pela adição do timestamp, ID do processo e extensão do ficheiro (.log) ao último segmento do caminho stdoutLogFile (tipicamente stdout) delimitado por sublinhados. Se o stdoutLogFile caminho terminar em stdout, um registo para uma aplicação com PID de 1934 criada a 05/02/2018 às 19:42:32 tem o nome de ficheiro stdout_20180205194132_1934.log.

Se stdoutLogEnabled for falso, os erros que ocorrem no arranque da aplicação são capturados e registados no log de eventos até ao limite de 30 KB. Após o arranque, todos os registos adicionais são descartados.

O seguinte elemento de exemplo aspNetCore configura o registo stdout no caminho relativo .\log\. Confirme que a identidade do utilizador do AppPool tem permissão para escrever no caminho fornecido.

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="true"
    stdoutLogFile=".\logs\stdout"
    hostingModel="inprocess">
</aspNetCore>

Ao publicar uma aplicação para implementação do Azure App Service, o Web SDK define o stdoutLogFile valor para \\?\%home%\LogFiles\stdout. A %home variável de ambiente é pré-definida para aplicações alojadas no Azure App Service.

Para criar regras de filtro de registo, consulte a secção Aplicar regras de filtro de registo no código da documentação do registo do ASP.NET Core.

Para mais informações sobre formatos de caminho, veja Formatos de caminho de ficheiro em sistemas Windows.

Registos de diagnóstico melhorados

O Módulo Núcleo ASP.NET é configurável para fornecer registos de diagnóstico aprimorados. Adicione o <handlerSettings> elemento ao <aspNetCore> elemento em web.config. Ao definir o debugLevel como TRACE, expõe uma maior fidelidade da informação de diagnóstico.

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="debugFile" value=".\logs\aspnetcore-debug.log" />
    <handlerSetting name="debugLevel" value="FILE,TRACE" />
  </handlerSettings>
</aspNetCore>

Quaisquer pastas no caminho (logs no exemplo anterior) são criadas pelo módulo quando o ficheiro de registo é criado. O pool de aplicativos deve ter acesso de escrita ao local onde os registos são guardados (usar IIS AppPool\{APP POOL NAME} para fornecer permissão de escrita, onde {APP POOL NAME} é o nome do pool de aplicativos).

Os valores do nível de depuração (debugLevel) podem incluir tanto o nível como a localização.

Níveis (por ordem do menor ao mais prolixo):

  • ERROR
  • ADVERTÊNCIA
  • INFORMAÇÃO
  • RASTREIO

Localizações (são permitidas várias localizações):

  • CONSOLA
  • REGISTO DE EVENTOS
  • FILE

As definições do handler também podem ser fornecidas através de variáveis de ambiente:

  • ASPNETCORE_MODULE_DEBUG_FILE: Caminho para o ficheiro de registo de depuração. (Padrão: aspnetcore-debug.log)
  • ASPNETCORE_MODULE_DEBUG: Debugar a definição do nível.

Advertência

Não deixe o registo de depuração ativado na implementação por mais tempo do que o necessário para resolver um problema. O tamanho do log não é limitado. Deixar o registo de depuração ativado pode esgotar o espaço disponível em disco e fazer com que o servidor ou serviço de aplicação colapse.

Veja a configuração do módulo ASP.NET Core com web.config para um exemplo do elemento aspNetCore no ficheiro web.config.