Add async/callback mode to instruments?

[timwoj]

I'd like to propose a new feature for prometheus-cpp that would add an async or callback mode to the instrument types. This would allow a user to add a callback method (such as a std::function) to an instrument. The callback would be called during Collect() to set the value of the instrument before it’s exported to prometheus. The difference here with normal operation is that it avoids needing to directly record a value periodically, and lets the prometheus export set it only when it’s actually needed.

Does this seem like something worthwhile to add? I don’t mind doing the work, but I just wanted to gauge the interest before I got started on it.

If you need a (possibly overly-complicated) example, opentelemetry-cpp has a similar feature in their “Observable” instruments.

[ganli]

I have same requirement, to implement sth like GaugeAdapter to collect metric from our internal statistics data on demand.
It's too complex & inefficient to sync such data with prometheus-cpp's internal registry.
For example, we have one counter to track the number of objects. Internally we use std::atomic_int to count, but it's so inefficient to call Gauge::Set in object's constructor/destructor.

[ganli]

Finally I implemented simple customized registry to do this job:

typedef std::function<double()> GaugeValueGetter;

class PassiveMetricsRegistry: public prometheus::Collectable
{
public:
    bool registerGaugeSource(
        std::string_view measureName,
        std::string_view help,
        const Labels& labels,
        GaugeValueGetter valueGetter);

    bool deregisterGaugeSource(
        std::string_view measureName,
        const Labels& labels);

    std::vector<prometheus::MetricFamily> Collect() const override;
};

auto pmr = std::make_shared<PassiveMetricsRegistry>();
prometheus::Exposer exposer(// endpoint);
exposer.RegisterCollectable(// normal registry);
exposer.RegisterCollectable(pmr);

But it's worth that opentelemetry-cpp provides this feature officially.

[timwoj]

We're not using otel-cpp for various reasons, instead preferring to use prometheus-cpp directly. I implemented this in a fork as zeek@2fec720, but never got around to opening a PR for it.

I agree that it's good for otel-cpp to provide this functionality directly themselves as well, since it has more uses there than just with Prometheus.