Who knows how to do this?

[ehall]

Let's say I want to provide a template of some kind that will (1) query for all of the interfaces on the associated device, and (2) suck down the total number of bytes transferred per cycle, and (3) allow the user to pick the color for each interface.

Currently the data query model allows you to pick an interface and it will provide a bunch of options on a per-interface basis. I want to turn that around, so that it is just one option that is applied to all interfaces. The only user input would be to pick the colors that are associated with each interface (this will have to be done, since there could be a variable number of interfaces, ranging from just one [localhost] to 48 or more [a switch]).

[TheWitness]

Moved to Feature Requests.

[ehall]

Not possible I take it

heh

[TheWitness]

No, just a feature request. I don't want to forget about it, but you should clarify where you want this feature (aka what part of the interface).

TheWitness

[ehall]

The most seamless way to handle this in the current construct would be to provide a "consolidate graphs" checkbox in the Data Query editor. When selected, this would force all of the detected data sources to be generated within a single graph, instead of causing individual graphs to be generated for each distinct data source.

This could arguably be put into the graph creation screen too, but putting it into the query editor is probably better choice since that makes it an explicit design decision, instead of a run-time user decision (you will see why this is needed below).

As for mapping color values to the individual readings, it might be sensible to provide a follow-up dialog after the graph creation screen (similar to the follow-up screen where data template values are filled in), which would present the user with a list of the detected data sources and allow the colors to be chosen for each of them.

There are some complicated things to consider here, but as a first step that is probably the most sensible way to implement the feature. For example, there is some potential for multiple data elements per data source (sent vs received octets, instead of just total octets), and that would preclude the use of area charts. Another possibility down the road might be to stack the graphs into a single logical graph (taller than normal), so that you can see each of the ~24 switch ports in a single cardiogram rather than having to keep up with 24 separate charts, and that would allow for the use of area charts again.

But for now, just having the option to consolidate data elements into a single graph in the query editor would be good enough, and for the rest of it "don't do that" is acceptable response.

[gandalf]

Thought about sth like this for weeks. But it came to me, that reindexing would cause this whole stuff to fail.
As far as I understood your idea, this would make up to define a single rrd containing all ds' needed? Yo reindexing would cause to add a new ds to an existing rrd. This is not really supported by rrdtool (altough there is a script for this in the download/contrib section at rrdtool.org). So it woul dbe better to keep with one rrd per interface (and probably two or more ds in there, but all for the same interface).
My last approach ended in sth like a filter to be defined for the selection of graph items (actually, there is a DropDown containing all Graph Items, but you may choose only one). The resulting list should have a checkbox per line to select that very ds; multiple checking of course allowed. But now you will need all other Graph Items fields as well: Color (you talked already about that), Graph Items Type, CDEF and the like.
IMHO, this does not seem to be a really good approach, so I dropped it.
Reinhard

[ehall]

Thought about sth like this for weeks. But it came to me, that reindexing would cause this whole stuff to fail. As far as I understood your idea, this would make up to define a single rrd containing all ds' needed? Yo reindexing would cause to add a new ds to an existing rrd.

Different entries are currently stored in separate data-sources (eg, eth0 gets a different rrd from wlan0). Adding a new interface (and choosing to graph it) would cause a new data source to be created.

You are talking about a new attribute value being tracked, but that isn't supported anywhere in cacti, so I wouldn't be expecting it to work here either.

My last approach ended in sth like a filter to be defined for the selection of graph items (actually, there is a DropDown containing all Graph Items, but you may choose only one). The resulting list should have a checkbox per line to select that very ds; multiple checking of course allowed. But now you will need all other Graph Items fields as well: Color (you talked already about that), Graph Items Type, CDEF and the like.
IMHO, this does not seem to be a really good approach, so I dropped it.

I'm not sure I understand what you were doing, but you shouldn't need to define things like CDEF because those would have already been applied to the graph template that is already being called. If the graphs work for each entry then they should still work.

The only reason you need per-entry colors is for usability.