-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
server.address
for Cassandra client instrumentation when there are multiple contact points?
#679
Comments
It should still be important to capture Also, there are fully managed Cassandra offerings (such as AstraDB which takes care of load balancing/fallback and allows to configure one endpoint) which would benefit from So I think something like
(maybe when it's available and different from an IP?) makes the most sense.
this also makes sense, but does it make sense to capture it on every span? I'd log it once when client starts at Info |
(related, I'm thankful for #486) |
@trask do we still need anything in this issue to be done in semconv? Or can we close this? |
It's not clear to me if Cassandra client instrumentation should populate
server.address
or not, since there can be multiple contact points.We can look at the execution info after the call completes and get the contact point that was used, but that means
server.address
wouldn't be available for sampling.Looking for feedback on these options:
server.address
, but won't be available for samplingThe text was updated successfully, but these errors were encountered: