Utilisez ApsaraMQ for RocketMQ avec Cloud Monitor pour configurer des règles d'alerte. Vous surveillerez ainsi l'état en temps réel de vos instances et les métriques métier clés, recevrez des notifications rapides en cas d'anomalie et gérerez proactivement les risques dans votre environnement de production.
Informations générales
ApsaraMQ for RocketMQ est un service de messagerie entièrement géré. Chaque spécification d'instance bénéficie d'une garantie SLA claire, qui assure que les métriques telles que le débit (TPS) de messagerie et le stockage des messages respectent les spécifications après l'achat de l'instance.
Bien que vous n'ayez pas à gérer les performances de l'instance, vous devez vérifier si la charge de travail de votre application approche les limites de spécification. ApsaraMQ for RocketMQ s'intègre à Cloud Monitor pour fournir un service de surveillance et d'alerte gratuit et prêt à l'emploi, afin de résoudre les problèmes suivants :
-
Alertes proactives sur les seuils de spécification de l'instance
Si votre utilisation réelle dépasse les limites de spécification de l'instance, ApsaraMQ for RocketMQ applique une limitation stricte du débit. En configurant préalablement des alertes sur ces seuils, vous identifiez les risques de dépassement et mettez à niveau votre instance rapidement pour éviter les interruptions d'activité dues à la limitation.
-
Alertes proactives sur les erreurs de logique métier
Des erreurs peuvent survenir lors de l'envoi ou de la réception de messages. En configurant des alertes sur les erreurs d'appel, vous détectez les anomalies avant que les utilisateurs ne les signalent, ce qui permet d'identifier et de corriger rapidement la source des erreurs.
-
Alertes proactives sur les métriques de performance métier
Si votre intergiciel de messagerie impose des exigences de performance spécifiques, telles que le temps de réponse (RT) ou la latence des messages, la configuration d'alertes sur ces métriques vous aide à gérer proactivement les risques métier.
Principes de configuration des alertes
ApsaraMQ for RocketMQ propose un ensemble complet de métriques et d'éléments de surveillance pour les alertes. Ces éléments se répartissent en trois types d'alertes : seuils opérationnels, performances d'envoi/réception et événements d'erreur.
Fort d'une vaste expérience en production, nous recommandons de configurer les alertes selon les principes suivants :
Les éléments de surveillance clés suivants constituent des recommandations de base. ApsaraMQ for RocketMQ fournit un ensemble complet de métriques de surveillance, ce qui vous permet de configurer des alertes plus granulaires et étendues selon vos besoins métier. Pour plus d'informations, consultez la section Surveillance et alertes.
|
Catégorie |
Alerte clé |
Recommandation |
Rôle |
|
Seuil opérationnel de l'instance et métriques de consommation |
Fréquence des appels API de l'instance |
|
Équipe opérations |
|
Métriques de performance d'envoi/réception de messages |
|
|
|
|
Événements d'erreur d'envoi/réception de messages |
|
|
|
Accéder à la configuration des règles d'alerte
Connectez-vous à la console ApsaraMQ for RocketMQ. Dans le volet de navigation de gauche, cliquez sur Instances.
Dans la barre de navigation supérieure, sélectionnez une région, par exemple China (Hangzhou). Sur la page Instances, cliquez sur le nom de l'instance à gérer.
Dans le volet de navigation de gauche, cliquez sur Monitoring and Alerts puis sur Create Alert Rule.
Bonnes pratiques
Configurer une alerte pour la fréquence des appels API de l'instance
Contexte : Chaque instance ApsaraMQ for RocketMQ possède une limite TPS définie pour les appels API d'envoi et de réception de messages. Par exemple, une instance Standard Edition prend en charge 5 000 appels API par seconde. Si la fréquence des appels API dépasse cette limite, l'instance subit une limitation de débit.
Risque en cas d'absence de configuration : Sans cette alerte, vous ne serez pas averti avant que la limite d'appels API de votre instance ne soit dépassée, ce qui entraînera l'échec de certaines requêtes de messages en raison de la limitation.
Quand configurer : Nous recommandons de configurer cette alerte immédiatement après la création de l'instance.
Définissez le Rule Name sur Instance API call frequency alert. Pour Metric Type, sélectionnez Basic Metrics, et pour Metric, sélectionnez Instance / Instance API call frequency(Instance). Configurez trois niveaux d'alerte : Critical (notification par téléphone, SMS, e-mail et webhook), Warn (notification par SMS, e-mail et webhook) et Info (notification par e-mail et webhook). Pour chaque niveau, définissez la condition de déclenchement après 3 périodes consécutives (1 période = 1 minute) si Sum >= Threshold (unité : count/s). Pour le niveau Critical, saisissez le seuil souhaité.
Seuil recommandé : Nous recommandons de définir le seuil à 70 % du TPS de pointe de l'instance. Par exemple, si votre instance a un TPS de pointe de 10 000, définissez le seuil d'alerte à 7 000. Vous trouverez le TPS de pointe de l'instance sur la page Instance Details dans la console.
-
Gestion des alertes : Si vous recevez une alerte de fréquence d'appels API de l'instance, suivez ces étapes :
Sur la page Instance Details, cliquez sur l'onglet Dashboard.
Dans la section Instance Message Volume Overview, vérifiez la courbe TPS Max value sous Instance Request Count Metrics (Production + Consumption) pour déterminer le modèle temporel lorsque le seuil d'alerte est atteint.
Dans la section Message Business Metrics Overview, examinez les métriques Top 20 Topics by Message Production Rate (messages/minute) et Top 20 GroupIDs by Message Consumption Rate (messages/minute). En vous basant sur le modèle temporel observé lors de l'atteinte du seuil, identifiez le topic et le groupe présentant des données anormales et analysez leurs courbes pour déterminer si la variation du trafic est prévue.
Si la modification métier est anormale, contactez l'équipe métier pour analyser la cause de l'anomalie.
Si l'augmentation du trafic est prévue, cela indique que la spécification de l'instance est insuffisante. Mettez à niveau l'instance immédiatement. Pour obtenir des instructions, consultez la section Mettre à niveau ou rétrograder une instance.
Configurer des alertes pour les taux de production et de consommation de messages
Contexte : ApsaraMQ for RocketMQ prend en charge la surveillance du TPS d'envoi et de réception de messages au niveau des topics et des groupes. Cela vous permet de configurer des alertes pour le TPS d'applications métier spécifiques, afin de suivre l'évolution de l'échelle de votre activité en temps utile.
Risque en cas d'absence de configuration : Sans cette alerte, des baisses ou des pics de trafic peuvent survenir sans avertissement, entraînant des risques métier inattendus.
Quand configurer : Nous recommandons de configurer cette alerte après la mise en production de votre activité et la stabilisation du trafic.
Taux d'envoi du producteur
Dans la boîte de dialogue des paramètres de règle, définissez le Rule Name sur Producer messages sent per minute alert. Pour Metric Type, sélectionnez l'onglet Basic Metrics, et pour Metric, sélectionnez Producer / Number of messages sent per minute(Topic). Configurez trois niveaux d'alerte : Critical (notification par téléphone, SMS, e-mail et webhook), Warn (notification par SMS, e-mail et webhook) et Info (notification par e-mail et webhook). Définissez la condition de déclenchement pour chaque niveau après 3 périodes consécutives (1 période = 1 minute) si Sum >= Threshold (unité : count/m), et saisissez le seuil approprié selon vos besoins métier. Pour Dimension, sélectionnez topic.
Seuil recommandé : Après la mise en production de votre activité, estimez le seuil d'alerte en fonction du volume de trafic stable.
-
Gestion des alertes : Si vous recevez une alerte de TPS d'envoi et de réception de messages, suivez ces étapes :
Sur la page Topics, cliquez sur le nom du topic spécifié dans la règle d'alerte.
Sur la page Topic Details, cliquez sur l'onglet Dashboard.
Dans le graphique Message Volume (messages/minute), vérifiez la courbe Production. Selon votre modèle métier, déterminez si les variations de la courbe sont raisonnables et analysez les éventuelles anomalies.
Taux de réception du consommateur
Dans la boîte de dialogue Set Rule Description, définissez le Rule Name sur Consumer messages received per minute alert. Pour Metric Type, sélectionnez Basic Metrics, et pour Metric, sélectionnez Consumer / Number of messages received per minute(Group). Configurez trois niveaux d'alerte : Critical, Warn et Info. Sélectionnez Sum comme méthode d'agrégation. Définissez la condition de déclenchement après 3 périodes consécutives (1 période = 1 minute) si la valeur est supérieure ou égale au seuil, et saisissez le seuil approprié. Pour Dimension, sélectionnez groupId et spécifiez le groupe de consommateurs cible.
Seuil recommandé : Après la mise en production de votre activité, estimez le seuil d'alerte en fonction du volume de trafic stable.
-
Gestion des alertes : Si vous recevez une alerte de TPS d'envoi et de réception de messages, suivez ces étapes :
Sur la page Groups, cliquez sur le Group ID spécifié dans la règle d'alerte.
Sur la page Group Details, cliquez sur l'onglet Dashboard.
Dans le graphique Trend of Message Production and Consumption Rate (messages/minute), vérifiez la courbe Consumption. Selon votre modèle métier, déterminez si les variations de la courbe sont raisonnables et analysez les éventuelles anomalies.
Configurer une alerte pour l'accumulation de messages
Les statistiques d'accumulation de messages peuvent être volatiles et sujettes aux erreurs. Nous ne recommandons pas de définir un seuil de surveillance pour une accumulation de seulement quelques dizaines de messages. Si votre activité est très sensible même à de petites accumulations, nous suggérons d'utiliser plutôt le seuil de latence de consommation pour la surveillance.
Contexte : ApsaraMQ for RocketMQ prend en charge la surveillance de l'accumulation de messages au niveau du groupe de consommateurs, ce qui permet d'alerter en cas de retard de consommation en aval.
L'alerte sur l'accumulation de messages est une fonctionnalité clé d'ApsaraMQ for RocketMQ. Cependant, pour les scénarios nécessitant un traitement de messages en temps réel, il est crucial de surveiller et de contrôler le nombre de messages non traités afin d'éviter tout impact sur l'activité dû aux retards de consommation.
Quand configurer : Nous recommandons de configurer cette alerte après la mise en production de votre activité et la stabilisation du trafic.
Dans la boîte de dialogue Set Rule Description, définissez le Rule Name sur Message accumulation alert. Pour Metric Type, sélectionnez Basic Metrics, et pour Metric, sélectionnez Consumer / Number of accumulated messages(Group). Configurez trois niveaux d'alerte : Critical (notification par téléphone, SMS, e-mail et webhook), Warn (notification par SMS, e-mail et webhook) et Info (notification par e-mail et webhook). Pour chaque niveau, définissez la condition de déclenchement après 3 périodes consécutives (1 période = 1 minute) si Sum >= Threshold et que la méthode statistique est le comptage. Pour Dimension, sélectionnez groupId et spécifiez le groupe de consommateurs correspondant.
Seuil recommandé : Après la mise en production de votre activité, estimez le seuil d'alerte en fonction de vos niveaux de tolérance acceptables.
-
Gestion des alertes : Si vous recevez une alerte d'accumulation de messages, suivez ces étapes :
Sur la page Groups, cliquez sur le Group ID spécifié dans la règle d'alerte.
Sur la page Group Details, cliquez sur l'onglet Dashboard.
Dans le graphique Accumulation-related Metrics (messages), vérifiez la courbe Accumulated Messages. Analysez la tendance de l'accumulation et identifiez le moment où elle a commencé.
En vous basant sur les changements métier et les journaux d'application, analysez les facteurs présents au début de l'accumulation pour trouver la cause racine. Pour plus d'informations sur les causes de l'accumulation de messages, consultez la section Comment gérer l'accumulation de messages.
Selon la cause racine, décidez s'il faut augmenter l'échelle de l'application consommatrice ou corriger les défauts dans la logique de consommation.
Configurer une alerte pour la latence de consommation
Étant donné que cette métrique est cumulative (calculée à partir du message non consommé le plus ancien dans le groupe de consommateurs), elle est très sensible. Si vous recevez une alerte de latence de consommation, vous devez d'abord déterminer si l'impact sur l'activité est dû à quelques messages bloqués ou à un retard de consommation global.
Contexte : ApsaraMQ for RocketMQ prend en charge la surveillance de la latence de consommation au niveau du groupe de consommateurs, fournissant une métrique plus spécifique pour analyser les scénarios d'accumulation de messages.
L'alerte sur l'accumulation de messages est une fonctionnalité clé d'ApsaraMQ for RocketMQ. Cependant, pour les scénarios nécessitant un traitement de messages en temps réel, il est crucial de surveiller et de contrôler la latence des messages accumulés afin d'éviter tout impact sur l'activité dû aux retards de consommation.
Quand configurer : Nous recommandons de configurer cette alerte après la mise en production de votre activité et la stabilisation du trafic.
Dans la boîte de dialogue des paramètres de règle, définissez le Rule Name sur Message processing latency alert. Pour Metric Type, sélectionnez Basic Metrics, et pour Metric, sélectionnez Consumer / Message processing latency(GroupId). Configurez trois niveaux d'alerte : Critical (notification par téléphone, SMS, e-mail et webhook), Warn (notification par SMS, e-mail et webhook) et Info (notification par e-mail et webhook). Pour chaque niveau, définissez la condition de déclenchement après 3 périodes consécutives (1 période = 1 minute) si Maximum >= Threshold (unité : ms), et saisissez les seuils appropriés pour chaque niveau selon vos besoins métier. Pour Dimension, sélectionnez le groupId correspondant.
Seuil recommandé : Après la mise en production de votre activité, estimez le seuil d'alerte en fonction de vos niveaux de tolérance acceptables.
-
Gestion des alertes : Si vous recevez une alerte de latence de consommation, suivez ces étapes :
Sur la page Groups, cliquez sur le Group ID spécifié dans la règle d'alerte.
Sur la page Group Details, cliquez sur l'onglet Dashboard.
Dans le graphique Accumulation-related Metrics (messages), vérifiez la courbe Accumulated Messages. Analysez la tendance de l'accumulation et identifiez le moment où elle a commencé.
En vous basant sur les changements métier et les journaux d'application, analysez les facteurs présents au début de l'accumulation pour trouver la cause racine. Pour plus d'informations sur les causes de l'accumulation de messages, consultez la section Comment gérer l'accumulation de messages.
Selon la cause racine, décidez s'il faut augmenter l'échelle de l'application consommatrice ou corriger les défauts dans la logique de consommation.
Configurer une alerte pour les messages morts (dead-letter)
Contexte : ApsaraMQ for RocketMQ prend en charge les messages morts. Les messages dont la consommation échoue et qui dépassent le nombre maximal de tentatives sont livrés à une file d'attente de messages morts pour traitement manuel. La surveillance du nombre de messages entrant dans cette file d'attente vous aide à détecter rapidement les problèmes inattendus et indéterminés dans votre activité.
Risque en cas d'absence de configuration : Ignorer les messages morts peut entraîner un traitement incomplet de l'activité.
Quand configurer : Nous recommandons de configurer cette alerte après la mise en production de votre activité et la stabilisation du trafic.
Dans la boîte de dialogue Set Rule Description, définissez le Rule Name sur Dead-letter message alert. Pour Metric Type, sélectionnez Basic Metrics, et pour Metric, sélectionnez Consumer / Number of dead-letter messages generated per minute(Group). Sous Thresholds and Alert Levels, configurez trois niveaux : Critical (notification par téléphone, SMS, e-mail et webhook), Warn (notification par SMS, e-mail et webhook) et Info (notification par e-mail et webhook). Pour chaque niveau, définissez la condition de déclenchement après 3 périodes consécutives (1 période = 1 minute), la méthode d'agrégation sur Sum et la condition sur Value >= Threshold (unité : count/m). Pour Dimension, sélectionnez groupId et définissez sa valeur sur le groupe de consommateurs correspondant.
Seuil recommandé : Nous recommandons d'estimer le seuil d'alerte en fonction de vos niveaux de tolérance acceptables après la mise en production et la stabilisation de votre activité.
-
Gestion des alertes : Si vous recevez une alerte concernant le nombre de messages morts, suivez ces étapes :
Interrogez les messages morts et analysez la liste des messages originaux. Pour obtenir des instructions, consultez la section File d'attente de messages morts.
En vous basant sur le Topic et le Message ID du message original, interrogez la trace du message pour analyser la cause de l'échec de la consommation. Pour obtenir des instructions, consultez la section Interroger une trace de message.
Selon la cause de l'échec de la consommation du message, déterminez les mesures correctives appropriées.
Configurer une alerte pour le nombre de limitations de débit
Contexte : ApsaraMQ for RocketMQ vous permet d'utiliser les événements de limitation de débit sur une instance spécifiée comme élément de surveillance. En surveillant le nombre de limitations, vous pouvez comprendre l'étendue de l'impact sur votre activité.
Risque en cas d'absence de configuration : Un nombre élevé de limitations indique une violation plus grave des spécifications de l'instance. Vous devez mettre à niveau la spécification de l'instance en temps utile.
-
Quand configurer : Après la mise en production de votre activité et la stabilisation du trafic.
Nombre de limitations au niveau de l'instance : Nous recommandons de configurer cette alerte après la création de l'instance.
Nombre de limitations au niveau du topic et du groupe : Nous recommandons de configurer cette alerte après la mise en production de votre activité et la stabilisation du trafic.
Dans la boîte de dialogue Set Rule Description, définissez le Rule Name sur Throttling count alert. Pour Metric Type, sélectionnez Basic Metrics, et pour Metric, sélectionnez Producer / Throttled messages per minute(Instance). Dans la section Thresholds and Alert Levels, définissez la condition de déclenchement pour chaque niveau après 3 périodes consécutives (1 période = 1 minute), la méthode d'agrégation sur Sum et la condition sur Value >= Threshold (unité : count/m). Les méthodes de notification sont : Critical (téléphone, SMS, e-mail et webhook), Warn (SMS, e-mail et webhook) et Info (e-mail et webhook).
Seuil recommandé : Après la mise en production de votre activité, estimez le seuil d'alerte en fonction de vos niveaux de tolérance acceptables.
-
Gestion des alertes : Si vous recevez une alerte de nombre de limitations, suivez ces étapes :
Sur la page Instance Details, cliquez sur l'onglet Dashboard.
Dans la section Instance Message Volume Overview, vérifiez la courbe Number of Throttled Requests pour analyser le timing et le modèle des événements de limitation.
Dans la section Message Business Metrics Overview, examinez la métrique Top 20 Topics by Message Production Rate (messages/minute). En vous basant sur le timing et le modèle de la limitation, identifiez le topic présentant des données anormales et vérifiez sa courbe pour déterminer si l'augmentation du trafic correspond aux attentes métier.
Sur la base de cette analyse, si l'augmentation du trafic est prévue, mettez à niveau la spécification de l'instance. Si elle n'est pas prévue, enquêtez sur la source du trafic anormal.