Replaces #6362.
I've reduced the attributes to only record the gc name and the action
that was taken (i.e. I've removed the gc cause). If needed we can add
the cause later, but for now this should be sufficient to determine
total time spent in GC, and categorize time spent as stop the world or
parallel.
This resolves#6694.
We've been tracking the update to cgroup version support and want to get
ahead of the widespread usage. The surface of the existing
`ContainerResource` has not changed, but its internals have been
factored out to two "extractor" utilities -- one that understands cgroup
v1 and another for v2. v1 is attempted and, if successful, the result is
used. If v1 fails, then the `ContainerResource` will fall back to v2.
As mentioned in #6694, the approach taken in this PR is borrowed from
[this SO
post](https://stackoverflow.com/questions/68816329/how-to-get-docker-container-id-from-within-the-container-with-cgroup-v2)
combined with local experimentation on docker desktop on a Mac, which
already uses cgroup2 v2.
Should help with maven central sporadic failure:
```
Could not determine the dependencies of task ':instrumentation:hibernate:hibernate-3.3:javaagent:test'.
> Could not resolve all task dependencies for configuration ':instrumentation:hibernate:hibernate-3.3:javaagent:testRuntimeClasspath'.
> Could not resolve javassist:javassist:+.
```
This PR adds support for OpenSearch 1.x and 2.x Java clients
auto-instrumentation.
This is made possible by OpenTelemetry specification v1.14.0 and
OpenTelemetry Java SDK v1.19.0.
Testing is being done using
org.opensearch:opensearch-testcontainers:2.0.0
(https://github.com/opensearch-project/opensearch-testcontainers)
Resolves#7007
Signed-off-by: Cédric Pelvet <cedric.pelvet@gmail.com>
Signed-off-by: Cédric Pelvet <cedric.pelvet@gmail.com>
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
~I'll create a tracking issue to remove these and support new versions.~
Tracking issue added to support latest project reactor 3.5.0 and revert
these limits: #7107
to improve the situation when logging/debugging
`Span.current().getSpanContext()`, currently:
> ImmutableSpanContext{traceId=115a2de6dffb17eaafd13a66d7aec660,
spanId=56af5c30e85bfb08,
traceFlags=**io.opentelemetry.javaagent.instrumentation.opentelemetryapi.trace.BridgedTraceFlags@20ea6fa6**,
traceState=ArrayBasedTraceState{entries=[]}, remote=false, valid=true}
In the 10/27 java sig we discussed that it would be valuable to
enumerate the attributes reported for memory pool and gc metrics when
different gcs are used.
I've went ahead and added a readme for the runtime metrics which
includes detailed information on the attributes reported. Note that I
also have the same data for gc metrics added in #6964 and #6963, but
will wait to add until those PRs are merged.
I suspect that this was added in the original RocketMQ instrumentation
because it existed in the Kafka instrumentation, and not because there
was a need for it(?)
See #6957 for documentation on why it is needed in Kafka
Runtime metrics doesn't include the meter version. This adds it from the
utility method in the instrumentation-api
`EmbeddedInstrumentationProperties.findVersion`. I know I can read the
properties file for this module, but its repetitive to implement that in
many places.
This may be a regression in 1.19.0 because you can no longer reconstruct
the original url for netty server spans (previously `http.host` was
captured which could be used).
While I was looking at issues
open-telemetry/opentelemetry-java-instrumentation#6694 and
open-telemetry/opentelemetry-java#2337, I saw that the code in
`io.opentelemetry.instrumentation.resources.ContainerResource` used
`null` several times as return value which isn't safe. Nowadays,
`Optional` is better suited to signal the absence of a result, so I
refactored `ContainerResource` to use `Optional`s instead of null.
On the way, I also refactored this class's unit tests into parameterised
tests to reduce test code duplication. These improvements should help
implementing a solution to
open-telemetry/opentelemetry-java-instrumentation#6694.
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
Calling `Mono#timeout()` with a timeout value smaller than the HTTP
client timeout caused the on request/response end callbacks to be simply
discarded; and the HTTP span was never finished.
Trask Stalnaker
