-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[#10929] Migrate Task Queue API and Logs API to GCP clients #10930
[#10929] Migrate Task Queue API and Logs API to GCP clients #10930
Conversation
a1bad7e
to
51921f6
Compare
Actually, why not use cloud logging v2 instead?
It's not the I'm referencing https://cloud.google.com/logging/docs/reference/libraries for the java client library |
That's the request object for the protobuf client and has nothing to do here. The log format that we need is very specifically this: https://cloud.google.com/logging/docs/reference/v2/rpc/google.appengine.logging.v1#google.appengine.logging.v1.RequestLog. |
8a85f3b
to
f09a08b
Compare
LogService logService = LogServiceFactory.getLogService(); | ||
private List<LogEntry> getErrorLogs() { | ||
if (Config.isDevServer()) { | ||
// Not supported in dev server |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe just print out a message to console or something equivalent here? So that developers know logs are not supported in dev environment rather than having to hunt down the code here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think printing to console would help. This API is not deliberately used by anyone in production system (cron job doesn't really count as any"one", does it?), and if someone really wants to test this, chances are s/he already knows that this is a GCP-specific feature.
# This indicates whether task queues are active (e.g. items added to task queue will be queued for execution). | ||
# This flag is only used during development mode; in production, task queue will always be active. | ||
# In addition, during development mode, there is no "queueing", i.e. all tasks will be immediately executed. | ||
app.taskqueue.active=true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@damithc once this goes live will need to add lines to build.properties
, just fyi for deployment of v7.10
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No: This flag is only used during development mode
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about app.region
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
app.region
is the other way around: necessary in staging/production but ignored in dev server
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah okay so that's the one that will need to be added then haha
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 💯
Really nice work parsing the logs using the protobuf - tested on staging environment and works well.
I tried to dig and see if there is a way to do it without generating the bindings by hand but could not find anything. Others seemed to have done the same: https://stackoverflow.com/a/59414384/13750147
LogLevel logLevel = currentLog.getLogLevel(); | ||
logLines = reconvertedLog.getLineList(); | ||
} catch (InvalidProtocolBufferException e) { | ||
// TODO |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are we planning on doing here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wkurniawan07 did you intend for this to be done in this PR or separately (i.e. needs some discussion)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure myself what best to do here. If we do a error-level log here, then this log will be part of the next logs compilation, which will also fail because of the same reason. At best we can do a warn-level log here, but let's be real: that's as good as no logs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea I think this will need some discussion and possibly research, maybe settle another time with another PR/issue. We go ahead with what we have for now then
# This is the deployment region of the app. | ||
# For dev server, this could be anything. | ||
# For staging/production server, this must match the region of your GAE application. | ||
app.region=us-central1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. How do I find the region used for the production version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@damithc you can type gcloud app describe --project <project-name>
(replace <project-name
with the project in GAE)
You should see something like this:
authDomain: gmail.com
codeBucket: staging.myapp-1337.appspot.com
defaultBucket: myapp-1337.appspot.com
defaultHostname: myapp-1337.appspot.com
featureSettings:
splitHealthChecks: true
gcrDomain: us.gcr.io
id: myapp-1337
locationId: us-central
name: apps/myapp-1337
servingStatus: SERVING
For teammates, we should be us-central
- so region should be us-central1
(the docs mention that for this region we have to map the name slightly differently):
Note: Two locations, which are called europe-west and us-central in App Engine commands and in the Google Cloud Console, are called europe-west1 and us-central1, respectively, elsewhere in Google documentation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. Thanks both. Will update and deploy again soon.
Fixes #10929
Note: don't be alarmed by the amount of code addition. There is an explanation for that.
In addition, one thing that this PR shows is that separating the services between dev server and staging/production server will be more of a challenge in the future (GAE really did us a favor in this aspect).