In #338, it was mentioned/implied that metric filtering is harder than it needs to be due to a lack of first-class metadata, such as what tracing provides in its "callsite metadata". This includes high-level things like log level, but also target, module path, and so on.
These additional metadata properties allow users to efficiently filter out, for example, all spans/events from a specific crate or module. In contrast, with metrics, at best, we can filter by metric name and/or labels, which is precarious and involves a priori knowledge of exactly what we want to filter.. whereas tracing's approach can allow (at least far more easily) for filtering via allowlist rather than blocklist.
We should consider what a design might look like to bring this same callsite metadata to metrics.
The primary concerns would roughly be:
what data should be included? (crate/module path seem obvious, but would "level" make sense?)
should this data be passed alongside Key or baked into it?
tobz
commented
1 year ago
In #338, it was mentioned/implied that metric filtering is harder than it needs to be due to a lack of first-class metadata, such as what
tracingprovides in its "callsite metadata". This includes high-level things like log level, but also target, module path, and so on.These additional metadata properties allow users to efficiently filter out, for example, all spans/events from a specific crate or module. In contrast, with
metrics, at best, we can filter by metric name and/or labels, which is precarious and involves a priori knowledge of exactly what we want to filter.. whereas tracing's approach can allow (at least far more easily) for filtering via allowlist rather than blocklist.We should consider what a design might look like to bring this same callsite metadata to
metrics.The primary concerns would roughly be:
Keyor baked into it?