More Graph Template Updates

[mrnoodle]

I would like to be able to add a CDEF to the list of graph items available when creating a graph or a graph template similar to Line or Area.

To allow for this, the Graph Template Item screen would have to include the "CDEF" option in the graph item pull down, and it would have to include a "CDEF Name" and "CDEF String" fields which would only be read if "CDEF" was selected as the "Graph Item" (similar to HRule).

The benefits would be:

1. Allow for custom CDEFs on a per graph basis without requiring their creation before in the CDEF menu.

2. Allow control over the naming of the CDEF.

3. Allow for reference of one CDEF from another. This is very useful when you need to compare a datasource that has already been converted in a previous CDEF.

For example, the first CDEF would calculate a percent utilization and the second would be used to compare the output of the first CDEF to a set value and then add an item to the graph if it was greater than the set value.

Code: Select all

CDEF:cdefb=a,b,-,a,/,100,*

CDEF:cdeff=cdefb,1,LE,0,cdefb,IF

You can currently implement most of the above by creating both of the CDEFs above in the standard location, and applying the first to a "Comment" graph item in the second row of the "Graph Item" list (the second row CDEF will be named cdefb by default by Cacti). Since it is a comment, nothing will be added to the graph. The second CDEF will then be used to apply to an AREA or LINE graph item whenever the first CDEF is greater than 1. Otherwise, it will graph a zero.

This feature can be used quite nicely to add alarm indicators to existing graphs as well. A third CDEF can bee added that would overlay a vertical red bar any time the first CDEF exceeded 80% and the value was not unknown:

Code: Select all

CDEF:cdefbb=cdefb,UN,0,cdefb,IF,80,GT,INF,UNKN,IF

4. Once created, all other graph items could use the created CDEF by referencing them by name.

[gandalf]

The first CDEF mentioned will be better implemented using the COMPUTE data source type. This will be supported by version 088
Reinhard

[mrnoodle]

Is there any more information available about the Compute Data source?

I would assume that it will allow for the addition of custom CDEF entries, but I would like to see some more details.


I suppose the request above could actually be expanded/modified to allow for the inclusion of a "Custom" graph item type that would allow for custom test to be added to a graph instead of a CDEF option. The custom field would work similar to the "Custom Text" feature of the CDEF screen. This could be used to define a CDEF or even add a DEF to the graph without having to insert a line or area. It would also allow for adding additional RRDTOOL features to graphs that are currently not supported.

For example, a you could add a custom field that included the text:

Code: Select all

--watermark "Generated by CompanyName"

This would allow the addition of a watermark to the graph without having to actually add support in the graph template item itself.

[gandalf]

Is there any more information available about the Compute Data source?

I would assume that it will allow for the addition of custom CDEF entries, but I would like to see some more details.

Please see plain rrdtool documentation.

I suppose the request above could actually be expanded/modified to allow for the inclusion of a "Custom" graph item type that would allow for custom test to be added to a graph instead of a CDEF option. The custom field would work similar to the "Custom Text" feature of the CDEF screen. This could be used to define a CDEF or even add a DEF to the graph without having to insert a line or area. It would also allow for adding additional RRDTOOL features to graphs that are currently not supported.

I already though about this one. To be honest, I did not yet have a conclusion. And please remember, that cacti introduces some high level functions not available with plain rrdtool. That would not be possible if those options would habe been entered as "plain text". So there are pro's and con's.

For example, a you could add a custom field that included the text:

Code: Select all

--watermark "Generated by CompanyName"

This would allow the addition of a watermark to the graph without having to actually add support in the graph template item itself.

This is an easy change. Please add a feature request at http://bugs.cacti,net. It is planned to support most rrdtool options. Currently, the main drawback is supporting different rrdtool versions. There is even not such thing as a option/version matrix so that you know which option was supported by which rrdtool version.
Then, please remember the syntax change from rrdtool 1.0 to 1.2. Bad. Now see e.g. support for 2nd y-axis introduced with latest rrdtool 1.3.5. So we will have to check rrdtool version up to the 3rd tupel; bad, very bad.

Currently I'm planning to define some option/version matrix as a table with cacti. But it's really hard to compile from the past which option was introduced by which rrdtool version. I suppose I'll have to do it the hard way.
Any discussion on this is welcomed
Reinhard

[mrnoodle]

After reading the documentation about the COMPUTE DS, I think that it will be a welcome addition to Cacti and it will be quite useful, but there are a few areas where customer CDEF would be more useful.

1. It is not 100% obvious in the man pages, but it appears that the COMPUTE needs to be added to the RRD when it is created. This is fine when you are aware of your requirements before you start your collecting the data but it is not helpful if you want to add information to graphs wityh already existing data.

If you can add to the existing graph data, you will have to have an interface that allows for updating the RRD files with the COMPUTE values that you want to include.

By allowing for the creation of CDEFs directly in the Graph Template, you gain all of the flexibility of the COMPUTE DS, at least when it comes to drawing the graphs themselves, without having to make any preparations ahead of time.

2. In the current age of ginormous Hard Drives for no $$$, this issue is less likly to apply, but the COMPUTE DS is stored in the RRD file and will make all of the files larger and consume more drive space. This is not much of an issue with the default RRA configurations, but it is more of an issue for installations that have modified the default configuration and increased the number of non-consolidated data sources.

3. The COMPUTE data source is can only be applied to other Data Sources in the same graph. It does not have the ability to make comparisons or calculations across multiple RRD files or to other CDEFS already defined.

Here is a graph (along with RRDTOOL output) that I created that makes use of a CDEF that compares other CDEFs in the file. It is a graph of the total throughput that overlays the color red on top of the graph whenever the utilization exceeds 40%.

First the RRD output:

