Skip to content
Go net/http configurable handler to measure HTTP requests independent of metrics backend (with Prometheus and OpenCensus as backend implementations)
Go Makefile
Branch: master
Clone or download
slok Migrate to GitHub actions (#24)
Migrate to GitHub actions
Latest commit 448665b Sep 15, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
.github Migrate to GitHub actions (#24) Sep 15, 2019
examples Update dependencies May 19, 2019
internal/mocks Add context to the metrics Recorder interface Mar 25, 2019
metrics Update dependencies May 19, 2019
middleware Update middleware framework integration tests Mar 27, 2019
.gitignore Init repository Mar 17, 2019 Add OpenCensus recorder options to readme Mar 27, 2019
LICENSE Init repository Mar 17, 2019
Makefile Add readme Mar 18, 2019 Update readme Sep 15, 2019
doc.go Add example for default case Mar 17, 2019
go.mod Update deps Jun 23, 2019
go.sum Update deps Jun 23, 2019

go-http-metrics Build Status Go Report Card GoDoc

go-http-metrics knows how to measure http metrics in different metric formats, it comes with a middleware that will measure metrics of a Go net/http handler. The metrics measured are based on RED and/or Four golden signals, follow standards and try to be measured in a efficient way.

If you are using a framework that isn't directly compatible with go's http.Handler interface from the std library, do not worry, there are multiple helpers available to get middlewares fo the most used http Go frameworks. If there isn't you can open an issue or a PR.

Table of contents


The metrics obtained with this middleware are the most important ones for a HTTP service.

  • Records the duration of the requests(with: code, handler, method).
  • Records the count of the requests(with: code, handler, method).
  • Records the size of the responses(with: code, handler, method).
  • Records the number requests being handled concurrently at a given time a.k.a inflight requests (with: handler).

Metrics recorder implementations

go-http-metrics is easy to extend to different metric backends by implementing metrics.Recorder interface.

Framework compatibility middlewares

The middleware is mainly focused to be compatible with Go std library using http.Handler, but it comes with helpers to get middlewares for other frameworks or libraries.

Getting Started

A simple example that uses Prometheus as the recorder with the standard Go handler.

package main

import (

    metrics ""

func main() {
    // Create our middleware.
    mdlw := middleware.New(middleware.Config{
        Recorder: metrics.NewRecorder(metrics.Config{}),

    // Our handler.
    myHandler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("hello world!"))
    h := mdlw.Handler("", myHandler)

    // Serve metrics.
    log.Printf("serving metrics at: %s", ":9090")
    go http.ListenAndServe(":9090", promhttp.Handler())

    // Serve our handler.
    log.Printf("listening at: %s", ":8080")
    if err := http.ListenAndServe(":8080", h); err != nil {
        log.Panicf("error while serving: %s", err)

For more examples check the examples. default and custom are the examples for Go net/http std library users.

Prometheus query examples

Get the request rate by handler:

) by (handler)

Get the request error rate:


Get percentile 99 of the whole service:


Get percentile 90 of each handler:

    ) by (handler, le)


Middleware Options

The factory options are the ones that are passed in the moment of creating the middleware factory using the middleware.Config object.


This is the implementation of the metrics backend, by default it's a dummy recorder.


Storing all the status codes could increase the cardinality of the metrics, usually this is not a common case because the used status codes by a service are not too much and are finite, but some services use a lot of different status codes, grouping the status on the \dxx form could impact the performance (in a good way) of the queries on Prometheus (as they are already aggregated), on the other hand it losses detail. For example the metrics code code="401", code="404", code="403" with this enabled option would end being code="4xx" label. By default is disabled.


This setting will disable measuring the size of the responses. By default measuring the size is enabled.


This settings will disable measuring the number of requests being handled concurrently by the handlers.

Custom handler ID

One of the options that you need to pass when wrapping the handler with the middleware is handlerID, this has 2 working ways.

  • If an empty string is passed mdwr.Handler("", h) it will get the handler label from the url path. This will create very high cardnialty on the metrics because /p/123/dashboard/1, /p/123/dashboard/2 and /p/9821/dashboard/1 would have different handler labels. This method is only recomended when the URLs are fixed (not dynamic or don't have parameters on the path).

  • If a predefined handler ID is passed, mdwr.Handler("/p/:userID/dashboard/:page", h) this will keep cardinality low because /p/123/dashboard/1, /p/123/dashboard/2 and /p/9821/dashboard/1 would have the same handler label on the metrics.

There are different parameters to set up your middleware factory, you can check everything on the docs and see the usage in the examples.

Prometheus recorder options


This option will make exposed metrics have a {PREFIX}_ in fornt of the metric. For example if a regular exposed metric is http_request_duration_seconds_count and I use Prefix: batman my exposed metric will be batman_http_request_duration_seconds_count. By default this will be disabled or empty, but can be useful if all the metrics of the app are prefixed with the app name.


DurationBuckets are the buckets used for the request duration histogram metric, by default it will use Prometheus defaults, this is from 5ms to 10s, on a regular HTTP service this is very common and in most cases this default works perfect, but on some cases where the latency is very low or very high due the nature of the service, this could be changed to measure a different range of time. Example, from 500ms to 320s Buckets: []float64{.5, 1, 2.5, 5, 10, 20, 40, 80, 160, 320}. Is not adviced to use more than 10 buckets.


This works the same as the DurationBuckets but for the metric that measures the size of the responses. It's measured in bytes and by default goes form 1B to 1GB.


The Prometheus registry to use, by default it will use Prometheus global registry (the default one on Prometheus library).

Label names

The label names of the Prometheus metrics can be configured using HandlerIDLabel, StatusCodeLabel, MethodLabel...

OpenCensus recorder options


Same option as the Prometheus recorder.


Same option as the Prometheus recorder.

Label names

Same options as the Prometheus recorder.


This Option is used to unregister the Recorder views before are being registered, this is option is mainly due to the nature of OpenCensus implementation and the huge usage fo global state making impossible to run multiple tests. On regular usage of the library this setting is very rare that needs to be used.



BenchmarkMiddlewareHandler/benchmark_with_default_settings.-4         	 1000000	      1206 ns/op	     256 B/op	       6 allocs/op
BenchmarkMiddlewareHandler/benchmark_disabling_measuring_size.-4      	 1000000	      1198 ns/op	     256 B/op	       6 allocs/op
BenchmarkMiddlewareHandler/benchmark_disabling_inflights.-4           	 1000000	      1139 ns/op	     256 B/op	       6 allocs/op
BenchmarkMiddlewareHandler/benchmark_with_grouped_status_code.-4      	 1000000	      1534 ns/op	     256 B/op	       7 allocs/op
BenchmarkMiddlewareHandler/benchmark_with_predefined_handler_ID-4     	 1000000	      1258 ns/op	     256 B/op	       6 allocs/op
You can’t perform that action at this time.