caddy icon indicating copy to clipboard operation
caddy copied to clipboard

Add custom labels in metric

Open Jaeyo opened this issue 4 months ago • 1 comments

i've opened a new issue to clarify the feature mentioned in comment and discuss whether the direction i'm thinking is appropriate.

first, a user should be able to specify the label fields of the metric to be exposed, and the value of the label should be dynamically specified using placeholder.

also these new label setting should be possible on per-server as well as global setting.

it's like,

# global
{
    metrics {
        labels {
            server "{server}"
            handler "{handler}"
        }
    }
}

# per-server
:80 {
    metrics {
        labels {
            proto "{scheme}/{version}"
        }
    }
}

global setting and per-server setting have the following rules.

  1. global setting apply by default to all servers.
  2. per-server setting override global setting and are specific to that server.
  3. if a per-server setting conflicts with a global setting, the per-server setting win.

the list of placeholders available in label is as follows, in addition to all of the globally available placeholders. (However, due to cardinality issues, things like time values should probably be discouraged)

  • {server}
  • {handler}
  • {scheme}: http, https
  • {method}: GET, POST, PUT, DELETE, etc.
  • {status}: HTTP status code
  • {version}: HTTP version (1.1, 2, etc.)
  • {remote_addr}
  • {host}
  • {content_type}

and as a result, it looks like the existing metrics > per_host setting should be kept for backwards compatibility for the time being, but deprecated.

and if a user hasn't set anything, only the server, handler label should be applied by default as before.

plz give me your opinions

Jaeyo avatar Aug 23 '25 15:08 Jaeyo

The metrics directive which goes inside site block isn't to configure metrics. It's to configure a handler that exposes metrics on the site. You also shouldn't need to list the placeholders. They'll use whatever available in the *Replacer at execution time. My only concern is that it may not be filled with values. That's what needs validation.

mohammed90 avatar Aug 23 '25 18:08 mohammed90