Mark metrics as "debug" or "detailed"

[pacejackson]

There's usually some contention between wanting to have as many metrics as possible to debug issues that arise in your application and the costs of storing all those metrics even though you rarely use them.

It would be useful to be able to mark metrics as "debug" or "detailed" and have baseplate not actually report those metrics by default. You could in turn, configure your application to send those metrics when you need to. This lets you add in the instrumentation early but only actually enable it when you need detailed debugging.

[witZack]

+1

[witZack]

Piggy backing this for a discussion, do you think it would be appropriate to start with a config flag that opts into {hostname}.{PID} path, so that initially you could get all the metrics by default with less cardinality? Then you see GC timings across the application for instance, but if you want to debug per, then flagging metrics with 'debug or detailed' could turn it back on, or you could turn it on globally if required?

[spladug]

I think we would prefer this sort of configuration to happen at the stats proxy/aggregation layer and keep it out of the application. That way we don't have to reimplement it for other language baseplates and we keep application code simpler.