One might argue that supporting the newest Pushgateway is just an
enhancement or even a bugfix (and this should be v1.1.1, which would
be a really nice version number). I decided to go for a positive view
of things and call it a feature. If something else changes its
behavior, it's not really a bug from client_golang's point of view.
Signed-off-by: beorn7 <beorn@grafana.com>
The part after the underscore has to be lowercase. Otherwise, it is
seen as the name of a Go type, which doesn't exist, which will result
in the example not showing up in godoc.
Signed-off-by: beorn7 <beorn@grafana.com>
This is a much stronger hash function than fnv64a and comparably fast
(with super-fast assembly implementation for amd64).
Performance is not critical here anyway.
The old fnv64a is kept for vectors, where collision detection is in
place and the weakness of the hashing doesn't matter that much. I
implemented a vector version with xxhash and found that xxhash is
slower in all cases except very very high cardinality (where it is
only slightly faster). Also, ``xxhash.New`` comes with an allocation
of 80 bytes. Thus, to keep vectors alloc-free, we needed to add a
`sync.Pool`, which would have an additional performance overhead.
Signed-off-by: beorn7 <beorn@grafana.com>
This makes the collisions a bit less likely by XOR'ing descIDs rather
than adding them up for the collectorID.
Signed-off-by: beorn7 <beorn@grafana.com>
Flush is another of the methods that will call WriteHeader if it
hasn't happened yet. Since we want to call observeWriteHeader (if
set), we need to do the WriteHeader call already here, similar to what
we have done in Write and ReadFrom.
This commit also adds comments explaining the above to not tempt
developers to remove the WriteHeader call.
Signed-off-by: beorn7 <beorn@grafana.com>
Prometheus has issues parsing RFC3339Nano timestamps if the year has more than 4 digits, in addition it is the second-pass parse attempt. Since this is a client library and the interface is a `time.Time` it makes sense that we pick the clearest simplest format-- so I propose we use the `model.Time` representation of time in our communications to prometheus. This (1) removes the issues with timezones in those queries going downstream and (2) completely works around this #614 issue as the parsing mechanism in prometheus can handle those times in this format.
Related to #614
Signed-off-by: Thomas Jackson <jacksontj.89@gmail.com>
beorn7