Add prometheus metrics endpoint

[0xste]

📝 Summary

An initial implementation of some prometheus metrics for MEV Boost

⛱ Motivation and Context

I want to be able to monitor my mev-boost container with prometheus to get better operational insight

📚 References

#253

✅ I have run these commands

• [✔️] go mod tidy
• [✔️] make test
• [✔️] make lint
• [❔] make run-mergemock-integration

Getting an error back from make run-mergemock-integration, but not sure if it's related to my change

ERROR  [2022-09-05T19:09:20+01:00] Unable to retrieve proposal payload           error="builder REST API returned non-200 status code: 204" slot="5"
make: *** [run-mergemock-integration] Error 1```

[ybstaked]

what's the progress on this? we also would appreciate having prometheus metrics on boost

[ybstaked]

wouldn't having a number of validators successfully registered per relay be more helpful? per pubkey might be a lot of data for validators operating at scale

[metachris]

These changes are deep and extensive into the core system and logic. Considering that mev-boost is run at 50% of all validators, it is too risky and impactful for adding a large amount of new logic in the core flows at the current time.

Perhaps consider collecting the metrics from the logs, or thinking about a possible plugin interface. 🤔

[0xste]

These changes are deep and extensive into the core system and logic. Considering that mev-boost is run at 50% of all validators, it is too risky and impactful for adding a large amount of new logic in the core flows at the current time.

Perhaps consider collecting the metrics from the logs, or thinking about a possible plugin interface. 🤔

Thanks for your feedback @metachris, i may pick this up again later and try coming at it from a different angle 👍

[ybstaked]

These changes are deep and extensive into the core system and logic. Considering that mev-boost is run at 50% of all validators, it is too risky and impactful for adding a large amount of new logic in the core flows at the current time.

Perhaps consider collecting the metrics from the logs, or thinking about a possible plugin interface. 🤔

@metachris as this PR is implemented as is, seems this would've been behind a -metrics flag (similar to prysm and teku have their prometheus metrics behind a flag on a separate metrics port). Making the metrics opt-in and improving the metrics collected, I think this would be a useful feature to add native prometheus metrics

[0xste]

@ybstaked @metachris happy to reopen and rebase this PR if there's any will to get it implemented

Otherwise the suggestion is the approach outlined in #370

[metachris]

I sincerely appreciate the effort in adding the prometheus support. As mentioned before, the changes reach too deep into the core program flow to merge and force on a majority of proposers, without extensive review and in particular discussions beforehand. If you feel you'd like to pursue this, then please open an issue and continue the conversation there.

[ybstaked]

@metachris since there's already an issue open for this here: #253, what are the discussion points?