chart types discussion

Andreas Dietrich adi at aspicon.de
Wed Nov 10 09:46:58 UTC 2010


  Hi Joseph,

thanks for your good questions and pointing more towards the use cases 
rather than the features itself.

I could make this pretty short: we hardly use the graphics indeed or at 
least not in an excessive or sophisticated way.

Of course it can be nice to view some time-based data, but I would say 
the vast majority of problems arise from wrong setups, maintenance work 
and resource limitations or are recognized by alerts that "watch" those 
time-based developments for me in the background (and they are purists 
as we know that don't like graphical data so much ;-)).
E.g. if I have some alerts setup for the User Load on some machines with 
"issue warning at 40%" and "issue critical alert at 60%" I will most 
likely directly look at the machine via SSH and in a first step via "ps 
-ef" or "top" (on Linux). On Windows machines I would have a look at the 
Task Manager.
So I would see no need to improve the existing charts at all because 
they would not help us, but would most likely slow things down or create 
potential new bugs.


availability-driven usage (Monitor=>* pages):

Nevertheless we most often have a look at the availability chart of 
resources (means we just go to the platform root->Monitor page). Here we 
may adjust the time settings or go directly to the other Monitor->* 
pages of interest, depending on where to get the best aggregated 
information we need (exact availability slots, min/avg/max measurement 
values, trait data, ...). After this you will most likely have a look at 
the agent.log or the machine or tunnel setup itself.


measurement-driven usage (Monitor=>Graphs):

If you recognize e.g. some higher load on a machine you may want to know 
if it is something that follows some pattern to take further actions 
(e.g. every work day between 8 and 9 pm, everytime the backup of data is 
done, ...).
Charts can help very much to visualize this, but it's a rather basic and 
easy thing to do in RHQ right now just adjusting the time frame and 
looking at the chart.
If you wan't to correlate the measurements you may click on another 
resource but we almost never use the more sophisticated charts that you 
can see and manipulate by clicking e.g. on the basic chart headers under 
Monitor=>Graphs=>(e.g. "Disk Reads Per Minute" on a mount point resource 
"/").

So I think it does not make sense to post those basic charts here that 
everybody can see looking e.g. at the CPU charts of some random machine.

I don't want to disappoint somebody, but I don't see the need for more 
advanced charting in RHQ right now...

The only thing that comes to my mind where this could be useful is when 
you need some documenting data/charts for some customer that they have 
to spend some more money on their equipment or applications in order to 
resolve bottlenecks, loose limitations or improve performance. But 
that's rather rare and existing RHQ charts would be sufficient for this.

For us it's a tool that
- should watch resources we would like to watch (different kinds),
- inform us when something goes wrong
- should be as efficient and effective as possible to manage the above 
two things (e.g. monitoring setup, alert management (setup, cleanup, 
documentation), overview and prioritization of problems, ...)
- to a minor extend: fast access to the resources current settings and 
historic resource values for investigating or identifying problems
=> That's the essence.

(for us) RHQ is NOT meant for or can't:
- fixing the problem (except an agent hangs and needs to be restarted 
via GUI ;-))
    ... unexpected problems by nature are most often new or special 
cases you do not know upfront and cannot react on by "standards"


I would be interested where other production users (you know or that you 
are) see benefits in advanced charting in RHQ.

Kind regards
Andreas :-)



On 11/10/2010 06:10 AM, Joseph Marques wrote:
> The more information you provide, the better.  One example of each chart
> you use would be great, along with a blurb that explains why and how the
> chart is used in real-world operations.  In other words, it's more
> useful to explain how you're interacting with the data to solve
> problems, find root causes, and/or investigate variances within your
> enterprise, than it is just to explain how the data is rendered.
>
> Also, please provide your perspective on relative usage and relative
> importance of each chart.  Importance aside, which charts do you tend to
> use the most and why?  Frequency of use aside, which do you find provide
> the most important data and why?
>
> Thanks in advance.
>
> On 10/29/2010 04:11 AM, Andreas Dietrich wrote:
>> It's no problem to provide you with charts. Please tell which type you would like to see and I can post it here.
>>
>> ----- Original Message -----
>> From: "Heiko W.Rupp"<hrupp at redhat.com>
>> To: rhq-devel at lists.fedorahosted.org
>> Sent: Thursday, October 28, 2010 5:12:20 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
>> Subject: Re: chart types discussion
>>
>>
>> Am 28.10.2010 um 16:38 schrieb Charles Crouch:
>>
>>> Like I said before we need to have some of these different chart types rendered with real world data sets and pixel areas.
>> Andreas,
>>
>> I know that you guys are dealing with real world data -- do you have good examples from your daily work for this?
>> Perhaps some anonymized screen shots?
>>
>>     Heiko
>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/rhq-devel
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list