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.

Poison-pill i messaggi (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 limitemaxReceiveCount, l'età viene ripristinata. 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 finché non viene eliminato o scade. Se è configurato un DLQ, il messaggio viene inviato lì dopo aver raggiunto la soglia di ricezione.

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

Questa metrica consente di risolvere i problemi e ottimizzare il throughput delle code FIFO. Valori elevati di solito indicano una forte concorrenza.

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

Per la velocità effettiva e i 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 posticipati rimangono nascosti ai consumatori fino alla scadenza del periodo di ritardo, il che può influire sulla percezione del backlog o della velocità effettiva percepiti.

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

Questi messaggi vengono temporaneamente nascosti agli altri consumatori durante il periodo di timeout della visibilità.

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

In rare occasioni, uno dei server utilizzati da Amazon SQS per archiviare i messaggi potrebbe non essere disponibile quando Amazon SQS riporta le metriche delle code. In questo caso, questa metrica potrebbe riportare un valore diverso da zero, anche quando la coda è vuota o non ha ricevuto chiamate. ReceiveMessage In genere si risolve in pochi minuti, quindi se imposti un allarme per questa metrica, valuta più punti dati consecutivi anziché un singolo valore diverso da zero.

Riflette l'attuale arretrato di elaborazione nella coda.

Non esiste un limite fisso al numero di messaggi che possono essere accumulati, ma sono soggetti al periodo di conservazione configurato dalla coda. Architettura Amazon SQS di base

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 un polling breve o i messaggi vengono elaborati più rapidamente di quanto vengono prodotti.

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

SQS deduplica i messaggi in base all'hashing MessageDeduplicationId o al 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 relativi alla logica ridondante del produttore o verificare 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 per cui i valori sono più alti del previsto includono:

Usa questa metrica per tenere traccia del successo dell'elaborazione dei messaggi, ma non considerarla come un conteggio esatto dei messaggi eliminati univoci.

Sono inclusi tutti i messaggi restituiti ai consumatori, compresi quelli che vengono successivamente restituiti alla 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.

Usalo per monitorare l'attività dei consumatori, ma non considerarlo come un conteggio dei messaggi univoci elaborati.

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

I messaggi che vengono spostati automaticamente in un DLQ dopo il superamento di tale limite non maxReceiveCount sono inclusi in questa metrica.

Di conseguenza, NumberOfMessagesSent può essere inferiore a, NumberOfMessagesReceived soprattutto se le politiche di redrive trasferiscono molti messaggi ai DLQ dietro le quinte.

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

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

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

Consente di identificare potenziali problemi relativi ai rumorosi vicini in ambienti multi-tenant tracciando i gruppi di messaggi che consumano risorse sproporzionate.

Usa 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 frequenza standard, esclusi i messaggi provenienti da vicini rumorosi.

Aiuta a identificare il vero arretrato di elaborazione per i tipici gruppi di messaggi 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 correttamente.

Usa questa metrica per monitorare la velocità di elaborazione dei normali gruppi di messaggi e rilevare i colli di bottiglia nell'elaborazione non causati dai rumori dei vicini.

Consente di monitorare l'arretrato di messaggi ritardato proveniente da gruppi di messaggi con modelli di throughput normali o previsti (al contrario 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 colli di bottiglia nell'elaborazione nei gruppi di messaggi con modelli di throughput normali o previsti (al contrario dei gruppi di messaggi ad alto volume o rumorosi che altrimenti potrebbero distorcere la metrica).

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