View and write Cloud Run function logs
Writing runtime logs
Cloud Run functions includes simple runtime logging by default. Logs written to stdout
or
stderr
will appear automatically in the
Google 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. The string is stored in the textPayload
field of the log entry.
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.
PHP
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 write logs to stdout
or stderr
in the
form of a single line of serialized JSON. This line is picked up and parsed by
Cloud Run functions and is placed into the jsonPayload
field instead of
textPayload
. The snippets below demonstrate writing such structured logs.
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.
Writing logs using client libraries
Cloud Logging client libraries provide an alternative way to write logs. With these libraries you can use the standard logging mechanisms of your programming language and integrate with various supported logging frameworks. Client libraries also simplify population of the special JSON fields by automatically capturing some information and providing interfaces to appropriately populate the fields.
You can use client libraries to write logs with the Cloud Logging API
synchronously or asynchronously. Some client libraries also support writing
structured logs directly to stdout
or stderr
. Note that if you write logs
asynchronously, unexpected function termination
might result in lost log entries.
Also note that synchronous logging with the Logging API increases
function execution time because it requires waiting for API calls to be
completed.
Viewing runtime logs
Using the command-line tool
Logs for Cloud Run functions are viewable in the Cloud Logging UI, and via the Google Cloud CLI.
To view logs with the gcloud CLI, use the
gcloud functions logs read
command:
gcloud functions logs read --gen2
To view the logs for a specific function, provide the function name as an argument:
gcloud functions logs read FUNCTION_NAME --gen2
For functions in other languages, logs can be correlated
from the same function execution by using the x-cloud-trace-context
request header.
For the full range of log viewing options, see the documentation for
gcloud functions logs read
.
Using the Logging dashboard
You can also view runtime logs for Cloud Run functions in the Google 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
PHP
For additional logging options for Java, see Java Logging.
Understand instance scaling logs
When new instances are started for your function, Cloud Logging
includes log entries under the varlog/system
log name to reflect why each
instance was created. The log entry follows this format:
Starting new instance. Reason: REASON - DESCRIPTION
The following table provides a breakdown of instance descriptions:
Reason | Description |
---|---|
CUSTOMER_MIN_INSTANCE |
Customer-configured minimum instance for the function. |
SCHEDULED |
Instance started due to configured scaling factors (e.g. CPU utilization, request throughput, etc.) and their targets. |
OVERFLOW |
Instance started because no existing capacity was found for current traffic. |
Responding to runtime logs
You can respond to Cloud Logging events by forwarding their logs to a Cloud Run 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.