Skip to content

Improve configuration/composition of Prometheus metric collection #7364

@hendrikmakait

Description

@hendrikmakait

As of now, our Prometheus collectors are hard-coded into their respective submodules. This makes it hard to make changes to the metrics we expose. In particular, I see two use cases where better configuration/composability would benefit users:

  1. Some of the metrics we expose are very detailed and mostly useful for debugging and development purpose. Since there is a cost to each collected metric (in terms of storage, processing time, or $ spent on Cloud services), it would be helpful to be able to configure which (sets of) metrics we want to expose for scraping.
  2. Extensions or plugins may want to expose additional metrics, see the WorkStealingMetricCollector as an example. For these, having an easy way to (un)register collectors would be great.

The first point seems to be related to the second one. If we had an easy way to (un)register collectors, we could have a variety of optional collectors that users could register if desired.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions