Module counters 

What a running endpoint will say about itself.

docs/specs/sip-transport.md §12. Counters and nothing else: no metrics library, no exposition format, no push. A Counters snapshot is read through crate::Handle::counters and what an application does with it is the application’s business — a stack that picks an exposition format picks it for every user of the library, and that is the one observability decision here that cannot be undone later.

The atomics live behind an Arc shared with every handle rather than being answered by the event loop, which is the same choice ShedCounts made for the same reason: the loop is busy in precisely the situation these numbers describe. Handle::shed is synchronous; the async Handle::outstanding beside it has to ask the loop and can fail because of it. A snapshot that could return Err(EndpointClosed) under load would be unavailable exactly when an operator reached for it.

What these numbers do not promise is in §12.2 and repeated on the types below. The short version: each field is individually exact, and the relationship between two fields of one snapshot is not, because they are separate atomics read one after another.

Structs

CaptureCounts

How the capture is faring, if one is running (§13).

Counters

Everything an endpoint will tell you about itself, at one moment (§12).

DiscardCounts

Places the endpoint throws something away that are not backpressure (§12.1).

ShedCounts

A snapshot of what an endpoint has shed (see crate::Handle::shed).

TimeoutCounts

Transactions abandoned by the timer that gave up on them.

TransportCounts

What crossed one transport, in both directions.

UnsentCounts

Requests the endpoint tried to put on the wire and could not, by method (§12.3).