@trask @mateuszrzeszutek hello, what do you think about
SingleThreadedSpringWebfluxTest, the test contains dependencies on new
reactor netty classes in testLatestDeps case. I tried use reflection for
rewriting the test to java but it was not trivial and I not reach the
result
---------
Co-authored-by: Lauri Tulmin <ltulmin@splunk.com>
Currently we run spotless and other checks for each of the parallel test
steps which seems wasteful. Here is an attempt to run only the tests in
given partition without any extra checks in the `test` step and run all
the checks in the `build` step.
Resolves#7437.
A few caveats about this. The TL;DR on #7437 is that a non-containerized
process was reporting a `container.id` attribute. The submitter narrowed
it down and I was able to confirm with the test case in this PR.
I hunted for other means for code to determine if it's containerized
with the idea to not even do the parsing if not containerized, but I
couldn't find anything useful. In fact, most approaches of detecting
containerization at all do involve parsing cgroups. Wacky.
So I attempted to verify that container IDs should always be 64
characters. I found:
* podman - docs
[here](https://docs.podman.io/en/latest/markdown/podman-container-inspect.1.html)
"Container ID (full 64-char hash)"
* docker - UID generator source
[here](634a848b8e/pkg/stringid/stringid.go (L36))
shows 32 bytes (and even guards against fully numeric!)
* lxc [man page
](https://linuxcontainers.org/lxc/manpages/man1/lxc-info.1.html)says
"container identifier format is an alphanumeric string". If this maps
into cgroups (no idea!), it would have already been broken in some cases
because we enforce hex.
I'm a little concerned about this approach because the [otel
spec](94c9c75c4f/specification/resource/semantic_conventions/container.md)
suggests that "The UUID might be abbreviated.", but it's
unclear/non-specific about the circumstances that might cause this.
Open to hearing about why the approach presented here is a bad idea. 🙃
Related discussion #7257Resolves#3413Resolves#5059Resolves#6258Resolves#7179
Adds a logging implementation that'll collect agent logs in memory until
slf4j is detected in the instrumented application; and when that happens
will dump all the logs into the application slf4j and log directly to
the application logger from that time on.
It's still in a POC state, unfortunately: while it works fine with an
app that uses & initializes slf4j directly, Spring Boot applications
actually reconfigure the logging implementation (e.g. logback) a while
after slf4j is loaded; which causes all the startup agent logs (debug
included) to be dumped with the default logback pattern.
Future work:
* ~~Make sure all logs produces by the agent are sent to loggers named
`io.opentelemetry...`
(https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/7446)~~
DONE
* Make this work on Spring Boot
* Documentation
* Smoke test?
the current implementation of Start and End around the invocation of a
Jax WS is asymmetric around the JAX-WS Handler Chain.
Current behavior:
(execution of incoming MessageHandlers) -> (TracingStartInInterceptor)
-> (WebService Invocation) -> (execution of outgoing MessageHandlers) ->
(TracingEndInInterceptor)
if I understood the code of this cxf instrumentation correctly, the
intent was to build the span close around the WebService Invocation
(without Handler Chains).
So the desired behavior would look like this:
(execution of incoming MessageHandlers) -> (TracingStartInInterceptor)
-> (WebService Invocation) -> (TracingEndInInterceptor) -> (execution of
outgoing MessageHandlers)
Unfortunately CXF is calling the Outgoing Chain inside the POST_INVOKE
Phase of Cxf (so the outgoing chain is technically a sub-chain in the
incoming chain... which is documented but quite surprising...).
So the solution in the fix at least guarantees the the outgoing chain is
invoked AFTER end of tracing. For any extra Interceptors in the
POST_INVOKE Phase there is still no guarantee of ordering, but I think
this is not a opentelemetry issue but a design-flaw of CXF...
---------
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
Co-authored-by: Lauri Tulmin <ltulmin@splunk.com>
this is a follow-up to #7043
I tried to add a test when that PR was opened:
*
d2c6399a6e
but it doesn't really verify anything, since the NPE is throw/caught and
same behavior occurs
This PR allows:
* Executing the OTel Logback appender tests as GraalVM native
executables
* Executing the native tests once a day on Github
---------
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
Add `HttpServerResponseCustomizer` support for Servlet 2.2/3.0/5.0 and
Jetty 8/11 instrumentations. Enabled testing for it in JaxRs tests as
well since those should now all be covered due to servlet
instrumentations. Fixed Jetty 11 test source set directory name.
Known limitation - response headers do not work on Jetty 8 for internal
exception pages caused by throwing an exception that is handled outside
of instrumentation scope, working around this would require an
additional instrumentation and/or keeping an expired `Context` instance
referenced by the response object. This does not appear to be an issue
on Jetty 11. Additionally, calling `ServletResponse#reset` can wipe
headers as well, for which there is no workaround (yet?) in this PR.
Add `HttpServerResponseCustomizer` support for Netty 3.8, 4.0 and 4.1
instrumentations and enable testing for it in their respective
`HttpServerTest` tests.
Andrei Chugunov
Lauri Tulmin
jason plumb
Mateusz Rzeszutek
Nitesh S
Trask Stalnaker
pellmont
adamleantech
Abhinandan Seshadri
Jean Bisutti
Robert Toyonaga
Abhinandan Seshadri
Phil
Ago Allikmaa
Shelby Huang
