Logging using the Google Cloud Logging API #4

meltsufin · 2016-09-07T20:48:58Z

The Google Cloud Logging API or the stdout and stderr should be used to send logs to Stackdriver Logging.

gregw · 2016-09-07T22:59:26Z

So using the LogEntry.builder means that we can remove the JSON formatting classes?

I assume that there will be no local log file, unless configured in the users logging.properties and all logs will be consumed only by this API by default?

Should we also remove the request log file?

joakime · 2016-09-08T00:04:19Z

A bit concerned about the com.google.cloud.logging.HttpRequest object and what it shows in its testcase.

The Google Cloud Logging is java.util.logging based, so that means the the minimum server logging support level will be java.util.logging, not the Jetty default of StdErrLog

The setup for Google Cloud Logging API seems to be based on setting up the com.google.cloud.logging.LoggingHandler with the correct authentication and whatnot. (unless its auto initialized by the Google Cloud services layer)

Possible setup options:

Use slf4j-api -> slf4j-jdk14 on the server side,
- Jetty uses its Slf4jLog implementation
Use JavaUtilLog as the Jetty logger implementation.

In either setup, we would need to:

bar server org.slf4j from being used by the application.
allow java.util.logging to be used by the application, but prevent the application from replacing, resetting, or removing the root handlers (otherwise this will break the Google Cloud API use)

joakime · 2016-09-08T00:07:32Z

We need to make sure that the Jetty base image does not use etc/jetty-logging.xml as that is not compatible with both the java.util.logging layer, and the Google Cloud Logging API.

gregw · 2016-09-08T01:36:28Z

Please consider GoogleCloudPlatform/appengine-java-vm-runtime#282 in new logging design

meltsufin · 2016-09-09T16:28:19Z

Would it make sense to start out by making sure that the Jetty server log is directed to standard error? Standard out/error should automatically be picked up by Stackdriver Logging.

joakime · 2016-09-09T18:06:37Z

we would still need java.util.logging, as without it, nothing from the google layers would ever show up in the stackdriver logs without it.

the default jetty StdErrLog is multi-line, which the Stackdriver has had problems with in the past, hence all of the effort to make logging more stable with the json format, etc..

to fix StdErrLog would mean a fork of StdErrLog to something like GoogleStackdriverSystemErrLog just to conform to the limits of the Stackdriver standard out/error support

that effort would be better spent in just implementing the java.util.logging layer properly to Google Cloud Logging.

meltsufin · 2016-09-09T18:26:16Z

we would still need java.util.logging, as without it, nothing from the google layers would ever show up in the stackdriver logs without it.

What do you have in mind when you say "google layers"?

the default jetty StdErrLog is multi-line, which the Stackdriver has had problems with in the past, hence all of the effort to make logging more stable with the json format, etc..

There's work going on to automatically detect multi-line java stack traces in the logs. Is there anything else that's potentially multi-line in the Jetty server logs?

to fix StdErrLog would mean a fork of StdErrLog to something like GoogleStackdriverSystemErrLog just to conform to the limits of the Stackdriver standard out/error support

What limits are you referring to?

that effort would be better spent in just implementing the java.util.logging layer properly to Google Cloud Logging.

There are java.util.logging handlers in the Logging API. Beyond those handlers, what would our logging layer need to do?

joakime · 2016-09-09T20:06:10Z

Multiline output it very common, and not just for stack traces.

JSP produces multi-line, JSR365 (javax.websocket) does, most datasources, Jersey, Spring, and even the javax.servlet API does too (example: exceptions during startup / deployment are collected into a multi exception which is a single logging event that reports the main deployment concern, and then lists each deployment failure and possible stacktrace for that failure as well)

This is the limits that we refer to with the naive stackdriver parsing of System.err and System.out.

When I say "google layers" I mean any of the google or gcloud classes that operate on the server (or the webapp) would produce no output if using Jetty's default StdErrLog setup (which outputs only Jetty logging events to System.err)

