Spring Cloud Data Flow is built upon several Spring projects, but ultimately the dataflow-server is a Spring Boot app, so the logging techniques that apply to any Spring Boot application are applicable here as well.
While troubleshooting, following are the two primary areas where enabling the DEBUG logs could be useful.
Spring Cloud Data Flow builds upon Spring Cloud Deployer SPI and the platform specific dataflow-server uses the respective SPI implementations. Specifically, if we were to troubleshoot deployment specific issues; such as the network errors, it’d be useful to enable the DEBUG logs at the underlying deployer and the libraries used by it.
For instance, if you’d like to enable DEBUG logs for the local-deployer, you’d be starting the server with following.
$ java -jar <dataflow-server>.jar --logging.level.org.springframework.cloud.deployer.spi.local=DEBUG
(where, org.springframework.cloud.deployer.spi.local
is the global package for everything local-deployer
related)
For instance, if you’d like to enable DEBUG logs for the cloudfoundry-deployer, you’d be setting the following environment variable and upon restaging the dataflow-server, we will see more logs around request, response and the elaborate stack traces (upon failures). The cloudfoundry-deployer uses cf-java-client, so we will have to enable DEBUG logs for this library.
$ cf set-env dataflow-server JAVA_OPTS '-Dlogging.level.cloudfoundry-client=DEBUG' $ cf restage dataflow-server
(where, cloudfoundry-client
is the global package for everything cf-java-client
related)
If there’s a need to review Reactor logs, which is used by the cf-java-client
, then the following
would be helpful.
$ cf set-env dataflow-server JAVA_OPTS '-Dlogging.level.cloudfoundry-client=DEBUG -Dlogging.level.reactor.ipc.netty=DEBUG' $ cf restage dataflow-server
(where, reactor.ipc.netty
is the global package for everything reactor-netty
related)
Note | |
---|---|
Similar to the |
The streaming applications in Spring Cloud Data Flow are Spring Boot applications and they can be independently setup with logging configurations.
For instance, if you’d have to troubleshoot the header
and payload
specifics that are being passed
around source, processor and sink channels, you’d be deploying the stream with the following
options.
dataflow:>stream create foo --definition "http --logging.level.org.springframework.integration=DEBUG | transform --logging.level.org.springframework.integration=DEBUG | log --logging.level.org.springframework.integration=DEBUG" --deploy
(where, org.springframework.integration
is the global package for everything Spring Integration related,
which is responsible for messaging channels)
These properties can also be specified via deployment
properties when deploying the stream.
dataflow:>stream deploy foo --properties "app.*.logging.level.org.springframework.integration=DEBUG"