Reading and Writing Application Logs

Python |Java |PHP |Go

Overview

When a request is sent to your app, a request log is automatically written by App Engine. During the handling of the request, your app can also write application logs. In this page, you'll learn how to write application logs from your application, how to read both application and request logs programmatically using the Logs API, how to view logging in the Google Cloud Platform Console, and how to understand the request log data that App Engine writes during the request. To view the contents of the logs package, see the logs package reference.

Request logs vs application logs

There are two categories of log data: request logs and application logs. A request log is automatically written by App Engine for each request handled by your app, and contains information such as the project ID, HTTP version, and so forth. For a complete list of available properties for request logs, see Record. See also the request log table for descriptions of the request log fields.

Each request log contains a list of application logs (AppLog) associated with that request, returned in the Record.AppLog field. Each app log contains the time the log was written, the log message, and the log level.

Note: A request log can only hold 1000 app logs. If you add more than 1000, the older logs will not be retained.

Writing application logs

Important: Individual log entries from an application have an 8KB limit. Nothing beyond this limit will be written to the app log.

The App Engine Go SDK allows a developer to log the following levels of severity:

• Debug
• Warning
• Info
• Error
• Critical

The following snippet shows how to write log entries:

import (
	"net/http"

	"google.golang.org/appengine"
	"google.golang.org/appengine/datastore"
	"google.golang.org/appengine/log"
)

func logHandler(w http.ResponseWriter, r *http.Request) {
	ctx := appengine.NewContext(r)

	post := &Post{Body: "sample post"}
	key := datastore.NewIncompleteKey(ctx, "Posts", nil)
	if _, err := datastore.Put(ctx, key, post); err != nil {
		log.Errorf(ctx, "could not put into datastore: %v", err)
		http.Error(w, "An error occurred. Try again.", http.StatusInternalServerError)
		return
	}
	log.Debugf(ctx, "Datastore put successful")

	w.Write([]byte("ok!"))
}

Reading logs via API

Note: The Logs API only generates output for deployed apps.

The general process of getting logs using the Logs API is as follows:

1. Create a Query value that specifies which logs to return.
2. Call the Run method to obtain a Result iterator.
3. Repeatedly call the Next method to obtain Record values.

Sample code

The following sample displays 5 request logs at at time, along with their application logs. It lets you cycle through each set of logs using a Next link.

// This sample gets the app displays 5 log Records at a time, including all
// AppLogs, with a Next link to let the user page through the results using the
// Record's Offset property.
package app

import (
	"encoding/base64"
	"html/template"
	"net/http"

	"google.golang.org/appengine"
	"google.golang.org/appengine/log"
)

func init() {
	http.HandleFunc("/", handler)
}

const recordsPerPage = 5

func handler(w http.ResponseWriter, r *http.Request) {
	ctx := appengine.NewContext(r)

	// Set up a data structure to pass to the HTML template.
	var data struct {
		Records []*log.Record
		Offset  string // base-64 encoded string
	}

	// Set up a log.Query.
	query := &log.Query{AppLogs: true}

	// Get the incoming offset param from the Next link to advance through
	// the logs. (The first time the page is loaded there won't be any offset.)
	if offset := r.FormValue("offset"); offset != "" {
		query.Offset, _ = base64.URLEncoding.DecodeString(offset)
	}

	// Run the query, obtaining a Result iterator.
	res := query.Run(ctx)

	// Iterate through the results populating the data struct.
	for i := 0; i < recordsPerPage; i++ {
		rec, err := res.Next()
		if err == log.Done {
			break
		}
		if err != nil {
			log.Errorf(ctx, "Reading log records: %v", err)
			break
		}

		data.Records = append(data.Records, rec)
		if i == recordsPerPage-1 {
			data.Offset = base64.URLEncoding.EncodeToString(rec.Offset)
		}
	}

	// Render the template to the HTTP response.
	if err := tmpl.Execute(w, data); err != nil {
		log.Errorf(ctx, "Rendering template: %v", err)
	}
}

var tmpl = template.Must(template.New("").Parse(`
	{{range .Records}}
		<h2>Request Log</h2>
		<p>{{.EndTime}}: {{.IP}} {{.Method}} {{.Resource}}</p>
		{{with .AppLogs}}
			<h3>App Logs:</h3>
			<ul>
			{{range .}}
				<li>{{.Time}}: {{.Message}}</li>
			<{{end}}
			</ul>
		{{end}}
	{{end}}
	{{with .Offset}}
		<a href="?offset={{.}}">Next</a>
	{{end}}
`))

In the sample, notice that the GET handler expects to be re-invoked by the user clicking on the Next link, and so it extracts the offset param, if present. That offset is used in the subsequent re-invocation of log.Query.Run to "page through" each group of 5 request logs. There is nothing special about the number 5; it can be anything you want.

Log URL format in the Google Cloud Platform Console

See the following sample URL for an example of the log URL format in the Cloud Platform Console:

https://console.cloud.google.com/logs?filters=request_id:000000db00ff00ff827e493472570001737e73686966746361727331000168656164000100

Note: The URL no longer includes the filter_type.

Reading logs in the console

Note: the logs described here are shown as visible in the Log Viewer.

To view logs using the Log Viewer:

1. In the Cloud Platform Console, go to the logs for your project.

