resource auto-inference is not working for JDBC spans

[tobiasstadler]

Describe the bug

According to elastic/apm#465 context.destination.service.resource should be ${subtype}/${instance} (or ${type}/${instance} if subtype is null) for a JDBC Span, e.g. for a postgresql db named test: postgresql/test. However, context.destination.service.resource is only ${subtype} (or ${type}), resp. postgresql in the example above.

The algorithm in co.elastic.apm.agent.impl.transaction.Span#beforeEnd is not working because:

• JDBC spans are created as normal spans, not exit spans (see co.elastic.apm.agent.jdbc.helper.JdbcHelper#createJdbcSpan)
• JDBC spans usually set context.destination.service.resource to ConnectionMetaData.getDbVendor() (see co.elastic.apm.agent.jdbc.helper.JdbcHelper#createJdbcSpan)

Expected behavior

For a Postgres db named test context.destination.service.resource should be postgresql/test

[eyalkoren]

elastic/apm#465 is instructing how to auto-infer context.destination.service.resource if it is not set.
The relevant spec says that the service.resource field should contain the name of the vendor in the case of supported SQL DBs, so this is not a bug.

But I agree that this is a valid point - either we prefer this higher cardinality (i.e. including the instance), or we don't. Whatever we decide, it should probably be the same.
@felixbarny is there a reason we use different approach/cardinality for instrumented DBs vs. automatically inferred?

[felixbarny]

@felixbarny is there a reason we use different approach/cardinality for instrumented DBs vs. automatically inferred?

I don't think so. It feels like an oversight. But We'll have to coordinate with other agents. Although borderline, I think we can declare adding the instance as a non-breaking change.