Automation Tree Rules not applying properly.

[chris-technicate]

Problem:
Very specific tree rule shows properly in preview, but adds additional (not-wanted) graphs to tree

Description:
I have 2 graph rules that automate creation of a graph upon creating a host or re-indexing hosts.

Rule 1 creates graphs for all interfaces types that are active, routed, with a hardware address, and vlans not in the 100-1999 range. Then applies the graph template "Int-64bits/sec 95th"

Rule 2 is the same, except only virtual interfaces, and only in the 100-1999 range. Then applies the graph template "Int-64bits/sec 95th Exported" (a clone of the 1st with the word "exported" added to the end)

This rule works 100% perfect, and has since much earlier versions of cacti. Both graphs work perfect as well.

I have only 1 tree rule that applies to this type of graph. This rule has only 1 criteria:

Name: Add to Export
Tree: [exported]
Leaf Item Type: Graph
Optional: Sub-Tree Item [root]
Object Selection Criteria:
gt.name matches Int-64bits/sec 95th Exported

When showing eligible objects, I see only the interfaces that apply.

When adding a host, all graphs that are created by the above graph rules are added to the tree. All graphs including those not using said template are added to root.

Please tell me this is a bug, I have been banging my head on a wall for a couple days now.

Had Cacti not removed the export functionality from core I could have continued with exporting automatically based on the flag in the template. These graphs are exported to another system via cron based on the tree using the new export plugin. Seeing as the new plugin takes on average 30-40x to export as it did when in core this is critical for us.

Bounty offered for quick resolution!

[netniV]

Can you provide any screenshots of how your rules are defined? Also, have you defined both selection and creation criteria? I'm presuming so in how I'm interpreting what you've written.

[chris-technicate]

Which rules would you like a screenshot of? Is it ok to just copy paste relevant text?
I have not defined tree creation criteria as they all end up at the root of the tree. I needn't rename or modify the graph title, order, or create sub trees. Intentionally keeping all in root.

[netniV]

Screenshots are good to give a visual interpretation though the text can be useful for recreating. So both? Lol.

Provide as much as you can so we can diagnose as best as possible.

[chris-technicate]

Attached.

The disparity in count on the tree rule is graphs that had the template manually changed.

When I add a new host (as a test) this host has 19 "qualifying" interfaces for the graph rules. The graph rules created 12 of rule 1, 7 of rule 2 - perfect. BUT The tree rule added ALL graphs to root.

[netniV]

I noticed that you haven't actually enabled the rule, was that by design? Have you turned the rule off because it was creating too many?

[chris-technicate]

I duplicated the original rule and removed an internal identifier in the "Name" Field. (Only edit)

[netniV]

Ok, to be clear, what other graphs are included during tree creation that shouldn't be?

[chris-technicate]

Graphs related to graph rule #1 which specifies a different template.
The tree rule explicitly says:
"gt.name matches Int-64bits/sec 95th Exported"
It is adding graphs that do not match that title. It is adding all graphs for the device. Almost as if it matched the device and stopped there adding everything.

[netniV]

I'm looking into this now and creating my own selections to simulate what you have. In the meantime, if you can, you could set the logging level to HIGH, this will give a whole bunch of 'AUTOM8 TRACE' logs that can be used to identify what's occurring.

It will also generate a lot of logs we aren't interested in so may not be something to leave enabled for a long time if your polling time is every minute and you have a lot of devices.

[chris-technicate]

Our cron to reindex all hosts runs each morning @ 0300. I discovered just now that in fact all new graphs were added to the tree.

Any luck?

[netniV]

Well, your lucky 👍 I can't get a graph added to my tree yet. 👎

It successfully creates the graph but I think it's finding that the graph already exists so doesn't hit the tree rule. One way to test this is to create a manual automation network consisting of one device. Then run the following at the command line:

sudo -u <cron user> <path_to_cacti>/poller_automation.php --network=<network id> --force --debug

Replace the fields including the <> parts:

field	value
cron_user	with the user used in your cron.d/cacti file.
path_to_cacti	the physical location on the disk (eg, /usr/share/cacti)
network_id	the id of the single host network you created above

Unless you are willing to use the patch that I've created in PR #1349, you won't be able to filter the details as well or see the appropriate graph/template/device names. But you should at least be able to see these logs as they will be the only thing around now for AUTOM8

Unfortunately, if you filter for AUTOM8 the current logging does not correctly make the SQL into a single line statement so it appears across multiple lines which don't have the AUTOM8 prefix.

I'll work some more on it tonight but I don't have an answer for you at this time.

[chris-technicate]

I used your username at hotmail, did you receive?

[netniV]

OK, so we fixed up the cron issues by cloning the /etc/cron.d/cacti file and changing it to run the above reindex command instead.

There have been a bunch of other changes. Still waiting on using the updated version of the automation code to get better logging out. That would help identify the path which is creating the extra graphs.

[cigamit]

I guess we can commit that for 1.1.36. I just want to make sure it's right. Question, the json_encode() is that including line breaks?

[netniV]

i'm sure the SQL was the only parts that included line breaks so I replace them with a space. The json_encode replaces serialize so that it reads better since serial also includes extra bits about string length etc.

I also updated the logging routine so that it splits by line break and calls cacti_log for each one so it has the same automate prefix.

[cigamit]

Okay, if you are working on the plugin stuff, maybe I can take the graph issue? Your patch is pretty strait forward.

[netniV]

Sure that would be good. The patch I did works but doesn't use the linkEditMain that you mentioned. The other issues is that because we are using graph_view.php the sidebar and filters disappear when you open in a new table so that's why there is the breadcumb code to keep those there. I'm assuming that using the linkEditMain would kinda keep that.

I can get to it, but it'll be another hour or two before I start.

[cigamit]

I'll hack it out. I've got some time right now. Just want to clear as much of the deck before release. I'm going to tee up some bugs for cleaning up the RRDtool functions, and a few things floating around in my head as well. @browniebraun will have to fix his proxy to return output through the stream, which I'm assuming is working right now anyway. The change he made to dsstats broke the stdout pipe that was used for inspecting the RRDtool output. I figure it's better to re-write the RRDtool functions to play properly with proc_open(). We tried to do this years ago, but PHP was not stable enough at the time. It'll be safer now. So, I won't do it for this release, as I'll want more time for people on the edge to verify that it works across the board. I don't want to introduce anything in this release that messes that far into the underbelly of Cacti.

[netniV]

I've been working with @chris-technicate to get various bits working for him. This update to the logging will help because things become less developer orientated in the output especially when debugging is all turned on. It's just changing quite a big chunk of code so it'd be good to have others testing it.

[cigamit]

Okay, you tell me when your pull request is ready, and then I'll look for some obvious stuff in the pull request, and make the determination. Got the graph stuff worked out. Heading out for a while. I don't really see anything else that I want to pursue for the release on my end.

[netniV]

I have not found anything obvious. But I don't really use the Automation Process that much. It'd be nice to have a list of beta testers you could just fire things at for QA 👍

[cigamit]

Automation process is mostly good. However, if you filter on the label 'automation', there are a number of feature requests pending. I've also created a project for addressing them. I think it is one large project. Timing will be dependent on who takes it.

[netniV]

I believe that this has now been resolved, hasn't it @chris-technicate ?

[chris-technicate]

Will check into this today, replicate and report back.

[netniV]

Closing as there have been a number of automation improvements to 1.2 and no feed back on this original issue.