-
Notifications
You must be signed in to change notification settings - Fork 324
Added support for setting service name and version for a transaction via the public api #2451
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
Added support for setting service name and version for a transaction via the public api #2451
Conversation
…via the public api
👋 @tobiasstadler Thanks a lot for your contribution! It may take some time before we review a PR, so even if you don’t see activity for some time, it does not mean that we have forgotten about it. Every once in a while we go through a process of prioritization, after which we are focussing on the tasks that were planned for the upcoming milestone. The prioritization status is typically reflected through the PR labels. It could be pending triage, a candidate for a future milestone, or have a target milestone set to it. |
I will add unit tests once you decide this is the way to go (Manuel testing looks good). |
@felixbarny @eyalkoren Are you both comfortable with this approach? |
I added tests in 9be1a8a |
I just saw you are already prepared the changeling for 1.29.0. So I guess this wont't make it into the release? |
Ok, hopefully 1.29.1 or 1.30.0 then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR @tobiasstadler !
The API types are only known within the API itself and not elsewhere within the agent, including the API plugin. Let's keep it this way. We don't want version assumptions that may make the agent backwards incompatible. Even though it is protected within your implementation by the fact that the getServiceInfoForClassLoader
and setServiceInfoForClassLoader
methods won't be matched, allowing this dependency may bite us in the future.
There are ways to do that within the API (like we do with multiple APIs through usage of internal methods that use Object
in their signature), but I think the simplest would be to lose the ServiceInfo
type.
One option is to get the service name and version through two APIs. It is not as neat, but it avoids the object allocation and it would be required within the internal API anyway if we want to keep the complete separation between API types and agent types.
Another option is to get rid of getServiceInfoForClassLoader
altogether.
The fact that you added setServiceInfoForClassLoader
is enough if the co.elastic.apm.api.Transaction
interface has a useServiceInfoOf(ClassLoader)
(instead of what you did in #2444) . You can reference from the javadoc of each method
to the other to give users hints how they can be used. A co.elastic.apm.api.Transaction#setServiceInfo(String serviceName, String serviceVersion)
is still useful as well.
apm-agent-api/src/main/java/co/elastic/apm/api/ServiceInfo.java
Outdated
Show resolved
Hide resolved
apm-agent-api/src/main/java/co/elastic/apm/api/Transaction.java
Outdated
Show resolved
Hide resolved
apm-agent-core/src/main/java/co/elastic/apm/agent/bci/ElasticApmAgent.java
Outdated
Show resolved
Hide resolved
apm-agent-core/src/main/java/co/elastic/apm/agent/bci/ElasticApmAgent.java
Outdated
Show resolved
Hide resolved
.../apm-api-plugin/src/main/java/co/elastic/apm/agent/pluginapi/TransactionInstrumentation.java
Outdated
Show resolved
Hide resolved
public static class AdviceClass { | ||
@Advice.OnMethodExit(suppress = Throwable.class, inline = false) | ||
public static void setServiceInfoForClassLoader(@Advice.Argument(0) @Nullable ClassLoader classLoader, @Advice.Argument(1) String serviceName, @Advice.Argument(2) @Nullable String serviceVersion) { | ||
tracer.setServiceInfoForClassLoader(classLoader, ServiceInfo.of(serviceName, serviceVersion)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should check for serviceName
being null
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A null
service name will have no effect here - it won't be mapped and not even cause allocation of a ServiceInfo
object.
However, I wonder if we should allow null
service version going forward, now that #1726 is merged.
I think providing a service name without a version should be considered a bug, because it means we will use the global service version for a manually set service name, and there's no real reason why those would be related.
@felixbarny WDYT? Should we only allow overriding these two values together?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think its is fine to set a service name without a version. The global service version won't be used in such a case. But there service version won't be serialized and the apm-server also won't use the global service version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean - currently APM Server ignores the global version when we use a service name in transaction/metric context?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, my bad. This logic is only implemented for metrics. I created elastic/apm-server#7281 to fix this for transactions also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks!
Once we set our minds about how we handle null
values, please update the tests accordingly to verify that.
public static class AdviceClass { | ||
@Advice.OnMethodExit(suppress = Throwable.class, inline = false) | ||
public static void setServiceInfoForClassLoader(@Advice.Argument(0) @Nullable ClassLoader classLoader, @Advice.Argument(1) String serviceName, @Advice.Argument(2) @Nullable String serviceVersion) { | ||
tracer.setServiceInfoForClassLoader(classLoader, ServiceInfo.of(serviceName, serviceVersion)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A null
service name will have no effect here - it won't be mapped and not even cause allocation of a ServiceInfo
object.
However, I wonder if we should allow null
service version going forward, now that #1726 is merged.
I think providing a service name without a version should be considered a bug, because it means we will use the global service version for a manually set service name, and there's no real reason why those would be related.
@felixbarny WDYT? Should we only allow overriding these two values together?
.../apm-api-plugin/src/main/java/co/elastic/apm/agent/pluginapi/TransactionInstrumentation.java
Outdated
Show resolved
Hide resolved
Co-authored-by: eyalkoren <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for following up @tobiasstadler !
Please just add tests that reflect our decision on using null
values (I am approving anyway).
/test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One optional suggestion to bring in some of the improvements from #2444. Otherwise, LGTM.
.../apm-api-plugin/src/main/java/co/elastic/apm/agent/pluginapi/TransactionInstrumentation.java
Outdated
Show resolved
Hide resolved
/run elasticsearch-ci/docs |
Thank You! |
Thank you for your great collaboration ❤️ |
What does this PR do?
Adds support for setting service name and version for a transaction via the public api
Checklist