2. Use the desired filter to retrieve the logs you want to see. You can filter by various combinations of time, log level, module, and log filter label or regular expression.

   Notice that labels are regular expressions for filtering the logs by logging fields. Valid labels include the following:

   • day
   • month
   • year
   • hour
   • minute
   • second
   • tzone
   • remotehost
   • identd_user
   • user
   • status
   • bytes
   • referrer
   • useragent
   • method
   • path
   • querystring
   • protocol
   • request_id

   For example, path:/foo.* useragent:.*Chrome.* gets logs for all requests to a path starting with /foo that were issued from a Chrome browser.

A typical App Engine log contains data in the Apache combined log format, along with some special App Engine fields, as shown in the following sample log:

192.0.2.0 - test [27/Jun/2014:09:11:47 -0700] "GET / HTTP/1.1" 200 414
"http://www.example.com/index.html"
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36"
"1-dot-calm-sylph-602.appspot.com" ms=195 cpu_ms=42 cpm_usd=0.000046
loading_request=1 instance=00c61b117cfeb66f973d7df1b7f4ae1f064d app_engine_release=1.9.54

Understanding request log fields

The following table lists the fields in order of occurrence along with a description:

Field Order	Field Name	Always Present?	Description
1	Client address	Yes	Client IP address. Example: 192.0.2.0
2	RFC1413 identity	No	RFC1413 identity of the client. This is nearly always the character -
3	User	No	Present only if the app uses the Users API and the user is logged in. This value is the "nickname" portion of the Google Account, for example, if the Google Account is [e-mail], the nickname that is logged in this field is test.
4	Timestamp	Yes	Request timestamp. Example: [27/Jun/2014:09:11:47 -0700]
5	Request querystring	Yes	First line of the request, containing method, path, and HTTP version. Example: GET / HTTP/1.1
6	HTTP Status Code	Yes	Returned HTTP status code. Example: 200
7	Response size	Yes	Response size in bytes. Example: 414
8	Referrer path	No	If there is no referrer, the log contains no path, but only -. Example referrer path: "http://www.example.com/index.html".
9	User-agent	Yes	Identifies the browser and operating system to the web server. Example: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
10	Hostname	Yes	The hostname used by the client to connect to the App Engine application. Example : (1-dot-calm-sylph-602.appspot.com)
11	Wallclock time	Yes	Total clock time in milliseconds spent by App Engine on the request. This time duration does not include time spent between the client and the server running the instance of your application. Example: ms=195.
12	CPU milliseconds	Yes	CPU milliseconds required to fulfill the request. This is the number of milliseconds spent by the CPU actually executing your application code, expressed in terms of a baseline 1.2 GHz Intel x86 CPU. If the CPU actually used is faster than the baseline, the CPU milliseconds can be larger than the actual clock time defined above. Example: cpu_ms=42
13	Exit code	No	Only present if the instance shut down after getting the request. In the format exit_code=XXX where XXX is a 3 digit number corresponding to the reason the instance shut down. The exit codes are not documented since they are primarily intended to help Google spot and fix issues.
14	Estimated cost	Yes	DEPRECATED. Estimated cost of 1000 requests just like this one, in USD. Example: cpm_usd=0.000046
15	Queue name	No	The name of the task queue used. Only present if request used a task queue. Example: queue_name=default
16	Task name	No	The name of the task executed in the task queue for this request. Only present if the request resulted in the queuing of a task. Example: task_name=7287390692361099748
17	Pending queue	No	Only present if a request spent some time in a pending queue. If there are many of these in your logs and/or the values are high, it might be an indication that you need more instances to serve your traffic. Example: pending_ms=195
18	Loading request	No	Only present if the request is a loading request. This means an instance had to be started up. Ideally, your instances should be up and healthy for as long as possible, serving large numbers of requests before being recycled and needing to be started again. Which means you shouldn't see too many of these in your logs. Example: loading_request=1.
19	Instance	Yes	Unique identifier for the instance that handles the request. Example: instance=00c61b117cfeb66f973d7df1b7f4ae1f064d
20	Version	Yes	The current App Engine release version used in production App Engine: 1.9.54

Quotas and limits

Your application is affected by the following logs-related quotas:

• Logs data retrieved via the Logs API.
• Log ingestion allotment and retention.

Quota for data retrieved

The first 100 megabytes of logs data retrieved per day via the Logs API calls are free. After this amount is exceeded, no further Logs API calls will succeed unless billing is enabled for your app. If billing is enabled for your app, data in excess of 100 megabytes results in charges of $0.12/GB.

Logs ingestion allotment

Logging for App Engine apps is provided by Stackdriver. By default, logs are stored for an application free of charge for up to 7 days and 5GB. Logs older than the maximum retention time are deleted, and attempts to store above the free ingestion limit of 5 gigabytes will result in an error. You can update to the Premium Tier for greater storage capacity and retention length. See Stackdriver pricing for more information on logging rates and limits. If you want to retain your logs for longer than what Stackdriver allows, you can export logs to Google Cloud Storage, Google BigQuery, or Google Cloud Pub/Sub.

The development server and Logs API

By default, logs are stored in memory only in the development server and are accessible if you wish to test the Logs API feature. If you wish to persist logs from the development server to disk at the default location /tmp/dev_appserver.logs, supply the --persist_logs command line option as follows:

dev_appserver.py --persist_logs your-app-directory

If you wish to persist the logs from the development server to disk at a location of your own choosing, supply the desired path and filename to the --logs_path command line option as follows:

dev_appserver.py --logs_path=your-path/your-logfile-name your-app-directory