[oskarszoon]

Closes #333.

What

The meter provider in telemetry/telemetry.go registered no Views, so http.client.request.duration — the histogram otelhttp.NewTransport records on all four outbound paths (teranode/client.go, merkleservice/client.go, bump/datahub.go, services/webhook/service.go) — kept whatever bucket set the instrumentation advises. That is 14 boundaries / 15 buckets per attribute set, on a metric already multiplied by target host, method and status code.

Nothing downstream can re-bucket an explicit histogram, so the lever has to exist here.

This registers one View narrowing it to 8 boundaries:

var httpClientDurationBoundaries = []float64{0.005, 0.025, 0.1, 0.25, 1, 2.5, 10, 30}

Nine buckets instead of fifteen.

Correction to the issue

#333 claims a possible unit mismatch — "semconv puts http.client.request.duration in seconds, but the SDK default boundary set is millisecond-shaped, so every bucket above the first may be empty". That is wrong, and there is no correctness bug here. The instrumentation ships its own seconds-shaped advisory, which the SDK honours:

• otel/semconv/v1.43.0/httpconv/metric.go declares the instrument metric.WithUnit("s") with a default advisory of 0.005 … 10
• otelhttp/internal/semconv/client.go:41 passes that same seconds-shaped list when constructing the instrument
• otelhttp/internal/semconv/client.go:336 records durationToSeconds(md.RequestDuration)

So the metric is already in the right unit against the right buckets. The issue's series-count argument stands; its correctness argument does not. The count is also 14 boundaries, not 15.

Why these boundaries

Every value is also an edge of latencyBuckets in metrics/metrics.go, so a quantile taken off this histogram and one taken off arcade_teranode_request_duration_seconds for the same calls interpolate over shared edges rather than two unrelated grids.

The top boundary is 30s rather than the 10s the issue suggested, because defaultTimeout is 30 * time.Second on both teranode/client.go and merkleservice/client.go. With a 10s ceiling a timed-out request and a merely slow one are the same datapoint in the overflow bucket — which is exactly the case worth alerting on.

arcade_* metrics are structurally unaffected

They reach the reader through prometheusbridge.NewMetricProducer. PeriodicReader.Collect runs the view-resolved pipeline and then appends the producer's ScopeMetrics directly, so external producer output bypasses view resolution entirely. Their promauto bucket definitions stay authoritative regardless of how a View is scoped. The View criterion is also the exact, wildcard-free instrument name, which could not match an arcade_* name in any case.

Both facts are asserted by tests rather than just reasoned about.

Deliberately not included

No AttributeFilter. url.scheme, server.port and network.protocol.version look like an 8x multiplier but are functionally determined by server.address for a fixed set of targets — removing them saves bytes per datapoint and zero series. server.address does multiply, but it is the attribute that separates the four outbound paths and is worth its cost.

http.response.status_code is the remaining independent dimension. Unlike bucket boundaries it can be collapsed downstream, so it is left alone here.

Tests

telemetry/telemetry_test.go drives a real otelhttp.NewTransport against an httptest server through a ManualReader configured with the same bridge producer initMetrics uses, then reads the collected metricdata:

• view_narrows_the_boundary_set — asserts Unit == "s" (unit-drift guard) and that the collected bounds equal httpClientDurationBoundaries. Fails if the View does not reach the instrument otelhttp actually creates.
• baseline_without_the_view — the control: same setup, no Views, yields exactly the 14-value advisory. This is what makes the assertion above meaningful, and doubles as a drift alarm if a dependency bump ever reverts to the SDK default.
• TestMetricViews_LeaveBridgedArcadeMetricsAlone — observes on the real metrics.TeranodeRequestDuration and compares the bridged family's bounds against what prometheus.DefaultGatherer reports, read from the registry rather than hardcoded.

$ go build ./...          (exit 0)
$ go vet ./telemetry/...  (exit 0)
$ go test ./telemetry/... -count=1
ok  github.com/bsv-blockchain/arcade/telemetry  0.739s
$ go test ./telemetry/... -race -count=1
ok  github.com/bsv-blockchain/arcade/telemetry  2.146s

All 9 pre-existing tests in the package still pass. gofmt -l telemetry/ is empty. golangci-lint could not run locally — the installed binary is built with go1.26 against this module's go 1.27.0 target — so CI will need to cover it.

Separate bug worth its own issue

http.client.request.body.size and http.client.response.body.size have no advisory (httpconv/metric.go sets only description and unit By). They therefore do fall back to the SDK's default 0, 5, 10, 25 … 10000 — which for a byte-valued histogram means everything above ~10KB lands in the overflow bucket. That is the genuinely-mismatched histogram #333 suspected, just on a different metric, and it is 15 more buckets each. Out of scope here; happy to follow up.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[mrz1836]

LGTM