CloudWatch Metriche disponibili per Amazon SQS

Per le code standard, se un messaggio viene ricevuto tre o più volte e non viene eliminato, SQS lo sposta in fondo alla coda. La metrica riflette quindi l'età del messaggio successivo che non ha superato la soglia di ricezione. Questo riordino si verifica anche quando è in vigore una politica di redrive.

I messaggi Poison-pill (quelli ricevuti ripetutamente ma mai eliminati) vengono esclusi da questa metrica fino a quando non vengono elaborati correttamente.

Quando un messaggio viene spostato in un DLQ dopo aver superato il, la data di scadenza viene ripristinata. maxReceiveCount In tal caso, la metrica del DLQ riflette l'ora in cui il messaggio è stato spostato, non quando è stato originariamente inviato.

Le code FIFO non riordinano i messaggi per mantenere l'ordine. Un messaggio non riuscito blocca il relativo gruppo di messaggi fino alla sua eliminazione o alla scadenza. Se è configurato un DLQ, il messaggio viene inviato lì dopo il raggiungimento della soglia di ricezione.

Un messaggio viene considerato in transito dopo che è stato ricevuto dalla coda da un consumatore ma non è ancora stato eliminato o è scaduto.

Questa metrica consente di risolvere i problemi e ottimizzare la velocità effettiva delle code FIFO. I valori elevati di solito indicano una forte concorrenza.

Se la coda presenta un notevole arretrato e questo valore rimane basso, valuta la possibilità di ridimensionare i consumatori o aumentare il numero di gruppi di messaggi attivi.

Per informazioni sulla velocità effettiva e sui limiti in volo, consulta. Quote di Amazon SQS

Si applica alle code configurate con un ritardo predefinito e ai singoli messaggi inviati con un parametro. DelaySeconds

I messaggi ritardati rimangono nascosti ai consumatori fino alla scadenza del periodo di ritardo, il che può influire sulla percezione dell'arretrato o del throughput delle code.

I messaggi entrano nello stato in corso dopo essere stati inviati a un consumatore tramite l'ReceiveMessageAPI.

Questi messaggi sono temporaneamente nascosti agli altri consumatori durante la finestra di timeout di visibilità.

Utilizza questa metrica per tenere traccia dei ritardi nell'elaborazione dei messaggi o dei consumatori bloccati.

Riflette l'attuale arretrato di elaborazione nella coda.

Non esiste un limite rigido al numero di messaggi che possono accumularsi, ma sono soggetti al periodo di conservazione configurato dalla coda.

Un valore costantemente elevato può indicare che i consumatori non dispongono di risorse sufficienti o che la logica di elaborazione è bloccata.

Questa metrica può aiutare a identificare le inefficienze nel comportamento dei sondaggi o i casi di consumo sottoutilizzati.

Possono verificarsi valori elevati quando la coda è vuota, il consumatore utilizza sondaggi brevi o i messaggi vengono elaborati più velocemente di quanto vengano prodotti.

Questo non è un indicatore preciso dello stato della coda. Riflette il comportamento sul lato del servizio e può includere nuovi tentativi.

SQS deduplica i messaggi in base all'hashing basato sul MessageDeduplicationId contenuto (se abilitato).

Un valore elevato può indicare che un produttore invia ripetutamente lo stesso messaggio entro la finestra di deduplicazione di 5 minuti.

Utilizzate questa metrica per risolvere i problemi della logica ridondante del produttore o per confermare che la deduplicazione funzioni come previsto.

Questa metrica conta tutte le operazioni di eliminazione riuscite, anche se lo stesso messaggio viene eliminato più di una volta.

I motivi più comuni alla base dei valori includono: higher-than-expected

Utilizzate questa metrica per tenere traccia del successo dell'elaborazione dei messaggi, ma non trattatela come un conteggio esatto dei messaggi unici eliminati.

Ciò include tutti i messaggi restituiti ai consumatori, compresi quelli che vengono successivamente rimessi in coda a causa della scadenza del timeout di visibilità.

Un singolo messaggio può essere ricevuto più volte se non viene eliminato, il che può far sì che questa metrica superi il numero di messaggi inviati.

Utilizzala per tracciare l'attività dei consumatori, ma non considerarla come un numero di messaggi unici elaborati.

SendMessageBatchVengono conteggiate le chiamate manuali verso SendMessage o verso un DLQ, incluse quelle dirette a un DLQ.

I messaggi che vengono spostati automaticamente in un DLQ dopo aver superato il limite non maxReceiveCount sono inclusi in questa metrica.

Di conseguenza, NumberOfMessagesSent potrebbe essere inferiore a, NumberOfMessagesReceived specialmente se le politiche di redrive spostano molti messaggi in background. DLQs

Questa metrica non verrà visualizzata nella CloudWatch console finché la coda non riceverà il primo messaggio.

Utilizza questa metrica per tenere traccia della dimensione di ogni messaggio in byte. Ciò è utile per analizzare le tendenze del payload o stimare i costi di throughput.

La dimensione massima dei messaggi per SQS è di 1 MiB.

Aiuta a identificare potenziali problemi legati alla rumorosità dei vicini in ambienti multi-tenant tracciando i gruppi di messaggi che consumano risorse sproporzionate.

Utilizzate questa metrica per impostare allarmi che si attivano quando il numero di gruppi rumorosi supera la soglia accettabile, indicando potenziali problemi di equità delle code.

Fornisce visibilità sul backlog della coda per i gruppi di messaggi con tariffa standard, esclusi i messaggi provenienti da vicini rumorosi.

Aiuta a identificare il vero backlog di elaborazione per i gruppi di messaggi tipici filtrando l'impatto dei vicini rumorosi.

Tiene traccia dei messaggi in corso (in fase di elaborazione ma non ancora eliminati) provenienti da gruppi di messaggi che si comportano bene.

Utilizza questa metrica per monitorare la velocità di elaborazione dei normali gruppi di messaggi e rilevare rallentamenti nell'elaborazione che non sono causati da vicini rumorosi.

Aiuta a monitorare l'arretrato dei messaggi in ritardo provenienti da gruppi di messaggi con schemi di throughput normali o previsti (a differenza dei gruppi ad alto volume o rumorosi)

Utile per comprendere i requisiti di elaborazione futuri e la pianificazione della capacità per i carichi di lavoro tipici.

Utilizzato per monitorare la conformità agli SLA e rilevare i rallentamenti nell'elaborazione in gruppi di messaggi con modelli di throughput normali o previsti (al contrario dei gruppi di messaggi ad alto volume o rumorosi che altrimenti potrebbero alterare la metrica).

Utilizzate questa metrica per impostare allarmi per i timeout di elaborazione dei messaggi che ignorano i messaggi invecchiati artificialmente provenienti da vicini rumorosi.