Verfügbare CloudWatch Metriken für Amazon SQS

Wenn bei Standardwarteschlangen eine Nachricht dreimal oder öfter empfangen und nicht gelöscht wird, verschiebt SQS sie an das Ende der Warteschlange. Die Metrik gibt dann das Alter der nächsten Nachricht an, die den Empfangsschwellenwert nicht überschritten hat. Diese Neuordnung erfolgt auch dann, wenn eine Redrive-Richtlinie in Kraft ist.

Poison-pill Nachrichten (Nachrichten, die wiederholt empfangen, aber nie gelöscht wurden) werden von dieser Metrik ausgeschlossen, bis sie erfolgreich verarbeitet wurden.

Wenn eine Nachricht nach Überschreitung des Grenzwerts in einen DLQ verschoben wirdmaxReceiveCount, wird das Alter zurückgesetzt. In diesem Fall gibt die DLQ-Metrik den Zeitpunkt an, zu dem die Nachricht verschoben wurde — nicht den Zeitpunkt, zu dem sie ursprünglich gesendet wurde.

FIFO-Warteschlangen ordnen Nachrichten nicht neu an, um die Reihenfolge beizubehalten. Eine fehlgeschlagene Nachricht blockiert ihre Nachrichtengruppe, bis sie gelöscht wird oder abläuft. Wenn ein DLQ konfiguriert ist, wird die Nachricht dorthin gesendet, nachdem der Empfangsschwellenwert erreicht ist.

Eine Nachricht gilt als während des Fluges, wenn sie von einem Verbraucher aus der Warteschlange empfangen, aber noch nicht gelöscht oder abgelaufen ist.

Diese Metrik hilft Ihnen bei der Fehlerbehebung und Optimierung des Durchsatzes in der FIFO-Warteschlange. Hohe Werte deuten in der Regel auf eine starke Parallelität hin.

Wenn die Warteschlange einen großen Rückstand hat und dieser Wert niedrig bleibt, sollten Sie erwägen, die Anzahl der Verbraucher zu skalieren oder die Anzahl der aktiven Nachrichtengruppen zu erhöhen.

Informationen zu Durchsatz und Grenzwerten während des Fluges finden Sie unter. Amazon-SQS-Kontingente

Gilt für Warteschlangen, die mit einer Standardverzögerung konfiguriert sind, und für einzelne Nachrichten, die mit einem DelaySeconds Parameter gesendet werden.

Verspätete Nachrichten bleiben den Verbrauchern verborgen, bis ihre Verzögerungszeit abgelaufen ist, was sich auf den wahrgenommenen Warteschlangenstau oder den Durchsatz auswirken kann.

Nachrichten erhalten den Status während des Fluges, nachdem sie über die API an einen Verbraucher gesendet wurden. ReceiveMessage

Diese Nachrichten werden während des Zeitlimits für die Sichtbarkeit vorübergehend vor anderen Verbrauchern verborgen.

Verwenden Sie diese Metrik, um Verzögerungen bei der Nachrichtenverarbeitung oder unsichere Verbraucher zu verfolgen.

In seltenen Fällen ist einer der Server, die Amazon SQS zum Speichern Ihrer Nachrichten verwendet, möglicherweise nicht verfügbar, wenn Amazon SQS Warteschlangenmetriken meldet. In diesem Fall meldet diese Metrik möglicherweise einen Wert ungleich Null, auch wenn die Warteschlange ansonsten leer ist oder keine Anrufe eingegangen sind. ReceiveMessage Das Problem wird in der Regel innerhalb von Minuten behoben. Wenn Sie also einen Alarm für diese Metrik einrichten, werten Sie mehrere aufeinanderfolgende Datenpunkte aus und nicht einen einzelnen Wert ungleich Null.

Spiegelt den aktuellen Verarbeitungsrückstand in der Warteschlange wider.

Es gibt keine feste Grenze für die Anzahl der Nachrichten, die sich ansammeln können, aber sie unterliegen der konfigurierten Aufbewahrungsfrist der Warteschlange.

Ein gleichbleibend hoher Wert kann auf eine unzureichende Versorgung der Verbraucher oder auf eine festgefahrene Verarbeitungslogik hindeuten.

Diese Metrik kann helfen, Ineffizienzen im Abfrageverhalten oder zu wenig ausgelastete Consumer-Instances zu identifizieren.

Hohe Werte können auftreten, wenn die Warteschlange leer ist, der Verbraucher kurze Abfragen verwendet oder Nachrichten schneller verarbeitet werden, als sie produziert werden.

Dies ist kein genauer Indikator für den Status der Warteschlange. Es spiegelt das Verhalten auf der Serviceseite wider und kann Wiederholungsversuche beinhalten.

