Tair (Redis® OSS-Compatible):Use logs de consultas lentas para solucionar problemas de timeout

Métodos de visualização

Escolha um caminho de solução de problemas

Os logs de consultas lentas são o método principal para solucionar problemas de timeout, mas não cobrem todas as causas possíveis. Correlacione o comportamento observado com o caminho correspondente neste tópico.

Verifique primeiro o desempenho do servidor

O log de consultas lentas registra apenas solicitações que excedem o limiar de consulta lenta. Antes de determinar se um timeout origina-se de uma solicitação lenta ou do enlace de rede, confirme se a própria instância apresenta algum gargalo de desempenho.

Analisar logs de consultas lentas para identificar a causa do timeout

Timeouts de service podem ter causas complexas, mas frequentemente estão relacionados a solicitações lentas. Siga estas etapas para solucionar problemas de timeout.

1. Quando ocorrer um timeout de service, verifique primeiro o log de consulta lenta do nó proxy. Para instruções, consulte Query slow query logs.

   Nota

   • Se sua instância utilizar a arquitetura padrão, pule para Step 3 para analisar o log de consulta lenta do nó de dados.

   • Caso o log de consulta lenta do nó proxy esteja vazio, verifique a conexão de rede entre o cliente e a instância. Se a instância for acessada via rede pública (Internet), consulte Solucionar problemas de latência de conexão de rede pública abaixo.

2. Identifique o comando na entrada mais antiga do log de consulta lenta do nó proxy.

   Nota

   Logs de consulta lenta do nó proxy geralmente são gerados quando solicitações lentas em um nó de dados causam acúmulo de comandos.

   Neste exemplo, a entrada mais antiga do log de consulta lenta foi gerada por um comando KEYS. O endereço IP no registro do log corresponde ao endereço IP do cliente que enviou o comando.

   Na página Slow Logs, clique na aba Proxy Node para visualizar o log de consulta lenta do nó proxy. Neste exemplo, a tabela exibe cinco registros: um para o comando KEYS e quatro para comandos SET, com tempos de execução variando de 64.048 a 88.861 microssegundos.

3. Verifique o log de consulta lenta do nó de dados para confirmar se o comando encontrado no log do proxy também aparece lá, o que pode confirmá-lo como a causa raiz.

   Nota

   Normalmente, o comando que gera primeiro uma entrada de consulta lenta no nó proxy também gera uma entrada no nó de dados. O log de consulta lenta do nó de dados costuma ter menos entradas que o do nó proxy porque os dois logs definem o tempo de execução de forma diferente e utilizam limiares distintos para consultas lentas.

   Neste exemplo, a comparação entre os dois logs revela que existe uma entrada para o comando KEYS em ambos. A ausência de outros comandos do log do proxy no log do nó de dados confirma que o comando KEYS é a causa raiz.

   Na página Slow Logs, clique na aba Data Node para visualizar o log de consulta lenta do nó de dados. Neste exemplo, aparece apenas uma entrada de consulta lenta para o comando KEYS. Seu longo tempo de execução confirma que este comando é a causa raiz do timeout.

4. No log de consulta lenta do nó proxy, pesquise o comando da etapa anterior para encontrar o endereço IP do cliente de source. Em seguida, otimize a aplicação cliente. Se a análise do log de consultas lentas e a verificação da conexão de rede pública não identificarem a causa, consulte Continuar a solução de problemas na VPC, ECS e no lado da aplicação.

Limitações dos logs de consultas lentas e de auditoria para solução de problemas de chaves quentes

O parâmetro slowlog-log-slower-than define o limiar para o log de consulta lenta do nó de dados. O valor padrão é 20.000 microssegundos (20 ms). Solicitações de leitura que ocorrem com alta frequência, mas individualmente são concluídas mais rápido que esse limiar, não são registradas. Como resultado, o log de consultas lentas padrão não consegue capturar as solicitações de leitura que causam um problema de chave quente. Se você suspeitar de um problema de chave quente, reduza o valor de slowlog-log-slower-than para registrar mais solicitações e identificar a source das leituras de alta frequência. Para instruções, consulte Query slow query logs.

Após ativar os logs de auditoria, apenas operações de escrita são registradas. Operações de leitura não são gravadas. Consequentemente, não é possível usar logs de auditoria para visualizar os endereços IP dos clientes das solicitações de leitura que acessam uma chave quente. Para localizar esses endereços IP, reduza o limiar de slowlog-log-slower-than e verifique os logs de consultas lentas resultantes. Para mais informações sobre o recurso de log de auditoria, consulte Overview of audit logs. Caso o problema de chave quente seja causado por solicitações de escrita, use o recurso de consulta de chaves quentes baseado em log de auditoria. Para instruções, consulte Query historical hotkeys.

Solucionar problemas de latência de conexão de rede pública

Se as métricas do servidor não mostrarem gargalos de desempenho (CPU, memória e conexões normais, e log de consultas lentas vazio), mas o cliente ainda relatar erros de timeout de conexão, verifique o enlace de rede entre o cliente e a instância.

Continuar a solução de problemas na VPC, ECS e no lado da aplicação

Caso a análise do log de consultas lentas e a verificação da conexão de rede pública não identifiquem a causa, use informações da VPC, ECS e do lado da aplicação para restringir o escopo.

1. Obtenha o ID da VPC e o ID do vSwitch na página do product.

2. Verifique se a instância ECS que apresenta lentidão ou timeouts está anormal e se o momento coincide com alguma alteração na aplicação.

3. Se o momento coincidir com uma alteração na aplicação, reverta a mudança ou investigue-a em busca de pistas. Use o ID da VPC e o ID do vSwitch para continuar a solução de problemas no console da VPC ou ECS.