--- title: Instrumenting a Ruby Cloud Run Container In-Container description: Datadog, the leading service for cloud-scale monitoring. breadcrumbs: >- Docs > Serverless > Google Cloud Run > Choosing an Instrumentation Method for Containers > In-Container Instrumentation > Instrumenting a Ruby Cloud Run Container In-Container --- # Instrumenting a Ruby Cloud Run Container In-Container ## Setup{% #setup %} {% alert level="info" %} A sample application is [available on GitHub](https://github.com/DataDog/serverless-gcp-sample-apps/tree/main/cloud-run/in-container/ruby). {% /alert %} 1. **Install the Datadog Ruby tracer**. Add the `datadog` gem to your Gemfile: ``` source 'https://rubygems.org' gem 'datadog' ``` See [Tracing Ruby applications](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries/ruby/#instrument-your-application) for additional information on how to configure the tracer and enable auto instrumentation. 1. **Install 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.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 Add the following instructions and arguments to your Dockerfile. ```dockerfile COPY --from=datadog/serverless-init: /datadog-init /app/datadog-init ENTRYPOINT ["/app/datadog-init"] CMD ["rails", "server", "-b", "0.0.0.0"] ``` {% collapsible-section %} Alternative configuration: 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. ```dockerfile CMD ["/app/datadog-init", "rails", "server", "-b", "0.0.0.0"] ``` If you require your entrypoint to be instrumented as well, you can instead swap your entrypoint and CMD arguments. ```dockerfile ENTRYPOINT ["/app/datadog-init"] CMD ["/your_entrypoint.sh", "rails", "server", "-b", "0.0.0.0"] ``` As long as your command to run is passed as an argument to `datadog-init`, you will receive full instrumentation. {% /collapsible-section %} 1. **Set up logs**. To enable logging, set the environment variable `DD_LOGS_ENABLED=true`. This allows `serverless-init` to read logs from stdout and stderr. Datadog also recommends setting the environment variable `DD_SOURCE=ruby` to enable advanced Datadog log parsing. To enable log-trace correlation, you need to include `Datadog::Tracing.log_correlation` in your log format. For example: ```ruby logger = Logger.new(STDOUT) logger.formatter = proc do |severity, datetime, progname, msg| "[#{datetime}] #{severity}: [#{Datadog::Tracing.log_correlation}] #{msg}\n" end logger.info "Hello world!" ``` For more information, see [Correlating Ruby Logs and Traces](https://docs.datadoghq.com/tracing/other_telemetry/connect_logs_and_traces/ruby/). 1. **Configure your application**. 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](https://app.datadoghq.com/organization-settings/api-keys), 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](https://docs.datadoghq.com/getting_started/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. ```shell gcloud run deploy --image=gcr.io// \ --port=8080 \ --update-env-vars=DD_API_KEY=$DD_API_KEY \ --update-env-vars=DD_SITE=$DD_SITE \ ``` **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](https://cloud.google.com/run/docs/configuring/services/labels) in the Cloud Run documentation for instructions. **Send custom metrics**. To send custom metrics, [install the DogStatsD client](https://docs.datadoghq.com/extend/dogstatsd/?tab=ruby#install-the-dogstatsd-client) and [view code examples](https://docs.datadoghq.com/metrics/custom_metrics/dogstatsd_metrics_submission/?tab=ruby#code-examples-5). In serverless, only the *distribution* metric type is supported. ### Environment variables{% #environment-variables %} | Variable | Description | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `DD_API_KEY` | [Datadog API key](https://app.datadoghq.com/organization-settings/api-keys) - **Required** | | `DD_SITE` | [Datadog site](https://docs.datadoghq.com/getting_started/site/) - **Required** | | `DD_SERVICE` | Datadog Service name. **Required** | | `DD_LOGS_ENABLED` | When true, send logs (stdout and stderr) to Datadog. Defaults to false. | | `DD_LOGS_INJECTION` | When true, enrich all logs with trace data for supported loggers. See [Correlate Logs and Traces](https://docs.datadoghq.com/tracing/other_telemetry/connect_logs_and_traces/) for more information. | | `DD_VERSION` | See [Unified Service Tagging](https://docs.datadoghq.com/getting_started/tagging/unified_service_tagging/). | | `DD_ENV` | See [Unified Service Tagging](https://docs.datadoghq.com/getting_started/tagging/unified_service_tagging/). | | `DD_SOURCE` | Set the log source to enable a [Log Pipeline](https://docs.datadoghq.com/logs/log_configuration/pipelines) for advanced parsing. To automatically apply language-specific parsing rules, set to `ruby`, or use your custom pipeline. Defaults to `cloudrun`. | | `DD_TAGS` | Add 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` ## Troubleshooting{% #troubleshooting %} 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: ```dockerfile RUN apt-get update && apt-get install -y ca-certificates ``` To have your Cloud Run services appear in the [software catalog](https://cloud.google.com/run/docs/configuring/services/labels), you must set the `DD_SERVICE`, `DD_VERSION`, and `DD_ENV` environment variables. ## Further reading{% #further-reading %} - [Tracing Ruby Applications](https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries/ruby/) - [Correlating Ruby Logs and Traces](https://docs.datadoghq.com/tracing/other_telemetry/connect_logs_and_traces/ruby/)