[ 
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901262&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901262
 ]

ASF GitHub Bot logged work on ARTEMIS-4579:
-------------------------------------------

                Author: ASF GitHub Bot
            Created on: 23/Jan/24 19:23
            Start Date: 23/Jan/24 19:23
    Worklog Time Spent: 10m 
      Work Description: jsmucr commented on PR #4752:
URL: 
https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1906776157

   And as I was composing my previous post, I realized that maybe it's not the 
idea but the approach that we couldn't agree upon!
   
   > Can't you get this by listScheduledMessages on the control?
   
   That's pretty close actually. In order to be able to monitor the entire 
cluster via Zabbix I've created sort of a JMX proxy which collects and exposes 
data from all nodes at once. That proxy is also capable of calling methods, and 
exposing their results as custom JMX attributes.
   
   ---
   
   So basically, the issue you have with the `*FirstMessage*` API is that it's 
a set of attributes, not a set of operations, right?




Issue Time Tracking
-------------------

    Worklog Id:     (was: 901262)
    Time Spent: 2h 40m  (was: 2.5h)

> Add the *FirstMessage* API for scheduled messages
> -------------------------------------------------
>
>                 Key: ARTEMIS-4579
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-4579
>             Project: ActiveMQ Artemis
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 2.31.2
>            Reporter: Jan Å mucr
>            Priority: Major
>             Fix For: 2.32.0
>
>          Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> Alerting on issues with messages not being received properly for a period of 
> time is an uneasy task. We use the {{getFirstMessageAge()}} command to 
> trigger alerts in Zabbix, and it works as long as there are no consumers.
> But this approach fails when there are consumers repeatedly failing to 
> receive a message. That message is getting scheduled for redelivery over and 
> over, and even though there still is an old message in the queue to be 
> reported, it's no longer visible via {{getFirstMessage*()}} API.
> The goal here is to add a set of functions working with messages scheduled 
> for delivery:
> {noformat}
> getFirstScheduledMessageAsJSON()
> getFirstScheduledMessageTimestamp()
> getFirstScheduledMessageAge()
> {noformat}
> It may be not the most effective approach but it's quite a convenient one, 
> especially when monitoring a wide set of queues, each with its own set of 
> alerts.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to