The histogram stats decoder keeps track of the last seen histogram sample
in order to properly detect counter resets. We are seeing an issue where
a histogram with UnknownResetHint gets treated as a counter reset when it follows
a stale histogram sample.

I believe that this is incorrect since stale samples should be completely ignored
in PromQL. As a result, they should not be stored in the histogram stats iterator
and the counter reset detection needs to be done against the last non-stale sample.

Signed-off-by: Filip Petkovski <[email protected]>

Signed-off-by: Filip Petkovski <[email protected]>

The histogram stats iterator does not fully clear the histogram object
and is not resilient to new fields being added to the histogram type.

To resolve the issue, the commit uses the CopyTo methods which should
be future proof to new fields being added.

Signed-off-by: Filip Petkovski <[email protected]>

chunkenc.Iterator.AtFloatHistogram may do a shallow copy if
it receives nil as input pointer. This can in turn share the
span slice with multiple histograms in the matrixSelectorHPool,
leading to unexpected errors.

Signed-off-by: György Krajcsovits <[email protected]>

Signed-off-by: György Krajcsovits <[email protected]>

Signed-off-by: George Krajcsovits <[email protected]>

Ignore stale histograms for counter reset detection

Use CopyTo when resetting histogram in stats iterator

So long as they specify timestamps. We don't check that the timestamps
are different.

Extend test, and use client_golang/prometheus/testutil to simplify metric check.

Signed-off-by: Bryan Boreham <[email protected]>

…r is reconnected to a new network

Signed-off-by: [email protected] <[email protected]>

[BUGFIX] Docker SD: fix the issue of failing to match the first network when the container is reconnected to a new network

Fix histogram pool poisoning bug chunkenc.Iterator

Signed-off-by: Bryan Boreham <[email protected]>

Cut release 2.54.1