Define events for the socket source

[binarylogic]

As part of finishing https://github.com/timberio/vector-product/issues/14, we need to define internal events for the socket source.

Prior Work

This source was previously instrumented as part of our initial work. But I want to double-check that it is comprehensive.

Defining events

• If you have not already, please read RFC 2064.
  • Be sure to read the Guide-level Proposal section and the implementation details that affect performance.
• You can also look at the currently defined events for precedence.
• Events should be named properly: <ComponentName><Noun><Verb>. For example, the syslog source defines the SyslogEventReceived struct.

Requirements

• Add a SocketEventReceived event.
  • Derive a events_processed metric via the emit_metrics method. (example)
  • If possible, derive a bytes_processed metric via the emit_metrics method. (example)
• Audit and add events for all possible errors. (example)
• Audit and add events for all component-specific behavior. (example)
• Ensure that logs in the hot path are rate limited via the rate_limit_secs parameter. (example).
• Ensure that all log messages start with a capital letter and end with a .. (example)

[bruceg]

A couple of questions here.

1. The socket source defines separate events for the mode of the source, ie TcpEventReceived and UdpEventReceived. Should these be unified into one SocketEventReceived as suggested or left separate?

2. If we keep separate events, in the socket source, there is an event named UnixSocketEventReceived. This does not match the other events above, however, UnixEventReceived is awkwardly generic, and UdsEventReceived is a little obscure (UNIX domain socket). Should this be renamed or just leave it?

[binarylogic]

We should unify the events into a SocketEventReceived event and add a mode attribute that represents the socket mode (tcp, udp, unix).