Strange results when enabling Apache Access logging

UPDATE:

I tested this on multiple nodes with alerts, nDepth and both configured with the same results.  The difference between this server and the test server is it's behind a firewall but all ports needed are open and all other tools seem to work fine from these servers.

Can you give me an example of what the random nodes are named?

Do you have nDepth full log storage enabled?

Do you have Apache Error also enabled, or just Access?

There's a detection engine that tries to extract node names from log data to make sure they appear in Manage > Nodes. It sounds like it may be mis-detecting against Apache Access logs.

Nicole,

I think that's exactly what's happening.  I'm removing nDepth from all the tools although it does the same regardless how I configure the agent.  I just have a small VM appliance supporting a LEM50 license so I was sending nDepth to localhost but until I get this sorted out I'm disabling that.

I'm not sure how to enable or disable nDepth, it's in it's default config.

Apache Error is on and it's not having an issues.

Here's an example of the nodes, the IP addresses coincide directly with access IP's from the access log.

Node IP        Node Name    Agent Node
74.203.107.88,    74.203.107.88,    198.152.214.22

I have a ticket open, Case #282424

Thanks - development has confirmed what you're seeing and is investigating a resolution.

nDepth log storage defaults to "off" (you can always search alerts), so if you haven't turned it on, you're okay there. Enabling it in the tools doesn't cause any harm or take up any space until the appliance has it enabled.

So, what's happening is that the tools themselves (Apache Access, for example) try to detect the originating source IP based on the contents of the log data itself. The regular expression that does this detection is picking up the wrong IP.

And, we're fixing it! We should have an update that you can install soon. It'll be super easy, it's just a change to the tool. After that, you can delete the non-Agent nodes that are appearing, and they won't reappear.

We have resolved this issue - I asked the owner of your case to contact you with the resolution.

Anyone else affected should contact support for the tool update associated with this fix. It will be automatically included in the next maintenance release.

Well, I received the message, downloaded the update and applied it, the problem IS NOT RESOLVED.

After some investigation I discovered both the old and new version of the tool .xml still exists on the appliance so it's not pushing the updated .xml to the agents.

The new .xml may indeed correct the problem but the update script on the 5.3 appliance isn't replacing the older script, it's just adding another one to the list and confusing the manager.

I submitted all this information over the weekend and this morning but have not heard back from support.

I think we might have this one nailed down... hopefully you have the update in hand.

There was a bug introduced when we addressed an issue for a customer with a non-standard logging config. We've separated these two issues and you should be able to use the newer version.

We're also looking into what caused the two versions issue that support cleaned up.

Thanks for being patient!

I applied the new version and it seems to be working well.  Thanks for working through the issues and getting it resolved.