Another part of #932
In this PR I changed all the library instrumentation packages -- these
are breaking changes, so I figured the earlier we do this the less
painful it'll be to the users. I know that at least some of them are
actively used, so we'll need to spell this out in the release notes.
---------
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
Hi,
I copied existing JSF 1.2-2 instrumentation, updated dependencies and
namespaces related to JSF 3+.
I don't work with Mojjara implementation, but copied by analogy and
verified that package names are unchanged.
I named new packages by anology with `servlet` packages, but I use
`jsf-jakarta-common` when in servlet we have `servlet-javax-common`.
My idea was to avoid touching existing packages, but perhaps to keep
consistency, I can rename old `jsf-common` to `jsf-javax-common`.
Tested with Tomcat and my app, it's working fine with JSF 4 :)
Basically, `akka-http` instrumenter has the responsibility to instrument
the `http.server.duration` for the Play framework application, but the
current implementation has not marked the `http.route` attribute.
ref:
8e8161cb2e/instrumentation/akka/akka-http-10.0/javaagent/src/main/java/io/opentelemetry/javaagent/instrumentation/akkahttp/server/AkkaHttpServerAttributesGetter.java (L59)
Actually, it's hard to record that attribute by only the akka-http layer
because that library's request object doesn't hold the route
information, e.g. placeholder.
So this patch delegates that job to the `play-mvc` instrumenter and when
that has been able to get the route info, the instrumenter puts
`http.route` attribute onto `http.server.duration`.
For example, when the routes configuration of the Play is like the
following:
```
GET /foo/:bar controllers.HomeController.doSomething(bar: String)
```
and when it tries to access that API, then OTEL instruments like so:
```prometheus
http_server_duration_count{otel_scope_name="io.opentelemetry.akka-http-10.0",otel_scope_version="1.23.0-alpha-SNAPSHOT",http_flavor="1.1",http_method="GET",http_route="/foo/$bar<[^/]+>",http_scheme="http",http_status_code="200",net_host_name="localhost",net_host_port="9000"} 1.0 1676078079798
http_server_duration_sum{otel_scope_name="io.opentelemetry.akka-http-10.0",otel_scope_version="1.23.0-alpha-SNAPSHOT",http_flavor="1.1",http_method="GET",http_route="/foo/$bar<[^/]+>",http_scheme="http",http_status_code="200",net_host_name="localhost",net_host_port="9000"} 12183.558843 1676078079798
http_server_duration_bucket{otel_scope_name="io.opentelemetry.akka-http-10.0",otel_scope_version="1.23.0-alpha-SNAPSHOT",http_flavor="1.1",http_method="GET",http_route="/foo/$bar<[^/]+>",http_scheme="http",http_status_code="200",net_host_name="localhost",net_host_port="9000",le="0.0"} 0.0 1676078079798
...
http_server_duration_bucket{otel_scope_name="io.opentelemetry.akka-http-10.0",otel_scope_version="1.23.0-alpha-SNAPSHOT",http_flavor="1.1",http_method="GET",http_route="/foo/$bar<[^/]+>",http_scheme="http",http_status_code="200",net_host_name="localhost",net_host_port="9000",le="+Inf"} 1.0 1676078079798
```
Rel: #1415
---------
Signed-off-by: moznion <moznion@mail.moznion.net>
We are seeing examples where Spring Scheduling INTERNAL spans are
created inside of an existing parent span, which creates unnecessary
noise.
And these spans don't necessary make sense as these are not "background
jobs" (since they occur inside of an existing span).
(see for example
https://github.com/microsoft/ApplicationInsights-Java/issues/2870)
This PR changes Spring Scheduling instrumentation to only instrumenting
repeating jobs, not one-time scheduled jobs (which corresponds to
ScheduledExecutorService behavior where context is not propagated to
runnable)
---------
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
Hopefully resolves
https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/7597
Without reproducing the issue it is hard to tell whether this will help.
Another issue that could arise is that we add our metrics class in
`metric.reporters` property which will probably break if this
configuration is used to build consumer or producer after deserializing
as our classes don't seem to be available there. If this fails we'll
need to ask the issue reporter for instructions how to reproduce and
find a different strategy for fixing this.
Fix#7729
This PR adopts Azure SDK tracing API changes from the latest release
(azure-core 1.36.0, azure-core-tracing-opentelemetry 1.0.0-beta.32)
The API changes are not breaking (1.19 instrumentation is still
compatible), but the new instrumentation is slightly more performant and
supports new features. We are also going to break compatibility with
1.19 instrumentation at some point (in 6-12 months).
We now have 3 versions for azure-sdk. We still have about 10% of users
on versions [1.14-1.19), but it's declining and I'll be happy to remove
1.14 in the next few months if this trend continues.
---------
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
Resolves
https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/7597
I wasn't able to reproduce this. Figuring out how to run beam, flink and
kafka together feels like too much effort. Without reproducing it is too
hard to tell why the configuration is serialized, but my hunch is that
it is enough to ensure that the configuration can be serialized.
the `getMdcCopy` test is omitted as it is only available in
jboss-logmanager 1.3+ and the test depends on jboss-logmanager 1.1
---------
Co-authored-by: opentelemetrybot <107717825+opentelemetrybot@users.noreply.github.com>
…n-api-semconv
We're already doing that for `SpanNameExtractor`, `OperationMetrics`,
`ContextCustomizer`, etc., so I figured we should do the same for
`AttributesExtractor` implementation. Also, none of the implementations
have any additional public surface - aside from the builder/factory
method users can just simply use the interface everywhere.
While using Ratpack Handlers, the context is added by the
`OpenTelemetryServerHandler`
While using Ratpack Services, we might need to add manually the OT
Context into the Ratpack Execution and try to get it from the Execution
in the Ratpack `HttpClient`
This is another follow-up from #7616. This makes the test options class
immutable and uses `@AutoValue` and `@AutoValue.Builder`. As a result, a
bunch of the configuration/setup code for these said options now flings
around a builder instance. This isn't great, but I think it's an
incremental improvement that can be seen in the `@BeforeAll
AbstractHttpClientTest.setupOptions()` method, where the immutable
options are (finally) instantiated.
Mateusz Rzeszutek