Skip to main content
Both Lambda and Fargate constructs take a destination — where your telemetry is sent, and which OpenTelemetry signals to include. Configure it once on the construct; every workload that construct instruments uses the same settings.
Read Odigos AWS CDK first for install and when to use the package. This page covers only the shared destination options.

​
Choosing a destination

You give the construct an endpoint in one of two formats, depending on which protocol your destination speaks:
​
string
OTLP over gRPC, written as a bare host:port with no https:// prefix — for example otlp.example.com:4317. Port 4317 is the convention.
​
string
OTLP over HTTP, written as a full URL including the scheme — for example https://otlp.example.com:4318. Port 4318 is the convention.
The two formats aren’t interchangeable, and getting them mixed up is the most common mistake here — so the construct checks: a scheme in endpoint, or a missing one in httpEndpoint, stops the build immediately rather than deploying something that starts up fine and then quietly delivers nothing. Using a port that belongs to the other protocol (4318 with gRPC, or 4317 with HTTP) produces a warning.
How many endpoints to set differs between the two constructs. Lambda takes exactly one. Fargate accepts either or both, and often should get both — see Fargate → Transport for why.
Two more optional settings:
​
boolean
default:"false"
Skip TLS verification. Applies to the gRPC endpoint only — the HTTP exporter takes its transport from the URL scheme.
​
object
Headers sent with every request, which in practice means your destination’s credential (an API key or token).
These are stored as a plain environment variable on the workload — readable by anyone who can describe the function or task definition, and visible in the AWS console. For a long-lived credential, prefer a destination that authenticates by network position (a private VPC endpoint, or mTLS), or send telemetry to a collector you run that holds the real credential.

​
Choosing which signals to send

OpenTelemetry produces three kinds of data, and you choose which ones to send:
​
boolean
default:"true"
Traces — the request-by-request timelines. On by default.
​
boolean
default:"false"
Metrics — numeric measurements over time. Off unless you turn it on.
​
boolean
default:"false"
Logs. Off unless you turn it on.
Traces are on by default because that is the primary signal most teams set up OpenTelemetry for. Metrics and logs are opt-in: enabling a signal you are not ready to receive is not free — refused batches are retried on a backoff, and on Lambda that retrying happens inside billed duration. Turn them on when you want those signals and your destination is configured to accept them.
Match this to what your destination in Odigos has enabled. Odigos compares the workload’s full telemetry configuration against what it expects, so a traces-only workload checked against a destination configured for all three signals is reported as drifted — even though the workload is working fine. Read the enabled signals off the destination in Odigos and state the same ones here.
Turning all three off stops the build — a workload with instrumentation but nowhere to send anything would be silent, which is never what you meant.

​
Next steps

Lambda construct

Layer sources, web-server mode, Java handler interfaces.

Fargate construct

Languages, service naming, the agents image.