Defina o problema antes de coletar

Identifique o processo e a versão, a operação afetada, o intervalo, o p95/p99 e a taxa de erro. Compare com uma janela saudável e anote carga, implantação e dependências. Uma captura sem contexto é difícil de interpretar e pode conter detalhes que não devem ser compartilhados.

Em produção, siga o procedimento operacional da equipe, confirme permissões e impacto, limite a duração e proteja os arquivos coletados. Ferramentas de diagnóstico podem consumir recursos; traces e dumps podem incluir informações sensíveis.

Observe primeiro os contadores do runtime

dotnet-counters oferece uma visão ao vivo de métricas expostas pelo runtime e pelo processo. Com o SDK e a ferramenta disponíveis, selecione o processo e acompanhe o provider System.Runtime:

dotnet-counters monitor --process-id <PID> System.Runtime

Observe tendências durante a janela do problema: uso de CPU, taxa de alocação, tamanho do heap, tempo em GC, exceções e indicadores do ThreadPool. Nenhum contador isolado prova uma causa. Por exemplo, alocação alta pode ser normal se o processo tiver folga e pausas pequenas; compare com latência e comportamento do serviço.

Use trace para aprofundar a hipótese

Se os contadores apontarem para CPU, GC ou espera, um trace curto pode ajudar a localizar stacks e eventos relevantes:

dotnet-trace collect --process-id <PID> --duration 00:00:30

Abra o arquivo gerado em uma ferramenta compatível e procure padrões relacionados ao sintoma, como métodos que dominam CPU ou atividade de GC. Faça uma captura curta e direcionada; aumentar o período sem necessidade aumenta o volume e o custo de análise.

Relacione runtime, aplicação e dependências

Contadores dão contexto do processo; traces distribuídos relacionam uma requisição às etapas da aplicação e às chamadas externas; logs explicam eventos. Correlacione esses sinais com consultas SQL, chamadas HTTP, filas, CPU e conexões para distinguir tempo de execução de tempo de espera.

Veja como compor logs, métricas e traces em observabilidade com OpenTelemetry, Serilog e Dynatrace. Para o caminho de consultas, consulte diagnóstico de EF Core e SQL.

Transforme observação em experimento

  1. Escreva a hipótese apoiada pelos sinais observados.
  2. Escolha uma alteração que possa ser isolada e revertida.
  3. Reproduza o mesmo perfil e colete a mesma métrica antes e depois.
  4. Confirme o efeito em latência, erros e recursos; procure regressões em outras rotas.

Para código isolado, compare alternativas com BenchmarkDotNet. Para comportamento sob tráfego, use cenários e thresholds com k6. O guia prático de performance reúne o fluxo completo.

Referências oficiais