Add more active support instrumentation data

[ChrisBr]

Currently the db & view data is coming from ActiveSupportInstrumentation#process-action.action-controller event. This only tells you that all DB queries / View took N amount of time.

However, ActiveSupport also offers more events which allow to get more granular data:

• https://edgeguides.rubyonrails.org/active_support_instrumentation.html#sql-active-record
• https://edgeguides.rubyonrails.org/active_support_instrumentation.html#action-view

I would be open to look into the details and send a PR if this is a feature you would accept?

[dmke]

This looks interesting. I've just raised the minimal supported version from 4.0 to 4.2, so you can assume these keys exist:

• https://guides.rubyonrails.org/v4.2/active_support_instrumentation.html#process-action-action-controller
• https://guides.rubyonrails.org/v4.2/active_support_instrumentation.html#action-view

Keys added in later Rails versions should only be added if present in the payload hash.

The SQL instrumentation however does not look like they'd be useful. I wouldn't store queries or bind parameters in a time series database; they belong (if at all) in a log file.

If you want to give it a try, please target the 1.0-beta branch (not master) for now.

[ChrisBr]

The SQL instrumentation however does not look like they'd be useful. I wouldn't store queries or bind parameters in a time series database; they belong (if at all) in a log file.

Yes, the query would need to get 'cleaned', so e.g. replace / unify values. For instance what is described here:

• http://stevenyue.com/blogs/tracking-sql-queries-in-rails/
• https://github.com/steventen/sql_tracker
  Would that be more useful or neglecting SQL instrumentation for now?

If you want to give it a try, please target the 1.0-beta branch (not master) for now.

Ok, will have a look at the action view instrumentation.

As I understand, https://guides.rubyonrails.org/v4.2/active_support_instrumentation.html#process-action-action-controller is already implemented in this gem, no?

[dmke]

Would [sql_tracker] be more useful or neglecting SQL instrumentation for now?

Hm, I'm hesitant to pull in external dependencies. If its feasible to wrap the query tracking in a defined?(SqlTracker) conditional (which leaves the decision to add this dependency to the host application), then go for it.

As I understand, https://guides.rubyonrails.org/v4.2/active_support_instrumentation.html#process-action-action-controller is already implemented in this gem, no?

Indeed, I've merged your PR half an hour ago.