Log snmpv3 auth failures

[Hipska]

While I still believe this is a check that gosnmp should do, let's not wait for them to implement.

Fixes #7929 as no metrics with strange values will be produced, instead telegraf will return a clear error message.
Closes #8215 since there is no feedback from original author.

Required for all PRs:

• Associated README.md updated.
• Has appropriate unit tests.

[telegraf-tiger]

🤝 ✅ CLA has been signed. Thank you!

[Hipska]

Hi @reimda I have added some hardcoded messages for the most common types of report that will be received. What do you think of that?

[Hipska]

There is something going on with gosnmp/gosnmp#314 but I'm not yet convinced it is good yet.

[Hipska]

Okay, we can go. When a new version of gosnmp is released, I will update our check..

[reimda]

With gosnmp/gosnmp#314 merged it sounds like we should change our approach for this PR. If we update gosnmp we won't need to hard code the USM report OIDs, and we can use the improved error message that Get() returns instead of adding our own.

[Hipska]

Indeed, so maybe we can already merge this and adapt the improvements when gosnmp releases a new version afterwards?

[reimda]

I was thinking since the gosnmp PR has been merged and since go mod lets us depend on any commit in a library, we don't need to wait for a new gosnmp release. We could go get github.com/gosnmp/gosnmp@a3738642b2d1 to use the latest from gosnmp. That would let us fix the auth failures now and in the way we expect to use long-term.

I ordinarily avoid using prerelease libraries, but looking at gosnmp's history, besides PR 314 there is only one other code change since the 1.30.0 release and it's pretty simple. In this case using a prerelease doesn't introduce much risk.

Gosnmp seems to be making releases every few months and 1.30.0 came out a month ago. If we don't use a prerelease version we will likely have to wait a month or two for a release before we come back to this.

[TimRots]

Gosnmp seems to be making releases every few months and 1.30.0 came out a month ago. If we don't use a prerelease version we will likely have to wait a month or two for a release before we come back to this.

Sorry for the hold-up. Released gosnmp v1.31.0 today.

Thanks again @Hipska for your help

[Hipska]

Great! I think I’ll have time this week to implement this.

[reimda]

Gosnmp seems to be making releases every few months and 1.30.0 came out a month ago. If we don't use a prerelease version we will likely have to wait a month or two for a release before we come back to this.

Sorry for the hold-up. Released gosnmp v1.31.0 today.

@TimRots Thanks for your work on gosnmp and for releasing 1.31.0! I was clearly too pessimistic about release scheduling. Having a gosnmp release that includes gosnmp/gosnmp#314 is great for this PR.

[TimRots]

@TimRots Thanks for your work on gosnmp and for releasing 1.31.0!

Thank you @reimda. Happy to help out :)

I was clearly too pessimistic about release scheduling.

Since gosnmp became a community effort we try to do a monthly release, but it still depends on how much time we have to work on things. If a bug is urgent and we try to move forward quicker ofc.

Having a gosnmp release that includes gosnmp/gosnmp#314 is great for this PR.

314 landed really nice with the help from hipska and superq. Will keep an eye on this pr to see how it works out here :)

[Hipska]

Hi @reimda, can you please review again?

[telegraf-tiger]

Looks like new artifacts were built from this PR. Get them here!

Artifact URLs

• aarch64.rpm

• armel.rpm

• armv6hl.rpm

• i386.rpm

• ppc64le.rpm

• s390x.rpm

• x86_64.rpm

• darwin_amd64.tar.gz

• freebsd_amd64.tar.gz

• freebsd_i386.tar.gz

• linux_amd64.tar.gz

• linux_arm64.tar.gz

• linux_armel.tar.gz

• linux_armhf.tar.gz

• linux_i386.tar.gz

• linux_mips.tar.gz

• linux_mipsel.tar.gz

• linux_ppc64le.tar.gz

• linux_s390x.tar.gz

• static_linux_amd64.tar.gz

• windows_amd64.zip

• windows_i386.zip

• amd64.deb

• arm64.deb

• armel.deb

• armhf.deb

• i386.deb

• mips.deb

• mipsel.deb

• ppc64el.deb

• s390x.deb

[reimda]

Looks great!

[srebhan]

Looks good to me.

[Stomper98]

I am still seeing this issue on Centos 7 with Telegraf 1.21.2. We get massive amount of hostnames with random numeric values when a remote SNMPv3 service fails connection. Following through on all the tickets about this issue with gosnmp, is there a fix in sight ?

[Hipska]

@Stomper98 whoosh this is a fix/Pr that has been merged a very long time ago. So on our end there is nothing to be fixed since we didn’t got any reports on it anymore.

if you experience any snmpv3 issues, please create a new bug with your relevant config and log messages, so we can look into it.