CLI · BefehleQueues & Streams

Queues & Streams

Nachrichten auf einem bereitgestellten Broker veröffentlichen, ansehen und leeren.

eqs mq arbeitet gegen einen Broker, den Sie über den Marketplace bereitgestellt haben. Dieselbe Hülle wie bei eqs db — die api hält die Zugangsdaten, prüft die Berechtigung und protokolliert, was gelaufen ist — und bewusst andere Verben, denn eine Queue hat keine Zeilen zum Abfragen.

eqs mq queues <svc>

Was der Broker enthält. Streams bei NATS; bei AMQP abgelehnt, das nicht auflisten kann.

--jsonReines JSON
shell
eqs mq queues events
eqs mq peek <svc> <Ziel>

Liest Nachrichten, ohne sie zu konsumieren — soweit der Broker das zulässt.

--limit <n>Nachrichten vor dem Abschneiden (Standard 100)
shell
eqs mq peek orders dead-letter --limit 5
eqs mq consume <svc> <Ziel>

Nimmt Nachrichten herunter. Sie kommen nicht zurück.

--limit <n>Wie viele
--jsonReines JSON, zum Umleiten in eine Datei
shell
eqs mq consume orders dead-letter --limit 10 --json > geleert.json
eqs mq publish <svc> <Ziel> <Inhalt>

Legt eine Nachricht auf eine Queue oder ein Subject.

shell
eqs mq publish events orders.created '{"id":42}'
eqs mq purge <svc> <Ziel>

Verwirft alles, was darauf liegt. Verlangt data.ddl.

shell
eqs mq purge orders dead-letter

Hineinschauen ist nicht überall kostenlos

Das ist der Teil, den man vor dem Einsatz in Produktion lesen sollte.

BrokerWas ein peek bewirkt
NATSNichts. JetStream liest die Nachricht über ihre Sequenz und lässt sie genau dort, wo sie war. Sie können denselben Stream den ganzen Tag ansehen
AMQPEr fasst sie an. Das Protokoll kennt kein Ansehen ohne Nehmen: jede Nachricht wird geholt und zurückgelegt, und RabbitMQ markiert sie als erneut zugestellt
Bei AMQP erhöht jeder peek den Zustellzähler. Alles, was auf Wiederzustellungen achtet, sieht einen Versuch, und ein Consumer mit Retry-Limit ist einen Versuch näher daran, diese Nachricht aufzugeben. Das wiegt vor allem bei einer Dead-Letter-Queue schwer, also genau dort, wo man zu peek greift — deshalb gibt der Befehl eine Warnung aus, statt Sie es vom Consumer erfahren zu lassen, der aufgegeben hat.

Das Ergebnis nennt immer, welcher der beiden Fälle eingetreten ist, damit ein Skript sie unterscheiden kann.

Berechtigungen

VerbVerlangtWer sie hat
queues, peekdata.readReader, Contributor, Owner
consume, publishdata.writeContributor, Owner
purgedata.ddlOwner

purge ist keine Strukturänderung, data.ddl mag also nach dem falschen Ort aussehen. Es ist der richtige: diese Berechtigung existiert, weil eine Zeile zu ändern und eine Tabelle zu löschen nicht dasselbe Risiko sind — und eine Produktions-Queue zu leeren gehört zur zweiten Sorte. Ein Contributor kann die Queue mit consume Nachricht für Nachricht leeren und bekommt zurück, was er genommen hat; was er nicht kann, ist alles auf einmal wegzuwerfen.

Was der jeweilige Broker nicht kann

Beide Grenzen werden beim Namen genannt statt mit einem leeren Ergebnis beantwortet, denn „Sie haben keine Queues" ist eine falsche Antwort und keine leere.

  • AMQP listet keine Queues. Das gehört nicht zum Protokoll — es steckt in RabbitMQs Management-HTTP-API, auf einem anderen Port hinter einer anderen Zugangsberechtigung. Nennen Sie die Queue: eqs mq peek <svc> <queue>.
  • NATS braucht JetStream für alles außer publish. Reines NATS speichert nichts: eine Nachricht ohne Abonnenten ist weg, es gibt also nichts anzusehen, zu leeren oder zu verwerfen.

Das Protokoll

Jede Operation wird protokolliert: wer sie ausgeführt hat, gegen welchen Broker, welche Queue und wie lange sie gedauert hat. Der Inhalt der Nachrichten nicht, aus demselben Grund wie die --param-Werte bei eqs db — er ist der Teil, der am ehesten personenbezogene Daten trägt.

Zurück
Servicedaten