Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>

Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>
Co-authored-by: Sebastian <sebastian.schmieschek@digital.cabinet-office.gov.uk>

When making a request to the API with the path /metrics
default prometheus exposition format metrics will be returned

Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>
Co-authored-by: Sebastian <sebastian.schmieschek@digital.cabinet-office.gov.uk>

We add metrics for:

- internal server errors
- routing table reload attempts
- routing table reload errors

Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>
Co-authored-by: Sebastian <sebastian.schmieschek@digital.cabinet-office.gov.uk>

so we can observe how many redirects have been handled

Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>
Co-authored-by: Sebastian <sebastian.schmieschek@digital.cabinet-office.gov.uk>

Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>
Co-authored-by: Sebastian <sebastian.schmieschek@digital.cabinet-office.gov.uk>

When we are given a request for which there is no entry in the trie we
should increment a counter, so that we can track unknown entries

Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>
Co-authored-by: Sebastian <sebastian.schmieschek@digital.cabinet-office.gov.uk>
Co-authored-by: Chris <chris.banks@digital.cabinet-office.gov.uk>

We want to measure:
* the number of requests
* the duration of responses

We measure the backend handlers individually, so the metrics are defined
as prometheus vectors

Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>

In order for us to instrument each backend handler separately, the
backendTransport (which is the handler) needs to know who it is, or at
least how it should record its performance

Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>

Every time the backend handler sees a request, it should increment the
request count counter

Every time the backend handler responds with a status code, we should
record the duration of that request

Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>

Every time the backend handler responds with a status code, we should
count that response

Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>

Instead of implementing our own way of measuring latency and count, we
can use a real histogram instead

Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>

Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>

Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>

Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>

```
make run
---
curl http://localhost:8081/metrics | promtool check metrics
echo $?
=> 0
```

Signed-off-by: Toby Lorne <toby.lornewelch-richards@digital.cabinet-office.gov.uk>
Co-authored-by: Philip <philip.potter@digital.cabinet-office.gov.uk>

because of how http.Redirect works (does not necessarily take a url.URL
but rather a string), we stripQuery using a string not a URL

we do not need to catch this error because the provenance of the URL
argument to stripquery is from a url.URL. However future contributors
should be aware of this nuance

Signed-off-by: toby lorne <toby@toby.codes>

We should use the descriptive names of the status codes, instead of the
number

This also capitalises the response body of 410 Gone because consistency

Signed-off-by: toby lorne <toby@toby.codes>

and add a clarifying comment to demonstrate that the metric should
always get incremented

Signed-off-by: toby lorne <toby@toby.codes>

Signed-off-by: toby lorne <toby@toby.codes>

Signed-off-by: toby lorne <toby@toby.codes>