So, we have top level options, and multiple sub-options.

Option 1: Standard Jetty Logging

This would be Jetty setup for StdErrLog and without etc/jetty-logging.xml.

Only Jetty logging events at INFO level are produced on System.err.
No other output is produced.
Nothing on System.out
Nothing from java.util.logging
Application logging does not exist and is not configured
No JSP logging events
No 3rd party events
This setup is known to produce horrible results in the console loggers

Option 2: Jetty uses java.util.logging

Technique A: Jetty uses its JavaUtilLog implementation

Server side would setup a Handler to output its events somewhere
Application logging for java.util.logging works
Application configuration of levels works
Application configuration of custom j.u.l handlers work
Google APIs / classes can participate in logging
JSP logging events supported
Limited 3rd party support (as we are stuck on java.util.logging only)

Technique B: Jetty uses its Slf4jLog implementation

Server side would setup a Handler to output its events somewhere
Application logging for java.util.logging works
Application configuration of levels works
Application configuration of custom j.u.l handlers work
Google APIs / classes can participate in logging
JSP logging events supported
Full 3rd party logging support (as we can now support any logging events from anywhere: system, server classloader, jndi, applications, etc..)

In either technique, since we are using java.util.logging now, using the Google Cloud Logging API is attainable, and preferred over the System.out and System.err parsing.

However, as noted before, we still need to be careful to not allow the application to remove/reset/change the Google Cloud Logging Handlers at the java.util.logging root context. (configuring the Google Cloud Logging, such as setting the named logger levels is very much supported)

Using the Google Cloud Logging API also means we have preliminary support for associating the HttpRequest (via the traceid or similar information), something that the Stackdriver support for system.out and system.err has historically never been able to do.

gregw · 2016-09-09T23:06:48Z

For the sake of clarity, I think I should prepare a PR for Joakim's Option 1: all the logging in jetty stripped back to the minimal: no request log and stderr log for the container. I'll add a simple test webapp that generates errors and/or causes errors within the container and we can see how the logging looks in the cloud console.

We can then see exactly what needs to be fixed and that will guide us in choosing between status quo, Technique A, Technique B, logging API or something else.

meltsufin · 2016-09-12T14:52:32Z

Yes, sounds good!

added google copyright

deleted jetty-loggin.properties file

* Issue #4 Revert to default jetty logging * Issue #4 Revert to default jetty logging deleted jetty-loggin.properties file

gregw · 2016-09-16T04:14:40Z

@meltsufin I've been looking at the cloud logging API and have a number of questions: about it should be used in the Flex environment; and how we would like to set it up.

So firstly, we need to know how traceid should be added to a LogEntry? I assume it is something like entry.addLabel("traceid",traceid); but it would be good to have this confirmed (and in any documentation of the contract that is being developed).

Having added a traceid, it is not clear if that is sufficient, or if we should also add a HttpRequest to the log entry? While this can be done, I'm hoping that it is not necessary, as it appears to be redundant information with what is available via the trace id?

So is there somebody we can talk to who can assist with these questions? if not, we can just experiment, but as the console is a moving target that may not be productive.

Eitherway, we are going to need to add scoping information ( traceid and/or httprequest ) to every LogEntry generated. This is easy enough to do, but there are many options for doing so:

We could write a Jetty specific log sink, that has a ThreadLocal scope, so that all jetty logs would be sent to the cloud API with the addition of scope information. Currently the compat image has listeners that maintain a logging scope, so we would have to do a similar listener in jetty-runtime that maintains request specific logging scope. However, this would only work for jetty logging and we would not be able to plumb other logging into it.
The cloud logging comes with a java.util.logging.Handler(JUL), which would be a more portable way to plug into the cloud logging. We would need to extend the libraries handler so we could override the entryFor method to implement a request scope as above. Jetty logging would then be piped into (JUL). Any other application logging frameworks could also be optionally piped to JUL.
The need for a scoping traceid and/or HttpRequest is probably sufficiently generic that would could make a pull request back to google-cloud-java. This would put the ThreadLocal code into the API code, but we would still need to create listeners to maintain the request scope.

