Script EventSource to grab Traps?? Is it possible?

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

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).

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. 

2 minutes ago, Stuart Weenig said:

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. 

But that means I would've to install something at the collector level (to receives the traps & dumps them into a log entry). Right?

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. 

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.

@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?

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

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!

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.