otel.instrumentation.common.peer-service-mapping: support glob

[codefromthecrypt]

Is your feature request related to a problem? Please describe.

Right now, there's a handy feature to map peer service names, given hostname or hostname:port. This is important for topology view. https://opentelemetry.io/docs/zero-code/java/agent/instrumentation/#peer-service-name

One issue is that you may want to bucket a service like "openai-azure", but be stifled by its use of subdomains. It isn't viable in some cases to enumerate all possible hostnames as they could be parametrized in a way that changes independent from the agent config.

E.g. x.openai.azure.com, y.openai.azure.com

This concern is not limited to azure openai as it applies to anything using subdomains, like s3.

Describe the solution you'd like

I think the simplest way out would be to accept asterisk as a wildcard. so, *.openai.azure.com=openai-azure or similar. This could be very efficient especially if only one wildcard was permitted, or a substring variant.

Describe alternatives you've considered

Today, if you know the names, you can just list them all.

Also, you could instead map other things instead of hostname, like db.system recently renamed to db.system.name. However, as this is already a drifted config pattern (due to appending ".name"), it might be confusing to document. So, it seems low-hanging fruit to just accept a wildcard.

Also, I think while we could do regex, it is overkill for the pattern described vs a glob or substring.

Additional context

thought about this, testing otel-tui https://github.com/ymtdzzz/otel-tui/issues/200

[trask]

makes sense to me, agree on simplified matching, we should align with https://github.com/open-telemetry/opentelemetry-configuration/blob/main/README.md#properties-which-pattern-matching

[xiepuhuan]

Please assign to me. @trask

[xiepuhuan]

@trask I have two questions.

1. Does the host, port and path all need to support glob?
2. For example, If the old version uses the configuration otel.instrumentation.common.peer.service mapping=example.com?=exampleService. In versions that do not support glob, the host is considered to match exactly example.com In versions that support glob, think host glob matches example.com? If it is the latter, it is inconsistent with the expected matching result of the old version. Do I need to add configuration options to explicitly enable glob?

[trask]

Sorry for the late reply.

1. Seems ok to limit glob support to host initially at least.
2. I don't think you need an option to explicitly enable glob support.