Try it free

Monitor Google Cloud Run managed

  • Dynatrace Classic
  • How-to guide
  • 11-min read

Google Cloud Run managed is a compute platform for running containers in a serverless environment. To monitor services running on Google Cloud Run managed using Dynatrace, you need to integrate OneAgent within your containerized application.

Integrate Dynatrace into your containers

There are several ways to build and deploy containers to Cloud Run, such as with Cloud Build.

While the instructions to integrate Dynatrace may differ depending on the technology stack used to build and deploy, the integration of Dynatrace independently follows the same approach:

  1. Add the Dynatrace OneAgent binaries to your container image by copying from a public codemodule image.
  2. Configure OneAgent with the necessary connection parameters and additional options such as custom tags.
  3. Enable process injection for automatic instrumentation of your workloads.

Prerequisites

Before you begin, you need to take care of the following:

  • Get an access token with InstallerDownload scope to retrieve connection parameters from the Dynatrace API. For details on access tokens, see Dynatrace API - Tokens and authentication.

    In the procedures that follow, replace <DT_TOKEN> with your actual access token.

  • Get your environment ID and API endpoint. The endpoint is https://<DT_ENV_ID>.live.dynatrace.com. For details, see What is a monitoring environment?.

    In the procedures that follow, replace <DT_ENV_ID> with your environment ID and <DT_ENV_FQDN> with your API endpoint.

  • Install gcloud CLI

  • Retrieve and store connection credentials in Secret Manager. Retrieve runtime connection parameters from the Dynatrace connection info API:

    curl -H "Authorization: Api-Token <DT_TOKEN>" "https://<DT_ENV_FQDN>/api/v1/deployment/installer/agent/connectioninfo"

    Map the response fields to the following environment variables:

    Environment variableAPI response field
    DT_TENANTtenantUUID
    DT_TENANTTOKENtenantToken (a short communication token, not the PaaS token)
    DT_CONNECTION_POINTformattedCommunicationEndpoints

    Store each value as a secret:

    echo -n "<DT_CONNECTION_POINT_VALUE>" | gcloud secrets create dt-connection-point --data-file=- --project=<GCP_PROJECT_ID>
    echo -n "<DT_TENANT_VALUE>" | gcloud secrets create dt-tenant --data-file=- --project=<GCP_PROJECT_ID>
    echo -n "<DT_TENANTTOKEN_VALUE>" | gcloud secrets create dt-tenanttoken --data-file=- --project=<GCP_PROJECT_ID>

    Grant the Cloud Run service account the roles/secretmanager.secretAccessor role on your secrets. See Secret Manager access control for details. Replace <PROJECT_NUMBER> with the numeric project ID (run gcloud projects describe <GCP_PROJECT_ID> --format='value(projectNumber)'):

    gcloud projects add-iam-policy-binding <GCP_PROJECT_ID> --member="serviceAccount:<PROJECT_NUMBER>-compute@developer.gserviceaccount.com" --role="roles/secretmanager.secretAccessor"

After you have completed the above prerequisites, follow one of these procedures (select a tab) to integrate Dynatrace into your containers.

If you use Cloud Build, you may encounter toomanyrequests rate limit errors when pulling codemodule images directly from public ECR, because Cloud Build workers share IP address pools. To avoid this, mirror the image to a private registry.

Avoid ECR rate limits: mirror to a private registry

Pull the codemodule image and push it to a registry within your own infrastructure. Example using Google Artifact Registry:

gcloud artifacts repositories create dynatrace --repository-format=docker --location=<GCP_REGION> --project=<GCP_PROJECT_ID>
gcloud auth configure-docker <GCP_REGION>-docker.pkg.dev
docker pull public.ecr.aws/dynatrace/dynatrace-codemodules:<VERSION>-<TECH>
docker tag public.ecr.aws/dynatrace/dynatrace-codemodules:<VERSION>-<TECH> <GCP_REGION>-docker.pkg.dev/<GCP_PROJECT_ID>/dynatrace/dynatrace-codemodules:<VERSION>-<TECH>
docker push <GCP_REGION>-docker.pkg.dev/<GCP_PROJECT_ID>/dynatrace/dynatrace-codemodules:<VERSION>-<TECH>

Replace <TECH> with the technology tag (for example python) and <VERSION> with the codemodule version. Then update the CODEMODULE_IMAGE ARG in your Dockerfile to point to your private registry path.

Integrate into cloud built with cloudbuild.yaml

Step 1

Update your Dockerfile

Step 2

Configure Cloud Build

Step 3

Build and deploy

Step 1 Update your Dockerfile

Requires Docker version 17.05+

