Missing metrics / panic: duplicate metrics collector registration attempted

Help
1

1. The problem I’m having:

I want to expose Prometheus metrics on :9090/metrics.
The docs say to enable metrics in the global settings.
But then it either panics, or exposes too few metrics.
If I remove it servers, it doesn’t panic, but I get very few metrics.

I assume it panics because I listen on several ports and it tries to attach to each.
It doesn’t panic with the following, but it also doesn’t expose the metrics, and admin exposes very few metrics.

{
	servers {
		metrics
	}
}
:8080 {
	metrics /metrics
	respond "Hello"
}

curl -s localhost:8080/metrics
Hello
curl -s localhost:2019/metrics | wc -l
20

Also, this sentence is not true:

Metrics must be turned on in your global options first.

2. Error messages and/or full log output:

panic: duplicate metrics collector registration attempted

3. Caddy version:

v2.9.0-beta.2

4. How I installed and ran Caddy:

a. System environment:

Docker

d. My complete Caddy config:

{
	servers {
		metrics
	}
}
:9000 {
	respond "Hello"
}
:8080 {
	respond "Hello"
}

5. Links to relevant resources:

2

This is a known issue in the beta and was fixed here

The fix will go out with the next beta

1 Like
3

Thanks, using master solves the error.

But am I supposed to be seeing more metrics than this?

Several metrics are mentioned in the docs that are missing here.
Like caddy_http_response_size_bytes for example.

# HELP caddy_config_last_reload_success_timestamp_seconds Timestamp of the last successful configuration reload.
# TYPE caddy_config_last_reload_success_timestamp_seconds gauge
caddy_config_last_reload_success_timestamp_seconds 1.7297037920974286e+09
# HELP caddy_config_last_reload_successful Whether the last configuration reload attempt was successful.
# TYPE caddy_config_last_reload_successful gauge
caddy_config_last_reload_successful 1
# HELP caddy_http_requests_in_flight Number of requests currently handled by this server.
# TYPE caddy_http_requests_in_flight gauge
caddy_http_requests_in_flight{handler="metrics",server="srv1"} 1
# HELP go_build_info Build information about the main Go module.
# TYPE go_build_info gauge
go_build_info{checksum="",path="caddy",version="(devel)"} 1
# HELP promhttp_metric_handler_requests_in_flight Current number of scrapes being served.
# TYPE promhttp_metric_handler_requests_in_flight gauge
promhttp_metric_handler_requests_in_flight 1
# HELP promhttp_metric_handler_requests_total Total number of scrapes by HTTP status code.
# TYPE promhttp_metric_handler_requests_total counter
promhttp_metric_handler_requests_total{code="200"} 0
promhttp_metric_handler_requests_total{code="500"} 0
promhttp_metric_handler_requests_total{code="503"} 0
4

@Mohammed90 Also, it’s not clear whether I need the global setting then?

suggested:

{
	metrics
}
:9000 {
  metrics /metrics
}

Is this the correct minimal?

:9000 {
  metrics /metrics
}
5

They’ll show up when you have traffic flowing.

They serve different purposes. The global option enables metrics collection and only exposes them on the admin endpoint (default: localhost:2019/metrics). The metrics handler which you add per-site allows you to expose metrics on a different endpoint in addition to the :2019/metrics. So, in this example:

You’ll be able to get metrics from both localhost:2019/metrics and :9000/metrics.

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.