Script EventSource to grab Traps?? Is it possible?

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!

Hopefully you're using SNMPTT?

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.

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!

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

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

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.

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. 

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?

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.