-
Notifications
You must be signed in to change notification settings - Fork 993
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
Observation "granularity" #3442
Comments
- introduces observation levels (same as in logging) - extends the current API to allow passing of ObservationLevel fixes gh-3442
- introduces observation levels (same as in logging) - extends the current API to allow passing of ObservationLevel fixes gh-3442
- introduces observation levels (same as in logging) - extends the current API to allow passing of ObservationLevel fixes gh-3442
We had some discussions internally, what do you think about having these levels: @bclozel, @jzheaux, @ttddyy, @mhalbritter @marcingrzejszczak |
So, if I map them to logging level, would For JDBC instrumentation, I have connection, query, and result-set observations, all of which I believe fall into I wonder what would be the best fit for |
I'm fine with the 4 levels. |
- introduces observation levels (same as in logging) - extends the current API to allow passing of ObservationLevel fixes gh-3442
We received some feedback from users who instrument components that in some cases it would be useful to conditionally create Observations based on configuration. Something similar to log levels, e.g.: let's say we have two "levels"
BASIC
andDETAILED
, if the config is set toDETAILED
/ALL
, all observations are created, if the config is set toBASIC
, only those Observations are created that haveBASIC
as their level andDETAILED
goes to noop./cc @jzheaux
The text was updated successfully, but these errors were encountered: