It is possible (perhaps even likely) that instrumentation will generate metrics with cardinality explosions. There may be backends that can handle this, so it's not necessarily an error in the instrumentation. However, it will often be a mistake in the instrumentation, and the SDK needs to include some sort of mechanism so that the the application will not die with a memory leak in this case. This could especially happen with a pull-based exporter if nothing is pulling the data from it, for example.
The SDK specification should define the standard strategy for this circuit breaker. There are at least several possible options to solving this, and it would be good if all languages implemented the same default strategy.
Some options:
a) Count the cardinality and start dropping recordings for instruments that exceed it.
b) Watch for specific dimensions that are causing the explosion and start automatically dropping those dimensions.
c) Something more clever.
It is possible (perhaps even likely) that instrumentation will generate metrics with cardinality explosions. There may be backends that can handle this, so it's not necessarily an error in the instrumentation. However, it will often be a mistake in the instrumentation, and the SDK needs to include some sort of mechanism so that the the application will not die with a memory leak in this case. This could especially happen with a pull-based exporter if nothing is pulling the data from it, for example.
The SDK specification should define the standard strategy for this circuit breaker. There are at least several possible options to solving this, and it would be good if all languages implemented the same default strategy.
Some options:
a) Count the cardinality and start dropping recordings for instruments that exceed it.
b) Watch for specific dimensions that are causing the explosion and start automatically dropping those dimensions.
c) Something more clever.