SQS dedupliziert Nachrichten auf der Grundlage des MessageDeduplicationId oder inhaltsbasierten Hashings (falls aktiviert).

Ein hoher Wert kann darauf hinweisen, dass ein Producer innerhalb des 5-minütigen Deduplizierungsfensters wiederholt dieselbe Nachricht sendet.

Verwenden Sie diese Metrik, um Fehler bei redundanter Producer-Logik zu beheben oder um zu bestätigen, dass die Deduplizierung wie vorgesehen funktioniert.

Diese Metrik zählt alle erfolgreichen Löschvorgänge — auch wenn dieselbe Nachricht mehrmals gelöscht wird.

Zu den häufigsten Gründen für Werte, die über den Erwartungen liegen, gehören:

Verwenden Sie diese Metrik, um den Erfolg der Nachrichtenverarbeitung zu verfolgen, aber behandeln Sie sie nicht als exakte Anzahl eindeutiger gelöschter Nachrichten.

Dazu gehören alle Nachrichten, die an Verbraucher zurückgegeben werden, einschließlich der Nachrichten, die aufgrund des Zeitlimits für die Sichtbarkeit später wieder in die Warteschlange zurückgeschickt werden.

Eine einzelne Nachricht kann mehrfach empfangen werden, wenn sie nicht gelöscht wird. Dies kann dazu führen, dass diese Metrik die Anzahl der gesendeten Nachrichten übersteigt.

Verwenden Sie diesen Wert, um die Aktivitäten der Verbraucher zu verfolgen. Behandeln Sie ihn jedoch nicht als Anzahl der verarbeiteten eindeutigen Nachrichten.

Manuelle Anrufe an SendMessage oder SendMessageBatch werden gezählt, auch solche, die direkt auf einen DLQ abzielen.

Nachrichten, die automatisch in einen DLQ verschoben werden, nachdem sie den Wert überschritten haben, maxReceiveCount sind in dieser Metrik nicht enthalten.

Daher NumberOfMessagesSent kann dieser Wert niedriger sein als NumberOfMessagesReceived — insbesondere dann, wenn viele Nachrichten im Hintergrund aufgrund von Redrive-Richtlinien an DLQs verschoben werden.

Diese Metrik wird erst in der CloudWatch Konsole angezeigt, wenn die Warteschlange ihre erste Nachricht erhält.

Verwenden Sie diese Metrik, um die Größe jeder Nachricht in Byte zu verfolgen. Dies ist nützlich, um Nutzlasttrends zu analysieren oder die Durchsatzkosten abzuschätzen.

Die maximale Nachrichtengröße für SQS beträgt 1 MiB.

Hilft bei der Identifizierung potenzieller Noisy-Neighbor-Probleme in Umgebungen mit mehreren Mandanten, indem Nachrichtengruppen nachverfolgt werden, die unverhältnismäßig viele Ressourcen verbrauchen.

Verwenden Sie diese Metrik, um Alarme einzurichten, die ausgelöst werden, wenn die Anzahl der lauten Gruppen Ihren akzeptablen Schwellenwert überschreitet. Dies weist auf potenzielle Probleme mit der Warteschleife hin.

Bietet Einblick in den Warteschlangenrückstand für Nachrichtengruppen mit Standardgeschwindigkeit, ausgenommen Nachrichten von lauten Nachbarn.

Hilft dabei, den tatsächlichen Verarbeitungsrückstand für typische Nachrichtengruppen zu ermitteln, indem die Auswirkungen lauter Nachbarn herausgefiltert werden.

Verfolgt Nachrichten während des Fluges (die verarbeitet, aber noch nicht gelöscht werden) aus Nachrichtengruppen, die sich gut verhalten.

Verwenden Sie diese Metrik, um den Verarbeitungsdurchsatz normaler Nachrichtengruppen zu überwachen und Verarbeitungsengpässe zu erkennen, die nicht durch laute Nachbarn verursacht werden.

Hilft bei der Überwachung des verzögerten Nachrichtenrückstands von Nachrichtengruppen mit normalem oder erwartetem Durchsatzmuster (im Gegensatz zu Gruppen mit hohem Volumen oder lauten Nachrichten)

Nützlich, um zukünftige Verarbeitungsanforderungen und die Kapazitätsplanung für typische Workloads zu verstehen.

Wird zur Überwachung der SLA-Einhaltung und zur Erkennung von Verarbeitungsengpässen in Nachrichtengruppen mit normalem oder erwartetem Durchsatzmuster verwendet (im Gegensatz zu Nachrichtengruppen mit hohem Volumen oder hohem Rauschen, die andernfalls die Metrik verzerren könnten).

Verwenden Sie diese Metrik, um Alarme für Timeouts bei der Nachrichtenverarbeitung einzurichten, bei denen künstlich gealterte Nachrichten von lauten Nachbarn ignoriert werden.