Skip to content
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

Allow specifying a readable service name for databases when the JDBC url has IP Address #6514

Open
sriraamas opened this issue Jan 18, 2024 · 10 comments
Labels
inst: jdbc JDBC instrumentation

Comments

@sriraamas
Copy link

In our application, we use IP address in the JDBC url to connect to our database, like:

jdbc://10.4.2.1:3306/test_database

This means that the service name is 10.4.2.1 when I leverage trace.db.client.split-by-host configuration.

However, we would like to specify the service name for this database as a connection parameter to jdbc like:

jdbc://10.4.2.1:3306/test_database?serviceName=user-writer-instance.db.com

Currently, the serverName parameter is lost during runtime because its overridden by the actual host of the jdbc url, which is 10.4.2.1

@nayeem-kamal
Copy link
Contributor

Hi @sriraamas. I believe you should be able to achieve this by utilizing service mapping (dd.service.mapping) to explicitly set the names for your services.
https://docs.datadoghq.com/tracing/trace_collection/library_config/java/#configuration-options

@sriraamas
Copy link
Author

sriraamas commented Jan 18, 2024 via email

@bm1549
Copy link
Contributor

bm1549 commented Jan 18, 2024

Hi @sriraamas, could you try using dd.service.mapping to map the IP address in addition to using trace.db.client.split-by-host? The resulting properties would be

-Ddd.trace.db.client.split-by-host=TRUE -Ddd.service.mapping=10.4.2.1:user-writer-instance.db.com

@sriraamas
Copy link
Author

fwiw, I verified that this works. The workaround recommended works but it is a lot of additional work.

@tmccombs
Copy link

It is also somewhat problematic because the ip to name mapping must be know at startup time.

The reason we use ip addresses instead of a domain name is so that we can quickly detect if the DNS changed, and properly drain existing connections. But that means we don't necessarily know the mapping initially.

(I work with sriraamas)

@bm1549
Copy link
Contributor

bm1549 commented Jan 19, 2024

@sriraamas @tmccombs another option to try which can vary based on your setup is to use the option dd.trace.db.client.split-by-instance

This will change the service name being used to be the instance, which can vary based on the connection string you're using. You may be able to use that in conjunction with dd.service.mapping to get the desired behavior

@sriraamas
Copy link
Author

In our case, by default, db-instance is set to the database being used. so are you saying, if its user database in the user-db host, do service.mapping from user to user.db.com ? The downside there is, we have both reader and writer hosts being used on the same database instance. so, I can't know if its reader/writer.

@bm1549
Copy link
Contributor

bm1549 commented Jan 22, 2024

Thanks for sharing that

Given the information you provided, it indicates that dd.trace.split-by-tags may be beneficial for you. You can use it to identify and rename the service name for reader and writer spans. Can you try that out and let me know if it solves your problem?

@sriraamas
Copy link
Author

sriraamas commented Jan 22, 2024 via email

@bm1549
Copy link
Contributor

bm1549 commented Jan 25, 2024

Hi @sriraamas thank you for your patience. I'm reaching out to confirm that, without custom instrumentation, you are correct

In this case, we'll attach this issue to a feature request internally and consider it as part of our long-term roadmap. Please use the options specified above until then

@bm1549 bm1549 added the inst: jdbc JDBC instrumentation label Feb 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
inst: jdbc JDBC instrumentation
Projects
None yet
Development

No branches or pull requests

4 participants