Can this plugin be extended to receive snmp traps?

[tchenscw]

Hi, Since snmpv3 support for snmptrap plugin has been opened for a long time, I was wondering whether there is a way to extend this plugin to receive snmp traps via v3 protocol.

[edperry]

You should look at https://www.elastic.co/guide/en/logstash/current/plugins-inputs-snmptrap.html

[tchenscw]

Hi edperry, I did. But this issues https://github.com/logstash-plugins/logstash-integration-snmp/issues/49 remains opened since 2015. Even longer for the ruby support of snmpv3. My angle is since snmp input plugin act similar as snmp manager, extending it with trap receiver would not be as far fetched. Any thoughts?

Thanks

[edperry]

I am not the repo manager, but it seems the reason the logstash-input-snmptrap did not implement is because the "gem" snmp library does not support it. I don't know if both are using the same library or not. This a bet would be that they are.

As for adding it to this project, IMO it would not be appropriate, since this is a "Polling" plugin and receiving SNMP traps is a Passive operation (Listening) those are completely 2 different functions and again IMO should be 2 seperate functions like logstash-input-file and logstash-input-tcp similar functionality but different logic and behavior.

but again, these are only my thoughts based on my observation of the Logstash community over the years. I would defer to any of the repo-admins to their opinions.

[axrayn]

@tchenscw Pretty much as @edperry says. The logstash-input-snmptrap is a purely ruby implementation using the http://github.com/hallidave/ruby-snmp gem for the SNMP parts whereas this plugin is JRuby using the SNMP4J Java library.

The problem arises because (last I checked) the author of the ruby gem said back in 2011 that he didn't have the time or motivation to add it (https://github.com/hallidave/ruby-snmp/issues/2#issuecomment-832274) in writing v3 support.

As for including SNMP trap support in this plugin, whilst @colinsurprenant does have it listed in the 'Post GA' plans in the META issue logstash-plugins/logstash-input-snmptrap#2, I'd be inclined to agree with @edperry that this plugin is more designed as a poller not a listener.

[colinsurprenant]

@tchenscw @edperry @axrayn thanks for your input here!

• Yes the legacy snmptrap input is mostly unmaintained at this time and does rely on an old gem that does not support v3.
• The original plan per logstash-plugins/logstash-input-snmptrap#2 Post V1 GA tasks is to bring back the trap handling into this new snmp input plugin.
• I do not see any problem in handling both polling and receiving traps into this same plugin. If someone really want separate handling for polling and trap handling then it will be possible to use two plugin instances (in 2 defferent pipelines if needed too) just for that.
• The usage of the solid SNMP4J library here will provide more robust trap handling and we will be able to reuse all rest of the infrastructure code we have here too.

[axrayn]

Ironically, after I posted, I started looking at whether I could rewrite the snmptrap plugin from scratch using the SNMP4J library. I stopped after the third or fourth "I'll just borrow this function from the snmp plugin...." and had realised the craziness. :)

[colinsurprenant]

@axrayn, any PRs for that are welcome 😄 I myself likely won't be able to work on that in the next few weeks.

[axrayn]

@colinsurprenant I'm still struggling with tables, that's a higher priority for our needs at work. Will definitely see what I can do though.

[colinsurprenant]

@axrayn finding the best way to represent snmp tables is definitely high on my priorities too. I'd love to hear your thoughts, let's open a separate "design" issue about this.

[colinsurprenant]

@axrayn opened #45 for this.

[tchenscw]

@colinsurprenant @axrayn Thanks for the explanation. Glad to hear there is a plan to support trap receiver. Our group has some expertise in Java but not in Ruby. We will follow closely and see if there's anything we can help.

[colinsurprenant]

Issue #46 discusses trap handling. Closing.