Migrate syslog/v2 to syslog/v3 (adds RFC3164 support to inputs.syslog) (#4593)

[thepacketgeek]

Add RFC3164 Support for inputs.syslog (#4593)

This PR replaces go-syslog/v2 usage with go-syslog/v3 so that the inputs.syslog plugin can use the new RFC3164 support. Resolves #4593

Usage

When defining the inputs, a user will specify the syslog_standard option (Either "5424" [default] or "3164"). The best_effort option will also apply when "3164" is used.

Notes

I was really hoping that this would let me use telegraf direction for Cisco syslog messages, but from my understanding it seems they have some problems with current go-syslog parsing:

Format: <PRI>SEQNUM:HOST:MONTHDAY YEARHOUR:MINUTES:SECONDS.MILLISECONDSTIMEZONE:%APPNAME-SEVERITY-MSGID:%TAGS:MESSAGE

Example: <187>37972: Nov 21 16:53:33.429: %LINK-3-UPDOWN: Interface GigabitEthernet0/8, changed state to down

• Seq field instead of version number
• No hostname provided
• Severity level, app, and MsgId is encoded in the %APPNAME-SEVERITY-MSGID format

@goller Is handing these messages something that might be in scope for the RFC3164 parser in go-syslog?

Required for all PRs:

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

[thepacketgeek]

This also addresses #7023, although @leodido I'd love feedback on what you think about options to expose for RFC3164 parsing?

[endersonmaia]

Is there anything I can do to make this available on the next release ?

[thepacketgeek]

@endersonmaia I've just rebased and things should be good to go, I'm not sure how to get in front of a reviewer

[endersonmaia]

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

wow, that's nice, I'll give it a shot and test for real on some of my devices, and give some feedback if something breaks

@thepacketgeek I'll ping some contributors here that I have already interacted, hope that's fine

/cc @danielnelson , @ssoroka

[thepacketgeek]

Thank you!!

[endersonmaia]

/cc @sjwang90

[sjwang90]

Thanks @thepacketgeek and @endersonmaia. You both were able to test with the built artifacts? We'll get this reviewed by some of our Telegraf maintainers soon.

[endersonmaia]

I'm planning to test later this week, and will update here Em qua, 23 de jun de 2021 15:53, Samantha Wang ***@***.***> escreveu:

…

Thanks @thepacketgeek <https://github.com/thepacketgeek> and @endersonmaia <https://github.com/endersonmaia>. You both were able to test with the built artifacts? We'll get this reviewed by some of our Telegraf maintainers soon. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#8454 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAC4VRMKHG3TD7OQXQLWDTUIURPANCNFSM4T6VDT4Q> .

[endersonmaia]

I just tested it with one of my devices, and it's working just fine!

[leodido]

I've taken a quick look at this PR and it LGTM!

[thepacketgeek]

@leodido Are there any action items for me to complete, or is this PR just waiting for merge?

[telegraf-tiger]

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

Artifact URLs

• darwin_amd64.tar.gz

• windows_amd64.zip

• windows_i386.zip

• s390x.rpm

• linux_s390x.tar.gz

• s390x.deb

• aarch64.rpm

• linux_arm64.tar.gz

• arm64.deb

• i386.rpm

• freebsd_i386.tar.gz

• linux_i386.tar.gz

• i386.deb

• linux_mips.tar.gz

• mips.deb

• static_linux_amd64.tar.gz

• linux_mipsel.tar.gz

• mipsel.deb

• ppc64le.rpm

• linux_ppc64le.tar.gz

• ppc64el.deb

• armel.rpm

• linux_armel.tar.gz

• armel.deb

• armv6hl.rpm

• freebsd_armv7.tar.gz

• linux_armhf.tar.gz

• armhf.deb

• x86_64.rpm

• freebsd_amd64.tar.gz

• linux_amd64.tar.gz

• amd64.deb

[leodido]

🔥