- use standard messaging span name
- replace `message.type` with experimental attribute
`messaging.pulsar.message.type`, `message.type` is from rpc semantic
conventions
- replace `net.sock.peer.addr` that was filled with broker url with
`net.peer.name` and `net.peer.port`
It follows the
[issue](https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/6395#issue-1323561263)
I opened some days ago.
The `executeReactive` method use the same processor used by
`executeAsync` (see
[here](65d2c19c40/core/src/main/java/com/datastax/dse/driver/internal/core/cql/reactive/CqlRequestReactiveProcessor.java (L53)))
and wrap the callback in the `DefaultReactiveResultSet` publisher.
Here I'm simply overriding the `executeReactive` method doing the same
thing: call the already instrumented `executeAsync` method and wrapping
the callback using the `DefaultReactiveResultSet` publisher.
~~I did an upgrade of the `java-driver-core` library to have
`TracingCqlSession.java` extending the `ReactiveSession`. I have to
probably rename the `cassandra-4.0` module in `cassandra-4.14` but I'll
let you confirm this.~~ -> Cassandra-4.4 is enough.
---------
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
Resolves
https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/7436
* Created new Module `spring-webflux-5.3` which contains only
server-side library instrumentation
* Minimum supported version is 5.3 because there are various problems in
older versions of reactor and webflux that prevent a few of the tests
from passing.
* Moved existing `spring-webflux-5.0` (webclient instrumentation) into a
common `spring-webflux` folder next to the 5.3 (server) instrumentation.
Moved the README to the parent folder so the docs are cohesive between
client/server instrumentation.
* Implemented `WebFilter` which instruments the server-side
* Depends on the `reactor-3.1` instrumentation to pass the context
around. Registers the react hook when it creates the `WebFilter`
* Tests using the standard HTTP server test suite
---------
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
Co-authored-by: Mateusz Rzeszutek <mrzeszutek@splunk.com>
This PR resolves#7629
This adds javaagent instrumentation for the
[jodd-http](https://http.jodd.org/) `HttpRequest`.
It creates `Http Client Spans` and `Http Client Metrics`, the lowest
supported version is `org.jodd:jodd-http:4.2.0` (most recent: `6.3.0`),
since this is the first version of the library supporting java 8, having
follow-redirect capability and `HttpRequest#overwriteHeader()` method.
The instrumented method's signature and return type `HttpRequest#send()`
has not been modified since, and therefore the instrumentation works for
all `jodd-http` versions above `4.2.0`.
Since this is my first contribution/instrumentation, I orientated myself
on the `apache-httpclient-5.0` instrumentation, but obviously I would be
glad to get some feedback on this
---------
Co-authored-by: Mateusz Rzeszutek <mrzeszutek@splunk.com>
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>
Related to #7107 and #7202
Support WebFlux 6.
Supporting reactor 3.5 seems pretty straightforward, the
`subscriberContext()` was deprecated in 3.4 in favor of
`contextWrite()`. In 3.5, `subscriberContext()` was removed.
This PR doesn't bump `latestDepTestLibrary` to 3.5 yet because there are
a couple of tests that succeed in 3.4 using `contextWrite()` but fail in
3.5 using `contextWrite()`.
My proposal is to review/merge this PR, and then I can ping our resident
reactor experts to see if they have thoughts on the failing tests in
3.5.
fyi I added topic for SIG meeting in 2 weeks b/c I'd like to automate
this but have some questions:
* What is the purpose of keeping around old diffs?
* If we need them, what about not including the empty ones?
* Do we diff minor versions against patches (if any), or only against
last minor?
This was discussed a long while back, but never documented (and recently
came up in #6889)
Co-authored-by: Fabrizio Ferri-Benedetti <fferribenedetti@splunk.com>
Added new "Restrict pushes that create matching branches: UNCHECKED",
which I discovered is needed during contrib release.
Removed the old `v*` branch protections since we don't need to make any
more patch releases from those old branch names anymore.
Working PR to capture all the changes required to update to otel java
1.19.0. The new log API force allows
`:instrumentation-appender-api-internal` and
`:instrumentation-appender-sdk-internal`, but necessitates a decent
amount of refactoring as a result.
The PR points at the `1.19.0-SNAPSHOT`, which I'll update upon
publication.
Co-authored-by: Mateusz Rzeszutek <mrzeszutek@splunk.com>
Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
Co-authored-by: Lauri Tulmin <ltulmin@splunk.com>
This seems nice for after pushing `spotlessApply` on an otherwise
approved and passing PR. I just enabled it and tried it on #6774.
(somewhat related to #6743)
Btw, I thought this was helpful explanation
> After you enable auto-merge for a pull request, if someone who does
not have write permissions to the repository pushes new changes to the
head branch or switches the base branch of the pull request, auto-merge
will be disabled. For example, if a maintainer enables auto-merge for a
pull request from a fork, auto-merge will be disabled after a
contributor pushes new changes to the pull request.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request#about-auto-merge
Lauri Tulmin
Simone Giusso
James Moessis
Mateusz Rzeszutek
Felix Wong
Phil
moznion
OpenTelemetry Bot
kaibocai
Gregor Zeitlinger
Trask Stalnaker
sodared
jack-berg
Aaron Ai