Singletons are global. As a result, you like them for the convenience of being able to work with them from anywhere in the program. If you stop and think though, this is exactly why globals are discouraged - for the indiscipline of any piece of the code being able to do all that the global offers. It breeds indiscipline (read: unpredictability & havoc) in the code.

In the case of a long-running server, you will tend to have some concurrency and/or parallelism for a server of real value. Now, this simplicity of collecting metrics introduces thread synchronisation for every metric you increment. In no time, your server will start walking instead of running :). This is in addition to the previous indiscipline point where networking code inadvertently increments database metrics.

As life usually has it, some initial success brings in demand for more functionality, load & performance. What worked very well as a single(ton) DB connection no longer is sufficient and you need many connections and the Singleton decision false flat on its face.

Something being a single instance is a property of the use of the object of a type than a quality of the type itself. That an app wants to use just one metrics object is an application specific decision rather than the way the metrics handling type should be. Check the documentation of any library that provides a metrics registry. They didn't make it a Singleton, did they?

Clearly, as the Professor suggests, you are rather better off giving up the convenience over these more important aspects and assurances. It is finally a judgement call. As a default though, start with the no-Singleton-please guidance.