The constraint that shapes everything
A refactor that recently landed in a codebase I work in replaced our metrics god class with per-subsystem modules. The design was a colleague's work, not mine. But studying the change, and migrating my own instruments over to the new pattern, taught me more about OpenTelemetry's design constraints than any tutorial had.
The constraint that shapes everything is easy to state: an OTel instrument — a counter, a histogram, an observable gauge — can be created once per process and never unregistered. Register the same instrument twice and, depending on the SDK, you get warnings or subtly duplicated data. So every metrics architecture in an OTel codebase is really an answer to one question: where does the process-level singleton live?
The old answer in our codebase was one global Metrics object, built at startup and threaded through the application by dependency injection. That does solve the singleton problem. It also creates a monster.
The anti-pattern: one god class of mixins
