On 7/16/2022 at 10:03 AM, Stuart Weenig said:Agreed.
This is how syslog works with LM Logs. It can be done, but LM is pretty anti-traps, so they might not do it for traps any time soon (even though they likely could). Have you thought about samplicator? It could be a single point that your infrastructure can send to, and you can configure it to forward to one/all/specific collectors.
That said, I'll echo LM: what are you getting from traps that you aren't getting from polling? Seriously. If the answer is non-zero, in most cases, you can identify the values bound into the traps and poll them, eliminating the need for a trap. Not to mention EventSources don't have a concept of one trap to open the alert and a corresponding alert to close the trap.
Thanks Michael. Unfortunatly the issue is that we've hit a hard limit on how much we can poll off the end devices. We're polling Huawei optical kit that aggregate's residential connections and in addition to interface stats we are attempting to use the equipment supported dying gasp traps as these represent a customer impacting issue. However attempting the poll the 800000+ dying gasp state per device has proven completely unable to scale (both in collector tasks as well as load introduced on the managed element).
