Utiliser les journaux de requêtes lentes pour diagnostiquer les problèmes de délai d'expiration - Tair (Redis® OSS-Compatible)

Les requêtes lentes constituent une cause fréquente de délais d'expiration des connexions, ce qui affecte la qualité de service de Tair (Redis OSS-compatible). Le système de journalisation des requêtes lentes de Tair (Redis OSS-compatible) enregistre chaque requête lente ainsi que l'adresse IP du client à l'origine de celle-ci. Vous pouvez ainsi identifier à la fois la requête et sa source. Suivez la procédure décrite dans cette rubrique pour localiser la cause d'un délai d'expiration et utilisez les autres méthodes de dépannage si les journaux de requêtes lentes n'expliquent pas le problème.

Méthodes de consultation

Type	Méthode
Journal des requêtes lentes du nœud de données	Connectez-vous à l'instance depuis un client et exécutez la commande SLOWLOG GET. Pour plus de détails, consultez SLOWLOG GET. Utilisez la console ou appelez une opération API : Interroger les journaux de requêtes lentes DescribeSlowLogRecords
Journal des requêtes lentes du nœud proxy	Utilisez la console ou appelez une opération API : Interroger les journaux de requêtes lentes DescribeSlowLogRecords

Choisir une méthode de dépannage

Les journaux de requêtes lentes constituent la méthode principale pour diagnostiquer les problèmes de délai d'expiration, mais ils ne couvrent pas toutes les causes possibles. Faites correspondre les symptômes observés à la méthode de dépannage appropriée décrite dans cette rubrique.

Condition observable	Méthode
Un délai d'expiration du service se produit	Commencez par consulter le journal des requêtes lentes du nœud proxy, puis vérifiez le journal des requêtes lentes du nœud de données. Consultez la section Analyser les journaux de requêtes lentes pour identifier la cause du délai d'expiration.
Un délai d'expiration du service se produit et l'instance utilise l'architecture standard	Ignorez le journal des requêtes lentes du nœud proxy et analysez directement le journal des requêtes lentes du nœud de données. Consultez la section Analyser les journaux de requêtes lentes pour identifier la cause du délai d'expiration.
Le journal des requêtes lentes du nœud proxy est vide et l'instance est accessible via un réseau public (Internet)	Vérifiez la liaison réseau entre le client et l'instance. Consultez la section Diagnostiquer la latence de connexion sur réseau public.
Les requêtes de lecture sur une clé sont très fréquentes, mais chacune s'exécute plus rapidement que le seuil défini par `slowlog-log-slower-than`, elles ne sont donc pas enregistrées dans le journal des requêtes lentes	Consultez la section Limites des journaux de requêtes lentes et d'audit pour le dépannage des clés chaudes.
L'analyse des journaux de requêtes lentes et la vérification de la connexion réseau publique n'identifient pas la cause	Consultez la section Poursuivre le dépannage côté VPC, ECS et application.

Vérifier d'abord les performances côté serveur

Le journal des requêtes lentes n'enregistre que les requêtes dépassant le seuil configuré. Avant de déterminer si un délai d'expiration provient d'une requête lente ou d'un problème réseau, confirmez si l'instance elle-même présente un goulot d'étranglement au niveau des performances.

Exécuter l'inspection AI Instance Inspection

Sur la page du produit, cliquez sur AI Instance Inspection.
Sélectionnez les huit éléments d'inspection et cliquez sur Start Inspection.
Examinez le rapport d'inspection généré pour détecter toute anomalie concernant l'état de l'instance, la sécurité, la haute disponibilité (HA), les performances des nœuds de données, les performances des nœuds proxy, les journaux de requêtes lentes, les conditions liées aux clés volumineuses et aux clés chaudes, ainsi que les alertes d'événements.

Consulter la surveillance des performances

Sur la page du produit, cliquez sur Performance Monitoring.
Basculez vers la vue Data Node ou Proxy Node, puis examinez l'utilisation du CPU, le nombre de requêtes par seconde (QPS), le temps de réponse moyen (RT) ainsi que les débits du trafic entrant et sortant.
Utilisez les métriques de chaque nœud pour déterminer si l'instance rencontre un problème de performance.

Analyser les journaux de requêtes lentes pour identifier la cause du délai d'expiration

Les délais d'expiration des services peuvent avoir des causes complexes, mais ils sont souvent liés à des requêtes lentes. Suivez ces étapes pour diagnostiquer les problèmes de délai d'expiration.

Lorsqu'un délai d'expiration du service se produit, commencez par vérifier le journal des requêtes lentes du nœud proxy. Pour obtenir des instructions, consultez Interroger les journaux de requêtes lentes.
Remarque
- Si votre instance utilise l'architecture standard, passez directement à l'Étape 3 pour analyser le journal des requêtes lentes du nœud de données.
- Si le journal des requêtes lentes du nœud proxy est vide, vérifiez la connexion réseau entre le client et l'instance. Si l'instance est accessible via un réseau public (Internet), consultez la section Diagnostiquer la latence de connexion sur réseau public ci-dessous.
Identifiez la commande à partir de la première entrée du journal des requêtes lentes du nœud proxy.

Remarque
Les journaux des requêtes lentes du nœud proxy sont généralement générés lorsque des requêtes lentes sur un nœud de données provoquent une accumulation de commandes.

Dans cet exemple, la première entrée du journal des requêtes lentes est générée par une commande KEYS. L'adresse IP figurant dans l'enregistrement du journal correspond à l'adresse IP du client ayant envoyé la commande.

