We're using Brave's ExtraFieldPropagation feature to propagate custom fields (e.g. an internal-only request identifier) between services as HTTP headers.
Some of our services make requests to external services using a RestTemplate or Feign client in the course of processing a request. Since Sleuth enhances all RestTemplate beans and Feign clients with the propagation feature, this means that external services receive the internal-only headers, which I'd like to avoid.
I know of two workarounds that allow me to avoid this behavior, both of which are flawed:
Instantiate a client object manually as opposed to using a #Bean so that Sleuth does not add an interceptor. The downside I see here is that developers have to remember to follow this pattern to avoid leaking information, and this is difficult to enforce.
Add an interceptor that removes these headers from outgoing requests. The downsides here are that a) I need separate interceptors for RestTemplate and Feign clients (not a huge deal); b) it looks like Feign client interceptors do not have a way to influence order of execution (see javadoc here), so I can't guarantee that the new interceptor will run last / after the Sleuth one.
Is there a way to customize Sleuth (e.g. via some kind of injector bean) such that, prior to injecting headers in an outgoing HTTP request, I can reason about the destination of the request? I saw documentation regarding custom injector beans, but it appears those no longer exist in spring boot >= 2. I can't seem to find an equivalent construct in Brave.
You can unsample a given URL which means that the headers will be propagated but not sent to Zipkin. You can't disable instrumentation for only some of the URLs cause we're instrumenting all of the components that are registered as beans.
Related
which is better alternative for calling REST endpoint in springboot application, calling REST endpoints using WebClient or calling REST endpoints using RestTemplate ?
Spring’s documentation recommends using WebClient, but that’s only a valid recommendation for reactive apps. If you aren’t writing a reactive app, use OpenFeign instead. Like anything else in software, it fits well for some cases, but might complicate things for others. Choosing WebClient to implement the REST endpoint calls is strongly coupled to making your app reactive
RestTemplate gives many advantages if you are using it from within Springboot application, i.e. in your server side to another part of your own app - sort of like an internal call. Because the RestTemplate "knows" all your entities and beans and so if you need to send over or receive an object which is known within your springboot application RestTemplate can map them automatically which is a very nice advantage. If you sending a request to some third party api and do not pass or receive your known entities RestTemplate is still a valid option but it just becomes just another Http client. Its just simply there as part of Springboot provided tools. But in this case you may use any other client as well.
I'm running a Spring Boot app using:
Spring Boot 2.3.8
Spring Cloud Hoxton.SR10
I've declared the spring-cloud-starter-zipkin and spring-cloud-starter-openfeign dependencies, and have configured my app to point to a Zipkin server. Its a pretty vanilla setup and configuration (I also declare the spring-cloud-starter-netflix-ribbon and spring-cloud-starter-kubernetes-all dependencies o allow Spring Feign to use k8s service discovery).
My app declares a #SpringFeign annotated interface with a method to call to a remote service S.
So generally zipkin is getting spans from my app (for e.g. incoming REST calls) and B3 headers are being propagated via HTTP to the service S being called through feign.
But zipkin does not report a span from my app representing the Feign call to S.
Is that something that should "just happen", or am I missing a piece of the puzzle?
I can e.g. add #NewSpan to the feign interface method, but that doesn't give me HTTP details for the request/response as span tags. And I rather not do that if this is supposed to work out of the box.
This should be done out of the box: https://docs.spring.io/spring-cloud-sleuth/docs/2.2.7.RELEASE/reference/html/#feign
You can take a look at the feign sample (you need to go back in the history, currently it is for 3.x): https://github.com/spring-cloud/spring-cloud-sleuth/tree/master/spring-cloud-sleuth-samples/spring-cloud-sleuth-sample-feign
In order to see if propagation works, look into the outgoing request, it should contain the tracing-related headers.
I get that Feign is declarative and hence it abstracts out a lot of things for the developer. But, when should one choose one over the other? Though feign is declarative, it has serious problems with oAuth. What are some of the considerations in using RestTemplate over Feign
Feign allows you to abstract the mechanics of calling a REST service. Once you configure and annotate the Feign interface, you can call a REST service by making a simple Java function call. The actual implementation of making a REST call is handled at runtime by Feign. This means that the implementation can be configured without changing your business logic code.
By just changing the Feign configuration in Java or using properties you can add encoding/decoding, logging, and change the REST call implementation library. All this is done through configuration only, while the business logic that calls the service remains unchanged.
Since Feign uses standard Java interfaces, it's also easy to mock them during unit tests.
There are certain advantages.
1.URLs are not hardcoded.
2.you don't have to write unit test cases for feign as there is no code to test however you have to write integration tests.
3.we can use Eureka Client ID instead of the URL.
4.Feign handled the actual code.
5.Feign integrates with Ribbon and Eureka Automatically.
6.Feign provides a very easy way to call RESTful services.
One of the advantages of using Feign over RestTemplate is that, we do not need to write any implementation to call the other services. So there is no
need to write any unit test as there is no code to test in the first place. However, it is advised that we write Integration tests.
Using Feign-clients over rest-templates has number of advantages. I will list down those below.
The developer need not worry about the implementation. Just to create abstract Feign interface and few annotations - declarative
principle. (If you want customized configuration, then it will hold
some code)
With Spring Cloud Eureka, Ribbon client-side load-balancer will be equipped with Feign client.
No need to worry about the unit test, because there is no implementation from you to test. (Arguable)
Supports Feign annotations and JAX-RS annotations.
Highly compatible and easily configurable with Spring Cloud (Specially with Eureka server registry)
Allows Feign client configuration via #Configuration class or application properties.
Allows us to add interceptors. (Add interceptors via #Configuration or application properties. Alternatively can use
Spring Cloud provided interceptors as well. Example -
BasicAuthRequestInterceptor)
Hystrix support for fall-back mechanism.
Logging
Error handling
Feign is a good choice, If you are fascinated with JPA and the way how it resolves your queries, then Feign is the tool for you. Feign will handle your server requests perfectly fine.
RestTemplate is used for making the synchronous call. When using RestTemplate, the URL parameter is constructed programmatically, and data is sent across to the other service. In more complex scenarios, we will have to get to the details of the HTTP APIs provided by RestTemplate or even to APIs at a much lower level.
Feign is a Spring Cloud Netflix library for providing a higher level of abstraction over REST-based service calls. Spring Cloud Feign works on a declarative principle. When using Feign, we write declarative REST service interfaces at the client, and use those interfaces to program the client. The developer need not worry about the implementation ...
Advantages of using Feign over RestTemplate:
Declarative approach: Feign provides a more declarative approach to define and use REST API clients, which can make the code more readable and easier to maintain.
Integrated with Eureka: Feign is integrated with Netflix Eureka for service discovery, making it easier to build and consume APIs in a microservices architecture.
Better error handling: Feign provides better error handling, including support for custom error handling and retries.
Support for multiple encodings: Feign supports multiple encoding types, including JSON, XML, and form data, while RestTemplate only supports JSON and XML.
Disadvantages of using Feign over RestTemplate:
Limited flexibility: Feign provides a more opinionated approach to defining and using REST API clients, which may limit flexibility in certain situations.
Limited control over HTTP request and response: Feign abstracts away some of the low-level details of the HTTP request and response, which can make it harder to control and customize these details if needed.
Lack of official support: Feign is not an officially supported library from Spring, which may be a consideration for some developers or organizations.
I have a rest web service that is implemented using spring boot starter web. This service acts as a client to another application that requires authentication to make calls to it.
Calls made from the client to the server are using org.springframework.web.client.RestTemplate.
Is there a way to come up with a solution to add authentication headers to outbound requests at one single point before they are sent out?
I don't want to add headers in each of the requests separately.
Javadoc for RestTemplate says:
This template uses a SimpleClientHttpRequestFactory and a
DefaultResponseErrorHandler as default strategies for creating HTTP
connections or handling HTTP errors, respectively. These defaults can
be overridden through
HttpAccessor.setRequestFactory(org.springframework.http.client.ClientHttpRequestFactory)
So I would take SimpleClientHttpRequestFactory and override its prepareConnection(..) method.
In Spring Integration, handlers and interceptors look like they basically achieve the same thing. There are even some 'duped' implementations, such as MessageTransformingChannelInterceptor and MessageTransformingHandler, which as far as I can tell provide the same functionality with different semantics.
Is there a time when one is appropriate and not another? If it's a matter of preference then I'm guessing that there'd be some sort of convention?
Thanks,
Roy
My general rule of thumb is to use interceptors sparingly; and typically, only for "passive" things like logging, wire tap etc.
Some users like to do message validation in interceptors; especially if they want to apply the same validation to multiple channels, perhaps with a global interceptor with an appropriate channel pattern.
The transforming interceptor was created in a very early iteration of the framework (2008) and we should probably remove (at least) the only mention of it in the reference (in the XML section).
Handlers
Handler means a Class which handles with certain thing.
For example, in the Spring framework, a HandlerMapping is used to map requests to specific controllers or handlers based on the URL pattern or request method.
Handler is responsible for processing a request and generating a response while a Filter is responsible for modifying or inspecting a request or response
Interceptors
Interceptors share a common API for the server and the client side.
Interceptors are often used to implement cross-cutting concerns such as transaction management, security, or logging.
Interceptors are part of Spring's AOP framework and are used to intercept method calls to Spring beans. They allow you to add behaviour to a method call before or after it is executed. Interceptors can be configured using annotations or XML configuration. Interceptors are used to intercept method calls to Spring beans.