Feature Request: Improve observability

[sapmli]

We would like to improve our monitoring and error handling, especially for those cases which do not reach the backend session.

For example, we would like to expose the number of currently connected clients to Prometheus, to better understand load and idle times. But s.conns is an internal field, which we cannot grab during the NewSession(c *smtp.Conn) (smtp.Session, error) call. It would be great to have a method like this:

// Len returns the number of active connections.
func (s *Server) Len() int {
    s.locker.Lock()
    defer s.locker.Unlock()

    return len(s.conns)
}

The other thing is that, before the session is created, there is nothing we can do to identify a client connection. For example, there's no possibility to capture clients which do connect, timeout, and disconnect to whole time. We would like to trace such cases, in order to help users debug and fix setup problems, e.g. a missing proxy protocol or broken TLS certificate or whatever might be in the way, before the session is established.

For this, it would be great to add a connection ID as public field in the Conn struct. It should be generated as soon as the connection is accepted. Maybe something like a UUID or the format postfix uses as queue ID. MTAs usually log connect/disconnect events like [<conn-id>] connect from <hostname>[<ip-addr:port>], which is currently not possible. So, additionally to adding the connection ID, it would be great to either make go-smtp log that itself, or offer a logging hook, or to enhance the existing ErrorLog hook to also support connect and disconnect events. Also, all log lines sent to the ErrorLog should be enriched by the connection ID.

I'm looking forward to hear your opinion about this.

[lyda]

Oddly, I have a similar issue. I added this because I want metrics more than logs, but expanding it to your use case would be interesting. It might work already.

https://github.com/emersion/go-smtp/pull/274

[lyda]

Ok, in lieu of #274, is there an interest in any observability option @emersion ?