Allow option to disable resource.name 404 rewriting

[datadog]

Allow option to disable resource.name 404 rewriting

[rymndhng]

The cirumstance where the 404s are not useful to be grouped together is because applications may implement generic routes with a different permission scheme. i.e. if I am seeing a huge number of 404s on the url pattern /foo/:id/bar/:id, I want to see the spans with 404s grouped under the same resource name /foo/:id/bar/:id instead of a catch-all 404.

[realark]

@rymndhng Is this instrumentation for a server? If so how would you know which resource to associate the 404 with?

For example, if you had two endpoints /my/service and /other/service, where would you expect a request /a/bad/request to appear?

[rymndhng]

@realark I think I see where you're coming from. In the case where there is no tag resource.name set, it would be valuable to set resource.name to 404.

The current implementation always sets the resource.name to 404 when the response status is 404. I think it would be more reasonable to set the resource.name if it is not already set. This would users to distinguish between 404s from mismatched routes v.s. 404s returned by your application.

[tylerbenson]

@rymndhng can you explain the circumstance where the 404 being returned by the application is useful to not group together?

[randomanderson]

Resolved with #1152