gcloud beta logging read creates huge log files in .config

[Julian Bunn]

We are trying to migrate from request_logs to the "gcloud beta logging read" system.

When downloading logs using the beta command, we find that simultaneously there are large files being created in:

~/.config/gcloud/logs

For example, downloading logs for our GAE app from yesterday, we have the following file in ~/.config/gcloud/logs/2017.04.05

 12293554288 Apr  5 10:41 01.00.02.690250.log

The file contains entries like this:

2017-04-05 10:35:02,227 INFO     ___FILE_ONLY___   

2017-04-05 10:35:02,228 INFO     ___FILE_ONLY___ responseSize

2017-04-05 10:35:02,228 INFO     ___FILE_ONLY___ :

2017-04-05 10:35:02,228 INFO     ___FILE_ONLY___  '

2017-04-05 10:35:02,228 INFO     ___FILE_ONLY___ 76

2017-04-05 10:35:02,228 INFO     ___FILE_ONLY___ '

2017-04-05 10:35:02,228 INFO     ___FILE_ONLY___ 

How can we prevent the creation of this file when using the beta logging command, or at least reduce its size?

Thanks!

 

[George (Cloud Platform Support)]

Hello Julian, 

We could not reproduce the issue locally. The files in our linux machine’s ~/.config/gcloud/logs directory are reasonably small. 

You may attempt to reduce the size of your file by applying filtering more aggressively. Details on filter setup are to be found on the “Command Line Interface” documentation page. 

Hoping this is of help to you, I remain at your disposal for related questions. 

[Julian Bunn]

Hello,

The size of the files in the ~/.config subdir appear to scale with the number of logs downloaded by the gcloud tool. 

We are downloading a day's worth of logs at a time, for a busy application which produces around 750k log entries per day. 

(Downloading this many log entries takes at least 10 hours with the gcloud tool, which is another problem entirely!)

Right now I am simply deleting the log files created in the .config subdir, after our download job finishes, but this is a rather crude fix!

Thanks,

Julian

--
You received this message because you are subscribed to a topic in the Google Groups "Google App Engine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/8jY242lvAHk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/ae255ffc-6ae9-47d0-afed-428c65911c98%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[George (Cloud Platform Support)]

This is intended behavior: "The gcloud tool creates and stores logs in a log file that you can query, located at $HOME/.config/gcloud/logs. ", as documented at "Tips, Troubleshooting, & Known Issues". 

Do you use the logs in the ~/.config/gcloud/logs directory in any way? 

Do you export logs with the beta command to one of your storage buckets?

[Julian Bunn]

Thanks for the info. We have no use for the gcloud beta logging tool's log files, and would like to disable them.

Right now we are simply deleting them after the command terminates, but we would like to avoid such a heavyweight approach, not to mention the considerable I/O load they cause to our storage.

We are downloading the logs from our GAE application to our own archive server: we do not use Google's storage buckets for that.

--

You received this message because you are subscribed to a topic in the Google Groups "Google App Engine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/8jY242lvAHk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/4a6b5b95-afbd-4cbe-8fde-86380ca70759%40googlegroups.com.

[George (Cloud Platform Support)]

As a first approach, you may try using the --severity=SEVERITY flag, or filter the read entries by using --limit=LIMIT, all this to diminish from start the general volume of logs. 

You may also consider implementing a cron job in Linux, to avoid having to delete unwanted files manually. 

[Julian Bunn]

Isn't the qualifier for the beta logging read command --verbosity (not --severity)?

gcloud beta logging read --limit=1 --verbosity=none

However, when this is used it still produces a log in the ~/.config directory that contains all log level entries, including "INFO" level.

Perhaps I have misunderstood what you are suggesting?

(We are already running cron jobs to process our logs.)

On Wed, Apr 12, 2017 at 1:53 PM, 'George (Cloud Platform Support)' via Google App Engine <google-a...@googlegroups.com> wrote:

As a first approach, you may try using the --severity=SEVERITY flag, or filter the read entries by using --limit=LIMIT, all this to diminish from start the general volume of logs. 

You may also consider implementing a cron job in Linux, to avoid having to delete unwanted files manually. 

--

You received this message because you are subscribed to a topic in the Google Groups "Google App Engine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-appengine/8jY242lvAHk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-appengine+unsubscribe@googlegroups.com.
To post to this group, send email to google-appengine@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/7d05734a-b3d7-45bf-ab9d-1ef9a6eb9231%40googlegroups.com.

[George (Cloud Platform Support)]

Hello Julian,

You are encouraged to create an issue tracker entry at http://issuetracker.google.com/, as this issue deserves the direct attention of the developers. Posting there may speed up the research for an eventual resolution. It is worthwhile providing a good use case, to facilitate in the end the acceptance of the feature request.

[Matthew Bruggeman]

For what it's worth, I'm fairly certain you can also just pipe the logs to /dev/null/

https://unix.stackexchange.com/questions/332019/replace-file-with-hard-link-to-dev-null