Problem

The catalogStats section of serverStatus reports a top-level collections counter together with per-collection-type counters (capped, clustered, timeseries). The accounting is inconsistent between collection types:

• Creating a capped collection increments both collections and capped.
• Creating a clustered collection increments both collections and clustered.
• Creating a timeseries collection increments only timeseries and not collections.

So capped and clustered behave like subcategories of collections, while timeseries is tracked outside it. Consumers of these metrics cannot interpret collections consistently, and the per-type counters are not comparable with each other.

Where it comes from

In CollectionCatalog::Stats::adjustOnCollectionRegistration, a timeseries collection is tracked only via the userTimeseries counter, whereas every other user collection is counted in userCollections with userCapped and userClustered incremented additionally as sub-counters. The server status section maps these counters 1:1 onto the reported fields. The disjoint accounting is only documented in an internal code comment on the Stats struct, not in the serverStatus output itself.

Proposed solution

Make the semantics of catalogStats consistent: either count timeseries collections in collections so that all per-type counters are subcategories of it, or clearly document/expose that timeseries is disjoint from collections. Backward compatibility for existing consumers of these metrics should be considered.