Skip to content

Consider adding richer metadata to metric emission. #370

Closed
@tobz

Description

@tobz

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-coreComponent: core functionality such as traits, etc.E-complexEffort: complex.T-enhancementType: enhancement.T-ergonomicsType: ergonomics.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions