Since v10 Upgrade,getting errors in Windows Event Viewer Applications Solarwinds

Hey Don--

Is this affecting performance? If it isn't and you can wait, I'd see what the community has to say about it. If it is, go ahead and open a support ticket.

M

Yes, Im getting the same thing.

Hi Don,

This is a known bug that should not affect performance or functionality.  We have already fixed this in our code base for the next release.  The down side is it does add entries to your event log.

Thanks

We have this same issue, but we have seen about 12,500 events in the last 4-5 days.  in our case it adds a LOT of entries.  A few per second.

Hi Don, This is a known bug that should not affect performance or functionality.  We have already fixed this in our code base for the next release.  The down side is it does add entries to your event log. Thanks

Karlo,

I am receiving the same event log errors. I do not believe this is affecting performance, however, I do believe it is affecting functionality for me. It appears that I am receiving these errors as a result of the problem that I mentioned in this post:

Can you confirm that these event log errors are not being generated as a result of the NodeID fields not being updated for the Syslog and Traps tables?

I opened case #184425 but it was closed after I was told there was currently no fix for this issue and it would be fixed in a subsequent release. I would really like to speak with someone about this. I believe that this problem may have begun in v10.

Hi Sam,

The situation I describe above with regards to the error from the Syslog service is unrelated to your Traps question/issue.  The syslog and traps services do not share their internal mappings of IP address to NodeID.

Your issue is more of a tracking issue of changing NodeIDs and IP addresses in the Traps and Syslog tables.  We do not have any procedures that update historical data beyond a certain recent point in time.  The syslog service bug I describe is for updating very recent entries.  Older entries we do not make any assumptions about as you may have one Node that sends traps and then next month delete that node and have a new different node with the same IP address that sends different syslog and traps.  Hence, Orion cannot tell the difference between this situation and the situation you describe.

It would be up to you to execute your own SQL to update any syslog and traps entries you would want to match to a given NodeID.  For example something like:

UPDATE Syslog SET NodeID = 1234 WHERE IP = '1.1.1.1'

(Run a SELECT * FROM Syslog WHERE IP = '1.1.1.1' to make sure you will be updating the rows you are expecting)

This would overwrite every entry from this IP address and set the NodeID and potentially ruin the history of the syslog table.  Updating the Traps tables in a similar way would also potentially ruin your data from a historical perspective, but if you are confident with the rows you are updating, then this would be the way to fix your data.

Hope this helps,

Karlo,

Thank you very much for your reply and your explanation. However, just to be clear, it is not historical Syslog and Trap records that I am concerned about. I discovered that I could update those in the manner that you mentioned.

What I am concerned about is the fact that *new* Syslog and Trap records are not being created with a proper NodeID even after I have added the Node in Orion (the record is incorrectly created with a NodeID of 0). These are new traps and syslog messages being sent after the node has already been added. Surely this is not the desired behavior, correct? In all my time working with Orion NPM, I have never seen this problem and that's why I don't believe this is the correct behavior.

Thanks.

Hi Sam,

I'm sorry I misunderstood your post.  If the NodeIDs are not being inserted properly then this could be an issue.  One reason that we might not be inserting the right NodeID is because you have multiple polling engines and we only get the NodeIDs for the current polling engine.  If you are sending messages from nodes on other polling engines to the primary polling engine, then this would insert 0 into the table.

If this is not the case and you do not have any duplicate IP addresses in the database, then open a support ticket again and reference this thwack thread so that we can get a look at your diagnostics and find out why you are getting a 0 inserting into your tables.

Thanks

Thanks Karlo! I will follow-up with the Support team.