Register a metric with a Registry.

Throws:

• RegistrationFailure

Failures encountered when attempting to register a metric.

The metric name specifies the general feature of a system that is measured (e.g. http_requests_total - the total number of HTTP requests received). It may contain ASCII letters and digits, as well as underscores and colons. It must match the regex [a-zA-Z_:][a-zA-Z0-9_:]*.

Note that MetricName has a IsString instance. If you enable {-# LANGUAGE OverloadedStrings #-}, you can simply use string literals.

See also, the best practice for metric and label naming.

User readable help text describing what a given metric represents.

Metric describes a specific type of metric, but in an un-registered state. Pass Metrics to registerMetric to construct the metric for operation.

Append a dynamic label to a metric. A dynamic label is a label that can be assigned different values at runtime. The returned metric is a function from label value to a configured metric. The child metric inherits all of the parent metric's labels.

As an example of where you might use dynamic labels, consider the metric http_responses_total, which counts HTTP responses. If you want to track the status code, you can add a dynamic label code:

httpResponsesByCode <-
  register "http_responses_total" "HTTP responses" mempty
    (addLabel "code" counter)

-- later

okResponses <- httpResponsesByCode "200"
incCounter okResponses

A Registry is used to build up the list of all known Metrics that will be reported to Prometheus. You add a Metric to the Registry with register.

Given a computation that registers metrics, assemble a final registry.

This is really just runStateT, but with a name that has more meaning.

Build WAI middleware that responds to GET requests to path by streaming Prometheus metrics. This is the typical way to expose instrumentation, allowing Prometheus to collect metrics directly from the app by polling.

Fork a thread that collects information about the instrumentation process of this application itself. Specifically, the following metrics will be added:

• haskell_prometheus_push_latency_seconds: The latency when pushing metrics to a Pushgateway
• haskell_prometheus_push_interval_seconds: The interval between pushes
• haskell_prometheus_push_exceptions_total: Total count of exceptions while pushing metrics

A counter is a cumulative metric that represents a single numerical value that only ever goes up. A counter is typically used to count requests served, tasks completed, errors occurred, etc. Counters should not be used to expose current counts of items whose number can also go down, e.g. the number of currently running threads. Use gauges for this use case.

Create a new counter.

Increment a counter by 1.

Increment a counter by a particular amount.

Instrument some code that may throw exceptions by counting the amount of exceptions thrown. The exception will not be caught, only counted.

A gauge is a metric that represents a single numerical value that can arbitrarily go up and down.

Gauges are typically used for measured values like temperatures or current memory usage, but also "counts" that can go up and down, like the number of running threads.

Create a new gauge, initialising it at 0.

Increment a gauge by 1.

Decrement a gauge by 1.

Apply a function to move a gauge.

Set a gauge to an exact value.

A histogram samples observations (usually things like request durations or response sizes) and counts them in configurable buckets. It also provides a sum of all observed values.

Create a new histogram that samples into a specific set of buckets.

The buckets (bins) that a Histrogram can sample to.

linearBuckets start width numBuckets creates numBuckets buckets, each width wide, where the lowest bucket has an upper bound of start (assuming width is positive).

exponentialBuckets start factor numBuckets creates numBuckets buckets, where the lowest bucket has an upper bound of start and each following bucket's upper bound is factor times the previous bucket's upper bound.

Pre-defined buckets that are probably suitable for IO operations. Upper-bounds are: 1μs, 10μs, 100μs, 1ms, 10ms, 100ms, 200ms, 300ms, 400ms, 500ms, 600ms, 700ms, 800ms, 900ms, 1s, 2s, 4s, 8s, 16s.

Construct Buckets from anything list-like containing bucket upper-bounds.

The input list will be sorted, and does not need to be sorted before hand.

Record an observation into the buckets of a histogram.

Run a computation, recording how long it takes to a Histogram.