For the caddy admin API you can see which path was called and how often in the metrics data:
I was wondering if there was a way to do something similar but for domain on caddy_http_requests_total data. Something like this?
caddy_http_requests_total{domain=“example.com ”,handler=“reverse_proxy”,server=“srv0”} 1219otherdomain.com ”,handler=“reverse_proxy”,server=“srv0”} 123
The rationale being we are hosting many domains off one caddy instance and I’m curious to know who’s sending how many requests. It’s not really important to know too much other than that.
Alternatively I suppose this is something I could log? I was looking through the log docs but I wasn’t exactly sure how to create a custom log format that writes the origin/domain out? I did some googling but couldn’t find an example, if you had one handy I would be much obliged!
matt
March 12, 2021, 11:28pm
2
This one’s for you, @hairyhenderson
matt
March 12, 2021, 11:30pm
3
The access logs emit almost everything about the request. You can see a sample here: How Logging Works — Caddy Documentation
The domain name is in the request>host field.
Unfortunately the metrics issue looks to be impossible at the moment:
opened 03:03PM - 08 Oct 20 UTC
feature
discussion
Initiated through [this](https://caddy.community/t/per-host-prometheus-metrics/1… 0035) forum post – involving @hairyhenderson –, I'd like to open the discussion about extending the `metrics` directive to support metrics (request count, etc.) on a per-host basis.
I'd like to have metrics exposed for every single site block (speaking in Caddyfile terminology), i.e. metrics about different sites / vhosts result in different Prometheus metrics labels.
Since determining the labels automatically based on the incoming requests' host headers is problematic (see discussion above), a solution would be to manually assign a tag to the `metrics` directive. For instance:
```
example.org {
root /var/www/html
file_server
metrics /metrics {
host "example.org"
}
}
```
I'm not really involved with Caddy's code base or development process, so this is rather supposed to be a starter for further discussion.
opened 09:56AM - 12 Feb 21 UTC
feature
discussion
On one hand, with lack of lables, prometheus metrics make barely more sense than… measuring nationwide average body temperatures. On the other hand, with too many labels, in prometheus might be a source of unbounded high-cardinality, which will cause issues when scraping with Prometheus over long periods of time and with larger deployments.
In the usecase we had, we needed to see per-host metrics (for an obvious reason, different hosts often have very different performance), and also a per-content-type metric, here's why:
1) Dynamically generated resources usually have way bigger TTFB, and mixing such resources with static files we obscure actual peaks in data, because each dynamically generated HTML document also pulls 10 to 100 static files. Content-type is a good heuristic for dynamic content, because html is usually dynamically generated, and everything else is static in most cases
2) No matter if html is dynamic or static, its performance is more critical for overall page load time, because it's the root document for the page, and each millisecond of its load time is always added to overall page load time, which is not always the case for page resources.
We intended to create two extra grafana panels, to be able to see metrics subsets that represent:
- html documents only
- small static files (js/css)
- large static files (images)
Also, it might be useful to separate metrics by document cache status, when caddy cache is enabled.
Based at the discussion in this ticket: https://github.com/caddyserver/caddy/issues/3784 and in this PR: https://github.com/caddyserver/caddy/pull/4015
We came up with a following proposal:
- It's better to add extra configuration options, that allow both more detailed metrics and reduction of metrics size, rather just hardcoding extra added labels
- We cannot extend an existing `metrics` directive, because it defines the virtual host that serves metrics if defined inside of a specific host
- we chose `metrics_options` as new directive name; does anyone have better ideas maybe?
```
// enable per-host metrics for a single host
example.com {
respond /foo "hello world"
metrics_options {
tags {
host example.com
}
}
}
// enable per-host metrics + per-content-type for a single host
example2.com {
respond /bar "hello world"
metrics_options {
tags {
host example2.com
}
headers-to-tags {
response.content-type
}
}
}
// disable metrics for a single host
example3.com:8443 {
respond /baz "hello world"
metrics_options {
disable
}
}
// disable metrics for a subpath
example3.com {
handle_path /static {
metrics_options {
disable
}
}
}
// globally enable per-host metric, and also per-cache-status, based on response
metrics_option {
headers-to-tags {
request.host
response.x-cache-status
}
}
```
Hey thanks guys for your amazingly quick replies!
system
April 11, 2021, 10:23pm
6
This topic was automatically closed after 30 days. New replies are no longer allowed.
