SNMP Integration

[BenB196]

Integration release checklist

It would be nice to have a native SNMP integration within the Elastic Agent.

Currently to use SNMP, a user either needs to use Logstash or use something like snmp_exporter in conjunction with the Prometheus or OpenMetrics integrations. Both options require additional infrastructure overhead, that would be nice to remove.

All changes

• [ ] Change follows the contributing guidelines
• [ ] Supported versions of the monitoring target are documented
• [ ] Supported operating systems are documented (if applicable)
• [ ] Integration or System tests exist
• [ ] Documentation exists
• [ ] Fields follow ECS and naming conventions
• [ ] At least a manual test with ES / Kibana / Agent has been performed.
• [ ] Required Kibana version set to:

[legoguy1000]

I'd move (or duplicate) this to https://github.com/elastic/beats since the underlying agent/beat code to add the input would have to updated then an integration can be built on top of it.

[BenB196]

So, it looks like https://github.com/elastic/beats/issues/12798 already exists. Not sure if this one should be closed until its complete, or if it should be left open for tracking.

[botelastic[bot]]

Hi! We just realized that we haven't looked into this issue in a while. We're sorry! We're labeling this issue as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1. Thank you for your contribution!

[BenB196]

Not stale

[botelastic[bot]]

Hi! We just realized that we haven't looked into this issue in a while. We're sorry! We're labeling this issue as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1. Thank you for your contribution!

[marc-rousseau]

👍

[Erikg346]

+1 still need snmp integration

[zez3]

Same here +1

[zez3]

@kpollich @nimarezainia @cmacknz @jamiehynds any chance of having this pushed one step ahead?

[zez3]

https://pkg.go.dev/github.com/gosnmp/gosnmp

[JAndritsch]

+1

It would be awesome if there were Filebeat inputs equivalent to Logstash's snmp and snmptrap as well as an integration.

[nimarezainia]

@zez3 @JAndritsch apologies, unfortunately as of now we don't have plans to provide this functionality due t available development capacity and other higher priority projects.

[donasmello]

+1

[JAndritsch]

Would an integration for this basically be:

• Agent configuration that configures Filebeat to use a new snmp or snmp_trap input (obviously Beats would need to support these inputs too).
• Some kind of ingest pipeline that renames fields which have already been translated from an OID into their ECS equivalent

?

[cmacknz]

Yes, the first step would be to add an input type to one of the Beats that can walk SNMP OIDs. Likely in Filebeat or perhaps Packetbeat.

Then an integration to map the OIDs to ECS fields could be implemented. In cases where we have device or vendor specific integrations they could be augmented with the ability to retrieve SNMP data, this would additionally give the ability to handle vendor specific OIDs or standard OIDs that intentionally or unintentionally diverge from the standard. There is likely to be quite a lot of work here depending on what information you are after.

[BenB196]

Circling back on this topic, as it's been a bit since I opened it. At this point, I have mainly been using snmp_exporter in conjunction with Prometheus Collectors integration to do this work. And I somewhat agree with Elastic's hesitation to do a custom implementation of SNMP, as it's a significant lift to implement.

What I do think that would probably be a much better investment would be for Elastic to improve the user experience of what I'll refer to as "3rd party binary integrations" (integrations which require some additional service/binary to work).

It would be nice for Elastic integrations to be able to support additional things like referencing snmp_exporter, that can then distribute things like pre-built definitions as well as pipelines for ECS alignment and such. As of right now, there isn't a good way to share/distribute a lot of the work around these areas, because (at least from what I can tell) integrations here mainly rely on the underlying beats and such, and don't support requiring/specifying 3rd party binaries.

[zez3]

and don't support requiring/specifying 3rd party binaries.

I've encountered the same issue some time ago, my initial https://github.com/elastic/beats/issues/33049 was closed in favor of https://github.com/elastic/elastic-agent/issues/1237 My workaround was to use a custom tcp integration and push my local data(which was decrypted on the fly using a special binary) via some cronjob bash commands containing netcat into that listening beat localhost:port input.

We have in one Monitoring system alone ~5k snmp sensors that are managed by multiples teams. Fleet is not yet space aware. We cannot apply the same workaround here, even with snmp_exporter. If we are to use elastic stack as replacement for our current monitoring solutions(PRTG,MRTG,Zabbix,Spectrum CA, Prometheus+grafana and god knows what other teams use) then this is a must have. It must be easy to set-up. From my point of view the snmp walk input with a custom OID option would suffice for a start.

I would like to ask the observability team for their opinion on this Can some please ping the PM there? @jamiehynds

[zez3]

@abhiksingh Would you consider this a relevant enhancement request?

[willemdh]

We totally agree with this as a necessity. It's hard to see Elastic as a third generation monitoring product if its not able to do basic first generation monitoring stuff.