ApsaraMQ for RocketMQ vous permet de configurer des règles d'alerte via Cloud Monitor afin de surveiller en temps réel l'état de fonctionnement et les indicateurs métier clés de vos instances, de recevoir rapidement des notifications d'alerte en cas d'anomalies et de mettre en place une détection précoce des risques pour 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 s'accompagne d'un accord de niveau de service (SLA) clair. Après l'achat d'une instance, ses performances concernant des métriques telles que le TPS de messagerie, le stockage des messages et le débit réseau sont garanties conformément à ses spécifications.
Vous n'avez pas à vous soucier des performances de l'instance. Toutefois, dans un environnement de production, vous devez vérifier si votre consommation réelle et votre échelle métier approchent les limites de spécification de votre instance. ApsaraMQ for RocketMQ, conjointement avec CloudMonitor, fournit un service de surveillance et d'alerte gratuit et prêt à l'emploi qui répond aux problèmes suivants :
-
Détection précoce des seuils de spécification de l'instance
Si l'utilisation de vos ressources dépasse les limites de spécification de l'instance, ApsaraMQ for RocketMQ applique une limitation de débit. En configurant à l'avance des alertes pour les seuils de spécification, vous pouvez détecter tôt le risque de dépassement des limites et mettre rapidement à niveau les configurations de l'instance afin d'éviter les pannes métier causées par la limitation de débit.
-
Détection précoce des erreurs de logique métier
Des erreurs peuvent survenir lors de l'envoi et de la réception de messages. La configuration d'alertes pour les erreurs d'appel vous permet de détecter les anomalies avant qu'elles ne soient signalées par votre application métier. Cela vous aide à identifier la source de l'erreur et à la corriger rapidement.
-
Détection précoce des indicateurs de performance métier
Si votre pipeline de messagerie a des exigences de performance spécifiques, telles que le temps de réponse (RT) ou la latence des messages, la configuration d'alertes pour ces métriques métier vous aide à gérer proactivement les risques liés au métier.
Principes de configuration des alertes
ApsaraMQ for RocketMQ propose un ensemble complet de métriques et d'éléments d'alerte. Ces éléments se répartissent en trois catégories : seuils de fonctionnement, performances de messagerie et événements d'exception.
Fort d'une vaste expérience des environnements de production, nous vous recommandons de configurer les alertes suivantes :
Les éléments de surveillance principaux ci-dessous constituent des recommandations de base. ApsaraMQ for RocketMQ fournit un ensemble complet de métriques de surveillance. Vous pouvez configurer des alertes plus fines et plus complètes en fonction de vos besoins métier. Pour plus d'informations, consultez la section Surveillance et alertes.
Catégorie d'alerte | Éléments d'alerte clés | Quand configurer | Rôle cible |
Seuils de ressources de l'instance et métriques de consommation |
|
| Ingénieurs O&M des ressources |
Métriques de performance de messagerie |
|
|
|
Événements d'exception de messagerie |
|
|
|
Point d'entrée de configuration des alertes
Connectez-vous à la console ApsaraMQ for RocketMQ, puis cliquez sur Instances dans le volet de navigation de gauche.
Dans la barre de menu supérieure, sélectionnez une région, par exemple China (Hangzhou), puis cliquez sur le nom de l'instance cible dans la liste des instances.
Dans le volet de navigation de gauche, cliquez sur Monitoring and Alerts, puis sur Create Alert Rule.
Bonnes pratiques
Configurer des alertes de TPS de pointe pour les appels API d'instance
Contexte : une spécification d'instance ApsaraMQ for RocketMQ 5.0 définit une limite de TPS de base pour l'envoi et la réception de messages, correspondant au taux d'appels API. Si le TPS de pointe des appels API d'une instance dépasse cette limite, une limitation de débit est appliquée. Pour plus d'informations sur les limites de TPS de base, consultez la section Quotas et limites.
Risque en l'absence de configuration : sans cette alerte, vous ne recevez aucun avertissement avant que le taux d'appels API ne dépasse la limite, ce qui entraîne l'échec de certaines demandes d'envoi et de réception de messages dès le début de la limitation de débit.
-
Quand configurer : nous vous recommandons de configurer cette alerte après la création de l'instance et la définition du ratio requêtes d'envoi/requêtes de réception. Pour ajuster le ratio, procédez comme suit :
Sur la page Instance Details, cliquez sur l'onglet Basic Information.
Cliquez sur Edit pour ouvrir le panneau Modify Configurations, où vous pouvez ajuster le ratio requêtes d'envoi/requêtes de réception.
Appels API d'envoi de l'instance
-
Seuil recommandé : définissez le seuil à 70 % de la limite de TPS d'envoi de pointe de l'instance. Par exemple, si la limite de TPS d'envoi de pointe est de 5 000, définissez le seuil à 3 500.
Les instances Professional Edition et Enterprise Platinum Edition prennent en charge le TPS élastique pour les pics de trafic. Si vous activez cette fonctionnalité, définissez votre seuil à 70 % de la limite de spécification élastique (TPS d'envoi de pointe + TPS d'envoi élastique).
Une instance serverless prend en charge l'élasticité adaptative. Définissez votre seuil à 70 % du TPS d'envoi de pointe élastique de l'instance.
Vous pouvez afficher la limite de TPS d'envoi de pointe et le TPS d'envoi élastique d'une instance sur la page Instance Details de la console.
-
Réponse : lorsque vous recevez une alerte concernant le taux d'appels API d'envoi de l'instance, suivez ces étapes :
Sur la page Instance Details, cliquez sur l'onglet Dashboard.
Dans la section Throttling-related Metrics, vérifiez la courbe Production TPS MAX Value dans le graphique Production TPS Watermark pour identifier le moment où le seuil a été atteint.
Dans la section Instance Overview, vérifiez le graphique Rate of Messages Sent by Producer to Server (messages/min). Mettez en corrélation le moment où le seuil a été atteint avec l'activité du topic pour trouver la source du trafic anormal, et analysez sa courbe pour déterminer si la variation de trafic est attendue.
Si la variation de trafic est inattendue, contactez l'équipe métier pour une analyse approfondie.
Si la variation de trafic est attendue, la spécification actuelle de l'instance est insuffisante. Mettez immédiatement à niveau les configurations de l'instance pour ajuster la spécification de calcul de messagerie.
Appels API de réception de l'instance
-
Seuil recommandé : définissez le seuil à 70 % de la limite de TPS de réception de pointe de l'instance. Par exemple, si la limite de TPS de réception de pointe est de 5 000, définissez le seuil à 3 500.
Les instances Professional Edition et Enterprise Platinum Edition prennent en charge le TPS élastique pour les pics de trafic. Si vous activez cette fonctionnalité, définissez votre seuil à 70 % de la limite de spécification élastique (TPS de réception de pointe + TPS de réception élastique).
Une instance serverless prend en charge l'élasticité adaptative. Définissez votre seuil à 70 % du TPS de réception de pointe élastique de l'instance.
Vous pouvez afficher la limite de TPS de réception de pointe et le TPS de réception élastique d'une instance sur la page Instance Details de la console.
-
Réponse : lorsque vous recevez une alerte concernant le taux d'appels API de réception de l'instance, suivez ces étapes :
Sur la page Instance Details, cliquez sur l'onglet Dashboard.
Dans la section Throttling-related Metrics, vérifiez la courbe Consumption TPS MAX Value dans le graphique Consumption TPS Watermark pour identifier le moment où le seuil a été atteint.
Dans la section Instance Overview, vérifiez le graphique Rate of Messages Delivered from Server to Consumer (messages/min). Mettez en corrélation le moment où le seuil a été atteint avec l'activité du groupe de consommateurs pour trouver la source de la consommation anormale, et analysez sa courbe pour déterminer si la variation de trafic est attendue.
Si la variation de trafic est inattendue, contactez l'équipe métier pour une analyse approfondie.
Si la variation de trafic est attendue, la spécification actuelle de l'instance est insuffisante. Mettez immédiatement à niveau les configurations de l'instance pour ajuster la spécification de calcul de messagerie.
Configurer des alertes pour les messages par minute
Contexte : ApsaraMQ for RocketMQ vous permet de surveiller le TPS d'envoi et de réception de messages au niveau du topic et du groupe de consommateurs. En configurant des alertes pour ces métriques, vous pouvez surveiller proactivement le volume de trafic de services métier spécifiques.
Risque en l'absence de configuration : le TPS d'envoi et de réception de messages d'un topic reflète la fréquence d'appel du métier. Sans cette alerte, une chute soudaine à zéro ou une augmentation inattendue du trafic peut passer inaperçue, entraînant potentiellement des risques métier.
Quand configurer : nous vous recommandons de configurer cette alerte après la mise en production de votre application et la stabilisation du trafic.
Messages envoyés par les producteurs
Seuil recommandé : estimez le seuil d'alerte en fonction du trafic réel observé pendant la période stable après la mise en production de votre application.
-
Réponse : lorsque vous recevez une alerte de TPS d'envoi 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.
Vérifiez la courbe Production dans le graphique Message Volume (messages/min). Selon votre modèle métier, déterminez si les fluctuations de la courbe sont raisonnables et analysez toute anomalie.
Messages reçus par les consommateurs
Seuil recommandé : estimez le seuil d'alerte en fonction du trafic réel observé pendant la période stable après la mise en production de votre application.
-
Réponse : lorsque vous recevez une alerte de TPS de réception de messages, suivez ces étapes :
Sur la page Groups, cliquez sur l'ID du groupe de consommateurs spécifié dans la règle d'alerte.
Sur la page Group Details, cliquez sur l'onglet Dashboard.
Vérifiez la courbe Consumption Rate (messages/min) dans le graphique Message Production and Consumption Rate Trend (messages/min). Selon votre modèle métier, déterminez si les fluctuations de la courbe sont raisonnables et analysez toute anomalie.
Configurer des alertes pour la bande passante sortante Internet
Contexte : les instances de la série ApsaraMQ for RocketMQ 5.0 prennent en charge l'accès Internet, mais cet accès est limité par la bande passante sortante Internet. Le dépassement de la limite de bande passante de votre spécification altère l'accès Internet.
Risque en l'absence de configuration : sans cette alerte, vous ne serez pas averti si le trafic Internet de votre instance dépasse la limite de bande passante, ce qui peut entraîner une perte de paquets, des délais d'attente des appels clients ou des échecs.
-
Quand configurer : configurez cette alerte après la création d'une instance non serverless et l'activation de l'accès Internet.
RemarqueUne instance serverless prend en charge la bande passante élastique, il n'est donc pas nécessaire de configurer cette alerte.
-
Seuil recommandé : définissez le seuil à 35 % de votre limite de spécification. Nous recommandons cette valeur car l'objectif est d'alerter à 70 % de la limite, et l'outil de surveillance collecte des données représentant environ 50 % du trafic réel (70 % × 50 % = 35 %). Par exemple, si vous achetez une instance avec une bande passante de 1 Mbit/s, le seuil d'alerte recommandé est de 43 750 B/s. Vous pouvez trouver les informations sur la bande passante Internet de votre instance dans la section Running Information de l'onglet Basic Information sur la page Instance Details.
RemarqueLors de l'estimation du seuil, convertissez les Mbit/s en B/s avant de calculer. Par exemple : 1 Mbit/s = 1×10^6 bits/s = (1×10^6)/8 B/s = 125 000 B/s. Le seuil recommandé est
125,000 B/s × 0.7 × 0.5 = 43,750 B/s. -
Réponse : lorsque vous recevez une alerte concernant la bande passante sortante Internet, suivez ces étapes :
Sur la page Instance Details, cliquez sur l'onglet Dashboard.
Dans la section Billing Metrics Overview, vérifiez la courbe Outbound Bandwidth dans le graphique Internet Outbound Traffic Bandwidth pour identifier le moment où le seuil a été atteint. Assurez-vous que les unités du graphique correspondent aux unités de votre seuil d'alerte.
Dans la section Instance Overview, vérifiez les graphiques Rate of Messages Sent by Producer to Server (messages/min) et Rate of Messages Delivered from Server to Consumer (messages/min). Mettez en corrélation le moment où le seuil a été atteint pour trouver le topic ou le groupe de consommateurs présentant des données anormales, et analysez la courbe pour déterminer si la variation de trafic est attendue.
Si la variation de trafic est inattendue, contactez l'équipe métier pour une analyse approfondie.
Si la variation de trafic est attendue, la spécification actuelle de l'instance est insuffisante. Mettez immédiatement à niveau les configurations de l'instance pour ajuster la spécification de bande passante sortante Internet.
Configurer des alertes pour l'accumulation de messages
Les statistiques d'accumulation de messages peuvent fluctuer et contenir des imprécisions. Nous ne recommandons pas de définir un seuil d'alerte pour une accumulation de quelques dizaines de messages. Si votre application est très sensible même à de petits retards, surveillez plutôt le délai de consommation.
Contexte : ApsaraMQ for RocketMQ vous permet de surveiller l'accumulation de messages au niveau du groupe de consommateurs, ce qui peut vous alerter en cas de scénario de retard de consommation en aval.
Risque en l'absence de configuration : bien que l'accumulation de messages soit une fonctionnalité standard de ApsaraMQ for RocketMQ, pour un traitement en temps réel, vous devez surveiller et contrôler le volume de messages non traités afin d'éviter tout impact métier dû à un retard de consommation.
Quand configurer : nous vous recommandons de configurer cette alerte après la mise en production de votre application et la stabilisation du trafic.
Seuil recommandé : estimez le seuil d'alerte en fonction de la tolérance de votre application après sa mise en production.
-
Réponse : lorsque vous recevez une alerte concernant l'accumulation de messages, suivez ces étapes :
Sur la page Groups, cliquez sur l'ID du groupe de consommateurs spécifié dans la règle d'alerte.
Sur la page Group Details, cliquez sur l'onglet Dashboard.
Vérifiez la courbe Accumulated Messages dans le graphique Accumulation-related Metrics. Analysez la tendance de l'accumulation pour déterminer quand elle a commencé.
En vous basant sur les changements métier et les journaux d'application, analysez les facteurs présents au moment initial de l'accumulation pour en trouver la cause. Pour plus d'informations sur les principes de consommation des messages, consultez la section Types de consommateurs.
Selon la cause, décidez s'il faut augmenter la capacité de l'application consommatrice ou corriger les défauts dans la logique de consommation.
Configurer des alertes pour le délai de consommation
Le délai de consommation est calculé sur la base du message le plus ancien parmi tous les messages non consommés du groupe de consommateurs actuel, ce qui en fait une métrique cumulative et sensible. Lorsque vous recevez une alerte concernant le délai de consommation, vous devez d'abord déterminer si le retard est causé par quelques messages bloqués ou par un retard global de consommation.
Contexte : ApsaraMQ for RocketMQ vous permet de surveiller le délai de consommation au niveau du groupe de consommateurs, fournissant ainsi une métrique plus précise pour analyser les scénarios de retard de consommation.
Risque en l'absence de configuration : bien que l'accumulation de messages soit une fonctionnalité standard de ApsaraMQ for RocketMQ, pour un traitement en temps réel, vous devez surveiller et contrôler le délai des messages en attente afin d'éviter tout impact métier dû à des retards de consommation.
Quand configurer : nous vous recommandons de configurer cette alerte après la mise en production de votre application et la stabilisation du trafic.
Seuil recommandé : estimez le seuil d'alerte en fonction de la tolérance de votre application après sa mise en production.
-
Réponse : lorsque vous recevez une alerte concernant le délai de consommation, suivez ces étapes :
Sur la page Groups, cliquez sur l'ID du groupe de consommateurs spécifié dans la règle d'alerte.
Sur la page Group Details, cliquez sur l'onglet Dashboard.
Vérifiez la courbe Accumulated Messages dans le graphique Accumulation-related Metrics. Analysez la tendance de l'accumulation pour déterminer quand elle a commencé.
En vous basant sur les changements métier et les journaux d'application, analysez les facteurs présents au moment initial de l'accumulation pour en trouver la cause. Pour plus d'informations sur les principes de consommation des messages, consultez la section Types de consommateurs.
Selon la cause, décidez s'il faut augmenter la capacité de l'application consommatrice ou corriger les défauts dans la logique de consommation.
Configurer des alertes pour les événements de limitation de débit
Contexte : ApsaraMQ for RocketMQ surveille les événements de limitation de débit pour une instance spécifique. En surveillant le nombre d'événements de limitation de débit, vous pouvez comprendre l'impact sur votre activité actuelle.
Risque en l'absence de configuration : un nombre élevé d'événements de limitation de débit indique que les spécifications de l'instance ont été largement dépassées. Vous devez mettre rapidement à niveau les configurations de l'instance.
-
Quand configurer : après la mise en production de votre application et la stabilisation du trafic.
Nombre de limitations au niveau de l'instance : configurez les alertes après la création de l'instance.
Nombre de limitations au niveau du topic et du groupe : configurez les alertes après la mise en production de votre application et la stabilisation du trafic.
Seuil recommandé : estimez le seuil d'alerte en fonction de la tolérance de votre application après sa mise en production.
-
Réponse : lorsque vous recevez une alerte concernant les événements de limitation de débit, suivez ces étapes :
Sur la page Instance Details, cliquez sur l'onglet Dashboard.
Dans la section Throttling-related Metrics, vérifiez le graphique Throttled Request Distribution (Production) pour analyser le timing et les modèles des événements de limitation de débit.
Dans la section Instance Overview, examinez la métrique Rate of Messages Sent by Producer to Server (messages/min). En vous basant sur le timing des événements de limitation de débit, identifiez le topic présentant des données anormales et vérifiez sa courbe pour déterminer si l'augmentation du trafic est attendue.
Sur la base de cette analyse, si l'augmentation du trafic est attendue, mettez à niveau les configurations de l'instance. Si elle n'est pas attendue, recherchez la source du trafic anormal.