prometheus-net 8.0.0

The ID prefix of this package has been reserved for one of the owners of this package by Prefix Reserved
.NET 6.0 .NET Standard 2.0 .NET Framework 4.6.2
dotnet add package prometheus-net --version 8.0.0
NuGet\Install-Package prometheus-net -Version 8.0.0
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="prometheus-net" Version="8.0.0" />
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add prometheus-net --version 8.0.0
#r "nuget: prometheus-net, 8.0.0"
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
// Install prometheus-net as a Cake Addin
#addin nuget:?package=prometheus-net&version=8.0.0

// Install prometheus-net as a Cake Tool
#tool nuget:?package=prometheus-net&version=8.0.0


This is a .NET library for instrumenting your applications and exporting metrics to Prometheus.

Build status Nuget Nuget

alternate text is missing from this package README image

The library targets the following runtimes (and newer):

  • .NET Framework 4.6.2
  • .NET 6.0

Table of contents

Best practices and usage

This library allows you to instrument your code with custom metrics and provides some built-in metric collection integrations for ASP.NET Core.

The documentation here is only a minimal quick start. For detailed guidance on using Prometheus in your solutions, refer to the prometheus-users discussion group. You are also expected to be familiar with the Prometheus user guide. /r/PrometheusMonitoring on Reddit may also prove a helpful resource.

Four types of metrics are available: Counter, Gauge, Summary and Histogram. See the documentation on metric types and instrumentation best practices to learn what each is good for.

The Metrics class is the main entry point to the API of this library. The most common practice in C# code is to have a static readonly field for each metric that you wish to export from a given class.

More complex patterns may also be used (e.g. combining with dependency injection). The library is quite tolerant of different usage models - if the API allows it, it will generally work fine and provide satisfactory performance. The library is thread-safe.

Quick start

After installing the library, you should:

  1. Collect some metrics, either by using built-in integrations or publishing your own custom metrics.
  2. Export the collected metrics over an HTTP endpoint (typically /metrics).
  3. Configure a Prometheus server to poll this endpoint for metrics on a regular interval.

Minimal sample app (based on .NET 6 Console app template):

using var server = new Prometheus.KestrelMetricServer(port: 1234);

Console.WriteLine("Open http://localhost:1234/metrics in a web browser.");
Console.WriteLine("Press enter to exit.");

Refer to the sample projects for quick start instructions:

Name Description
Sample.Web ASP.NET Core application that produces custom metrics and uses multiple integrations to publish built-in metrics
Sample.Console .NET console application that exports custom metrics
Sample.Console.DotNetMeters Demonstrates how to publish custom metrics via the .NET Meters API
Sample.Console.Exemplars .NET console application that attaches exemplars to some metrics
Sample.Console.NetFramework Same as above but targeting .NET Framework
Sample.Console.NoAspNetCore .NET console application that exports custom metrics without requiring the ASP.NET Core runtime to be installed
Sample.Grpc ASP.NET Core application that publishes a gRPC service
Sample.Grpc.Client Client app for the above
Sample.NetStandard Demonstrates how to reference prometheus-net in a .NET Standard class library
Sample.Web.DifferentPort Demonstrates how to set up the metric exporter on a different port from the main web API (e.g. for security purposes)
Sample.Web.MetricExpiration Demonstrates how to use automatic metric deletion
Sample.Web.NetFramework .NET Framework web app that publishes custom metrics

The rest of this document describes how to use individual features of the library.


Nuget package for general use and metrics export via HttpListener or to Pushgateway: prometheus-net

Install-Package prometheus-net

Nuget package for ASP.NET Core middleware and stand-alone Kestrel metrics server: prometheus-net.AspNetCore

Install-Package prometheus-net.AspNetCore

Nuget package for ASP.NET Core Health Check integration: prometheus-net.AspNetCore.HealthChecks

Install-Package prometheus-net.AspNetCore.HealthChecks

Nuget package for ASP.NET Core gRPC integration: prometheus-net.AspNetCore.Grpc

Install-Package prometheus-net.AspNetCore.Grpc

Nuget package for ASP.NET Web API middleware on .NET Framework: prometheus-net.NetFramework.AspNet

Install-Package prometheus-net.NetFramework.AspNet


Counters only increase in value and reset to zero when the process restarts.

private static readonly Counter ProcessedJobCount = Metrics
    .CreateCounter("myapp_jobs_processed_total", "Number of processed jobs.");




Gauges can have any numeric value and change arbitrarily.

private static readonly Gauge JobsInQueue = Metrics
    .CreateGauge("myapp_jobs_queued", "Number of jobs waiting for processing in the queue.");




var job = jobQueue.Dequeue();


Histograms track the size and number of events in buckets. This allows for aggregatable calculation of quantiles.

