Jesse Becker wrote: > A few notes: > > * There are a few places where I see negative values, that I think > should be caught by the RPN calculations. Here's an example: > http://bayimg.com/EAEdDaACF > These negative value's occur when there are datapoints missing in the RRD's. Somehow rrdtool sometimes interprets the missing data gaps as some random negative values. This is something weird in rrdtool.
Probably that could be solved with a RPN calculation, using the ADDNAN
arithmetic or something similar, I'm not exactly sure. The question is
if you want to make the step to extensive RPN calculations, while you
can almost immediately see with common sense that it will always be zero
for these situations.
> * Are the full Now/Max/Avg/Min stats really needed for all of the
> metrics? I am thinking mostly of metrics that are generally
> static--such as node count and total RAM installed.
>
For uniformity's sake I changed them all to display the same behavior. I
can imagine some people might like to see an average node/ram count, for
example with dynamic virtual clusters that power up nodes based on demand.
Changing it to only display stats "sometimes" seems a bit strange in
relation to uniformity. How do you decide which values are important and
which aren't, where do you draw the line? There is no way we can have
insight in every possible setup or situation that might trigger interest
in other values. It is easier to just do the same thing for every value.
The other side of the story is that the formatting/alignment will be a
even bigger challenge if you only enable the stats for some values in
the graph and not all of them.
> There are still a few alignment issues with the chart sizes; they are
> related to the different number of lines of text in each chart (yes,
> it's a pain, I know...). It's possible that they could be addressed
> more easily with newer versions of rrdtool (which can specify the size
> of the image, and scale the chart to fit).
Three possibilities;
- require rrdtool>=1.3.0 which has the --full-size-mode option
- set HEIGHT tags on the IMG's in the html .tpl's; this will maintain
aspect ratio, but might look a little funny due to resized pixels
- ignore it (I personally don't find it that annoying)
> * The graph sizes when "$graphreport_stats = false" are misaligned. I
> think that the code is resizing the graphs, regardless of the number
> of lines of text used in the legend.
>
I can fix this, if this is considered annoying. Probably related to some
string formatting done in my patch.
> And a general question to the list:
> * When "$graphreport_stats = false", should the behavior be to remove
> all stats from the graph and have a minimalist view of the data, or to
> show the more limited "condensed" view as currently in trunk?
>
> Of course, the current 3.1.x stable code doesn't show any stats, which
> some people may like. How to people feel about that option as well?
> Essentially, conf.php will have "$show_stats" option, with possible
> values of {no,yes, extended}. These would correspond respectively to
> the behavior of 3.1.x, trunk, and Ramon's patch.
That way resulting in "stats = yes" to enable your version of the stats
and "stats = extended" to my version of the stats. Well that is one
possibility, it depends on what people like as behavior. Either way, by
that rational we should keep the default behavior to "no", since that is
what 3.1 looks like now (no stats). I would say pick one of the two and
not over complicate things by having too many variations. The
formatting/alignments are a challenge either way, having too much
options only makes that more challenging.
We have to keep in mind that these are "graph.d" customizable reports.
Any user might replace these files anyway, regardless of what is shipped
with Ganglia, since this is now much easier in Ganglia 3.1.
Let me know what you would like.
Cheers,
- Ramon.
--
R. Bastiaans, B.ICT :: Systems Programmer, HPC&V
SARA - Computing & Networking Services
Science Park 121 PO Box 94613
1098 XG Amsterdam NL 1090 GP Amsterdam NL
P.+31 (0)20 592 3000 F.+31 (0)20 668 3167
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
_______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
