Tous les produits
Search

Ce produit

    Tair (Redis® OSS-Compatible):Consulter les données de surveillance des performances

    Centre de documentation

    Tair (Redis® OSS-Compatible):Consulter les données de surveillance des performances

    Dernière mise à jour :Aug 08, 2026

    Tair (compatible avec Redis OSS) suit en temps réel les indicateurs clés de santé des instances : utilisation du CPU, utilisation de la mémoire, latence moyenne et nombre de requêtes par seconde (QPS). Utilisez la page Performance Monitoring pour analyser les tendances sur n'importe quelle période du dernier mois et détecter les problèmes avant qu'ils n'affectent votre application.

    Métriques de surveillance

    La page Performance Monitoring propose les métriques suivantes :

    Métrique Description
    Utilisation du CPU Pourcentage de la capacité CPU utilisée par l'instance
    Utilisation de la mémoire Quantité de mémoire consommée par l'instance
    Latence moyenne Temps moyen de traitement d'une commande
    QPS (requêtes par seconde) Nombre total de commandes traitées par seconde

    Afficher les données de surveillance

    1. 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 votre instance. Recherchez l'instance et cliquez sur son ID.

    2. Dans le volet de navigation de gauche, cliquez sur Performance Monitoring.

    3. Sélectionnez une plage de temps. Les graphiques de tendance se mettent à jour pour afficher les données correspondantes.

      La plage de temps maximale par requête est de trois jours. La granularité des données dans les graphiques de tendance s'ajuste automatiquement en fonction de la plage sélectionnée.

    4. Interprétez les données en fonction de l'architecture de votre instance :

      Architecture Onglets disponibles Mode d'agrégation des métriques
      Maître-réplica (vue par défaut) Concentrez-vous sur les métriques du nœud maître
      Cluster All, Data Node L'onglet All affiche les données agrégées de tous les nœuds réplicas ou des réplicas en lecture (l'utilisation du CPU correspond à la moyenne sur tous les nœuds ; certaines métriques utilisent la somme)
      Séparation lecture/écriture All, Data Node L'onglet All agrège les nœuds réplicas ; les métriques des réplicas en lecture ne sont pas agrégées
      Toute architecture avec des nœuds proxy All, Proxy Node L'onglet All affiche les performances globales du proxy ; l'onglet Proxy Node affiche les métriques par proxy

    FAQ

    Pourquoi les réplicas en lecture affichent-ils un QPS en écriture après l'activation de la séparation lecture/écriture ?

    Le QPS en écriture sur les réplicas en lecture ne provient pas des requêtes d'écriture des clients. Il reflète les opérations d'écriture effectuées lors de la synchronisation des données du nœud maître vers les réplicas en lecture.

    Pourquoi le nombre de connexions affiche-t-il 0 pour les instances de type cluster ?

    En mode proxy, les nœuds de données affichent 0 connexion, car ces connexions sont internes : elles s'exécutent entre les nœuds proxy et les nœuds de données, sont réutilisées et leur moyenne se situe généralement entre 0 et 2. Pour voir les connexions client réelles, consultez les métriques des nœuds proxy dans l'onglet Proxy Node. Vous pouvez ignorer le nombre de connexions sur les nœuds de données.

    Pourquoi mon instance ne dispose-t-elle pas d'une métrique de taux d'utilisation du QPS ?

    Les instances de cluster cloud-native fournissent uniquement la valeur absolue du QPS (commandes par seconde) comme métrique de surveillance, et non un taux d'utilisation du QPS. En effet, les instances de cluster cloud-native n'ont pas de limite supérieure stricte en matière de QPS. La valeur de référence est d'environ 100 000 commandes par seconde, mais le débit réel peut être plus élevé selon les caractéristiques de la charge de travail. Pour évaluer la charge de l'instance, nous vous recommandons de surveiller plutôt l'utilisation du CPU, l'utilisation de la mémoire et l'utilisation de la bande passante.

    Pourquoi la métrique de latence P99 apparaît-elle après la mise à niveau vers une nouvelle version du proxy ?

    Les nouveaux nœuds proxy prennent en charge les statistiques de latence P99, alors que les versions précédentes du proxy ne collectaient pas cette métrique. Si vous constatez que la métrique de latence P99 passe de « indisponible » à « disponible », ou de 0 à une valeur non nulle après une mise à niveau, il s'agit d'un comportement attendu. Cela indique que la nouvelle version collecte correctement les données de latence et ne représente pas une dégradation des performances. De plus, lors de la vérification des connexions de l'instance, consultez le nombre de connexions sur les nœuds proxy plutôt que sur les nœuds de données. Le nombre de connexions des nœuds de données ne reflète pas les connexions client réelles.

    Pourquoi le nombre de connexions utilisées affiche-t-il 1 dans la surveillance des performances alors que la surveillance des sessions indique 0 connexion client ?

    Lorsque la surveillance des sessions indique que le nombre de connexions client est de 0, mais que le nombre de connexions utilisées (Counts, Sum) dans Performance Monitoring affiche constamment 1, cette connexion est une connexion interne de maintenance (O&M) ou de heartbeat, et non une connexion métier externe. La métrique du nombre de connexions utilisées inclut les connexions internes telles que les connexions O&M et de heartbeat. Pour distinguer les connexions métier des connexions internes, consultez les données de surveillance des sessions.

    Référence API

    Opération API Description
    DescribeHistoryMonitorValues Interroge l'historique de surveillance des performances d'une instance

    Étapes suivantes

    Si les données de surveillance révèlent un problème de performance, les rubriques suivantes peuvent vous aider à le diagnostiquer et à le résoudre :