Improve Email Observability in Spring Framework

[famaridon]

Hello,

I am using Spring Boot with Micrometer to monitor my application. Everything works well except for email monitoring. The JavaMailSenderImpl class does not support observation.

I created a decorator to solve this issue, but it's not perfect. I had to bridge the send(MimeMessage... mimeMessages) method to the send(MimeMessage mimeMessage) method. This has the side effect of reopening the Transport for each MimeMessage.

Before submitting a pull request, I would like to discuss two possible solutions with you:

Option 1: Register TransportListener

• Add the ability to register a TransportListener for all created Transport objects.
• Pros:
  • Useful for metrics: We can count delivered, not delivered, and partially delivered messages.
  • Spring does not need to add a custom class to support this.
• Cons:
  • Not useful for tracing: We cannot surround the network call.

Option 2: New MailSendListener Interface

• Create a new interface, MailSendListener, dedicated to mail observations, similar to Spring Data MongoDB.
• Pros:
  • Useful for metrics: We can count delivered, not delivered, and partially delivered messages.
  • Useful for tracing: We can surround the network call.
• Cons:
  • Spring needs to add a custom interface to support this.

Please let me know your thoughts on these options.

Thank you!

---

[bclozel]

That's something we could look into.
Are you aware of existing instrumentations or semantic conventions for this?
I'm wondering if this couldn't be just like JMS: an instrumentation at the jakarta.mail level that could be contributed to Micrometer directly.

[famaridon]

I found nothing about mail/SMTP in the semantic conventions. I will create an issue on the OpenTelemetry side.

It might be nice to add this to Micrometer. I will check how it works and test it.

Is it something like this? Micrometer Jakarta9 JMS Instrumentation

[bclozel]

@famaridon

I found nothing about mail/SMTP in the semantic conventions. I will create an issue on the OpenTelemetry side.

Thanks! Please share the link here.

Is it something like this? Micrometer Jakarta9 JMS Instrumentation

Yes, but proxying in this case might not be required, it all depends on what should be instrumented and how.

[famaridon]

@bclozel I think I need proxying the Session and the Transport to be able to catch calls to transport.sendMessage()

[bclozel]

Thanks @famaridon . I'll leave this opened for now but I will probably close it as soon as the OTel and Micrometer issues are created.

[famaridon]

Opentelemtry request open-telemetry/semantic-conventions#1945