Compartilhar via

Coletar diagnósticos em contêineres

  • Artigo

As mesmas ferramentas de diagnóstico úteis para diagnosticar problemas do .NET em outros cenários também funcionam em contêineres do Docker. No entanto, algumas das ferramentas exigem etapas especiais para funcionar em um contêiner. Este artigo aborda como ferramentas para coletar rastreamentos de desempenho e coletar despejos podem ser usadas em contêineres do Docker.

Usar ferramentas da CLI do .NET em um contêiner

Essas ferramentas se aplicam a: ✔️ SDK do .NET Core 3.1 e versões posteriores

As ferramentas de diagnóstico da CLI global do .NET (dotnet-counters, dotnet-dump, dotnet-gcdump, dotnet-monitor e dotnet-trace) foram projetadas para funcionar em uma ampla variedade de ambientes e devem funcionar diretamente em contêineres do Docker. Por isso, essas ferramentas são o método preferencial de coleta de informações de diagnóstico para cenários do .NET direcionados ao .NET Core 3.1 ou posterior em contêineres.

Você também pode instalar essas ferramentas sem o SDK do .NET baixando as variantes de arquivo único dos links no parágrafo anterior. Essas instalações exigem uma instalação global do runtime do .NET versão 3.1 ou posterior, que você pode adquirir seguindo qualquer um dos métodos prescritos na documentação de instalação do .NET ou consumindo qualquer um dos contêineres oficiais de runtime.

Usar ferramentas da CLI global do .NET em um contêiner sidecar

Se você quiser usar ferramentas de diagnóstico da CLI global do .NET para diagnosticar processos em um contêiner diferente, considere os seguintes requisitos adicionais:

  1. Os contêineres precisam compartilhar um namespace de processo (para que as ferramentas no contêiner sidecar possam acessar processos no contêiner de destino).
  2. As ferramentas de diagnóstico da CLI global do .NET precisam de acesso aos arquivos que o runtime do .NET grava no diretório /tmp, portanto, o diretório /tmp deve ser compartilhado entre o contêiner de destino e sidecar por meio de uma montagem de volume. Isso pode ser feito, por exemplo, fazendo com que os contêineres compartilhem um volume comum ou um volume emptyDir do Kubernetes. Se você tentar usar as ferramentas de diagnóstico de um contêiner de sidecar sem compartilhar o diretório /tmp, receberá um erro sobre o processo "não executar o runtime do .NET compatível".

Usar PerfCollect em um contêiner

Essa ferramenta se aplica ao: ✔️ .NET Core 2.1 e versões posteriores

O script PerfCollect é útil para coletar rastreamentos de desempenho e é a ferramenta recomendada para coletar rastreamentos antes do .NET Core 3.0. Se usar PerfCollect em um contêiner, considere os seguintes requisitos:

  • PerfCollect requer recursos adicionais para executar a ferramenta perf. O conjunto mínimo de recursos necessários é PERFMON e SYS_PTRACE. Alguns ambientes exigem SYS_ADMIN. Certifique-se de iniciar o contêiner com os recursos necessários. Se o conjunto mínimo não funcionar, tente com o conjunto completo.

  • PerfCollect requer que algumas variáveis de ambiente sejam definidas antes do aplicativo em que ele está iniciando a criação de perfil. Eles podem ser definidos em um Dockerfile ou quando você inicia o contêiner. Como essas variáveis não devem ser definidas em ambientes de produção normais, é comum adicioná-las apenas ao iniciar um contêiner que será perfilado. As duas variáveis necessárias pelo PerfCollect são:

    • DOTNET_PerfMapEnabled=1
    • DOTNET_EnableEventLog=1

Observação

Ao executar o aplicativo com o .NET 7, você também deve definir DOTNET_EnableWriteXorExecute=0 além das variáveis de ambiente anteriores.

Observação

O .NET 6 usa o prefixo DOTNET_ como padrão em vez de COMPlus_ para variáveis de ambiente que configuram o comportamento de tempo de execução do .NET. No entanto, o prefixo COMPlus_ continuará funcionando. Se você estiver usando uma versão anterior do runtime do .NET, continue usando o prefixo COMPlus_ para variáveis de ambiente.

Usar PerfCollect em um contêiner sidecar

Se você quiser executar PerfCollect em um contêiner para criar o perfil de um processo do .NET em um contêiner diferente, a experiência será quase a mesma. As diferenças são:

  • As variáveis de ambiente mencionadas anteriormente (DOTNET_PerfMapEnabled e DOTNET_EnableEventLog) precisam ser definidas para o contêiner de destino (não aquele em execução PerfCollect).
  • O contêiner que executa PerfCollect precisa ter a funcionalidade SYS_ADMIN (não o contêiner de destino).
  • Os dois contêineresprecisam compartilhar um namespace de processo.