Configuración

Una aplicación de ejemplo está disponible en GitHub.
  1. Instale el SDK de Datadog para Node.js.

    1. En su aplicación principal, instale el paquete dd-trace.

      npm install dd-trace
    2. Inicialice el trazador de Node.js con la variable de entorno NODE_OPTIONS:

      ENV NODE_OPTIONS="--require dd-trace/init"

    Para obtener más información, consulte Seguimiento de aplicaciones Node.js.

  2. Instale serverless-init.

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

    hub.docker.comgcr.iopublic.ecr.aws
    datadog/serverless-initgcr.io/datadoghq/serverless-initpublic.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

    Add the following instructions and arguments to your Dockerfile.

    COPY --from=datadog/serverless-init:<YOUR_TAG> /datadog-init /app/datadog-init
    ENTRYPOINT ["/app/datadog-init"]
    CMD ["/nodejs/bin/node", "/path/to/your/app.js"]
    

    Datadog expects serverless-init to be the top-level application, with the rest of your app’s command line passed in for serverless-init to execute.

    If you already have an entrypoint defined inside your Dockerfile, you can instead modify the CMD argument.

    CMD ["/app/datadog-init", "/nodejs/bin/node", "/path/to/your/app.js"]
    

    If you require your entrypoint to be instrumented as well, you can instead swap your entrypoint and CMD arguments.

    ENTRYPOINT ["/app/datadog-init"]
    CMD ["/your_entrypoint.sh", "/nodejs/bin/node", "/path/to/your/app.js"]
    

    As long as your command to run is passed as an argument to datadog-init, you will receive full instrumentation.


  3. Configure los registros.

    Para habilitar el registro, establezca la variable de entorno DD_LOGS_ENABLED=true. Esto permite que serverless-init lea los registros de stdout y stderr.

    Datadog también recomienda establecer las variables de entorno DD_LOGS_INJECTION=true y DD_SOURCE=nodejs para habilitar el parseo avanzado de registros de Datadog.

    Si desea que los registros multilínea se conserven en un solo mensaje de registro, Datadog recomienda escribir sus registros en formato JSON. Por ejemplo, puede utilizar una biblioteca de registro de terceros como winston:

    const { createLogger, format, transports } = require('winston');
    
    const logger = createLogger({
      level: 'info',
      exitOnError: false,
      format: format.json(),
      transports: [
        new transports.Console()
      ],
    });
    
    logger.info('Hello world!');

    Para obtener más información, consulte Correlación de registros y trazas de Node.js.

  4. Configure su aplicación.

    After the container is built and pushed to your registry, set the required environment variables for the Datadog Agent:

    • DD_API_KEY: Your Datadog API key, used to send data to your Datadog account. For privacy and safety, configure this API key as a Google Cloud Secret.
    • DD_SITE: Your Datadog site. For example, datadoghq.com.

    For more environment variables, see the Environment variables section on this page.

    The following command deploys the service and allows any external connection to reach it. In this example, your service listening is set to port 8080. Ensure that this port number matches the exposed port inside of your Dockerfile.

    gcloud run deploy <APP_NAME>
      --image=gcr.io/<YOUR_PROJECT>/<APP_NAME> \
      --port=8080 \
      --update-env-vars=DD_API_KEY=$DD_API_KEY \
      --update-env-vars=DD_SITE=$DD_SITE \
    
  1. Add a service label in Google Cloud. In your Cloud Run service’s info panel, add a label with the following key and value:

    KeyValue
    serviceThe 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.

  1. Enviar métricas personalizadas.

    Para enviar métricas personalizadas, vea ejemplos de código. En serverless, solo se admite el tipo de métrica distribution.

  2. Habilite el perfilado (vista previa).

    Para habilitar el Continuous Profiler, establezca la variable de entorno DD_PROFILING_ENABLED=true.

    El Continuous Profiler de Datadog está disponible en vista previa para los servicios de Google Cloud Run.

Environment variables

VariableDescription
DD_API_KEYDatadog API key - Required
DD_SITEDatadog site - Required
DD_SERVICEDatadog Service name. Required
DD_LOGS_ENABLEDWhen true, send logs (stdout and stderr) to Datadog. Defaults to false.
DD_LOGS_INJECTIONWhen true, enrich all logs with trace data for supported loggers. See Correlate Logs and Traces for more information.
DD_VERSIONSee Unified Service Tagging.
DD_ENVSee Unified Service Tagging.
DD_SOURCESet the log source to enable a Log Pipeline for advanced parsing. To automatically apply language-specific parsing rules, set to nodejs, or use your custom pipeline. Defaults to cloudrun.
DD_TAGSAdd custom tags to your logs, metrics, and traces. Tags should be comma separated in key/value format (for example: key1:value1,key2:value2).

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

Seguimiento distribuido con Pub/Sub

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
    

Solución de problemas

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.

If you are using request-based billing for a Google Cloud Run application instrumented in-container, very short requests may lead to dropped logs during the post-request CPU throttling. You can control the speed at which logs are sent to Datadog using the DD_LOGS_CONFIG_BATCH_WAIT environment variable. Set DD_LOGS_CONFIG_BATCH_WAIT to a value shorter than your typical request duration to avoid dropped logs. Sidecar instrumentation also prevents this issue, as the sidecar is not affected by request-based CPU throttling.

Lecturas adicionales