---
title: Choosing an Instrumentation Method for Containers
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: >-
  Docs > Serverless > Google Cloud Run > Choosing an Instrumentation Method for
  Containers
---

# Choosing an Instrumentation Method for Containers

To instrument your Google Cloud Run containers with Datadog, choose one of two options:

- [](https://docs.datadoghq.com/serverless/google_cloud_run/containers/in_container)
- [](https://docs.datadoghq.com/serverless/google_cloud_run/containers/sidecar)

- [**In-Container**](https://docs.datadoghq.com/serverless/google_cloud_run/containers/in_container): Wraps your application container with the Datadog Agent. Choose this option for a simpler setup, lower cost overhead, and direct log piping.
- [**Sidecar**](https://docs.datadoghq.com/serverless/google_cloud_run/containers/sidecar): Deploys the Datadog Agent in a separate container alongside your app container. Choose this option if you have multiple containers in a single service, if you prefer strict isolation of the Datadog Agent, or if you have performance-sensitive workloads.

## Comparison: In-Container versus sidecar instrumentation{% #comparison-in-container-versus-sidecar-instrumentation %}

| Aspect            | In-Container                                             | Sidecar                                                                                                                                                      |
| ----------------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Deployment        | One container (your app, wrapped with the Datadog Agent) | Two containers (your app, Datadog Agent)                                                                                                                     |
| Image changes     | Increases app image size.                                | No change to app image.                                                                                                                                      |
| Cost overhead     | Less than sidecar (no extra container).                  | Extra vCPU/memory. Overallocating the sidecar wastes cost; underallocating leads to premature scaling.                                                       |
| Logging           | Direct stdout/stderr access.                             | Shared volume + log library routing to a log file. Uncaught errors require extra handling, since they are not automatically handled by your logging library. |
| Failure isolation | In rare cases, Datadog Agent bugs can affect your app.   | Datadog Agent faults are isolated.                                                                                                                           |

## Further reading{% #further-reading %}

- [Google Cloud Run Integration](https://docs.datadoghq.com/integrations/google-cloud-run/)
- [Collect traces, logs, and custom metrics from Cloud Run services](https://www.datadoghq.com/blog/collect-traces-logs-from-cloud-run-with-datadog/)
- [Instrument your container with the in-container approach](https://docs.datadoghq.com/serverless/google_cloud_run/containers/in_container/)
- [Instrument your container with the sidecar approach](https://docs.datadoghq.com/serverless/google_cloud_run/containers/sidecar/)
- [Instrument Google Cloud Run applications with the new Datadog Agent sidecar](https://www.datadoghq.com/blog/instrument-cloud-run-with-datadog-sidecar/)