Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

NCM and NPM syslog/trap integration

pserwe

I have NPM and NCM running on the same server, I need to be able to receive syslog and traps *mostly* on the NPM,

but I want configuration backup from the NCM triggered on a filtered syslog message from the device.

As far as I can tell, I may not be able to accomplish that currently. Is there a way I can do this?

Peter

Find more posts tagged with

Accepted answers

All comments

chris.lapoint

Yes, this is possible. NCM can leverage the NPM Syslog Server. See the NCM Admin Guide for details on how to setup Realtime Change Detection using Syslog Server.

reheindel

I have looked through the NCM admin guide, but it is not real clear as to what I should expect to see.

I am running NPM/NCM on the same server, NPM existed there first so its syslog server was the one that was installed.

I still see syslog events from within NPM. should I also be able to see events within NCM's syslog viewer? (I don't currently)

Thanks,

Bob

pserwe

Okay Chris,

I can't seem to tell if this is precisely what's happening, or just what it looks like.

I'm running NPM's syslog server and trap receiver.

I am not running the services for NCM's syslog server and trap receiver because it's running on the same box, and the alerting takes precedence over NCM all day long.

As a workaround for syslog and traps not being able to be handled by both systems on the same box, can I forward the traps and syslogs from NPM to NCM?

Ideally, they should be sharing common data, full integration, even into the same SQL database, or at least have the NCM product be able to pull from both.

I don't have a need for NCM to do historical reporting on SNMP trap or syslog data. For that matter, NPM doesn't do that either, and it should.

The problem is, I need NCM's functionality to work even though I'm having NPM take the first crack at the data. The only way I could think of this to work would be to forward traps to a non-standard UDP port on localhost, something like create rules in NPM to forward traps to 127.0.0.1:8162 udp, and forward syslog to 127.0.0.1:8514 udp. In order for that to work, I need to be able to configure the NCM syslog server and trap receiver to listen on those non-standard addresses.

I have looked at the Admin guide. The NCM Syslog Server application is showing me syslog messages from two days ago, and none of the SSH user logout messages that I specifically want to discard some of, because it's the NCM/rancid user, and trigger configuration backup on the ones that aren't the NCM/rancid users so I have a snapshot of the config every time a user logs out of either the https or ssh interface of the device.

The configuration isn't complicated, it's just not working.

Peter

chris.lapoint

I have looked through the NCM admin guide, but it is not real clear as to what I should expect to see.
I am running NPM/NCM on the same server, NPM existed there first so its syslog server was the one that was installed.
I still see syslog events from within NPM. should I also be able to see events within NCM's syslog viewer? (I don't currently)
Thanks,
Bob

Sorry, let me clarify. NPM and NCM include the exact same Syslog server so you can only have on installed and working at one time. Since you had NPM and its Syslog Server already installed on the box, the NCM Syslog Server was not installed and you'll never see anything in its Syslog Viewer application.

You can follow the steps in the Admin Guide to configure the NPM Syslog Server for realtime change detection. At a high-level, the steps are as follows:

1) Configure your devices to send Syslog to NPM when change events occur

2) Create rule in Syslog to execute ConfigAutoDownload.exe ${IP}

HTH

chris.lapoint

Okay Chris,
I can't seem to tell if this is precisely what's happening, or just what it looks like.
I'm running NPM's syslog server and trap receiver.
I am not running the services for NCM's syslog server and trap receiver because it's running on the same box, and the alerting takes precedence over NCM all day long.
As a workaround for syslog and traps not being able to be handled by both systems on the same box, can I forward the traps and syslogs from NPM to NCM?
Ideally, they should be sharing common data, full integration, even into the same SQL database, or at least have the NCM product be able to pull from both.
I don't have a need for NCM to do historical reporting on SNMP trap or syslog data. For that matter, NPM doesn't do that either, and it should.
The problem is, I need NCM's functionality to work even though I'm having NPM take the first crack at the data. The only way I could think of this to work would be to forward traps to a non-standard UDP port on localhost, something like create rules in NPM to forward traps to 127.0.0.1:8162 udp, and forward syslog to 127.0.0.1:8514 udp. In order for that to work, I need to be able to configure the NCM syslog server and trap receiver to listen on those non-standard addresses.
I have looked at the Admin guide. The NCM Syslog Server application is showing me syslog messages from two days ago, and none of the SSH user logout messages that I specifically want to discard some of, because it's the NCM/rancid user, and trigger configuration backup on the ones that aren't the NCM/rancid users so I have a snapshot of the config every time a user logs out of either the https or ssh interface of the device.
The configuration isn't complicated, it's just not working.
Peter

