-
Notifications
You must be signed in to change notification settings - Fork 280
Description
Area(s)
No response
What's missing?
In existing conventions, server.address is used to record the actual communication server address. However, this falls short in dynamic middleware cluster scenarios (e.g., Kafka, Elasticsearch...):
Clients connect to clusters via a statically configured list of initial bootstrap nodes, while actual communication nodes change dynamically due to load balancing, failover, etc. Moreover, SDKs often do not expose real-time node addresses (or their acquisition is extremely costly). Asynchronous sending mechanisms further complicate obtaining real-time server.address. This makes it difficult to establish stable client-cluster associations in service maps.
For example, in java kafka instrumentation (related discussions in opentelemetry-java-instrumentation#10647 and opentelemetry-java-instrumentation#14032)
Describe the solution you'd like
Add a new attribute server.bootstrap.addresses, defined as a list of static bootstrap servers configured during client initialization (in host:port format). It's Recommended attribute.
- As a supplement to
server.address:server.addressrecords obtainable real-time communication nodes (for fine-grained observation), whileserver.bootstrap.addressesprovides a stable root association between the client and the cluster, ensuring the integrity of service maps. - Example value:
["broker1:9092", "broker2:9092"] - Feasibility: While real-time node addresses can be obtained in some cases, implementation is complex in many scenarios. Static bootstrap nodes are basic client configuration information, easy to acquire, and effectively solve the problem of service map construction in dynamic clusters.
Tip
React with π to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.