Bug 536401 (RHQ-754)

Summary: "Get current values" button should trigger a fetch of the current metrics from the agent
Product: [Other] RHQ Project Reporter: Heiko W. Rupp <hrupp>
Component: MonitoringAssignee: John Mazzitelli <mazz>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: ccrouch, cwelton, jpviragine, mazz, mfoley
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: All   
URL: http://jira.rhq-project.org/browse/RHQ-754
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-03 17:00:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 585306, 678340    

Description Heiko W. Rupp 2008-08-25 10:04:00 UTC
The get current data button on the metric data tab seems to indicate, that it triggers getting the current data values from the agent/managed resource. In reality it only triggers a page refresh.

We should add the functionality to actually really go to the managed resource - outside of an installed schedule - to gather the data.

See also http://forums.rhq-project.org/viewtopic.php?f=4&t=84

Comment 1 Joseph Marques 2008-08-25 21:29:12 UTC
but, heiko, what happens if you're viewing metric data for a compatible group that just so happens to modestly span, say, 25 agents.  do we really expect the server to go contact all known agents and wait until all data is available before displaying the page?

also, how will this work in the HA world?  each server is only going to have direct access to a subset of all known agents in the system as part of the way it natural load balances.

Comment 2 Heiko W. Rupp 2008-09-13 12:35:14 UTC
I think it could be a compromise to only allow this for single resources and not for groups. 

Groups are sort of special anyway, as in normal operation no two metrics from different resources will arrive at the same time.

This "trigger a fetch" is something that comes up every now and then from customers and users - the current behavior is erratic. The 'fake' solution would be to rename the button to 'redraw'.

HA makes things indeed somewhat more difficult. How does updating the metric schedule on server 1 work when the agent is on server 2? In this case, there needs to be some communication between servers too, as we can't wait until the agent perhaps connects to server 1 for this.

Comment 3 Len DiMaggio 2008-10-09 18:04:22 UTC
This issue will cause confusion for SOA-P users - the legacy ESB mgmt console does allow for async collections of stats:

   https://jira.jboss.org/jira/browse/SOA-929

So - can we get it fixed?   ;-)



Comment 4 John Mazzitelli 2008-10-21 12:44:23 UTC
once this is implemented, the label of the button should also change to say "Get Live Values" as opposed to "Get Current Values".

Comment 5 Red Hat Bugzilla 2009-11-10 21:16:16 UTC
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-754


Comment 6 wes hayutin 2010-02-16 21:10:09 UTC
Mass move to component = Monitoring

Comment 7 John Mazzitelli 2011-02-17 17:09:56 UTC
i will take a look to see what can be done.

Comment 8 John Mazzitelli 2011-02-22 21:58:54 UTC
I have gwt-ified the Measurement>Tables subtab. And there is now a "Get Live Data" button on it. You select one or more metrics in the table and you click the button to pop up a dialog that contains a table of the metrics with their live data as retrieved from the agent.

Comment 9 Mike Foley 2011-05-03 19:58:53 UTC
verified RHQ 4.0 community release, as follows:  on Monitoring, Tables sub-tab ... there is the both Refresh (to reload the page), and Get Live Data ... to get live data from the agent.  Both seem to work.  When I click Get Live Data on a volatile resource (User Load on the RHQ Agent) I see the numbers changing each time.

Comment 10 Heiko W. Rupp 2013-09-03 17:00:49 UTC
Bulk closing of old issues that are in VERIFIED state.