Instrument the generation of Action Mailer messages #12556
Conversation
| @@ -512,10 +512,14 @@ def initialize(method_name=nil, *args) | |||
| end | |||
|
|
|||
| def process(*args) #:nodoc: | |||
There was a problem hiding this comment.
I am wondering if it is worthy breaking ActionMailer::Base in two modules now. One with all the delivery stuff and another one on top that would add the instrumentation, following ActionController pattern.
There was a problem hiding this comment.
I was thinking that - I actually had a branch based off the first one that did this, but obviously it didn't work since it hooked into deliver_mail, which only happens after the mail has been generated.
Would it be okay to get this in first and then work on a refactoring later? It would probably require moving the existing #process code into a module (Implementation) and then including that and a separate Instrumentation module. It could easily obfuscate the content of this PR.
There was a problem hiding this comment.
I also want to use the same mechanism for including additional messages in the log line, e.g. Active Record includes a module that implements an add_info_to_payload method.
|
Just a few questions:
|
|
|
||
| super | ||
| @_message = NullMail.new unless @_mail_was_called | ||
| ActiveSupport::Notifications.instrument("generate.action_mailer", payload) do |
There was a problem hiding this comment.
maybe process.action_mailer to mimic action controller as well?
|
The logged message is fine, we can always adjust it later. :) |
|
@josevalim should I include the mailer method in the instrumentation? Right now only the name of the mailer itself is included. |
|
Okay, I've included the action - seems to be prudent. Do you want me to rebase? |
|
Yes, please rebase. I have also added a message about the event name. IMO it should be called |
|
Nah, I'll change it to "process". |
|
Actually, "process" makes it sound like we handle an incoming mail, "an email was processed". |
|
Naming is hard... what about "render"? Although actual rendering happens multiple times :-/ |
|
Okay, I've renamed it to "process" and squashed. I guess we'll find out if the name is confusing or not. If you merge this I'll start work on refactoring and adding support for view rendering time and db time. |
| def process(method_name, *args) #:nodoc: | ||
| payload = { | ||
| :mailer => self.class.name.to_s, | ||
| :action => method_name |
There was a problem hiding this comment.
Is that the convention in Rails nowadays?
There was a problem hiding this comment.
|
The build is failing due to some other thing :-/ |
The processing of outbound mail is instrumented with the key `process.action_mailer`. The payload includes the mailer name as well as the mailer method.
|
@dasch : Yes, this is not your fault ; this failure is present in lots of pull requests. @josevalim : Could you please review and merge this one if everything is ok ? :-) |
Instrument the generation of Action Mailer messages
|
Thanks! I'll get started on more granular metrics as soon as I have the time. |
|
Thank you guys! |
Currently, only the time spent sending a mail is instrumented in Action Mailer. The time it takes to render the views and building the mail object itself is not instrumented at all.
This PR adds very basic instrumentation. More data, such as view rendering time, database time, and really anything, can be added later.