CLI · ComandosColas & streams

Colas & streams

Publicar, inspeccionar y vaciar mensajes en un broker desplegado.

eqs mq trabaja contra un broker que desplegaste desde el marketplace. El mismo sobre que eqs db — la api guarda las credenciales, comprueba el permiso y registra lo que se ejecutó — y verbos deliberadamente distintos, porque una cola no tiene filas que consultar.

eqs mq queues <svc>

Lo que guarda el broker. Streams en NATS; rechazado en AMQP, que no sabe listar.

--jsonJSON en crudo
shell
eqs mq queues events
eqs mq peek <svc> <destino>

Lee mensajes sin consumirlos — hasta donde el broker lo permita.

--limit <n>Mensajes antes de truncar (por defecto 100)
shell
eqs mq peek orders dead-letter --limit 5
eqs mq consume <svc> <destino>

Retira los mensajes. No vuelven.

--limit <n>Cuántos retirar
--jsonJSON en crudo, para redirigir a un archivo
shell
eqs mq consume orders dead-letter --limit 10 --json > vaciado.json
eqs mq publish <svc> <destino> <cuerpo>

Pone un mensaje en una cola o subject.

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

Descarta todo lo que hay. Exige data.ddl.

shell
eqs mq purge orders dead-letter

Asomarse no siempre sale gratis

Esta es la parte que conviene leer antes de usarlo en producción.

BrokerQué hace un peek
NATSNada. JetStream lee el mensaje por secuencia y lo deja exactamente donde estaba. Puedes asomarte al mismo stream todo el día
AMQPLo toca. El protocolo no tiene mirar sin llevarse: cada mensaje se obtiene y se devuelve, y RabbitMQ lo marca como reentregado
En AMQP, cada peek sube el contador de entregas. Cualquier cosa que vigile reentregas ve un intento, y un consumidor con límite de reintentos queda un intento más cerca de rendirse con ese mensaje. Eso pesa sobre todo en una dead-letter queue, que es justo donde se recurre al peek — por eso el comando imprime un aviso cuando ocurre, en vez de dejar que lo descubras por el consumidor que se rindió.

El resultado siempre indica cuál de los dos casos te tocó, para que un script pueda distinguirlo.

Permisos

VerboExigeQuién lo tiene
queues, peekdata.readReader, Contributor, Owner
consume, publishdata.writeContributor, Owner
purgedata.ddlOwner

purge no es un cambio de estructura, así que data.ddl puede parecer el sitio equivocado. Es el correcto: ese permiso existe porque editar una fila y borrar una tabla no son el mismo riesgo, y vaciar una cola de producción es del segundo tipo. Un Contributor puede vaciar la cola mensaje a mensaje con consume, que devuelve lo que se llevó; lo que no puede es descartarlo todo de una vez.

Lo que cada broker no puede hacer

Ambos límites se responden por su nombre, y no con un resultado vacío, porque "no tienes colas" es una respuesta equivocada y no una respuesta nula.

  • AMQP no lista colas. No forma parte del protocolo — está en la API HTTP de gestión de RabbitMQ, en otro puerto y con otra credencial. Nombra la cola: eqs mq peek <svc> <cola>.
  • NATS necesita JetStream para todo menos publish. NATS a secas no guarda nada: un mensaje sin suscriptor desapareció, así que no hay nada que mirar, vaciar ni descartar.

El registro

Toda operación queda registrada: quién la ejecutó, contra qué broker, qué cola y cuánto tardó. El cuerpo de los mensajes no, por la misma razón que los valores de --param en eqs db — es el contenido con más probabilidad de llevar datos personales.

Anterior
Datos del servicio