Add poller information to graph-variables

[bernisys]

Feature Request

Is your feature request related to a problem? Please describe

While it is possible to add all kind of host-based information to a graph's text items, it seems to be impossible to show the poller information there as well. For troubleshooting it would be really great to have for example the poller's source IP address or its name in the legend of a graph.

Describe the solution you'd like

Add a set of variables for poller infos from the DB, prefixed with |poller_|
At least poller_id, poller_name, poller_ip would be great for a start.

[TheWitness]

@bernisys , are you asking for |poller_*| and for |device_*| to be less than status or rather automatic?

[bernisys]

@TheWitness, not sure what you mean by that.

The |host_| macros are already existing (sorry i mistakenly named them |device_|), for example you can add |host_hostname| to the graph legend and it resolves to the polled device's hostname in the graph image.

I would like to have additional possibility to project the poller information into the graph legend, so that customers can for example see easily, which poller is responsible to handle the remote device by simply displaying its name in the legend.

[TheWitness]

Yea, I get it. It should be more generalized in the future. It's somewhat static on the device side now.

Let's say someone adds a column to the host table. It can not be used presently. So, it was a broader statement for the usability and portability of the feature.

[bernisys]

I was thinking a bit over it, maybe it could be done via an default set of allowed keywords in an associative array that can be extended by a local configuration on demand.

Keys would then be the names of the valid elements that reflect the content which is allowed to be displayed, this way you can also avoid that people can simply add SNMP credentials to a graph legend, if they have access to the graph templates section.
Values should be a data structure, that can contain various information reflecting for example the table and column which is the source of the displayable element, also the secions in which this content is allowed (graph title, legend, ...)

This way it is easily extendable and on usage you can simply check if the |some_thing| element that appears in a template is really existing or not (array_key_exists), and what data it relies on (check the data structure). That might save a lot of "if then else" in the code, making it shorter and more maintainable.

Not sure if that is doable, or if i am on the wrong thinking-path.

[TheWitness]

@bernisys, the way we have traditionally done this was through keywords:

• |host_blah| - Device Columns
• |query_blah| - Data Query Columns
• |input_blah| - Data Input Columns

Now what we need is:

• |poller_blah| - Poller Columns
• |site_blah| - Site Columns

In honesty, we should make it very generic. For hears, we only permitted some columns and only some tables. I'm not saying to extend to beyond tables that include Graph, Device, or Data Source meta-data. We could do that, but then we need to describe the unifying columns, the join columns if you will somewhere.

Regarding people doing stupid things like adding a |host_snmp_password| to a Graph Legend or Title. Never though about that honestly. As @netniV will tell you again and again, we should move to Classes such that the device class for example could be extended by a plugin to add new methods or extend existing methods. That big of a move can not happen over night if at all at this point. Certainly not in 1.3. However, adding the above two to the suite is literally a no-brainer.

[TheWitness]

Additionally, it's sad that whisker syntax was invented after Cacti adopted the pipe over whisker semantics. I prefer whisker actually.

[bernisys]

I think a good idea could be to start and collect all the items that would actually make any sense in the graphs. Probably include the community for ideas as well, everyone could contribute in the issue thread, then all ideas can be collected at one point.
Also including maybe information about the not so obvious things that might come handy for deeper debugging - not sure if there is anything useful on that level though. But at least the possibility should be kept open to add it dynamically on demand later. (Without inventing a whole new world of a Turing-complete meta-language. We have an excess of those already and also stuff like that needs to be debugged - yuck.) Then sort out ways to describe this somehow. I'd say a flexible set of queries plus a description of the input parameters should be good.

As you mentioned the "join columns" part, well, yes it is a bit more complex, but even this could probably be done quite elegantly by a cunningly crafted data structure that describes in a kind of meta-language, which things need to be thrown into a DB query and joined together in order to get the right answer out of the DB. (Speaking of which, i never really found a simple way to link a RRD filename/ID to related graph IDs and vice versa...)

I was thinking about a flexible but simple mechanism. It could be based on an object/class that already has some information that is needed to generate the graph anyway, assigned to the respective keys, like $array["host_hostname"]["cached"] => "MyHost"; that's pretty straightforward, if it needs to resolve the basic "|host_hostname|" macro, the info is already there. And if the cached content is not present, then there should be a description how to retrieve it from the DB, for example: $array["host_hostname"]["query"] = "select hostname from host where id=|host_id|";

So if the hostname is already in the cache, it is simply taken from there, and if not, then the system tries to create the SQL query and resolve it. Since the "host_id" part is one of the base values, it should be already there and can be directly resolved. If it is not yet cached, follow the path thru the patterns. And bail out at a certain depth to avoid circular dependencies creating an endless loop. If at that point not all necessary parameters are defined -> throw an error in the log.

Some difficulties will arise of course, because one value can be resolved in many ways ... and this is the case for many keywords, like host_id can be taken from several tables, and the system would need to figure out, from where it could be resolved with the given information.

But this way you could actually recurse thru the breadcrumbs given in the query strings and resolve all missing data points.
Not sure about performance here, maybe some information could be cached locally to speed up repeating queries following the same pattern.

Whisker syntax? Never heard of that term TBH. In templates and macros I usually come across stuff like %KEY% or {KEY} - i guess it is that second one.