By upgrading prometheus/client_model, several test functions had to be re-written due to 2 breaking changes made in protobuf when parsing messages to text:
1. '<' and '>' characters were replaced with '{' and '}' respectively.
2. The text format is non-deterministic. More information in https://github.com/golang/protobuf/issues/1121
Signed-off-by: Arthur Silva Sens <arthur.sens@coralogix.com>
Fixes#1127.
If a native histogram has no observations and a zero threshold of
zero, then it is indistinguishable from a classic histogram. To give
scrapers a hint that it is indeed a native histogram, we add a no-op
span.
This needs follow-up PRs in prometheus/prometheus and
prometheus/client_model.
Signed-off-by: beorn7 <beorn@grafana.com>
The current code doesn't work fork negative schemas if the observed
value should go into a bucket with a non-positive key.
Signed-off-by: beorn7 <beorn@grafana.com>
The current code doesn't work fork negative schemas if the observed
value should go into a bucket with a non-positive key.
Signed-off-by: beorn7 <beorn@grafana.com>
This replaces usage of proto.{Float64,Int32,Int64,String,Uint32,Uint64},
which doesn't break the interface.
And remove usage of proto.MarshalTextString in wrap_test.go
Updates: #1175
Signed-off-by: Shengjing Zhu <zhsj@debian.org>
Signed-off-by: Shengjing Zhu <zhsj@debian.org>
* Fix float64 comparison test failure on archs using FMA
Architectures using FMA optimization yield slightly different results so
we cannot assume floating point values will be precisely the same across
different architectures.
The solution in this change is to check "abs(a-b) < tolerance" instead
of comparing the exact values. This will give us confidence that the
histogram buckets are near identical.
Signed-off-by: Seth Bunce <seth.bunce@getcruise.com>
* Apply suggestions from code review
Co-authored-by: Daniel Swarbrick <daniel.swarbrick@gmail.com>
Signed-off-by: Seth Bunce <seth.bunce@getcruise.com>
* copy float compare dependency
Per discussion in the pull request, we'd like to avoid having an extra
dependency on a float comparison package. Instead, we copy the float compare
functions from the float comparison package.
The float comparison package we're choosing is this. The author of this
package has commented in the pull request and it looks like we have consensus
that this is the best option.
github.com/beorn7/floats
Signed-off-by: Seth Bunce <seth.bunce@gmail.com>
* remove float32 variant, relocate into separate file
This change removes the float32 variant of the AlmostEqual funcs, that we will
likely never use. This change also relocates the function into a separate file
to avoid modifying a file that's a fork of another vendored package.
Signed-off-by: Seth Bunce <seth.bunce@gmail.com>
Signed-off-by: Seth Bunce <seth.bunce@getcruise.com>
Signed-off-by: Seth Bunce <seth.bunce@gmail.com>
Co-authored-by: Daniel Swarbrick <daniel.swarbrick@gmail.com>
This intends to avoid confusing users by the subtle difference between
a native histogram and a sparse bucket.
Signed-off-by: beorn7 <beorn@grafana.com>
NaN observations now go to no bucket, but increment count (and
effectively set sum to NaN, too).
±Inf observations now go to the bucket following the bucket that would
have received math.MaxFloat64. The former is now the last bucket that
can be created.
The getLe is modified to return math.MaxFloat64 for the penultimate
possible bucket.
Also add a test for getLe.
Signed-off-by: beorn7 <beorn@grafana.com>
Note that this is an incompatible change. To scrape this new format,
the Prometheus server needs to be updated at the same time. PR
incoming.
Signed-off-by: beorn7 <beorn@grafana.com>
This function calculates exponential buckets with different arguments
than the existing ExponentialBuckets function. Instead of specifying the
start and factor, the user can specify the min and max bucket value. We
have been doing it this way internally at my company for some time.
Signed-off-by: Seth Bunce <seth.bunce@getcruise.com>
`github.com/golang/protobuf/proto` is deprecated in lieu of
`google.golang.org/protobuf/proto`. However, we cannot simply
migrate. Types from the proto package are exposed to users of packages
in this repo. If we migrate here, users have to migrate to. Thus, we
could only migrate with a major version bump.
In different news, with all the inline lint:ignore comments, including
the existing ones, there is no need to repeat the exception in the
Makefile.
A current version of `staticcheck` is happy with the code after this
commit. golangci-lint is broken at the moment, however, and ignores
the lint:ignore comments in the code as well as those via envvar.
Signed-off-by: beorn7 <beorn@grafana.com>
This is, sadly, the only way to avoid a breaking change. The cost is
that anyone using exemplars has to perform a type assertion. This is,
however, a common pattern where interfaces turn out to need additional
methods in a stable library or only some implementations can provide
the additional methods (AKA "interface upgrade").
Needless to say that in v2 of this library, we'll do things in a more
straight forward way.
Signed-off-by: beorn7 <beorn@grafana.com>
it appears there is a copy/paste error in the exponential buckets test failure message which is fixed here.
Signed-off-by: David Worth <dworth@strava.com>
These tests are always timing out in our Jenkins CI environment. We have moved our timeout to 2 minutes. I have added a check for the short flag so other can skip these tests as we are until this can be identified.
The new vendoring was produced by running:
godep save -r ./examples/... ./prometheus/... ./text/... ./model/... ./extraction/...
Two things to note:
- "extraction/processor0_0_{1,2}_test.go" imported a package from
"github.com/prometheus/prometheus", all for just one tiny testing
function. To not have to deal with a circular vendoring dependency, I
simply replaced the usage of the function by some in-line logic.
- godep grouped the rewritten imports slightly differently for some
reason, but at least the standard library imports are still in a
separate section. Not sure if it's worth manually keeping our old
import grouping scheme or if we should simply use that godep-generated
one.
This rewrite had may backs and forths. In my git repository, it
consists of 35 commits which I cannot group or merge into reasonable
review buckets. Gerrit breaks fundamental git semantics, so I have to
squash the 35 commits into one for the review.
I'll push this not with refs/for/master, but with refs/for/next so
that we can transition after submission in a controlled fashion.
For the review, I recommend to start with looking at godoc and in
particular the many examples. After that, continue with a line-by-line
detailed review. (The big picture is hopefully as expected after
wrapping up the discussion earlier.)
Change-Id: Ib38cc46493a5139ca29d84020650929d94cac850
Arthur Silva Sens