Skip to content

Decision needed: Should we allow deleting a labelset from an existing metric? #140

@dmagliola

Description

@dmagliola

This issue comes from this recently closed PR.

I'll try to summarize the situation here, but I encourage to read the discussion on that PR.

Basically, the question is whether we should allow deletion of a labelset for a metric that's observed values on that labelset.

Reasons for doing it:

  • Removing stale metrics
  • Example use case: Exporting metrics about containers running on a host, with container identifier as a guid that is part of the label set. Containers disappear after being terminated by our cluster manager and we'd like the related metrics to disappear as well.
  • The best practices actually say this should be a feature: Metrics with labels SHOULD support a remove() method with the same signature as labels() that will remove a Child from the metric no longer exporting it

Reasons against:

  • This should be done using const metrics, as supported by the Go/Python/Java do. See https://www.robustperception.io/setting-a-prometheus-counter/. Maybe we need to add this instead to the client
  • That bit of the best practices quoted above likely needs some reconsidering. There are use cases for this, but they're very very rare. Mostly the people looking for this actually want const metrics.
  • This is actually quite involved to implement with our new file-based Data Store. This is not really a reason not to do this, but it's a cost that is good to keep in mind. The new implementation is considerably harder than the code change in the PR linked above.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions