We can instrument the same information with fewer API calls, and I had encountered this as a readability problem in the exporter / receiver. Since CountSend and CountReceive already see the four parameters correctly, and since the Span already has a name indicative of whether it is exporter or receiver, we can report the span attributes from inside the Count methods using fixed attribute names.
The exporter and receiver code avoids use of MetricsLevel to gate calls into the netstats code, so that span instrumentation is independent of metrics detail. Netstats is level-aware, so this is not a change in observability.
To avoid complicating release cycles with collector-contrib, I've left behind a no-op interface which can be removed after several release cycles.
This is a simplification.
We can instrument the same information with fewer API calls, and I had encountered this as a readability problem in the exporter / receiver. Since CountSend and CountReceive already see the four parameters correctly, and since the Span already has a name indicative of whether it is exporter or receiver, we can report the span attributes from inside the Count methods using fixed attribute names.
The exporter and receiver code avoids use of MetricsLevel to gate calls into the netstats code, so that span instrumentation is independent of metrics detail. Netstats is level-aware, so this is not a change in observability.
To avoid complicating release cycles with collector-contrib, I've left behind a no-op interface which can be removed after several release cycles.