You're on the right track with assuming you only need a single Syslog Server for Realtime Change Detection to run. As noted in my post above, if NPM and NCM are installed the same box, you can just use NPM's Syslog Server. The Admin Guide instructions for setting up realtime change detection that reference NCM's Syslog Server also apply to NPM's Syslog Server. NCM doesn't care which Syslog Server you use.

After you've followed the Admin Guide instructions for enabling Realtime Change Detection in the NCM desktop application, here's how you configure NPM's Syslog Server to trigger NCM:

a. Configure devices to send syslog to NPM when configuration changes occur

b. Open NPM Syslog Server

c. Click View > Alerts/Filter Rules.

d. Click Add New Rule.

e. Provide the appropriate information on the General tab and DNS Hostname tab.

f. Click the Message tab, and then type the message pattern to look for in the Message Type Pattern field. The message pattern will vary by device type. For example, when a change is made to a Cisco router, a syslog message containing SYS-5-CONFIG_I: is sent. For more information about what messages are sent, see the documentation provided by the vendor of your device.

g. Click the Alert Actions tab, and then click Add New Action.

h. Select Execute an external program, and then click OK.

i. Type the following in the Program to execute field: Path\Configuration Management\ConfigAutoDownload.exe ${IP}
Where Path is the location of the Configuration Management folder. For example, “C:\Program Files\SolarWinds”. If the path contains spaces, enclose the path section of the statement in quotation marks (“).
j. Click OK.
k. Ensure the new rule is checked in the Alerts / Filter Rules

pserwe

You're on the right track with assuming you only need a single Syslog Server for Realtime Change Detection to run. As noted in my post above, if NPM and NCM are installed the same box, you can just use NPM's Syslog Server. The Admin Guide instructions for setting up realtime change detection that reference NCM's Syslog Server also apply to NPM's Syslog Server. NCM doesn't care which Syslog Server you use.
After you've followed the Admin Guide instructions for enabling Realtime Change Detection in the NCM desktop application, here's how you configure NPM's Syslog Server to trigger NCM:
a. Configure devices to send syslog to NPM when configuration changes occur
b. Open NPM Syslog Server
c. Click View > Alerts/Filter Rules.
d. Click Add New Rule.
e. Provide the appropriate information on the General tab and DNS Hostname tab.
f. Click the Message tab, and then type the message pattern to look for in the Message Type Pattern field. The message pattern will vary by device type. For example, when a change is made to a Cisco router, a syslog message containing SYS-5-CONFIG_I: is sent. For more information about what messages are sent, see the documentation provided by the vendor of your device.
g. Click the Alert Actions tab, and then click Add New Action.
h. Select Execute an external program, and then click OK.
i. Type the following in the Program to execute field: Path\Configuration Management\ConfigAutoDownload.exe ${IP}
Where Path is the location of the Configuration Management folder. For example, “C:\Program Files\SolarWinds”. If the path contains spaces, enclose the path section of the statement in quotation marks (“).
j. Click OK.
k. Ensure the new rule is checked in the Alerts / Filter Rules

I see, I seem to have previously missed that it's handled from an external standalone app handler, so, for the sake of centralizing as much as I can, I won't do *any* rules or operations from NCM's syslog viewer, especially since I get seemingly incomplete results trying to view syslog from it. I can just use NCM's syslog handler to build the rules and run that external program.

I'm still begging for traps and syslog to be better integrated into the core NPM application. I can't stand having 3 places to deal with traps and syslog, not to mention the lesser functionality which on syslog I can kind of understand, but on traps, not really. Anyway, that's a feature request and already noted in the appropriate forum, plus, I'm sure we'll touch on it tomorrow ever so slightly.

Thanks again,

Peter