Skip to content
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

Capture of InProc Telemetry Type not working properly #2774

Closed
zoomingrocket opened this issue Dec 6, 2022 · 6 comments
Closed

Capture of InProc Telemetry Type not working properly #2774

zoomingrocket opened this issue Dec 6, 2022 · 6 comments

Comments

@zoomingrocket
Copy link

zoomingrocket commented Dec 6, 2022

Expected behavior

We were currently using App Insight 3.3.1 GA and started evaluating 3.4.5 GA. Immediately after switching over to the new release, we started noticing a huge spike of InProc invocations getting captured as "Request" type.

We are using "captureControllerSpans" as true in config JSON & customInstrumentation

"preview": {
    "captureControllerSpans": true,
}
,
    "customInstrumentation": [
      {
        "className": "com.boomi.execution.ExecutionTask",
        "methodName": "call"
      }

3.3.1 GA Release behavior
image

Actual behavior

3.4.5 GA Release Behavior
image

To Reproduce

We are using a COTs Middleware system and this is noticed for all requests captured where inProc is now classified as "Request" type instead

Sample Application

N/A

System information

Please provide the following information:

  • SDK Version: 3.4.5 GA
  • OS type and version: Cent OS 7.9
  • Application Server type and version (if applicable): N/A
  • Using spring-boot? N/A
  • Additional relevant libraries (with version, if applicable): N/A

Logs

Let me know what specific log we should capture which will be helpful in debugging this behavior

Screenshots

Posted above

@ghost ghost added the Needs: Triage 🔍 label Dec 6, 2022
@zoomingrocket
Copy link
Author

So after further analysis, the primary difference with the latest GA release is any custom instrumentation method invocations are by default tagged with telemetry type as "Request" instead of earlier behavior where they were marked inProc when part of another parent invocation.

We have tried two combinations

  1. Disable inProc and leave the customInstrumentation but it resulted in the same behavior where all invocations for custom instrumentation class were captured with Telemetry Type REQUEST
  2. Keep InProc ON and remove custom instrumentation - This resulted in no inProc capture at all, on top of it we missed actual custom instrumentation requests starting which had no traceparent as just standalone trace capture.

So looking for suggestions to have the best of both worlds :) We are ok to disable InProc capture, but we want the custom instrumentation requests to be captured as standalone requests only when there is no traceparent or invocation not part of a parent request span. This is currently possible in 3.3.1 GA with inProc capture disabled and only having custom instrumentation enabled

@trask
Copy link
Member

trask commented Dec 6, 2022

hi @zoomingrocket, thanks for reporting this!

this behavior was changed by #2513, but I've sent #2776 which should bring the best of both worlds (and bring your particular use case back to the old behavior)

@zoomingrocket
Copy link
Author

@trask - Thanks appreciate the update, happy to test a snapshot build when available.

trask added a commit that referenced this issue Dec 11, 2022
See #2774

Co-authored-by: github-actions[bot] <github-action[bot]@users.noreply.github.com>
@trask
Copy link
Member

trask commented Dec 11, 2022

@zoomingrocket
Copy link
Author

@trask - Verified with snapshot build, behavior is back to normal. Thanks!

@trask
Copy link
Member

trask commented Dec 14, 2022

@trask trask closed this as completed Dec 14, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Jan 14, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants