Telemetry
Opt-in, drop-in telemetry that captures every operation and publishes it to a collector and Grafana dashboard — no custom trace class required.
What it is
Telemetry is built on top of Tracing — under the hood, it’s an ITrace implementation that hooks into the same BeforeExecution()/AfterExecution() pipeline, buffers a record per operation, and periodically flushes the batch to a collector. Two packages compose it: RepoDb.Telemetry.Core defines the contracts and reusable pieces, and RepoDb.Telemetry.Default is the ready-to-use implementation — no custom ITrace class to write.
Enabling it
GlobalConfiguration
.Setup(new GlobalConfigurationOptions { UseRegisteredGlobalTraces = true })
.UseDefaultTelemetry(new DefaultTelemetryOption("<YOUR_APPLICATION_NAME>")
{
Host = "https://your-collector-host",
ApiKey = "YOUR_API_KEY",
Group = "<YOUR_APPLICATION_GROUP>"
});
UseRegisteredGlobalTraces = true is required — it runs every globally registered tracer, this one included, for every operation without passing a trace argument at each call site. See Telemetry in Quickstart for the full Docker Compose stack (collector, Postgres, Grafana) this points at.
What gets captured
Every operation is captured as a record with the application, group, session id, operation name, the SQL statement, elapsed time, client machine, and source assembly. Items are buffered in memory and flushed on an interval — gzip-compressed and POSTed to the collector — and a publish failure never throws; it’s routed to an optional errorCallback and logger instead.
Why not OpenTelemetry
This is a deliberate tradeoff, not an oversight. The pipeline hooks directly into RepoDB’s own before/after execution events and serializes a lightweight payload straight to HTTP, skipping OTel’s Span/Activity machinery and collector protocol overhead in the hot path — consistent with a library whose whole point is staying a thin, fast layer over ADO.NET. An OTel-based exporter is on the roadmap as a separate, opt-in package for teams that need it.