AnalyticDB:Surveillance

Aperçu de la FAQ

• Comment surveiller l'utilisation du disque pour un cluster Data Warehouse Edition en mode réservé ?

• Comment consulter l'espace de stockage occupé par les données chaudes et froides ?

• Comment vérifier des informations telles que la taille des tables ?

• Pourquoi l'utilisation des données chaudes est-elle supérieure à l'utilisation totale du disque sur la page Informations de surveillance ?

• Pourquoi l'utilisation moyenne du CPU augmente-t-elle après le passage d'un cluster du mode réservé au mode élastique ?

• Pourquoi la page Informations de surveillance affiche-t-elle un temps de réponse élevé pour les requêtes, alors qu'aucune instruction SQL longue ne figure sur la page Diagnostic et optimisation ?

Surveiller l'utilisation du disque en mode réservé

Configurez la surveillance et les alertes afin d'éviter que l'utilisation du disque ne dépasse le seuil de sécurité. Vous recevrez ainsi des notifications en temps utile pour gérer l'espace disque et maintenir la stabilité du service.

1. Connectez-vous à la console AnalyticDB for MySQL. Dans le coin supérieur gauche de la console, sélectionnez une région. Dans le volet de navigation de gauche, cliquez sur Clusters. Localisez le cluster à gérer et cliquez sur son ID.

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

3. Sur la page Monitoring Information, cliquez sur l'onglet Query and Write pour afficher l'utilisation du disque.

   En mode réservé, l'utilisation du disque s'affiche sous forme de pourcentage. En mode élastique, l'utilisation absolue du disque des nœuds de lecture/écriture est affichée.

   • Mode réservé

     Remarque

     L'utilisation maximale du disque correspond à la valeur la plus élevée parmi tous les nœuds du cluster. Si cette valeur atteint 90 % ou plus, les opérations d'écriture sont verrouillées. Surveillez attentivement cette métrique.

   • Mode élastique

     Remarque

     L'utilisation du disque fait référence à l'utilisation maximale du disque d'un seul nœud de lecture/écriture. Si cette valeur atteint 8 To ou plus, vous ne pouvez plus écrire de données dans le cluster. Surveillez attentivement cette métrique.

4. Sur la page Monitoring Information, cliquez sur Alert Rule Settings.

5. Sur la page Alert Rules, cliquez sur Create Alert Rules.

6. Sur la page Create Alert Rule, configurez les paramètres.

   Paramètre	Description
   Resource Range	La portée de la règle d'alerte. Valeurs possibles : All Resources : Cette option applique la règle à toutes les instances d'un produit sous votre compte. Par exemple, si vous définissez une alerte déclenchée lorsque l'utilisation du disque de AnalyticDB for MySQL est supérieure ou égale à 80 %, la règle s'applique à toutes les instances AnalyticDB for MySQL. Lorsque Resource Range est défini sur All Resources, les alertes peuvent être déclenchées pour un maximum de 1 000 ressources. Si le nombre de ressources dépasse 1 000, les alertes risquent de ne pas être déclenchées même si le seuil est atteint. Nous vous recommandons d'utiliser des groupes d'applications pour regrouper les ressources par activité métier avant de configurer les alertes. Application Group : La règle d'alerte s'applique à toutes les ressources d'un groupe d'applications spécifié pour le produit. Instance : La règle s'applique uniquement à des instances spécifiques du produit. Par exemple, si vous définissez une alerte au niveau de l'instance pour une utilisation du disque supérieure ou égale à 80 %, une notification est envoyée lorsque l'utilisation du disque de cette instance spécifique atteint ou dépasse le seuil.
   Rule Description	Les conditions qui déclenchent l'alerte. Pour configurer la description de la règle : Cliquez sur Add Rule. Dans le panneau Add Rule Description, définissez des paramètres tels que Rule Name, Metric Type, Monitoring Metric, Threshold and Alert Level et Chart Preview. Cliquez sur OK.
   Mute Period	L'intervalle entre les notifications répétées pour une alerte non résolue. Valeurs possibles : 5 minutes, 15 minutes, 30 minutes, 60 minutes, 3 heures, 6 heures, 12 heures et 24 heures. Lorsqu'une métrique atteint le seuil d'alerte, une alerte est envoyée. Si la métrique continue de dépasser le seuil pendant la période de mise en sourdine, aucune notification répétée n'est envoyée. Si la condition n'est pas résolue à la fin de la période de mise en sourdine, CloudMonitor envoie une autre notification d'alerte.
   Effective Time	La période pendant laquelle la règle d'alerte est active. Important Pour les alertes d'utilisation du disque, chaque contact d'alerte est notifié au maximum quatre fois par jour. Les alertes suivantes sont mises en sourdine.
   Alert Contact Group	Le groupe de contacts qui reçoit les notifications d'alerte. Les notifications pour les groupes d'applications sont envoyées aux contacts de ce groupe de contacts d'alerte. Un groupe de contacts d'alerte peut contenir un ou plusieurs contacts d'alerte. Pour savoir comment créer des contacts et des groupes de contacts d'alerte, consultez la section Créer un contact ou un groupe de contacts d'alerte.
   Alert Callback	Une URL accessible publiquement. CloudMonitor pousse les informations d'alerte vers cette URL via des requêtes POST. Seul le protocole HTTP est pris en charge. Pour savoir comment configurer un rappel d'alerte, consultez la section Utiliser les rappels d'alerte basés sur des seuils. Remarque Cliquez sur Advanced Settings pour configurer ce paramètre.
   Auto Scaling	Si vous activez Auto Scaling, la règle de mise à l'échelle correspondante est déclenchée lorsqu'une alerte se produit. Vous devez spécifier la Region, le ESS Group et la ESS Rule pour Auto Scaling. Pour savoir comment créer un groupe de mise à l'échelle, consultez la section Configurer un groupe de mise à l'échelle. Pour savoir comment créer une règle de mise à l'échelle, consultez la section Configurer une règle de mise à l'échelle. Remarque Cliquez sur Advanced Settings pour configurer ce paramètre.
   Simple Log Service	Si vous activez Simple Log Service, les informations d'alerte sont écrites dans Log Service lorsqu'une alerte se produit. Vous devez spécifier la Region, le Project et le Logstore pour Log Service. Pour savoir comment créer un Project et un Logstore, consultez la section Collecter et analyser les journaux texte ECS à l'aide de LoongCollector. Remarque Cliquez sur Advanced Settings pour configurer ce paramètre.
   Simple Message Queue (formerly MNS) - Topic	Si vous activez Simple Message Queue (formerly MNS) - Topic, les informations d'alerte sont envoyées à un topic spécifié dans Message Service. Vous devez spécifier la région et le topic pour Message Service. Pour savoir comment créer un topic, consultez la section Créer un topic.
   Method for handling alerts when no monitoring data is available	L'action à effectuer lorsque les données de surveillance ne sont pas disponibles pour une règle d'alerte. Valeurs possibles : Do not do anything (par défaut) Send alert notifications Consider as recovered Remarque Cliquez sur Advanced Settings pour configurer ce paramètre.
   Tag	Ajoute des paires clé-valeur personnalisées en tant que tags au contenu de l'alerte.

