Feature Request: Make Elysia lifecycle spans configurable (opt-in/opt-out per phase)

[turisanapo]

What is the problem this feature would solve?

The OpenTelemetry plugin currently emits spans for all Elysia lifecycle phases by default.

In production, this can generate a lot of low-value spans depending on the application architecture and hooks used. In my case, only a subset of phases is useful for analysis, while others mostly add noise and ingestion cost.

I would like to keep using the plugin, but control which lifecycle phases generate spans.

What is the feature you are proposing to solve the problem?

Add a configuration option to selectively enable/disable lifecycle phase spans.

Example API ideas:

opentelemetry({
  // Option A: explicit includes
  enabledLifecycleSpans: [
    "Request",
    "Handle",
    "Error"
  ]
})

opentelemetry({
  // Option B: explicit excludes
  disabledLifecycleSpans: [
    "Request",
    "Transform",
    "AfterHandle"
  ]
})

opentelemetry({
  // Option C: phase predicate
  shouldTraceLifecycleSpan: (phase, context) => {
    return phase !== "AfterResponse"
  }
})

This would allow users to:

• Keep root/request tracing
• Reduce noisy spans
• Align emitted spans with the actual operational value
• Lower trace ingestion/storage costs

What alternatives have you considered?

1. Head sampling (OTEL_TRACES_SAMPLER)
   This reduces trace volume but not per-trace span noise for traces that are sampled.

2. Downstream filtering in collector/backend
   Possible, but adds complexity and still generates spans in-process that are later discarded.

3. Custom fork/patch of @elysiajs/opentelemetry
   Works, but increases maintenance burden and diverges from upstream.

A built-in config for lifecycle span selection would be the cleanest and most maintainable approach.