New Relic integrations with the Google Cloud Platform (GCP) include one that reports Google Cloud Run data to New Relic. This document explains how to activate the GCP Cloud Run integration and describes the data it reports.
Features
Cloud Run is Google Cloud's fully managed serverless container platform for running stateless services and one-off jobs. New Relic Cloud Run integration collects request, latency, container utilization, and execution metrics across services (via revisions) and jobs.
Activate integration
To enable the integration, follow standard procedures to connect your GCP service to New Relic:
Polling frequency
New Relic integrations query your GCP services according to a polling interval that varies by integration. The polling frequency for Google Cloud Run is 5 minutes. The resolution is 1 data point every minute.
Workload Identity Federation
Find and use data
After you enable the integration, your Cloud Run resources appear as entities in the New Relic entity explorer. To see dashboards and manage services, go to one.newrelic.com > All capabilities > Infrastructure > GCP.
All Cloud Run metrics available in GCP Cloud Monitoring are collected as dimensional metrics in the Metric event type. Additional metrics beyond this table are collected automatically. See Google's Cloud Run metrics documentation for the complete list.
Entities
Metric data
Key metrics — Revision
Metric name | Unit | Description |
|---|---|---|
| Count | Number of requests reaching the revision, faceted by |
| Milliseconds | Request latency distribution for traffic served by the revision. |
| Seconds | Billable time aggregated across all container instances of the revision. |
| Count | Number of container instances backing the revision, faceted by state (active, idle). |
| Seconds | CPU-seconds allocated to the revision's container instances. |
| Percent | CPU utilization distribution of the revision's container instances. |
| GiB-seconds | Memory-seconds allocated to the revision's container instances. |
| Percent | Memory utilization distribution of the revision's container instances. |
| Bytes | Network bytes received by the revision's container instances. |
| Bytes | Network bytes sent by the revision's container instances. |
| Count | Maximum concurrent requests observed per container instance of the revision. |
| Milliseconds | Container startup latency distribution for the revision. |
For the complete list of revision metrics, see Google's Cloud Run metrics documentation.
Key metrics — Job
Metric name | Unit | Description |
|---|---|---|
| Count | Number of completed job executions, faceted by result (succeeded, failed, cancelled). |
| Count | Number of executions currently running for the job. |
| Count | Number of completed task attempts across all executions of the job. |
| Count | Number of task attempts currently running across executions of the job. |
| Seconds | CPU-seconds allocated to the job's container instances. |
| GiB-seconds | Memory-seconds allocated to the job's container instances. |
| Bytes | Network bytes received by the job's container instances. |
| Bytes | Network bytes sent by the job's container instances. |
For the complete list of job metrics, see Google's Cloud Run metrics documentation.
Service account or user account
Find and use data
After activating the integration and waiting a few minutes (based on the polling frequency), data will appear in the New Relic UI. To find and use your data, including links to your and alert settings, go to one.newrelic.com > All capabilities > Infrastructure > GCP > (select an integration).
Data is attached to the following event type:
Entity | Event Type | Provider |
|---|---|---|
Revision |
|
|
For more on how to use your data, see Understand and use integration data.
Run Revision data
Metric | Unit | Description |
|---|---|---|
| Seconds | Billable time aggregated from all container instances of the revision. For a given container instance, billable time occurs when the container instance is starting or at least one request is being processed. Billable time is rounded up to the nearest 100 milliseconds. Examples: If a revision with 2 container instances has been continuously serving traffic in the last minute, the value is 2s/s with the default "rate" aligner. If a single request lasting 30ms was received by a revision in the past minute, it is rounded up to 100ms and averaged to 1.7ms/s over the minute with the default "rate" aligner. |
| Seconds | Container CPU allocation of the revision in seconds. |
| Other | Container memory allocation of the revision in Gigabytes-seconds. |
| Count | Number of requests reaching the revision. Excludes requests that are not reaching your container instances (for example, unauthorized requests or when maximum number of instances is reached). |
| Milliseconds | Distribution of request latency in milliseconds reaching the revision. |