Andrew H Schwartz

@TonyCTHsu thanks for the look! To address in your specific comment > I believe it is behaving as expected, sinceactive_record.instantiation span is considered to belong to the application service, which...

Also, for completeness, we initially attempted to see if using the service_name configuration on the [active_record](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries/ruby/#active-record), as opposed to rails, instrumentation option would be respected: ```rb c.tracing.instrument :active_record, service_name: "foo"...

> would it be desirable that active_record.instantiation span's service name matches your global c.service? That would be fine; but stated perhaps at a higher level / user story: I would...

> @ozydingo In your last comment, can you clarify where "threeplay" is configured? I am not seeing it in the configuration you specified. > > It's set using the DD_SEEVICE...

@p-datadog > @ozydingo @dannyrife Could you also clarify why you wish to provide service name to `rails` instrumentation instead of specifying it globally, Actually I think in our case that...

This implementation is a bit overly aggressive. As @jwkoelewijn points out, it breaks any code we might type or copy-paste that uses a `jobs` instance variable: ``` worker (local) >...

Thanks @adam12. I've updated `mis/README.md.erb` and run `rake` as well as checked the erb template generation manually to regenerate to make sure I haven't missed anything.