anon retrieval: public BetterStack dealbot dashboard exposes anonymous retrieval

[BigLep]

Done Criteria

We have a section for "anonymous" retrieval that covers:

• Success rate
• Counts
• Anonymous retrieval timing metrics we have

Why Important

Give visibility into what dealbot is collecting, especially until we cut over to relying on the Probelab FCO network dashboard

Notes

1. I expect this looks similar to the "pull section"
2. We don't have to graph every metric, just the mai things for now
3. Lets first review in calibration, and then can copy the changes over.

[BigLep]

@silent-cipher : I'm hoping you can take this as well in support of getting #427 closed out

[silent-cipher]

Sampled retrieval section added to the calibration dashboard

Added a new Sampled retrieval section to the calibration provider dashboard, mirroring the existing Pull statuses section.

Charts (4)

Chart	Type	Metric	Done-criterion
Sampled Retrieval success rate	line	sampledPieceRetrievalStatus	Success rate
Sampled Retrieval: provider summary	table	sampledPieceRetrievalStatus	Counts (success / failure / total per SP)
Sampled Retrieval throughput (p50)	line	sampledPieceRetrievalThroughputBps	Timing
Sampled Retrieval TTFB (p90)	line	sampledPieceRetrievalFirstByteMs	Timing

All four reuse the Pull section's query logic (counter-delta for status/counts, histogram-bucket quantiles for timing), filtered to checkType = 'sampledRetrieval'.

Notes

• Kept minimal per "don't graph every metric, just the main things."
• Data will be sparse for now: the sampled-retrieval check was only just enabled in calibration/staging.

Question: are these 4 enough, or do we want more timing charts like Pull has?

Pull has 5 timing/throughput charts (throughput p50 + p90, ack latency p90, started latency p90, completion latency); we currently have 2 (throughput p50, TTFB p90). We have these additional sampled-retrieval histograms available if we want to match Pull's depth:

• sampledPieceRetrievalThroughputBps → throughput p90
• sampledPieceRetrievalLastByteMs → total retrieval time (p90)
• sampledRetrievalCheckMs → end-to-end check duration (p90)

If these 4 look good, I'll copy the section over to the production (public) dashboard. Otherwise, happy to add any of the above first.

[BigLep]

If these 4 look good, I'll copy the section over to the production (public) dashboard. Otherwise, happy to add any of the above first.

Thanks @silent-cipher . It looks good to me.

I reviewed https://telemetry.betterstack.com/dashboards/wt6QCw?rf=now-3d&rt=now&top=4802

(Separately, I'd want to understand why an approved calibration SP is failing, but that's a separate matter).

[silent-cipher]

I've copied these charts to production/mainnet (public) dashboard as well. But, we don't have any data there yet since retrieval_sampled jobs are disabled on mainnet. We'll enable this job on mainnet once subgraph finishes indexing.

[BigLep]

Sounds good. I assume you'll mark it complete once you see the charts on the mainnet dashboard with data.