-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracing and log correlation without otel #43718
base: main
Are you sure you want to change the base?
Conversation
Fallback tracing benchmarks
So with fallback tracing (no logs) enabled by default, we're going to create ~2 spans for client SDK code in common case (1 public API-surface and 1 HTTP), adding ~90ns to each client call along with some allocations which seems reasonable. This time is essentially spent on generating random Ids and we'd probably get a comparable impact from x-ms-client-id thing. |
API change check API changes are not detected in this pull request. |
Champion scenario: var httpPipeline = new HttpPipelineBuilder()
.policies(new HttpRetryPolicy(), new HttpRedirectPolicy(), new HttpInstrumentationPolicy(null, null))
.build();
// this would effectively be done by codegen in client libs (when they create a span)
// but users can also provide context explicitly and we'll use it.
// we also support creating this context from OTel spans
RequestOptions requestOptions = new RequestOptions().setInstrumentationContext(createRandomContext());
HttpRequest request = new HttpRequest(HttpMethod.GET, "http://www.microsoft.com")
.setRequestOptions(requestOptions);
httpPipeline.send(request); logs with simulated error (formatted, verbose)
or with simulated error and redirect (formatted, info)
So We can easily extend it to support implicit context propagation (which already works with otel). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
moved to HttpInstrumentationLoggingTests
@@ -314,27 +311,6 @@ public void tracingIsDisabledOnInstance() throws IOException { | |||
assertEquals(0, exporter.getFinishedSpanItems().size()); | |||
} | |||
|
|||
@Test | |||
public void tracingIsDisabledOnRequest() throws IOException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removed disabling individual requests - we didn't advertise this feature in azure-core and I don't recall anyone asking for it.
We also don't support it in other languages.
.../src/main/java/io/clientcore/core/implementation/instrumentation/fallback/RandomIdUtils.java
Outdated
Show resolved
Hide resolved
...re/src/main/java/io/clientcore/core/implementation/instrumentation/otel/OTelInitializer.java
Outdated
Show resolved
Hide resolved
...va/io/clientcore/core/implementation/instrumentation/fallback/FallbackContextPropagator.java
Show resolved
Hide resolved
...va/io/clientcore/core/implementation/instrumentation/fallback/FallbackContextPropagator.java
Outdated
Show resolved
Hide resolved
...va/io/clientcore/core/implementation/instrumentation/fallback/FallbackContextPropagator.java
Outdated
Show resolved
Hide resolved
...ain/java/io/clientcore/core/implementation/instrumentation/fallback/FallbackSpanContext.java
Outdated
Show resolved
Hide resolved
bcc6c9c
to
4db1075
Compare
The next PR in the series of client core tracing+logging improvements.
In this episode, we:
InstrumentationContext
- strongly typed container for trace context that's used to correlate logs with or without otelHttpInstrumentationPolicy
withHttpLoggingPolicy
. This is not strictly necessary, but allows toHttpRetryPolicy
andHttpRedirectPolicy
logging
intoinstrumentation
packageIn next episodes:
HttpLogOptions
andInstrumetnationOptions
?