@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>
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>
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>
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>
…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.
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.
I decided splitting changes on different PRs due to there are a lot of
lines of code in tests here and it should simplify review process.
Another option is I can add additional commit to this PR with conversion
of other groovy files.
As part of discussions #7616, the idea of trying to do a more piecemeal
approach came up. A reasonable ask.
This is the first step in refactoring the http client tests. It factors
out the `HttpClientResult` inner class of the `AbstractHttpClientTest`
so that this can be reused by new test framework later. It also factors
the relevant abstract methods in the abstract class to a new type
adapter, which will also be reused.
Co-authored-by: Mateusz Rzeszutek <mrzeszutek@splunk.com>
This PR includes updates to the SQLSanitizer, DbClientSpanNameExtractor
and SqlStatementInfo to name spans according to procedure name for CALL
statements. The updates to the naming logic are in the SqlSanitizer and
table has been renamed to identifier as using the table variable for the
procedure name would not be idiomatic. SqlStatementInfo has been updated
so that the db.sql.table attribute is not included for procedures.
Let's keep close to the SDK repo config.
I reverted some of the changes, only left those that I think make sense
anyway (e.g. comparing enums with `==`)
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.
Bumps [spotless-plugin-gradle](https://github.com/diffplug/spotless)
from 6.12.0 to 6.12.1.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="718a504c12"><code>718a504</code></a>
Published gradle/6.12.1</li>
<li><a
href="c13acee213"><code>c13acee</code></a>
Published lib/2.31.1</li>
<li><a
href="552aabf876"><code>552aabf</code></a>
fix(deps): update dependency com.facebook:ktfmt to v0.42 (<a
href="https://github-redirect.dependabot.com/diffplug/spotless/issues/1421">#1421</a>)</li>
<li><a
href="4063e9f6d1"><code>4063e9f</code></a>
Add support for KtLint 0.48.0 (<a
href="https://github-redirect.dependabot.com/diffplug/spotless/issues/1432">#1432</a>
fixes <a
href="https://github-redirect.dependabot.com/diffplug/spotless/issues/1430">#1430</a>)</li>
<li><a
href="062e835846"><code>062e835</code></a>
Bump changelogs.</li>
<li><a
href="8f7e00594d"><code>8f7e005</code></a>
spotlessApply</li>
<li><a
href="9a8ccae9ec"><code>9a8ccae</code></a>
Bump default ktfmt 0.41 -> 0.42</li>
<li><a
href="fb4277d2b1"><code>fb4277d</code></a>
Merge branch 'main-ktlint-0.48.0' into renovate/ver_ktfmt</li>
<li><a
href="b44d70d00a"><code>b44d70d</code></a>
Move changelog entries to the correct release.</li>
<li><a
href="b3d8e89002"><code>b3d8e89</code></a>
spotlessApply for 2023</li>
<li>Additional commits viewable in <a
href="https://github.com/diffplug/spotless/compare/gradle/6.12.0...gradle/6.12.1">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
You can trigger a rebase of this PR by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Mateusz Rzeszutek <mrzeszutek@splunk.com>
Fixes#7265
I took a look at the new Observation API, and I think that it still
makes sense to continue using the interceptors to implement this
instrumentation: they implement the OTel spec (which includes way more
attributes than the default observation convention implemented in
Spring), and cooperate with the Kafka client instrumentation and link
the receive and process spans together. And it's quite a simple change
in one of our interceptors, instead of rewriting everything.
(Draft because Spring Boot 3 hasn't released yet, and it is required to
run the tests. If we're not in a hurry this PR can wait a bit for that)
When a webflux filter is added which throws an exception, the
instrumentation does not currently capture the `http.status_code`.
The fix is to move `WebClientTracingFilter` from the first to the last
filter in the chain, which I think(?) is the general strategy we've
taken for other client instrumentation, e.g. so that if a filter makes
another http call it won't be suppressed.
I don't love the test coverage I added, so let me know if you have any
better suggestions?
EDIT: btw, I did archaeology to confirm that behavior (adding to the
beginning of the chain) has been in place since the webflux
instrumentation was added originally
6f472a62a0 (diff-493ad89b5bde807c90387aa2bb67eb10d3bcef6b6a388bd31e11796a6d01ac38R36)
~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
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).
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>
sfriberg
Lauri Tulmin
Helen
Mateusz Rzeszutek
OpenTelemetry Bot
Andrei Chugunov
adamleantech
Abhinandan Seshadri
Abhinandan Seshadri
Jean Bisutti
James Moessis
Trask Stalnaker
jason plumb
Alex Kats
dependabot[bot]
jack-berg
Aaron Ai
王展城
