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>
* Introduce MetricVecOpts and add constraints to VariableLabels
MetricVecOpts exposes options specific to MetricVec initialisation. The
first option exposed by MetricVecOpts are constraints on VariableLabels,
allowing restrictions on the possible values a label can take, to
prevent cardinality explosion when the label value comes from a
non-trusted source (as a user input or HTTP header).
Signed-off-by: Quentin Devos <4972091+Okhoshi@users.noreply.github.com>
* Add tests
Signed-off-by: Quentin Devos <4972091+Okhoshi@users.noreply.github.com>
Signed-off-by: Quentin Devos <4972091+Okhoshi@users.noreply.github.com>
* prometheus: implement Collector interface for Registry
This change allows Registries to be used as Collectors.
This enables new instances of Registry to be passed to ephemeral
subroutines for collecting metrics from subroutines which are still
running:
```go
package main
import (
"fmt"
"github.com/prometheus/client_golang/prometheus"
)
func main() {
globalReg := prometheus.NewRegistry()
for i := 0; i < 100; i++ {
workerReg := prometheus.WrapRegistererWith(prometheus.Labels{
// Add an ID label so registered metrics from workers don't
// collide.
"worker_id": fmt.Sprintf("%d", i),
}, prometheus.NewRegistry()
globalReg.MustRegister(workerReg)
go func(i int) {
runWorker(workerReg)
// Unregister any metrics the worker may have created.
globalReg.Unregister(workerReg)
}(i)
}
}
// runWorker runs a worker, registering worker-specific metrics.
func runWorker(reg *prometheus.Registry) {
// ... register metrics ...
// ... do work ...
}
```
This change makes it easier to avoid leaking metrics from subroutines
which do not consistently properly unregister metrics.
Signed-off-by: Robert Fratto <robertfratto@gmail.com>
* fix grammar in doc comment
Signed-off-by: Robert Fratto <robertfratto@gmail.com>
* document why Registry implements Collector with example
Signed-off-by: Robert Fratto <robertfratto@gmail.com>
Signed-off-by: Robert Fratto <robertfratto@gmail.com>
* fix assorted oddities found by golangci-lint
Signed-off-by: Christoph Mewes <christoph@kubermatic.com>
* permanently enable the linters
Signed-off-by: Christoph Mewes <christoph@kubermatic.com>
* post-rebase blues
Signed-off-by: Christoph Mewes <christoph@kubermatic.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 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>
This unifies both constructors in one with an options argument.
The options argument allows to switch on error reporting, as discussed
in #219.
The change of the contructor signature is breaking, but only mildly
so. Plus, the process collector is rarely used explicitly. I used
Sourcegraph to search for public usages, with the following results:
- 2 occurrences of NewProcessCollectorPIDFn, once in @discordianfish's
glimpse, once in @fabxc's etcd_exporter (deprecated anyway). Both
are Prom veterans and will simply do the one line change if needed.
- 8 occurrences of NewProcessCollector, of which 7 are of the form
NewProcessCollector(os.Getpid(), "")
Thus, it's a very easy change, which I even hinted at in the doc
comment.
Signed-off-by: beorn7 <beorn@soundcloud.com>
The only known external usage of it was in prometheus/pushgateway,
where it was removed by
https://github.com/prometheus/pushgateway/pull/200 .
Originally, the expectation was that users would implement the Metric
interface now and then. As we know now, neither it is happening, nor
would it make a lot of sense. (Users implement the Collector interface
instead.) By now, LabelPairSorter is essentially noise in the already
quite cluttered namespace in the prometheus package.
Signed-off-by: beorn7 <beorn@soundcloud.com>
This is for types we don't want to export but which are used in
different packages within client_golang.
Currently, that's only NormalizeMetricFamilies (used in the prometheus
package and in the testutil package). More to be added as needed.
Signed-off-by: beorn7 <beorn@soundcloud.com>
So far, if a gauge was named `xxx_count`, and a summary or histogram
`xxx`, this would have led to a legal protobuf exposition but would
have created a name collision on `xxx_count` in the text format and
within the Prometheus server.
Signed-off-by: beorn7 <beorn@soundcloud.com>
Also, clarify in the doc comment.
Previously, the assumption was that inconsistent label dimensions are
violating the exposition format spec. However, especially with the
knowledge that OpenMetrics will explicitly allow inconsistent label
dimensions in expositions, we should allow it in client_golang, too.
Note that registration with proper Descs provided will still check for
consistont label dimensions. However, you can "cheat" with custom
Collectors as you can collect metrics that don't follew the provided
Desc (this will be made more explicit and less cheaty once #47 is
fixed). You can also create expositions with inconsistent label
dimensions by merging Gatherers with the Gatherers slice type. (The
latter is used in the Pushgateway.)
Effectively, normal direct instrumentation will always have consistent
label dimensions in this way, but you can cover special use cases with
custom collectors or merging of different Gatherers.
Signed-off-by: beorn7 <beorn@soundcloud.com>
While not strictly correct, it can easily happen that proto messages
are created that use nil pointers instead of pointers in empty strings
to denote an empty string.
Signed-off-by: beorn7 <beorn@soundcloud.com>
Oleksandr Redko