I believe we should initially develop option 2., but with the intention of donating the log context code back to the API project once we happy it is fit for purpose.

Finally, I assume we should be doing this logging using the async writer option?

meltsufin · 2016-09-16T14:31:53Z

The trace id should be read from the x-cloud-trace-context HTTP header and provided in the traceId attribute of the log message.
The general structure of the log message should be something like this:

{
    "severity" : <severity code>,
    "timestamp": <timestamp>,
    "message": <log message>,
            "sourceLocation": {
        "filename": <filename>
        "line": <line number>
            }
           "serviceContext": {
                "service": <service name>
                "version": <version identifier, e.g. Git version SHA>
            }
    "traceId" : <trace id>
}

joakime · 2016-09-16T15:01:44Z

@meltsufin i think greg is asking where to put the traceId in the LogEntry object (from the Google Cloud Logging API).

See: https://github.com/GoogleCloudPlatform/google-cloud-java/blob/master/google-cloud-logging/src/main/java/com/google/cloud/logging/LogEntry.java

From my reading of the API, I think greg could use the LogEntry.insertId(String)

meltsufin · 2016-09-16T16:06:28Z

I would think entry.addLabel() should work as Greg mentioned, but insertId() looks promising too. I guess we need to experiment with these.

gregw · 2016-09-16T23:58:05Z

OK I will experiment... my reading of insertId is that is a unique id for the log entry, which is not the traceid as that is shared by many log entries.

I hoping that by the lack of response regarding HttpRequest, that means we don't need to complete that object and associate it with LogEntries.... but I guess experimentation will reveal that.

standby...

gregw · 2016-09-21T05:30:39Z

I'm looking at testing the google logging APIs and the first thing I've noticed is how large the client library and their dependencies are! Over 21MB of jars in the dependencies listed below.

I'm a bit concerned that this represents significant bloat in every image just to do logging! I'm sure the size and scope of these dependencies can be trimmed with maven exclusions, but such an approach is inherently fragile. We also will need to undertake extra efforts to sanitize the container classpath, specially as dependencies such as commons logging are included which have been historically problematic with classloading hiding.

I guess we could use shading and hope that static dependency resolution will be sufficient?

Anyway, just wanted to raise the issue of size early, as the current approach of pulling logs from a known file has the benefit of having the logging code external to the images. Making the images responsible for their own logging is going to result in lots of duplicate code in every instance.

