How to access to Google AppEngine Managed VM logs?

Question

I am trying out Managed VMs Beta from Google AppEngine and while it runs locally in my IDE with the AppEngine dev server, I cannot seem to make it run with mvn appengine:gcloud_app_run.

I consistently and forever get:

"[INFO] INFO: default: "GET /_ah/health?IsLastSuccessful=no HTTP/1.1" 503 298"

And thus need to access the logs outputted in the docker container to diagnose that 503.

I have activated logging with the following line in the appengine-maven-plugin configuration section (works great within the IDE).

<gcloud_app_enable_mvm_logs>true</gcloud_app_enable_mvm_logs>

Then I tried accessing the logs from the docker container with:

➜  ~  docker ps                                                                       
CONTAINER ID        IMAGE                                                       COMMAND                CREATED             STATUS              PORTS                     NAMES
76369bc9b773        heimdall-dev.default.1:latest                               "/home/vmagent/jetty   5 seconds ago       Up 4 seconds        0.0.0.0:49174->8080/tcp   google.appengine.heimdall-dev.default.1.0.2014-11-13T210256.776274Z 

➜  ~  docker logs 76369bc9b773
Info: Limiting Java heap size to: 1456M
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=64M; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=166M; support was removed in 8.0
2014-11-13 21:02:59.384:INFO::main: Logging initialized @372ms
2014-11-13 21:02:59.487:INFO::main: Redirecting stderr/stdout to /var/log/app_engine/STDERR.2014_11_13.log//var/log/app_engine/STDOUT.2014_11_13.log

So I expected the log files to be "magically" mapped to the local /var folder on my local machine (i.e. outside of the docker container`. However it seems not to be it:

➜  ~  tail -f /var/log/app_engine/STDERR.2014_11_13.log
tail: /var/log/app_engine/STDERR.2014_11_13.log: No such file or directory
➜  ~  tail -f /var/log/app_engine/STDOUT.2014_11_13.log
tail: /var/log/app_engine/STDOUT.2014_11_13.log: No such file or directory

Is it the right way to do so? If yes, what am I missing? Else what is the right way to access the logs?

P.S.: I also tried ssh-ing into the docker container with docker attach 76369bc9b773 but this consistently returned me an error.

P.S.2: my app is a "basic" Spring MVC+Security+Social+DataJPA over Java 8, so I guess there is a glitch with the bean initialization that does not happen in IDE+GAE Dev Server somehow

P.S.3: I followed the tutorial here: https://github.com/GoogleCloudPlatform/appengine-java-vm-guestbook-extras and got stage 3 to run properly with mvn appengine:gcloud_app_run

P.S.4: to make my app run in the IDE, since I am using Spring MVC, I had to implement my own /_ah/start endpoint (inspired from Google App Engine Localhost Backend Error and No mapping found using Spring3 MVC + Maven2 on GAE) however I am unsure whether or not that is the right thing to do

P.S.5: I had a look at the admin console running on port 8000, and the logs there are just the same as the one in the shell (i.e. not much else than the HTTP 503 message)

Answer 1

Just as a completion to your initial answer @Nicolas, I've created a small shell script that will

1. Builds the project
2. Launch docker
3. Launch a console that will show the latest logs
4. Launch the gcloud preview app command

I'm sharing the .sh file with you now:

#!/bin/sh
mvn clean install   #build via MAVEN
boot2dockerstatus=$( boot2docker status )
echo $boot2dockerstatus
if [ $boot2dockerstatus != 'running' ]
    then
        boot2docker start
        boot2docker status
fi
open http://localhost:8080


#ADD logs debugging on a separate window (MacOSx only) !! 
osascript -e 'tell app "Terminal"
    do script "cd /var/log/app_engine/; tail -F *.log"
end tell'

gcloud --verbosity debug preview app run --enable-mvm-logs "./target/<your-project-build-name-here>" 

Answer 2

I finally managed to access logs of the appengine VM using volumes of docker. And hacking a file of the google-cloud-sdk after browsing the python code.

However, since I am working on Mac OS X, some extra things where needed because of the VirtualBox layer in between the OS and docker, as described here: http://viget.com/extend/how-to-use-docker-on-os-x-the-missing-guide

So, below are the commands I ran.

1 - stop all docker containers if necessary:

➜  ~ docker stop $(docker ps -a -q)

2 - remove all docker containers if necessary:

➜  ~ docker rm $(docker ps -a -q)

3 - stop the boot2docker VirtualBox VM:

➜  ~ boot2docker down

4 - create the directory where you want it mapped on your local machine (make sure it is one where you have read/write permissions without needing to sudo):

➜  ~ mkdir -p ~/var/log/app_engine

5 - mount the directory into the boot2docker VirtualBox VM:

➜  ~ VBoxManage sharedfolder add boot2docker-vm -name var -hostpath ~/var/log/app_engine

6 - start the boot2docker VirtualBox VM:

➜  ~ boot2docker up

7 - edit line 266 of file google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/vm_runtime_proxy.py

265    external_logs_path = os.path.join(
266        '/var/log/app_engine',
267        self._escape_domain(

with the path to the sharedfolder, in my case:

265    external_logs_path = os.path.join(
266        '/Users/nicolas/var/log/app_engine',
267        self._escape_domain(

8 - run the app:

➜  ~ mvn appengine:gcloud_app_run

9 - check the logs are there:

➜  ~  ls ~/var/log/app_engine/heimdall-dev/default/1/0/
STDERR.2014_11_16.log   STDOUT.2014_11_16.log   app.0.log.json          app.0.log.json.1        app.0.log.json.1.lck    app.0.log.json.2        app.0.log.json.2.lck    app.0.log.json.lck      request.2014_11_16.log

Not exactly straightforward and easy...

It must be possible to make the default /var/mog/app_engine local folder available to the VirtualBox VM by changing the permissions and thus there would be no need to hack into google-cloud-sdk python files. However, I haven't had the time to test that yet. I'll update the answer when I get to test that.