jbertram commented on PR #4752:
URL: 
https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1905272950

   For awhile I've actually discouraged folks from using the "first message" 
metrics. [I discussed this on the ActiveMQ users 
list](https://lists.apache.org/thread/d79n3kbb28k2v4pm7y0kywb5xpvrmpf4) not 
long ago:
   
   > The `getFirstMessageAge` operation is actually fairly "heavy" and not 
generally recommended. Furthermore, the age of the first message isn't 
meaningful in and of itself in this scenario because if the `consumerCount` is 
0 then by definition no messages can be stuck. A robust stuck-message detection 
mechanism must, at the very least, verify that `consumerCount` > 0. Also, 
instead of using the age of the first message I recommend inspecting 
`messagesAcknowledged` over time. For example, if the `consumerCount` > 0 and 
`messagesAcknowledged` remains unchanged for 60 seconds then messages (or more 
likely *consumers*) may be stuck. If you're using Prometheus then I believe you 
can use a [range vector 
selector](https://prometheus.io/docs/prometheus/latest/querying/basics/#range-vector-selectors)
 for this kind of operation.
   
   At this point I'm against adding "first message" metrics for scheduled 
messages because it will be a relatively "heavy" operation due to the 
`synchronized` block. A lot of JMX monitoring tools will simply poll queue 
MBeans which means this new management method may be invoked *a lot*, 
especially on a broker with lots of queues. Over the last few years we've seen 
an increasing number of deployments with many thousands of queues. This is one 
reason we implemented (and generally recommend using) [pluggable 
metrics](https://activemq.apache.org/components/artemis/documentation/latest/metrics.html#metrics)
 which should provide a lighter footprint than JMX and open the door for easier 
integration with tools that specialize in graphing and alerting (e.g. 
Prometheus & Grafana).
   
   Would it be possible for you to use existing metrics to solve your problem 
rather than implementing this new management method?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to