Conversation
| * @deprecated for removal after 1.55.0. Use {@link #isEnabled(Severity, Context)} or {@link | ||
| * #isEnabled(Severity)} instead. | ||
| */ | ||
| @Deprecated |
There was a problem hiding this comment.
Note, also removing this deprecated API
Codecov Report❌ Patch coverage is ❌ Your patch status has failed because the patch coverage (72.22%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #8200 +/- ##
============================================
+ Coverage 90.29% 90.30% +0.01%
+ Complexity 7652 7651 -1
============================================
Files 843 843
Lines 23066 23073 +7
Branches 2310 2310
============================================
+ Hits 20827 20836 +9
+ Misses 1520 1519 -1
+ Partials 719 718 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| * the response is subject to change over the application, callers should call this before each | ||
| * call to {@link #logRecordBuilder()}. | ||
| */ | ||
| default boolean isEnabled(Severity severity, Context context) { |
There was a problem hiding this comment.
why does this need the context as an additional parameter, but the tracer & instrument ones don't?
There was a problem hiding this comment.
For logs, the behavior of isEnabled can be toggled based on context. See LoggerConfig.trace_based: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/sdk.md#loggerconfig
There's been no discussed analog for traces or metrics.
You could get creative and imagine cases where we add such capabilities in the future, but the cases seem farfetched to me:
- The span analog to filtering based on context is a sampler. Hard to imagine it making sense to filter out spans before calling the sampler.
- For metrics, metric recording is binary: on and you get the whole population of measurements, off and you get none of the measurements. Hard to imagine it being useful / common to filter measurements based on some data in context.
If I'm wrong and someday the spec adds a context argument to the trace / metric enabled methods, we can add an overload to accommodate.
2 participants
The enabled concept API has been stabilized at the spec level across metrics, logs and traces: