-
Notifications
You must be signed in to change notification settings - Fork 324
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
Use the resource auto-inference to set context.destination.service.resource for JDBC spans (#1913) #1914
Conversation
❕ Build Aborted
Expand to view the summary
Build stats
Trends 🧪Steps errorsExpand to view the steps failures
|
This change means that existing service maps will change when you upgrade your agent and you will get multiple behaviors when using mixed agent versions. So such a change should be done very consciously. While this is definitely an option we are considering, in order to increase granularity of DB service representation, we will not change that in the Java agent before we make the decision and change it in the cross-agents spec. For context, the reason we don't take this lightly is the risk of getting very high cardinality, which means useless service maps and list of dependencies. The flip side, of too-low cardinality is much a lesser risk, which is why it is the way it is at the moment. |
@eyalkoren Would you be ok with putting the change behind a configuration option? Of course the current behavior will be the default. |
What would be the use case of disabling it? Do you have a specific example of something that will change/break by applying it? The purpose of auto-inference is that all exit spans fill this field. |
I do not want to disable auto-inference. I was talking about the value of |
Ahh, gotcha, sorry for the misunderstanding. Do your JDBC spans contain the correct value in the This generally sounds like a reasonable request, but, as I said - we are in the process of reevaluating whether to change that by default, so I rather we wait a bit with that. In the mean time, can you apply an ingest pipeline to achieve that? |
Yes, in my case (PostgreSQL) I tried using an ingest pipeline and it works fine for spans, but it doesn't work for the service_destination metricset, because there is no |
Sorry, I don't follow - the agent sets the |
No, it is stored for spans and the ingest pipeline works fine for spans. But the metrics, calculated for the transactions/spans by the apm-server (or kibana?), do not have a Here is an example before the ingest pipeline: Span
Metric
|
Yeah, that's right, I was only thinking about getting the nodes in the map, but the DB service metrics won't work. Since this is not specific to the Java agent, would you mind opening an issue in the https://github.com/elastic/apm repo, describing what you need? I can't find an existing one for this. It would be great to get your input on why you think the instance should be used for DB service node distinction.
I think this is a very important issue and I prefer we tackle it properly, not as a patch. Thanks for the useful input! |
FYI, I created #1928 to enable resource auto-inference via a config option. I think this is a step in the right direction. It enables me (and possibly others) to include In my opinion populating |
FYI, I created elastic/apm#473 |
What does this PR do?
Fixes #1913
Checklist