sedmo

I've noticed similar issues with Cirrus since upgrading to V4. My node list seems to scroll down by a few nodes every five to ten seconds. If I just leave it sit, it will eventually scroll down to near the end of my node list.

Try this post and see if it helps with your problem. I think you can accomplish what you need by removing your alert suppression and adding a criteria to your trigger condition that says: NodeName is not equal to Rick's Leaf Node

That runs on the DB server.

That usually indicates something is trying to make an SNMP query to the device with the wrong community string.

Try this thread.

you can do this by creating a filter on the resource like this: unmanaged = 0

You will see this behavior when using basic alerts if you have multiple polling engines. When setting up a basic alert you will only see the nodes that are assigned to the polling engine you are connected to.

They all just have to meet the criteria specified in your alert trigger. This also means that the alert will be triggered if 10 different servers each send one "login failed" message within a 10 second window.

How about something like this? (Caption like '*nice*' AND Environments = 'Incidents & Operations' AND Category = 'Call Logging') or Caption like '*symp*'

I find the site at the link below useful for Cisco MIB's http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en

Here is what the Cisco web site has to say about this message. If you do not want these messages added to the database then you should create a filter that discards these messages. Error Message ILPOWER-5-IEEE-DISCONNECT: Interface [chars]: PD removed. Explanation This message means that the powered device is no longer…

Yes, you can clear syslog messages based on either the message type or IP address. The queries would look something like this: To delete records based on data in the message type field: delete from syslog where messagetype = 'criteria' To delete records based on data in the ip field: delete from syslog where ip =…

Sometimes this can happen if you are using a 32 bit counter to monitor an interface that is pushing a decent amount of traffic. I would suggest checking the box to allow 64 bit counters for the device and see if that clears up the problem.

I believe the first line in the alert that says "Trigger when all of the following apply" should be "Trigger when any of the following apply". With the current configuration all of the sub conditions would have to be true in order for the alert to trigger. In other words, all three nodes would have to be down.

See this thread for more information on this topic. You can also find more information about advanced alerts in the doumentation located here:

If you schedule a job to download the configs there are options on the Notifications tab to let you log and/or email the results of each attempted download. 

The port channels should show up as an interface on your device that you can monitor just like any other interface.

Is it possible that this could just be a timing issue? Maybe Solarwinds is discovering the HTTP-Monitor app is down before it discovers that the node is down? If this is the case, you should be able to fix it by specifying that the trigger conditions must exist for a certain amount of time before the alert is triggered.

The way the alert is currently configured it is triggered if the node name is LA, NY, MX OR average response time is greater than 75. So you should be getting alerts for LA, NY and MX no matter what the average respone time is. You should also get alerts for any other node that has an average response time greater than 75.…

See if this thread provides any help.

You could probably do this without using regular expressions by entering two different patterns separated by a comma. *User: user1 logged command:!exec: enable*, *User: user2 logged command:!exec: enable* 

The bandwidth issue sure looks like a rollover problem with the counters. What is the statistics polling interval for this device? If it's higher than 5 minutes, I would recommend setting it to 5 minutes and see what happens. Another good clue that it's a rollover problem would be to see if the behavior remains during…

You can select all of the nodes you want to run the script on and then right click on one of them and select Execute Command Script. Another option is to setup a scheduled job that executes a command script on the devices.

I think you could use something like this. statusdescription like '%Down%' AND Unmanaged=0 and Status <>11

See if this thread is helpful.

This seems to work ok for me using version 5.5.1. Is there any chance you could post screen shots of your rule and policy configurations?

Try this. Volume \\${Node.Caption}\${SQL:Select Substring ('${Caption}',1,1) + '$' AS Caption}

Try changing your alert to read Trigger alert when all of the following Node status is equal to down IOS is equal to (windows IOS)

Yes, it is possible to do this with the "Execute Command Script" function. You can do this through a scheduled job or by right-clicking one of the devices in your NCM node list and selecting Execute Command Script. Use the top half of the dialog box that appears to select the nodes you want to run the script on. Use the…

I think you could safely do this while the system is running but there are a couple of things you should probably do in addition to the delete query. 1. make sure you have a backup of your database. 2. create a trap filter that discards incoming authenticationFailure traps. If the traps are coming in at a fast enough rate…