Move everything over to a more expensive but less collision-prone way.
However, keep the old fingerprinting under the name "FastFingerprint"
to be used in the storage layer (where we need collision detection
anyway).
This fixes https://github.com/prometheus/client_golang/issues/74 .
IT CHANGES THE FINGERPRINTING AND THEREFORE INVALIDATES EACH AND EVERY
PERSISTED FINGERPRINT (I.E. YOU HAVE TO WIPE THE STORAGE TO USE THIS).
This commit removes the LabelValuesToSignature function as it is used
nowhere (and broken in the way it is implemented right now).
Also, remove one more golint warning.
Also, add a test to expose
https://github.com/prometheus/client_golang/issues/74 .
benchmark old ns/op new ns/op delta
BenchmarkMetric 7034 6272 -10.83%
benchmark old allocs new allocs delta
BenchmarkMetric 52 32 -38.46%
benchmark old bytes new bytes delta
BenchmarkMetric 1976 1800 -8.91%
Summaries as implemented cannot be aggregated in a meaningful
way. Partitoning them by status code and method only made sense if we
were interested in the individual latency and size of e.g. GET request
that result in status 503. In general, that's not the case. Most of
the time, the user will be interested in the latency and size of _all_
HTTP requests.
(With future changes to client_golang, we will consider making the
HTTP instrumentation configurable, e.g. to handle the case where the
user is only interested in the latency of successful requests.)
- Change Fingerprints to be simple uint64s.
- Deal sensibly with missing metric names.
- Enable finer-grained time resolution.
Merge this concurrently with the merge of the new storage backend into
prometheus/prometheus.
Change-Id: Idd82f137aa0c4286df422c53ce3c62e0de285360
This is actually the intended behavior, and (as a nice side effect)
makes things cheaper to calculate.
Also, introduce a separator character to avoid hash collisions
(like label values {"ab","c"} vs {"a", "bc"}).
Apply the same principles to signature.go.
Change-Id: I607db544f278ed89684fe5fa11abdbc3e03d3061
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
The LabelsToSignature function is now used outside of the prometheus
package, too. Leaving it in the prometheuos package is misleading
design and will lead to circulat import chains soon.
Change-Id: If1ca442d4023b33b138cf79fee68e82ff2a355be
This also adds a check that forbids any user-supplied metrics to start
with the reserved label name prefix "__".
Change-Id: I2fe94c740b685ad05c4c670613cf2af7b9e1c1c0
So far we've been using Go's native time.Time for anything related to sample
timestamps. Since the range of time.Time is much bigger than what we need, this
has created two problems:
- there could be time.Time values which were out of the range/precision of the
time type that we persist to disk, therefore causing incorrectly ordered keys.
One bug caused by this was:
https://github.com/prometheus/prometheus/issues/367
It would be good to use a timestamp type that's more closely aligned with
what the underlying storage supports.
- sizeof(time.Time) is 192, while Prometheus should be ok with a single 64-bit
Unix timestamp (possibly even a 32-bit one). Since we store samples in large
numbers, this seriously affects memory usage. Furthermore, copying/working
with the data will be faster if it's smaller.
*MEMORY USAGE RESULTS*
Initial memory usage comparisons for a running Prometheus with 1 timeseries and
100,000 samples show roughly a 13% decrease in total (VIRT) memory usage. In my
tests, this advantage for some reason decreased a bit the more samples the
timeseries had (to 5-7% for millions of samples). This I can't fully explain,
but perhaps garbage collection issues were involved.
*WHEN TO USE THE NEW TIMESTAMP TYPE*
The new clientmodel.Timestamp type should be used whenever time
calculations are either directly or indirectly related to sample
timestamps.
For example:
- the timestamp of a sample itself
- all kinds of watermarks
- anything that may become or is compared to a sample timestamp (like the timestamp
passed into Target.Scrape()).
When to still use time.Time:
- for measuring durations/times not related to sample timestamps, like duration
telemetry exporting, timers that indicate how frequently to execute some
action, etc.
Change-Id: I253a467388774280c10400fda122369ff77c1730
Colliding labels can happen e.g. when an exporter job is scraped and already
includes "job" labels for its samples in /metrics. In this case, a
collisionPrefix of "exporter_" is added to the colliding target labels, but the
specifics (the collision prefix) are managed by Prometheus, not the client
library.
This commit introduces all relevant server-side artifacts such that the
Result streams can be used by external parties for one-off tools and
such. This will ultimately better enable us to support additional
wireformats with much more ease.
Fabian Reinartz