Skip to main content
This page shows how to instrument an ECS service running on Fargate yourself via CloudFormation, by editing its task definition directly — no changes made by the connector on your behalf. Odigos still discovers the service and reports its status once your changes are in place; see Odigos-managed vs. self-managed instrumentation for how that works.
Prefer the Odigos CDK construct? See CDK: Fargate. This page is the hand-written CloudFormation / raw ECS form of the same change.

How it works

Self-managed Fargate instrumentation adds one extra container to your task definition, plus a handful of environment variables on your application container. Here’s what happens each time the task starts:
  1. A small helper container, odigos-agent, starts first. It copies the files your application’s language agent needs into a shared volume, then exits. It’s marked non-essential, since its only job is to prepare files — it isn’t part of your running application.
  2. Your application container waits for step 1 to finish successfully before it starts (DependsOn: ... Condition: SUCCESS) — this guarantees the agent files are already in place by the time your code runs.
  3. Your application container picks up the agent through environment variables specific to its language — for example JAVA_TOOL_OPTIONS for Java — and begins exporting telemetry.
There’s no intermediate collector inside the task — each Fargate task sends telemetry directly to your OTLP destination, so that destination’s endpoint must be reachable from the task’s network. See Telemetry export.

CloudFormation

Merge these properties into your task definition. Only the exact agent path, activation variable, and network protocol change per language. Pick yours below:

Rules that apply to every language

It’s the only thing marking a container as instrumented, and its recorded language is what the activation environment is checked against. Never set ODIGOS_MANAGED — that’s the connector’s own rollback record, written only when you hand the workload to Odigos-managed instrumentation instead.
Both are compared exactly against what your OTLP destination resolves to on this connector. If it only offers OTLP/gRPC, use the gRPC endpoint (standard port 4317) and OTEL_EXPORTER_OTLP_PROTOCOL=grpc instead of the http/protobuf shown above (except PHP and Ruby, which support HTTP only — see their tabs). Pairing an endpoint with the wrong transport fails at runtime as an opaque connection reset.
Its Command is per task, not per language. A task definition with application containers in more than one language needs a chained && cp -r /instrumentations/<lang> /var/odigos/<lang> for each, in alphabetical order — Odigos compares the command exactly against the union of every marked container’s language.
Registering a new task-definition revision isn’t enough on its own — update the service to it, or it keeps running the old one.
A 10-container task-definition limit, Linux-only agents bundle (no Windows tasks), and the odigos-agent container must stay non-essential — ECS only accepts a SUCCESS dependency against a non-essential container.
The image is pulled by the task’s execution role at every task start. If your task’s subnet can’t reach registry.odigos.io, mirror the image into a registry it can — see Preload artifacts.

Next steps

Preload artifacts

Mirror the Fargate agents image into a private registry.

CDK: Fargate

Every option on the Fargate CDK construct, in depth.