Siga uma solicitação lenta antes de redimensionar

Escolha uma requisição com um resultado esperado claro

Para um endpoint de relatório ilustrativo, registre o padrão de rota, o tamanho aproximado dos dados, o contexto de autenticação e se ele cria trabalho em segundo plano. Use uma conta de teste e dados representativos sanitizados. Não copie tokens, identificadores de clientes ou corpos de requisição completos para uma nota de incidente.

Separe o custo de inicialização da primeira requisição do comportamento repetido em regime estacionário. Registre a janela UTC e a revisão de release. Determine se todas as rotas estão lentas, se apenas relatórios grandes são afetados ou se o atraso segue uma dependência externa específica. Essas distinções tornam a próxima medição mais útil do que uma ampla coleta de métricas não relacionadas.

Construa uma linha do tempo sem contar em dobro

Os traces do OpenTelemetry conectam spans relacionados por meio de contexto propagado entre limites de serviço. Apenas correspondência de timestamps não é suficiente. Spans síncronos aninhados e chamadas paralelas podem se sobrepor. Filhos assíncronos podem sobreviver ao pai, então somar a duração de cada span pode contar o tempo decorrido em dobro. Siga as operações que determinam quando a requisição é concluída.

Referência técnica: Traces do OpenTelemetry · Comportamento de término de span do OpenTelemetry.

O maior intervalo sugere onde inspecionar, não a causa raiz. Um intervalo de banco de dados medido na API pode incluir a espera por uma conexão antes de uma consulta chegar ao banco de dados. Telemetria ausente também não prova que nenhum trabalho ocorreu; inspecione a amostragem e a cobertura de instrumentação.

Correlacione observações da aplicação e do host

Colete tempos de requisição, erros, uso de conexões de banco de dados, idade da fila, CPU, memória e pressão de disco para a mesma janela. Anote backups, migrações ou releases simultâneos. Uma única captura de tela de utilização pode perder o pico que afetou a requisição.

Use IDs de correlação e timestamps em logs redigidos com retenção e controles de acesso apropriados. Evite segredos brutos, payloads de clientes e rótulos de métricas ilimitados. Instrumente o limite necessário para a hipótese e revise a sobrecarga. Um novo agente de tracing é em si uma mudança que vale observar.

Inspecione a consulta sem causar outro incidente

Identifique primeiro a forma da consulta, as características de tamanho da entrada e as esperas de conexão ou lock. PostgreSQL EXPLAIN descreve um plano; EXPLAIN ANALYZE na verdade executa a instrução e adiciona sobrecarga de instrumentação. Uma escrita pode alterar dados, enquanto uma leitura cara ainda cria carga. Use um banco de dados representativo isolado para a investigação inicial.

O custo do planejador não é milissegundos decorridos. Uma tabela de teste minúscula pode produzir um plano diferente do conjunto de dados maior da aplicação. Revise estatísticas, índices e distribuição, e compare a mesma forma de consulta após alterá-la. Nunca cole uma escrita desconhecida em um comando de análise em produção apenas para obter tempo.

Referência técnica: EXPLAIN do PostgreSQL.

Preveja o que uma mudança deve melhorar

Se a espera no pool domina, inspecione conexões de worker ou requisições que mantêm uma conexão desnecessariamente. Se a execução da consulta domina, inspecione o plano e as linhas solicitadas. Se uma API externa domina, revise timeouts, retentativas e se o trabalho precisa ser síncrono. Saturação de CPU durante a serialização aponta para um experimento diferente.

Escreva uma previsão: reduzir a concorrência de exportação deve reduzir a espera no pool da API enquanto as exportações demoram mais. Isso expõe o tradeoff. Repita a mesma mistura de requisições, compare latência e erros, e verifique se a melhoria não apenas moveu a falha para uma fila em crescimento contínuo.

Mantenha o resultado e sua incerteza

Registre a observação original, a mudança testada, o método de comparação e a incerteza restante. Se as evidências contradizem a hipótese, desfaça a mudança isolada onde apropriado e investigue outro limite. Evite acumular mudanças permanentes de ajuste sem explicação.

Redimensione quando as medições identificarem uma restrição de recurso que alocação adicional poderia resolver. Use o orçamento de carga de trabalho e capture uma regressão de release no resumo de incidente. O resultado é um diagnóstico fundamentado, não uma latência prometida ou um benchmark de provedor.