Code: Select all

/usr/local/rrdtool-1.2.28/bin/rrdtool graph - \
--imgformat=PNG \
--start=-86400 \
--end=-300 \
--title="xxxxxxx - Outbound Traffic" \
--base=1000 \
--height=300 \
--width=700 \
--alt-autoscale-max \
--lower-limit=0 \
--vertical-label="Bits per Second" \
--slope-mode \
--font TITLE:12:/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Bold.ttf \
--font AXIS:8:/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf \
--font LEGEND:8:/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf \
--font UNIT:8:/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf \
DEF:a="/usr/local/cacti/rra/xxxxxxx_maxoutbound_1982.rrd":maxoutbound:AVERAGE \
DEF:b="/usr/local/cacti/rra/xxxxxxx_idletraffic_1981.rrd":idletraffic:AVERAGE \
DEF:c="/usr/local/cacti/rra/xxxxxxx_maxoutbound_1982.rrd":maxoutbound:MAX \
CDEF:cdefa=a,0,* \
CDEF:cdefb=a,b,-,a,/,100,* \
CDEF:cdefc=b,0,* \
CDEF:cdefg=a,b,- \
CDEF:cdefbc=cdefb,50,GT,cdefb,100,GT,UNKN,cdefg,IF,UNKN,IF \
LINE1:cdefa#000000FF:""  \
COMMENT:" "  \
LINE1:cdefc#000000FF:""  \
COMMENT:" \n"  \
GPRINT:a:LAST:"Max Outbound\:%8.2lf %sbps\n"  \
COMMENT:" \n"  \
LINE1:cdefg#009485FF:""  \
AREA:cdefg#00948533:"Outbound Traffic\:"  \
GPRINT:cdefg:LAST:"Current\:%8.2lf %s"  \
GPRINT:cdefg:AVERAGE:"Average\:%8.2lf %s"  \
GPRINT:cdefg:MAX:"Maximum\:%8.2lf %s\n"  \
COMMENT:" \n"  \
AREA:cdefbc#FF00007F:"Alarm State > 80% Utilization\n"  \
COMMENT:" \n"  \
COMMENT:"Last Updated\: Fri 02 Jan 12\:55\:16 CST 2009\n" 

CDEFB in the output above had to be added to a comment inserted into the second line of the graph items and CDEFBC had to be created assuming the CDEF naming in Cacti was consistant and the Comment was located in the same position.

With the above proposal, I would define the 2 CDEFs manually in the graph with custom names that I had assigned, then I would create the "Alarm State" Area Graph Item and apply the CDEF that was already created by name.

[mrnoodle]

I agree that multiple versions of RRDTOOL make things far more difficult and I would not expect you as the Developer to account for all of the possible combinations of options availabe with all of the different versions of RRDTOOL available.

I would suggest options were added in one of 2 ways.

1. As it exists with the CDEF "Custom Sting" already, allow someone to enter in whatever (a basic sanity check could be applied since it is a web site) text they like and check the Graph Debug output to see how it works. The only thing I would limit in this operation is anything that could be destructive to the system. (Maybe this option would be limited to just custom CDEFs)

2. Add a new section to the "Configuration Settings" screen to allow Administrators to enable/disable some additional/more advanced features that can only be used with more current versions of RRDTOOL. For the items in this area, you could add a note as to which version of RRDTOOL was required to support a specific option and it would be up to the admin to verify the correct version was in use.



I haven't fuly thought out how it would work, but I have a feeling that allowing for custom elements in "Graph Templates" would allow for the creation of a new set of templates that could be used to generate graphs of data that already exists and add a second "template" option when manually adding graphs to the system.

[gandalf]

After reading the documentation about the COMPUTE DS, I think that it will be a welcome addition to Cacti and it will be quite useful, but there are a few areas where customer CDEF would be more useful.

1. It is not 100% obvious in the man pages, but it appears that the COMPUTE needs to be added to the RRD when it is created. This is fine when you are aware of your requirements before you start your collecting the data but it is not helpful if you want to add information to graphs wityh already existing data.

That's correct. And that's a drawback of COMPUTE in general. No change after file has been created as the data source are computed on each rrdtool update.

2. In the current age of ginormous Hard Drives for no $$$, this issue is less likly to apply, but the COMPUTE DS is stored in the RRD file and will make all of the files larger and consume more drive space. This is not much of an issue with the default RRA configurations, but it is more of an issue for installations that have modified the default configuration and increased the number of non-consolidated data sources.

Correct again, but IMHO not of much importance

3. The COMPUTE data source is can only be applied to other Data Sources in the same graph. It does not have the ability to make comparisons or calculations across multiple RRD files or to other CDEFS already defined.

Not quite correct, but close. COMPUTE is restricted to data source items of the same rrd file.

CDEFB in the output above had to be added to a comment inserted into the second line of the graph items and CDEFBC had to be created assuming the CDEF naming in Cacti was consistant and the Comment was located in the same position.

The stable naming of data sources is indeed an issue. That's basically the reason why I love COMPUTE. But COMPUTE is more for percentage calculations and by far not that flexible as a "free-form CDEF"

With the above proposal, I would define the 2 CDEFs manually in the graph with custom names that I had assigned, then I would create the "Alarm State" Area Graph Item and apply the CDEF that was already created by name.

Don't get me wrong. I'm not _against_ your proposal. Currently I only like to _discuss_ it. Still the same drawback applies to your free-form CDEFs: the position dependancy. It's not your fault, for sure.
And in fact, as you already said, it's doable by now. But it requires quite some nasty workarounds. If we only find a solution for "stable" naming of DEFs and CDEFs generated by cacti so it is possible to refer to them using any free-form CDEF, that would be great
Reinhard