Tracing

Sending traces from your app with the standard OTEL_* environment variables — the per-invocation span you get for free, what to add to it, and what happens when nothing is configured.

Your app emits a trace per invocation if you point it at a collector, and does nothing at all if you do not. There is no revenexx-specific tracing SDK, no proprietary agent, and no vendor to sign up with.

Configuration is the standard variables

Tracing is configured with the standard OpenTelemetry environment variables, set as app variables on the deployed app:

App variables
OTEL_EXPORTER_OTLP_ENDPOINT=https://otlp.your-collector.example
OTEL_EXPORTER_OTLP_HEADERS=authorization=Bearer%20<token>
OTEL_SERVICE_NAME=acme-serials

Because they are the standard names, whatever you already run works: your own collector, or a hosted backend that speaks OTLP. Set them in App Studio's variables screen, or with the apps commands — they are variables like any other, per app and per tenant.

Set OTEL_SERVICE_NAME deliberately. A dozen apps all reporting as app is not a trace you can read.

The per-invocation span

With an endpoint configured, each invocation of your function produces a span covering the whole invocation: how long it took, whether it failed, and which trigger caused it — an HTTP request through the gateway, an event delivery, or a scheduled tick.

That top-level span is the useful part on its own. It answers the questions you actually get asked:

  • Is the app slow, or is something the app calls slow?
  • Which tenant's invocations are the slow ones?
  • Did that 3 a.m. schedule run, and how long did it take?
  • Is the p99 a real tail or one pathological request?

Correlating with the gateway

Every response through the gateway carries an X-Request-ID, generated if the caller did not send one. It is the correlation id for the request end to end — see API usage.

Two habits make it worth having:

Log it. One line per invocation with the request id, the tenant and the outcome turns "a customer says it was slow at 14:20" into a lookup.

Forward it. When you call another app or a declared external host, pass X-Request-ID through. That is what makes one trace span the whole chain instead of three unrelated traces.

Adding your own detail

Beyond the invocation span, use the ordinary OpenTelemetry API for JavaScript. There is nothing platform-specific to learn: instrument the calls that can be slow — an outbound HTTP request, a batch read, an expensive computation — and leave the rest alone.

Two rules about what goes into a span:

Do not put customer data in an attribute. A span is telemetry that leaves the platform for your collector. Ids, counts, statuses and durations are fine; a name, an address, an email or a price is not something to export by accident.

Attributes are for things you will filter on. The tenant, the route, the schedule name, the number of rows touched. An attribute nobody queries is cost without a benefit.

Alongside a span, c.log() writes a line to the execution record you can read in App Studio — which is the faster tool while you are developing, and the one that needs no collector at all.

Free when unset

With no OTEL_* variables set, tracing is off and costs nothing. No exporter starts, no spans are built, no requests are attempted against an endpoint that is not there, and your app's latency is unaffected.

So it is safe to leave unconfigured on a tenant that does not need it, and safe to switch on later — setting the variables and redeploying is the whole change. There is no code in your app that has to know either way, which is the point of using the standard variables instead of an SDK you initialise.

Next steps

Was this page helpful?