| Summary: | wrong "Low" value in JBoss ESB Statistics metrics | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise SOA Platform 4 | Reporter: | Jaroslaw Kijanowski <kijanowski> | ||||||||
| Component: | Documentation, Monitoring and Management | Assignee: | Dana Mison <dmison> | ||||||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | |||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | high | ||||||||||
| Version: | 4.3 CR1 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | 4.3 GA | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| URL: | http://jira.jboss.org/jira/browse/SOA-957 | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2009-01-16 16:11:43 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Attachments: |
|
||||||||||
|
Description
Jaroslaw Kijanowski
2008-10-20 08:07:34 UTC
Attachment: Added: low.png Attachment: Added: 12.png Attachment: Added: 120.png Presumably the lowest value would be the value of the count from the first query to the server, whatever that happens to be. yep, thought about that too, but the default collection interval is 10 minutes, so this would mean that after the first ten minutes, since I've added the SOA-P to the inventory, 2669 messages has been sent. A little bit strange if you consider that I've imported it immediately. Anyway I try to reproduce this with a fresh installation later. I *think* the value was "6" at the very beginning, which would make sense. I'm not sure how JON would handle this but I would have expected it to make a query as soon as you had inventoried it. It may be that it does defer the collection, as you say. In any case it is the value in the ESB server that is relevant as it starts counting as soon as the server is running and will always increase, unless the counters are reset or wrap. As Kevin says, the lowest value of the count would be the first query to the server. If the SOA-P server was started in advance of the JON agent, then it may not be 0. The bytes processed differing is strange - that may be a symptom of http://jira.rhq-project.org/browse/RHQ-963, you may want to file a JBNADM bug against that. Without any JMX evidence, there's nothing here to suggest that this is a bug in the plugin. Question: "the value in the ESB server that is relevant as it starts counting as soon as the server is running and will always increase, unless the counters are reset or wrap" So - for this value ^ - we should be able to always check the value in the legacy ESB Mgmt console, right? (07:51:42 PM) mazz: ok, I think I get it... if you provide a timeframe LONGER than what our raw measurement tables contain, we query the compressed tables (07:51:55 PM) mazz: and the compressed tables don't have all the raw data points (07:52:18 PM) mazz: if you look at the graphs for the 120 days, its got a single data point, at the high number (07:52:39 PM) mazz: hence why the "low" shows you the high number - because currently, there is only a single data point in the compressed table (07:53:38 PM) mazz: I think this is "working as expected". I think as per design we are allowed to lose detailed information for old data (07:53:57 PM) ghinkle: correct (07:54:01 PM) joseph: jarek - this is by design. if you look at course grained time periods, the data gets less and less accurate. don't look for perfection at 120 days out, look for it at small scales. (07:54:37 PM) mazz: this makes for a good FAQ :) or documented somewhere (07:54:57 PM) mazz: explain raw measurement data, compressed measurement data and how you lose accuracy as the data ages (07:56:34 PM) mazz: actually, "lose accuracy" isn't the correct term (07:56:41 PM) mazz: the data is accurate for what it represents (07:57:06 PM) mazz: you just lose "fine-grained" data - in its place you get coarse-grained compressed data Just to confirm - this is a "vanilla" JON issue and is not specific to the ESB plugin, correct? If this is the case, the explanation should be in the JON docs - but - it will affect SOA-P users, so we should include this JIRA in the list of open bugs in 4.3 release notes. Assigned to Darrin, set documentation component, selected documentation 'affects' flag. Affects: Added: [Documentation (Ref Guide, User Guide, etc.)] Related RHQ jira is http://jira.rhq-project.org/browse/RHQ-999 "we should be able to always check the value in the legacy ESB Mgmt console, right? " If you check the MBean before/after the first poll from JON then I would expect the minimum value reported to lie somewhere between those values. note added Closing - it's listed in the 4.3 GA release notes and here: http://jira.rhq-project.org/browse/RHQ-999 |