Bug 1053187 - JBossAS7 plugin does not include "Count Delta" metric for message queues
Summary: JBossAS7 plugin does not include "Count Delta" metric for message queues
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Plugin -- JBoss EAP 6
Version: JON 3.1.2,JON 3.2
Hardware: All
OS: All
unspecified
high
Target Milestone: ---
: ---
Assignee: Libor Zoubek
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-14 19:55 UTC by Marc Shirley
Modified: 2018-12-04 16:58 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-17 23:28:44 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 675783 0 None None None Never

Description Marc Shirley 2014-01-14 19:55:19 UTC
Description of problem:
The Messaging Service->HornetQ Service->JMS Queue Service->"Count Delta" metric for message queues does not exist in the JBossAS7 plugin, though the metric does exist for message queues in the JBossAS5 plugin.  This results in no method of being able to determine when a queue is no longer receiving new messages for purposes such as alerting.  

Version-Release number of selected component (if applicable):
JBoss ON 3.1.2
JBoss ON 3.2.0

How reproducible:
Very

Steps to Reproduce:
1. Navigate to JBoss AS 7 or EAP 6.0 resource
2. Navigate to Messaging Service
3. Navigate to HornetQ Service
4. Navigate to JMS Queue Service
5. Navigate to a JMS queue
6. Click on Schedules
7. Verify the metric "Count Delta" does not exist

Actual results:
No metric exists for monitoring the rate of new messages coming to the queue for alerting purposes.

Expected results:
"Count Delta" metric should be available.

Additional info:
The metric appears to exist in the HornetQ service so the issue looks to be with the plugin's defined metrics.

Comment 1 Libor Zoubek 2014-04-02 12:30:09 UTC
Hello marc, I am not able to find "Count Delta" metric on hornetq server. 

I am using EAP 6.2.GA, I've set message-counters-enabled to true on my hornetq instance - and it does not seem to have effect.

This is what I get from jboss-cli, AFAIK JON 3.2.0 already exposes all these metrics
[standalone@localhost:9999 jms-queue=xxx] :read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "consumer-count" => 0,
        "dead-letter-address" => "jms.queue.DLQ",
        "delivering-count" => 0,
        "durable" => true,
        "entries" => ["java:/queue/xxx"],
        "expiry-address" => "jms.queue.ExpiryQueue",
        "message-count" => 0L,
        "messages-added" => 0L,
        "paused" => false,
        "queue-address" => "jms.queue.xxx",
        "scheduled-count" => 0L,
        "selector" => undefined,
        "temporary" => false
    }
}

I even tried to connect via JMX but the information reported by JMS Queue MBean is same as above.

Comment 2 Marc Shirley 2014-04-02 23:36:34 UTC
I haven't checked through the CLI myself.  My initial assumption that it should exist was based on API information such as [1].  I had assumed that since it was available in the API and was exposed in previous versions of EAP, it should be exposed in the 6.x versions.

[1] https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6.2/html-single/API_Documentation/files/javadoc/org/hornetq/core/messagecounter/MessageCounter.html

Comment 3 Larry O'Leary 2014-06-13 00:12:07 UTC
Deferring this to JBoss ON 3.3 payload.

We should probably first understand the use case for "Count Delta" and whether an existing metric from HornetQ already provides such information. If it doesn't and the use case is valid, then an enhancement request is required on the JBoss EAP and HornetQ components. Once such a metric is made available, the JBoss EAP management plug-in can then add the metric.

Comment 4 Larry O'Leary 2014-12-17 23:28:44 UTC
Closing as NOTABUG.

There does not appear to be a clear use case provided to demonstrate the need for a countDelta. 

Furthermore, reading the API such a metric is exposed by a getCountDelta method. The purpose of this method is to return a count since the last execution of the method. This does not fit into the management or monitoring system as this data is already being captured via the getCount metric and as it is a trendsup type, a per minute value is already provided and therefore a delta is not needed. I suppose you could think of the messages per minute metric as the delta.


Note You need to log in before you can comment on or make changes to this bug.