Créer un rapport de diagnostic - Tair (Redis® OSS-Compatible)

Décrit comment exécuter le diagnostic d'une instance et interpréter les rapports de diagnostic, notamment les métriques de performance, la distribution déséquilibrée des requêtes et les requêtes lentes.

Effectuer un diagnostic sur une instance

Tair (Redis OSS-compatible) intègre la fonctionnalité de rapport de diagnostic du service Database Autonomy Service (DAS). Cette fonctionnalité vous permet de créer un rapport de diagnostic pour évaluer l'état d'une instance sur une période donnée. Les rapports de diagnostic collectent des métriques telles que le niveau de performance, la distribution déséquilibrée des requêtes et les journaux de requêtes lentes afin de vous aider à identifier les anomalies au sein de l'instance.

Procédure

Connectez-vous à la console et accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où se trouve l'instance que vous souhaitez gérer. Localisez ensuite l'instance et cliquez sur son ID.
Dans le volet de navigation de gauche, choisissez CloudDBA > Diagnostic Reports.
Cliquez sur Create Reports.
Dans la boîte de dialogue qui s'affiche, spécifiez la plage de temps pour laquelle vous souhaitez créer un rapport de diagnostic, puis cliquez sur OK.

Remarque
La plage de temps ne peut pas dépasser une journée. Si vous spécifiez une plage de temps plus courte pour le diagnostic, le rapport de diagnostic collecte des statistiques plus détaillées.
Actualisez la page Diagnostic Report pour afficher la progression de la tâche de diagnostic. Une fois le rapport de diagnostic créé, cliquez sur View Report dans la colonne Actions.

Remarque
Pour plus d'informations sur l'interprétation d'un rapport de diagnostic, consultez

et

Comprendre un rapport de diagnostic d'instance

.

Comprendre un rapport de diagnostic d'instance

Un rapport de diagnostic évalue la santé d'une instance ApsaraDB for Redis en analysant les métriques de performance, la distribution des requêtes et les données de requêtes lentes. Utilisez-le pour identifier les anomalies et y remédier avant qu'elles n'affectent votre activité.

Sections du rapport

Un rapport de diagnostic comprend quatre sections :

Informations de base sur l'instance : l'ID de l'instance, le type d'instance, la version du moteur et la zone de déploiement de l'instance
Résumé : le score de santé de l'instance et le détail des déductions
Niveau de performance : l'état actuel des principales métriques de performance
10 principaux nœuds recevant le plus grand nombre de requêtes lentes : les 10 principaux nœuds de données par nombre de requêtes lentes, avec des détails sur ces requêtes

Informations de base sur l'instance

Affiche l'ID de l'instance, le type d'instance, la version du moteur et la région de déploiement de l'instance.

La période de diagnostic s'étend du 1er mars 2021 à 11:10:23 au 1er mars 2021 à 14:10:23. Les informations de base sur l'instance incluent les champs suivants :

Instance ID : l'ID de l'instance et le nom de l'instance (suffixe d'exemple : « -Diagnostic Report Test »)
Specification : 2 GB Cluster Edition (2 nodes)
Instance type : Redis 5.0
Zone : China (Hangzhou)

Résumé

Affiche le score de santé global de l'instance. Le score maximum est de 100. Les scores inférieurs à 100 indiquent les éléments de diagnostic ayant entraîné des déductions et expliquent les raisons.

Le score de santé est de 70 sur 100. Les éléments suivants ont entraîné des déductions :

High CPU utilization : l'utilisation du CPU a atteint 85,9 %, dépassant le seuil de sécurité. 10 points déduits.
High memory usage : l'utilisation de la mémoire a atteint 100,0 %, dépassant le seuil de sécurité. 10 points déduits.
Slow log access : 12 entrées de journal de requêtes lentes enregistrées sur le serveur. 10 points déduits.

Niveau de performance

Affiche l'état actuel des principales métriques de performance. Portez une attention particulière à toute métrique dont l'état est Hazard ; des valeurs soutenues supérieures au seuil peuvent réduire le débit et augmenter la latence.

Pour les instances exécutées dans une architecture de cluster ou une architecture de répartition lecture/écriture, vérifiez si les métriques sont réparties de manière inégale entre les nœuds de données. Examinez les graphiques de courbe Top 5 Nodes pour chaque métrique afin d'identifier les nœuds subissant la charge la plus élevée. Pour plus de détails sur l'architecture, consultez Cluster master-replica instances et Read/write splitting instances .

Performance level

Le tableau suivant décrit chaque métrique, son seuil, l'impact commercial en cas de dépassement de ce seuil et la procédure de dépannage.

