RHQ Charting Replacement
Jay Shaughnessy
jshaughn at redhat.com
Thu Oct 18 16:20:34 UTC 2012
On 10/18/2012 5:32 AM, Heiko W.Rupp wrote:
> Mike,
>
> this is great stuff, thanks for assembling it.
>
> In your table I am missing a use case that we did not have yet (*1)
>
> - have a dashboard only displaying various metric graph portlets - perhaps even with availability overlaid as colored areas --
> perhaps even with the timeline included as you suggest in your assessment
> - allow to show more than one value ("srmm") in one of the "normal" graphs (not the big popup thing)
>
> Did you also look into group charts?
> In the past there were also charts for single metrics of comp groups ("mrsm")
>
> And then I would really love to see the possibility to have the user add a formula to compute the values shown (*2).
>
> In "the good old days" :-) we decided to not draw lines between data points (this especially applies to chart 'e'), as this may
> indicate some intermediate values to the user that we may not know about.
> Chart a) seems to honor that in some places where dots are not connected; also the individual data points are clearly marked
> as donuts.
>
> 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.
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.
> Thanks again
> Heiko
>
>
> *1) JON1 actually had such pages with mini-charts
> *2) I know that this is complicated just by the fact that the various metrics involved don't necessarily have the same schedule.
>
> Am 12.10.2012 um 00:51 schrieb mike thompson:
>
>> Hi All,
>>
>> Although the RHQ charting rewrite is underway, we decided to take a step back and look holistically at the changes and explicitly bring to light exactly what we have in the current system and what steps we are proposing to implement.
>>
>> Attached are two documents. The first is the 'RHQ Charting Assessment' that is an inventory of what charts we have where and what they represent. Additionally in the document are the immediate future steps of things we are trying to resolve with the chart replacement. The second document is the 'RHQ Charting Gallery' which is just a visual supplement for first document showing the actual charts.
>>
>> -- Mike
>>
>> <RHQ Charting Assessment.pdf>
>> <RHQ Chart Gallery.pdf>_______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/rhq-devel/attachments/20121018/0066acd9/attachment-0001.html>
More information about the rhq-devel
mailing list