-
Notifications
You must be signed in to change notification settings - Fork 323
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
OpenTelemetry bridge #1631
Merged
Merged
OpenTelemetry bridge #1631
Changes from 77 commits
Commits
Show all changes
117 commits
Select commit
Hold shift + click to select a range
27fab55
Fist working draft
felixbarny 517e037
Lazily parse tracestate
felixbarny 605c893
Use built-in Context
felixbarny 844f097
Translate OTel attributes to intake API
felixbarny 1a28319
Refine instrumentations
felixbarny 204bea7
Mark as experimental
felixbarny a7b65c9
Add enable_experimental_instrumentations option
felixbarny c89b977
polishing
felixbarny 87e8420
Extract advice to separate class
felixbarny 8f63bf1
more polishing
felixbarny 9b2e489
Map OTel semantic convention attributes to data model
felixbarny a7899d9
Mark spans non-discardable on context propagation
felixbarny 56594eb
Remove construction of URL fields that are filled on APM Server
felixbarny ca4e5a6
Add license headers
felixbarny 31c5b97
Revert "Remove construction of URL fields that are filled on APM Server"
felixbarny f04c94f
Map destination details of external spans
felixbarny 1d72e4a
Avoid calling method that's @since Java 9
felixbarny 316c65b
Fix packaging and shading
felixbarny 4bf7349
Add docs
felixbarny 083d297
Add changelog
felixbarny a9788b0
Merge remote-tracking branch 'origin/master' into opentelemetry-bridge
felixbarny 5465c38
Document when OTel bridge has been added
felixbarny 970e425
Update to OTel 0.15.0 and test older versions too
felixbarny 233179d
Implement review suggestions
felixbarny d9e5498
Merge remote-tracking branch 'origin/master' into opentelemetry-bridge
felixbarny a85d5f4
Bubble up operation modes to apis.asciidoc
felixbarny b4f69e6
Log warning once if unsupported APIs are used
felixbarny 430ca09
Be more clear about what is and what's not supported
felixbarny 39f086c
Update and require OTel 0.16.0
felixbarny 02cbb45
Remove smurf naming convention
felixbarny 66b4e22
Merge remote-tracking branch 'origin/master' into opentelemetry-bridge
felixbarny 4ff5c4f
Set outcome
felixbarny 7398cca
Merge remote-tracking branch 'origin/master' into opentelemetry-bridge
felixbarny d8f37df
Update to otel 1.0.0
felixbarny c03d09f
Merge remote-tracking branch 'upstream/master' into opentelemetry-bridge
SylvainJuge 21c8002
fix advice class names
SylvainJuge 6faddb1
fix url test
SylvainJuge bb1b599
Merge branch 'master' of github.com:elastic/apm-agent-java into opent…
SylvainJuge 27ebcfd
post-merge update
SylvainJuge 28dd7d5
add missing ivy test dependency
SylvainJuge d021714
test versions 1.0.x->1.5.0
SylvainJuge 81daba2
add few tests for coverage
SylvainJuge fe86a0a
fix doc release version
SylvainJuge fe0501c
update docs
SylvainJuge a296813
introduce ElasticContext to rule them all
SylvainJuge ac1d10f
bridge otel root context
SylvainJuge de91e3f
code cleanup
SylvainJuge 2db9716
code cleanup + update test to 1.6.0
SylvainJuge 8d88a51
Merge branch 'master' of github.com:elastic/apm-agent-java into opent…
SylvainJuge 717d51f
add missing license header
SylvainJuge 1b0804b
minor tweaks
SylvainJuge 11964eb
Merge branch 'master' of github.com:elastic/apm-agent-java into opent…
SylvainJuge b86d00e
fix doc update test fail msg
SylvainJuge 5c77c00
add span kind + wip on shared spec
SylvainJuge 214ae74
add wip gherkin spec
SylvainJuge 86e5b1c
add missing file headers
SylvainJuge f0629cc
wip http + db span mapping
SylvainJuge 73f29a3
finalize 1st tep of bridge
SylvainJuge 5bc47b2
minor cleanup
SylvainJuge a2d6da8
replace 'custom' with 'unknown' for bridge
SylvainJuge 9fd61a0
update json spec for span type/subtype
SylvainJuge 776fb2a
Merge remote-tracking branch 'origin/master' into opentelemetry-bridge
felixbarny 8b13a40
Use AssignReturned annotations
felixbarny 9a8a616
Merge remote-tracking branch 'origin/master' into opentelemetry-bridge
felixbarny bcbfef7
Fix parent project version
felixbarny c058bb2
wip main cucumber tasks
SylvainJuge 7c6549c
Merge branch 'master' into opentelemetry-bridge
SylvainJuge ab10fbe
infer on otel span end + basic outcome mapping
SylvainJuge e38ce0a
pom cleanup
SylvainJuge dde7cd6
code cleanup
SylvainJuge fccfd52
set outcome for otel spans
SylvainJuge 4c5341f
fix tests
SylvainJuge d08186b
do not infer outcome from lack of exception
SylvainJuge 5f4ce60
fix documentation
SylvainJuge 0ecddde
fix/cleanup documentation
SylvainJuge a7ab69a
Merge branch 'master' of github.com:elastic/apm-agent-java into opent…
SylvainJuge 8951c30
update changelog
SylvainJuge 544d965
Merge branch 'main' of github.com:elastic/apm-agent-java into opentel…
SylvainJuge 805b21d
fix sdk logger change
SylvainJuge 6ec3ac3
add latest versions for test coverage
SylvainJuge a318c61
update generated doc
SylvainJuge a10814d
compile agent sdk for java 7
SylvainJuge fc5c5e2
fix doc links
SylvainJuge 64b393b
Apply suggestions from code review (docs links)
SylvainJuge 1c94a7b
Merge branch 'main' of github.com:elastic/apm-agent-java into opentel…
SylvainJuge a71e8ad
aim for release in 1.30.0
SylvainJuge 8f50b8c
Merge branch 'opentelemetry-bridge' of github.com:felixbarny/apm-agen…
SylvainJuge 097ab8a
add missing otel attributes & kind serialization
SylvainJuge 1d874fb
Merge branch 'main' of github.com:elastic/apm-agent-java into opentel…
SylvainJuge 8099d37
prevent NPE when Context.root() is not called first
SylvainJuge a4fd963
move to a single module for opentelemetry
SylvainJuge 6bae41e
move to dedicated sub-module for opentelemetry
SylvainJuge 54d961f
capture OTel API version when possible
SylvainJuge 6b55f88
minimize changelog diff
SylvainJuge bf95b39
clarify some comments/doc
SylvainJuge 71b53fa
properly reformat
SylvainJuge 42751d9
minor fix to otel mvn dependencies
SylvainJuge 1f59e49
remove unused context propagator
SylvainJuge f91dcdf
bump version to 1.30.0
SylvainJuge eaf672a
Merge branch 'main' of github.com:elastic/apm-agent-java into opentel…
SylvainJuge 5506146
Merge branch 'main' of github.com:elastic/apm-agent-java into opentel…
SylvainJuge 26a7d60
prevent multiple root contexts
SylvainJuge f5cdebc
fix pebkc
SylvainJuge 984d375
set implicit active parent only at startSpan
SylvainJuge 4070339
fix docs (attempt for menu)
SylvainJuge e1a00e5
fix API docs menu integration
SylvainJuge 72bce1f
trim whitespace
SylvainJuge 404b0ce
Merge branch 'main' of github.com:elastic/apm-agent-java into opentel…
SylvainJuge 3493ee1
fix links to public-api
SylvainJuge 89ec40f
Merge branch 'main' of github.com:elastic/apm-agent-java into opentel…
SylvainJuge 6e63eef
Merge branch 'main' of github.com:elastic/apm-agent-java into opentel…
SylvainJuge e4b85c1
fix generated doc
SylvainJuge 72e5d24
doc: try removing float blocks
SylvainJuge eaaa292
fix API menu
SylvainJuge 1481a3a
Merge branch 'main' of github.com:elastic/apm-agent-java into opentel…
SylvainJuge 020ed20
fix new module version
SylvainJuge c887091
Merge branch 'main' into opentelemetry-bridge
SylvainJuge File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
68 changes: 68 additions & 0 deletions
68
apm-agent-core/src/main/java/co/elastic/apm/agent/impl/transaction/ElasticContext.java
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,68 @@ | ||
/* | ||
* Licensed to Elasticsearch B.V. under one or more contributor | ||
* license agreements. See the NOTICE file distributed with | ||
* this work for additional information regarding copyright | ||
* ownership. Elasticsearch B.V. licenses this file to you under | ||
* the Apache License, Version 2.0 (the "License"); you may | ||
* not use this file except in compliance with the License. | ||
* You may obtain a copy of the License at | ||
* | ||
* http://www.apache.org/licenses/LICENSE-2.0 | ||
* | ||
* Unless required by applicable law or agreed to in writing, | ||
* software distributed under the License is distributed on an | ||
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY | ||
* KIND, either express or implied. See the License for the | ||
* specific language governing permissions and limitations | ||
* under the License. | ||
*/ | ||
package co.elastic.apm.agent.impl.transaction; | ||
|
||
import co.elastic.apm.agent.impl.Scope; | ||
|
||
import javax.annotation.Nullable; | ||
|
||
public interface ElasticContext<T extends ElasticContext<T>> { | ||
|
||
/** | ||
* Makes the context active | ||
* | ||
* @return this | ||
*/ | ||
T activate(); | ||
|
||
/** | ||
* Deactivates context | ||
* | ||
* @return this | ||
*/ | ||
T deactivate(); | ||
|
||
/** | ||
* Activates context in a scope | ||
* | ||
* @return active scope that will deactivate context when closed | ||
*/ | ||
Scope activateInScope(); | ||
|
||
/** | ||
* Adds a span as active within context. Might return a different context instance if required, for example | ||
* when the context implementation is immutable and thus can't be modified. | ||
* | ||
* @param span span to add to the context | ||
* @return context with activated span | ||
*/ | ||
ElasticContext<T> withActiveSpan(AbstractSpan<?> span); | ||
|
||
/** | ||
* @return the span/transaction that is associated to this context, {@literal null} if there is none | ||
*/ | ||
@Nullable | ||
AbstractSpan<?> getSpan(); | ||
|
||
/** | ||
* @return transaction associated to this context, {@literal null} if there is none | ||
*/ | ||
@Nullable | ||
Transaction getTransaction(); | ||
} |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
How come this is here and not in
OTelSpan
? I assume it's because of serialization and trying to follow are the guidelines:AbstractSpan
, so we cannot extend or implement the internal types in the OTel pluginOTelSpan
wraps anAbastractSpan
, so it knows about it but not vice versaI would be happy if we can lose any OTel stuff in our internal code as much as possible.
With the attributes it's easy since it's only a
Map<String, Object>
so just renaming toattributes
would do. For theotelKind
it's also easy - since we only need itstoString
implementation, the field can be of typeObject
and renamedkind
andOTelSpanKind
can go into the plugin.However, this will not accommodate future additions (like OTel events?) and it doesn't lose the OTel-specific serialization from our general-purpose serializer.
Proposal
Maybe a more generic solution is to introduce another interface to the
co.elastic.apm.agent.impl.context
package:The plugin will implement it with attributes and kind and the
serialize
implementation would be the currentDslJsonSerializer#serializeOTel
implementation. It may eliminate the need to copy the attributes to an additional map.It will be another
AbstractSpan
field that will be serialized in the appropriate order.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 will try to look at an alternative for this, maybe close to what you suggested.
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'm skeptical that pulling out the attributes out of
AbstractSpan
is possible. Think about the case where someone uses the OTel API to add a custom attribute to a span or transaction that has been created by the auto-instrumentation of the agent.The
OTelSpan
is just an ephemeral bridge object where we should think twice before adding state to it.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.
That's right, we shouldn't add a state to
OTelSpan
, theAbstractSpan
would still own the bridge context. It's not where the data resides, only where the implementation resides. I prefer the bridge to maintain this part of the context, which is tightly coupled with the OTel API.This is what I propose (calling it
FreeFormContext
because the internal context already has room for custom context):We add another context type that has a very loose API:
Anything that implements it is also responsible for proper serialization of it. Not sure about recycling, but I think that as long as we don't allow multiple types of that within the same runtime, it can be set once and then only recycled. That is only relevant if we really find a proper way to recycle these spans of course.
Then we add another context property to spans:
The bridge will have a
OTelSpanContext implements FreeFormContext
and instead of doing:OTelSpan
would do something like:I hope this makes sense.
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 see what you mean here, but I'm not sure that we can generically handle the JSON serialization part in an elegant way.
We could even allow the plugin to create dedicated sub-classes of
Transaction
andSpan
for that purpose.For example, we have to assume that the serialized form will always be in the same place in JSON.
In this case, we have an extra
otel
attribute:span.otel
object withspan.otel.kind
andspan.otel.attributes
, but any other implementation could use a different structure.While I like the idea to keep the core of the agent as OTel-agnostic as possible, I don't think that we should handle this right now:
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.
Wouldn't a copy+paste of the current serialization work without any change?
JSON relies on nesting. You can assume that you are in the right place within the "parent" node serialization because it is the one invoking you and once you are invoked, you serialize the nested tree as you know it should be.
I see it exactly the opposite 😄
Even though it seems it is going this direction, we don't yet know whether using us with OTel is going to be the absolute norm. It seemed to go there with OpenTracing before. Currently we add fields to our core to support niche cases.
I don't think about other implementations, it's not about abstraction for the purpose of polymorphism, it's abstraction for the purpose of proper responsibility separation - the bridge should know about the core, the core should not know about the bridge.
That said, I am only explaining to emphasize my rationale, it's not something I will insist on so feel free to make the call and leave as is.