[v1.2] Custom-metric callbacks for observability (active_meetings, transcript_chunks, reconnects)

[MaxMansfield]

Context

Production deployments need metrics, not just logs. The metrics customers consistently ask for:

• rtms.active_meetings (gauge) — how many Client instances currently joined
• rtms.transcript_chunks_per_second (counter) — throughput
• rtms.reconnect_attempts (counter, by scenario 1/2/3) — recovery health
• rtms.signature_failures (counter) — security signal
• rtms.join_latency_ms (histogram) — time from join() to on_join_confirm

Today customers grep CloudWatch Logs Insights and emit their own metrics via boto3.client("cloudwatch").put_metric_data from inside callbacks. Slow, fragile, and assumes the customer is on AWS.

What to ship

Two complementary paths:

1. Built-in OpenTelemetry exporter — emit metrics via OTLP. Customers point at any backend (CloudWatch via ADOT, Prometheus, Datadog, New Relic, Honeycomb).
2. Pluggable metric sink for non-OTel setups:

def my_sink(name: str, value: float, labels: dict[str, str]):
    boto3.client("cloudwatch").put_metric_data(...)

rtms.set_metric_sink(my_sink)

Document both. OTel is the modern default; the sink is the escape hatch.

Acceptance criteria

• At minimum the 5 metrics above are emitted
• OTel exporter is opt-in via env var ZM_RTMS_OTEL_ENABLED=true or constructor param
• rtms.set_metric_sink(callable) for custom routing
• CloudWatch + Prometheus + Datadog routing examples in docs
• Metric names follow OTel semantic conventions where applicable

Cross-language parity

• Same 5 metrics emitted in both languages
• Same metric names
• Same env var contracts
• OTel exporter in both, sink API in both
• Documentation parity

Source

Tracked in vault: Projects/RTMS SDK v1.2.md → DEVS-X13.

Tracker

Part of the v1.2 milestone. Project: https://github.com/orgs/zoom/projects/11.