[INFO] \- com.google.cloud:google-cloud:jar:0.3.0:compile
[INFO]    +- com.google.cloud:google-cloud-bigquery:jar:0.3.0:compile
[INFO]    |  \- com.google.apis:google-api-services-bigquery:jar:v2-rev303-1.22.0:compile
[INFO]    |     \- com.google.api-client:google-api-client:jar:1.22.0:compile
[INFO]    +- com.google.cloud:google-cloud-compute:jar:0.3.0:compile
[INFO]    |  \- com.google.apis:google-api-services-compute:jar:v1-rev103-1.21.0:compile
[INFO]    +- com.google.cloud:google-cloud-core:jar:0.3.0:compile
[INFO]    |  +- com.google.auth:google-auth-library-credentials:jar:0.3.1:compile
[INFO]    |  +- com.google.auth:google-auth-library-oauth2-http:jar:0.3.1:compile
[INFO]    |  |  \- com.google.http-client:google-http-client-jackson2:jar:1.19.0:compile
[INFO]    |  |     \- com.fasterxml.jackson.core:jackson-core:jar:2.1.3:compile
[INFO]    |  +- com.google.http-client:google-http-client:jar:1.21.0:compile
[INFO]    |  |  +- com.google.code.findbugs:jsr305:jar:1.3.9:compile
[INFO]    |  |  \- org.apache.httpcomponents:httpclient:jar:4.0.1:compile
[INFO]    |  |     +- org.apache.httpcomponents:httpcore:jar:4.0.1:compile
[INFO]    |  |     +- commons-logging:commons-logging:jar:1.1.1:compile
[INFO]    |  |     \- commons-codec:commons-codec:jar:1.3:compile
[INFO]    |  +- com.google.oauth-client:google-oauth-client:jar:1.21.0:compile
[INFO]    |  +- com.google.guava:guava:jar:19.0:compile
[INFO]    |  +- com.google.api-client:google-api-client-appengine:jar:1.21.0:compile
[INFO]    |  |  +- com.google.oauth-client:google-oauth-client-appengine:jar:1.21.0:compile
[INFO]    |  |  |  +- com.google.oauth-client:google-oauth-client-servlet:jar:1.21.0:compile
[INFO]    |  |  |  |  \- com.google.http-client:google-http-client-jdo:jar:1.21.0:compile
[INFO]    |  |  |  \- javax.servlet:servlet-api:jar:2.5:provided
[INFO]    |  |  +- com.google.api-client:google-api-client-servlet:jar:1.21.0:compile
[INFO]    |  |  |  \- javax.jdo:jdo2-api:jar:2.3-eb:compile
[INFO]    |  |  |     \- javax.transaction:transaction-api:jar:1.1:compile
[INFO]    |  |  \- com.google.http-client:google-http-client-appengine:jar:1.21.0:compile
[INFO]    |  +- com.google.http-client:google-http-client-jackson:jar:1.21.0:compile
[INFO]    |  |  \- org.codehaus.jackson:jackson-core-asl:jar:1.9.11:compile
[INFO]    |  +- joda-time:joda-time:jar:2.9.2:compile
[INFO]    |  +- org.json:json:jar:20151123:compile
[INFO]    |  +- com.google.protobuf:protobuf-java:jar:3.0.0-beta-3:compile
[INFO]    |  +- com.google.api:gax:jar:0.0.16:compile
[INFO]    |  |  \- com.google.inject:guice:jar:4.0:compile
[INFO]    |  |     +- javax.inject:javax.inject:jar:1:compile
[INFO]    |  |     \- aopalliance:aopalliance:jar:1.0:compile
[INFO]    |  \- com.google.api.grpc:grpc-google-common-protos:jar:0.0.7:compile
[INFO]    +- com.google.cloud:google-cloud-datastore:jar:0.3.0:compile
[INFO]    |  +- com.google.cloud.datastore:datastore-v1-protos:jar:1.0.1:compile
[INFO]    |  \- com.google.cloud.datastore:datastore-v1-proto-client:jar:1.1.0:compile
[INFO]    |     \- com.google.http-client:google-http-client-protobuf:jar:1.20.0:compile
[INFO]    +- com.google.cloud:google-cloud-dns:jar:0.3.0:compile
[INFO]    |  +- com.google.apis:google-api-services-dns:jar:v1-rev7-1.21.0:compile
[INFO]    |  \- commons-fileupload:commons-fileupload:jar:1.3.1:compile
[INFO]    |     \- commons-io:commons-io:jar:2.2:compile
[INFO]    +- com.google.cloud:google-cloud-errorreporting:jar:0.3.0:compile
[INFO]    |  +- io.netty:netty-tcnative-boringssl-static:jar:1.1.33.Fork17:compile
[INFO]    |  +- com.google.api.grpc:grpc-google-devtools-clouderrorreporting-v1beta1:jar:0.0.7:compile
[INFO]    |  +- io.grpc:grpc-all:jar:0.15.0:compile
[INFO]    |  |  +- io.grpc:grpc-auth:jar:0.15.0:compile
[INFO]    |  |  +- io.grpc:grpc-netty:jar:0.15.0:compile
[INFO]    |  |  |  \- io.netty:netty-codec-http2:jar:4.1.1.Final:compile (version selected from constraint [4.1.1.Final,4.1.1.Final])
[INFO]    |  |  |     +- io.netty:netty-codec-http:jar:4.1.1.Final:compile
[INFO]    |  |  |     |  \- io.netty:netty-codec:jar:4.1.1.Final:compile
[INFO]    |  |  |     \- io.netty:netty-handler:jar:4.1.1.Final:compile
[INFO]    |  |  |        +- io.netty:netty-buffer:jar:4.1.1.Final:compile
[INFO]    |  |  |        |  \- io.netty:netty-common:jar:4.1.1.Final:compile
[INFO]    |  |  |        \- io.netty:netty-transport:jar:4.1.1.Final:compile
[INFO]    |  |  |           \- io.netty:netty-resolver:jar:4.1.1.Final:compile
[INFO]    |  |  +- io.grpc:grpc-okhttp:jar:0.15.0:compile
[INFO]    |  |  |  +- com.squareup.okio:okio:jar:1.6.0:compile
[INFO]    |  |  |  \- com.squareup.okhttp:okhttp:jar:2.5.0:compile
[INFO]    |  |  +- io.grpc:grpc-protobuf-nano:jar:0.15.0:compile
[INFO]    |  |  |  \- com.google.protobuf.nano:protobuf-javanano:jar:3.0.0-alpha-5:compile
[INFO]    |  |  +- io.grpc:grpc-stub:jar:0.15.0:compile
[INFO]    |  |  +- io.grpc:grpc-protobuf:jar:0.15.0:compile
[INFO]    |  |  |  \- com.google.protobuf:protobuf-java-util:jar:3.0.0-beta-3:compile
[INFO]    |  |  |     \- com.google.code.gson:gson:jar:2.3:compile
[INFO]    |  |  +- io.grpc:grpc-protobuf-lite:jar:0.15.0:compile
[INFO]    |  |  \- io.grpc:grpc-core:jar:0.15.0:compile (version selected from constraint [0.15.0,0.15.0])
[INFO]    |  \- com.google.auto.value:auto-value:jar:1.1:compile
[INFO]    +- com.google.cloud:google-cloud-language:jar:0.3.0:compile
[INFO]    |  \- com.google.api.grpc:grpc-google-cloud-language-v1beta1:jar:0.0.7:compile
[INFO]    +- com.google.cloud:google-cloud-logging:jar:0.3.0:compile
[INFO]    |  \- com.google.api.grpc:grpc-google-logging-v2:jar:0.0.7:compile
[INFO]    +- com.google.cloud:google-cloud-pubsub:jar:0.3.0:compile
[INFO]    |  \- com.google.api.grpc:grpc-google-pubsub-v1:jar:0.0.7:compile
[INFO]    +- com.google.cloud:google-cloud-resourcemanager:jar:0.3.0:compile
[INFO]    |  \- com.google.apis:google-api-services-cloudresourcemanager:jar:v1beta1-rev10-1.21.0:compile
[INFO]    +- com.google.cloud:google-cloud-speech:jar:0.3.0:compile
[INFO]    |  \- com.google.api.grpc:grpc-google-cloud-speech-v1beta1:jar:0.0.7:compile
[INFO]    +- com.google.cloud:google-cloud-storage:jar:0.3.0:compile
[INFO]    |  \- com.google.apis:google-api-services-storage:jar:v1-rev62-1.21.0:compile
[INFO]    +- com.google.cloud:google-cloud-trace:jar:0.3.0:compile
[INFO]    |  \- com.google.api.grpc:grpc-google-devtools-cloudtrace-v1:jar:0.0.7:compile
[INFO]    +- com.google.cloud:google-cloud-translate:jar:0.3.0:compile
[INFO]    |  \- com.google.apis:google-api-services-translate:jar:v2-rev47-1.22.0:compile
[INFO]    \- com.google.cloud:google-cloud-vision:jar:0.3.0:compile
[INFO]       \- com.google.api.grpc:grpc-google-cloud-vision-v1:jar:0.0.7:compile

