[
https://issues.apache.org/jira/browse/ARTEMIS-4579?focusedWorklogId=901259&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-901259
]
ASF GitHub Bot logged work on ARTEMIS-4579:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 23/Jan/24 19:13
Start Date: 23/Jan/24 19:13
Worklog Time Spent: 10m
Work Description: jsmucr commented on PR #4752:
URL:
https://github.com/apache/activemq-artemis/pull/4752#issuecomment-1906753969
Okay, perhaps I'm not clear enough on what I'm trying to achieve here. And I
understand your concerns, so I'll be glad for just another simple solution of
my problem if you can think of any.
Here's the use case:
* There's a SLA for every file we run through the broker. It's crucial to
know there's a message running around for 10 minutes while it was supposed to
leave our system 5 minutes ago. Then there's a five minute trigger which puts
us on guard but it's quite common for individual consumers to run into issues
with remote customer services (such as connection or gateway timeouts), and
it's likely for a warning to disappear before we hit the 10-minute alert.
* There's a 24/7 first level support without any access to underlying
systems except for those alerts. These people wake us up at night based on what
an alert says. If it says 5 minutes, they wait (_because it's yellow_), once it
hits 10 minutes, we already know there's something to take a look at.
* In order to figure out which message is the oldest one that cannot be
delivered, we need to look (all sleepy and grumpy) at it's metadata. Currently,
this basically means to pause the queue, because the GUI doesn't display
messages-in-flight. The time is running out, so a GUI is a must. Unless, of
course, there's an attribute, which directly shows the metadata and allows one
to act quickly.
Issue Time Tracking
-------------------
Worklog Id: (was: 901259)
Time Spent: 2.5h (was: 2h 20m)
> 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: 2.5h
> 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)
