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