Re: [Ganglia-developers] add extras parsing to json graph-definitions
On Thu, Jul 19, 2012 at 8:54 AM, Jochen Hein joc...@jochen.org wrote: Vladimir Vuksan vli...@veus.hr writes: I would define a scaling factor or some other variable. I do want to steer away from having tool specific options unless absolutely necessary. I agree that would be a useful goal, I just have no idea what I options I may need for my special problem [see my mail to ganglia-general]. I've had a look at the other PHP-reports. A couple of them pass the option '--rigid' to rddtool. Other used options are --logarithmic and --lower-limit. I've no idea how that could be mapped into json and keep the syntax and the parsing simple. Speaking as the one who wrote[1] a good chunk of the original modular report code, the idea for for the 'extras' variable is to allow the report writer to make whatever changes to make the graph look the way they want. This includes overriding the default settings. The various options cited, such as --rigid and --logarithmic, are perfect examples. Quoting from graph.php: /* The $extras variable is used for other arguemnts that may not * fit nicely for other reasons. Complicated requests for --color, or adding --ridgid, for example. * It is simply a way for the graph writer to add an arbitrary options when calling rrdtool, and to * forcibly override other settings, since rrdtool will use the last version of an option passed. */ Note that this *predates* JSON support, and when I wrote the code, there had been zero mention of any other backends other than rrdtool. It's worth nothing that a lot, perhaps even most, of the graphing code is rrdtool specific. However, I don't see any particular reason why the JSON code in graph.php should not make use of the 'extras' graph variable. Short of re-writing the graphing API (so to speak), this seems a reasonable solution in the short term. I agree with Vladimir that something generic is preferable, but I expect that something sufficiently generic won't be much use. We'll have a data structure that includes a handful of values for title, x/y label, and a massive string or array of all_the_other_options_for_this_graph_type. [1] Or screwed up horribly, take your pick. -- Jesse Becker -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] add extras parsing to json graph-definitions
On Thu, Jul 19, 2012 at 8:54 AM, Jochen Hein joc...@jochen.org wrote:
Vladimir Vuksan vli...@veus.hr writes:
I would define a scaling factor or some other variable. I do want to
steer away from having tool specific options unless absolutely
necessary.
I agree that would be a useful goal, I just have no idea what I options
I may need for my special problem [see my mail to ganglia-general].
I've had a look at the other PHP-reports. A couple of them pass the
option '--rigid' to rddtool. Other used options are --logarithmic and
--lower-limit. I've no idea how that could be mapped into json and keep
the syntax and the parsing simple.
I'd suggest something like:
options: {
logarithmic: true,
rigid: false,
lower-limit: 0
}
with sensible defaults. If it's ignored by another graphing toolkit,
that's fine.
Jeff
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] add extras parsing to json graph-definitions
On Jul 19, 2012, at 9:12 AM, Jeff Buchbinder wrote:
On Thu, Jul 19, 2012 at 8:54 AM, Jochen Hein joc...@jochen.org wrote:
Vladimir Vuksan vli...@veus.hr writes:
I would define a scaling factor or some other variable. I do want to
steer away from having tool specific options unless absolutely
necessary.
I agree that would be a useful goal, I just have no idea what I options
I may need for my special problem [see my mail to ganglia-general].
I've had a look at the other PHP-reports. A couple of them pass the
option '--rigid' to rddtool. Other used options are --logarithmic and
--lower-limit. I've no idea how that could be mapped into json and keep
the syntax and the parsing simple.
I'd suggest something like:
options: {
logarithmic: true,
rigid: false,
lower-limit: 0
}
with sensible defaults. If it's ignored by another graphing toolkit,
that's fine.
Silently ignoring unsupported options seems like a bad choice to me, because it
makes graph authoring troubleshooting more difficult. If someone uses an
unsupported option, we should blow up with an informative error message ASAP.
Think about when you've misspelled a configuration option (in any system, not
just gweb), and wasted a lot of time hunting for the cause of the odd results
you see - totally frustrating, and totally preventable.
More generally: The JSON format should be focused on making the simple common
cases easy. The format should be small, simple, easy to use. Allowing lots of
platform-specific options dilutes this value. The PHP route is still available
for the non-trivial cases. If you need RRD-specific features, then I think PHP
is the way to go.
Presenting platform-specific options in a seemingly platform-agnostic way is
worse. If we are going to support JSON options which are really RRD-specific,
we need to make this clear.
One suggestion on how to do this (which I don't like as well, but I'll mention
it anyway): Put RRD-specific options into something like
{rrd-options:--color --rigid --whatever}. This at least gives someone else
a clue that the JSON graph is intended only for use with RRD, rather than
leaving it up to gweb to determine how to interpret logarithmic or rigid
for any graphing platform we want to try supporting.
alex
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] add extras parsing to json graph-definitions
What Alex said.
- Logarithmic is universal so that shouldn't be controversial
Lower-limit and upper-limits are already implemented. Rigid is something
very rrdtool specific so I want to punt on it at this time.
Vladimir
On Thu, 19 Jul 2012, Alex Dean wrote:
On Jul 19, 2012, at 9:12 AM, Jeff Buchbinder wrote:
On Thu, Jul 19, 2012 at 8:54 AM, Jochen Hein joc...@jochen.org wrote:
Vladimir Vuksan vli...@veus.hr writes:
I would define a scaling factor or some other variable. I do want to
steer away from having tool specific options unless absolutely
necessary.
I agree that would be a useful goal, I just have no idea what I options
I may need for my special problem [see my mail to ganglia-general].
I've had a look at the other PHP-reports. A couple of them pass the
option '--rigid' to rddtool. Other used options are --logarithmic and
--lower-limit. I've no idea how that could be mapped into json and keep
the syntax and the parsing simple.
I'd suggest something like:
options: {
logarithmic: true,
rigid: false,
lower-limit: 0
}
with sensible defaults. If it's ignored by another graphing toolkit,
that's fine.
Silently ignoring unsupported options seems like a bad choice to me, because
it makes graph authoring troubleshooting more difficult. If someone uses an
unsupported option, we should blow up with an informative error message ASAP.
Think about when you've misspelled a configuration option (in any system, not
just gweb), and wasted a lot of time hunting for the cause of the odd results
you see - totally frustrating, and totally preventable.
More generally: The JSON format should be focused on making the simple
common cases easy. The format should be small, simple, easy to use.
Allowing lots of platform-specific options dilutes this value. The PHP route
is still available for the non-trivial cases. If you need RRD-specific
features, then I think PHP is the way to go.
Presenting platform-specific options in a seemingly platform-agnostic way is
worse. If we are going to support JSON options which are really RRD-specific,
we need to make this clear.
One suggestion on how to do this (which I don't like as well, but I'll
mention it anyway): Put RRD-specific options into something like
{rrd-options:--color --rigid --whatever}. This at least gives someone
else a clue that the JSON graph is intended only for use with RRD, rather
than leaving it up to gweb to determine how to interpret logarithmic or
rigid for any graphing platform we want to try supporting.
alex
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] add extras parsing to json graph-definitions
On Wed, Jul 18, 2012 at 5:06 AM, Jochen Hein joc...@jochen.org wrote:
Hi,
I'm working on getting ganglia to display correct units for one
custom graph. One of the first tries was to give some extra option
to rrdtools.
When using php-graphs, this is done via $rrdtool_graph[ 'extras' ],
but there is nothing for json graphs.
That simple patch (against 3.4.2) should fix that:
--- ganglia/graph.php.orig 2012-07-17 16:25:37.0 +0200
+++ ganglia/graph.php 2012-07-18 10:44:45.0 +0200
@@ -28,6 +28,7 @@
sanitize( $graph_config[ 'vertical_label' ] );
}
+ $rrdtool_graph[ 'extras' ] = $graph_config[ 'extras' ];
$rrdtool_graph['lower-limit'] = '0';
if( isset($graph_config['height_adjustment']) ) {
Jochen
I'll apply that patch to the tree.
Thanks!
Jeff
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] add extras parsing to json graph-definitions
I don't like it. It's rrdtool specific. I want something a little bit more
generic that gets translated to rrdtool commands.
Vladimir
On Wed, 18 Jul 2012, Jeff Buchbinder wrote:
On Wed, Jul 18, 2012 at 5:06 AM, Jochen Hein joc...@jochen.org wrote:
Hi,
I'm working on getting ganglia to display correct units for one
custom graph. One of the first tries was to give some extra option
to rrdtools.
When using php-graphs, this is done via $rrdtool_graph[ 'extras' ],
but there is nothing for json graphs.
That simple patch (against 3.4.2) should fix that:
--- ganglia/graph.php.orig 2012-07-17 16:25:37.0 +0200
+++ ganglia/graph.php 2012-07-18 10:44:45.0 +0200
@@ -28,6 +28,7 @@
sanitize( $graph_config[ 'vertical_label' ] );
}
+ $rrdtool_graph[ 'extras' ] = $graph_config[ 'extras' ];
$rrdtool_graph['lower-limit'] = '0';
if( isset($graph_config['height_adjustment']) ) {
Jochen
I'll apply that patch to the tree.
Thanks!
Jeff
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] add extras parsing to json graph-definitions
On Wed, Jul 18, 2012 at 9:55 AM, Vladimir Vuksan vli...@veus.hr wrote: I don't like it. It's rrdtool specific. I want something a little bit more generic that gets translated to rrdtool commands. Eventual suggestion: we define a function to convert between whatever extras format we're using and target rendering tools. It's probably a good idea to have it be an array rather than just plain text. Jeff -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
Re: [Ganglia-developers] add extras parsing to json graph-definitions
I would define a scaling factor or some other variable. I do want to steer away from having tool specific options unless absolutely necessary. Vladimir On Wed, 18 Jul 2012, Jeff Buchbinder wrote: On Wed, Jul 18, 2012 at 9:55 AM, Vladimir Vuksan vli...@veus.hr wrote: I don't like it. It's rrdtool specific. I want something a little bit more generic that gets translated to rrdtool commands. Eventual suggestion: we define a function to convert between whatever extras format we're using and target rendering tools. It's probably a good idea to have it be an array rather than just plain text. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