Add the codemodule as the first build stage and copy its contents into the runtime image using COPY --from. Select the tab for your technology.

Replace <VERSION> with an available codemodule tag. Browse available tags at gallery.ecr.aws/dynatrace/dynatrace-codemodules. Note that tech-specific tags (for example -python) are not published for every version. Use the all-technology tag (no suffix) as a fallback. No docker login is required because public.ecr.aws/dynatrace is publicly accessible.

The runtime base image must be glibc-based. Alpine (musl libc) is not supported by the Dynatrace code module for any technology.

ARG CODEMODULE_IMAGE=public.ecr.aws/dynatrace/dynatrace-codemodules:<VERSION>-java


FROM ${CODEMODULE_IMAGE} AS dynatrace


FROM maven:3-eclipse-temurin-21-alpine AS build
WORKDIR /app
COPY pom.xml .
RUN mvn -q dependency:go-offline
COPY src ./src
RUN mvn -q package -DskipTests


FROM eclipse-temurin:21-jre
COPY --from=dynatrace / /
WORKDIR /app
COPY --from=build /app/target/*.jar app.jar
ENV LD_PRELOAD=/opt/dynatrace/oneagent/agent/lib64/liboneagentproc.so
ENV DT_LOGSTREAM=stdout
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]
ARG CODEMODULE_IMAGE=public.ecr.aws/dynatrace/dynatrace-codemodules:<VERSION>-nodejs


FROM ${CODEMODULE_IMAGE} AS dynatrace


FROM node:20-slim AS build
WORKDIR /app
COPY package*.json .
RUN npm install --omit=dev


FROM node:20-slim
COPY --from=dynatrace / /
WORKDIR /app
COPY --from=build /app/node_modules ./node_modules
COPY . .
ENV LD_PRELOAD=/opt/dynatrace/oneagent/agent/lib64/liboneagentproc.so
ENV DT_LOGSTREAM=stdout
EXPOSE 8080
ENTRYPOINT ["node", "server.js"]
ARG CODEMODULE_IMAGE=public.ecr.aws/dynatrace/dynatrace-codemodules:<VERSION>-python


FROM ${CODEMODULE_IMAGE} AS dynatrace


FROM python:3.12-slim AS build
WORKDIR /app
COPY requirements.txt .
RUN pip install --prefix=/install -r requirements.txt


FROM python:3.12-slim
COPY --from=dynatrace / /
WORKDIR /app
COPY --from=build /install /usr/local
COPY . .
ENV LD_PRELOAD=/opt/dynatrace/oneagent/agent/lib64/liboneagentproc.so
ENV DT_LOGSTREAM=stdout
EXPOSE 8080
ENTRYPOINT ["python", "app.py"]

Step 2 Adjust your Google Cloud Build configuration file

Open your cloudbuild.yaml file and add the following steps:

steps:
  # Build the container image
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', '$_IMAGE', '.']
  # Push the container image to Artifact Registry
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', '$_IMAGE']
  # Deploy container image to Cloud Run
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: gcloud
    args:
      - run
      - deploy
      - $_SERVICE_NAME
      - --allow-unauthenticated
      - --image=$_IMAGE
      - --region=$_GCP_REGION
      - --execution-environment=gen2
      - --project=$_PROJECT
      - --update-secrets=DT_CONNECTION_POINT=dt-connection-point:latest,DT_TENANT=dt-tenant:latest,DT_TENANTTOKEN=dt-tenanttoken:latest
      - --update-env-vars=DT_TAGS=$_SERVICE_NAME,DT_LOGLEVELCON=INFO
  • $_IMAGE is your full Artifact Registry image path, for example <GCP_REGION>-docker.pkg.dev/<GCP_PROJECT_ID>/<REPO>/<IMAGE>:<TAG>
  • <GCP_PROJECT_ID> is the name of your Google Cloud project

The gen2 execution environment is recommended for best compatibility.

You can change DT_TAGS and DT_LOGLEVELCON as needed. DT_LOGLEVELCON accepts NONE, INFO, WARNING, or SEVERE.

Step 3 Build and deploy your Cloud Run Service

Edit and run this command:

gcloud builds submit . --project <GCP_PROJECT_ID> --substitutions "_IMAGE=<GCP_REGION>-docker.pkg.dev/<GCP_PROJECT_ID>/<REPO>/<IMAGE>:<TAG>,_SERVICE_NAME=<YOUR_SERVICE_NAME>,_PROJECT=<GCP_PROJECT_ID>,_GCP_REGION=<GCP_REGION>" --config cloudbuild.yaml

Make sure to substitute the placeholders with your actual values.

  • . is the build source directory (current directory)
  • <GCP_REGION>-docker.pkg.dev/<GCP_PROJECT_ID>/<REPO>/<IMAGE>:<TAG> is the full Artifact Registry image path
  • <YOUR_SERVICE_NAME> is the name of your Cloud Run service, also used as the DT_TAGS value
  • <GCP_PROJECT_ID> is the name of your Google Cloud project
  • <GCP_REGION> is the name of the Google Cloud region you deploy to

Integrate into cloud built without cloudbuild.yaml

Step 1

Update your Dockerfile

Step 2

Build and deploy

Step 1 Update your Dockerfile

Requires Docker version 17.05+

Add the codemodule as the first build stage and copy its contents into the runtime image using COPY --from. Select the tab for your technology.

Replace <VERSION> with an available codemodule tag. Browse available tags at gallery.ecr.aws/dynatrace/dynatrace-codemodules. Note that tech-specific tags (for example -python) are not published for every version. Use the all-technology tag (no suffix) as a fallback. No docker login is required because public.ecr.aws/dynatrace is publicly accessible.

The runtime base image must be glibc-based. Alpine (musl libc) is not supported by the Dynatrace code module for any technology.

ARG CODEMODULE_IMAGE=public.ecr.aws/dynatrace/dynatrace-codemodules:<VERSION>-java


FROM ${CODEMODULE_IMAGE} AS dynatrace


FROM maven:3-eclipse-temurin-21-alpine AS build
WORKDIR /app
COPY pom.xml .
RUN mvn -q dependency:go-offline
COPY src ./src
RUN mvn -q package -DskipTests


FROM eclipse-temurin:21-jre
COPY --from=dynatrace / /
WORKDIR /app
COPY --from=build /app/target/*.jar app.jar
ENV LD_PRELOAD=/opt/dynatrace/oneagent/agent/lib64/liboneagentproc.so
ENV DT_LOGSTREAM=stdout
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]
ARG CODEMODULE_IMAGE=public.ecr.aws/dynatrace/dynatrace-codemodules:<VERSION>-nodejs


FROM ${CODEMODULE_IMAGE} AS dynatrace


FROM node:20-slim AS build
WORKDIR /app
COPY package*.json .
RUN npm install --omit=dev


FROM node:20-slim
COPY --from=dynatrace / /
WORKDIR /app
COPY --from=build /app/node_modules ./node_modules
COPY . .
ENV LD_PRELOAD=/opt/dynatrace/oneagent/agent/lib64/liboneagentproc.so
ENV DT_LOGSTREAM=stdout
EXPOSE 8080
ENTRYPOINT ["node", "server.js"]
ARG CODEMODULE_IMAGE=public.ecr.aws/dynatrace/dynatrace-codemodules:<VERSION>-python


FROM ${CODEMODULE_IMAGE} AS dynatrace


FROM python:3.12-slim AS build
WORKDIR /app
COPY requirements.txt .
RUN pip install --prefix=/install -r requirements.txt


FROM python:3.12-slim
COPY --from=dynatrace / /
WORKDIR /app
COPY --from=build /install /usr/local
COPY . .
ENV LD_PRELOAD=/opt/dynatrace/oneagent/agent/lib64/liboneagentproc.so
ENV DT_LOGSTREAM=stdout
EXPOSE 8080
ENTRYPOINT ["python", "app.py"]

Step 2 Build and deploy your Cloud Run Service

To build your Cloud Run Service, edit and run the following command within your project directory:

gcloud builds submit --region=<GCP_REGION> --tag <GCP_REGION>-docker.pkg.dev/<GCP_PROJECT_ID>/<REPO>/<IMAGE>:<TAG>

To deploy your Cloud Run Service with the connection credentials from Secret Manager:

gcloud run deploy <YOUR_SERVICE_NAME> --image <GCP_REGION>-docker.pkg.dev/<GCP_PROJECT_ID>/<REPO>/<IMAGE>:<TAG> --allow-unauthenticated --update-secrets=DT_CONNECTION_POINT=dt-connection-point:latest,DT_TENANT=dt-tenant:latest,DT_TENANTTOKEN=dt-tenanttoken:latest --update-env-vars=DT_TAGS=<YOUR_SERVICE_NAME>,DT_LOGLEVELCON=INFO --execution-environment=gen2 --region=<GCP_REGION> --project=<GCP_PROJECT_ID>

Make sure to substitute the placeholders with your actual values.

  • <GCP_REGION> is the name of the Google Cloud region you deploy to
  • <GCP_PROJECT_ID> is the name of your Google Cloud project
  • <REPO>/<IMAGE>:<TAG> is the Artifact Registry repository, image name, and tag
  • <YOUR_SERVICE_NAME> is the name of your Cloud Run service, also used as the DT_TAGS value

The gen2 execution environment is recommended for best compatibility.

Integrate using Jib container tool

Google's Jib container tool builds optimized Docker and OCI images for your Java applications without a Docker daemon—and without requiring deep mastery of Docker best practices. It is available as plugins for Maven and Gradle and as a Java library.

Jib does not process Dockerfiles and has no equivalent of the COPY --from=<image> multi-stage build instruction used by the codemodule approach. Direct integration with the codemodule image is therefore not supported.

As a workaround, you can extract the codemodule contents to a local directory first and then include that directory in your Jib build using extraDirectories:

  1. Pull and extract the codemodule image to a local path (requires Docker): 
    docker create --name dt-codemodule public.ecr.aws/dynatrace/dynatrace-codemodules:<VERSION>-java
    docker cp dt-codemodule:/ ./dynatrace-codemodule/
    docker rm dt-codemodule
  2. Add the extracted directory to your Jib configuration as an extra directory mapped to /.
  3. Set the LD_PRELOAD, DT_LOGSTREAM, and runtime connection environment variables as described in the other tabs.

Note that this approach still requires Docker to be available for the extraction step.

Additional configuration

You can use additional environment variables to configure, for example, troubleshooting or advanced networking settings.

Networking

NameDescription
DT_NETWORK_ZONESpecifies to use a network zone. For details, see Network zones.
DT_PROXYWhen using a proxy, use this environment variable to pass proxy credentials. For details, see Set up OneAgent on containers for application-only monitoring

Additional metadata for process grouping and service detection

NameDescription
DT_LOCALTOVIRTUALHOSTNAMEMultiple containers are sometimes detected as a single instance (localhost), leading to various problems in, for example, service detection or availability alerts. Use this environment variable to define a unique name for your container instance. For details, see Service Detection v1
DT_APPLICATIONIDSome technologies don't provide unique application names. In such cases, use this environment variable to provide a unique name. For details, see Service Detection v1
DT_TAGSApplies custom tags to your process group
DT_CUSTOM_PROPApplies custom metadata to your process group
DT_CLUSTER_IDIf the process group detection rules won't work for your use-case, use this environment variable to group all processes with the same value.
DT_NODE_IDIf the process group detection rules won't work for your use-case, use this environment variable to separate process group instances

Troubleshooting

NameDescription
DT_LOGSTREAMSet this variable with stdout to configure agent to log errors into console. To see additional agent logs set the log level with DT_LOGLEVELCON as below.
DT_LOGLEVELCONUse this environment variable to define the console log level. Valid options are NONE, INFO, WARNING, SEVERE in order to increase log level.

.NET-specific variables

This section contains variables only relevant for .NET environments.

ParameterDescription
DT_AGENTACTIVE.NET-specific variable to configure OneAgent monitoring of .NET Framework and .NET Core applications. OneAgent .NET monitoring is active by default (true). To deactivate it, set DT_AGENTACTIVE to false. If you configure .NET monitoring using the .NET profiler environment variables, you need to set DT_AGENTACTIVE to true to activate it.

Verify that the integration was successful

After the build and deploy, you should start seeing your Cloud Run service in Dynatrace.

Verify via service overview

Check your service's overview within Dynatrace for your instrumented application.

The service will show up in Dynatrace after running the newly built version and calling it at least once via, for example, a webrequest.

Verify via host overview

You can filter for containers in the host overview to filter by Monitoring Mode with Standalone/PaaS.

Known limitations

  • No host metrics for Gen1

    The first generation of the GCR execution environment, also referred to as Gen1, comes with intentionally increased security limitations. As a consequence, some OneAgent functionalities cannot work in this runtime and are not available. For example, metrics on the Hosts page such as CPU Usage and Memory Usage are not available.

  • GCR instances detected as hosts

    GCR execution environments are currently displayed on the Hosts page, with proper detection of GCP properties and the memory limit of each of these runtime (container) instances, not on the Container groups page. Container metrics are not available.

  • Possible startup overhead

    Because each revision of Google Cloud Run scales automatically to the number of container instances needed to handle incoming requests, such cold starts might appear more often than on other environments, thus increasing overall startup overhead.

Update OneAgent

To update to a new version of Dynatrace OneAgent, update the <VERSION> tag in the CODEMODULE_IMAGE ARG in your Dockerfile, then rebuild and redeploy.

Uninstall OneAgent

To uninstall OneAgent from application-only monitoring, remove references from your application or Docker image and redeploy the application.

Related topics

  • Set up Dynatrace on Google Cloud (Dynatrace Classic)
  • OneAgent platform and capability support matrix
Related tags
Infrastructure Observability