Metric	Threshold	Applies to	Impact	Possible causes and next steps
CPU utilization	60 %	All architectures	Une utilisation élevée du CPU réduit le débit et augmente le temps de réponse. Les clients peuvent devenir indisponibles.	Causes : commandes à haute complexité, hotkeys ou création fréquente de connexions. Consultez Résoudre une utilisation élevée du CPU sur une instance.
Memory usage	80 %	All architectures	Une utilisation élevée et soutenue de la mémoire augmente le temps de réponse, déstabilise les requêtes par seconde (QPS) et déclenche une éviction fréquente des clés.	Causes : épuisement de la mémoire ou grand nombre de grandes clés. Consultez Résoudre une utilisation élevée de la mémoire sur une instance.
Connections usage of data nodes	80 %	Instances de cluster en mode de connexion directe uniquement. Lorsque les clients se connectent via des nœuds proxy, surveillez les connexions au niveau du nœud proxy. Consultez Activer le mode de connexion directe et Afficher les données de surveillance des performances.	Lorsque les connexions atteignent la limite, les nouvelles demandes de connexion expirent ou échouent.	Causes : pics de trafic ou connexions inactives non libérées. Consultez Sessions d'instance.
Inbound traffic	80 %	All architectures	Lorsque le trafic dépasse la bande passante fournie par le type d'instance, les performances du client se dégradent.	Causes : pics de charge de travail ou grandes clés lues ou écrites fréquemment. Consultez Résoudre une utilisation élevée du trafic sur une instance.
Outbound traffic	80 %	All architectures

Distribution déséquilibrée des requêtes

Pour les instances exécutées dans une architecture de cluster ou une architecture de répartition lecture/écriture, le rapport vérifie également si les requêtes sont réparties uniformément entre les nœuds de données. Si des requêtes déséquilibrées sont détectées pour une métrique, identifiez quels nœuds reçoivent la charge déséquilibrée.

Le rapport signale une distribution déséquilibrée des requêtes lorsque les deux conditions suivantes sont réunies :

Les valeurs de pointe sur tous les nœuds de données dépassent les seuils minimaux ci-dessous :
- Utilisation du CPU : 10 %
- Utilisation de la mémoire : 20 %
- Trafic entrant et sortant : 5 Mbit/s
- Utilisation des connexions : 5 %
Le score d'équilibre dépasse 1,3. Le score d'équilibre est calculé comme suit : max{average performance value of all data nodes} / median performance value of all data nodes. Par exemple, une instance dispose de quatre nœuds de données avec une utilisation moyenne du CPU de 10 %, 30 %, 50 % et 60 %. La médiane est de 40 %, et le score d'équilibre est de 60 % / 40 % = 1,5. Comme 1,5 > 1,3, le rapport considère que l'utilisation du CPU est déséquilibrée.

Cause possible	Méthode de dépannage
Un nœud de données contient un nombre excessif de grandes clés.	Utilisez la fonctionnalité d'analyse hors ligne des clés ou la fonctionnalité de statistiques des clés principales pour les identifier et les redistribuer.
Un nœud de données contient des hotkeys.	Utilisez la fonctionnalité de statistiques des clés principales pour identifier les hotkeys.
Les hash tags sont mal configurés. Les clés partageant le même hash tag sont toujours placées sur le même nœud de données. Si de nombreuses clés partagent un hash tag, ce nœud devient surchargé.	Vérifiez et ajustez votre configuration de hash tag pour répartir les clés entre les nœuds.

10 principaux nœuds recevant le plus grand nombre de requêtes lentes

Répertorie les 10 principaux nœuds de données par nombre de requêtes lentes et fournit des détails sur ces requêtes. Le rapport s'appuie sur deux sources de données de journal des requêtes lentes :

Journaux d'audit système : journaux de requêtes lentes conservés pendant 4 jours
Journaux des nœuds de données : les 1 024 dernières entrées de journal, stockées directement sur chaque nœud de données. Connectez-vous à l'instance à l'aide de redis-cli et exécutez la commande SLOWLOG GET pour les récupérer.

Deux nœuds, r-bp-db-0 et r-bp-db-1, comptent chacun 6 requêtes lentes. Les principales commandes de requêtes lentes et leurs durées d'exécution sont les suivantes :

keys * : temps d'exécution maximal d'environ 86 ms, moyenne d'environ 86 ms
keys key:0000001* : temps d'exécution maximal d'environ 62 ms, moyenne d'environ 59 ms
Plusieurs commandes del : temps d'exécution d'environ 12–18 ms

Utilisez les données de requêtes lentes pour identifier les commandes à l'origine des problèmes de performance.

Cause	Solution
Commandes avec une complexité temporelle O(N) ou un coût CPU élevé, telles que `KEYS *`	Évaluez et désactivez les commandes à haut risque telles que `FLUSHALL`, `KEYS` et `HGETALL`. Consultez Désactiver les commandes à haut risque.
Grandes clés lues ou écrites fréquemment sur les nœuds de données	Analysez les grandes clés à l'aide de la fonctionnalité d'analyse hors ligne des clés, puis divisez-les en fonction de vos besoins métier.