joakime · 2016-09-21T13:41:31Z

21MB is a pittance in today's world. That's only 30% of the size of your average web page today! (60MB is the average amount of content a single web page downloads in 2016)

That being said, there's seems to be a few obvious things in that list of dependencies that really are not needed to do logging.

My take on not needed deps (for features in google cloud that are not logging):

[INFO]    +- com.google.cloud:google-cloud-bigquery:jar:0.3.0:compile
[INFO]    |  \- com.google.apis:google-api-services-bigquery:jar:v2-rev303-1.22.0:compile
[INFO]    |     \- com.google.api-client:google-api-client:jar:1.22.0:compile
[INFO]    +- com.google.cloud:google-cloud-compute:jar:0.3.0:compile
[INFO]    |  \- com.google.apis:google-api-services-compute:jar:v1-rev103-1.21.0:compile
[INFO]    +- com.google.cloud:google-cloud-datastore:jar:0.3.0:compile
[INFO]    |  +- com.google.cloud.datastore:datastore-v1-protos:jar:1.0.1:compile
[INFO]    |  \- com.google.cloud.datastore:datastore-v1-proto-client:jar:1.1.0:compile
[INFO]    |     \- com.google.http-client:google-http-client-protobuf:jar:1.20.0:compile
[INFO]    +- com.google.cloud:google-cloud-dns:jar:0.3.0:compile
[INFO]    |  +- com.google.apis:google-api-services-dns:jar:v1-rev7-1.21.0:compile
[INFO]    |  \- commons-fileupload:commons-fileupload:jar:1.3.1:compile
[INFO]    |     \- commons-io:commons-io:jar:2.2:compile
[INFO]    +- com.google.cloud:google-cloud-speech:jar:0.3.0:compile
[INFO]    |  \- com.google.api.grpc:grpc-google-cloud-speech-v1beta1:jar:0.0.7:compile
[INFO]    +- com.google.cloud:google-cloud-storage:jar:0.3.0:compile
[INFO]    |  \- com.google.apis:google-api-services-storage:jar:v1-rev62-1.21.0:compile
[INFO]    +- com.google.cloud:google-cloud-trace:jar:0.3.0:compile
[INFO]    |  \- com.google.api.grpc:grpc-google-devtools-cloudtrace-v1:jar:0.0.7:compile
[INFO]    +- com.google.cloud:google-cloud-translate:jar:0.3.0:compile
[INFO]    |  \- com.google.apis:google-api-services-translate:jar:v2-rev47-1.22.0:compile
[INFO]    \- com.google.cloud:google-cloud-vision:jar:0.3.0:compile
[INFO]       \- com.google.api.grpc:grpc-google-cloud-vision-v1:jar:0.0.7:compile

