Record data collected by Server-Timing Middleware

[kaylareopelle]

Rails' Changelog Text

Server-Timing specification defines how the server can communicate to browsers performance metrics about the request it is responding to. The ServerTiming middleware is enabled by default on the development environment by default using the config.server_timing setting and set the relevant duration metrics in the Server-Timing header. The full specification for Server-Timing header can be found in: https://www.w3.org/TR/server-timing/#dfn-server-timing-header-field Sebastian Sogamoso, Guillermo Iguaran

Questions

• Can this benefit our agent’s recording abilities?
• Is this within the purview of the Ruby Agent, or is it covered by a different agent?

Ideas

• Add as an attribute on a metric that’s already getting recorded
• Could be behind a feature flag/configuration option that runs only when the setting is enabled within Rails

[kaylareopelle]

Tabling to do more internal research to determine whether this is recorded by another Agent.

[workato-integration[bot]]

https://issues.newrelic.com/browse/NEWRELIC-3412

[hannahramadan]

Notes:

• Rails ServerTiming class, under ActionDispatch. It was introduced in Rails7.
• This is a current feature request of the node agent
• No mention of Server-Timing (or any variant) in the browser agent.
• server_timing is disabled by default in Rails
• The syntax of the Server-Timing header allows for metrics communications in different ways: server metric name only, metric with value, metric with value and description, and metric with description.

[hannahramadan]

Further investigation w/ @kaylareopelle

• We are reporting 3 HTTP response headers: http.statusCode, contentLength, and contentType. These headers are added as transaction attributes in transaction.rb, and discovered in middleware_tracing.rb. We are not currently set up to report on additional/custom headers, however, we do receive them through as the second item in the results array variable when calling MiddlewareTracing#call.
• Server-Timing is a header key with a string value. For example:

"Server-Timing"=> "sql.active_record;dur=13.86, start_processing.action_controller;dur=0.20, instantiation.active_record;dur=21.80, render_partial.action_view;dur=1.77, render_template.action_view;dur=37.60, render_layout.action_view;dur=130.13, process_action.action_controller;dur=174.32"

• 5 of the 7 recorded activities in Sever-Timing are already reported by the agent. We have plans to subscribe to an untracked one.
  • sql.active_record - active_record_notifications.rb#L101-L104
  • start_processing.action_controller - currently on deck to subscribe to #1510
  • instantiation.active_record - Not tracked by the agent.
  • render_partial.action_view - action_view.rb#L24-L27
  • render_template.action_view - action_view.rb#L24-L27
  • render_layout.action_view- action_view.rb#L24-L27
  • process_action.action_controller - action_controller.rb#L30-L31

Because we provide much of the same information as server-timing, I don't see much value in adding. Recording server-timing data would give customers this information as a part of a transaction attribute(s), which in the UI could be of value. It would be nice to know if this, or the ability to track custom/additional headers, is of interest to customers.

[kaylareopelle]

Closing this issue as "Won't do" since we already report on most of the information in the Server-Timing Middleware header.