Trask Stalnaker

Closing, if you are unable to use the auto-instrumentation solution (this repo), you can now use the auto-instrumentation solution's underlying OpenTelemetry exporters directly: https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/monitor/azure-monitor-opentelemetry-exporter/README.md

Hey @stevendick-swissre, were the exception stack traces the primary problem, since they tend to be large? What do you think about a simple rate limit on the capturing of exception...

@stevendick-swissre can you send me email ([email protected])? It looks like you had another issue yesterday, and I want to make sure we get you sorted quickly.

I believe there are some good hooks now in 3.4.0-BETA to address this issue: * rate limited sampling (to limit an unexpected spike in requests and associated telemetry) * exceptions...

hi @sidyes @Jitu-Ranjan! we will pull this feature into Application Insights Java once it has been added upstream in OpenTelemetry (https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/400)

closing, addressed by #1702

hi @xsmrcek, you can use `applicationinsights-web` 2.x artifact and use ``` RequestTelemetry requestTelemetry = ThreadContext.getRequestTelemetryContext().getHttpRequestTelemetry(); requestTelemetry.getProperties().put("myattr1", "myvalue1"); ``` this will add the custom properties onto the request [btw, we are...

hey @xsmrcek, I ran `RabbitTest`, using 3.4.0-BETA javaagent and was able to see:  can you confirm exact repro steps from your end?

Can you let us know what your use case is for TrackAvailability?

This is tracked at https://github.com/open-telemetry/opentelemetry-java-instrumentation/issues/2515, we will pull into Application Insights once it is available upstream