In the above example, the counter metadata specifies label1 and label2 but it's possible to store samples with more or fewer labels, e.g.["bob","alice","eve"]. This could happen under different circumstances. For example, a new version of the code introduces label3 for the counter.
Depending on the setup, flushing the storage after the new code is out could be a valid way to avoid the problem. However, it becomes complex in environments with canary deployment where multiple versions of the code are required to run together.
While there are ways to avoid the scenario, offering users the option to ignore errors for a limited number of metrics can be beneficial. It avoids the complete failure of the rendering operation in cases of minor inconsistencies. This PR does that.
This PR addresses a specific scenario encountered with Redis and RedisNg storage, where samples with mismatching labels can be stored. For instance:
In the above example, the counter metadata specifies
label1
andlabel2
but it's possible to store samples with more or fewer labels, e.g.["bob","alice","eve"]
. This could happen under different circumstances. For example, a new version of the code introduceslabel3
for the counter.Depending on the setup, flushing the storage after the new code is out could be a valid way to avoid the problem. However, it becomes complex in environments with canary deployment where multiple versions of the code are required to run together.
While there are ways to avoid the scenario, offering users the option to ignore errors for a limited number of metrics can be beneficial. It avoids the complete failure of the rendering operation in cases of minor inconsistencies. This PR does that.
Thanks for reviewing this! 🙏