On Oct 18, 2012, at 9:30 AM, "Larry O'Leary" <loleary(a)redhat.com>
wrote:
On Thu, 2012-10-18 at 12:20 -0400, Jay Shaughnessy wrote:
> On 10/18/2012 5:32 AM, Heiko W.Rupp wrote:
>
>> With respect to live data, I have mixed feelings
>> - they are clearly useful, as in some scenarios users don't want to wait 20
mins for data points when debugging and also don't
>> want to go through the hassle to modify schedules
>> - having many live data portlets on a dashboard, may impose a huge load on the
whole RHQ system plus managed resources,
>> as it clearly bypassing all the logic we have developed to keep load low (perhaps
we can in the future go down to 10sec
>> schedules and thus not needing live charts anyway) -- here the auto-update of an
existing chart when new data comes in seems
>> more important (to me).
> I think I'd like to see the "live" data approach go away in favor of
> simplifying the product to some degree, hopefully making it more clear
> to the user how things work and what they are seeing. We have the
> metric collection schedule mechanism, and users can use that to tune
> things, pulling data as they see the need. Live graphing, which is
> not really "live" or "real-time", just more near-real-time than
> perhaps the schedule is set for, is a totally different mechanism that
> works against the set schedules, the expected perf, and the work being
> done on the agent. And initiates, iirc, direct requests from server to
> agent.
+1 - Although I think the "Get Live Value" button on a metric table or
even the schedules page should be a necessity, I do not think live
metric charts are a good idea.
I agree as well having multiple sources of the same data can lead to confusion when trying
to reconcile the two. As Larry mentioned the "Get Live Value" button can still
be used to find out if things are going haywire, but the charting of these metrics is
unnecessary given other more standard means of charting data.
> Alternatively I'd favor more integration between charts and schedules,
> if necessary. For active graphs let them show the current schedule
> and auto-refresh based on that. And provide a hook to update the
> schedule if say the user wants to speed it up.
+1 - I like this idea a lot. From a UI perspective, the user now gets
auto-refresh based on when data is actually available instead of having
to guess. Additionally, chart rendering and scale might make more sense
to the user and establish the connection between metric collection and
the collection interval defined by the metric schedule.
+1 Again, this is another more consistent way of refreshing and managing the metric
schedule for "standard" metric charts.
--
Larry O'Leary
https://plus.google.com/u/0/112645929986009801513
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel