Clarify that *.system captures the client perception

[lmolkova]

Fixes #813

Changes

Clarifies that db|messaing|gen_ai.system captures the product name from the client's perspective which may not match the actual product used on the server side.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

[gregkalapos]

Definitely a useful addition to the spec. Given these fields are experimental I think it's fine to merge as is.

Only thing I was thinking about is if there are maybe some higher level frameworks already instrumented that have a smarter logic to detect the *.system. If so, then for them this may be a breaking change.

I looked into the EF Core instrumentation that has some logic around populating db.system, but that ultimately ends up using ProviderName, which based on the doc would be aligned with this PR:

The name is typically the name of the provider assembly.

So that's ok.

Maybe someone knows about other similar cases - those would be nice to check.

[lmolkova]

@gregkalapos

thanks for checking EF!
what do you think could be breaking? There is no semantical change for the attribute, just the clarification that it's what client thinks the DB system is. Let me know if there is something I can do to clarify it further.

[gregkalapos]

@gregkalapos

thanks for checking EF! what do you think could be breaking? There is no semantical change for the attribute, just the clarification that it's what client thinks the DB system is. Let me know if there is something I can do to clarify it further.

I was thinking that SemConv stability lists the following as a breaking change:

The attribute values provided for the event that are defined in a list of well-known values.

Although db.system has allow_custom_values: true, so I'm not sure this applies - but I was thinking more from a real user's experience.

So if there is some higher level instrumentation that e.g. connects to MongoDb, but has some smart logic to set db.system to MongoDB, ConsomsDB, etc. based on what it connects to and let's assume it's a ConsosDB library, then for that instrumentation could be breaking - because prior to this PR it was ok to set db.system based on what it really connects to and now it must be CosmosDb. But this is completely hypothetical and the field is experimental. Just raising this so maybe someone has a real example. But very unlikely.

[lmolkova]

@gregkalapos ah, I see what you mean. There is no intent to force instrumentations to use something - if they know the actual system they should use it. The intent is to explain that in some cases they don't.

I updated the PR to make it more clear. PTAL

[pyohannes]

This looks good to me, just some minor wording nits.