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>
- Expected text format is now read from an io.Reader.
- Metrics are gathered from a Gatherer.
- Added a convenience wrapper to collect from a Collector.
Signed-off-by: beorn7 <beorn@soundcloud.com>
`testutil` is more in line with stdlib naming conventions.
The package should be below `prometheus` as it only provides utils to
test exposition code, not to test HTTP client code.
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>
400 and 422 are documented error codes from Prometheus, so we should
attempt to parse the error returned for both of them.
Needed to change a test that was requiring the old behaviour - made it
use 500 instead of 400.
Signed-off-by: Bryan Boreham <bjboreham@gmail.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>