The C# SDK exposes worker metrics via the standard System.Diagnostics.Metrics API, making them compatible with any .NET metrics listener -- most notably the OpenTelemetry .NET SDK.

• Quick Reference
• Configuration
  • DI-Based Workers
  • WorkflowTaskHost Convenience API
  • Prometheus via OpenTelemetry
  • Console Exporter (Development)
• Metric Types
  • Counters
  • Histograms
  • Gauges
• Labels
• Example Metrics Output
• Best Practices

All metrics are registered under the meter named Conductor.Client.

MetricsCollector is automatically registered as a singleton when you call AddConductorWorker(). No additional setup is needed for the SDK to start recording -- metrics are written to System.Diagnostics.Metrics instruments immediately.

var host = new HostBuilder()
    .ConfigureServices(services =>
    {
        // MetricsCollector is registered automatically here.
        services.AddConductorWorker(config);
        services.AddConductorWorkflowTask(new MyWorker());
        services.WithHostedService();
    })
    .Build();

To expose the metrics externally (e.g. Prometheus scraping), attach a metrics listener or exporter as shown below.

If you use the one-liner WorkflowTaskHost.CreateWorkerHost(...), metrics are registered automatically via the same AddConductorWorker() call:

var host = WorkflowTaskHost.CreateWorkerHost(config, workers: new MyWorker());
await host.RunAsync();

Add the following NuGet packages to your project:

dotnet add package OpenTelemetry
dotnet add package OpenTelemetry.Exporter.Prometheus.HttpListener --prerelease

Then configure a MeterProvider before starting the host:

using OpenTelemetry;
using OpenTelemetry.Metrics;
using Conductor.Client.Telemetry;

var meterProvider = Sdk.CreateMeterProviderBuilder()
    .AddMeter(MetricsCollector.MeterName)   // "Conductor.Client"
    .AddPrometheusHttpListener(options =>
    {
        options.UriPrefixes = new[] { "http://*:9090/" };
    })
    .Build();

// ... start the host ...

// Dispose when shutting down.
meterProvider?.Dispose();

Metrics are now available at http://localhost:9090/metrics in Prometheus text format.

For quick debugging, the OpenTelemetry console exporter prints metrics to stdout:

dotnet add package OpenTelemetry.Exporter.Console

var meterProvider = Sdk.CreateMeterProviderBuilder()
    .AddMeter(MetricsCollector.MeterName)
    .AddConsoleExporter()
    .Build();

Monotonically increasing values. Prometheus exposes them with a _total suffix.

Distribution metrics with sum, count, and bucket breakdowns. All time values are in seconds. All size values are in bytes.

Point-in-time values sampled by the metrics listener.

When scraped by Prometheus (via the OpenTelemetry exporter), the output looks like:

# HELP task_poll_total Total task poll attempts
# TYPE task_poll_total counter
task_poll_total{task_type="my_worker"} 142

# HELP task_poll_time_seconds Task poll round-trip duration (seconds)
# TYPE task_poll_time_seconds histogram
task_poll_time_seconds_bucket{task_type="my_worker",le="0.005"} 12
task_poll_time_seconds_bucket{task_type="my_worker",le="0.01"} 45
task_poll_time_seconds_bucket{task_type="my_worker",le="0.025"} 98
task_poll_time_seconds_bucket{task_type="my_worker",le="0.05"} 120
task_poll_time_seconds_bucket{task_type="my_worker",le="0.1"} 135
task_poll_time_seconds_bucket{task_type="my_worker",le="0.25"} 140
task_poll_time_seconds_bucket{task_type="my_worker",le="0.5"} 142
task_poll_time_seconds_bucket{task_type="my_worker",le="1"} 142
task_poll_time_seconds_bucket{task_type="my_worker",le="+Inf"} 142
task_poll_time_seconds_sum{task_type="my_worker"} 3.842
task_poll_time_seconds_count{task_type="my_worker"} 142

# HELP task_execute_time_seconds Task execution duration (seconds)
# TYPE task_execute_time_seconds histogram
task_execute_time_seconds_bucket{task_type="my_worker",le="0.25"} 50
task_execute_time_seconds_bucket{task_type="my_worker",le="0.5"} 80
task_execute_time_seconds_bucket{task_type="my_worker",le="1"} 110
task_execute_time_seconds_bucket{task_type="my_worker",le="2.5"} 135
task_execute_time_seconds_bucket{task_type="my_worker",le="+Inf"} 142
task_execute_time_seconds_sum{task_type="my_worker"} 98.553
task_execute_time_seconds_count{task_type="my_worker"} 142

# HELP active_workers Workers currently executing tasks
# TYPE active_workers gauge
active_workers{task_type="my_worker"} 5

# HELP task_execution_queue_full_total Polls returning zero capacity
# TYPE task_execution_queue_full_total counter
task_execution_queue_full_total{task_type="my_worker"} 3

1. Use the OpenTelemetry Prometheus exporter for production. It serves a standard /metrics endpoint that Prometheus can scrape directly.

2. Set histogram bucket boundaries via OpenTelemetry Views if the defaults don't match your workload. For example, if your workers are consistently fast (< 100ms), add more fine-grained lower buckets:

   builder.AddView("task_execute_time_seconds",
       new ExplicitBucketHistogramConfiguration
       {
           Boundaries = new double[] { 0.001, 0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5 }
       });

3. Alert on task_update_error_total. A non-zero rate means task results are being lost after all retries are exhausted -- this is a critical failure.

4. Monitor task_execution_queue_full_total. A sustained rate indicates the worker needs more capacity (increase BatchSize or add replicas).

5. Use rate() on counters, not raw values. For example:

   rate(task_poll_total{task_type="my_worker"}[5m])
   

6. Track p99 execution latency using histogram quantiles:

   histogram_quantile(0.99, rate(task_execute_time_seconds_bucket[5m]))
   

7. The MetricsCollector is available as a singleton via DI. You can inject it into your own services to record workflow_start_error_total, external_payload_used_total, or any other metrics that occur outside the poll loop.