Add Initial Setup + GetBlobsV2 Metrics

[SunnysidedJ]

Hi,

I'd like to start spec-ing EL metrics with GetBlobsV2 as they seem to be useful in monitoring PeerDAS. I've copied the format from https://github.com/ethereum/beacon-metrics for consistency.

Discussion from Discord:
https://discord.com/channels/595666850260713488/1252403418941624532/1374373828691497064
Initial proposal (edited) from Sunnyside Labs:
https://testinprod.notion.site/Proposal-for-Unified-EL-metrics-for-PeerDAS-1d28fc57f54680f2a3cbfe408d7db4b8?source=copy_link

Issue: #1

[SunnysidedJ]

@KatyaRyazantseva @mininny

[KatyaRyazantseva]

@SunnysidedJ could you please review thestructure proposal by @will-corcoran? This is the structure we are going to follow for metrics specs repos. Still in progress, feel free to comment.

[macfarla]

Q re how this will work with the changes here ethereum/execution-apis#674 for moving partial response behavior to getBlobsV3

• will getBlobsV2 and getBlobsV3 use the same metrics
• specifically for execution_engine_getblobs_available_total - once V2 is no longer returning partial responses, should this counter still be incremented with how many are available in the pool, even if null is returned? Or should it be all or nothing, in line with the response?

if context is helpful, PR for getBlobsV3 for besu hyperledger/besu#8967

[SunnysidedJ]

Q re how this will work with the changes here ethereum/execution-apis#674 for moving partial response behavior to getBlobsV3

• will getBlobsV2 and getBlobsV3 use the same metrics
• specifically for execution_engine_getblobs_available_total - once V2 is no longer returning partial responses, should this counter still be incremented with how many are available in the pool, even if null is returned? Or should it be all or nothing, in line with the response?

if context is helpful, PR for getBlobsV3 for besu hyperledger/besu#8967

Pasting the same reply from the Discord channel here as well.

I think execution_engine_getblobs_available_total could still be a useful metric for GetBlobsV2 in few ways, ,e.g. it could be used to calculate how many blobs were available upon failure on average; (available_total - (requested_total * hit_ratio)) / miss_total.

It'd be nice if we have the same metrics for getBlobsV3 as well if we were to implement it for Fusaka. In addition to existing ones, another metric called something like execution_engine_getblobs_partial_hit_total would be very helpful in distinguishing between complete and partial hit returns.