and two that feel like they are possible not needed:

[INFO]    +- com.google.cloud:google-cloud-language:jar:0.3.0:compile
[INFO]    |  \- com.google.api.grpc:grpc-google-cloud-language-v1beta1:jar:0.0.7:compile

remove XML reference

* Issue #4 removed unused JUL file * Issue #4 removed unused JUL file remove XML reference

bbassingthwaite · 2016-11-04T17:42:29Z

@gregw Did you ever figure out where to put the traceId in your LogEntry? Thanks!

meltsufin · 2017-07-24T13:45:15Z

Fxed in #81

meltsufin mentioned this issue Sep 7, 2016

Logging Rotation and Levels Manual Merge #2

Closed

This was referenced Sep 8, 2016

Make app logging available via request log - 13170 GoogleCloudPlatform/appengine-java-vm-runtime#318

Closed

Make Jetty and Jetty compat do log rotations GoogleCloudPlatform/appengine-java-vm-runtime#231

Open

gregw mentioned this issue Sep 8, 2016

Health check logging levels based on error GoogleCloudPlatform/appengine-java-vm-runtime#282

Closed

gregw self-assigned this Sep 9, 2016

gregw added a commit to jetty-project/gcloud-jetty-runtime that referenced this issue Sep 14, 2016

Issue GoogleCloudPlatform#4 revert to default jetty logging

