Idea Details

Spectrum - Syslog Server

Last activity 06-13-2019 10:07 AM
franz.wallner's profile image
12-20-2012 07:28 AM

Within our environment we have several information, which is only send by syslog from Cisco Devices and not available via SNMP Trap. eg. the IS-IS neighborship information is only available via Syslog on Cisco.
Due to this we would like to have the capability to collect syslog messages and forward them as Event to Spectrum too.
In the meantime we are using IBM Tivoli Netcool, which has a Syslog Probe available.


Comments

09-15-2016 12:04 AM

I've done some very early work with a free syslog utility called rsyslog .  One of the nice features is that it has an output module for SNMP traps (omsnmp: SNMP Trap Output Module — rsyslog 8.18.0 documentation  ).  The default trap that comes out doesn't seem to match the MIB, so I had working around things using event procedures but then noticed that I could specify arbitrary values for trap oid and varbinds.  So, in my rsyslog.conf I have the following, in addition to the defaults:

 

module(load="omsnmp")

 

ruleset(name="network"){
    action(type="omfile" file="/var/log/networklog")
    action(type="omsnmp" transport="udp" server="SPECTRUM_IP_HERE"
           trapoid="1.3.6.1.4.1.546.1.1.0.4" port="162" version="1"
           messageoid="1.3.6.1.4.1.546.11.1.1.6" community="public")
}    

 

# Provides UDP syslog reception
# for parameters see http://www.rsyslog.com/doc/imudp.html
module(load="imudp") # needs to be done just once
input(type="imudp" port="514" ruleset="network")

 

The trap OID is the one used by SystemEDGE for a log file match and the message OID is the same varbind that SystemEDGE uses for the line that matches.  Spectrum supports a use case where SystemEDGE, SNMP Research CIAgent (also known as Aprisma iAgent), and NSM can use log file match traps from these agents as a source of syslog data ( Configuring CA Spectrum to Process Syslog File Matches - CA Spectrum - 10.1 and 10.1.1 - CA Technologies Documentation ).  So, my thought in choosing the SystemEDGE trap format (and I'm missing several varbinds) was that I can reuse this functionality, especially since there are just over 12K parsemap entries that come out of the box with Spectrum 10.1+

 

It appears to work:

 

 

The out of the box clear is working for my link up/link down as well:

 

These are coming in purely via syslog since I have no SNMP traps configured on my test router.

 

Useful?

 

-Rob

02-09-2016 03:33 AM

Hi Kiran,

 

are there any news on integrating this with 3rd party solutions ?

 

Regards,

Ben

06-15-2015 05:05 AM

Hello All,

 

The team has spent an enormous amount of time on this idea trying multiple options - given this has so many votes.

But we are not able to get a solution as we cannot just have a "syslog browser" but also need a "syslog server" to get the solution, which is not only HUGE work, but also changes the Spectrum deployment, making it very risky.

 

We will need to decline this request and we are trying to research ways to integrate with 3rd party solutions for this.

 

Regards,

Kiran Diwakar

09-10-2014 01:37 PM

If you need to have udp 'replicated' to other hosts I would suggest using something like samplicate. This is a small powerful utility which lets you 'samplicate' any udp traffic on any port to other hosts/ports. We use it on our trap directors, to replicate to other systems and dev boxes. You can configure multiple processes to samplicate different traffic (syslog vs traps).

 

Regarding syslog analysis, it is a very tedious process trying to correlate some traps with syslog, as in some cases there is not a 1 to 1 match. For BGP for example, it is difficult to match up what Spectrum gets and what syslog gets and work out which we can deduplicate.

 

We are trying to stop reliance on syslog, but it's not so easy You could convert syslog to traps and then send them to spectrum but you still need to deduplicate them so you don't get many events/alarms for the same problem.

 

I think trying to add syslog is not a bad thing, but you will find some customers do some crazy stuff and a simple syslog server won't necessarily give them any benefit. If there is a syslog solution, it should be as an add-on and not something you must use. There are many open-source solutions as well as 3rd party solutions, and you will find that different customers use their choice for different reasons.

09-05-2014 03:45 AM

We use Splunk for analyzing syslog. It has superior search and reporting capabilities.

I think Spectrum is not suitable for storing large amounts of syslog data as events.

MySQL (where the event data is stored) is too slow for that and Spectrum lacks proper event reporting.

08-31-2014 09:27 AM

Hi Kiran,

keep in mind that other competitors have a syslog solution/integration in their portfolio.

Just last week a had a discussion with our UK colleges that they can't move to spectrum without a syslog solution.

 

best regards

Uwe

07-30-2014 08:45 AM

We have also been investigating a tighter integration with Spectrum for Syslog processing.  The direction that we are looking to take is to create a syslog connector for SOI or EventIntegration piece of SOI.  The connector technology with EventIntegration is so simple it should make for an easy way to get the data into the system and then either process it within SOI or transfer it back to Spectrum.

07-30-2014 08:40 AM

Hi Jurgen,

 

Point very well taken - we could recommend something.

The reason we have refrained from doing so is because we would need to go through a formal set of steps internally, get legal approvals etc to "recommend" something. I personally do not mind following that route.

But you would agree Jurgen, we would need to be able to spend that time on items that have the maximum impact across the user base. While I will ask around within our services and pre-sales teams - for us to go this formal route, we would typically need more votes. Just wanted to share my perspective too.


Thanks for your time with the comment and suggestions - much appreciated.


Regards,

Kiran Diwakar

07-30-2014 07:36 AM

I have one thought,

 

Instead of leaving people searching their own solution, it might be useful to steer them towards a solution. This way, you as CA know what most people
would use, and start developing the integrations for this supported 3party tool.

 

I have of course no clue on the commercially and strategically point of view of CA Technologies. Kiwi is great for us, but it is a solarwinds product.  Do you want to
make your customers aware of solarwinds?

Could CA agree with Solarwinds or another company on a CA Syslog Aggregator which is a CA branded OEM version of kiwi or something else.

 

Reason to mention this:  in my organization it’s difficult to introduce a new vendor, they want to know why existings can’t do it and much more
blablabla.  If it was a CA Syslog aggregator, nobody would think about it, it’s an extension of the existing baseline.

 

Instead of developing from scratch with all the efforts you can:

 

  • Recommend a third party solution
  • OEM version of a third party solution
  • Write a syslog to trap module for unix/linux (Using a tracer on the syslog daemon messages file, e.g. perl based, scheduler controlled)
  • Develop the "syslog to trap" service on Windows

 

The last two enable syslog under your control without big changes in the CA Software.

These or just suggestions that might make it easier to bypass the issue until they give a green light for the development.

 

but from my point of view (15 years management software, an old Micromuse Admin )

It’s the way to go, syslog is tcp, traps not and more info is available through syslog then through snmp.

  

Thanks for the follow up

  

Jurgen

07-30-2014 07:07 AM

We are considering and reviewing implementing this - but this needs a full blown syslog server in Spectrum and the effort is becoming too prohibitive.

We would need to request users to continue to use a 3rd party tool.

 

Thoughts before I mark the idea?


Regards,

Kiran Diwakar

07-30-2014 04:55 AM

We use a similar Kiwi solution, as it adds the advantage of multiplying your syslog messages to other sources (Securtiy, archiving, ...) and more user friendly then a syslog daemon on a unix/linux platform.  I hope they bring out a straight syslog listener, so we don't have to convert to traps.

06-06-2013 05:56 PM

I had the same need to integrate monitoring platform with v / OS, what we did was to implement the software kiwi syslog server, which has the ability to convert syslog messages to SNMP traps, and these are sent to spectrum