This question already has answers here:
Spring Boot - How to log all requests and responses with exceptions in single place?
(28 answers)
Closed 3 years ago.
I have a Spring Boot backend application and I'd like to list all the REST API calls made by clients to my application.
I'm running my app in Tomcat/nginx.
Way 1 (Actuator):
You can track last 100 request using Spring Boot Actuator. Here is the way to do this :
Add the maven dependency:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Edit the application.properties and add the following line:
management.endpoints.web.exposure.include=*
After running your spring boot application, now you can track the latest 100 http requests by calling this url:
http://localhost:8070/actuator/httptrace
Way 2 (Aspect):
But you can also get the log using Aspect.
It provide you some amazing annotation like: #Before , #AfterReturning, #AfterThrowing etc.
Here #Before log the url,request parameters, #AfterReturning log the response parameters and #AfterThrowing log the error with message, You may not don't need all endpoints log, so here have some filters based on package.
To implement this feature using aspects check this anawer
Related
My Goal
I need to read a file and divide each line as a message and send to kafka from a spring batch project and another spring integration project will be receiving the messages to process it in a async way. I want to return those messages after processing to the batch project and create 4 different files out of those messages.
Here I am trying to use OutBoundGateway and ReplyingKafkaTemplate. I am unable to configure it properly... Is there any example or reference guide to configure it.
I have checked spring batch integration samples github repository... There is no sample for outBoundGateway or ReplyingKafkaTemplate.
Thanks in Advance.
For ReplyingKafkaTemplate logic in Spring Integration there is a dedicated KafkaProducerMessageHandler which can be configured with a ReplyingKafkaTemplate.
See more info in docs:
https://docs.spring.io/spring-integration/docs/current/reference/html/kafka.html#kafka-outbound-gateway
And more about ReplyingKafkaTemplate:
https://docs.spring.io/spring-kafka/reference/html/#replying-template
Probably on the other a KafkaInboundGateway must be configured, respectively:
https://docs.spring.io/spring-integration/docs/current/reference/html/kafka.html#kafka-inbound-gateway
I have the following setup:
Proxy (P) -- HTTP --> Spring Boot 2 app (X) -- HTTP --> Spring Boot 1 app (Y)
The proxy sends the requestId as an HTTP header which I need to include in the logs of both X and Y.
For the X app I could easily do it with the support of Spring Cloud Sleuth 2 using
spring:
sleuth:
propagation-keys: requestId
and creating a CurrentTraceContext implementation with inspiration from Slf4jCurrentTraceContext where I add
MDC.put("requestId", ExtraFieldPropagation.get(currentSpan, "requestId"));
and then I can easily add it to the logs using the following log pattern:
%d{yy-MM-dd E HH:mm:ss.SSS} %5p [component=${springAppName},requestId=%X{requestId:-}] %m%n"
But now I need to propagate the requestId also to Y app.
Unfortunately there I cannot leverage the goodies introduced in Spring Cloud Sleuth 2.0, (like TraceContext from brave library) since that is a Spring Boot 1.x app.
Wondering what are the options?
I was thinking to extend the Slf4jSpanLogger and inject into DefaultTracer but not sure how to get the requestId there is no TraceContext in SpanLogger.
requestId has to be there in the headers. You would have to modify the current logic of parsing the HTTP headers for Boot 1.x and retrieve that value from the headers and put it in the span.
The easiest way however would be to propagate that value as baggage cause baggage works out of the box for Boot 1.x. That way if we see the baggage- prefixed headers, Sleuth 1.3.x will automatically propagate it. Remember to whitelist the baggage in Boot 2.0.
I'm trying to enable a Spring Cloud Gateway app to automatically refresh its routing config yml on the fly. I have been able to set up a Cloud Config server to host the route YAML and enabled the Spring Cloud Gateway to automatically refresh its config via a #Scheduled contextRefresher.refresh() usage. However, this requires two running apps, and we want to try to minimize the number of additional servers needed to support this requirement.
The Spring Cloud Config Server documentation suggests any boot app can be embedded with a config server via the #EnableConfigServer annotation: https://cloud.spring.io/spring-cloud-static/spring-cloud.html#_spring_cloud_config_server
However, when attempting to introduce the spring-cloud-config-server module in my Gateway's build.gradle, I run into the following error on startup:
org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'org.springframework.http.codec.ServerCodecConfigurer' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}
From the discussion here (https://github.com/spring-cloud/spring-cloud-gateway/issues/319) it seems that the issue above arises because spring-boot-starter-web is incompatible w/ Gateway; Gateway is a Netty app and spring-boot-starter-web uses tomcat/servlets. When trying to exclude spring-boot-starter-web from the cloud-config-server module, the app fails again w/:
onfigReactiveWebServerApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanDefinitionStoreException: Failed to process import candidates for configuration class [org.springframework.cloud.config.server.config.ConfigServerAutoConfiguration]; nested exception is java.io.FileNotFoundException: class path resource [org/springframework/web/servlet/config/annotation/WebMvcConfigurerAdapter.class] cannot be opened because it does not exist
Is it the case that a Spring Cloud Gateway app cannot be enabled as a CloudConfig server? Or am I missing something.
FWIW my sprincCloudVersion is Finchley.SR1
They can not. Config server is based on spring MVC (servlets), gateway is based on spring webflux and Netty. They are not compatible and cannot be run together.
I am using Wildfly and I started to write some clients to connect to other backends. Now I want to set some timeouts to my stubs to avoid that my application performance suffers from slow or not responding backends.
The connection works very well, but when I wanted to set the timeout I realized that I have to fall back to the client implementation so I used resteasy (used in Wildfly afaik).
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-client</artifactId>
<version>3.0.8.Final</version>
<scope>provided</scope>
</dependency>
Is there really no standard way to accomplish that?
The resteasy documentation is quite short. Does anyone have a good source with examples for setting a timeout there?
greetings
m
PS:
Client client = ClientBuilder.newClient();
Builder request = client.target(ADRESS_BALANCE).request();
return request.get(BigInteger.class);
RestEasy way to set socketTimeout:
ResteasyClientBuilder builder = (ResteasyClientBuilder) ClientBuilder.newBuilder();
builder.socketTimeout(60, TimeUnit.SECONDS);
If you would like to use standard way check this answer
I'm having trouble with a jersey application running on a jetty server that will take up to 30 seconds to start. I don't know what causes this behaviour, and I'm unsure how to debug it.
Jersey is not started until the first HTTP request to one of its services are made. After the first request is made, the following gets printed:
INFO: Initiating Jersey application, version 'Jersey: 1.3 06/17/2010 04:53 PM'
After that, 5 to 45 seconds pass, and then jersey prints info about what resources it found and replies to the HTTP request.
First, I'd like to force jersey to start when the rest of the app starts as a hack to get around this until I find the culprit. Is there any way to do that without emulating an actual HTTP request to jetty?
Second, I'm stumped as to how to debug this. I've checked the constructors in my service classes, and they don't appear to be responsible. Has anyone had similar problems with jersey?
You could try the following in your web.xml:
<servlet>
<servlet-name>ServletAdaptor</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
I'm not sure why there'd be a long delay - perhaps it's doing some form of check for updates - are you able to monitor the http traffic from your application? Glassfish does that and it can take a while.