96d9036

gregw added a commit to jetty-project/gcloud-jetty-runtime that referenced this issue Sep 14, 2016

Issue GoogleCloudPlatform#4 revert to default jetty logging

39f4328

added google copyright

gregw added a commit to jetty-project/gcloud-jetty-runtime that referenced this issue Sep 14, 2016

Issue GoogleCloudPlatform#4 Revert to default jetty logging

5696164

gregw mentioned this issue Sep 14, 2016

Updated async-rest demo to latest Flex GoogleCloudPlatform/java-docs-samples#338

Merged

gregw added a commit to jetty-project/gcloud-jetty-runtime that referenced this issue Sep 14, 2016

Issue GoogleCloudPlatform#4 Revert to default jetty logging

ec10664

deleted jetty-loggin.properties file

gregw added a commit that referenced this issue Sep 15, 2016

Issue #4 Revert to default jetty logging (#19)

46e13ff

* Issue #4 Revert to default jetty logging * Issue #4 Revert to default jetty logging deleted jetty-loggin.properties file

gregw added a commit that referenced this issue Sep 27, 2016

Issue #4 removed unused JUL file

e56468c

gregw mentioned this issue Sep 27, 2016

Issue #4 removed unused JUL file #55

Merged

gregw added a commit that referenced this issue Sep 28, 2016

Issue #4 removed unused JUL file

6bf442f

remove XML reference

gregw added a commit that referenced this issue Sep 28, 2016

Issue #4 removed unused JUL file (#55)

8500b2e

* Issue #4 removed unused JUL file * Issue #4 removed unused JUL file remove XML reference

joakime mentioned this issue Oct 12, 2016

Ensure Jetty request logging doesn't fill up disk space #60

Closed

meltsufin closed this as completed Jul 24, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Logging using the Google Cloud Logging API #4

Logging using the Google Cloud Logging API #4

meltsufin commented Sep 7, 2016 •

edited

Loading

gregw commented Sep 7, 2016

joakime commented Sep 8, 2016

joakime commented Sep 8, 2016

gregw commented Sep 8, 2016

meltsufin commented Sep 9, 2016

joakime commented Sep 9, 2016

meltsufin commented Sep 9, 2016

joakime commented Sep 9, 2016

gregw commented Sep 9, 2016

meltsufin commented Sep 12, 2016

gregw commented Sep 16, 2016

meltsufin commented Sep 16, 2016

joakime commented Sep 16, 2016

meltsufin commented Sep 16, 2016

gregw commented Sep 16, 2016

gregw commented Sep 21, 2016

joakime commented Sep 21, 2016

bbassingthwaite commented Nov 4, 2016

meltsufin commented Jul 24, 2017

Logging using the Google Cloud Logging API #4

Logging using the Google Cloud Logging API #4

Comments

meltsufin commented Sep 7, 2016 • edited Loading

gregw commented Sep 7, 2016

joakime commented Sep 8, 2016

joakime commented Sep 8, 2016

gregw commented Sep 8, 2016

meltsufin commented Sep 9, 2016

joakime commented Sep 9, 2016

meltsufin commented Sep 9, 2016

joakime commented Sep 9, 2016

Option 1: Standard Jetty Logging

Option 2: Jetty uses java.util.logging

gregw commented Sep 9, 2016

meltsufin commented Sep 12, 2016

gregw commented Sep 16, 2016

meltsufin commented Sep 16, 2016

joakime commented Sep 16, 2016

meltsufin commented Sep 16, 2016

gregw commented Sep 16, 2016

gregw commented Sep 21, 2016

joakime commented Sep 21, 2016

bbassingthwaite commented Nov 4, 2016

meltsufin commented Jul 24, 2017

meltsufin commented Sep 7, 2016 •

edited

Loading