Coletar diagnósticos em contêineres

As mesmas ferramentas de diagnóstico úteis para diagnosticar problemas do .NET Core 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.

Usando 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 Core (dotnet-counters, dotnet-dump, dotnet-gcdump, dotnet-monitor e dotnet-trace) foram projetadas para funcionar em uma grande 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 Core direcionados ao .NET Core 3.1 ou posteriores 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.

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

Se você quiser usar ferramentas de diagnóstico da CLI global do .NET Core 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 Core precisam de acesso aos arquivos que o runtime do .NET Core 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".

Usando 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 ao iniciar 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.

Usando PerfCollect em um contêiner sidecar

Se você quiser executar PerfCollect em um contêiner para criar um perfil de um processo do .NET Core em um contêiner diferente, a experiência será quase a mesma, exceto por essas diferenças:

• 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.