Slow Query Log estava desligado durante o incidente: o que ainda dá para provar?

Depois de um incidente, uma das perguntas mais comuns é:

“o banco estava lento?”

A resposta parece simples quando existe histórico de queries lentas. Mas e quando você chega depois do problema e encontra isto?

1
slow_query_log = OFF

Foi exatamente a limitação encontrada em uma investigação real.

A pior saída seria concluir:

não houve slow query.

O log estar desligado prova outra coisa: não havia histórico daquele mecanismo para confirmar nem descartar queries lentas na janela do incidente.

Isso não encerra a investigação. Só muda a força das conclusões que podem ser feitas.

O que estava comprovado #

Na coleta, a configuração do MySQL mostrava o Slow Query Log desabilitado e não havia arquivo histórico útil para a janela analisada.

Em paralelo, outras camadas tinham evidência disponível:

respostas HTTP 500, 502 e 504 na origem;
falhas temporárias na comunicação Nginx → FastCGI/PHP-FPM;
mensagens de Too many open files e falha de criação de sockets;
upstream timed out, recv() failed e conexões encerradas prematuramente;
monitoria registrando pressão de CPU/load;
configuração efetiva do Nginx e limites dos processos;
configuração do pool PHP-FPM;
distribuição do impacto em rotas dinâmicas.

Isso permitia investigar a degradação mesmo sem responder retrospectivamente quais queries foram lentas.

Ausência de Slow Query Log é uma limitação forense #

A diferença semântica importa.

1
2
3
4
5
ERRADO
"Não houve slow query."

CORRETO
"Não havia histórico de Slow Query Log habilitado para confirmar ou descartar slow queries naquela janela."

A primeira frase transforma falta de observabilidade em conclusão.

A segunda documenta a limitação real.

Em troubleshooting, saber o que não pode ser provado faz parte do diagnóstico.

O que ainda dá para investigar #

Mesmo sem histórico de queries lentas, outras fontes ajudam a reconstruir o modo de falha.

1. Logs da camada web #

No caso analisado, o error.log do Nginx mostrou falhas concretas entre a origem e o backend FastCGI/PHP-FPM.

Uma busca sanitizada pode começar assim:

1
2
grep -Ei 'too many open files|socket\(\) failed|upstream timed out|recv\(\) failed|prematurely closed' \
  /var/log/nginx/error.log

Isso não diz automaticamente por que o incidente ocorreu, mas mostra como a degradação se manifestou.

2. Distribuição dos códigos HTTP #

O access log mostrou crescimento anormal de respostas 5xx durante a janela crítica.

Aqui também existe uma regra importante: antes de transformar contagem de log em métrica de usuário, confirmar o formato daquele log.

No caso real, o access log era global da origem e não registrava Host. Portanto ele servia como indicador de carga recebida pela origem, e não como número exclusivo de visitantes de uma aplicação.

3. Monitoria de host #

CPU e load estavam elevados durante o evento.

Isso é evidência de pressão de processamento, mas não deveria virar sozinho uma RCA do tipo:

CPU alta causou tudo.

A monitoria ajuda a compor a linha do tempo e a correlacionar pressão do host com os erros de aplicação.

4. Limites reais do processo #

Uma configuração declarada no systemd nem sempre representa o limite efetivamente aplicado a um processo já em execução.

No incidente, a investigação comparou configuração e limite efetivo dos processos Nginx, porque os logs registravam erros de file descriptor.

Um roteiro útil é:

1
2
systemctl show nginx -p LimitNOFILE
cat /proc/$(cat /run/nginx.pid)/limits | grep -i 'open files'

Esse tipo de comparação produz evidência muito mais forte do que olhar apenas o arquivo de configuração.

5. Estado do PHP-FPM #

Como havia erros entre Nginx e FastCGI, o pool PHP-FPM também precisava ser examinado.

Foram coletados parâmetros como pm.max_children, servidores iniciais/spare, pm.max_requests e timeout.

A busca não encontrou evidência explícita de:

1
server reached pm.max_children

A interpretação correta foi limitada: não havia evidência direta, naquela busca, de esgotamento explícito do pool por esse mecanismo.

Isso não significa que o PHP-FPM estava necessariamente saudável em toda a janela.

E o banco em tempo real? #

Se o incidente ainda estiver acontecendo, não depender exclusivamente de histórico.

Consultas como estas ajudam a fotografar o estado atual:

1
2
3
SHOW FULL PROCESSLIST;
SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'long_query_time';

O ponto é temporal: PROCESSLIST descreve o presente. Ele não reconstrói queries que já terminaram horas antes.

Por isso observabilidade precisa existir antes do próximo incidente.

O que fazer depois de descobrir que o log estava OFF #

A ação não deveria ser simplesmente ativar logging sem pensar em volume, retenção e disco.

O caminho mais seguro é definir uma janela controlada de observação:

1
2
3
4
5
6
7
objetivo da coleta
→ threshold de long_query_time
→ local do arquivo
→ rotação/retenção
→ capacidade de disco
→ janela de observação
→ correlação com monitoria e erros

Depois, validar se o dado produzido realmente responde às perguntas operacionais.

O aprendizado do caso #

O incidente tinha bastante evidência em Nginx, sistema, PHP-FPM e monitoria.

No banco, porém, faltava justamente o histórico necessário para avaliar queries lentas retrospectivamente.

Isso criou uma conclusão importante:

observabilidade ausente não absolve nem condena um componente. Ela limita o que pode ser afirmado sobre ele.

Quando a evidência desaparece ou nunca foi coletada, o trabalho técnico não é preencher o espaço com uma hipótese convincente.

É registrar o limite, usar as outras fontes disponíveis e preparar o ambiente para que a próxima investigação tenha uma resposta melhor.

Caso relacionado #

Este mesmo evento também gerou uma análise focada na degradação da origem sob concorrência, com Nginx, PHP-FPM, file descriptors e respostas 5xx. O recorte aqui é diferente: o que fazer quando a evidência de banco que você gostaria de consultar simplesmente não existia durante a janela do incidente.