private static readonly Histogram OrderValueHistogram = Metrics
    .CreateHistogram("myapp_order_value_usd", "Histogram of received order values (in USD).",
        new HistogramConfiguration
            // We divide measurements in 10 buckets of $100 each, up to $1000.
            Buckets = Histogram.LinearBuckets(start: 100, width: 100, count: 10)




Summaries track the trends in events over time (10 minutes by default).

private static readonly Summary RequestSizeSummary = Metrics
    .CreateSummary("myapp_request_size_bytes", "Summary of request sizes (in bytes) over last 10 minutes.");



By default, only the sum and total count are reported. You may also specify quantiles to measure:

private static readonly Summary RequestSizeSummary = Metrics
    .CreateSummary("myapp_request_size_bytes", "Summary of request sizes (in bytes) over last 10 minutes.",
        new SummaryConfiguration
            Objectives = new[]
                new QuantileEpsilonPair(0.5, 0.05),
                new QuantileEpsilonPair(0.9, 0.05),
                new QuantileEpsilonPair(0.95, 0.01),
                new QuantileEpsilonPair(0.99, 0.005),

The epsilon indicates the absolute error allowed in measurements. For more information, refer to the Prometheus documentation on summaries and histograms.

Measuring operation duration

Timers can be used to report the duration of an operation (in seconds) to a Summary, Histogram, Gauge or Counter. Wrap the operation you want to measure in a using block.

private static readonly Histogram LoginDuration = Metrics
    .CreateHistogram("myapp_login_duration_seconds", "Histogram of login call processing durations.");


using (LoginDuration.NewTimer())

Tracking in-progress operations

You can use Gauge.TrackInProgress() to track how many concurrent operations are taking place. Wrap the operation you want to track in a using block.

private static readonly Gauge DocumentImportsInProgress = Metrics
    .CreateGauge("myapp_document_imports_in_progress", "Number of import operations ongoing.");


using (DocumentImportsInProgress.TrackInProgress())

Counting exceptions

You can use Counter.CountExceptions() to count the number of exceptions that occur while executing some code.

private static readonly Counter FailedDocumentImports = Metrics
    .CreateCounter("myapp_document_imports_failed_total", "Number of import operations that failed.");


FailedDocumentImports.CountExceptions(() => DocumentRepository.ImportDocument(path));

You can also filter the exception types to observe:

FailedDocumentImports.CountExceptions(() => DocumentRepository.ImportDocument(path), IsImportRelatedException);

bool IsImportRelatedException(Exception ex)
    // Do not count "access denied" exceptions - those are user error for pointing us to a forbidden file.
    if (ex is UnauthorizedAccessException)
        return false;

    return true;


All metrics can have labels, allowing grouping of related time series.

See the best practices on naming and labels.

Taking a counter as an example:

private static readonly Counter RequestCountByMethod = Metrics
    .CreateCounter("myapp_requests_total", "Number of requests received, by HTTP method.", labelNames: new[] { "method" });


// You can specify the values for the labels later, once you know the right values (e.g in your request handler code).

NB! Best practices of metric design is to minimize the number of different label values. For example:

  • HTTP request method is a good choice for labeling - there are not many values.
  • URL is a bad choice for labeling - it has many possible values and would lead to significant data processing inefficiency.

Static labels

You can add static labels that always have fixed values. This is possible on two levels:

  • on the metrics registry (e.g. Metrics.DefaultRegistry)
  • on a metric factory (e.g. Metrics.WithLabels())

All levels of labeling can be combined and instance-specific metric labels can also be applied on top, as usual.

Example with static labels on two levels and one instance-specific label:

Metrics.DefaultRegistry.SetStaticLabels(new Dictionary<string, string>
  // Labels applied to all metrics in the registry.
  { "environment", "testing" }

var backgroundServicesMetricFactory = Metrics.WithLabels(new Dictionary<string, string>
  // Labels applied to all metrics created via this factory.
  { "category", "background-services" }

var requestsHandled = backgroundServicesMetricFactory
  .CreateCounter("myapp_requests_handled_total", "Count of requests handled, labelled by response code.", labelNames: new[] { "response_code" });

// Labels applied to individual instances of the metric.


Exemplars facilitate distributed tracing, by attaching related trace IDs to metrics. This enables a metrics visualization app to cross-reference traces that explain how the metric got the value it has.

alternate text is missing from this package README image

See also, Grafana fundamentals - introduction to exemplars.

By default, prometheus-net will create an exemplar with the trace_id and span_id labels based on the current distributed tracing context (Activity.Current). If using OpenTelemetry tracing with ASP.NET Core, the traceparent HTTP request header will be used to automatically assign Activity.Current.

private static readonly Counter TotalSleepTime = Metrics
    .CreateCounter("sample_sleep_seconds_total", "Total amount of time spent sleeping.");

// You only need to create the Activity if one is not automatically assigned (e.g. by ASP.NET Core).
using (var activity = new Activity("Pausing before record processing").Start())
    var sleepStopwatch = Stopwatch.StartNew();
    await Task.Delay(TimeSpan.FromSeconds(1));

    // The trace_id and span_id from the current Activity are exposed as the exemplar.

This will be published as the following metric point:

sample_sleep_seconds_total 251.03833569999986 # {trace_id="08ad1c8cec52bf5284538abae7e6d26a",span_id="4761a4918922879b"} 1.0010688 1672634812.125

You can override any default exemplar logic by providing your own exemplar when updating the value of the metric:

private static readonly Counter RecordsProcessed = Metrics
    .CreateCounter("sample_records_processed_total", "Total number of records processed.");

// The key from an exemplar key-value pair should be created once and reused to minimize memory allocations.
private static readonly Exemplar.LabelKey RecordIdKey = Exemplar.Key("record_id");

foreach (var record in recordsToProcess)
    var exemplar = Exemplar.From(RecordIdKey.WithValue(record.Id.ToString()));

Warning Exemplars are limited to 128 ASCII characters (counting both keys and values) - they are meant to contain IDs for cross-referencing with trace databases, not as a replacement for trace databases.

Exemplars are only published if the metrics are being scraped by an OpenMetrics-capable client. For development purposes, you can force the library to use the OpenMetrics exposition format by adding ?accept=application/openmetrics-text to the /metrics URL.

Note The Prometheus database automatically negotiates OpenMetrics support when scraping metrics - you do not need to apply any special scraping configuration in production scenarios. You may need to enable exemplar storage, though.

See also, Sample.Console.Exemplars.

Limiting exemplar volume

Exemplars can be expensive to store in the metrics database. For this reason, it can be useful to only record exemplars for "interesting" metric values.

You can use ExemplarBehavior.NewExemplarMinInterval to define a minimum interval between exemplars - a new exemplar will only be recorded if this much time has passed. This can be useful to limit the rate of publishing unique exemplars.

You can customize the default exemplar provider via IMetricFactory.ExemplarBehavior or CounterConfiguration.ExemplarBehavior and HistogramConfiguration.ExemplarBehavior, which allows you to provide your own method to generate exemplars and to filter which values/metrics exemplars are recorded for:

Example of a custom exemplar provider used together with exemplar rate limiting:

// For the next histogram we only want to record exemplars for values larger than 0.1 (i.e. when record processing goes slowly).
static Exemplar RecordExemplarForSlowRecordProcessingDuration(Collector metric, double value)
    if (value < 0.1)
        return Exemplar.None;

    return Exemplar.FromTraceContext();

var recordProcessingDuration = Metrics
    .CreateHistogram("sample_record_processing_duration_seconds", "How long it took to process a record, in seconds.",
    new HistogramConfiguration
        Buckets = Histogram.PowersOfTenDividedBuckets(-4, 1, 5),
        ExemplarBehavior = new()
            DefaultExemplarProvider = RecordExemplarForSlowRecordProcessingDuration,
            // Even if we have interesting data more often, do not record it to conserve exemplar storage.
            NewExemplarMinInterval = TimeSpan.FromMinutes(5)

For the ASP.NET Core HTTP server metrics, you can further fine-tune exemplar recording by inspecting the HTTP request and response:

app.UseHttpMetrics(options =>
    options.ConfigureMeasurements(measurementOptions =>
        // Only measure exemplar if the HTTP response status code is not "OK".
        measurementOptions.ExemplarPredicate = context => context.Response.StatusCode != HttpStatusCode.Ok;

When are metrics published?

Metrics without labels are published immediately after the Metrics.CreateX() call. Metrics that use labels are published when you provide the label values for the first time.

Sometimes you want to delay publishing a metric until you have loaded some data and have a meaningful value to supply for it. The API allows you to suppress publishing of the initial value until you decide the time is right.

private static readonly Gauge UsersLoggedIn = Metrics
    .CreateGauge("myapp_users_logged_in", "Number of active user sessions",
        new GaugeConfiguration
            SuppressInitialValue = true


// After setting the value for the first time, the metric becomes published.

You can also use .Publish() on a metric to mark it as ready to be published without modifying the initial value (e.g. to publish a zero). Conversely, you can use .Unpublish() to hide a metric temporarily. Note that the metric remains in memory and retains its value.

Deleting metrics

You can use .Dispose() or .RemoveLabelled() methods on the metric classes to manually delete metrics at any time.

In some situations, it can be hard to determine when a metric with a specific set of labels becomes irrelevant and needs to be removed. The library provides some assistance here by enabling automatic expiration of metrics when they are no longer used.

To enable automatic expiration, create the metrics via the metric factory returned by Metrics.WithManagedLifetime(). All such metrics will have a fixed expiration time, with the expiration restarting based on certain conditions that indicate the metric is in use.

Option 1: metric lifetime can be controlled by leases - the metric expiration timer starts when the last lease is released (and will be reset when a new lease is taken again).

var factory = Metrics.WithManagedLifetime(expiresAfter: TimeSpan.FromMinutes(5));

// With expiring metrics, we get back handles to the metric, not the metric directly.
var inProgressHandle = expiringMetricFactory
  .CreateGauge("documents_in_progress", "Number of documents currently being processed.",
    // Automatic metric deletion only makes sense if we have a high/unknown cardinality label set,
    // so here is a sample label for each "document provider", whoever that may be.
    labelNames: new[] { "document_provider" });


public void ProcessDocument(string documentProvider)
  // Automatic metric deletion will not occur while this lease is held.
  // This will also reset any existing expiration timer for this document provider.
  inProgressHandle.WithLease(metric =>
    using (metric.TrackInProgress())
  }, documentProvider);
  // Lease is released here.
  // If this was the last lease for this document provider, the expiration timer will now start.

Scenario 2: sometimes managing the leases is not required because you simply want the metric lifetime to be extended whenever the value is updated.

var factory = Metrics.WithManagedLifetime(expiresAfter: TimeSpan.FromMinutes(5));

// With expiring metrics, we get back handles to the metric, not the metric directly.
var processingStartedHandle = expiringMetricFactory
  .CreateGauge("documents_started_processing_total", "Number of documents for which processing has started.",
    // Automatic metric deletion only makes sense if we have a high/unknown cardinality label set,
    // so here is a sample label for each "document provider", whoever that may be.
    labelNames: new[] { "document_provider" });

// This returns a metric instance that will reset the expiration timer whenever the metric value is updated.
var processingStarted = processingStartedHandle.WithExtendLifetimeOnUse();


public void ProcessDocument(string documentProvider)
  // This will reset the expiration timer for this document provider.


The expiration logic is scoped to the factory. Multiple handles for the same metric from the same factory will share their expiration logic. However, handles for the same metric from different factories will have independent expiration logic.

See also, Sample.Web.MetricExpiration.

ASP.NET Core exporter middleware

For projects built with ASP.NET Core, a middleware plugin is provided.

If you use the default Visual Studio project templates, modify the UseEndpoints call as follows:

  • Add endpoints.MapMetrics() anywhere in the delegate body.
public void Configure(IApplicationBuilder app, ...)
    // ...

    app.UseEndpoints(endpoints =>
        // ...


The default configuration will publish metrics on the /metrics URL.

The ASP.NET Core functionality is delivered in the prometheus-net.AspNetCore NuGet package.

See also, Sample.Web.

ASP.NET Core HTTP request metrics

The library exposes some metrics from ASP.NET Core applications:

  • Number of HTTP requests in progress.
  • Total number of received HTTP requests.
  • Duration of HTTP requests.

The ASP.NET Core functionality is delivered in the prometheus-net.AspNetCore NuGet package.

You can expose HTTP metrics by modifying your Startup.Configure() method:

  • After app.UseRouting() add app.UseHttpMetrics().

Example Startup.cs:

public void Configure(IApplicationBuilder app, ...)
    // ...


    // ...

By default, metrics are collected separately for each response status code (200, 201, 202, 203, ...). You can considerably reduce the size of the data set by only preserving information about the first digit of the status code:

app.UseHttpMetrics(options =>
    // This will preserve only the first digit of the status code.
    // For example: 200, 201, 203 -> 2xx

NB! Exception handler middleware that changes HTTP response codes must be registered after UseHttpMetrics() in order to ensure that prometheus-net reports the correct HTTP response status code.

The action, controller and endpoint route parameters are always captured by default. If Razor Pages is in use, the page label will be captured to show the path to the page.

You can include additional route parameters as follows:

app.UseHttpMetrics(options =>
    // Assume there exists a custom route parameter with this name.

You can also extract arbitrary data from the HttpContext into label values as follows:

app.UseHttpMetrics(options =>
    options.AddCustomLabel("host", context => context.Request.Host.Host);

See also, Sample.Web.

ASP.NET Core gRPC request metrics

The library allows you to expose some metrics from ASP.NET Core gRPC services. These metrics include labels for service and method name.

You can expose gRPC metrics by modifying your Startup.Configure() method:

  • After app.UseRouting() add app.UseGrpcMetrics().

Example Startup.cs:

public void Configure(IApplicationBuilder app, ...)
    // ...


    // ...

The gRPC functionality is delivered in the prometheus-net.AspNetCore.Grpc NuGet package.

See also, Sample.Grpc.

IHttpClientFactory metrics

This library allows you to expose metrics about HttpClient instances created using IHttpClientFactory.

The exposed metrics include:

  • Number of HTTP requests in progress.
  • Total number of started HTTP requests.
  • Duration of HTTP client requests (from start of request to end of reading response headers).
  • Duration of HTTP client responses (from start of request to end of reading response body).

Example Startup.cs modification to enable these metrics:

public void ConfigureServices(IServiceCollection services)
    // ...


    // ...

See also, Sample.Web.

ASP.NET Core health check status metrics

You can expose the current status of ASP.NET Core health checks as Prometheus metrics by extending your IHealthChecksBuilder in the Startup.ConfigureServices() method:

public void ConfigureServices(IServiceCollection services, ...)
    // ...

        // ...
        <Your Health Checks>
        // ...

    // ...

The status of each health check will be published in the aspnetcore_healthcheck_status metric.

The ASP.NET Core health check integration is delivered in the prometheus-net.AspNetCore.HealthChecks NuGet package.

See also, Sample.Web.

Protecting the metrics endpoint from unauthorized access

You may wish to restrict access to the metrics export URL. Documentation on how to apply ASP.NET Core security mechanisms is beyond the scope of this readme file but a good starting point may be to require an authorization policy to be satisfied for accessing the endpoint

app.UseEndpoints(endpoints =>
    // ...

    // Assumes that you have previously configured the "ReadMetrics" policy (not shown).

Another commonly used option is to expose a separate web server endpoint (e.g. a new KestrelMetricServer instance) on a different port, with firewall rules limiting access to only certain IP addresses. Refer to the sample project Sample.Web.DifferentPort.

ASP.NET Web API exporter

The easiest way to export metrics from an ASP.NET Web API app on the full .NET Framework is to use AspNetMetricServer in your Global.asax.cs file. Insert the following line to the top of the Application_Start method:

protected void Application_Start(object sender, EventArgs e)

    // Other code follows.

The above snippet exposes metrics on the /metrics URL.

The AspNetMetricServer class is provided by the prometheus-net.NetFramework.AspNet NuGet package.

Kestrel stand-alone server

In some situation, you may wish to start a stand-alone metric server using Kestrel (e.g. if your app has no other HTTP-accessible functionality).

var metricServer = new KestrelMetricServer(port: 1234);

The default configuration will publish metrics on the /metrics URL.

If your app is an ASP.NET Core web app, you can use a pipeline-integrated mechanism:

services.AddMetricServer(options =>
    options.Port = 1234;

Publishing to Pushgateway

Metrics can be posted to a Pushgateway server.

var pusher = new MetricPusher(new MetricPusherOptions
    Endpoint = "",
    Job = "some_job"


Note that the default behavior of the metric pusher is to append metrics. You can use MetricPusherOptions.ReplaceOnPush to make it replace existing metrics in the same group, removing any that are no longer pushed.

Publishing to Pushgateway with basic authentication

You can use a custom HttpClient to supply credentials for the Pushgateway.

// Placeholder username and password here - replace with your own data.
var headerValue = Convert.ToBase64String(Encoding.UTF8.GetBytes("username:password"));
var httpClient = new HttpClient();
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", headerValue);

var pusher = new MetricPusher(new MetricPusherOptions
    Endpoint =  "",
    Job = "some_job",
    HttpClientProvider = () => httpClient


Publishing via standalone HTTP handler

As a fallback option for scenarios where Kestrel or ASP.NET Core hosting is unsuitable, an HttpListener based metrics server implementation is also available.

var metricServer = new MetricServer(port: 1234);

The default configuration will publish metrics on the /metrics URL.

MetricServer.Start() may throw an access denied exception on Windows if your user does not have the right to open a web server on the specified port. You can use the netsh command to grant yourself the required permissions:

netsh http add urlacl url=http://+:1234/metrics user=DOMAIN\user

Publishing raw metrics document

In scenarios where you handle publishing via a custom endpoint, you can export the entire metrics data set as a Prometheus text document.

await Metrics.DefaultRegistry.CollectAndExportAsTextAsync(outputStream);

Just-in-time updates

In some scenarios you may want to only collect data when it is requested by Prometheus. To easily implement this scenario prometheus-net enables you to register a callback before every collection occurs. Register your callback using Metrics.DefaultRegistry.AddBeforeCollectCallback().

Every callback will be executed before each collection, which will not finish until every callback has finished executing. Prometheus will expect each scrape to complete within a certain amount of seconds. To avoid timeouts, ensure that any registered callbacks execute quickly.

  • A synchronous callback (of type Action) should not take more than a few milliseconds. Do not read data from remote systems in these callbacks.
  • An asynchronous callback (of type Func<CancellationToken, Task>) is more suitable for long-running data collection work (lasting a few seconds). You can use asynchronous callbacks for reading data from remote systems.
Metrics.DefaultRegistry.AddBeforeCollectCallback(async (cancel) =>
    // Probe a remote system.
    var response = await httpClient.GetAsync("", cancel);

    // Increase a counter by however many bytes we loaded.
    googlePageBytes.Inc(response.Content.Headers.ContentLength ?? 0);

Suppressing default metrics

The library enables various default metrics and integrations by default. If these default metrics are not desirable you may remove them by calling Metrics.SuppressDefaultMetrics() before registering any of your own metrics.

DiagnosticSource integration

.NET Core provides the DiagnosticSource mechanism for reporting diagnostic events, used widely by .NET and ASP.NET Core classes. To expose basic data on these events via Prometheus, you can use the DiagnosticSourceAdapter class:

// An optional "options" parameter is available to customize adapter behavior.
var registration = DiagnosticSourceAdapter.StartListening();


// Stops listening for DiagnosticSource events.

Any events that occur are exported as Prometheus metrics, indicating the name of the event source and the name of the event:

diagnostic_events_total{source="Microsoft.AspNetCore",event="Microsoft.AspNetCore.Mvc.AfterAction"} 4
diagnostic_events_total{source="HttpHandlerDiagnosticListener",event="System.Net.Http.Request"} 8

The level of detail obtained from this is rather low - only the total count for each event is exported. For more fine-grained analytics, you need to listen to DiagnosticSource events on your own and create custom metrics that can understand the meaning of each particular type of event that is of interest to you.

EventCounter integration

Note The output produced by this integration has changed significantly between prometheus-net 6.0 and prometheus-net 7.0. The old output format is no longer supported.

.NET Core provides the EventCounter mechanism for reporting diagnostic events, used used widely by .NET and ASP.NET Core classes. This library publishes all .NET EventCounter data by default. To suppress this, see Suppressing default metrics.

You can configure the integration using Metrics.ConfigureEventCounterAdapter().

By default, prometheus-net will only publish the well-known .NET EventCounters to minimize resource consumption in the default configuration. A custom event source filter must be provided in the configuration to enable publishing of additional event counters.

See also, Sample.Console.

.NET Meters integration

Note The output produced by this integration has changed significantly between prometheus-net 6.0 and prometheus-net 7.0. The old output format is no longer supported.

.NET provides the Meters mechanism for reporting diagnostic metrics. This library publishes all .NET Meters API data by default. To suppress this, see Suppressing default metrics.

You can configure the integration using Metrics.ConfigureMeterAdapter().

See also, Sample.Console.DotNetMeters.


A suite of benchmarks is included if you wish to explore the performance characteristics of the library. Simply build and run the Benchmarks.NetCore project in Release mode.

As an example of the performance of measuring data using prometheus-net, we have the results of the MeasurementBenchmarks here, converted into measurements per second:

Metric type Concurrency Measurements per second
Gauge 1 thread 521 million
Counter 1 thread 87 million
Histogram 1 thread 46 million
Summary 1 thread 2 million
Gauge 16 threads 55 million
Counter 16 threads 10 million
Histogram 16 threads 14 million
Summary 16 threads 2 million

Note All measurements on all threads are recorded by the same metric instance, for maximum stress and concurrent load. In real-world apps with the load spread across multiple metrics, you can expect even better performance.

Another popular .NET SDK with Prometheus support is the OpenTelemetry SDK. To help you choose, we have SdkComparisonBenchmarks.cs to compare the two SDKs and give some idea of how they differer in the performance tradeoffs made. Both SDKs are evaluated in single-threaded mode under a comparable workload and enabled feature set.

alternate text is missing from this package README image alternate text is missing from this package README image alternate text is missing from this package README image alternate text is missing from this package README image

Note As authors of this SDK are not necessarily experts in use of other SDKs, please feel free to submit pull requests with benchmark improvements to better highlight the strengths or weaknesses here.

Community projects

Some useful related projects are:

Note: to avoid confusion between "official" prometheus-net and community maintained packages, the prometheus-net namespace is protected on However, the prometheus-net.Contrib.* namespace allows package publishing by all authors.

Product Compatible and additional computed target framework versions.
.NET net5.0 was computed.  net5.0-windows was computed.  net6.0 is compatible.  net6.0-android was computed.  net6.0-ios was computed.  net6.0-maccatalyst was computed.  net6.0-macos was computed.  net6.0-tvos was computed.  net6.0-windows was computed.  net7.0 is compatible.  net7.0-android was computed.  net7.0-ios was computed.  net7.0-maccatalyst was computed.  net7.0-macos was computed.  net7.0-tvos was computed.  net7.0-windows was computed. 
.NET Core netcoreapp2.0 was computed.  netcoreapp2.1 was computed.  netcoreapp2.2 was computed.  netcoreapp3.0 was computed.  netcoreapp3.1 was computed. 
.NET Standard netstandard2.0 is compatible.  netstandard2.1 was computed. 
.NET Framework net461 was computed.  net462 is compatible.  net463 was computed.  net47 was computed.  net471 was computed.  net472 was computed.  net48 was computed.  net481 was computed. 
MonoAndroid monoandroid was computed. 
MonoMac monomac was computed. 
MonoTouch monotouch was computed. 
Tizen tizen40 was computed.  tizen60 was computed. 
Xamarin.iOS xamarinios was computed. 
Xamarin.Mac xamarinmac was computed. 
Xamarin.TVOS xamarintvos was computed. 
Xamarin.WatchOS xamarinwatchos was computed. 
Compatible target framework(s)
Additional computed target framework(s)
Learn more about Target Frameworks and .NET Standard.

NuGet packages (117)

Showing the top 5 NuGet packages that depend on prometheus-net:

Package Downloads
prometheus-net.AspNetCore The ID prefix of this package has been reserved for one of the owners of this package by

ASP.NET Core middleware and stand-alone Kestrel server for exporting metrics to Prometheus


Client library for the Kubernetes open source container orchestrator.


Exposes .NET core runtime metrics (GC, JIT, lock contention, thread pool, exceptions) using the prometheus-net package.

MassTransit.Prometheus The ID prefix of this package has been reserved for one of the owners of this package by

MassTransit Prometheus support; MassTransit provides a developer-focused, modern platform for creating distributed applications without complexity.


Exposes .NET core diagnostic listeners and counters

GitHub repositories (23)

Showing the top 5 popular GitHub repositories that depend on prometheus-net:

Repository Stars
The Free Software Media System
A toolkit for developing high-performance HTTP reverse proxy applications.
Distributed Application Framework for .NET
Enterprise HealthChecks for ASP.NET Core Diagnostics Package
Proto Actor - Ultra fast distributed actors for Go, C# and Java/Kotlin
Version Downloads Last updated
8.0.0 1,673,690 2/17/2023
8.0.0-pre-230212122408-a055f5b 2,768 2/12/2023
8.0.0-pre-230210074852-a7c1277 109 2/10/2023
8.0.0-pre-230209100041-c35ac64 1,078 2/9/2023
8.0.0-pre-230209074620-4f8f59c 78 2/9/2023
8.0.0-pre-230203154858-4bf76fb 514 2/3/2023
8.0.0-pre-230203125716-1813839 86 2/3/2023
8.0.0-pre-230203073826-06c2e2f 273 2/3/2023
8.0.0-pre-230201062733-ece2743 247 2/1/2023
8.0.0-pre-230127154206-9ec9e9b 1,265 1/27/2023
8.0.0-pre-230127124604-8b7c7e1 93 1/27/2023
8.0.0-pre-230127111923-d72115a 103 1/27/2023
8.0.0-pre-230127084218-90f4311 96 1/27/2023
8.0.0-pre-230127075825-bfc1041 108 1/27/2023
8.0.0-pre-230126143551-210a1ab 139 1/26/2023
8.0.0-pre-230119065217-312c2e9 2,049 1/19/2023
8.0.0-pre-230116052305-1ed397b 738 1/16/2023
8.0.0-pre-230102092516-2351266 2,136 1/2/2023
8.0.0-pre-230101195105-9f23889 99 1/1/2023
8.0.0-pre-230101084444-630935f 88 1/1/2023
8.0.0-pre-221231102537-13e7ac6 101 12/31/2022
8.0.0-pre-221231100152-fb39dcb 89 12/31/2022
8.0.0-pre-000351-fb39dcb 89 12/31/2022
8.0.0-pre-000347-e83cc87 92 12/30/2022
8.0.0-pre-000346-e83cc87 89 12/30/2022
8.0.0-pre-000342-4d6812e 203 12/29/2022
7.1.0-pre-000318-0479f53 15,497 11/15/2022
7.1.0-pre-000310-9c9e1e9 3,844 11/7/2022
7.1.0-pre-000307-f980713 1,419 10/27/2022
7.0.0 3,925,878 10/26/2022
7.0.0-pre-000305-75cc817 4,124 10/17/2022
7.0.0-pre-000304-cbb305a 114 10/17/2022
7.0.0-pre-000303-5a44ada 358 10/16/2022
7.0.0-pre-000301-06c5932 360 10/13/2022
7.0.0-pre-000298-4b8d3e7 129 10/13/2022
7.0.0-pre-000297-7068d28 120 10/13/2022
7.0.0-pre-000296-5b1a1c4 5,004 10/5/2022
7.0.0-pre-000294-486fcd8 140 10/5/2022
7.0.0-pre-000293-d13fe06 508 10/4/2022
7.0.0-pre-000292-88fbe2a 124 10/4/2022
7.0.0-pre-000288-4688bd3 651 10/2/2022
7.0.0-pre-000282-d90ebf3 1,237 9/28/2022
7.0.0-pre-000280-ce6d494 128 9/28/2022
7.0.0-pre-000277-6bc5023 201 9/27/2022
7.0.0-pre-000276-9e65611 304 9/23/2022
7.0.0-pre-000270-ee6c23e 139 9/23/2022
7.0.0-pre-000269-08d9f2c 134 9/22/2022
7.0.0-pre-000259-7317089 527 9/21/2022
7.0.0-pre-000244-66d82e6 217 9/19/2022
6.0.0 12,491,390 3/3/2022
6.0.0-pre-000234-4598e28 171 3/3/2022
6.0.0-pre-000233-0dd30d3 970 3/2/2022
6.0.0-pre-000231-38d45fa 24,711 2/20/2022
6.0.0-pre-000223-ab9edeb 189 2/18/2022
5.1.0-pre-000215-c81d12d 9,355 1/22/2022
5.0.2 5,870,745 11/19/2021
5.0.2-pre-000210-fbf24c8 1,662 11/19/2021
5.0.1 8,363,802 8/19/2021
5.0.1-pre-000202-59e0610 288 8/19/2021
5.0.0 117,777 8/18/2021
5.0.0-pre-000201-8d79f11 2,125 7/30/2021
5.0.0-pre-000200-0afede9 470 7/30/2021
4.3.0-pre-000199-35f4961 327 7/29/2021
4.3.0-pre-000198-79466f7 340 7/29/2021
4.2.0 3,002,231 7/6/2021
4.2.0-pre-000195-ec10b08 295 7/6/2021
4.2.0-pre-000194-7aacfb0 291 7/6/2021
4.1.1 16,759,377 12/12/2020
4.1.1-pre-000180-1cfbebb 466 12/12/2020
4.1.0 11,885 12/12/2020
4.1.0-pre-000179-9582014 452 12/12/2020
4.1.0-pre-000171-15be8f3 3,796 12/6/2020
4.0.0 2,614,080 10/18/2020
4.0.0-pre-000158-d425fff 515 10/18/2020
4.0.0-pre-000134-2fea549 58,543 7/6/2020
3.6.0 5,574,927 6/19/2020
3.6.0-pre-000131-673cfe2 514 6/19/2020
3.6.0-pre-000129-bd91778 4,458 6/16/2020
3.5.0 4,586,962 3/9/2020
3.5.0-pre-000099-ee2bdbd 10,971 3/9/2020
3.5.0-pre-000098-f9cb93e 6,764 2/9/2020
3.4.0 1,937,041 12/26/2019
3.4.0-pre-000084-e9d0f37 436 12/26/2019
3.4.0-pre-000082-546478d 2,113 12/23/2019
3.4.0-pre-000081-1712a44 433 12/23/2019
3.4.0-pre-000079-eff2a83 454 12/22/2019
3.4.0-pre-000078-34a900d 503 12/22/2019
3.4.0-pre-000077-0ace5bd 543 12/20/2019
3.4.0-pre-000067-701dfdc 436 12/19/2019
3.3.1-pre-000052-0842664 1,772 12/13/2019
3.3.0 4,438,852 10/18/2019
3.3.0-pre-000042-252e89c 463 10/18/2019
3.2.1 418,219 10/2/2019
3.2.1-pre-000036-696f4ab 437 10/2/2019
3.2.0 2,025 10/1/2019
3.2.0-pre-000035-8d4cf7d 487 10/1/2019
3.2.0-pre-000032-9939133 497 9/25/2019
3.2.0-pre-000028-abe3225 461 9/25/2019
3.2.0-pre-000027-29e0fce 461 9/25/2019
3.1.5-pre-000023-d29ca37 816 9/24/2019
3.1.5-pre-000021-8c7b328 447 9/24/2019
3.1.5-pre-000020-5a2fc50 474 9/24/2019
3.1.4 1,828,825 6/20/2019
3.1.4-pre-000016-95d0170 524 6/20/2019
3.1.3 341,405 5/30/2019
3.1.3-pre-000009-505a08e 580 5/29/2019
3.1.3-cb-000009-505a08e 491 5/29/2019
3.1.2 4,813,193 4/27/2019
3.1.2-pre-006681-4f8ce09 3,972 4/23/2019
3.1.1 184,613 4/10/2019
3.1.1-pre-006463-cd3cd18 531 4/10/2019
3.1.0 115,516 3/29/2019
3.1.0-pre-006304-959164e 544 3/27/2019
3.1.0-pre-006267-9aac888 3,451 3/22/2019
3.1.0-pre-006177-d35e0b8 722 3/15/2019
3.0.3 418,633 2/11/2019
3.0.2 7,449 2/7/2019
3.0.1 3,776 2/6/2019
3.0.0 90,305 2/5/2019
3.0.0-pre-005830-d9493da 592 2/4/2019
3.0.0-pre-005828-27b7100 574 2/4/2019
3.0.0-pre-005823-68ad8e2 590 2/4/2019
3.0.0-pre-005803-4289c4a 600 2/1/2019
3.0.0-pre-005801-6f306bc 684 1/31/2019
3.0.0-pre-005800-ec1da05 604 1/31/2019
3.0.0-pre-005795-6aca95b 620 1/30/2019
3.0.0-pre-005647-e277cbe 2,156 1/9/2019
2.1.3 1,625,986 9/25/2018
2.1.3-pre-005238-380e4ab 674 9/25/2018
2.1.2 37,581 9/6/2018
2.1.2-pre-005131-012bc01 736 9/6/2018
2.1.1-pre-004445-bc00b93 4,972 5/25/2018
2.1.0 656,097 4/13/2018
2.1.0-pre-003985-910fb52 887 4/11/2018
2.1.0-pre-003982-37c9f93 783 4/11/2018
2.0.0 248,549 2/26/2018
2.0.0-pre-003523-49de0a3 2,110 2/22/2018
2.0.0-pre-003112-3de1c34 2,684 2/7/2018
2.0.0-pre-003077-0447c86 1,805 2/5/2018
2.0.0-pre-003054-ffb96c7 937 2/1/2018
2.0.0-pre-003051-6f12a46 1,076 2/1/2018
2.0.0-pre-003009-4e26344 7,423 1/27/2018
2.0.0-pre-002968-9fcb8aa 1,034 1/25/2018
1.3.6-rc 28,627 5/5/2017
1.3.5 179,834 3/18/2017
1.3.4 8,159 3/10/2017
1.3.4-beta 942 1/16/2017
1.2.4 8,453 11/9/2016
1.2.3 1,457 10/31/2016 16,907 8/20/2016
1.1.4 2,244 7/14/2016
1.1.3 2,006 6/1/2016
1.1.2 1,184 5/21/2016
1.1.1 1,383 4/25/2016
1.1.0 1,412 3/8/2016
0.0.11 1,397 1/11/2016
0.0.10 1,114 12/19/2015
0.0.9 1,167 12/4/2015
0.0.8 1,173 12/2/2015
0.0.7 1,287 11/26/2015
0.0.6 1,198 11/18/2015
0.0.5 1,553 11/6/2015
0.0.3 1,368 4/15/2015