Sur la page Slow Logs, cliquez sur l'onglet Proxy Node pour afficher le journal des requêtes lentes du nœud proxy. Dans cet exemple, le tableau affiche cinq enregistrements : un pour une commande KEYS et quatre pour des commandes SET, avec des temps d'exécution compris entre 64 048 et 88 861 microsecondes.
Vérifiez le journal des requêtes lentes du nœud de données pour voir si la commande identifiée dans le journal du proxy y apparaît également, ce qui permettrait de la confirmer comme cause racine.

Remarque
En règle générale, la commande qui génère la première entrée de journal des requêtes lentes sur un nœud proxy génère également une entrée sur un nœud de données. Le journal des requêtes lentes du nœud de données contient généralement moins d'entrées que celui du nœud proxy, car les deux journaux définissent le temps d'exécution différemment et utilisent des seuils de requêtes lentes distincts.

Dans cet exemple, la comparaison des deux journaux révèle qu'une entrée pour la commande KEYS existe dans les deux. L'absence des autres commandes du journal du proxy dans le journal du nœud de données confirme que la commande KEYS est la cause racine.

Sur la page Slow Logs, cliquez sur l'onglet Data Node pour afficher le journal des requêtes lentes du nœud de données. Dans cet exemple, seule une entrée de journal des requêtes lentes pour la commande KEYS apparaît. Son temps d'exécution élevé confirme que cette commande est la cause racine du délai d'expiration.
Dans le journal des requêtes lentes du nœud proxy, recherchez la commande identifiée à l'étape précédente pour trouver l'adresse IP du client source. Optimisez ensuite l'application cliente. Si l'analyse des journaux de requêtes lentes et la vérification de la connexion réseau publique n'identifient pas la cause, consultez la section Poursuivre le dépannage côté VPC, ECS et application.

Limites des journaux de requêtes lentes et d'audit pour le dépannage des clés chaudes

Le paramètre slowlog-log-slower-than définit le seuil pour le journal des requêtes lentes du nœud de données. La valeur par défaut est de 20 000 microsecondes (20 ms). Les requêtes de lecture très fréquentes, mais dont l'exécution individuelle est plus rapide que ce seuil, ne sont pas enregistrées. Par conséquent, le journal des requêtes lentes par défaut ne peut pas capturer les requêtes de lecture à l'origine d'un problème de clé chaude. Si vous suspectez un problème de clé chaude, abaissez la valeur de slowlog-log-slower-than afin d'enregistrer davantage de requêtes et d'identifier la source des requêtes de lecture à haute fréquence. Pour obtenir des instructions, consultez Interroger les journaux de requêtes lentes.

Une fois les journaux d'audit activés, seules les opérations d'écriture sont enregistrées. Les opérations de lecture ne le sont pas. Il est donc impossible d'utiliser les journaux d'audit pour afficher les adresses IP des clients effectuant des requêtes de lecture sur une clé chaude. Pour localiser ces adresses IP, abaissez le seuil slowlog-log-slower-than et examinez les journaux de requêtes lentes résultants. Pour plus d'informations sur la fonctionnalité de journal d'audit, consultez Présentation des journaux d'audit. Si le problème de clé chaude est causé par des requêtes d'écriture, utilisez plutôt la fonctionnalité de requête de clés chaudes basée sur les journaux d'audit. Pour obtenir des instructions, consultez Interroger les clés chaudes historiques.

Diagnostiquer la latence de connexion sur réseau public

Si les métriques côté serveur n'indiquent aucun goulot d'étranglement au niveau des performances (CPU, mémoire et connexions sont normaux, et le journal des requêtes lentes est vide), mais que le client signale toujours des erreurs de délai d'expiration de connexion, vérifiez la liaison réseau entre le client et l'instance.

Symptômes courants

Le client signale des erreurs telles que socket error, read error ou connection timeout, tandis que les métriques côté serveur de l'instance (CPU, mémoire et connexions) sont normales et que le RT est faible.

Cause principale

La liaison réseau public entre le client et l'instance est instable, et la transmission interrégionale ajoute de la latence. Ces deux effets sont plus prononcés dans les scénarios d'accès transfrontalier.

Recommandations

Utilisez une connexion réseau interne pour les charges de travail métier critiques au lieu de compter sur une liaison réseau public.
Pour les déploiements interrégionaux, utilisez Cloud Enterprise Network (CEN) pour connecter les VPC entre les régions et obtenir une connectivité réseau interne stable à faible latence. Pour obtenir des instructions, consultez Gérer les connexions interrégionales.
Côté client, augmentez les valeurs de délai d'expiration de connexion et de délai d'expiration en lecture/écriture, et implémentez une logique de nouvelle tentative pour gérer les fluctuations du réseau. Pour connaître les solutions aux erreurs de délai d'expiration courantes, consultez Erreurs courantes et dépannage.

Poursuivre le dépannage côté VPC, ECS et application

Si l'analyse des journaux de requêtes lentes et la vérification de la connexion réseau publique n'identifient pas la cause, utilisez les informations relatives au VPC, à l'ECS et à l'application pour réduire le périmètre de recherche.

Récupérez l'ID du VPC et l'ID du vSwitch depuis la page du produit.
Vérifiez si l'instance ECS rencontrant des lenteurs ou des délais d'expiration présente des anomalies et si le moment coïncide avec une modification de l'application.
Si le moment coïncide avec une modification de l'application, annulez la modification ou enquêtez pour trouver des indices. Utilisez l'ID du VPC et l'ID du vSwitch pour poursuivre le dépannage dans la console VPC ou ECS.