Writing runtime logs
Cloud Functions includes simple runtime logging by default. Logs written to stdout
or
stderr
will appear automatically in the
Cloud Console.
For more advanced logging, use the
Cloud Logging Client Libraries.
As a default, the log payload is a simple text string, as shown in the following
snippets. This string is stored in textPayload
.
Node.js
Most log entries do not have an associated log level. These include:- Logs emitted using
console.log()
,console.info()
,console.warn()
orconsole.error()
- Logs written directly to
stdout
orstderr
Internal system messages have the DEBUG
log level.
Python
- Logs to standard output or standard error do not have an associated log level.
- Internal system messages have the
DEBUG
log level.
Go
- Logs to
stdout
orstderr
do not have an associated log level. - Internal system messages have the
DEBUG
log level.
Java
- Logs to
stdout
orstderr
do not have an associated log level. - Internal system messages have the
DEBUG
log level.
C#
- Text written to
stdout
(for example, viaConsole.WriteLine
) andstderr
(for example, viaConsole.Error.WriteLine
) do not have a log level. - ASP.NET Core logging levels are mapped to Cloud Logging levels as follows:
LogLevel.Trace
andLogLevel.Debug map
to Cloud LoggingDEBUG
.LogLevel.Information
maps to Cloud LoggingINFO
.LogLevel.Warning
maps to Cloud LoggingWARNING
.LogLevel.Error
maps to Cloud LoggingERROR
.LogLevel.Critical
maps to Cloud LoggingCRITICAL
.
Ruby
Log entries do not have an associated log level.
Writing structured logs
The default text logs described above do not have an associated log level.
If you want to include log levels, or other specific fields, in your log entries,
you can use structured data instead, in the form of a single line of serialized JSON.
This line is picked up and parsed by Cloud Logging and is placed into
jsonPayload
instead of textPayload
. The data is constructed as a JSON dictionary.
The snippets below demonstrate creating these log entries.
Node.js
Python
Structured logging support is available in Python 3.8 and later.
Go
The structure for each log entry is provided by an Entry
type:
When an Entry struct is logged, the String
method is called to marshal it to
the JSON format expected by Cloud Logging:
Java
Enable JSON logging with Logback and SLF4J
by enabling the Logstash JSON Encoder
in your logback.xml
configuration.
Processing special JSON fields in messages
When you provide structured data as a JSON dictionary, some special fields are
stripped from the jsonPayload
and are written to the corresponding field in
the generated LogEntry
, as
described in the documentation for special fields.
For example, if your JSON includes a severity
property, it is removed from the
jsonPayload
and appears instead as the log entry's severity
. The message
property is used as the main display text of the log entry if present.
Viewing runtime logs
Using the command-line tool
Logs for Cloud Functions are viewable in the Cloud Logging UI, and
via the gcloud
command-line tool.
To view logs with the gcloud
tool, use the
logs read
command:
gcloud functions logs read
To view the logs for a specific function, provide the function name as an argument:
gcloud functions logs read FUNCTION_NAME
You can even view the logs for a specific execution:
gcloud functions logs read FUNCTION_NAME --execution-id EXECUTION_ID
For the full range of log viewing options, view the help for logs read
:
gcloud functions logs read --help
Using the Logging dashboard
You can also view runtime logs for Cloud Functions from the Cloud Console.
Using the Logging API
Runtime logs can also be written and retrieved through the Cloud Logging API. The Cloud Logging Client Libraries provide an idiomatic interface to the Logging API:
Node.js
For more information, see the Node.js Client Library reference.Python
For more information, see the Python Client Library reference.Go
For more information, see the Go Client Library reference.Java
For more information, see the Java Client Library reference.C#
Ruby
For additional logging options for Java, see Java Logging.
Responding to runtime logs
You can respond to Cloud Logging events by forwarding their logs to a Cloud Function. For more information, see the Second-Party Triggers with Cloud Logging page.
Viewing build image logs
You can also see the logs for the build image step of the deployment process. Follow the link for more information.