← Suporte L2: diagnosticar, mitigar e escalar
07 / 11 · 60 MIN

Diagnóstico por camadas com evidência

Localiza a observação entre cliente, ligação e dependências sem confundir correlação com causa.

Definir uma observação comparável

Antes de testar, regista origem, destino, nome usado, porta, protocolo e contexto de execução. Um pedido no portátil pode atravessar um proxy que o serviço APS não utiliza. Também pode usar outra identidade, outra cadeia de confiança ou configuração de cliente. O sucesso nesse caminho não demonstra sucesso no caminho afetado. Numa oficina, desenha os dois percursos e assinala cada diferença conhecida. Escolhe a próxima observação para reduzir uma dessas diferenças, dentro do acesso autorizado. Não copies variáveis de ambiente completas para um ticket: descreve a configuração relevante sem divulgar segredos. Mantém o resultado e as limitações junto à hipótese que pretendes investigar.

Ler marcos cumulativos do curl

Os tempos apresentados por write-out exigem atenção ao ponto inicial. Num pedido HTTPS novo e direto, sem redirects nem reutilização, time_connect termina na ligação TCP e time_appconnect no handshake TLS. Com 0,12 e 0,42 segundos, a diferença é 0,30. Não somes os valores como fases independentes. Se o primeiro byte chega a 2,42 segundos, decorreram dois segundos depois do handshake. Esse intervalo pode incluir envio, trânsito, filas e trabalho em dependências; não demonstra dois segundos de CPU. Para fluxos com proxy, redirects ou reutilização, revê a interpretação e recolhe contexto adicional. O exercício é uma leitura limitada de marcos, não um perfil completo da aplicação.

Alterar endereço sem perder identidade

Num laboratório autorizado e direto, --resolve pode associar reports.example:443 a um endereço específico mantendo https://reports.example/ na URL. Isso permite comparar um destino mantendo o nome pedido. Substituir a URL pelo IP altera a identidade usada na negociação e pode selecionar outro virtual host. Usar --insecure remove uma verificação importante para o diagnóstico; o desaparecimento do erro nesse modo não significa que a identidade esteja correta. Regista também proxy e regras de exclusão efetivamente aplicados. Uma opção que altera o caminho não autoriza contornar controlos de produção. O objetivo da oficina é compreender qual variável muda e quais permanecem iguais, com nomes e endereços reservados para exemplos.

Limites de espera e resultado incerto

Um limite de ligação não equivale ao limite de toda a operação. No curl, --connect-timeout cobre resolução e os handshakes pedidos; depois da ligação, o pedido pode continuar à espera. Define também um limite global adequado quando esse é o propósito do teste. Para operações com efeitos, um timeout observado pelo cliente não demonstra rejeição remota. Num exercício de instrução de fundos, consulta o estado pela identidade original e confirma o contrato de repetição antes de reenviar. Uma identidade nova pode ser tratada como outra operação. Coordena a mitigação com o responsável e conserva a sequência das tentativas. Não uses retries ilimitados para substituir reconciliação ou diagnóstico.

Interpretar estado e bloqueios PostgreSQL

No PostgreSQL 18, idle in transaction indica uma transação aberta sem consulta em execução naquele momento. Não significa que a sessão terminou nem prova que está a bloquear outras. Se pg_blocking_pids(510) devolve 412, essa observação relaciona 412 com a espera de 510 por um lock. A relação pode envolver um detentor incompatível ou uma espera anterior na fila. Regista hora, sessões e contexto autorizado, sem publicar texto SQL sensível. Leva ao DBA a necessidade de confirmar impacto e escolher mitigação. A função também tem custo; chamadas muito frequentes podem afetar desempenho. Uma recolha limitada não autoriza terminar sessões nem demonstra que a mesma relação existia durante todo o incidente.

Oficina de escalada técnica reproduzível

Usa o registo sintético apresentado e escreve três frases: observação, hipótese e próxima verificação. Por exemplo, o intervalo entre TLS e primeiro byte é elevado face ao caso saudável, mas ainda não se sabe se o tempo está na aplicação ou numa dependência. Junta origem, caminho e pedido correlacionável. Se há um snapshot de bloqueio, identifica a sua hora e não o apresentes como história completa. Um colega deve conseguir repetir o raciocínio sem credenciais nem dados reais de clientes. Pede-lhe para encontrar uma explicação alternativa compatível com os mesmos sinais. Fecha a oficina com um pedido específico à equipa competente e com o critério que permitiria aceitar ou rejeitar a hipótese.

# Synthetic observation from one fresh direct HTTPS request
# No proxy, redirects, connection reuse or production execution.
time_namelookup=0.02
time_connect=0.12
time_appconnect=0.42
time_starttransfer=2.42
time_total=2.52
# TCP-to-TLS interval: 0.42 - 0.12 = 0.30 seconds
# TLS-to-first-byte interval: 2.42 - 0.42 = 2.00 seconds
# These intervals do not isolate application CPU or database time.
NA PRÁTICA

Numa ligação nova, time_connect=0.12 e time_appconnect=0.42 indicam um intervalo de 0,30 s entre TCP e TLS concluídos. Não medem isoladamente CPU da aplicação.

Armadilhas comuns

Somar tempos cumulativos; comparar portátil e serviço sem contexto; desligar validação TLS; interpretar idle in transaction como sessão concluída; terminar blockers sem autorização.

Tópicos relacionados: Hipóteses e evidências úteis · Mitigação e validação operacional · Passagem de turno e melhoria

Leva esta ideia contigo

Um diagnóstico útil reduz as explicações possíveis e documenta limites. Um comando bem-sucedido não substitui a validação do resultado de negócio.

Criar conta

Referência: curl command line manual · Operational support; PostgreSQL 18, OpenSSL 3.5 and BIND 9.20.29 examples; reviewed 2026-09-30