[cijothomas]

Description

Report span and log processor queue capacity with observable up-down counters instead of recording the capacity once with synchronous counters.

A processor can be constructed before the SDK installs the real meter provider. In that case, the one-time synchronous measurement is made against a proxy instrument and is not replayed when the provider is installed, so queue capacity is never exported. Observing the fixed capacity during collection avoids that initialization-order dependency and remains compliant with the metrics semantic conventions.

Adds regression coverage for processors created before the real meter provider is installed.

[opentelemetry-pr-dashboard]

Pull request dashboard status

Waiting on the author · refreshed 2026-10-26 20:55 UTC

Respond to 1 review item (e.g. link a commit, explain why not, ask a follow-up):

• Top-level threads: 1

Status above doesn't look right?

• Just replied or pushed? Anything around or after the refresh time above may not be picked up yet — give it a few minutes.
• Should this be with reviewers? Comment /dashboard route:reviewers to route it to them.
• Anything wrong — including the routing? Report it with what you expected; it helps us improve the dashboard.

[cijothomas]

@DylanRussell Please review. Hit the issue while working on open-telemetry/opentelemetry-demo#3932 and it worked around by re-ordering, but this PR would be a better fix.

[Shriprasad-P]

Thanks for switching queue capacity to an observable instrument — that should fix the late MeterProvider case cleanly.

A few notes from reading _processor_metrics.py and the new test:

1. Callback closure over capacity — record_queue_capacity captures capacity by value from __init__. That is fine if capacity is immutable for the processor lifetime; if anything ever resizes the queue, this metric would silently stay stale. Worth a one-line comment near the callback that capacity is fixed at construction, or asserting that in the test docstring.
2. Double collect in the test — collecting twice is good for proxy/late-provider stability. Consider also asserting that no cumulative counter-style noisy points appear for capacity (only the single Observation), so a regression back to add() would fail loudly.
3. Description length — the log-path description is one long line; matching the span-path multi-line style would keep lint/formatters happier across the file.

Otherwise the approach looks sound and the changelog entry matches the change.

[opentelemetry-pr-dashboard]

Hi @cijothomas — just a friendly reminder that this pull request is waiting on you. The dashboard status comment has the open items and is kept current.

• Replying is enough to hand it off — answer, explain why no change is needed, or ask a follow-up. The dashboard routes it onward once nothing on the list is waiting on you.
• To hand it back for any other reason, including the dashboard getting this wrong, comment /dashboard route:reviewers.

[github-actions]

This PR has been automatically marked as stale because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 days of this comment.
If you're still working on this, please add a comment or push new commits.