Script EventSource to grab Traps?? Is it possible?

Hello LM folks,

Due to the fact of LM not suppressing SNMP Traps, we've came up with an idea to do it ourselves (leveraging the API).

However, we need to somehow listen to those traps via Groovy scripting (if possible of course). This doesn't seem doable but, doesn't hurt to ask.

Did anyone accomplished/had this need in the past?

Thanks!

Vitor_Santos

Posted 5 years ago·Last reply 5 years ago

12 comments

Vitor_Santos

OP5 years ago

We've a Trap server in our environment & all our clients send Traps into it. The problem is that it belongs to our old solution architecture (which we like a lot) but, they'll be shutdown soon.
Our upper management wants to get rid of those & all the VPN tunnels we've from our DCs to our clients infra (which allowed us to send Traps to a single spot).

That's why we're ultimately leveraging a workaround for the stuff we still need to rely on Traps. Never mind, I think we just found a solution.
We'll receive the duplicated Traps on LM, set the ES to clear them every 5 minutes (which really doesn't matter because we're sending them to SNOW & ignoring the CLEAR events there).

This way the alert will have to be cleared manually on SNOW & we're also transforming the Event ID (alert id on LM) to be static (this way we only have 1 alarm on SNOW).

Thanks!

LM User

·5 years ago

Hopefully you're using SNMPTT?

LM User

·5 years ago

You could have all the trap stuff go to one place with a single logger that converts traps into individual files per device. Then your config source could go to that directory and look for a file that matches the name of the device. Single destination, no modification of collectors.

Vitor_Santos

OP5 years ago

3 minutes ago, Stuart Weenig said:

I don't know of a way, but you might ping support. There used to be a bunch of freeware tools that do this.

Yes, I found a tool this morning that does that. Was able to create a config source that accommodates our needs, however, that represent a LOT of manual work in each collector. Which isn't a optimal solution.
We were wondering if there's a property that we can set on the collector config for it to dump the received traps within a certain log file. I'll poke support about it.

Thanks anyway @Stuart Weenig!

LM User

·5 years ago

I don't know of a way, but you might ping support. There used to be a bunch of freeware tools that do this.

Vitor_Santos

OP5 years ago

@Stuart Weenig, do you know if there's any way to dump the traps received by the LM collector into a .txt file or something?

Vitor_Santos

OP5 years ago

13 minutes ago, Stuart Weenig said:

Yes, you'd have to build something that converts the traps to logs.

LogicMonitor has always frowned at reliance on traps due to their unreliable nature and due to the fact that you can 99.9% of the time get at the data through polling, which opens a whole better mode of monitoring. Case in point: the fourth search result for "snmp traps vs polling" is a blog post I did 9 years ago where I talked about a different product's ability to receive/process traps.

One of my mantras: "Just because you did do it one way, should you continue to do it that way?" Think about the goal? How can you adjust to a better observability mechanism and enrich your data. Think about it, you can't do dynamic thresholds on a trap, but if you were polling the data you could.

I totally agree with you, if possible use SNMP or some other retrieval method. However, there are certain very specific metrics/conditions that are only available with Traps/Syslogs.

LM User

·5 years ago

Yes, you'd have to build something that converts the traps to logs.

LogicMonitor has always frowned at reliance on traps due to their unreliable nature and due to the fact that you can 99.9% of the time get at the data through polling, which opens a whole better mode of monitoring. Case in point: the fourth search result for "snmp traps vs polling" is a blog post I did 9 years ago where I talked about a different product's ability to receive/process traps.

One of my mantras: "Just because you did do it one way, should you continue to do it that way?" Think about the goal? How can you adjust to a better observability mechanism and enrich your data. Think about it, you can't do dynamic thresholds on a trap, but if you were polling the data you could.

LM User

·5 years ago

You could create a trap listener, separate from lm, that converts the traps with their data to a log entry. Then you could create a scripted log ES to parse through the events and suppress the ones you don't want.

OID name translation has been requested before.

Vitor_Santos

OP5 years ago

Exactly, that's one of the intentions that we've as well.
It would be very handy. However, I'm not sure if this is doable.

We would like to create a scripted Event Source for Traps to accomplish the message suppression as well (that's lacking on ES for Traps currently).

Jason_Fant

·5 years ago

I too would like that ability. While the traps is somewhat functional, I'd like to be able to take the trap and write some scripting to replace some of the OIDs in the message of the trap to what their names actually are within the MIB.

Something like this:
Enterprise OID: 1.3.6.1.4.1.231.7.2.1.21.2.3
Message: 1.3.6.1.4.1.231.7.2.1.21.1.3.2: SYS1
1.3.6.1.4.1.231.7.2.1.3.1.1.1: 1
1.3.6.1.4.1.231.7.2.1.3.1.1.10: ADVISORY
1.3.6.1.4.1.231.7.2.1.3.1.1.11: --
1.3.6.1.4.1.231.7.2.1.3.1.1.12: --
1.3.6.1.4.1.231.7.2.1.3.1.1.13: --
1.3.6.1.4.1.231.7.2.1.3.1.1.14: 1615802432
1.3.6.1.4.1.231.7.2.1.3.1.1.2: 0
1.3.6.1.4.1.231.7.2.1.3.1.1.3: 0
1.3.6.1.4.1.231.7.2.1.3.1.1.4: 2147481553
1.3.6.1.4.1.231.7.2.1.3.1.1.5: F4066
1.3.6.1.4.1.231.7.2.1.3.1.1.6: M4
1.3.6.1.4.1.231.7.2.1.3.1.1.7: NO ACT
1.3.6.1.4.1.231.7.2.1.3.1.1.8: BPA
1.3.6.1.4.1.231.7.2.1.3.1.1.9: CP
enterpriseOid: 1.3.6.1.4.1.231.7.2.1.21.2.3

To this:
Enterprise OID: 1.3.6.1.4.1.231.7.2.1.21.2.3
Message: hicomErrTrpMnemonic: SYS1
hicomErrorPabxId: 1
hicomErrorSubevent: ADVISORY
hicomErrorCardRef: --
hicomErrorBoardVersion: --
hicomErrorFwType: --
hicomErrorTimDat: 1615802432
hicomErrorAlGroup: 0
hicomErrorAlSubId: 0
hicomErrorSerialNo: 2147481553
hicomErrorMsgId: F4066
hicomErrorPriority: M4
hicomErrorAction: NO ACT
hicomErrorAbsMod: BPA
hicomErrorEvent: CP
enterpriseOid: 1.3.6.1.4.1.231.7.2.1.21.2.3