Skip to content
Ivy

OpenTelemetry

OpenTelemetry for AWS Lambda

Ivy is built on OpenTelemetry. Ingest accepts standard OTLP over HTTP, spans use OpenTelemetry semantic conventions (rpc.system=aws-api, faas.*, http.*, gen_ai.*), and storage uses the OpenTelemetry Collector's ClickHouse exporter. The Ivy Lambda layer is one producer of those spans, tuned for Lambda; any OpenTelemetry SDK can be another.

Send OTLP from anything

Point any OpenTelemetry SDK or Collector at Ivy's ingest endpoint with a project's ingest key:

OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=https://<ingest endpoint>/v1/traces
OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer <ingest key>

The key decides which workspace and project the spans land in. Create one in the dashboard (Settings → Projects) or through the API. Ingest takes protobuf or JSON over HTTP; there is no gRPC endpoint.

To appear as a Lambda invocation in Ivy's invocation list and error groups, a trace's root span needs ivy.invocation=true plus the usual faas.* attributes; other spans are stored and shown as they are. The span conventions list the attributes.

Why a layer of its own, then?

The OpenTelemetry Lambda layers are general purpose and configurable. Ivy's layer makes a few Lambda-specific choices out of the box:

  • Small cold-start cost. About 20–45 ms added to init, with a 32 KB tracer and an extension written in Rust.
  • Export after the response. Spans leave through a Lambda extension once your function has responded, so warm responses are not measurably slower.
  • Payloads by default. Events, responses and AWS SDK and HTTP bodies, capped and redacted inside the function.
  • Failures outside the handler. Init errors, out of memory, crashes and timeouts through the Lambda Telemetry API.
  • OTel libraries without an OTel SDK. Libraries that use @opentelemetry/api, like the Vercel AI SDK, report into the layer directly.

If you already run the AWS Distro for OpenTelemetry or your own OpenTelemetry SDK, keep it and send its spans to Ivy over OTLP. If your app registers its own tracer provider, the Ivy layer leaves it alone.

Standard attributes

Span Attributes
Invocation faas.invocation_id, faas.coldstart, faas.trigger, cloud.resource_id, http.request.method, url.path, http.response.status_code
AWS SDK call rpc.system=aws-api, rpc.service, rpc.method, aws.request_id, aws.dynamodb.table_names, messaging.destination.name
HTTP call http.request.method, url.full, server.address, http.response.status_code
LLM call gen_ai.* (OpenTelemetry GenAI) or the Vercel AI SDK's ai.*

Ivy-specific data, such as payloads and failure details, lives under ivy.*.

No lock-in

The data is OpenTelemetry in ClickHouse, the code is MIT licensed, and the layer only needs two environment variables (IVY_ENDPOINT, IVY_API_KEY) to point somewhere else.

Trace your first function today

Paste this into your coding agent. It signs you up and adds tracing; you approve twice. Free for 100,000 traces a month.

Set up Ivy for my AWS Lambda functions using https://ivytrace.dev/llms.txt

Prefer to do it by hand? Manual setup · Self-host