In Part 1 of this series, we looked at key Cloud Run metrics you can monitor to ensure the reliability and performance of your serverless containerized workloads. We’ll now explore how you can access those metrics within Cloud Run and Google’s dedicated observability tool, Cloud Monitoring. We’ll also look at several ways you can view and explore logs and traces in the Cloud Run UI and Google Cloud CLI.

Monitored resources, labels, and metric types

Cloud Monitoring automatically collects metrics from different components of Google Cloud-hosted applications and services and separates them into monitored resource types. For example, Cloud SQL emits metrics to Cloud Monitoring from the SQL Database and SQL Database Instance monitored resource types.

Each resource type has a set of dimensions called labels that contextualize incoming metrics to help identify the services or jobs that need your attention. In Cloud Run, the two monitored resource types are Cloud Run Revision and Cloud Run Job. The Cloud Run Revision monitored resource includes the labels:

• project_id
• service_name
• revision_name
• location
• configuration_name

And the Cloud Run Job monitored resource includes:

• project_id
• job_name
• location

Labels facilitate troubleshooting by enabling you to see precisely where an issue is occurring to help identify root causes. With revision labels, for example, you can pinpoint exactly which revision and project is associated with an issue so that you can address and resolve problems, optimize performance, and, when needed, roll back to a revision that is running smoothly.

The next layer of monitoring telemetry Cloud Monitoring collects are metric types, which are data collected from monitored resources. Like monitored resources, some metric types include labels to help further classify and contextualize incoming telemetry. For example, the Cloud Run instance_count metric type includes a state label that can have a value of either active or idle. By using the state label, you can easily see a breakdown of container instances by state for a quick overview. See the documentation for a full list of Cloud Run metric types and their associated labels.

In the next section, we’ll look at how you can collect and visualize metric types for Cloud Run monitored resources.

Collect and visualize Cloud Run metric types

You can view Cloud Run metrics through the Cloud Run UI or within Google’s Cloud Monitoring service. Because Cloud Run is automatically integrated with Cloud Monitoring, no further setup or configuration is required to view metrics in Cloud Run. This means that viewing metrics via the Cloud Run UI is sufficient if you want to quickly see how your revisions and jobs are performing. For more in-depth, advanced filtering options such as custom metric analysis and historical data comparisons, Cloud Monitoring is a better fit.

To view metrics directly within the Cloud Run UI, simply navigate to Cloud Run, select a service in the service list, and click the Metrics tab.

By default, the Cloud Run UI will show you metrics from that service that were received within the last 24 hours. You can view different time frames by clicking on any of the options (one hour, six hours, one day, seven days, or 30 days) available on the top left of the Cloud Run metrics dashboard.

The Cloud Run UI also enables you to view a detailed list of a service’s revisions so that you can track its history and get specific information such as resource limits and current allocation. It also allows you to manage how request traffic is routed across revisions and, if necessary, how to roll back to a previous revision. For instance, if a newly deployed revision experiences performance degradation, bugs, or other issues, you can use the revision list to roll back to a revision with better performance.

While this UI is ideal for quick adjustments and specifically monitoring Cloud Run, Google’s Cloud Monitoring tool provides more advanced options and enables you to view metrics from across several different Google tools.

For example, let’s say you manage a Cloud Run service that processes user-generated content and stores it in a Cloud SQL database. Users report delays during content submission, but the Cloud Run UI doesn’t reveal the issue. A custom dashboard in Cloud Monitoring can help uncover potential root causes by correlating metrics from both Cloud Run and Cloud SQL. For instance, it may show that while Cloud Run’s CPU and memory utilization are normal, request latency spikes align with surges in database query execution times and the number of active connections reaching their limit, revealing a database bottleneck causing delays and occasional request failures in Cloud Run. With this information, you optimize slow queries, increase database connection limits, and add caching to reduce database load. The custom dashboard not only helped resolve the issue but also became a proactive tool for monitoring both services to ensure seamless performance during peak traffic.

View logs

Cloud Run services and jobs emit logs containing details about request and responses, container startups and shutdowns, security alerts, and other important information you need to analyze and maintain the health and performance of your serverless applications.

In Cloud Run, there are two types of logs:

• Request logs, which record information about requests being sent to your Cloud Run services
• Container logs, which contain information about the status of the container instances that comprise your serverless application as it’s running

You can view logs within the Cloud Run UI by clicking on the specific service or job you are interested in, then clicking on the Logs tab.

You can also view service logs via the Google Cloud CLI in the form of “tailing logs”, which present you with a near real-time feed of the most recent logs or “existing logs,” which provide you with a view of historical logs that have already been generated.

You can view trailing logs with the Google Cloud CLI using the following command:

gcloud beta run services logs tail SERVICE --project PROJECT-ID

And to view existing logs, you can use:

 gcloud beta run services logs read SERVICE --limit=10 --project PROJECT-ID

View service request traces

You can get an even deeper look at your Cloud Run-hosted applications’ performance and identify bottlenecks by viewing traces of incoming service requests. Traces are visualized as spans that represent the time it takes for requests to complete different segments of their execution cycle, such as database queries and API calls.

To view a service’s traces within the Google Cloud console, copy the URL of the service (e.g., https://self-monitoring-instrumented-nodejs-1234567-ue.a.run.app). Then navigate to the Trace Overview page, click on the “Trace explorer,” and use the copied URL as your search parameter.

Traces will then appear as shown in the screenshot below.

Monitor serverless containerized workloads with Datadog

In this post, we looked at how you can use Google Cloud’s native monitoring tools to collect metrics, traces, and logs to monitor the health and performance of your Cloud Run-hosted workloads. In Part 3 of this series, we’ll show how you can use Datadog’s Cloud Run integration to get full visibility into your serverless containerized workloads, so you can monitor the key metrics covered in Part 1 of this series in addition to traces and logs for added context when troubleshooting. We’ll also look at how Datadog enables you to collect and visualize Cloud Run monitoring data alongside telemetry from any other Google Cloud service you’re using with a single, unified platform.