This page describes the logs available when using Cloud Run, and how to view and write logs.
Cloud Run has three types of logs, and these are automatically sent to Cloud Logging:
- Request logs (services only): logs of requests sent to Cloud Run services. These logs are created automatically.
- Container logs (services and jobs): logs emitted from the instances, typically from your own code, written to supported locations as described in Writing container logs.
- System logs (services and jobs): platform-generated logs containing information about
your services and jobs. These logs are written to
varlog/system
.
View logs
You can view logs for your service or job in several ways:
- Use the Cloud Run page in the Google Cloud console
- Use Google Cloud CLI to view logs using gcloud (services only)
- Use Cloud Logging Logs Explorer in the Google Cloud console
- Use Cloud Code
Both of the console methods of viewing logs examine the same logs stored in Cloud Logging, but the Cloud Logging Logs Explorer provides more details and more filtering capabilities.
View logs in Cloud Run
You can view logs for services and jobs in the corresponding service and jobs pages.
View logs for a service
To view service logs in the Cloud Run page:
Click the desired service in the displayed list.
Click the LOGS tab to get the request and container logs for all revisions of this service. You can filter by log severity level.
View logs for a job
To view job logs in the Cloud Run page:
Click the JOBS tab.
Locate the job in the jobs list, and click on it.
Click the LOGS tab to get the container logs for all executions of this job. You can filter by log severity level.
Alternatively, if you want to see the logs pre-filtered for a specific job execution, click on the job execution and then click the LOGS tab.
View service logs using Google Cloud CLI
You can use Google Cloud CLI to view tailing logs or read existing logs for a Cloud Run service in the command line By default, the logs are formatted in a single-line format optimized for the console.
To tail logs, you need to install the log-streaming
component in
Google Cloud CLI. If the component isn't installed, you will be prompted
to install it when required.
View tailing logs in the command line
For a Cloud Run service, you can tail logs in real-time from your Cloud Run service directly in the command-line:
gcloud beta run services logs tail SERVICE --project PROJECT-ID
Replace
- SERVICE with the name of the Cloud Run service
- PROJECT-ID with the Google Cloud project ID. You can view your
project ID by running the command
gcloud config get-value project
.
Read logs in the command line
For a Cloud Run service, you can read existing logs in either of two ways:
- In a console-optimized format:
gcloud run services logs read SERVICE --limit=10 --project PROJECT-ID
- Directly from Cloud Logging:
gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=SERVICE" --project PROJECT-ID --limit 10
Replace
- SERVICE with the name of the Cloud Run service
- PROJECT-ID with the Google Cloud project ID. You can view your
project ID by running the command
gcloud config get-value project
.
View logs in Cloud Logging
To view your Cloud Run logs in the Cloud Logging Logs Explorer:
Go to the Logs Explorer page in the Google Cloud console:
Select an existing Google Cloud project at the top of the page, or create a new project.
Using the drop-down menus, select the resource Cloud Run Revision for a service, or Cloud Run Job for a job.
For more information, see Using the Logs Explorer.
View service logs in Cloud Code
To view your logs in Cloud Code, read the IntelliJ and Visual Studio Code guides.
Read logs programmatically
If you want to read the logs programmatically, you can use one of these methods:
- Use a log sink to Pub/Sub and a script to pull from Pub/Sub.
- Call the Logging API through the Client Libraries for your programming language.
- Call the Logging API REST endpoints directly.
Understand instance scaling logs
When new instances are started for your service, 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 service. |
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. |
Write container logs
When you write logs from your service or job, they will be picked up automatically by Cloud Logging so long as the logs are written to any of these locations:
- Standard output (
stdout
) or standard error (stderr
) streams - Any files under the
/var/log
directory - syslog (
/dev/log
) - Logs written using Cloud Logging client libraries, which are available for many popular languages
Most developers are expected to write logs using standard output and standard error.
The container logs written to these supported locations are automatically associated with the Cloud Run service, revision, and location, or with the Cloud Run job. Exceptions contained in these logs are captured by and reported in Error Reporting.
The integrated logging balances reliability and resource usage, and should work for most applications. If your application has requirements for higher volume or reliability, we recommend using the Cloud Logging API directly, either as a library within your application or as a separate sidecar container.
Use simple text vs structured JSON in logs
When you write logs, you can send a simple text string or send a single line
of serialized JSON, also called "structured" data. This is picked up and
parsed by Cloud Logging and is placed into jsonPayload
. In
contrast, the simple text message is placed in textPayload
.
Write structured logs
The following snippet shows how to write structured log entries. It also shows how to correlate log messages with the corresponding request log.
Node.js
Python
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.
Customize standard field names to exclude unwanted content from ingestion in the logs payload. For a list of field names and expected data formats see Use the logging agent.
Special JSON fields in messages
When you provide a structured log 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.
For more on special properties read the Logging Resource section
below.
Correlate your container logs with a request log (services only)
In the Logs Explorer, logs correlated by the same trace
are
viewable in "parent-child" format: when you click on the triangle
icon at the left of the request log entry, the container logs related to that
request show up nested under the request log.
Container logs are not automatically correlated to request logs unless you use a
Cloud Logging client library.
To correlate container logs with request logs without using a client library,
you can use a structured JSON log line that contains a
logging.googleapis.com/trace
field with the trace identifier extracted from
the X-Cloud-Trace-Context
header as shown in the above sample for
structured logging.
Control request log resource usage (services only)
Request logs are created automatically. Although you cannot control the amount of request logs directly from Cloud Run, you can make use of the logs exclusion feature from Cloud Logging.
A note about logging agents
If you've used Cloud Logging with certain Google Cloud products, such as Compute Engine, you may have used Cloud Logging logging agents. Cloud Run does not use logging agents because it has built-in support for log collection.
Logging resource names
The logging resource names for Cloud Run are:
- Cloud Run Revision (
cloud_run_revision
). - Cloud Run Job (
cloud_run_job
).
Logging resources
Clicking on a log entry in the Logs Explorer opens up a JSON formatted log entry so you can drill down to the details you want.
All of the fields in a log entry, such as timestamps, severity, and httpRequest
are standard, and are described in the documentation for a
log entry.
Cloud Run adds additional metadata, so you can identify the source of a log. This includes the (labels that you set on your Cloud Run service) and resource labels that are specific to Cloud Run.
Log entry fields for a service
The following is a list of fields that can be found in the log entry for a Cloud Run service:
Field | Values and notes |
---|---|
LogEntry.labels.instanceId |
The instance that handled the request. |
LogEntry.labels. mylabel,LogEntry.labels. mysecondlabel |
The labels that are set by you on the service. |
LogEntry.logName |
Identifies the log, for example, request log, standard error, standard output, etc. |
LogEntry.resource.labels.location |
Identifies the Google Cloud location of the service. |
LogEntry.resource.labels.project_id |
The project the service is deployed to. |
LogEntry.resource.labels.revision_name |
The revision that served the request. |
LogEntry.resource.labels.service_name |
The service that served the request. |
LogEntry.resource.type |
cloud_run_revision . The Cloud Run resource type. |
Here's an example request log entry for a Cloud Run service:
{
httpRequest: {…}
insertId: "5c82b3d1000ece0000000000"
labels: {
instanceId: "00bf4bf00000fb59c906a00000c9e29c2c4e06dce91500000000056008d2b6460f163c0057b97b2345f2725fb2423ee5f0bafd36df887fdb1122371563cf1ff453717282afe000001"
mylabel: "mylabelvalue"
mysecondlabel: "mysecondlabelvalue"
}
logName: "projects/my-project/logs/run.googleapis.com%2Frequests"
receiveTimestamp: "2019-03-08T18:26:25.981686167Z"
resource: {
labels: {
configuration_name: "myservice"
location: "us-central1"
project_id: "my-project"
revision_name: "myservice-00002"
service_name: "myservice"
}
type: "cloud_run_revision"
}
severity: "INFO"
timestamp: "2019-03-08T18:26:25.970397Z"
}
Log entry fields for jobs
The following is a list of fields that can be found in the log entry for a Cloud Run job:
Field | Values and notes |
LogEntry.labels.instanceId | The instance. |
LogEntry.labels.mylabel,
LogEntry.labels.mysecondlabel |
The labels that are set by you on the job. |
LogEntry.logName | Identifies the log, for example, request log, standard error, standard output, etc. |
LogEntry.resource.labels.location | Identifies the Google Cloud location of the service. |
LogEntry.resource.labels.project_id | The project the service is deployed to. |
LogEntry.resource.labels.job_name | The name of the job. |
LogEntry.labels.execution_name | The name of the job execution. |
LogEntry.labels.task_index | The task index. |
LogEntry.labels.task_attempt | How many times this task has been attempted. |
LogEntry.resource.type | cloud_run_job . The Cloud Run resource type.
|