-
Notifications
You must be signed in to change notification settings - Fork 999
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
Provide a way to make decisions based on the parent in ObservationPredicate #3678
Comments
Thanks for opening this @jonatan-ivanov ie: @Configuration
public class TestConfiguration {
@Bean
ObservationPredicate ignoreActuator() {
return (s, context) -> ignoreActuatorRecursive(context);
};
public boolean ignoreActuatorRecursive(Observation.ContextView context) {
if (context instanceof ServerRequestObservationContext serverRequestObservationContext) {
HttpServletRequest carrier = serverRequestObservationContext.getCarrier();
return !carrier.getServletPath().startsWith("/actuator"); // <----- Line (*)
}
if (context.getParentObservation() != null) { // <-- Will the parent still be set if it was ignored in line (*)?
return ignoreActuatorRecursive(context.getParentObservation().getContextView());
}
return true;
}
} It would be great for the parent to remain set even if the parent observation was ignored in a previous predicate. The reason being so that you can properly ignore any subsequent observations deriving from a root span that was ignored. |
No, and there the parent can't be really set in these cases. If an Observation is ignored we will create a noop one that is hopefully eliminated by JIT. |
@braunsonm |
This issue was originally discussed in spring-projects/spring-boot#34400
The scenario is the following: if Spring Security is used and users want to ignore
/actuator
endpoints, there is no easy way to do it today because Spring Security does not add details about the request. One potential solution would be checking the parent (root) Observation but it is not available through the context when the predicate is tested.There is a reproducer in the issue mentioned above.
Also see: spring-projects/spring-security#12854
The text was updated successfully, but these errors were encountered: