Overview

maxEstimatedScanRejected and maxEstimatedScanRejectedAndOverridden in max_estimated_scan_bytes_metrics.cpp are implemented as Counter64/MetricBuilder serverStatus metrics (under serverStatus.metrics.query.maxEstimatedScanBytes.*).

During review of SERVER-127688, denis631 asked whether these should instead be OTel metrics, contingent on whether the feature is planned for backport to older release branches.

Findings

• No jstest anywhere in the codebase reads back an OTel counter value directly (no $listMetrics, no serverStatus.otelMetrics.* assertions found). OTel counters appear to be consumed only by external exporters (Prometheus/OTLP), not queryable in-shell.
• max_estimated_scan_bytes.js currently asserts directly on {{db.adminCommand( {serverStatus: 1}

  ).metrics.query.maxEstimatedScanBytes.rejected}}. Dropping the Counter64 in favor of OTel-only would remove the ability to verify these counters from jstests.

• MetricNames (src/mongo/otel/metrics/metric_names.h) is a single, centrally shared registry, not scoped to query team ownership — adding entries there is a shared-infra change, not a local one.

Decision needed

• Should maxEstimatedScanRejected/maxEstimatedScanRejectedAndOverridden (and the sibling maxEstimatedScanDryRunWouldReject counter added in SERVER-130231) stay as serverStatus Counter64 metrics, gain an additional OTel counter alongside the existing one, or move to OTel-only (accepting the jstest coverage loss or rewriting those assertions against an external metrics path)?
• Is there a concrete backport plan for maxEstimatedScanBytes that would inform this decision?

References

• PR: https://github.com/10gen/mongo/pull/57108
• Origin: denis631's review comment on src/mongo/db/query/max_estimated_scan_bytes_metrics.cpp:38