7. Une fois les paramètres configurés, cliquez sur OK.

Afficher le stockage des données chaudes et froides

Connectez-vous à la console AnalyticDB for MySQL. Sur la page Monitoring Information, vous pouvez afficher les valeurs Hot Data Space Used et Cold Data Space Used.

Vérifier la taille des tables

Connectez-vous à la console AnalyticDB for MySQL. Sur la page Monitoring Information de votre cluster, cliquez sur l'onglet Table Information Statistics pour afficher des informations telles que la taille des tables.

Utilisation des données chaudes par rapport à l'utilisation totale du disque

Un cluster AnalyticDB for MySQL contient plusieurs nœuds de stockage. L'utilisation du disque représente l'utilisation maximale du disque d'un seul nœud de lecture/écriture, tandis que l'utilisation des données chaudes correspond à la somme de l'utilisation du disque de tous les nœuds de lecture/écriture.

Augmentation de l'utilisation du CPU en mode élastique

Lorsque vous faites passer un cluster C32 du mode réservé au mode élastique, le nombre de cœurs d'un seul nœud est réduit à 8. Par défaut, une tâche BUILD occupe 3 cœurs, ce qui entraîne une augmentation de l'utilisation moyenne du CPU. Si cette augmentation n'affecte pas vos services, aucune action n'est requise. Si vos services sont impactés, augmentez la capacité du cluster ou Soumettez un ticket pour contacter le support technique. Pour plus d'informations sur les tâches BUILD, consultez la section BUILD.

Écart dans le temps de réponse des requêtes

Le temps de réponse des requêtes sur la page Monitoring Information et la durée totale sur la page Diagnostics and Optimization sont calculés différemment. Le temps de réponse des requêtes sur la page Monitoring Information inclut également le temps de mise en cache du jeu de résultats. Par conséquent, si une requête renvoie un grand jeu de résultats nécessitant une mise en cache, le temps de réponse sur la page Monitoring Information est plus long que la durée totale indiquée sur la page Diagnostics and Optimization. Vous pouvez utiliser la page SQL Audit pour identifier les instructions SQL dont les temps de réponse sont longs.

Les informations suivantes décrivent le calcul du temps consommé par une instruction SQL :

Après soumission d'une instruction SQL à AnalyticDB for MySQL, celle-ci est d'abord placée dans une file d'attente. Si la concurrence des requêtes est élevée, cela peut entraîner un long temps d'attente. Après avoir quitté la file d'attente, l'instruction entre dans le moteur d'exécution, qui analyse la requête et génère un plan d'exécution ; cette étape constitue le temps de plan d'exécution. Une fois le plan d'exécution généré, des sous-tâches s'exécutent sur les nœuds de stockage et de calcul, ce qui constitue le temps d'exécution. Une fois la requête terminée, si le jeu de résultats est volumineux, le nœud frontal met les résultats en cache, ce qui constitue le temps de mise en cache du jeu de résultats. La figure suivante illustre la répartition temporelle d'une instruction SQL :