ApsaraMQ for RocketMQ propose un tableau de bord ainsi que des fonctions de surveillance et d'alerte. Ces outils vous permettent de surveiller l'état des brokers et les métriques clés à chaque étape de la messagerie. Configurez également des règles d'alerte pour les métriques critiques afin de détecter les anomalies au plus tôt. Cette rubrique explique comment utiliser le tableau de bord et les fonctions de surveillance et d'alerte d'ApsaraMQ for RocketMQ pour gérer les pannes dans ApsaraMQ for RocketMQ. Elle fournit des solutions pour vos opérations quotidiennes de maintenance (O&M) et le dépannage.
Mise en œuvre
Problèmes fondamentaux
Les points suivants décrivent les enjeux majeurs du dépannage :
Comment envoyer des alertes et signaler les exceptions de service.
Comment localiser rapidement les anomalies.
Solutions proposées
Les indicateurs fournis par ApsaraMQ for RocketMQ, tels que les métriques et les traces, incluent les informations d'état à chaque étape de la messagerie ainsi que le débit des brokers et des ressources ApsaraMQ for RocketMQ. On peut classer les métriques dans les catégories suivantes :
-
Métriques de niveau 1 : Utilisez comme métriques de niveau 1 celles qui mesurent le fonctionnement de votre activité métier. Des anomalies sur ces métriques indiquent des problèmes au sein du système métier. Dans la plupart des cas, ces métriques servent de base à la surveillance et aux alertes.
Par exemple, si une limitation de l'instance est déclenchée parce que le nombre de transactions de messagerie par seconde (TPS) dépasse la limite spécifiée, utilisez le TPS comme métrique de surveillance et créez une règle d'alerte pour empêcher efficacement la limitation de l'instance.
-
Métriques de niveau 2 : Utilisez comme métriques de niveau 2 celles qui permettent de localiser les pannes.
Par exemple, l'accumulation de messages indique qu'une panne s'est produite lors de la consommation. Le taux de réussite d'envoi des messages révèle si des exceptions surviennent pendant l'envoi.
Métriques de niveau 3 : Ces métriques permettent d'analyser plus en détail les métriques de niveau 2. Elles aident à identifier les causes des variations observées sur les métriques de niveau 2.
Solution pour les exceptions de consommation
-
Utilisez la métrique
ConsumerLagLatencyPerGidTopic, qui indique le temps de latence du traitement des messages, comme métrique de surveillance et créez une règle d'alerte. Pour plus d'informations, consultez Surveillance et alerte.Cette métrique reflète l'état de santé du système de consommation et peut influencer l'impact sur l'activité métier. Elle fournit davantage d'informations que le simple nombre de messages accumulés.
Si le volume de messages est faible, le nombre de messages accumulés peut ne pas déclencher d'alertes même en cas de problème.
Si le volume de messages est élevé, le nombre de messages accumulés peut générer de fausses alertes.
Si le nombre de messages fluctue fortement, il est difficile de configurer avec précision le seuil d'alerte pour l'accumulation de messages.
-
Vérifiez si la métrique
rocketmq_process_time(qui indique le temps consommé pour le traitement des messages) et la métriquerocketmq_process_time_count{invocation_status="success"/invocation_status="success | failure"}(qui indique le taux de réussite du traitement des messages) sont normales. Cela permet de déterminer si l'exception provient du client consommateur.Le taux de réussite du traitement des messages est calculé selon la formule suivante : Taux de réussite = Nombre de traitements réussis / (Nombre d'échecs de traitement + Nombre de traitements réussis).
Accédez à la page Dashboard dans la console ApsaraMQ for RocketMQ pour consulter les statistiques des métriques précédentes. Pour plus d'informations sur le tableau de bord, consultez Tableau de bord.
Identifiez la cause spécifique en vous appuyant sur la logique métier ou la tendance d'évolution des métriques. Par exemple, si la durée de traitement des messages augmente, vérifiez si la mémoire et le CPU du service consommateur sont surchargés. Vous pouvez également examiner l'état d'exécution de la logique métier en aval dont dépend la logique de consommation pour approfondir l'analyse.
Solution pour les exceptions de production
-
Vérifiez si la métrique
rocketmq_send_cost_time_count{invocation_status="success"/invocation_status="success | failure"}, qui indique le taux de réussite de l'envoi des messages, est normale. Ce taux est calculé selon la formule suivante : Taux de réussite d'envoi = Nombre d'envois réussis / (Nombre d'échecs d'envoi + Nombre d'envois réussis).Accédez à la page Dashboard dans la console ApsaraMQ for RocketMQ pour consulter les statistiques de cette métrique. Pour plus d'informations sur le tableau de bord, consultez Tableau de bord.
Vérifiez si le réseau fonctionne correctement ou si un échec de transmission ponctuel est dû au redémarrage d'un broker.