Support OpenTelemetry's way to suppress autoinstrumentation
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- java
- Domain
- observability
Research direction
Start by locating the configuration-resolution path for the currently supported otel.javaagent.enabled setting and compare it with the OpenTelemetry Java Agent settings named in the issue. Implement the applicable compatibility, including config-file and environment-variable precedence, then verify that resolved settings appear in the diagnostic log.
Written by the indexing model from the issue text.
Description
Is your feature request related to a problem? Please describe.
As illustrated by this bug report, users may expect the OpenTelemetry's Java Agent's configuration settings for suppressing instrumentation would work for the App Insights Agent. However, currently only otel.javaagent.enabled is supported with a handful of other ones.
The particular parameter of interest would be otel.instrumentation.common.default-enabled aimed to suppress all default instrumentation and reversing from "I suppress N things" to "I allow N things". Going further, a combination with otel.instrumentation.opentelemetry-api.enabled=true, otel.instrumentation.opentelemetry-instrumentation-annotations.enabled=true would allow to let only user instrumentation.
Describe the solution you would like
Where applicable, be compatible with vanilla OpenTelemetry Java Agent configuration settings. If configured through the config file as well, allow properties/env variables override that configuration. Post configuration resolution into the diagnostic log.
Describe alternatives you have considered
The alternative is suppressing through configuration file and using sampling overrides, which technically is not suppression of instrumentation (and still must have performance overhead), but functionally is even more powerful for the user for limiting noisy telemetry.
- Dominant language
- Java
- Stars
- 327
- Forks
- 222
- Avg merge
- 22h 34m
- Merged PRs (30d)
- 14
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/ApplicationInsights-Java
-
microsoft/ApplicationInsights-Java#4851 · 1 assignee ·
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
microsoft/ApplicationInsights-Java#4817 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
microsoft/ApplicationInsights-Java#4770 · 2 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
microsoft/ApplicationInsights-Java#4769 · 2 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
microsoft/ApplicationInsights-Java#4729 · 121 comments ·
All issues in microsoft/ApplicationInsights-Java
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
elastic/gradle-plugins#157 ·
-
enhancement Tools
Difficulty 1/5 Under an hour Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
apache/rocketmq-dashboard#5008 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
DETECT_PARAMETER_NAMES=false silently disables @ConstructorProperties-based Creator detection too Open
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
FasterXML/jackson-databind#6229 ·