Statistiques CloudWatch disponibles pour Amazon SQS

Pour les files d'attente standard, si un message est reçu trois fois ou plus et n'est pas supprimé, SQS le déplace vers la fin de la file d'attente. La métrique reflète ensuite l'âge du prochain message qui n'a pas dépassé le seuil de réception. Cette réorganisation se produit même lorsqu'une politique de redrive est en place.

Poison-pill les messages (ceux reçus à plusieurs reprises mais jamais supprimés) sont exclus de cette métrique jusqu'à ce qu'ils soient traités avec succès.

Lorsqu'un message est déplacé vers une DLQ après avoir dépassé lemaxReceiveCount, l'âge est réinitialisé. Dans ce cas, la métrique du DLQ reflète l'heure à laquelle le message a été déplacé, et non la date de son envoi initial.

Les files d'attente FIFO ne réorganisent pas les messages pour préserver l'ordre. Un message qui a échoué bloque son groupe de messages jusqu'à sa suppression ou son expiration. Si un DLQ est configuré, le message y est envoyé une fois que le seuil de réception est atteint.

Un message est considéré comme étant en vol lorsqu'il a été reçu de la file d'attente par un consommateur mais qu'il n'a pas encore été supprimé ou qu'il n'a pas expiré.

Cette métrique vous aide à résoudre les problèmes et à optimiser le débit des files d'attente FIFO. Des valeurs élevées indiquent généralement une forte simultanéité.

Si la file d'attente présente un arriéré important et que cette valeur reste faible, envisagez de redimensionner le nombre de consommateurs ou d'augmenter le nombre de groupes de messages actifs.

Pour les limites de débit et de vol, consultezQuotas Amazon SQS.

S'applique aux files d'attente configurées avec un délai par défaut et aux messages individuels envoyés avec un DelaySeconds paramètre.

Les messages différés restent cachés aux consommateurs jusqu'à l'expiration de leur délai, ce qui peut affecter la perception de l'arriéré ou du débit dans les files d'attente.

Les messages passent à l'état de vol après avoir été envoyés à un consommateur via l'ReceiveMessageAPI.

Ces messages sont temporairement masqués aux autres consommateurs pendant le délai de visibilité.

Utilisez cette métrique pour suivre les retards de traitement des messages ou les clients bloqués.

En de rares occasions, l'un des serveurs qu'Amazon SQS utilise pour stocker vos messages peut ne pas être disponible lorsqu'Amazon SQS publie des statistiques de file d'attente. Dans ce cas, cette métrique peut indiquer une valeur différente de zéro, y compris lorsque la file d'attente est vide ou n'a reçu aucun ReceiveMessage appel. Elle se résout généralement en quelques minutes. Par conséquent, si vous définissez une alarme pour cette métrique, évaluez plusieurs points de données consécutifs plutôt qu'une seule valeur différente de zéro.

Reflète le retard de traitement actuel dans la file d'attente.

Il n'y a pas de limite stricte au nombre de messages pouvant être accumulés, mais ceux-ci sont soumis à la période de rétention configurée par la file d'attente.

Une valeur constamment élevée peut indiquer des consommateurs sous-approvisionnés ou une logique de traitement bloquée.

Cette métrique peut aider à identifier les inefficacités dans le comportement des sondages ou les instances de consommation sous-utilisées.

Des valeurs élevées peuvent apparaître lorsque la file d'attente est vide, que le consommateur utilise une courte interrogation ou que les messages sont traités plus rapidement qu'ils ne sont produits.

Il ne s'agit pas d'un indicateur précis de l'état de la file d'attente. Il reflète le comportement côté service et peut inclure de nouvelles tentatives.

SQS déduplique les messages en fonction du hachage basé sur le contenu MessageDeduplicationId ou le hachage basé sur le contenu (s'il est activé).

Une valeur élevée peut indiquer qu'un producteur envoie à plusieurs reprises le même message pendant la période de déduplication de 5 minutes.

Utilisez cette métrique pour résoudre les problèmes liés à la logique redondante du producteur ou pour confirmer que la déduplication fonctionne comme prévu.

Cette métrique compte toutes les opérations de suppression réussies, même si le même message est supprimé plusieurs fois.

Les raisons courantes expliquant les valeurs plus élevées que prévu sont les suivantes :

Utilisez cette métrique pour suivre le succès du traitement des messages, mais ne la considérez pas comme un nombre exact de messages supprimés uniques.

Cela inclut tous les messages renvoyés aux consommateurs, y compris ceux qui sont ensuite renvoyés dans la file d'attente en raison de l'expiration du délai de visibilité.

Un même message peut être reçu plusieurs fois s'il n'est pas supprimé, ce qui peut entraîner un dépassement du nombre de messages envoyés.

Utilisez-le pour suivre l'activité des consommateurs, mais ne le considérez pas comme un nombre de messages uniques traités.

Les appels manuels à destination SendMessage ou en cours de traitement SendMessageBatch sont comptabilisés, y compris ceux qui ciblent directement un DLQ.

Les messages qui sont automatiquement déplacés vers une DLQ après avoir dépassé le ne maxReceiveCount sont pas inclus dans cette métrique.

Par conséquent, il NumberOfMessagesSent peut être inférieur à, NumberOfMessagesReceived surtout si les politiques de reconduite transfèrent de nombreux messages vers des DLQ en arrière-plan.

Cette métrique n'apparaîtra pas dans la CloudWatch console tant que la file d'attente n'aura pas reçu son premier message.

Utilisez cette métrique pour suivre la taille de chaque message en octets. Cela est utile pour analyser les tendances de la charge utile ou estimer le coût du débit.

La taille maximale des messages pour SQS est de 1 Mo.

Permet d'identifier les problèmes potentiels de voisinage bruyant dans les environnements à locataires multiples en suivant les groupes de messages consommant des ressources disproportionnées.

Utilisez cette métrique pour définir des alarmes qui se déclenchent lorsque le nombre de groupes bruyants dépasse votre seuil acceptable, indiquant ainsi des problèmes potentiels d'équité de la file d'attente.

Fournit une visibilité sur le backlog des files d'attente pour les groupes de messages à débit standard, à l'exclusion des messages provenant de voisins bruyants.

Permet d'identifier le véritable retard de traitement pour les groupes de messages types en filtrant l'impact des voisins bruyants.

Suit les messages en vol (en cours de traitement mais pas encore supprimés) provenant de groupes de messages qui se comportent bien.

Utilisez cette métrique pour surveiller le débit de traitement des groupes de messages normaux et détecter les goulots d'étranglement de traitement qui ne sont pas causés par des voisins bruyants.

Permet de surveiller l'arriéré de messages différés provenant de groupes de messages présentant des modèles de débit normaux ou attendus (par opposition aux groupes à volume élevé ou bruyants)

Utile pour comprendre les besoins de traitement futurs et planifier les capacités pour les charges de travail typiques.

Utilisé pour surveiller la conformité aux SLA et détecter les goulots d'étranglement de traitement dans les groupes de messages présentant des modèles de débit normaux ou attendus (par opposition aux groupes de messages à volume élevé ou bruyants qui pourraient autrement fausser la métrique).

Utilisez cette métrique pour définir des alarmes pour les délais de traitement des messages qui ignorent les messages vieillis artificiellement provenant de voisins bruyants.