report mempool fetched and missing counts to prometheus

[philippem]

We are currently reporting the mempool tx count to prometheus.
This MR adds the missing and fetched counts to the same prometheus gauge, using different labels.

[shesek]

There's an IntGaugeVec we could use:

The integer version of GaugeVec. Provides better performance if metric values are all integers.

However, this will likely make it impossible to compare historical values recorded as floats with new integer values, so I'm not sure if its worth it. What do you think?

[philippem]

There's an IntGaugeVec we could use:

The integer version of GaugeVec. Provides better performance if metric values are all integers.

However, this will likely make it impossible to compare historical values recorded as floats with new integer values, so I'm not sure if its worth it. What do you think?

Prometheus stores all metrics as float64. https://prometheus.io/docs/concepts/data_model/
I wonder where the better performance will be on... maybe on the exporter side?
Changing to IntGaugeVec would impact metrics.rs which we received from upstream, I don't think it's worth changing it given that the metrics end up as floats in Prometheus.

[shesek]

I wonder where the better performance will be on... maybe on the exporter side?

It appears so, it uses integer date types on the rust side which is more performant.

The PR that introduced this to rust-prometheus includes some benchmarks:

$ ENABLE_FEATURES="nightly" make bench
...
test counter::bench_counter_no_labels                   ... bench:          13 ns/iter (+/- 4)
test counter::bench_int_counter_no_labels               ... bench:           6 ns/iter (+/- 0)
test gauge::bench_gauge_no_labels                       ... bench:          15 ns/iter (+/- 1)
test gauge::bench_int_gauge_no_labels                   ... bench:           7 ns/iter (+/- 1)
...

IntCounter and IntGauge can improve 50% performance.

---

Changing to IntGaugeVec would impact metrics.rs which we received from upstream, I don't think it's worth changing it given that the metrics end up as floats in Prometheus.

I don't feel strongly about this, and it can be done in a future PR if we do decide to do it. But keeping the codebase similar to upstream is long a lost cause, it was changed significantly in our fork and basically rewritten in romanz/electrs.

[shesek]

Prometheus stores all metrics as float64

Also if that's the case (I was not aware of it), my earlier "impossible to compare historical values recorded as floats with new integer values" comment is probably incorrect

[philippem]

Prometheus stores all metrics as float64

Also if that's the case (I was not aware of it), my earlier "impossible to compare historical values recorded as floats with new integer values" comment is probably incorrect

The electrs prometheus exporter (gauges) are snapshots. The prometheus server will scrape and record values, and we can run queries on the data in prometheus, and compare historical values. The histograms generated by electrs are less useful, because they are an aggregation since the last electrs restart.

[philippem]

I wonder where the better performance will be on... maybe on the exporter side?

It appears so, it uses integer date types on the rust side which is more performant.

The PR that introduced this to rust-prometheus includes some benchmarks:

$ ENABLE_FEATURES="nightly" make bench
...
test counter::bench_counter_no_labels                   ... bench:          13 ns/iter (+/- 4)
test counter::bench_int_counter_no_labels               ... bench:           6 ns/iter (+/- 0)
test gauge::bench_gauge_no_labels                       ... bench:          15 ns/iter (+/- 1)
test gauge::bench_int_gauge_no_labels                   ... bench:           7 ns/iter (+/- 1)

where is that time being spent? How often are we manipulating the gauges and counters?

IntCounter and IntGauge can improve 50% performance.

From what?

I don't feel strongly about this, and it can be done in a future PR if we do decide to do it. But keeping the codebase similar to upstream is long a lost cause, it was changed significantly in our fork and basically rewritten in romanz/electrs.
OK

[philippem]

amended

[shesek]

mempool.rs.copy got accidentally committed. All LGTM other than that.

[philippem]

• removed file that was committed by accident
• rebased onto new-index