Queue idle_since attribute behavior change between 3.6 and 3.7

[Laurent Luce]

Hello,

We rely on the queue idle_since attribute to get an idea of when the last message was added to the queue or consumed from the queue.  With 3.6, it seems to report the date and time accurately.  We noticed that with 3.7.19, the idle_since value is always the current time (or very close to) even if we know no activity happened on the queue for days.  Did the implementation change?  We are using 3.7.19 with Erlang 22.0.2.  Web-stomp to the queues.

Laurent

[Laurent Luce]

Is there another option using the management API to get the latest activity timestamp for a specific queue?

[Girish Sivasubramanian]

HI All,

  

 I wanted to check if there is a guidance on why the Idle time keeps changing.

Thanks,

Girish

[Luke Bakken]

Hi everyone,

This issue came up recently, and we have provided a response here: https://github.com/rabbitmq/rabbitmq-management/issues/766

This will not be addressed. The metric you are looking at will always include internal queue process activities which change from version to version as we see fit. It does not and never has meant consumer activity. This also means you should not depend on this metric for anything. It's an implementation detail that leaked years ago. Use consumer message rates metrics instead. 

[Szymon Bluma]

What is "consumer message rate"?

At `http://localhost:15672/api/queues/%2f/{queue_name}` I do not see any usable value like "idle time".

My scenario:

With queue idle time I was closing/killing a consumer after a few hours of idle.

[Michael Klishin]

Consumer delivery rate is a queue metric, see [1][2].

The metric you were using is a leaked piece of implementation detail. Your consumer can keep track of its own "activity"

(e.g. last delivery processing time) and shut down as needed. This has several benefits:

 * Your application decides what to do based on the information available to it

 * Some instances can choose to shut down, others can choose to stay up

 * It's significantly less likely that this logic will be affected by future RabbitMQ releases, while available metrics or how exactly they are computed can be

If you have to use RabbitMQ queue metrics, they can be retrieved using the HTTP API.

That's what "autoscaling" tools use, using messages in Ready state or rates as their decision making factor.

1. https://www.rabbitmq.com/monitoring.html

2. https://www.rabbitmq.com/monitoring.html#queue-metrics

3. https://www.rabbitmq.com/prometheus.html

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/8a01f350-396d-4bdc-9c90-82884cf6a7f3%40googlegroups.com.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