EverTask has monitoring events, a dashboard and Serilog integration, but no native OpenTelemetry instrumentation: no ActivitySource, no Meter, and no trace context flowing from the code that dispatches a task to the handler that executes it. TickerQ ships OTel natively; for Hangfire it is community packages only.
Design sketch
- Traces: a dispatch span (created in
Dispatcher) and an execution span (created around the handler), linked by W3C traceparent/tracestate persisted with the task row — new storage field(s), one new migration per relational provider (migrations are frozen; never edit existing ones). The execution span restores the persisted context as parent/link, so a task's trace connects back to the request that dispatched it.
- The execution span is a built-in pipeline behavior — depends on the behaviors issue; ships as the first consumer of that API.
- Metrics (
Meter): dispatched/completed/failed/cancelled counters, execution duration histogram, queue depth, rate-limit deferrals and rejections. Names aligned with OTel semantic conventions where they fit (messaging-style attributes: queue, task type, outcome).
- Packaging: instrumentation in the core behind an opt-in (
AddOpenTelemetryInstrumentation() or similar); no exporter dependencies in core packages.
- Export targets (Sentry Crons, Application Insights) remain separate roadmap items.
Distribution compatibility
The persisted trace context is the piece worth doing carefully now: it is exactly what makes traces span processes once publishers and the consumer are separated (#59) and hosts are multiple (#31). A publisher's dispatch span and the consumer's execution span end up in one trace with no extra work later.
EverTask has monitoring events, a dashboard and Serilog integration, but no native OpenTelemetry instrumentation: no
ActivitySource, noMeter, and no trace context flowing from the code that dispatches a task to the handler that executes it. TickerQ ships OTel natively; for Hangfire it is community packages only.Design sketch
Dispatcher) and an execution span (created around the handler), linked by W3Ctraceparent/tracestatepersisted with the task row — new storage field(s), one new migration per relational provider (migrations are frozen; never edit existing ones). The execution span restores the persisted context as parent/link, so a task's trace connects back to the request that dispatched it.Meter): dispatched/completed/failed/cancelled counters, execution duration histogram, queue depth, rate-limit deferrals and rejections. Names aligned with OTel semantic conventions where they fit (messaging-style attributes: queue, task type, outcome).AddOpenTelemetryInstrumentation()or similar); no exporter dependencies in core packages.Distribution compatibility
The persisted trace context is the piece worth doing carefully now: it is exactly what makes traces span processes once publishers and the consumer are separated (#59) and hosts are multiple (#31). A publisher's dispatch span and the consumer's execution span end up in one trace with no extra work later.