Configuration

1. Installez le SDK Python Datadog.

   Ajoutez ddtrace à votre requirements.txt ou pyproject.toml. Vous pouvez trouver la dernière version sur PyPI :

   requirements.txt

   Copy

   ddtrace==<VERSION>

   Alternativement, vous pouvez installer le SDK dans votre Dockerfile :

   Dockerfile

   Copy

   RUN pip install ddtrace

   Ensuite, enveloppez votre commande de démarrage avec ddtrace-run :

   Dockerfile

   Copy

   CMD ["ddtrace-run", "python", "app.py"]

   Pour plus d’informations, consultez Tracing Python applications.

2. Installez serverless-init en tant que sidecar.

   Datadog publishes new releases of the serverless-init container image to Google’s gcr.io, AWS’s ECR, and on Docker Hub:

   hub.docker.com	gcr.io	public.ecr.aws
   datadog/serverless-init	gcr.io/datadoghq/serverless-init	public.ecr.aws/datadog/serverless-init

   Images are tagged based on semantic versioning, with each new version receiving three relevant tags:

   • 1, 1-alpine: use these to track the latest minor releases, without breaking changes
   • 1.x.x, 1.x.x-alpine: use these to pin to a precise version of the library
   • latest, latest-alpine: use these to follow the latest version release, which may include breaking changes
   Setup

   Install the Datadog CLI

   npm install -g @datadog/datadog-ci @datadog/datadog-ci-plugin-cloud-run
   

   Install the gcloud CLI and authenticate with gcloud auth login.

   Configuration

   Configure the Datadog site and Datadog API key, and define the service name to use in Datadog.

   export DATADOG_SITE="<DATADOG_SITE>"
   export DD_API_KEY="<DD_API_KEY>"
   export DD_SERVICE="<SERVICE_NAME>"
   

   Instrument

   If you are new to Datadog serverless monitoring, launch the Datadog CLI in interactive mode to guide your first installation for a quick start.

   datadog-ci cloud-run instrument -i
   

   To set up the Datadog sidecar for your applications, run the instrument command after your normal deployment. You can specify multiple services to instrument by passing multiple --service flags.

   datadog-ci cloud-run instrument --project <GCP-PROJECT-ID> --service <CLOUD-RUN-SERVICE-NAME> --region <GCP-REGION>
   

   You can pin to a specific image with the --sidecar-image flag. See the latest releases on Docker Hub.

   Additional parameters can be found in the CLI documentation.

   The Datadog Terraform module for Google Cloud Run wraps the google_cloud_run_v2_service resource and automatically configures your Cloud Run app for Datadog Serverless Monitoring by adding required environment variables and the serverless-init sidecar.

   If you don’t already have Terraform set up, install Terraform, create a new directory, and make a file called main.tf.

   Then, add the following to your Terraform configuration, updating it as necessary based on your needs:

   variable "datadog_api_key" {
     description = "Your Datadog API key"
     type        = string
     sensitive   = true
   }
   
   module "my-cloud-run-app" {
     source  = "DataDog/cloud-run-datadog/google"
     version = "~> 1.0"
   
     project  = "my-gcp-project"
     name     = "my-cloud-run-app"
     location = "us-central1"
   
     datadog_api_key = var.datadog_api_key
     datadog_service = "test-service" // your application service
     datadog_version = "0.0.0" // your code version
     datadog_env     = "prod" // your application environment
     
     datadog_enable_logging = true
   
     deletion_protection = false
     
     template = {
       containers = [
         {
           name  = "main"
           image = "us-docker.pkg.dev/cloudrun/container/hello"
           
           resources = {
             limits = {
               cpu    = "1"
               memory = "512Mi"
             }
           }
           ports = {
             container_port = 8080
           }
           env = [
             { name = "DD_TRACE_ENABLED", value = "true" },
           ]
         },
       ]
     }
   }
   

   See the Environment Variables for more information on the configuration options available through the env.

   Ensure the container port for the main container is the same as the one exposed in your Dockerfile/service.

   If you haven’t already, initialize your Terraform project:

   terraform init
   

   To deploy your app, run:

   terraform apply
   

   Create a YAML file that contains your configuration. You can use the following example and adapt it to your needs:

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: '<SERVICE_NAME>'
     labels:
       cloud.googleapis.com/location: '<LOCATION>'
       service: '<SERVICE_NAME>'
   spec:
     template:
       metadata:
         labels:
           service: '<SERVICE_NAME>'
         annotations:
           # The maximum number of instances that can be created for this service.
           # https://cloud.google.com/run/docs/reference/rest/v1/RevisionTemplate
           autoscaling.knative.dev/maxScale: '100'
           # The startup CPU boost feature for revisions provides additional CPU during
           # instance startup time and for 10 seconds after the instance has started.
           # https://cloud.google.com/run/docs/configuring/services/cpu#startup-boost
           run.googleapis.com/startup-cpu-boost: 'true'
       spec:
         containers:
           - env:
               - name: DD_SERVICE
                 value: '<SERVICE_NAME>'
               - name: DD_LOGS_INJECTION
                 value: 'true'
             image: '<CONTAINER_IMAGE>'
             name: run-sidecar-1
             ports:
               - containerPort: 8080
                 name: http1
             resources:
               limits:
                 cpu: 1000m
                 memory: 512Mi
             startupProbe:
               failureThreshold: 1
               periodSeconds: 240
               tcpSocket:
                 port: 8080
               timeoutSeconds: 240
             volumeMounts:
               - mountPath: /shared-volume
                 name: shared-volume
           - env:
               - name: DD_SERVERLESS_LOG_PATH
                 value: shared-volume/logs/*.log
               - name: DD_SITE
                 value: '<DATADOG_SITE>'
               - name: DD_ENV
                 value: '<ENV>'
               - name: DD_API_KEY
                 value: '<API_KEY>'
               - name: DD_SERVICE
                 value: '<SERVICE_NAME>'
               - name: DD_VERSION
                 value: '<VERSION>'
               - name: DD_LOG_LEVEL
                 value: debug
               - name: DD_SOURCE
                 value: 'python'
               - name: DD_HEALTH_PORT
                 value: '12345'
             image: gcr.io/datadoghq/serverless-init:<YOUR_TAG>
             name: serverless-init-1
             resources:
               limits:
                 cpu: 1000m
                 memory: 512Mi
             startupProbe:
               failureThreshold: 3
               periodSeconds: 10
               tcpSocket:
                 port: 12345
               timeoutSeconds: 1
             volumeMounts:
               - mountPath: /shared-volume
                 name: shared-volume
         volumes:
           - emptyDir:
               medium: Memory
               sizeLimit: 512Mi
             name: shared-volume
     traffic:
       - latestRevision: true
         percent: 100
   

   This example uses the latest version of serverless-init. See the latest releases on Docker Hub to pin a specific version.

   See the Environment Variables for more information.

   In this example, the environment variables, startup health check, and volume mount are already added. If you don’t want to enable logs, remove the shared volume.

   Ensure the container port for the main container is the same as the one exposed in your Dockerfile/service.

   To deploy your container, run:

   gcloud run services replace <FILENAME>.yaml
   

   After deploying your Cloud Run app, you can manually modify your app’s settings to enable Datadog monitoring.

   1. Create a Volume with In-Memory volume type.

   2. Add a new container with image URL: gcr.io/datadoghq/serverless-init:<YOUR_TAG>. See the latest releases on Docker Hub to pin a specific version.

   3. Add the volume mount to every container in your application. Choose a path such as /shared-volume, and remember it for the next step.

   4. Add the following environment variables to your serverless-init sidecar container:

      • DD_SERVICE: A name for your service. For example, gcr-sidecar-test.
      • DD_ENV: A name for your environment. For example, dev.
      • DD_SERVERLESS_LOG_PATH: Your log path. For example, /shared-volume/logs/*.log. The path must begin with the mount path you defined in the previous step.
      • DD_API_KEY: Your Datadog API key.

      For a list of all environment variables, including additional tags, see Environment variables.

3. Configurez les logs.

   À l’étape précédente, vous avez créé un volume partagé. Vous avez peut-être également défini la variable d’environnement DD_SERVERLESS_LOG_PATH, dont la valeur par défaut est /shared-volume/logs/app.log.

   À cette étape, configurez votre bibliothèque de journalisation pour écrire les logs dans le fichier défini dans DD_SERVERLESS_LOG_PATH. Vous pouvez également définir un format personnalisé pour la corrélation log/trace et d’autres fonctionnalités. Datadog recommande de définir les variables d’environnement suivantes :

   • ENV PYTHONUNBUFFERED=1 : Dans votre conteneur principal. Assurez-vous que les sorties Python apparaissent immédiatement dans les logs du conteneur au lieu d’être mises en mémoire tampon.
   • ENV DD_LOGS_INJECTION=true : Dans votre conteneur principal. Activez la corrélation log/trace pour les loggers pris en charge.
   • DD_SOURCE=python : Dans votre conteneur sidecar. Activez le parsing avancé des logs Datadog.

   Ensuite, mettez à jour votre bibliothèque de journalisation. Par exemple, vous pouvez utiliser la bibliothèque native logging de Python :

   Copy

   LOG_FILE = "/shared-logs/logs/app.log"
   os.makedirs(os.path.dirname(LOG_FILE), exist_ok=True)
   
   FORMAT = ('%(asctime)s %(levelname)s [%(name)s] [%(filename)s:%(lineno)d] '
           '[dd.service=%(dd.service)s dd.env=%(dd.env)s dd.version=%(dd.version)s dd.trace_id=%(dd.trace_id)s dd.span_id=%(dd.span_id)s] '
           '- %(message)s')
   
   logging.basicConfig(
       level=logging.INFO,
       format=FORMAT,
       handlers=[
           logging.FileHandler(LOG_FILE),
           logging.StreamHandler(sys.stdout)
       ]
   )
   logger = logging.getLogger(__name__)
   logger.level = logging.INFO
   
   logger.info('Hello world!')

   Pour plus d’informations, consultez Corrélation des logs et des traces Python.

4. Add a service label in Google Cloud. In your Cloud Run service’s info panel, add a label with the following key and value:

   Key	Value
   service	The name of your service. Matches the value provided as the DD_SERVICE environment variable.

   See Configure labels for services in the Cloud Run documentation for instructions.

5. Envoyez des métriques personnalisées.

   Pour envoyer des métriques personnalisées, installez le client DogStatsD et consultez des exemples de code. Dans serverless, seul le type de métrique distribution est pris en charge.

6. Activez le profilage (préversion).

   Pour activer le Continuous Profiler, définissez la variable d’environnement DD_PROFILING_ENABLED=true dans votre conteneur d’application.

   Le Continuous Profiler de Datadog est disponible en préversion pour les services Google Cloud Run.

Environment variables

Do not set the following environment variables in your serverless environment. They should only be set in non-serverless environments.

• DD_AGENT_HOST
• DD_TRACE_AGENT_URL

Traçage distribué avec Pub/Sub

Définissez DD_TRACE_INFERRED_PROXY_SERVICES_ENABLED=true dans le conteneur d’application. Cela crée un span gcp.pubsub.receive inféré pour la requête push.

Le tracing des abonnements push Google Cloud Pub/Sub nécessite la version 4.8.0 ou ultérieure de ddtrace.

To get end-to-end distributed traces between Pub/Sub producers and Cloud Run, configure your push subscriptions with the --push-no-wrapper and --push-no-wrapper-write-metadata flags. This moves message attributes from the JSON body to HTTP headers, allowing Datadog to extract producer trace context and create span links.

For more information, see Producer-aware tracing for Google Cloud Pub/Sub and Cloud Run and Payload unwrapping in the Google Cloud documentation.

Configure push subscriptions for full trace visibility

Create a new push subscription:

gcloud pubsub subscriptions create order-processor-sub \
  --topic=orders \
  --push-endpoint=https://order-processor-xyz.run.app/pubsub \
  --push-no-wrapper \
  --push-no-wrapper-write-metadata

Update an existing push subscription:

gcloud pubsub subscriptions update order-processor-sub \
  --push-no-wrapper \
  --push-no-wrapper-write-metadata

Configure Eventarc Pub/Sub triggers

Eventarc Pub/Sub triggers use push subscriptions as the underlying delivery mechanism. When you create an Eventarc trigger, GCP automatically creates a managed push subscription. However, Eventarc does not expose --push-no-wrapper-write-metadata as a trigger creation parameter, so you must manually update the auto-created subscription.

1. Create the Eventarc trigger:

   gcloud eventarc triggers create order-processor-trigger \
     --destination-run-service=order-processor \
     --destination-run-region=us-central1 \
     --event-filters="type=google.cloud.pubsub.topic.v1.messagePublished" \
     --transport-topic=projects/my-project/topics/orders \
     --location=us-central1
   

2. Find the auto-created subscription:

   gcloud pubsub subscriptions list \
     --filter="topic:projects/my-project/topics/orders" \
     --format="table(name,pushConfig.pushEndpoint)"
   

   Example output:

   NAME                                                          PUSH_ENDPOINT
   eventarc-us-central1-order-processor-trigger-abc-sub-def      https://order-processor-xyz.run.app
   

3. Update the subscription for trace propagation:

   gcloud pubsub subscriptions update \
     eventarc-us-central1-order-processor-trigger-abc-sub-def \
     --push-no-wrapper \
     --push-no-wrapper-write-metadata
   

Dépannage

This integration depends on your runtime having a full SSL implementation. If you are using a slim image, you may need to add the following command to your Dockerfile to include certificates:

RUN apt-get update && apt-get install -y ca-certificates

To have your Cloud Run services appear in the software catalog, you must set the DD_SERVICE, DD_VERSION, and DD_ENV environment variables.

Pour aller plus loin

Documentation, liens et articles supplémentaires utiles:

Tracer des applications PythonDOCUMENTATION Corrélation des logs et des traces PythonDOCUMENTATION