Timestamp for oldest message on a queue

Linus

Is there some simple way to get the timestamp of the oldest message on given queue with semp? For example is the list of message in getMsgVpnQueueMsgs ordered (see below)? Or can it be? Obivously the broker knows what first first message to be poped on a given queues is.

https://docs.solace.com/API-Developer-Online-Ref-Documentation/swagger-ui/software-broker/monitor/index.html#/queue/getMsgVpnQueueMsgs

Aaron

Hi @Linus. Check this thread: https://solace.community/discussion/1749/whether-the-queue-messages-objects-returned-in-the-semp-response-list-follow-a-specific-order

Linus

Since monitoring tooling provied is very limited (read broken) then we need this kind of functionality, if it does not work that is fine then we need to do something else more complex.

It is strange however that broker client is not using the same semp api as being exposed...

Aaron

Since monitoring tooling provied is very limited (read broken) 

What monitoring tooling are you referring to?

Are you looking to get this information on a regular basis, across all queues? For example, something like: query all queues every 60 seconds and determine the oldest message on each; raise alert if greater than 3 minutes. Something like that?

It is strange however that broker client is not using the same semp api as being exposed...

I don't understand. "Broker client" means a messaging client to me, a publisher/consumer of messages. The SEMP API is for management of the broker: configuration and monitoring. These are very different things. Can you explain more?

Thanks!

Linus

PubSub+ Monitor is the tool I am referring to.

So what we want is being able to plugin parts of the semp api into our regular existing monitoring instead new tools of uncertain quality. For that we need to be able to expose certain things in a controlled way so each team does not need to look into the semp api in detail. Timestamp of the oldest message is good data point. Also the broker really should be able to quickly find that message since it is the next message to expose to the client...

This just side note.

A web browser is also a client, sorry for being unclear. The admin view of the broker oes not use the regular SEMP api but an api __private_monior__ in the path instead. There we can see properties like msgSpoolMsgCount which is not in the regular api for the similar endpoint. So the idea of using the inspecting the admin tool that shows most of what we want in an easy way falls to the side because of the lack of dogfooding.