Should stackdriver logging support be provided?

[gregw]

It has been discussed as part of https://github.com/GoogleCloudPlatform/jetty-runtime/issues/68 (and it's associated PR https://github.com/GoogleCloudPlatform/jetty-runtime/pull/81) that container independent parts of the logging configuration should eventually be moved from the jetty-runtime to the openjdk-runtime.

This would potentially involve: google-cloud-java jars and their dependencies being placed in the image; a configuration file that would be able to be turned on via an environment variable.

However, on consideration, I am not sure if doing the above is all that valuable. With modern build tools, assembling the jars necessary for an application is simple. It is actually more difficult to merge in a classpath of image-provided jars with an application, as there may be duplicates and version differences that need to be resolved (exactly the task that application build tools are best at).

Furthermore, turning on logging with a simple env variable will seldom be sufficient. Users will often wish to configure their logging with a custom logging.properties file, so a provided one is of less value.

We are providing stackdriver logging in the jetty-runtime because we are providing the container and we are responsible for the containers logs. However, we do hide the stackdriving classes from the application and it is free to provide it's own different mechanisms for logging and their dependencies. If the users of openjdk-runtime are treated like the users of the jetty-runtime, then they are responsible for their own application logging. Of course google-cloud-logging is easily available and should be well documented to make logging to stackdriver simple if the application chooses to do so.

Thus I'm in favour of leaving stackdriver logging only in the jetty-runtime.

[meltsufin]

@gregw Agreed, but I think we need to document how to turn on the nice Stackdriver logging using JUL. So, this issue is more of a documentation issue.