mirror
/
client_golang
mirror of https://github.com/prometheus/client_golang.git
1
0
Fork 1
Code Issues Packages Projects Releases Wiki Activity
client_golang/prometheus/registry_test.go

874 lines
23 KiB
Go
Raw Normal View History

Change "Prometheus Team" to "The Prometheus Authors".
2015-02-02 17:14:36 +03:00
// Copyright 2014 The Prometheus Authors
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
Change "Prometheus Team" to "The Prometheus Authors".
2015-02-02 17:14:36 +03:00
// Copyright (c) 2013, The Prometheus Authors
Update client to reflect new API needs. 1. The output format is now versioned per the Semantic Versioning scheme. Mainline Prometheus will be adapted to use differing consumption methodologies as the generators' formats evolve to support legacy clients. 2. The telemetry outputter now supports GZIP output encoding. In sample runs, this cuts the output size in half. 3. Basic sanity tests are added for registration with varying levels of pedanticness. 4. We have support for base labels in the registration and emission phases. 5. We have label support for individual metric mutation operations. 6. A number of simplications have been made.
2013-01-19 17:48:30 +04:00
// All rights reserved.
//
Sundry cosmetic fixes across the board. - Comments are migrated from ``/* */`` to ``//`` per convention. - ``NewDefaultHistogram`` helper. - ``Registry.Handler`` and ``Registry.YieldExporter`` deprecation. - Cleanup of legacy import paths. - Updating examples to use acknowledged patterns. - Parameterizing the random parameter namespaces for ``examples/random/main.go``, which is useful for demoing population behaviors.
2013-02-12 05:36:06 +04:00
// Use of this source code is governed by a BSD-style license that can be found
// in the LICENSE file.
Update client to reflect new API needs. 1. The output format is now versioned per the Semantic Versioning scheme. Mainline Prometheus will be adapted to use differing consumption methodologies as the generators' formats evolve to support legacy clients. 2. The telemetry outputter now supports GZIP output encoding. In sample runs, this cuts the output size in half. 3. Basic sanity tests are added for registration with varying levels of pedanticness. 4. We have support for base labels in the registration and emission phases. 5. We have label support for individual metric mutation operations. 6. A number of simplications have been made.
2013-01-19 17:48:30 +04:00
Move http stuff in its own package promhttp To keep backwards compatibility while not creating circular import chains, some code had to be duplicated. But all functions using it have been declared deprecated hereby. The new ways of instrumenting handlers will all go into the new package, and ultimately, the prometheus package itself will be completely igorant of HTTP.
2016-08-03 15:57:02 +03:00
package prometheus_test
Update client to reflect new API needs. 1. The output format is now versioned per the Semantic Versioning scheme. Mainline Prometheus will be adapted to use differing consumption methodologies as the generators' formats evolve to support legacy clients. 2. The telemetry outputter now supports GZIP output encoding. In sample runs, this cuts the output size in half. 3. Basic sanity tests are added for registration with varying levels of pedanticness. 4. We have support for base labels in the registration and emission phases. 5. We have label support for individual metric mutation operations. 6. A number of simplications have been made.
2013-01-19 17:48:30 +04:00
import (
"bytes"
Add a concurrent end-to-end test for observe-register-gather This is an attempt to expose https://github.com/istio/istio/issues/8906 . The failure to do so makes me believe the error is either already fixed in current client_golang, or something weird I haven't spotted yet is happening in the istio code. Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-10-10 17:59:24 +03:00
"math/rand"
Update client to reflect new API needs. 1. The output format is now versioned per the Semantic Versioning scheme. Mainline Prometheus will be adapted to use differing consumption methodologies as the generators' formats evolve to support legacy clients. 2. The telemetry outputter now supports GZIP output encoding. In sample runs, this cuts the output size in half. 3. Basic sanity tests are added for registration with varying levels of pedanticness. 4. We have support for base labels in the registration and emission phases. 5. We have label support for individual metric mutation operations. 6. A number of simplications have been made.
2013-01-19 17:48:30 +04:00
"net/http"
Create a public registry interface and separate out HTTP exposition General context and approch =========================== This is the first part of the long awaited wider refurbishment of `client_golang/prometheus/...`. After a lot of struggling, I decided to not go for one breaking big-bang, but cut things into smaller steps after all, mostly to keep the changes manageable and easy to review. I'm aiming for having the invasive breaking changes concentrated in as few steps as possible (ideally one). Some steps will not be breaking at all, but typically there will be breaking changes that only affect quite special cases so that 95+% of users will not be affected. This first step is an example for that, see details below. What's happening in this commit? ================================ This step is about finally creating an exported registry interface. This could not be done by simply export the existing internal implementation because the interface would be _way_ too fat. This commit introduces a qutie lean `Registry` interface (compared to the previous interval implementation). The functions that act on the default registry are retained (with very few exceptions) so that most use cases won't see a change. However, several of those are deprecated now to clean up the namespace in the future. The default registry is kept in the public variable `DefaultRegistry`. This follows the example of the http package in the standard library (cf. `http.DefaultServeMux`, `http.DefaultClient`) with the same implications. (This pattern is somewhat disputed within the Go community but I chose to go with the devil you know instead of creating something more complex or even disallowing any changes to the default registry. The current approach gives everybody the freedom to not touch DefaultRegistry or to do everything with a custom registry to play save.) Another important part in making the registry lean is the extraction of the HTTP exposition, which also allows for customization of the HTTP exposition. Note that the separation of metric collection and exposition has the side effect that managing the MetricFamily and Metric protobuf objects in a free-list or pool isn't really feasible anymore. By now (with better GC in more recent Go versions), the returns were anyway dimisishing. To be effective at all, scrapes had to happen more often than GC cycles, and even then most elements of the protobufs (everything excetp the MetricFamily and Metric structs themselves) would still cause allocation churn. In a future breaking change, the signature of the Write method in the Metric interface will be adjusted accordingly. In this commit, avoiding breakage is more important. The following issues are fixed by this commit (some solved "on the fly" now that I was touching the code anyway and it would have been stupid to port the bugs): https://github.com/prometheus/client_golang/issues/46 https://github.com/prometheus/client_golang/issues/100 https://github.com/prometheus/client_golang/issues/170 https://github.com/prometheus/client_golang/issues/205 Documentation including examples have been amended as required. What future changes does this commit enable? ============================================ The following items are not yet implemented, but this commit opens the possibility of implementing these independently. - The separation of the HTTP exposition allows the implementation of other exposition methods based on the Registry interface, as known from other Prometheus client libraries, e.g. sending the metrics to Graphite. Cf. https://github.com/prometheus/client_golang/issues/197 - The public `Registry` interface allows the implementation of convenience tools for testing metrics collection. Those tools can inspect the collected MetricFamily protobufs and compare them to expectation. Also, tests can use their own testing instance of a registry. Cf. https://github.com/prometheus/client_golang/issues/58 Notable non-goals of this commit ================================ Non-goals that will be tackled later ------------------------------------ The following two issues are quite closely connected to the changes in this commit but the line has been drawn deliberately to address them in later steps of the refurbishment: - `InstrumentHandler` has many known problems. The plan is to create a saner way to conveniently intrument HTTP handlers and remove the old `InstrumentHandler` altogether. To keep breakage low for now, even the default handler to expose metrics is still using the old `InstrumentHandler`. This leads to weird naming inconsistencies but I have deemed it better to not break the world right now but do it in the change that provides better ways of instrumenting HTTP handlers. Cf. https://github.com/prometheus/client_golang/issues/200 - There is work underway to make the whole handling of metric descriptors (`Desc`) more intuitive and transparent for the user (including an ability for less strict checking, cf. https://github.com/prometheus/client_golang/issues/47). That's quite invasive from the perspective of the internal code, namely the registry. I deliberately kept those changes out of this commit. - While this commit adds new external dependency, the effort to vendor anything within the library that is not visible in any exported types will have to be done later. Non-goals that _might_ be tackled later --------------------------------------- There is a strong and understandable urge to divide the `prometheus` package into a number of sub-packages (like `registry`, `collectors`, `http`, `metrics`, …). However, to not run into a multitude of circular import chains, this would need to break every single existing usage of the library. (As just one example, if the ubiquitious `prometheus.MustRegister` (with more than 2,000 uses on GitHub alone) is kept in the `prometheus` package, but the other registry concerns go into a new `registry` package, then the `prometheus` package would import the `registry` package (to call the actual register method), while at the same time the `registry` package needs to import the `prometheus` package to access `Collector`, `Metric`, `Desc` and more. If we moved `MustRegister` into the `registry` package, thousands of code lines would have to be fixed (which would be easy if the world was a mono repo, but it is not). If we moved everything else the proposed registry package needs into packages of their own, we would break thousands of other code lines.) The main problem is really the top-level functions like `MustRegister`, `Handler`, …, which effectively pull everything into one package. Those functions are however very convenient for the easy and very frequent use-cases. This problem has to be revisited later. For now, I'm trying to keep the amount of exported names in the package as low as possible (e.g. I unexported expvarCollector in this commit because the NewExpvarCollector constructor is enough to export, and it is now consistent with other collectors, like the goCollector). Non-goals that won't be tackled anytime soon -------------------------------------------- Something that I have played with a lot is "streaming collection", i.e. allow an implementation of the `Registry` interface that collects metrics incrementally and serves them while doing so. As it has turned out, this has many many issues and makes the `Registry` interface very clunky. Eventually, I made the call that it is unlikely we will really implement streaming collection; and making the interface more clunky for something that might not even happen is really a big no-no. Note that the `Registry` interface only creates the in-memory representation of the metric family protobufs in one go. The serializaton onto the wire can still be handled in a streaming fashion (which hasn't been done so far, without causing any trouble, but might be done in the future without breaking any interfaces). What are the breaking changes? ============================== - Signatures of functions pushing to Pushgateway have changed to allow arbitrary grouping (which was planned for a long time anyway, and now that I had to work on the Push code anyway for the registry refurbishment, I finally did it, cf. https://github.com/prometheus/client_golang/issues/100). With the gained insight that pushing to the default registry is almost never the right thing, and now that we are breaking the Push call anyway, all the Push functions were moved to their own package, which cleans up the namespace and is more idiomatic (pushing Collectors is now literally done by `push.Collectors(...)`). - The registry is doing more consistency checks by default now. Past creators of inconsistent metrics could have masked the problem by not setting `EnableCollectChecks`. Those inconsistencies will now be detected. (But note that a "best effort" metrics collection is now possible with `HandlerOpts.ErrorHandling = ContinueOnError`.) - `EnableCollectChecks` is gone. The registry is now performing some of those checks anyway (see previous item), and a registry with all of those checks can now be created with `NewPedanticRegistry` (only used for testing). - `PanicOnCollectError` is gone. This behavior can now be configured when creating a custom HTTP handler.
2016-07-20 18:11:14 +03:00
"net/http/httptest"
Add a concurrent end-to-end test for observe-register-gather This is an attempt to expose https://github.com/istio/istio/issues/8906 . The failure to do so makes me believe the error is either already fixed in current client_golang, or something weird I haven't spotted yet is happening in the istio code. Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-10-10 17:59:24 +03:00
"sync"
Update client to reflect new API needs. 1. The output format is now versioned per the Semantic Versioning scheme. Mainline Prometheus will be adapted to use differing consumption methodologies as the generators' formats evolve to support legacy clients. 2. The telemetry outputter now supports GZIP output encoding. In sample runs, this cuts the output size in half. 3. Basic sanity tests are added for registration with varying levels of pedanticness. 4. We have support for base labels in the registration and emission phases. 5. We have label support for individual metric mutation operations. 6. A number of simplications have been made.
2013-01-19 17:48:30 +04:00
"testing"
Add a concurrent end-to-end test for observe-register-gather This is an attempt to expose https://github.com/istio/istio/issues/8906 . The failure to do so makes me believe the error is either already fixed in current client_golang, or something weird I haven't spotted yet is happening in the istio code. Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-10-10 17:59:24 +03:00
"time"
Protocol Buffer negotiation support in handler.
2013-06-27 20:46:16 +04:00
Use non-rewritten Godep imports.
2015-02-27 18:12:59 +03:00
dto "github.com/prometheus/client_model/go"
Move http stuff in its own package promhttp To keep backwards compatibility while not creating circular import chains, some code had to be duplicated. But all functions using it have been declared deprecated hereby. The new ways of instrumenting handlers will all go into the new package, and ultimately, the prometheus package itself will be completely igorant of HTTP.
2016-08-03 15:57:02 +03:00
"github.com/golang/protobuf/proto"
Create a public registry interface and separate out HTTP exposition General context and approch =========================== This is the first part of the long awaited wider refurbishment of `client_golang/prometheus/...`. After a lot of struggling, I decided to not go for one breaking big-bang, but cut things into smaller steps after all, mostly to keep the changes manageable and easy to review. I'm aiming for having the invasive breaking changes concentrated in as few steps as possible (ideally one). Some steps will not be breaking at all, but typically there will be breaking changes that only affect quite special cases so that 95+% of users will not be affected. This first step is an example for that, see details below. What's happening in this commit? ================================ This step is about finally creating an exported registry interface. This could not be done by simply export the existing internal implementation because the interface would be _way_ too fat. This commit introduces a qutie lean `Registry` interface (compared to the previous interval implementation). The functions that act on the default registry are retained (with very few exceptions) so that most use cases won't see a change. However, several of those are deprecated now to clean up the namespace in the future. The default registry is kept in the public variable `DefaultRegistry`. This follows the example of the http package in the standard library (cf. `http.DefaultServeMux`, `http.DefaultClient`) with the same implications. (This pattern is somewhat disputed within the Go community but I chose to go with the devil you know instead of creating something more complex or even disallowing any changes to the default registry. The current approach gives everybody the freedom to not touch DefaultRegistry or to do everything with a custom registry to play save.) Another important part in making the registry lean is the extraction of the HTTP exposition, which also allows for customization of the HTTP exposition. Note that the separation of metric collection and exposition has the side effect that managing the MetricFamily and Metric protobuf objects in a free-list or pool isn't really feasible anymore. By now (with better GC in more recent Go versions), the returns were anyway dimisishing. To be effective at all, scrapes had to happen more often than GC cycles, and even then most elements of the protobufs (everything excetp the MetricFamily and Metric structs themselves) would still cause allocation churn. In a future breaking change, the signature of the Write method in the Metric interface will be adjusted accordingly. In this commit, avoiding breakage is more important. The following issues are fixed by this commit (some solved "on the fly" now that I was touching the code anyway and it would have been stupid to port the bugs): https://github.com/prometheus/client_golang/issues/46 https://github.com/prometheus/client_golang/issues/100 https://github.com/prometheus/client_golang/issues/170 https://github.com/prometheus/client_golang/issues/205 Documentation including examples have been amended as required. What future changes does this commit enable? ============================================ The following items are not yet implemented, but this commit opens the possibility of implementing these independently. - The separation of the HTTP exposition allows the implementation of other exposition methods based on the Registry interface, as known from other Prometheus client libraries, e.g. sending the metrics to Graphite. Cf. https://github.com/prometheus/client_golang/issues/197 - The public `Registry` interface allows the implementation of convenience tools for testing metrics collection. Those tools can inspect the collected MetricFamily protobufs and compare them to expectation. Also, tests can use their own testing instance of a registry. Cf. https://github.com/prometheus/client_golang/issues/58 Notable non-goals of this commit ================================ Non-goals that will be tackled later ------------------------------------ The following two issues are quite closely connected to the changes in this commit but the line has been drawn deliberately to address them in later steps of the refurbishment: - `InstrumentHandler` has many known problems. The plan is to create a saner way to conveniently intrument HTTP handlers and remove the old `InstrumentHandler` altogether. To keep breakage low for now, even the default handler to expose metrics is still using the old `InstrumentHandler`. This leads to weird naming inconsistencies but I have deemed it better to not break the world right now but do it in the change that provides better ways of instrumenting HTTP handlers. Cf. https://github.com/prometheus/client_golang/issues/200 - There is work underway to make the whole handling of metric descriptors (`Desc`) more intuitive and transparent for the user (including an ability for less strict checking, cf. https://github.com/prometheus/client_golang/issues/47). That's quite invasive from the perspective of the internal code, namely the registry. I deliberately kept those changes out of this commit. - While this commit adds new external dependency, the effort to vendor anything within the library that is not visible in any exported types will have to be done later. Non-goals that _might_ be tackled later --------------------------------------- There is a strong and understandable urge to divide the `prometheus` package into a number of sub-packages (like `registry`, `collectors`, `http`, `metrics`, …). However, to not run into a multitude of circular import chains, this would need to break every single existing usage of the library. (As just one example, if the ubiquitious `prometheus.MustRegister` (with more than 2,000 uses on GitHub alone) is kept in the `prometheus` package, but the other registry concerns go into a new `registry` package, then the `prometheus` package would import the `registry` package (to call the actual register method), while at the same time the `registry` package needs to import the `prometheus` package to access `Collector`, `Metric`, `Desc` and more. If we moved `MustRegister` into the `registry` package, thousands of code lines would have to be fixed (which would be easy if the world was a mono repo, but it is not). If we moved everything else the proposed registry package needs into packages of their own, we would break thousands of other code lines.) The main problem is really the top-level functions like `MustRegister`, `Handler`, …, which effectively pull everything into one package. Those functions are however very convenient for the easy and very frequent use-cases. This problem has to be revisited later. For now, I'm trying to keep the amount of exported names in the package as low as possible (e.g. I unexported expvarCollector in this commit because the NewExpvarCollector constructor is enough to export, and it is now consistent with other collectors, like the goCollector). Non-goals that won't be tackled anytime soon -------------------------------------------- Something that I have played with a lot is "streaming collection", i.e. allow an implementation of the `Registry` interface that collects metrics incrementally and serves them while doing so. As it has turned out, this has many many issues and makes the `Registry` interface very clunky. Eventually, I made the call that it is unlikely we will really implement streaming collection; and making the interface more clunky for something that might not even happen is really a big no-no. Note that the `Registry` interface only creates the in-memory representation of the metric family protobufs in one go. The serializaton onto the wire can still be handled in a streaming fashion (which hasn't been done so far, without causing any trouble, but might be done in the future without breaking any interfaces). What are the breaking changes? ============================== - Signatures of functions pushing to Pushgateway have changed to allow arbitrary grouping (which was planned for a long time anyway, and now that I had to work on the Push code anyway for the registry refurbishment, I finally did it, cf. https://github.com/prometheus/client_golang/issues/100). With the gained insight that pushing to the default registry is almost never the right thing, and now that we are breaking the Push call anyway, all the Push functions were moved to their own package, which cleans up the namespace and is more idiomatic (pushing Collectors is now literally done by `push.Collectors(...)`). - The registry is doing more consistency checks by default now. Past creators of inconsistent metrics could have masked the problem by not setting `EnableCollectChecks`. Those inconsistencies will now be detected. (But note that a "best effort" metrics collection is now possible with `HandlerOpts.ErrorHandling = ContinueOnError`.) - `EnableCollectChecks` is gone. The registry is now performing some of those checks anyway (see previous item), and a registry with all of those checks can now be created with `NewPedanticRegistry` (only used for testing). - `PanicOnCollectError` is gone. This behavior can now be configured when creating a custom HTTP handler.
2016-07-20 18:11:14 +03:00
"github.com/prometheus/common/expfmt"
Move http stuff in its own package promhttp To keep backwards compatibility while not creating circular import chains, some code had to be duplicated. But all functions using it have been declared deprecated hereby. The new ways of instrumenting handlers will all go into the new package, and ultimately, the prometheus package itself will be completely igorant of HTTP.
2016-08-03 15:57:02 +03:00
"github.com/prometheus/client_golang/prometheus"
"github.com/prometheus/client_golang/prometheus/promhttp"
Update client to reflect new API needs. 1. The output format is now versioned per the Semantic Versioning scheme. Mainline Prometheus will be adapted to use differing consumption methodologies as the generators' formats evolve to support legacy clients. 2. The telemetry outputter now supports GZIP output encoding. In sample runs, this cuts the output size in half. 3. Basic sanity tests are added for registration with varying levels of pedanticness. 4. We have support for base labels in the registration and emission phases. 5. We have label support for individual metric mutation operations. 6. A number of simplications have been made.
2013-01-19 17:48:30 +04:00
)
Introduce unchecked Collectors Fixes #47 . See there for more detailed discussion. Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-07-09 02:03:22 +03:00
// uncheckedCollector wraps a Collector but its Describe method yields no Desc.
type uncheckedCollector struct {
c prometheus.Collector
}
func (u uncheckedCollector) Describe(_ chan<- *prometheus.Desc) {}
func (u uncheckedCollector) Collect(c chan<- prometheus.Metric) {
u.c.Collect(c)
}
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
func testHandler(t testing.TB) {
Introduce unchecked Collectors Fixes #47 . See there for more detailed discussion. Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-07-09 02:03:22 +03:00
// TODO(beorn7): This test is a bit too "end-to-end". It tests quite a
// few moving parts that are not strongly coupled. They could/should be
// tested separately. However, the changes planned for v0.10 will
// require a major rework of this test anyway, at which time I will
// structure it in a better way.
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
Move http stuff in its own package promhttp To keep backwards compatibility while not creating circular import chains, some code had to be duplicated. But all functions using it have been declared deprecated hereby. The new ways of instrumenting handlers will all go into the new package, and ultimately, the prometheus package itself will be completely igorant of HTTP.
2016-08-03 15:57:02 +03:00
metricVec := prometheus.NewCounterVec(
prometheus.CounterOpts{
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
Name: "name",
Help: "docstring",
Move http stuff in its own package promhttp To keep backwards compatibility while not creating circular import chains, some code had to be duplicated. But all functions using it have been declared deprecated hereby. The new ways of instrumenting handlers will all go into the new package, and ultimately, the prometheus package itself will be completely igorant of HTTP.
2016-08-03 15:57:02 +03:00
ConstLabels: prometheus.Labels{"constname": "constvalue"},
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
},
[]string{"labelname"},
)
metricVec.WithLabelValues("val1").Inc()
metricVec.WithLabelValues("val2").Inc()
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
Allow the metric family injection hook to merge with existing metric families. If a metric family returned by the injection hook already exists (with the same name), then its metrics are simply merged into that metric family. With enabled collect-time checks, even uniqueness is checked, but in general, things stay the same that the caller is responsible to ensure metric consistency. This fixes https://github.com/prometheus/pushgateway/issues/27 .
2015-03-15 17:47:56 +03:00
externalMetricFamily := &dto.MetricFamily{
Name: proto.String("externalname"),
Help: proto.String("externaldocstring"),
Type: dto.MetricType_COUNTER.Enum(),
Metric: []*dto.Metric{
{
Label: []*dto.LabelPair{
{
Name: proto.String("externalconstname"),
Value: proto.String("externalconstvalue"),
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
Fix a number of minor things. - Clarify documentation about sorting requirements. - Add missing histogram support in consistency check. - Add label sorting to consistency check. - Improve error messages when reporting a metric. (Previously, the metric name was not printed.)
2015-06-08 23:12:07 +03:00
{
Name: proto.String("externallabelname"),
Value: proto.String("externalval1"),
},
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
Allow the metric family injection hook to merge with existing metric families. If a metric family returned by the injection hook already exists (with the same name), then its metrics are simply merged into that metric family. With enabled collect-time checks, even uniqueness is checked, but in general, things stay the same that the caller is responsible to ensure metric consistency. This fixes https://github.com/prometheus/pushgateway/issues/27 .
2015-03-15 17:47:56 +03:00
Counter: &dto.Counter{
Value: proto.Float64(1),
},
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
},
}
Create a public registry interface and separate out HTTP exposition General context and approch =========================== This is the first part of the long awaited wider refurbishment of `client_golang/prometheus/...`. After a lot of struggling, I decided to not go for one breaking big-bang, but cut things into smaller steps after all, mostly to keep the changes manageable and easy to review. I'm aiming for having the invasive breaking changes concentrated in as few steps as possible (ideally one). Some steps will not be breaking at all, but typically there will be breaking changes that only affect quite special cases so that 95+% of users will not be affected. This first step is an example for that, see details below. What's happening in this commit? ================================ This step is about finally creating an exported registry interface. This could not be done by simply export the existing internal implementation because the interface would be _way_ too fat. This commit introduces a qutie lean `Registry` interface (compared to the previous interval implementation). The functions that act on the default registry are retained (with very few exceptions) so that most use cases won't see a change. However, several of those are deprecated now to clean up the namespace in the future. The default registry is kept in the public variable `DefaultRegistry`. This follows the example of the http package in the standard library (cf. `http.DefaultServeMux`, `http.DefaultClient`) with the same implications. (This pattern is somewhat disputed within the Go community but I chose to go with the devil you know instead of creating something more complex or even disallowing any changes to the default registry. The current approach gives everybody the freedom to not touch DefaultRegistry or to do everything with a custom registry to play save.) Another important part in making the registry lean is the extraction of the HTTP exposition, which also allows for customization of the HTTP exposition. Note that the separation of metric collection and exposition has the side effect that managing the MetricFamily and Metric protobuf objects in a free-list or pool isn't really feasible anymore. By now (with better GC in more recent Go versions), the returns were anyway dimisishing. To be effective at all, scrapes had to happen more often than GC cycles, and even then most elements of the protobufs (everything excetp the MetricFamily and Metric structs themselves) would still cause allocation churn. In a future breaking change, the signature of the Write method in the Metric interface will be adjusted accordingly. In this commit, avoiding breakage is more important. The following issues are fixed by this commit (some solved "on the fly" now that I was touching the code anyway and it would have been stupid to port the bugs): https://github.com/prometheus/client_golang/issues/46 https://github.com/prometheus/client_golang/issues/100 https://github.com/prometheus/client_golang/issues/170 https://github.com/prometheus/client_golang/issues/205 Documentation including examples have been amended as required. What future changes does this commit enable? ============================================ The following items are not yet implemented, but this commit opens the possibility of implementing these independently. - The separation of the HTTP exposition allows the implementation of other exposition methods based on the Registry interface, as known from other Prometheus client libraries, e.g. sending the metrics to Graphite. Cf. https://github.com/prometheus/client_golang/issues/197 - The public `Registry` interface allows the implementation of convenience tools for testing metrics collection. Those tools can inspect the collected MetricFamily protobufs and compare them to expectation. Also, tests can use their own testing instance of a registry. Cf. https://github.com/prometheus/client_golang/issues/58 Notable non-goals of this commit ================================ Non-goals that will be tackled later ------------------------------------ The following two issues are quite closely connected to the changes in this commit but the line has been drawn deliberately to address them in later steps of the refurbishment: - `InstrumentHandler` has many known problems. The plan is to create a saner way to conveniently intrument HTTP handlers and remove the old `InstrumentHandler` altogether. To keep breakage low for now, even the default handler to expose metrics is still using the old `InstrumentHandler`. This leads to weird naming inconsistencies but I have deemed it better to not break the world right now but do it in the change that provides better ways of instrumenting HTTP handlers. Cf. https://github.com/prometheus/client_golang/issues/200 - There is work underway to make the whole handling of metric descriptors (`Desc`) more intuitive and transparent for the user (including an ability for less strict checking, cf. https://github.com/prometheus/client_golang/issues/47). That's quite invasive from the perspective of the internal code, namely the registry. I deliberately kept those changes out of this commit. - While this commit adds new external dependency, the effort to vendor anything within the library that is not visible in any exported types will have to be done later. Non-goals that _might_ be tackled later --------------------------------------- There is a strong and understandable urge to divide the `prometheus` package into a number of sub-packages (like `registry`, `collectors`, `http`, `metrics`, …). However, to not run into a multitude of circular import chains, this would need to break every single existing usage of the library. (As just one example, if the ubiquitious `prometheus.MustRegister` (with more than 2,000 uses on GitHub alone) is kept in the `prometheus` package, but the other registry concerns go into a new `registry` package, then the `prometheus` package would import the `registry` package (to call the actual register method), while at the same time the `registry` package needs to import the `prometheus` package to access `Collector`, `Metric`, `Desc` and more. If we moved `MustRegister` into the `registry` package, thousands of code lines would have to be fixed (which would be easy if the world was a mono repo, but it is not). If we moved everything else the proposed registry package needs into packages of their own, we would break thousands of other code lines.) The main problem is really the top-level functions like `MustRegister`, `Handler`, …, which effectively pull everything into one package. Those functions are however very convenient for the easy and very frequent use-cases. This problem has to be revisited later. For now, I'm trying to keep the amount of exported names in the package as low as possible (e.g. I unexported expvarCollector in this commit because the NewExpvarCollector constructor is enough to export, and it is now consistent with other collectors, like the goCollector). Non-goals that won't be tackled anytime soon -------------------------------------------- Something that I have played with a lot is "streaming collection", i.e. allow an implementation of the `Registry` interface that collects metrics incrementally and serves them while doing so. As it has turned out, this has many many issues and makes the `Registry` interface very clunky. Eventually, I made the call that it is unlikely we will really implement streaming collection; and making the interface more clunky for something that might not even happen is really a big no-no. Note that the `Registry` interface only creates the in-memory representation of the metric family protobufs in one go. The serializaton onto the wire can still be handled in a streaming fashion (which hasn't been done so far, without causing any trouble, but might be done in the future without breaking any interfaces). What are the breaking changes? ============================== - Signatures of functions pushing to Pushgateway have changed to allow arbitrary grouping (which was planned for a long time anyway, and now that I had to work on the Push code anyway for the registry refurbishment, I finally did it, cf. https://github.com/prometheus/client_golang/issues/100). With the gained insight that pushing to the default registry is almost never the right thing, and now that we are breaking the Push call anyway, all the Push functions were moved to their own package, which cleans up the namespace and is more idiomatic (pushing Collectors is now literally done by `push.Collectors(...)`). - The registry is doing more consistency checks by default now. Past creators of inconsistent metrics could have masked the problem by not setting `EnableCollectChecks`. Those inconsistencies will now be detected. (But note that a "best effort" metrics collection is now possible with `HandlerOpts.ErrorHandling = ContinueOnError`.) - `EnableCollectChecks` is gone. The registry is now performing some of those checks anyway (see previous item), and a registry with all of those checks can now be created with `NewPedanticRegistry` (only used for testing). - `PanicOnCollectError` is gone. This behavior can now be configured when creating a custom HTTP handler.
2016-07-20 18:11:14 +03:00
externalBuf := &bytes.Buffer{}
enc := expfmt.NewEncoder(externalBuf, expfmt.FmtProtoDelim)
if err := enc.Encode(externalMetricFamily); err != nil {
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
t.Fatal(err)
}
externalMetricFamilyAsBytes := externalBuf.Bytes()
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
externalMetricFamilyAsText := []byte(`# HELP externalname externaldocstring
# TYPE externalname counter
Fix a number of minor things. - Clarify documentation about sorting requirements. - Add missing histogram support in consistency check. - Add label sorting to consistency check. - Improve error messages when reporting a metric. (Previously, the metric name was not printed.)
2015-06-08 23:12:07 +03:00
externalname{externalconstname="externalconstvalue",externallabelname="externalval1"} 1
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
`)
externalMetricFamilyAsProtoText := []byte(`name: "externalname"
help: "externaldocstring"
type: COUNTER
metric: <
label: <
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
name: "externalconstname"
value: "externalconstvalue"
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
>
Fix a number of minor things. - Clarify documentation about sorting requirements. - Add missing histogram support in consistency check. - Add label sorting to consistency check. - Improve error messages when reporting a metric. (Previously, the metric name was not printed.)
2015-06-08 23:12:07 +03:00
label: <
name: "externallabelname"
value: "externalval1"
>
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
counter: <
value: 1
>
>
`)
Fix a number of minor things. - Clarify documentation about sorting requirements. - Add missing histogram support in consistency check. - Add label sorting to consistency check. - Improve error messages when reporting a metric. (Previously, the metric name was not printed.)
2015-06-08 23:12:07 +03:00
externalMetricFamilyAsProtoCompactText := []byte(`name:"externalname" help:"externaldocstring" type:COUNTER metric:<label:<name:"externalconstname" value:"externalconstvalue" > label:<name:"externallabelname" value:"externalval1" > counter:<value:1 > >
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
`)
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
expectedMetricFamily := &dto.MetricFamily{
Name: proto.String("name"),
Help: proto.String("docstring"),
Type: dto.MetricType_COUNTER.Enum(),
Metric: []*dto.Metric{
Optimize fingerprinting and metric locks. These are all simple changes we should have caught a long time ago: 1. The hashing mechanism for fingerprint label sets should have not allocated new objects for the actual hashing---at least not egregiously. This simplifies the hash writing by just byte- dumping the string stream into the hasher. 2. The hashing mechanism within the scope of a metric does not care about the value of the label keys themselves but only of the label values. The keys can be dropped from the calculation. 3. The locking mechanism for the metrics should not block on hash computation but rather solely on the actual mutation or critical section reads. 4. For scalar metrics (i.e., ones with niladic label signatures), we should rely on a preallocated map versus requesting a new one ad hoc. This is tested with Go 1.1, so the results may yield other values for us elsewhere: BEFORE BenchmarkLabelValuesToSignatureScalar 500000000 3.97 ns/op 0 B/op 0 allocs/op BenchmarkLabelValuesToSignatureSingle 5000000 714 ns/op 74 B/op 4 allocs/op BenchmarkLabelValuesToSignatureDouble 1000000 1153 ns/op 107 B/op 5 allocs/op BenchmarkLabelValuesToSignatureTriple 1000000 1588 ns/op 138 B/op 6 allocs/op BenchmarkLabelToSignatureScalar 500000000 3.91 ns/op 0 B/op 0 allocs/op BenchmarkLabelToSignatureSingle 2000000 874 ns/op 92 B/op 5 allocs/op BenchmarkLabelToSignatureDouble 1000000 1528 ns/op 139 B/op 7 allocs/op BenchmarkLabelToSignatureTriple 1000000 2172 ns/op 186 B/op 9 allocs/op AFTER BenchmarkLabelValuesToSignatureScalar 500000000 4.36 ns/op 0 B/op 0 allocs/op BenchmarkLabelValuesToSignatureSingle 5000000 378 ns/op 89 B/op 4 allocs/op BenchmarkLabelValuesToSignatureDouble 5000000 574 ns/op 142 B/op 5 allocs/op BenchmarkLabelValuesToSignatureTriple 5000000 758 ns/op 186 B/op 6 allocs/op BenchmarkLabelToSignatureScalar 500000000 4.06 ns/op 0 B/op 0 allocs/op BenchmarkLabelToSignatureSingle 5000000 472 ns/op 106 B/op 5 allocs/op BenchmarkLabelToSignatureDouble 2000000 746 ns/op 174 B/op 7 allocs/op BenchmarkLabelToSignatureTriple 1000000 1061 ns/op 235 B/op 9 allocs/op In effect, a single metric mutation operation's lookup overhead will move from Before::iBenchmarkLabelToSignature to After::BenchmarkLabelValuesToSignature. This MINIMALLY reduces 1/2 the overhead. I would be hesitant in reading the memory allocation statistics, for this was run with the GC still on and thusly inaccurate per Go benchmarking documentation. Before::BenchmarkLabelValuesToSignature never existed, so it is not of any intrinsic value in itself. That said, the cases that still rely on LabelToSignature experience consistently a 1/2 drop in time. Change-Id: Ifc9e69f718af65a59f5be8117473518233258159
2014-04-14 20:45:16 +04:00
{
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
Label: []*dto.LabelPair{
Optimize fingerprinting and metric locks. These are all simple changes we should have caught a long time ago: 1. The hashing mechanism for fingerprint label sets should have not allocated new objects for the actual hashing---at least not egregiously. This simplifies the hash writing by just byte- dumping the string stream into the hasher. 2. The hashing mechanism within the scope of a metric does not care about the value of the label keys themselves but only of the label values. The keys can be dropped from the calculation. 3. The locking mechanism for the metrics should not block on hash computation but rather solely on the actual mutation or critical section reads. 4. For scalar metrics (i.e., ones with niladic label signatures), we should rely on a preallocated map versus requesting a new one ad hoc. This is tested with Go 1.1, so the results may yield other values for us elsewhere: BEFORE BenchmarkLabelValuesToSignatureScalar 500000000 3.97 ns/op 0 B/op 0 allocs/op BenchmarkLabelValuesToSignatureSingle 5000000 714 ns/op 74 B/op 4 allocs/op BenchmarkLabelValuesToSignatureDouble 1000000 1153 ns/op 107 B/op 5 allocs/op BenchmarkLabelValuesToSignatureTriple 1000000 1588 ns/op 138 B/op 6 allocs/op BenchmarkLabelToSignatureScalar 500000000 3.91 ns/op 0 B/op 0 allocs/op BenchmarkLabelToSignatureSingle 2000000 874 ns/op 92 B/op 5 allocs/op BenchmarkLabelToSignatureDouble 1000000 1528 ns/op 139 B/op 7 allocs/op BenchmarkLabelToSignatureTriple 1000000 2172 ns/op 186 B/op 9 allocs/op AFTER BenchmarkLabelValuesToSignatureScalar 500000000 4.36 ns/op 0 B/op 0 allocs/op BenchmarkLabelValuesToSignatureSingle 5000000 378 ns/op 89 B/op 4 allocs/op BenchmarkLabelValuesToSignatureDouble 5000000 574 ns/op 142 B/op 5 allocs/op BenchmarkLabelValuesToSignatureTriple 5000000 758 ns/op 186 B/op 6 allocs/op BenchmarkLabelToSignatureScalar 500000000 4.06 ns/op 0 B/op 0 allocs/op BenchmarkLabelToSignatureSingle 5000000 472 ns/op 106 B/op 5 allocs/op BenchmarkLabelToSignatureDouble 2000000 746 ns/op 174 B/op 7 allocs/op BenchmarkLabelToSignatureTriple 1000000 1061 ns/op 235 B/op 9 allocs/op In effect, a single metric mutation operation's lookup overhead will move from Before::iBenchmarkLabelToSignature to After::BenchmarkLabelValuesToSignature. This MINIMALLY reduces 1/2 the overhead. I would be hesitant in reading the memory allocation statistics, for this was run with the GC still on and thusly inaccurate per Go benchmarking documentation. Before::BenchmarkLabelValuesToSignature never existed, so it is not of any intrinsic value in itself. That said, the cases that still rely on LabelToSignature experience consistently a 1/2 drop in time. Change-Id: Ifc9e69f718af65a59f5be8117473518233258159
2014-04-14 20:45:16 +04:00
{
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
Name: proto.String("constname"),
Value: proto.String("constvalue"),
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
Optimize fingerprinting and metric locks. These are all simple changes we should have caught a long time ago: 1. The hashing mechanism for fingerprint label sets should have not allocated new objects for the actual hashing---at least not egregiously. This simplifies the hash writing by just byte- dumping the string stream into the hasher. 2. The hashing mechanism within the scope of a metric does not care about the value of the label keys themselves but only of the label values. The keys can be dropped from the calculation. 3. The locking mechanism for the metrics should not block on hash computation but rather solely on the actual mutation or critical section reads. 4. For scalar metrics (i.e., ones with niladic label signatures), we should rely on a preallocated map versus requesting a new one ad hoc. This is tested with Go 1.1, so the results may yield other values for us elsewhere: BEFORE BenchmarkLabelValuesToSignatureScalar 500000000 3.97 ns/op 0 B/op 0 allocs/op BenchmarkLabelValuesToSignatureSingle 5000000 714 ns/op 74 B/op 4 allocs/op BenchmarkLabelValuesToSignatureDouble 1000000 1153 ns/op 107 B/op 5 allocs/op BenchmarkLabelValuesToSignatureTriple 1000000 1588 ns/op 138 B/op 6 allocs/op BenchmarkLabelToSignatureScalar 500000000 3.91 ns/op 0 B/op 0 allocs/op BenchmarkLabelToSignatureSingle 2000000 874 ns/op 92 B/op 5 allocs/op BenchmarkLabelToSignatureDouble 1000000 1528 ns/op 139 B/op 7 allocs/op BenchmarkLabelToSignatureTriple 1000000 2172 ns/op 186 B/op 9 allocs/op AFTER BenchmarkLabelValuesToSignatureScalar 500000000 4.36 ns/op 0 B/op 0 allocs/op BenchmarkLabelValuesToSignatureSingle 5000000 378 ns/op 89 B/op 4 allocs/op BenchmarkLabelValuesToSignatureDouble 5000000 574 ns/op 142 B/op 5 allocs/op BenchmarkLabelValuesToSignatureTriple 5000000 758 ns/op 186 B/op 6 allocs/op BenchmarkLabelToSignatureScalar 500000000 4.06 ns/op 0 B/op 0 allocs/op BenchmarkLabelToSignatureSingle 5000000 472 ns/op 106 B/op 5 allocs/op BenchmarkLabelToSignatureDouble 2000000 746 ns/op 174 B/op 7 allocs/op BenchmarkLabelToSignatureTriple 1000000 1061 ns/op 235 B/op 9 allocs/op In effect, a single metric mutation operation's lookup overhead will move from Before::iBenchmarkLabelToSignature to After::BenchmarkLabelValuesToSignature. This MINIMALLY reduces 1/2 the overhead. I would be hesitant in reading the memory allocation statistics, for this was run with the GC still on and thusly inaccurate per Go benchmarking documentation. Before::BenchmarkLabelValuesToSignature never existed, so it is not of any intrinsic value in itself. That said, the cases that still rely on LabelToSignature experience consistently a 1/2 drop in time. Change-Id: Ifc9e69f718af65a59f5be8117473518233258159
2014-04-14 20:45:16 +04:00
{
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
Name: proto.String("labelname"),
Value: proto.String("val1"),
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
},
Counter: &dto.Counter{
Value: proto.Float64(1),
},
},
Optimize fingerprinting and metric locks. These are all simple changes we should have caught a long time ago: 1. The hashing mechanism for fingerprint label sets should have not allocated new objects for the actual hashing---at least not egregiously. This simplifies the hash writing by just byte- dumping the string stream into the hasher. 2. The hashing mechanism within the scope of a metric does not care about the value of the label keys themselves but only of the label values. The keys can be dropped from the calculation. 3. The locking mechanism for the metrics should not block on hash computation but rather solely on the actual mutation or critical section reads. 4. For scalar metrics (i.e., ones with niladic label signatures), we should rely on a preallocated map versus requesting a new one ad hoc. This is tested with Go 1.1, so the results may yield other values for us elsewhere: BEFORE BenchmarkLabelValuesToSignatureScalar 500000000 3.97 ns/op 0 B/op 0 allocs/op BenchmarkLabelValuesToSignatureSingle 5000000 714 ns/op 74 B/op 4 allocs/op BenchmarkLabelValuesToSignatureDouble 1000000 1153 ns/op 107 B/op 5 allocs/op BenchmarkLabelValuesToSignatureTriple 1000000 1588 ns/op 138 B/op 6 allocs/op BenchmarkLabelToSignatureScalar 500000000 3.91 ns/op 0 B/op 0 allocs/op BenchmarkLabelToSignatureSingle 2000000 874 ns/op 92 B/op 5 allocs/op BenchmarkLabelToSignatureDouble 1000000 1528 ns/op 139 B/op 7 allocs/op BenchmarkLabelToSignatureTriple 1000000 2172 ns/op 186 B/op 9 allocs/op AFTER BenchmarkLabelValuesToSignatureScalar 500000000 4.36 ns/op 0 B/op 0 allocs/op BenchmarkLabelValuesToSignatureSingle 5000000 378 ns/op 89 B/op 4 allocs/op BenchmarkLabelValuesToSignatureDouble 5000000 574 ns/op 142 B/op 5 allocs/op BenchmarkLabelValuesToSignatureTriple 5000000 758 ns/op 186 B/op 6 allocs/op BenchmarkLabelToSignatureScalar 500000000 4.06 ns/op 0 B/op 0 allocs/op BenchmarkLabelToSignatureSingle 5000000 472 ns/op 106 B/op 5 allocs/op BenchmarkLabelToSignatureDouble 2000000 746 ns/op 174 B/op 7 allocs/op BenchmarkLabelToSignatureTriple 1000000 1061 ns/op 235 B/op 9 allocs/op In effect, a single metric mutation operation's lookup overhead will move from Before::iBenchmarkLabelToSignature to After::BenchmarkLabelValuesToSignature. This MINIMALLY reduces 1/2 the overhead. I would be hesitant in reading the memory allocation statistics, for this was run with the GC still on and thusly inaccurate per Go benchmarking documentation. Before::BenchmarkLabelValuesToSignature never existed, so it is not of any intrinsic value in itself. That said, the cases that still rely on LabelToSignature experience consistently a 1/2 drop in time. Change-Id: Ifc9e69f718af65a59f5be8117473518233258159
2014-04-14 20:45:16 +04:00
{
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
Label: []*dto.LabelPair{
Optimize fingerprinting and metric locks. These are all simple changes we should have caught a long time ago: 1. The hashing mechanism for fingerprint label sets should have not allocated new objects for the actual hashing---at least not egregiously. This simplifies the hash writing by just byte- dumping the string stream into the hasher. 2. The hashing mechanism within the scope of a metric does not care about the value of the label keys themselves but only of the label values. The keys can be dropped from the calculation. 3. The locking mechanism for the metrics should not block on hash computation but rather solely on the actual mutation or critical section reads. 4. For scalar metrics (i.e., ones with niladic label signatures), we should rely on a preallocated map versus requesting a new one ad hoc. This is tested with Go 1.1, so the results may yield other values for us elsewhere: BEFORE BenchmarkLabelValuesToSignatureScalar 500000000 3.97 ns/op 0 B/op 0 allocs/op BenchmarkLabelValuesToSignatureSingle 5000000 714 ns/op 74 B/op 4 allocs/op BenchmarkLabelValuesToSignatureDouble 1000000 1153 ns/op 107 B/op 5 allocs/op BenchmarkLabelValuesToSignatureTriple 1000000 1588 ns/op 138 B/op 6 allocs/op BenchmarkLabelToSignatureScalar 500000000 3.91 ns/op 0 B/op 0 allocs/op BenchmarkLabelToSignatureSingle 2000000 874 ns/op 92 B/op 5 allocs/op BenchmarkLabelToSignatureDouble 1000000 1528 ns/op 139 B/op 7 allocs/op BenchmarkLabelToSignatureTriple 1000000 2172 ns/op 186 B/op 9 allocs/op AFTER BenchmarkLabelValuesToSignatureScalar 500000000 4.36 ns/op 0 B/op 0 allocs/op BenchmarkLabelValuesToSignatureSingle 5000000 378 ns/op 89 B/op 4 allocs/op BenchmarkLabelValuesToSignatureDouble 5000000 574 ns/op 142 B/op 5 allocs/op BenchmarkLabelValuesToSignatureTriple 5000000 758 ns/op 186 B/op 6 allocs/op BenchmarkLabelToSignatureScalar 500000000 4.06 ns/op 0 B/op 0 allocs/op BenchmarkLabelToSignatureSingle 5000000 472 ns/op 106 B/op 5 allocs/op BenchmarkLabelToSignatureDouble 2000000 746 ns/op 174 B/op 7 allocs/op BenchmarkLabelToSignatureTriple 1000000 1061 ns/op 235 B/op 9 allocs/op In effect, a single metric mutation operation's lookup overhead will move from Before::iBenchmarkLabelToSignature to After::BenchmarkLabelValuesToSignature. This MINIMALLY reduces 1/2 the overhead. I would be hesitant in reading the memory allocation statistics, for this was run with the GC still on and thusly inaccurate per Go benchmarking documentation. Before::BenchmarkLabelValuesToSignature never existed, so it is not of any intrinsic value in itself. That said, the cases that still rely on LabelToSignature experience consistently a 1/2 drop in time. Change-Id: Ifc9e69f718af65a59f5be8117473518233258159
2014-04-14 20:45:16 +04:00
{
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
Name: proto.String("constname"),
Value: proto.String("constvalue"),
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
Optimize fingerprinting and metric locks. These are all simple changes we should have caught a long time ago: 1. The hashing mechanism for fingerprint label sets should have not allocated new objects for the actual hashing---at least not egregiously. This simplifies the hash writing by just byte- dumping the string stream into the hasher. 2. The hashing mechanism within the scope of a metric does not care about the value of the label keys themselves but only of the label values. The keys can be dropped from the calculation. 3. The locking mechanism for the metrics should not block on hash computation but rather solely on the actual mutation or critical section reads. 4. For scalar metrics (i.e., ones with niladic label signatures), we should rely on a preallocated map versus requesting a new one ad hoc. This is tested with Go 1.1, so the results may yield other values for us elsewhere: BEFORE BenchmarkLabelValuesToSignatureScalar 500000000 3.97 ns/op 0 B/op 0 allocs/op BenchmarkLabelValuesToSignatureSingle 5000000 714 ns/op 74 B/op 4 allocs/op BenchmarkLabelValuesToSignatureDouble 1000000 1153 ns/op 107 B/op 5 allocs/op BenchmarkLabelValuesToSignatureTriple 1000000 1588 ns/op 138 B/op 6 allocs/op BenchmarkLabelToSignatureScalar 500000000 3.91 ns/op 0 B/op 0 allocs/op BenchmarkLabelToSignatureSingle 2000000 874 ns/op 92 B/op 5 allocs/op BenchmarkLabelToSignatureDouble 1000000 1528 ns/op 139 B/op 7 allocs/op BenchmarkLabelToSignatureTriple 1000000 2172 ns/op 186 B/op 9 allocs/op AFTER BenchmarkLabelValuesToSignatureScalar 500000000 4.36 ns/op 0 B/op 0 allocs/op BenchmarkLabelValuesToSignatureSingle 5000000 378 ns/op 89 B/op 4 allocs/op BenchmarkLabelValuesToSignatureDouble 5000000 574 ns/op 142 B/op 5 allocs/op BenchmarkLabelValuesToSignatureTriple 5000000 758 ns/op 186 B/op 6 allocs/op BenchmarkLabelToSignatureScalar 500000000 4.06 ns/op 0 B/op 0 allocs/op BenchmarkLabelToSignatureSingle 5000000 472 ns/op 106 B/op 5 allocs/op BenchmarkLabelToSignatureDouble 2000000 746 ns/op 174 B/op 7 allocs/op BenchmarkLabelToSignatureTriple 1000000 1061 ns/op 235 B/op 9 allocs/op In effect, a single metric mutation operation's lookup overhead will move from Before::iBenchmarkLabelToSignature to After::BenchmarkLabelValuesToSignature. This MINIMALLY reduces 1/2 the overhead. I would be hesitant in reading the memory allocation statistics, for this was run with the GC still on and thusly inaccurate per Go benchmarking documentation. Before::BenchmarkLabelValuesToSignature never existed, so it is not of any intrinsic value in itself. That said, the cases that still rely on LabelToSignature experience consistently a 1/2 drop in time. Change-Id: Ifc9e69f718af65a59f5be8117473518233258159
2014-04-14 20:45:16 +04:00
{
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
Name: proto.String("labelname"),
Value: proto.String("val2"),
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
},
Counter: &dto.Counter{
Value: proto.Float64(1),
},
},
},
}
Create a public registry interface and separate out HTTP exposition General context and approch =========================== This is the first part of the long awaited wider refurbishment of `client_golang/prometheus/...`. After a lot of struggling, I decided to not go for one breaking big-bang, but cut things into smaller steps after all, mostly to keep the changes manageable and easy to review. I'm aiming for having the invasive breaking changes concentrated in as few steps as possible (ideally one). Some steps will not be breaking at all, but typically there will be breaking changes that only affect quite special cases so that 95+% of users will not be affected. This first step is an example for that, see details below. What's happening in this commit? ================================ This step is about finally creating an exported registry interface. This could not be done by simply export the existing internal implementation because the interface would be _way_ too fat. This commit introduces a qutie lean `Registry` interface (compared to the previous interval implementation). The functions that act on the default registry are retained (with very few exceptions) so that most use cases won't see a change. However, several of those are deprecated now to clean up the namespace in the future. The default registry is kept in the public variable `DefaultRegistry`. This follows the example of the http package in the standard library (cf. `http.DefaultServeMux`, `http.DefaultClient`) with the same implications. (This pattern is somewhat disputed within the Go community but I chose to go with the devil you know instead of creating something more complex or even disallowing any changes to the default registry. The current approach gives everybody the freedom to not touch DefaultRegistry or to do everything with a custom registry to play save.) Another important part in making the registry lean is the extraction of the HTTP exposition, which also allows for customization of the HTTP exposition. Note that the separation of metric collection and exposition has the side effect that managing the MetricFamily and Metric protobuf objects in a free-list or pool isn't really feasible anymore. By now (with better GC in more recent Go versions), the returns were anyway dimisishing. To be effective at all, scrapes had to happen more often than GC cycles, and even then most elements of the protobufs (everything excetp the MetricFamily and Metric structs themselves) would still cause allocation churn. In a future breaking change, the signature of the Write method in the Metric interface will be adjusted accordingly. In this commit, avoiding breakage is more important. The following issues are fixed by this commit (some solved "on the fly" now that I was touching the code anyway and it would have been stupid to port the bugs): https://github.com/prometheus/client_golang/issues/46 https://github.com/prometheus/client_golang/issues/100 https://github.com/prometheus/client_golang/issues/170 https://github.com/prometheus/client_golang/issues/205 Documentation including examples have been amended as required. What future changes does this commit enable? ============================================ The following items are not yet implemented, but this commit opens the possibility of implementing these independently. - The separation of the HTTP exposition allows the implementation of other exposition methods based on the Registry interface, as known from other Prometheus client libraries, e.g. sending the metrics to Graphite. Cf. https://github.com/prometheus/client_golang/issues/197 - The public `Registry` interface allows the implementation of convenience tools for testing metrics collection. Those tools can inspect the collected MetricFamily protobufs and compare them to expectation. Also, tests can use their own testing instance of a registry. Cf. https://github.com/prometheus/client_golang/issues/58 Notable non-goals of this commit ================================ Non-goals that will be tackled later ------------------------------------ The following two issues are quite closely connected to the changes in this commit but the line has been drawn deliberately to address them in later steps of the refurbishment: - `InstrumentHandler` has many known problems. The plan is to create a saner way to conveniently intrument HTTP handlers and remove the old `InstrumentHandler` altogether. To keep breakage low for now, even the default handler to expose metrics is still using the old `InstrumentHandler`. This leads to weird naming inconsistencies but I have deemed it better to not break the world right now but do it in the change that provides better ways of instrumenting HTTP handlers. Cf. https://github.com/prometheus/client_golang/issues/200 - There is work underway to make the whole handling of metric descriptors (`Desc`) more intuitive and transparent for the user (including an ability for less strict checking, cf. https://github.com/prometheus/client_golang/issues/47). That's quite invasive from the perspective of the internal code, namely the registry. I deliberately kept those changes out of this commit. - While this commit adds new external dependency, the effort to vendor anything within the library that is not visible in any exported types will have to be done later. Non-goals that _might_ be tackled later --------------------------------------- There is a strong and understandable urge to divide the `prometheus` package into a number of sub-packages (like `registry`, `collectors`, `http`, `metrics`, …). However, to not run into a multitude of circular import chains, this would need to break every single existing usage of the library. (As just one example, if the ubiquitious `prometheus.MustRegister` (with more than 2,000 uses on GitHub alone) is kept in the `prometheus` package, but the other registry concerns go into a new `registry` package, then the `prometheus` package would import the `registry` package (to call the actual register method), while at the same time the `registry` package needs to import the `prometheus` package to access `Collector`, `Metric`, `Desc` and more. If we moved `MustRegister` into the `registry` package, thousands of code lines would have to be fixed (which would be easy if the world was a mono repo, but it is not). If we moved everything else the proposed registry package needs into packages of their own, we would break thousands of other code lines.) The main problem is really the top-level functions like `MustRegister`, `Handler`, …, which effectively pull everything into one package. Those functions are however very convenient for the easy and very frequent use-cases. This problem has to be revisited later. For now, I'm trying to keep the amount of exported names in the package as low as possible (e.g. I unexported expvarCollector in this commit because the NewExpvarCollector constructor is enough to export, and it is now consistent with other collectors, like the goCollector). Non-goals that won't be tackled anytime soon -------------------------------------------- Something that I have played with a lot is "streaming collection", i.e. allow an implementation of the `Registry` interface that collects metrics incrementally and serves them while doing so. As it has turned out, this has many many issues and makes the `Registry` interface very clunky. Eventually, I made the call that it is unlikely we will really implement streaming collection; and making the interface more clunky for something that might not even happen is really a big no-no. Note that the `Registry` interface only creates the in-memory representation of the metric family protobufs in one go. The serializaton onto the wire can still be handled in a streaming fashion (which hasn't been done so far, without causing any trouble, but might be done in the future without breaking any interfaces). What are the breaking changes? ============================== - Signatures of functions pushing to Pushgateway have changed to allow arbitrary grouping (which was planned for a long time anyway, and now that I had to work on the Push code anyway for the registry refurbishment, I finally did it, cf. https://github.com/prometheus/client_golang/issues/100). With the gained insight that pushing to the default registry is almost never the right thing, and now that we are breaking the Push call anyway, all the Push functions were moved to their own package, which cleans up the namespace and is more idiomatic (pushing Collectors is now literally done by `push.Collectors(...)`). - The registry is doing more consistency checks by default now. Past creators of inconsistent metrics could have masked the problem by not setting `EnableCollectChecks`. Those inconsistencies will now be detected. (But note that a "best effort" metrics collection is now possible with `HandlerOpts.ErrorHandling = ContinueOnError`.) - `EnableCollectChecks` is gone. The registry is now performing some of those checks anyway (see previous item), and a registry with all of those checks can now be created with `NewPedanticRegistry` (only used for testing). - `PanicOnCollectError` is gone. This behavior can now be configured when creating a custom HTTP handler.
2016-07-20 18:11:14 +03:00
buf := &bytes.Buffer{}
enc = expfmt.NewEncoder(buf, expfmt.FmtProtoDelim)
if err := enc.Encode(expectedMetricFamily); err != nil {
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
t.Fatal(err)
}
expectedMetricFamilyAsBytes := buf.Bytes()
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
expectedMetricFamilyAsText := []byte(`# HELP name docstring
# TYPE name counter
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
name{constname="constvalue",labelname="val1"} 1
name{constname="constvalue",labelname="val2"} 1
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
`)
expectedMetricFamilyAsProtoText := []byte(`name: "name"
help: "docstring"
type: COUNTER
metric: <
label: <
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
name: "constname"
value: "constvalue"
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
>
label: <
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
name: "labelname"
value: "val1"
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
>
counter: <
value: 1
>
>
metric: <
label: <
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
name: "constname"
value: "constvalue"
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
>
label: <
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
name: "labelname"
value: "val2"
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
>
counter: <
value: 1
>
>
`)
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
expectedMetricFamilyAsProtoCompactText := []byte(`name:"name" help:"docstring" type:COUNTER metric:<label:<name:"constname" value:"constvalue" > label:<name:"labelname" value:"val1" > counter:<value:1 > > metric:<label:<name:"constname" value:"constvalue" > label:<name:"labelname" value:"val2" > counter:<value:1 > >
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
`)
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
Allow the metric family injection hook to merge with existing metric families. If a metric family returned by the injection hook already exists (with the same name), then its metrics are simply merged into that metric family. With enabled collect-time checks, even uniqueness is checked, but in general, things stay the same that the caller is responsible to ensure metric consistency. This fixes https://github.com/prometheus/pushgateway/issues/27 .
2015-03-15 17:47:56 +03:00
externalMetricFamilyWithSameName := &dto.MetricFamily{
Name: proto.String("name"),
Create a "merge gatherer" This allows to finally get rid of the infamous injection hook in the interface. The old SetMetricFamilyInjectionHook still exist as a deprecated function but is now implemented with the new plumbing under the hood. Now that we have multiple Gatherer implementation, I renamed push.Registry to push.FromGatherer. This commit also improves the consistency checks, which happened as a byproduct of the refactoring to allow checking in both the "merge gatherer" Gatherers as well as in the normal Registry.
2016-08-05 15:57:49 +03:00
Help: proto.String("docstring"),
Allow the metric family injection hook to merge with existing metric families. If a metric family returned by the injection hook already exists (with the same name), then its metrics are simply merged into that metric family. With enabled collect-time checks, even uniqueness is checked, but in general, things stay the same that the caller is responsible to ensure metric consistency. This fixes https://github.com/prometheus/pushgateway/issues/27 .
2015-03-15 17:47:56 +03:00
Type: dto.MetricType_COUNTER.Enum(),
Metric: []*dto.Metric{
{
Label: []*dto.LabelPair{
{
Name: proto.String("constname"),
Value: proto.String("constvalue"),
},
{
Name: proto.String("labelname"),
Value: proto.String("different_val"),
},
},
Counter: &dto.Counter{
Value: proto.Float64(42),
},
},
},
}
expectedMetricFamilyMergedWithExternalAsProtoCompactText := []byte(`name:"name" help:"docstring" type:COUNTER metric:<label:<name:"constname" value:"constvalue" > label:<name:"labelname" value:"different_val" > counter:<value:42 > > metric:<label:<name:"constname" value:"constvalue" > label:<name:"labelname" value:"val1" > counter:<value:1 > > metric:<label:<name:"constname" value:"constvalue" > label:<name:"labelname" value:"val2" > counter:<value:1 > >
`)
fail Gather'ing when label value is not utf8
2017-08-20 01:07:21 +03:00
externalMetricFamilyWithInvalidLabelValue := &dto.MetricFamily{
Name: proto.String("name"),
Help: proto.String("docstring"),
Type: dto.MetricType_COUNTER.Enum(),
Metric: []*dto.Metric{
{
Label: []*dto.LabelPair{
{
Name: proto.String("constname"),
Value: proto.String("\xFF"),
},
{
Name: proto.String("labelname"),
Value: proto.String("different_val"),
},
},
Counter: &dto.Counter{
Value: proto.Float64(42),
},
},
},
}
Use streaming encoding of metrics Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-10-20 02:28:16 +03:00
expectedMetricFamilyInvalidLabelValueAsText := []byte(`An error has occurred while serving metrics:
fail Gather'ing when label value is not utf8
2017-08-20 01:07:21 +03:00
Add more label checksn during gathering Including check for an invalid "quantile" label in summaries. Also, improve error messages. Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-07-13 15:14:39 +03:00
collected metric "name" { label:<name:"constname" value:"\377" > label:<name:"labelname" value:"different_val" > counter:<value:42 > } has a label named "constname" whose value is not utf8: "\xff"
Add suffix collision checks during gathering 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>
2018-07-13 17:29:17 +03:00
`)
summary := prometheus.NewSummary(prometheus.SummaryOpts{
Name: "complex",
Help: "A metric to check collisions with _sum and _count.",
})
summaryAsText := []byte(`# HELP complex A metric to check collisions with _sum and _count.
# TYPE complex summary
complex{quantile="0.5"} NaN
complex{quantile="0.9"} NaN
complex{quantile="0.99"} NaN
complex_sum 0
complex_count 0
`)
histogram := prometheus.NewHistogram(prometheus.HistogramOpts{
Name: "complex",
Help: "A metric to check collisions with _sun, _count, and _bucket.",
})
externalMetricFamilyWithBucketSuffix := &dto.MetricFamily{
Name: proto.String("complex_bucket"),
Help: proto.String("externaldocstring"),
Type: dto.MetricType_COUNTER.Enum(),
Metric: []*dto.Metric{
{
Counter: &dto.Counter{
Value: proto.Float64(1),
},
},
},
}
externalMetricFamilyWithBucketSuffixAsText := []byte(`# HELP complex_bucket externaldocstring
# TYPE complex_bucket counter
complex_bucket 1
`)
externalMetricFamilyWithCountSuffix := &dto.MetricFamily{
Name: proto.String("complex_count"),
Help: proto.String("externaldocstring"),
Type: dto.MetricType_COUNTER.Enum(),
Metric: []*dto.Metric{
{
Counter: &dto.Counter{
Value: proto.Float64(1),
},
},
},
}
Use streaming encoding of metrics Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-10-20 02:28:16 +03:00
bucketCollisionMsg := []byte(`An error has occurred while serving metrics:
Add suffix collision checks during gathering 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>
2018-07-13 17:29:17 +03:00
collected metric named "complex_bucket" collides with previously collected histogram named "complex"
`)
Use streaming encoding of metrics Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-10-20 02:28:16 +03:00
summaryCountCollisionMsg := []byte(`An error has occurred while serving metrics:
Add suffix collision checks during gathering 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>
2018-07-13 17:29:17 +03:00
collected metric named "complex_count" collides with previously collected summary named "complex"
`)
Use streaming encoding of metrics Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-10-20 02:28:16 +03:00
histogramCountCollisionMsg := []byte(`An error has occurred while serving metrics:
Add suffix collision checks during gathering 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>
2018-07-13 17:29:17 +03:00
collected metric named "complex_count" collides with previously collected histogram named "complex"
fail Gather'ing when label value is not utf8
2017-08-20 01:07:21 +03:00
`)
Expose failure to detect duplicate label names This is #471. Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-09-30 11:38:57 +03:00
externalMetricFamilyWithDuplicateLabel := &dto.MetricFamily{
Name: proto.String("broken_metric"),
Help: proto.String("The registry should detect the duplicate label."),
Type: dto.MetricType_COUNTER.Enum(),
Metric: []*dto.Metric{
{
Label: []*dto.LabelPair{
{
Name: proto.String("foo"),
Value: proto.String("bar"),
},
{
Name: proto.String("foo"),
Value: proto.String("baz"),
},
},
Counter: &dto.Counter{
Value: proto.Float64(2.7),
},
},
},
}
Use streaming encoding of metrics Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-10-20 02:28:16 +03:00
duplicateLabelMsg := []byte(`An error has occurred while serving metrics:
Add check for duplicated label names Fixes #471 Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-09-30 16:37:40 +03:00
collected metric "broken_metric" { label:<name:"foo" value:"bar" > label:<name:"foo" value:"baz" > counter:<value:2.7 > } has two or more labels with the same name: foo
`)
fail Gather'ing when label value is not utf8
2017-08-20 01:07:21 +03:00
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
type output struct {
headers map[string]string
body []byte
}
var scenarios = []struct {
Allow the metric family injection hook to merge with existing metric families. If a metric family returned by the injection hook already exists (with the same name), then its metrics are simply merged into that metric family. With enabled collect-time checks, even uniqueness is checked, but in general, things stay the same that the caller is responsible to ensure metric consistency. This fixes https://github.com/prometheus/pushgateway/issues/27 .
2015-03-15 17:47:56 +03:00
headers map[string]string
out output
Move http stuff in its own package promhttp To keep backwards compatibility while not creating circular import chains, some code had to be duplicated. But all functions using it have been declared deprecated hereby. The new ways of instrumenting handlers will all go into the new package, and ultimately, the prometheus package itself will be completely igorant of HTTP.
2016-08-03 15:57:02 +03:00
collector prometheus.Collector
Allow the metric family injection hook to merge with existing metric families. If a metric family returned by the injection hook already exists (with the same name), then its metrics are simply merged into that metric family. With enabled collect-time checks, even uniqueness is checked, but in general, things stay the same that the caller is responsible to ensure metric consistency. This fixes https://github.com/prometheus/pushgateway/issues/27 .
2015-03-15 17:47:56 +03:00
externalMF []*dto.MetricFamily
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
}{
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
{ // 0
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
headers: map[string]string{
"Accept": "foo/bar;q=0.2, dings/bums;q=0.8",
},
out: output{
headers: map[string]string{
Fix TestHandler prometheus/common has changed and now adds the charset to the Content-Type header.
2018-03-19 16:04:12 +03:00
"Content-Type": `text/plain; version=0.0.4; charset=utf-8`,
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
body: []byte{},
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
},
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
{ // 1
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
headers: map[string]string{
"Accept": "foo/bar;q=0.2, application/quark;q=0.8",
},
out: output{
headers: map[string]string{
Fix TestHandler prometheus/common has changed and now adds the charset to the Content-Type header.
2018-03-19 16:04:12 +03:00
"Content-Type": `text/plain; version=0.0.4; charset=utf-8`,
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
body: []byte{},
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
},
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
{ // 2
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
headers: map[string]string{
"Accept": "foo/bar;q=0.2, application/vnd.google.protobuf;proto=io.prometheus.client.MetricFamily;encoding=bla;q=0.8",
},
out: output{
headers: map[string]string{
Fix TestHandler prometheus/common has changed and now adds the charset to the Content-Type header.
2018-03-19 16:04:12 +03:00
"Content-Type": `text/plain; version=0.0.4; charset=utf-8`,
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
body: []byte{},
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
},
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
{ // 3
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
headers: map[string]string{
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
"Accept": "text/plain;q=0.2, application/vnd.google.protobuf;proto=io.prometheus.client.MetricFamily;encoding=delimited;q=0.8",
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
out: output{
headers: map[string]string{
Add a configurable version of InstrumentHandler and InstrumentHandlerFunc. Also, remove quotes from the Content-type header. It's not illegal to have quotes there, but they are not needed, and at other places, we are not using them. So fewer characters and more consistency. Change-Id: If7a78bde85154163e4426daec493d973213e83e9
2014-07-15 17:34:52 +04:00
"Content-Type": `application/vnd.google.protobuf; proto=io.prometheus.client.MetricFamily; encoding=delimited`,
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
body: []byte{},
},
},
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
{ // 4
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
headers: map[string]string{
"Accept": "application/json",
},
out: output{
headers: map[string]string{
Fix TestHandler prometheus/common has changed and now adds the charset to the Content-Type header.
2018-03-19 16:04:12 +03:00
"Content-Type": `text/plain; version=0.0.4; charset=utf-8`,
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
body: expectedMetricFamilyAsText,
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
Allow the metric family injection hook to merge with existing metric families. If a metric family returned by the injection hook already exists (with the same name), then its metrics are simply merged into that metric family. With enabled collect-time checks, even uniqueness is checked, but in general, things stay the same that the caller is responsible to ensure metric consistency. This fixes https://github.com/prometheus/pushgateway/issues/27 .
2015-03-15 17:47:56 +03:00
collector: metricVec,
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
{ // 5
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
headers: map[string]string{
"Accept": "application/vnd.google.protobuf;proto=io.prometheus.client.MetricFamily;encoding=delimited",
},
out: output{
headers: map[string]string{
Add a configurable version of InstrumentHandler and InstrumentHandlerFunc. Also, remove quotes from the Content-type header. It's not illegal to have quotes there, but they are not needed, and at other places, we are not using them. So fewer characters and more consistency. Change-Id: If7a78bde85154163e4426daec493d973213e83e9
2014-07-15 17:34:52 +04:00
"Content-Type": `application/vnd.google.protobuf; proto=io.prometheus.client.MetricFamily; encoding=delimited`,
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
body: expectedMetricFamilyAsBytes,
},
Allow the metric family injection hook to merge with existing metric families. If a metric family returned by the injection hook already exists (with the same name), then its metrics are simply merged into that metric family. With enabled collect-time checks, even uniqueness is checked, but in general, things stay the same that the caller is responsible to ensure metric consistency. This fixes https://github.com/prometheus/pushgateway/issues/27 .
2015-03-15 17:47:56 +03:00
collector: metricVec,
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
{ // 6
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
headers: map[string]string{
"Accept": "application/json",
},
out: output{
headers: map[string]string{
Fix TestHandler prometheus/common has changed and now adds the charset to the Content-Type header.
2018-03-19 16:04:12 +03:00
"Content-Type": `text/plain; version=0.0.4; charset=utf-8`,
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
body: externalMetricFamilyAsText,
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
Allow the metric family injection hook to merge with existing metric families. If a metric family returned by the injection hook already exists (with the same name), then its metrics are simply merged into that metric family. With enabled collect-time checks, even uniqueness is checked, but in general, things stay the same that the caller is responsible to ensure metric consistency. This fixes https://github.com/prometheus/pushgateway/issues/27 .
2015-03-15 17:47:56 +03:00
externalMF: []*dto.MetricFamily{externalMetricFamily},
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
{ // 7
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
headers: map[string]string{
"Accept": "application/vnd.google.protobuf;proto=io.prometheus.client.MetricFamily;encoding=delimited",
},
out: output{
headers: map[string]string{
Add a configurable version of InstrumentHandler and InstrumentHandlerFunc. Also, remove quotes from the Content-type header. It's not illegal to have quotes there, but they are not needed, and at other places, we are not using them. So fewer characters and more consistency. Change-Id: If7a78bde85154163e4426daec493d973213e83e9
2014-07-15 17:34:52 +04:00
"Content-Type": `application/vnd.google.protobuf; proto=io.prometheus.client.MetricFamily; encoding=delimited`,
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
body: externalMetricFamilyAsBytes,
},
Allow the metric family injection hook to merge with existing metric families. If a metric family returned by the injection hook already exists (with the same name), then its metrics are simply merged into that metric family. With enabled collect-time checks, even uniqueness is checked, but in general, things stay the same that the caller is responsible to ensure metric consistency. This fixes https://github.com/prometheus/pushgateway/issues/27 .
2015-03-15 17:47:56 +03:00
externalMF: []*dto.MetricFamily{externalMetricFamily},
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
{ // 8
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
headers: map[string]string{
"Accept": "application/vnd.google.protobuf;proto=io.prometheus.client.MetricFamily;encoding=delimited",
},
out: output{
headers: map[string]string{
Add a configurable version of InstrumentHandler and InstrumentHandlerFunc. Also, remove quotes from the Content-type header. It's not illegal to have quotes there, but they are not needed, and at other places, we are not using them. So fewer characters and more consistency. Change-Id: If7a78bde85154163e4426daec493d973213e83e9
2014-07-15 17:34:52 +04:00
"Content-Type": `application/vnd.google.protobuf; proto=io.prometheus.client.MetricFamily; encoding=delimited`,
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
body: bytes.Join(
[][]byte{
externalMetricFamilyAsBytes,
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
expectedMetricFamilyAsBytes,
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
[]byte{},
),
},
Allow the metric family injection hook to merge with existing metric families. If a metric family returned by the injection hook already exists (with the same name), then its metrics are simply merged into that metric family. With enabled collect-time checks, even uniqueness is checked, but in general, things stay the same that the caller is responsible to ensure metric consistency. This fixes https://github.com/prometheus/pushgateway/issues/27 .
2015-03-15 17:47:56 +03:00
collector: metricVec,
externalMF: []*dto.MetricFamily{externalMetricFamily},
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
},
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
{ // 9
headers: map[string]string{
"Accept": "text/plain",
},
out: output{
headers: map[string]string{
Fix TestHandler prometheus/common has changed and now adds the charset to the Content-Type header.
2018-03-19 16:04:12 +03:00
"Content-Type": `text/plain; version=0.0.4; charset=utf-8`,
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
},
body: []byte{},
},
},
{ // 10
headers: map[string]string{
"Accept": "application/vnd.google.protobuf;proto=io.prometheus.client.MetricFamily;encoding=bla;q=0.2, text/plain;q=0.5",
},
out: output{
headers: map[string]string{
Fix TestHandler prometheus/common has changed and now adds the charset to the Content-Type header.
2018-03-19 16:04:12 +03:00
"Content-Type": `text/plain; version=0.0.4; charset=utf-8`,
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
},
body: expectedMetricFamilyAsText,
},
Allow the metric family injection hook to merge with existing metric families. If a metric family returned by the injection hook already exists (with the same name), then its metrics are simply merged into that metric family. With enabled collect-time checks, even uniqueness is checked, but in general, things stay the same that the caller is responsible to ensure metric consistency. This fixes https://github.com/prometheus/pushgateway/issues/27 .
2015-03-15 17:47:56 +03:00
collector: metricVec,
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
},
{ // 11
headers: map[string]string{
"Accept": "application/vnd.google.protobuf;proto=io.prometheus.client.MetricFamily;encoding=bla;q=0.2, text/plain;q=0.5;version=0.0.4",
},
out: output{
headers: map[string]string{
Fix TestHandler prometheus/common has changed and now adds the charset to the Content-Type header.
2018-03-19 16:04:12 +03:00
"Content-Type": `text/plain; version=0.0.4; charset=utf-8`,
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
},
body: bytes.Join(
[][]byte{
externalMetricFamilyAsText,
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
expectedMetricFamilyAsText,
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
},
[]byte{},
),
},
Allow the metric family injection hook to merge with existing metric families. If a metric family returned by the injection hook already exists (with the same name), then its metrics are simply merged into that metric family. With enabled collect-time checks, even uniqueness is checked, but in general, things stay the same that the caller is responsible to ensure metric consistency. This fixes https://github.com/prometheus/pushgateway/issues/27 .
2015-03-15 17:47:56 +03:00
collector: metricVec,
externalMF: []*dto.MetricFamily{externalMetricFamily},
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
},
{ // 12
headers: map[string]string{
"Accept": "application/vnd.google.protobuf;proto=io.prometheus.client.MetricFamily;encoding=delimited;q=0.2, text/plain;q=0.5;version=0.0.2",
},
out: output{
headers: map[string]string{
Add a configurable version of InstrumentHandler and InstrumentHandlerFunc. Also, remove quotes from the Content-type header. It's not illegal to have quotes there, but they are not needed, and at other places, we are not using them. So fewer characters and more consistency. Change-Id: If7a78bde85154163e4426daec493d973213e83e9
2014-07-15 17:34:52 +04:00
"Content-Type": `application/vnd.google.protobuf; proto=io.prometheus.client.MetricFamily; encoding=delimited`,
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
},
body: bytes.Join(
[][]byte{
externalMetricFamilyAsBytes,
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
expectedMetricFamilyAsBytes,
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
},
[]byte{},
),
},
Allow the metric family injection hook to merge with existing metric families. If a metric family returned by the injection hook already exists (with the same name), then its metrics are simply merged into that metric family. With enabled collect-time checks, even uniqueness is checked, but in general, things stay the same that the caller is responsible to ensure metric consistency. This fixes https://github.com/prometheus/pushgateway/issues/27 .
2015-03-15 17:47:56 +03:00
collector: metricVec,
externalMF: []*dto.MetricFamily{externalMetricFamily},
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
},
{ // 13
headers: map[string]string{
"Accept": "application/vnd.google.protobuf;proto=io.prometheus.client.MetricFamily;encoding=text;q=0.5, application/vnd.google.protobuf;proto=io.prometheus.client.MetricFamily;encoding=delimited;q=0.4",
},
out: output{
headers: map[string]string{
Add a configurable version of InstrumentHandler and InstrumentHandlerFunc. Also, remove quotes from the Content-type header. It's not illegal to have quotes there, but they are not needed, and at other places, we are not using them. So fewer characters and more consistency. Change-Id: If7a78bde85154163e4426daec493d973213e83e9
2014-07-15 17:34:52 +04:00
"Content-Type": `application/vnd.google.protobuf; proto=io.prometheus.client.MetricFamily; encoding=text`,
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
},
body: bytes.Join(
[][]byte{
externalMetricFamilyAsProtoText,
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
expectedMetricFamilyAsProtoText,
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
},
[]byte{},
),
},
Allow the metric family injection hook to merge with existing metric families. If a metric family returned by the injection hook already exists (with the same name), then its metrics are simply merged into that metric family. With enabled collect-time checks, even uniqueness is checked, but in general, things stay the same that the caller is responsible to ensure metric consistency. This fixes https://github.com/prometheus/pushgateway/issues/27 .
2015-03-15 17:47:56 +03:00
collector: metricVec,
externalMF: []*dto.MetricFamily{externalMetricFamily},
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
},
{ // 14
headers: map[string]string{
"Accept": "application/vnd.google.protobuf;proto=io.prometheus.client.MetricFamily;encoding=compact-text",
},
out: output{
headers: map[string]string{
Add a configurable version of InstrumentHandler and InstrumentHandlerFunc. Also, remove quotes from the Content-type header. It's not illegal to have quotes there, but they are not needed, and at other places, we are not using them. So fewer characters and more consistency. Change-Id: If7a78bde85154163e4426daec493d973213e83e9
2014-07-15 17:34:52 +04:00
"Content-Type": `application/vnd.google.protobuf; proto=io.prometheus.client.MetricFamily; encoding=compact-text`,
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
},
body: bytes.Join(
[][]byte{
externalMetricFamilyAsProtoCompactText,
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
expectedMetricFamilyAsProtoCompactText,
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
},
[]byte{},
),
},
Allow the metric family injection hook to merge with existing metric families. If a metric family returned by the injection hook already exists (with the same name), then its metrics are simply merged into that metric family. With enabled collect-time checks, even uniqueness is checked, but in general, things stay the same that the caller is responsible to ensure metric consistency. This fixes https://github.com/prometheus/pushgateway/issues/27 .
2015-03-15 17:47:56 +03:00
collector: metricVec,
externalMF: []*dto.MetricFamily{externalMetricFamily},
},
{ // 15
headers: map[string]string{
"Accept": "application/vnd.google.protobuf;proto=io.prometheus.client.MetricFamily;encoding=compact-text",
},
out: output{
headers: map[string]string{
"Content-Type": `application/vnd.google.protobuf; proto=io.prometheus.client.MetricFamily; encoding=compact-text`,
},
body: bytes.Join(
[][]byte{
externalMetricFamilyAsProtoCompactText,
expectedMetricFamilyMergedWithExternalAsProtoCompactText,
},
[]byte{},
),
},
collector: metricVec,
externalMF: []*dto.MetricFamily{
externalMetricFamily,
externalMetricFamilyWithSameName,
},
Enable the Golang client library to create the new text formats. Most important here is the simple & flat text format, but while I'm on it, I have also added the text representations for protobufs (which is purely meant for debugging purposes). I hope my basic idea about handling those various protocols (and the text package) becomes clearer now. Change-Id: I7299853eadc82a426101e907f2b3d4e37f9e4c71
2014-04-23 15:40:37 +04:00
},
fail Gather'ing when label value is not utf8
2017-08-20 01:07:21 +03:00
{ // 16
headers: map[string]string{
"Accept": "application/vnd.google.protobuf;proto=io.prometheus.client.MetricFamily;encoding=compact-text",
},
out: output{
headers: map[string]string{
"Content-Type": `text/plain; charset=utf-8`,
},
body: expectedMetricFamilyInvalidLabelValueAsText,
},
collector: metricVec,
externalMF: []*dto.MetricFamily{
externalMetricFamily,
externalMetricFamilyWithInvalidLabelValue,
},
},
Introduce unchecked Collectors Fixes #47 . See there for more detailed discussion. Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-07-09 02:03:22 +03:00
{ // 17
headers: map[string]string{
Add suffix collision checks during gathering 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>
2018-07-13 17:29:17 +03:00
"Accept": "text/plain",
Introduce unchecked Collectors Fixes #47 . See there for more detailed discussion. Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-07-09 02:03:22 +03:00
},
out: output{
headers: map[string]string{
"Content-Type": `text/plain; version=0.0.4; charset=utf-8`,
},
body: expectedMetricFamilyAsText,
},
collector: uncheckedCollector{metricVec},
},
Add suffix collision checks during gathering 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>
2018-07-13 17:29:17 +03:00
{ // 18
headers: map[string]string{
"Accept": "text/plain",
},
out: output{
headers: map[string]string{
"Content-Type": `text/plain; charset=utf-8`,
},
body: histogramCountCollisionMsg,
},
collector: histogram,
externalMF: []*dto.MetricFamily{
externalMetricFamilyWithCountSuffix,
},
},
{ // 19
headers: map[string]string{
"Accept": "text/plain",
},
out: output{
headers: map[string]string{
"Content-Type": `text/plain; charset=utf-8`,
},
body: bucketCollisionMsg,
},
collector: histogram,
externalMF: []*dto.MetricFamily{
externalMetricFamilyWithBucketSuffix,
},
},
{ // 20
headers: map[string]string{
"Accept": "text/plain",
},
out: output{
headers: map[string]string{
"Content-Type": `text/plain; charset=utf-8`,
},
body: summaryCountCollisionMsg,
},
collector: summary,
externalMF: []*dto.MetricFamily{
externalMetricFamilyWithCountSuffix,
},
},
{ // 21
headers: map[string]string{
"Accept": "text/plain",
},
out: output{
headers: map[string]string{
"Content-Type": `text/plain; version=0.0.4; charset=utf-8`,
},
body: bytes.Join(
[][]byte{
summaryAsText,
externalMetricFamilyWithBucketSuffixAsText,
},
[]byte{},
),
},
collector: summary,
externalMF: []*dto.MetricFamily{
externalMetricFamilyWithBucketSuffix,
},
},
Expose failure to detect duplicate label names This is #471. Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-09-30 11:38:57 +03:00
{ // 22
headers: map[string]string{
"Accept": "text/plain",
},
out: output{
headers: map[string]string{
Add check for duplicated label names Fixes #471 Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-09-30 16:37:40 +03:00
"Content-Type": `text/plain; charset=utf-8`,
Expose failure to detect duplicate label names This is #471. Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-09-30 11:38:57 +03:00
},
body: duplicateLabelMsg,
},
externalMF: []*dto.MetricFamily{
externalMetricFamilyWithDuplicateLabel,
},
},
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
}
for i, scenario := range scenarios {
Move http stuff in its own package promhttp To keep backwards compatibility while not creating circular import chains, some code had to be duplicated. But all functions using it have been declared deprecated hereby. The new ways of instrumenting handlers will all go into the new package, and ultimately, the prometheus package itself will be completely igorant of HTTP.
2016-08-03 15:57:02 +03:00
registry := prometheus.NewPedanticRegistry()
Create a "merge gatherer" This allows to finally get rid of the infamous injection hook in the interface. The old SetMetricFamilyInjectionHook still exist as a deprecated function but is now implemented with the new plumbing under the hood. Now that we have multiple Gatherer implementation, I renamed push.Registry to push.FromGatherer. This commit also improves the consistency checks, which happened as a byproduct of the refactoring to allow checking in both the "merge gatherer" Gatherers as well as in the normal Registry.
2016-08-05 15:57:49 +03:00
gatherer := prometheus.Gatherer(registry)
Allow the metric family injection hook to merge with existing metric families. If a metric family returned by the injection hook already exists (with the same name), then its metrics are simply merged into that metric family. With enabled collect-time checks, even uniqueness is checked, but in general, things stay the same that the caller is responsible to ensure metric consistency. This fixes https://github.com/prometheus/pushgateway/issues/27 .
2015-03-15 17:47:56 +03:00
if scenario.externalMF != nil {
Create a "merge gatherer" This allows to finally get rid of the infamous injection hook in the interface. The old SetMetricFamilyInjectionHook still exist as a deprecated function but is now implemented with the new plumbing under the hood. Now that we have multiple Gatherer implementation, I renamed push.Registry to push.FromGatherer. This commit also improves the consistency checks, which happened as a byproduct of the refactoring to allow checking in both the "merge gatherer" Gatherers as well as in the normal Registry.
2016-08-05 15:57:49 +03:00
gatherer = prometheus.Gatherers{
registry,
prometheus.GathererFunc(func() ([]*dto.MetricFamily, error) {
return scenario.externalMF, nil
}),
}
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
}
Create a public registry interface and separate out HTTP exposition General context and approch =========================== This is the first part of the long awaited wider refurbishment of `client_golang/prometheus/...`. After a lot of struggling, I decided to not go for one breaking big-bang, but cut things into smaller steps after all, mostly to keep the changes manageable and easy to review. I'm aiming for having the invasive breaking changes concentrated in as few steps as possible (ideally one). Some steps will not be breaking at all, but typically there will be breaking changes that only affect quite special cases so that 95+% of users will not be affected. This first step is an example for that, see details below. What's happening in this commit? ================================ This step is about finally creating an exported registry interface. This could not be done by simply export the existing internal implementation because the interface would be _way_ too fat. This commit introduces a qutie lean `Registry` interface (compared to the previous interval implementation). The functions that act on the default registry are retained (with very few exceptions) so that most use cases won't see a change. However, several of those are deprecated now to clean up the namespace in the future. The default registry is kept in the public variable `DefaultRegistry`. This follows the example of the http package in the standard library (cf. `http.DefaultServeMux`, `http.DefaultClient`) with the same implications. (This pattern is somewhat disputed within the Go community but I chose to go with the devil you know instead of creating something more complex or even disallowing any changes to the default registry. The current approach gives everybody the freedom to not touch DefaultRegistry or to do everything with a custom registry to play save.) Another important part in making the registry lean is the extraction of the HTTP exposition, which also allows for customization of the HTTP exposition. Note that the separation of metric collection and exposition has the side effect that managing the MetricFamily and Metric protobuf objects in a free-list or pool isn't really feasible anymore. By now (with better GC in more recent Go versions), the returns were anyway dimisishing. To be effective at all, scrapes had to happen more often than GC cycles, and even then most elements of the protobufs (everything excetp the MetricFamily and Metric structs themselves) would still cause allocation churn. In a future breaking change, the signature of the Write method in the Metric interface will be adjusted accordingly. In this commit, avoiding breakage is more important. The following issues are fixed by this commit (some solved "on the fly" now that I was touching the code anyway and it would have been stupid to port the bugs): https://github.com/prometheus/client_golang/issues/46 https://github.com/prometheus/client_golang/issues/100 https://github.com/prometheus/client_golang/issues/170 https://github.com/prometheus/client_golang/issues/205 Documentation including examples have been amended as required. What future changes does this commit enable? ============================================ The following items are not yet implemented, but this commit opens the possibility of implementing these independently. - The separation of the HTTP exposition allows the implementation of other exposition methods based on the Registry interface, as known from other Prometheus client libraries, e.g. sending the metrics to Graphite. Cf. https://github.com/prometheus/client_golang/issues/197 - The public `Registry` interface allows the implementation of convenience tools for testing metrics collection. Those tools can inspect the collected MetricFamily protobufs and compare them to expectation. Also, tests can use their own testing instance of a registry. Cf. https://github.com/prometheus/client_golang/issues/58 Notable non-goals of this commit ================================ Non-goals that will be tackled later ------------------------------------ The following two issues are quite closely connected to the changes in this commit but the line has been drawn deliberately to address them in later steps of the refurbishment: - `InstrumentHandler` has many known problems. The plan is to create a saner way to conveniently intrument HTTP handlers and remove the old `InstrumentHandler` altogether. To keep breakage low for now, even the default handler to expose metrics is still using the old `InstrumentHandler`. This leads to weird naming inconsistencies but I have deemed it better to not break the world right now but do it in the change that provides better ways of instrumenting HTTP handlers. Cf. https://github.com/prometheus/client_golang/issues/200 - There is work underway to make the whole handling of metric descriptors (`Desc`) more intuitive and transparent for the user (including an ability for less strict checking, cf. https://github.com/prometheus/client_golang/issues/47). That's quite invasive from the perspective of the internal code, namely the registry. I deliberately kept those changes out of this commit. - While this commit adds new external dependency, the effort to vendor anything within the library that is not visible in any exported types will have to be done later. Non-goals that _might_ be tackled later --------------------------------------- There is a strong and understandable urge to divide the `prometheus` package into a number of sub-packages (like `registry`, `collectors`, `http`, `metrics`, …). However, to not run into a multitude of circular import chains, this would need to break every single existing usage of the library. (As just one example, if the ubiquitious `prometheus.MustRegister` (with more than 2,000 uses on GitHub alone) is kept in the `prometheus` package, but the other registry concerns go into a new `registry` package, then the `prometheus` package would import the `registry` package (to call the actual register method), while at the same time the `registry` package needs to import the `prometheus` package to access `Collector`, `Metric`, `Desc` and more. If we moved `MustRegister` into the `registry` package, thousands of code lines would have to be fixed (which would be easy if the world was a mono repo, but it is not). If we moved everything else the proposed registry package needs into packages of their own, we would break thousands of other code lines.) The main problem is really the top-level functions like `MustRegister`, `Handler`, …, which effectively pull everything into one package. Those functions are however very convenient for the easy and very frequent use-cases. This problem has to be revisited later. For now, I'm trying to keep the amount of exported names in the package as low as possible (e.g. I unexported expvarCollector in this commit because the NewExpvarCollector constructor is enough to export, and it is now consistent with other collectors, like the goCollector). Non-goals that won't be tackled anytime soon -------------------------------------------- Something that I have played with a lot is "streaming collection", i.e. allow an implementation of the `Registry` interface that collects metrics incrementally and serves them while doing so. As it has turned out, this has many many issues and makes the `Registry` interface very clunky. Eventually, I made the call that it is unlikely we will really implement streaming collection; and making the interface more clunky for something that might not even happen is really a big no-no. Note that the `Registry` interface only creates the in-memory representation of the metric family protobufs in one go. The serializaton onto the wire can still be handled in a streaming fashion (which hasn't been done so far, without causing any trouble, but might be done in the future without breaking any interfaces). What are the breaking changes? ============================== - Signatures of functions pushing to Pushgateway have changed to allow arbitrary grouping (which was planned for a long time anyway, and now that I had to work on the Push code anyway for the registry refurbishment, I finally did it, cf. https://github.com/prometheus/client_golang/issues/100). With the gained insight that pushing to the default registry is almost never the right thing, and now that we are breaking the Push call anyway, all the Push functions were moved to their own package, which cleans up the namespace and is more idiomatic (pushing Collectors is now literally done by `push.Collectors(...)`). - The registry is doing more consistency checks by default now. Past creators of inconsistent metrics could have masked the problem by not setting `EnableCollectChecks`. Those inconsistencies will now be detected. (But note that a "best effort" metrics collection is now possible with `HandlerOpts.ErrorHandling = ContinueOnError`.) - `EnableCollectChecks` is gone. The registry is now performing some of those checks anyway (see previous item), and a registry with all of those checks can now be created with `NewPedanticRegistry` (only used for testing). - `PanicOnCollectError` is gone. This behavior can now be configured when creating a custom HTTP handler.
2016-07-20 18:11:14 +03:00
if scenario.collector != nil {
Introduce unchecked Collectors Fixes #47 . See there for more detailed discussion. Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-07-09 02:03:22 +03:00
registry.MustRegister(scenario.collector)
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
}
Create a public registry interface and separate out HTTP exposition General context and approch =========================== This is the first part of the long awaited wider refurbishment of `client_golang/prometheus/...`. After a lot of struggling, I decided to not go for one breaking big-bang, but cut things into smaller steps after all, mostly to keep the changes manageable and easy to review. I'm aiming for having the invasive breaking changes concentrated in as few steps as possible (ideally one). Some steps will not be breaking at all, but typically there will be breaking changes that only affect quite special cases so that 95+% of users will not be affected. This first step is an example for that, see details below. What's happening in this commit? ================================ This step is about finally creating an exported registry interface. This could not be done by simply export the existing internal implementation because the interface would be _way_ too fat. This commit introduces a qutie lean `Registry` interface (compared to the previous interval implementation). The functions that act on the default registry are retained (with very few exceptions) so that most use cases won't see a change. However, several of those are deprecated now to clean up the namespace in the future. The default registry is kept in the public variable `DefaultRegistry`. This follows the example of the http package in the standard library (cf. `http.DefaultServeMux`, `http.DefaultClient`) with the same implications. (This pattern is somewhat disputed within the Go community but I chose to go with the devil you know instead of creating something more complex or even disallowing any changes to the default registry. The current approach gives everybody the freedom to not touch DefaultRegistry or to do everything with a custom registry to play save.) Another important part in making the registry lean is the extraction of the HTTP exposition, which also allows for customization of the HTTP exposition. Note that the separation of metric collection and exposition has the side effect that managing the MetricFamily and Metric protobuf objects in a free-list or pool isn't really feasible anymore. By now (with better GC in more recent Go versions), the returns were anyway dimisishing. To be effective at all, scrapes had to happen more often than GC cycles, and even then most elements of the protobufs (everything excetp the MetricFamily and Metric structs themselves) would still cause allocation churn. In a future breaking change, the signature of the Write method in the Metric interface will be adjusted accordingly. In this commit, avoiding breakage is more important. The following issues are fixed by this commit (some solved "on the fly" now that I was touching the code anyway and it would have been stupid to port the bugs): https://github.com/prometheus/client_golang/issues/46 https://github.com/prometheus/client_golang/issues/100 https://github.com/prometheus/client_golang/issues/170 https://github.com/prometheus/client_golang/issues/205 Documentation including examples have been amended as required. What future changes does this commit enable? ============================================ The following items are not yet implemented, but this commit opens the possibility of implementing these independently. - The separation of the HTTP exposition allows the implementation of other exposition methods based on the Registry interface, as known from other Prometheus client libraries, e.g. sending the metrics to Graphite. Cf. https://github.com/prometheus/client_golang/issues/197 - The public `Registry` interface allows the implementation of convenience tools for testing metrics collection. Those tools can inspect the collected MetricFamily protobufs and compare them to expectation. Also, tests can use their own testing instance of a registry. Cf. https://github.com/prometheus/client_golang/issues/58 Notable non-goals of this commit ================================ Non-goals that will be tackled later ------------------------------------ The following two issues are quite closely connected to the changes in this commit but the line has been drawn deliberately to address them in later steps of the refurbishment: - `InstrumentHandler` has many known problems. The plan is to create a saner way to conveniently intrument HTTP handlers and remove the old `InstrumentHandler` altogether. To keep breakage low for now, even the default handler to expose metrics is still using the old `InstrumentHandler`. This leads to weird naming inconsistencies but I have deemed it better to not break the world right now but do it in the change that provides better ways of instrumenting HTTP handlers. Cf. https://github.com/prometheus/client_golang/issues/200 - There is work underway to make the whole handling of metric descriptors (`Desc`) more intuitive and transparent for the user (including an ability for less strict checking, cf. https://github.com/prometheus/client_golang/issues/47). That's quite invasive from the perspective of the internal code, namely the registry. I deliberately kept those changes out of this commit. - While this commit adds new external dependency, the effort to vendor anything within the library that is not visible in any exported types will have to be done later. Non-goals that _might_ be tackled later --------------------------------------- There is a strong and understandable urge to divide the `prometheus` package into a number of sub-packages (like `registry`, `collectors`, `http`, `metrics`, …). However, to not run into a multitude of circular import chains, this would need to break every single existing usage of the library. (As just one example, if the ubiquitious `prometheus.MustRegister` (with more than 2,000 uses on GitHub alone) is kept in the `prometheus` package, but the other registry concerns go into a new `registry` package, then the `prometheus` package would import the `registry` package (to call the actual register method), while at the same time the `registry` package needs to import the `prometheus` package to access `Collector`, `Metric`, `Desc` and more. If we moved `MustRegister` into the `registry` package, thousands of code lines would have to be fixed (which would be easy if the world was a mono repo, but it is not). If we moved everything else the proposed registry package needs into packages of their own, we would break thousands of other code lines.) The main problem is really the top-level functions like `MustRegister`, `Handler`, …, which effectively pull everything into one package. Those functions are however very convenient for the easy and very frequent use-cases. This problem has to be revisited later. For now, I'm trying to keep the amount of exported names in the package as low as possible (e.g. I unexported expvarCollector in this commit because the NewExpvarCollector constructor is enough to export, and it is now consistent with other collectors, like the goCollector). Non-goals that won't be tackled anytime soon -------------------------------------------- Something that I have played with a lot is "streaming collection", i.e. allow an implementation of the `Registry` interface that collects metrics incrementally and serves them while doing so. As it has turned out, this has many many issues and makes the `Registry` interface very clunky. Eventually, I made the call that it is unlikely we will really implement streaming collection; and making the interface more clunky for something that might not even happen is really a big no-no. Note that the `Registry` interface only creates the in-memory representation of the metric family protobufs in one go. The serializaton onto the wire can still be handled in a streaming fashion (which hasn't been done so far, without causing any trouble, but might be done in the future without breaking any interfaces). What are the breaking changes? ============================== - Signatures of functions pushing to Pushgateway have changed to allow arbitrary grouping (which was planned for a long time anyway, and now that I had to work on the Push code anyway for the registry refurbishment, I finally did it, cf. https://github.com/prometheus/client_golang/issues/100). With the gained insight that pushing to the default registry is almost never the right thing, and now that we are breaking the Push call anyway, all the Push functions were moved to their own package, which cleans up the namespace and is more idiomatic (pushing Collectors is now literally done by `push.Collectors(...)`). - The registry is doing more consistency checks by default now. Past creators of inconsistent metrics could have masked the problem by not setting `EnableCollectChecks`. Those inconsistencies will now be detected. (But note that a "best effort" metrics collection is now possible with `HandlerOpts.ErrorHandling = ContinueOnError`.) - `EnableCollectChecks` is gone. The registry is now performing some of those checks anyway (see previous item), and a registry with all of those checks can now be created with `NewPedanticRegistry` (only used for testing). - `PanicOnCollectError` is gone. This behavior can now be configured when creating a custom HTTP handler.
2016-07-20 18:11:14 +03:00
writer := httptest.NewRecorder()
Create a "merge gatherer" This allows to finally get rid of the infamous injection hook in the interface. The old SetMetricFamilyInjectionHook still exist as a deprecated function but is now implemented with the new plumbing under the hood. Now that we have multiple Gatherer implementation, I renamed push.Registry to push.FromGatherer. This commit also improves the consistency checks, which happened as a byproduct of the refactoring to allow checking in both the "merge gatherer" Gatherers as well as in the normal Registry.
2016-08-05 15:57:49 +03:00
handler := prometheus.InstrumentHandler("prometheus", promhttp.HandlerFor(gatherer, promhttp.HandlerOpts{}))
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
request, _ := http.NewRequest("GET", "/", nil)
for key, value := range scenario.headers {
request.Header.Add(key, value)
}
handler(writer, request)
for key, value := range scenario.out.headers {
Handle items newly deprecated in Go 1.11 Remove where possible and ignore staticcheck warnings where we have to. Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-09-19 14:30:14 +03:00
if writer.Header().Get(key) != value {
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
t.Errorf(
"%d. expected %q for header %q, got %q",
i, value, key, writer.Header().Get(key),
)
}
}
Create a public registry interface and separate out HTTP exposition General context and approch =========================== This is the first part of the long awaited wider refurbishment of `client_golang/prometheus/...`. After a lot of struggling, I decided to not go for one breaking big-bang, but cut things into smaller steps after all, mostly to keep the changes manageable and easy to review. I'm aiming for having the invasive breaking changes concentrated in as few steps as possible (ideally one). Some steps will not be breaking at all, but typically there will be breaking changes that only affect quite special cases so that 95+% of users will not be affected. This first step is an example for that, see details below. What's happening in this commit? ================================ This step is about finally creating an exported registry interface. This could not be done by simply export the existing internal implementation because the interface would be _way_ too fat. This commit introduces a qutie lean `Registry` interface (compared to the previous interval implementation). The functions that act on the default registry are retained (with very few exceptions) so that most use cases won't see a change. However, several of those are deprecated now to clean up the namespace in the future. The default registry is kept in the public variable `DefaultRegistry`. This follows the example of the http package in the standard library (cf. `http.DefaultServeMux`, `http.DefaultClient`) with the same implications. (This pattern is somewhat disputed within the Go community but I chose to go with the devil you know instead of creating something more complex or even disallowing any changes to the default registry. The current approach gives everybody the freedom to not touch DefaultRegistry or to do everything with a custom registry to play save.) Another important part in making the registry lean is the extraction of the HTTP exposition, which also allows for customization of the HTTP exposition. Note that the separation of metric collection and exposition has the side effect that managing the MetricFamily and Metric protobuf objects in a free-list or pool isn't really feasible anymore. By now (with better GC in more recent Go versions), the returns were anyway dimisishing. To be effective at all, scrapes had to happen more often than GC cycles, and even then most elements of the protobufs (everything excetp the MetricFamily and Metric structs themselves) would still cause allocation churn. In a future breaking change, the signature of the Write method in the Metric interface will be adjusted accordingly. In this commit, avoiding breakage is more important. The following issues are fixed by this commit (some solved "on the fly" now that I was touching the code anyway and it would have been stupid to port the bugs): https://github.com/prometheus/client_golang/issues/46 https://github.com/prometheus/client_golang/issues/100 https://github.com/prometheus/client_golang/issues/170 https://github.com/prometheus/client_golang/issues/205 Documentation including examples have been amended as required. What future changes does this commit enable? ============================================ The following items are not yet implemented, but this commit opens the possibility of implementing these independently. - The separation of the HTTP exposition allows the implementation of other exposition methods based on the Registry interface, as known from other Prometheus client libraries, e.g. sending the metrics to Graphite. Cf. https://github.com/prometheus/client_golang/issues/197 - The public `Registry` interface allows the implementation of convenience tools for testing metrics collection. Those tools can inspect the collected MetricFamily protobufs and compare them to expectation. Also, tests can use their own testing instance of a registry. Cf. https://github.com/prometheus/client_golang/issues/58 Notable non-goals of this commit ================================ Non-goals that will be tackled later ------------------------------------ The following two issues are quite closely connected to the changes in this commit but the line has been drawn deliberately to address them in later steps of the refurbishment: - `InstrumentHandler` has many known problems. The plan is to create a saner way to conveniently intrument HTTP handlers and remove the old `InstrumentHandler` altogether. To keep breakage low for now, even the default handler to expose metrics is still using the old `InstrumentHandler`. This leads to weird naming inconsistencies but I have deemed it better to not break the world right now but do it in the change that provides better ways of instrumenting HTTP handlers. Cf. https://github.com/prometheus/client_golang/issues/200 - There is work underway to make the whole handling of metric descriptors (`Desc`) more intuitive and transparent for the user (including an ability for less strict checking, cf. https://github.com/prometheus/client_golang/issues/47). That's quite invasive from the perspective of the internal code, namely the registry. I deliberately kept those changes out of this commit. - While this commit adds new external dependency, the effort to vendor anything within the library that is not visible in any exported types will have to be done later. Non-goals that _might_ be tackled later --------------------------------------- There is a strong and understandable urge to divide the `prometheus` package into a number of sub-packages (like `registry`, `collectors`, `http`, `metrics`, …). However, to not run into a multitude of circular import chains, this would need to break every single existing usage of the library. (As just one example, if the ubiquitious `prometheus.MustRegister` (with more than 2,000 uses on GitHub alone) is kept in the `prometheus` package, but the other registry concerns go into a new `registry` package, then the `prometheus` package would import the `registry` package (to call the actual register method), while at the same time the `registry` package needs to import the `prometheus` package to access `Collector`, `Metric`, `Desc` and more. If we moved `MustRegister` into the `registry` package, thousands of code lines would have to be fixed (which would be easy if the world was a mono repo, but it is not). If we moved everything else the proposed registry package needs into packages of their own, we would break thousands of other code lines.) The main problem is really the top-level functions like `MustRegister`, `Handler`, …, which effectively pull everything into one package. Those functions are however very convenient for the easy and very frequent use-cases. This problem has to be revisited later. For now, I'm trying to keep the amount of exported names in the package as low as possible (e.g. I unexported expvarCollector in this commit because the NewExpvarCollector constructor is enough to export, and it is now consistent with other collectors, like the goCollector). Non-goals that won't be tackled anytime soon -------------------------------------------- Something that I have played with a lot is "streaming collection", i.e. allow an implementation of the `Registry` interface that collects metrics incrementally and serves them while doing so. As it has turned out, this has many many issues and makes the `Registry` interface very clunky. Eventually, I made the call that it is unlikely we will really implement streaming collection; and making the interface more clunky for something that might not even happen is really a big no-no. Note that the `Registry` interface only creates the in-memory representation of the metric family protobufs in one go. The serializaton onto the wire can still be handled in a streaming fashion (which hasn't been done so far, without causing any trouble, but might be done in the future without breaking any interfaces). What are the breaking changes? ============================== - Signatures of functions pushing to Pushgateway have changed to allow arbitrary grouping (which was planned for a long time anyway, and now that I had to work on the Push code anyway for the registry refurbishment, I finally did it, cf. https://github.com/prometheus/client_golang/issues/100). With the gained insight that pushing to the default registry is almost never the right thing, and now that we are breaking the Push call anyway, all the Push functions were moved to their own package, which cleans up the namespace and is more idiomatic (pushing Collectors is now literally done by `push.Collectors(...)`). - The registry is doing more consistency checks by default now. Past creators of inconsistent metrics could have masked the problem by not setting `EnableCollectChecks`. Those inconsistencies will now be detected. (But note that a "best effort" metrics collection is now possible with `HandlerOpts.ErrorHandling = ContinueOnError`.) - `EnableCollectChecks` is gone. The registry is now performing some of those checks anyway (see previous item), and a registry with all of those checks can now be created with `NewPedanticRegistry` (only used for testing). - `PanicOnCollectError` is gone. This behavior can now be configured when creating a custom HTTP handler.
2016-07-20 18:11:14 +03:00
if !bytes.Equal(scenario.out.body, writer.Body.Bytes()) {
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
t.Errorf(
Create a "merge gatherer" This allows to finally get rid of the infamous injection hook in the interface. The old SetMetricFamilyInjectionHook still exist as a deprecated function but is now implemented with the new plumbing under the hood. Now that we have multiple Gatherer implementation, I renamed push.Registry to push.FromGatherer. This commit also improves the consistency checks, which happened as a byproduct of the refactoring to allow checking in both the "merge gatherer" Gatherers as well as in the normal Registry.
2016-08-05 15:57:49 +03:00
"%d. expected body:\n%s\ngot body:\n%s\n",
Create a public registry interface and separate out HTTP exposition General context and approch =========================== This is the first part of the long awaited wider refurbishment of `client_golang/prometheus/...`. After a lot of struggling, I decided to not go for one breaking big-bang, but cut things into smaller steps after all, mostly to keep the changes manageable and easy to review. I'm aiming for having the invasive breaking changes concentrated in as few steps as possible (ideally one). Some steps will not be breaking at all, but typically there will be breaking changes that only affect quite special cases so that 95+% of users will not be affected. This first step is an example for that, see details below. What's happening in this commit? ================================ This step is about finally creating an exported registry interface. This could not be done by simply export the existing internal implementation because the interface would be _way_ too fat. This commit introduces a qutie lean `Registry` interface (compared to the previous interval implementation). The functions that act on the default registry are retained (with very few exceptions) so that most use cases won't see a change. However, several of those are deprecated now to clean up the namespace in the future. The default registry is kept in the public variable `DefaultRegistry`. This follows the example of the http package in the standard library (cf. `http.DefaultServeMux`, `http.DefaultClient`) with the same implications. (This pattern is somewhat disputed within the Go community but I chose to go with the devil you know instead of creating something more complex or even disallowing any changes to the default registry. The current approach gives everybody the freedom to not touch DefaultRegistry or to do everything with a custom registry to play save.) Another important part in making the registry lean is the extraction of the HTTP exposition, which also allows for customization of the HTTP exposition. Note that the separation of metric collection and exposition has the side effect that managing the MetricFamily and Metric protobuf objects in a free-list or pool isn't really feasible anymore. By now (with better GC in more recent Go versions), the returns were anyway dimisishing. To be effective at all, scrapes had to happen more often than GC cycles, and even then most elements of the protobufs (everything excetp the MetricFamily and Metric structs themselves) would still cause allocation churn. In a future breaking change, the signature of the Write method in the Metric interface will be adjusted accordingly. In this commit, avoiding breakage is more important. The following issues are fixed by this commit (some solved "on the fly" now that I was touching the code anyway and it would have been stupid to port the bugs): https://github.com/prometheus/client_golang/issues/46 https://github.com/prometheus/client_golang/issues/100 https://github.com/prometheus/client_golang/issues/170 https://github.com/prometheus/client_golang/issues/205 Documentation including examples have been amended as required. What future changes does this commit enable? ============================================ The following items are not yet implemented, but this commit opens the possibility of implementing these independently. - The separation of the HTTP exposition allows the implementation of other exposition methods based on the Registry interface, as known from other Prometheus client libraries, e.g. sending the metrics to Graphite. Cf. https://github.com/prometheus/client_golang/issues/197 - The public `Registry` interface allows the implementation of convenience tools for testing metrics collection. Those tools can inspect the collected MetricFamily protobufs and compare them to expectation. Also, tests can use their own testing instance of a registry. Cf. https://github.com/prometheus/client_golang/issues/58 Notable non-goals of this commit ================================ Non-goals that will be tackled later ------------------------------------ The following two issues are quite closely connected to the changes in this commit but the line has been drawn deliberately to address them in later steps of the refurbishment: - `InstrumentHandler` has many known problems. The plan is to create a saner way to conveniently intrument HTTP handlers and remove the old `InstrumentHandler` altogether. To keep breakage low for now, even the default handler to expose metrics is still using the old `InstrumentHandler`. This leads to weird naming inconsistencies but I have deemed it better to not break the world right now but do it in the change that provides better ways of instrumenting HTTP handlers. Cf. https://github.com/prometheus/client_golang/issues/200 - There is work underway to make the whole handling of metric descriptors (`Desc`) more intuitive and transparent for the user (including an ability for less strict checking, cf. https://github.com/prometheus/client_golang/issues/47). That's quite invasive from the perspective of the internal code, namely the registry. I deliberately kept those changes out of this commit. - While this commit adds new external dependency, the effort to vendor anything within the library that is not visible in any exported types will have to be done later. Non-goals that _might_ be tackled later --------------------------------------- There is a strong and understandable urge to divide the `prometheus` package into a number of sub-packages (like `registry`, `collectors`, `http`, `metrics`, …). However, to not run into a multitude of circular import chains, this would need to break every single existing usage of the library. (As just one example, if the ubiquitious `prometheus.MustRegister` (with more than 2,000 uses on GitHub alone) is kept in the `prometheus` package, but the other registry concerns go into a new `registry` package, then the `prometheus` package would import the `registry` package (to call the actual register method), while at the same time the `registry` package needs to import the `prometheus` package to access `Collector`, `Metric`, `Desc` and more. If we moved `MustRegister` into the `registry` package, thousands of code lines would have to be fixed (which would be easy if the world was a mono repo, but it is not). If we moved everything else the proposed registry package needs into packages of their own, we would break thousands of other code lines.) The main problem is really the top-level functions like `MustRegister`, `Handler`, …, which effectively pull everything into one package. Those functions are however very convenient for the easy and very frequent use-cases. This problem has to be revisited later. For now, I'm trying to keep the amount of exported names in the package as low as possible (e.g. I unexported expvarCollector in this commit because the NewExpvarCollector constructor is enough to export, and it is now consistent with other collectors, like the goCollector). Non-goals that won't be tackled anytime soon -------------------------------------------- Something that I have played with a lot is "streaming collection", i.e. allow an implementation of the `Registry` interface that collects metrics incrementally and serves them while doing so. As it has turned out, this has many many issues and makes the `Registry` interface very clunky. Eventually, I made the call that it is unlikely we will really implement streaming collection; and making the interface more clunky for something that might not even happen is really a big no-no. Note that the `Registry` interface only creates the in-memory representation of the metric family protobufs in one go. The serializaton onto the wire can still be handled in a streaming fashion (which hasn't been done so far, without causing any trouble, but might be done in the future without breaking any interfaces). What are the breaking changes? ============================== - Signatures of functions pushing to Pushgateway have changed to allow arbitrary grouping (which was planned for a long time anyway, and now that I had to work on the Push code anyway for the registry refurbishment, I finally did it, cf. https://github.com/prometheus/client_golang/issues/100). With the gained insight that pushing to the default registry is almost never the right thing, and now that we are breaking the Push call anyway, all the Push functions were moved to their own package, which cleans up the namespace and is more idiomatic (pushing Collectors is now literally done by `push.Collectors(...)`). - The registry is doing more consistency checks by default now. Past creators of inconsistent metrics could have masked the problem by not setting `EnableCollectChecks`. Those inconsistencies will now be detected. (But note that a "best effort" metrics collection is now possible with `HandlerOpts.ErrorHandling = ContinueOnError`.) - `EnableCollectChecks` is gone. The registry is now performing some of those checks anyway (see previous item), and a registry with all of those checks can now be created with `NewPedanticRegistry` (only used for testing). - `PanicOnCollectError` is gone. This behavior can now be configured when creating a custom HTTP handler.
2016-07-20 18:11:14 +03:00
i, scenario.out.body, writer.Body.Bytes(),
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
)
}
}
}
Complete rewrite of the exposition library. 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
2014-05-07 22:08:33 +04:00
func TestHandler(t *testing.T) {
Add a low-level MetricFamily injection hook. This hook is needed for the upcoming push gateway. Also remove go vet warnings and add test for Handler(). Change-Id: If6c56676c7a0f10c16b4effae7285903f8267616
2014-04-02 15:31:22 +04:00
testHandler(t)
}
func BenchmarkHandler(b *testing.B) {
for i := 0; i < b.N; i++ {
testHandler(b)
}
}
Create a public registry interface and separate out HTTP exposition General context and approch =========================== This is the first part of the long awaited wider refurbishment of `client_golang/prometheus/...`. After a lot of struggling, I decided to not go for one breaking big-bang, but cut things into smaller steps after all, mostly to keep the changes manageable and easy to review. I'm aiming for having the invasive breaking changes concentrated in as few steps as possible (ideally one). Some steps will not be breaking at all, but typically there will be breaking changes that only affect quite special cases so that 95+% of users will not be affected. This first step is an example for that, see details below. What's happening in this commit? ================================ This step is about finally creating an exported registry interface. This could not be done by simply export the existing internal implementation because the interface would be _way_ too fat. This commit introduces a qutie lean `Registry` interface (compared to the previous interval implementation). The functions that act on the default registry are retained (with very few exceptions) so that most use cases won't see a change. However, several of those are deprecated now to clean up the namespace in the future. The default registry is kept in the public variable `DefaultRegistry`. This follows the example of the http package in the standard library (cf. `http.DefaultServeMux`, `http.DefaultClient`) with the same implications. (This pattern is somewhat disputed within the Go community but I chose to go with the devil you know instead of creating something more complex or even disallowing any changes to the default registry. The current approach gives everybody the freedom to not touch DefaultRegistry or to do everything with a custom registry to play save.) Another important part in making the registry lean is the extraction of the HTTP exposition, which also allows for customization of the HTTP exposition. Note that the separation of metric collection and exposition has the side effect that managing the MetricFamily and Metric protobuf objects in a free-list or pool isn't really feasible anymore. By now (with better GC in more recent Go versions), the returns were anyway dimisishing. To be effective at all, scrapes had to happen more often than GC cycles, and even then most elements of the protobufs (everything excetp the MetricFamily and Metric structs themselves) would still cause allocation churn. In a future breaking change, the signature of the Write method in the Metric interface will be adjusted accordingly. In this commit, avoiding breakage is more important. The following issues are fixed by this commit (some solved "on the fly" now that I was touching the code anyway and it would have been stupid to port the bugs): https://github.com/prometheus/client_golang/issues/46 https://github.com/prometheus/client_golang/issues/100 https://github.com/prometheus/client_golang/issues/170 https://github.com/prometheus/client_golang/issues/205 Documentation including examples have been amended as required. What future changes does this commit enable? ============================================ The following items are not yet implemented, but this commit opens the possibility of implementing these independently. - The separation of the HTTP exposition allows the implementation of other exposition methods based on the Registry interface, as known from other Prometheus client libraries, e.g. sending the metrics to Graphite. Cf. https://github.com/prometheus/client_golang/issues/197 - The public `Registry` interface allows the implementation of convenience tools for testing metrics collection. Those tools can inspect the collected MetricFamily protobufs and compare them to expectation. Also, tests can use their own testing instance of a registry. Cf. https://github.com/prometheus/client_golang/issues/58 Notable non-goals of this commit ================================ Non-goals that will be tackled later ------------------------------------ The following two issues are quite closely connected to the changes in this commit but the line has been drawn deliberately to address them in later steps of the refurbishment: - `InstrumentHandler` has many known problems. The plan is to create a saner way to conveniently intrument HTTP handlers and remove the old `InstrumentHandler` altogether. To keep breakage low for now, even the default handler to expose metrics is still using the old `InstrumentHandler`. This leads to weird naming inconsistencies but I have deemed it better to not break the world right now but do it in the change that provides better ways of instrumenting HTTP handlers. Cf. https://github.com/prometheus/client_golang/issues/200 - There is work underway to make the whole handling of metric descriptors (`Desc`) more intuitive and transparent for the user (including an ability for less strict checking, cf. https://github.com/prometheus/client_golang/issues/47). That's quite invasive from the perspective of the internal code, namely the registry. I deliberately kept those changes out of this commit. - While this commit adds new external dependency, the effort to vendor anything within the library that is not visible in any exported types will have to be done later. Non-goals that _might_ be tackled later --------------------------------------- There is a strong and understandable urge to divide the `prometheus` package into a number of sub-packages (like `registry`, `collectors`, `http`, `metrics`, …). However, to not run into a multitude of circular import chains, this would need to break every single existing usage of the library. (As just one example, if the ubiquitious `prometheus.MustRegister` (with more than 2,000 uses on GitHub alone) is kept in the `prometheus` package, but the other registry concerns go into a new `registry` package, then the `prometheus` package would import the `registry` package (to call the actual register method), while at the same time the `registry` package needs to import the `prometheus` package to access `Collector`, `Metric`, `Desc` and more. If we moved `MustRegister` into the `registry` package, thousands of code lines would have to be fixed (which would be easy if the world was a mono repo, but it is not). If we moved everything else the proposed registry package needs into packages of their own, we would break thousands of other code lines.) The main problem is really the top-level functions like `MustRegister`, `Handler`, …, which effectively pull everything into one package. Those functions are however very convenient for the easy and very frequent use-cases. This problem has to be revisited later. For now, I'm trying to keep the amount of exported names in the package as low as possible (e.g. I unexported expvarCollector in this commit because the NewExpvarCollector constructor is enough to export, and it is now consistent with other collectors, like the goCollector). Non-goals that won't be tackled anytime soon -------------------------------------------- Something that I have played with a lot is "streaming collection", i.e. allow an implementation of the `Registry` interface that collects metrics incrementally and serves them while doing so. As it has turned out, this has many many issues and makes the `Registry` interface very clunky. Eventually, I made the call that it is unlikely we will really implement streaming collection; and making the interface more clunky for something that might not even happen is really a big no-no. Note that the `Registry` interface only creates the in-memory representation of the metric family protobufs in one go. The serializaton onto the wire can still be handled in a streaming fashion (which hasn't been done so far, without causing any trouble, but might be done in the future without breaking any interfaces). What are the breaking changes? ============================== - Signatures of functions pushing to Pushgateway have changed to allow arbitrary grouping (which was planned for a long time anyway, and now that I had to work on the Push code anyway for the registry refurbishment, I finally did it, cf. https://github.com/prometheus/client_golang/issues/100). With the gained insight that pushing to the default registry is almost never the right thing, and now that we are breaking the Push call anyway, all the Push functions were moved to their own package, which cleans up the namespace and is more idiomatic (pushing Collectors is now literally done by `push.Collectors(...)`). - The registry is doing more consistency checks by default now. Past creators of inconsistent metrics could have masked the problem by not setting `EnableCollectChecks`. Those inconsistencies will now be detected. (But note that a "best effort" metrics collection is now possible with `HandlerOpts.ErrorHandling = ContinueOnError`.) - `EnableCollectChecks` is gone. The registry is now performing some of those checks anyway (see previous item), and a registry with all of those checks can now be created with `NewPedanticRegistry` (only used for testing). - `PanicOnCollectError` is gone. This behavior can now be configured when creating a custom HTTP handler.
2016-07-20 18:11:14 +03:00
Adjust TestRegisterWithOrGet to the present Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-10-10 16:41:21 +03:00
func TestAlreadyRegistered(t *testing.T) {
reg := prometheus.NewRegistry()
Move http stuff in its own package promhttp To keep backwards compatibility while not creating circular import chains, some code had to be duplicated. But all functions using it have been declared deprecated hereby. The new ways of instrumenting handlers will all go into the new package, and ultimately, the prometheus package itself will be completely igorant of HTTP.
2016-08-03 15:57:02 +03:00
original := prometheus.NewCounterVec(
prometheus.CounterOpts{
Create a public registry interface and separate out HTTP exposition General context and approch =========================== This is the first part of the long awaited wider refurbishment of `client_golang/prometheus/...`. After a lot of struggling, I decided to not go for one breaking big-bang, but cut things into smaller steps after all, mostly to keep the changes manageable and easy to review. I'm aiming for having the invasive breaking changes concentrated in as few steps as possible (ideally one). Some steps will not be breaking at all, but typically there will be breaking changes that only affect quite special cases so that 95+% of users will not be affected. This first step is an example for that, see details below. What's happening in this commit? ================================ This step is about finally creating an exported registry interface. This could not be done by simply export the existing internal implementation because the interface would be _way_ too fat. This commit introduces a qutie lean `Registry` interface (compared to the previous interval implementation). The functions that act on the default registry are retained (with very few exceptions) so that most use cases won't see a change. However, several of those are deprecated now to clean up the namespace in the future. The default registry is kept in the public variable `DefaultRegistry`. This follows the example of the http package in the standard library (cf. `http.DefaultServeMux`, `http.DefaultClient`) with the same implications. (This pattern is somewhat disputed within the Go community but I chose to go with the devil you know instead of creating something more complex or even disallowing any changes to the default registry. The current approach gives everybody the freedom to not touch DefaultRegistry or to do everything with a custom registry to play save.) Another important part in making the registry lean is the extraction of the HTTP exposition, which also allows for customization of the HTTP exposition. Note that the separation of metric collection and exposition has the side effect that managing the MetricFamily and Metric protobuf objects in a free-list or pool isn't really feasible anymore. By now (with better GC in more recent Go versions), the returns were anyway dimisishing. To be effective at all, scrapes had to happen more often than GC cycles, and even then most elements of the protobufs (everything excetp the MetricFamily and Metric structs themselves) would still cause allocation churn. In a future breaking change, the signature of the Write method in the Metric interface will be adjusted accordingly. In this commit, avoiding breakage is more important. The following issues are fixed by this commit (some solved "on the fly" now that I was touching the code anyway and it would have been stupid to port the bugs): https://github.com/prometheus/client_golang/issues/46 https://github.com/prometheus/client_golang/issues/100 https://github.com/prometheus/client_golang/issues/170 https://github.com/prometheus/client_golang/issues/205 Documentation including examples have been amended as required. What future changes does this commit enable? ============================================ The following items are not yet implemented, but this commit opens the possibility of implementing these independently. - The separation of the HTTP exposition allows the implementation of other exposition methods based on the Registry interface, as known from other Prometheus client libraries, e.g. sending the metrics to Graphite. Cf. https://github.com/prometheus/client_golang/issues/197 - The public `Registry` interface allows the implementation of convenience tools for testing metrics collection. Those tools can inspect the collected MetricFamily protobufs and compare them to expectation. Also, tests can use their own testing instance of a registry. Cf. https://github.com/prometheus/client_golang/issues/58 Notable non-goals of this commit ================================ Non-goals that will be tackled later ------------------------------------ The following two issues are quite closely connected to the changes in this commit but the line has been drawn deliberately to address them in later steps of the refurbishment: - `InstrumentHandler` has many known problems. The plan is to create a saner way to conveniently intrument HTTP handlers and remove the old `InstrumentHandler` altogether. To keep breakage low for now, even the default handler to expose metrics is still using the old `InstrumentHandler`. This leads to weird naming inconsistencies but I have deemed it better to not break the world right now but do it in the change that provides better ways of instrumenting HTTP handlers. Cf. https://github.com/prometheus/client_golang/issues/200 - There is work underway to make the whole handling of metric descriptors (`Desc`) more intuitive and transparent for the user (including an ability for less strict checking, cf. https://github.com/prometheus/client_golang/issues/47). That's quite invasive from the perspective of the internal code, namely the registry. I deliberately kept those changes out of this commit. - While this commit adds new external dependency, the effort to vendor anything within the library that is not visible in any exported types will have to be done later. Non-goals that _might_ be tackled later --------------------------------------- There is a strong and understandable urge to divide the `prometheus` package into a number of sub-packages (like `registry`, `collectors`, `http`, `metrics`, …). However, to not run into a multitude of circular import chains, this would need to break every single existing usage of the library. (As just one example, if the ubiquitious `prometheus.MustRegister` (with more than 2,000 uses on GitHub alone) is kept in the `prometheus` package, but the other registry concerns go into a new `registry` package, then the `prometheus` package would import the `registry` package (to call the actual register method), while at the same time the `registry` package needs to import the `prometheus` package to access `Collector`, `Metric`, `Desc` and more. If we moved `MustRegister` into the `registry` package, thousands of code lines would have to be fixed (which would be easy if the world was a mono repo, but it is not). If we moved everything else the proposed registry package needs into packages of their own, we would break thousands of other code lines.) The main problem is really the top-level functions like `MustRegister`, `Handler`, …, which effectively pull everything into one package. Those functions are however very convenient for the easy and very frequent use-cases. This problem has to be revisited later. For now, I'm trying to keep the amount of exported names in the package as low as possible (e.g. I unexported expvarCollector in this commit because the NewExpvarCollector constructor is enough to export, and it is now consistent with other collectors, like the goCollector). Non-goals that won't be tackled anytime soon -------------------------------------------- Something that I have played with a lot is "streaming collection", i.e. allow an implementation of the `Registry` interface that collects metrics incrementally and serves them while doing so. As it has turned out, this has many many issues and makes the `Registry` interface very clunky. Eventually, I made the call that it is unlikely we will really implement streaming collection; and making the interface more clunky for something that might not even happen is really a big no-no. Note that the `Registry` interface only creates the in-memory representation of the metric family protobufs in one go. The serializaton onto the wire can still be handled in a streaming fashion (which hasn't been done so far, without causing any trouble, but might be done in the future without breaking any interfaces). What are the breaking changes? ============================== - Signatures of functions pushing to Pushgateway have changed to allow arbitrary grouping (which was planned for a long time anyway, and now that I had to work on the Push code anyway for the registry refurbishment, I finally did it, cf. https://github.com/prometheus/client_golang/issues/100). With the gained insight that pushing to the default registry is almost never the right thing, and now that we are breaking the Push call anyway, all the Push functions were moved to their own package, which cleans up the namespace and is more idiomatic (pushing Collectors is now literally done by `push.Collectors(...)`). - The registry is doing more consistency checks by default now. Past creators of inconsistent metrics could have masked the problem by not setting `EnableCollectChecks`. Those inconsistencies will now be detected. (But note that a "best effort" metrics collection is now possible with `HandlerOpts.ErrorHandling = ContinueOnError`.) - `EnableCollectChecks` is gone. The registry is now performing some of those checks anyway (see previous item), and a registry with all of those checks can now be created with `NewPedanticRegistry` (only used for testing). - `PanicOnCollectError` is gone. This behavior can now be configured when creating a custom HTTP handler.
2016-07-20 18:11:14 +03:00
Name: "test",
Help: "help",
},
[]string{"foo", "bar"},
)
Move http stuff in its own package promhttp To keep backwards compatibility while not creating circular import chains, some code had to be duplicated. But all functions using it have been declared deprecated hereby. The new ways of instrumenting handlers will all go into the new package, and ultimately, the prometheus package itself will be completely igorant of HTTP.
2016-08-03 15:57:02 +03:00
equalButNotSame := prometheus.NewCounterVec(
prometheus.CounterOpts{
Create a public registry interface and separate out HTTP exposition General context and approch =========================== This is the first part of the long awaited wider refurbishment of `client_golang/prometheus/...`. After a lot of struggling, I decided to not go for one breaking big-bang, but cut things into smaller steps after all, mostly to keep the changes manageable and easy to review. I'm aiming for having the invasive breaking changes concentrated in as few steps as possible (ideally one). Some steps will not be breaking at all, but typically there will be breaking changes that only affect quite special cases so that 95+% of users will not be affected. This first step is an example for that, see details below. What's happening in this commit? ================================ This step is about finally creating an exported registry interface. This could not be done by simply export the existing internal implementation because the interface would be _way_ too fat. This commit introduces a qutie lean `Registry` interface (compared to the previous interval implementation). The functions that act on the default registry are retained (with very few exceptions) so that most use cases won't see a change. However, several of those are deprecated now to clean up the namespace in the future. The default registry is kept in the public variable `DefaultRegistry`. This follows the example of the http package in the standard library (cf. `http.DefaultServeMux`, `http.DefaultClient`) with the same implications. (This pattern is somewhat disputed within the Go community but I chose to go with the devil you know instead of creating something more complex or even disallowing any changes to the default registry. The current approach gives everybody the freedom to not touch DefaultRegistry or to do everything with a custom registry to play save.) Another important part in making the registry lean is the extraction of the HTTP exposition, which also allows for customization of the HTTP exposition. Note that the separation of metric collection and exposition has the side effect that managing the MetricFamily and Metric protobuf objects in a free-list or pool isn't really feasible anymore. By now (with better GC in more recent Go versions), the returns were anyway dimisishing. To be effective at all, scrapes had to happen more often than GC cycles, and even then most elements of the protobufs (everything excetp the MetricFamily and Metric structs themselves) would still cause allocation churn. In a future breaking change, the signature of the Write method in the Metric interface will be adjusted accordingly. In this commit, avoiding breakage is more important. The following issues are fixed by this commit (some solved "on the fly" now that I was touching the code anyway and it would have been stupid to port the bugs): https://github.com/prometheus/client_golang/issues/46 https://github.com/prometheus/client_golang/issues/100 https://github.com/prometheus/client_golang/issues/170 https://github.com/prometheus/client_golang/issues/205 Documentation including examples have been amended as required. What future changes does this commit enable? ============================================ The following items are not yet implemented, but this commit opens the possibility of implementing these independently. - The separation of the HTTP exposition allows the implementation of other exposition methods based on the Registry interface, as known from other Prometheus client libraries, e.g. sending the metrics to Graphite. Cf. https://github.com/prometheus/client_golang/issues/197 - The public `Registry` interface allows the implementation of convenience tools for testing metrics collection. Those tools can inspect the collected MetricFamily protobufs and compare them to expectation. Also, tests can use their own testing instance of a registry. Cf. https://github.com/prometheus/client_golang/issues/58 Notable non-goals of this commit ================================ Non-goals that will be tackled later ------------------------------------ The following two issues are quite closely connected to the changes in this commit but the line has been drawn deliberately to address them in later steps of the refurbishment: - `InstrumentHandler` has many known problems. The plan is to create a saner way to conveniently intrument HTTP handlers and remove the old `InstrumentHandler` altogether. To keep breakage low for now, even the default handler to expose metrics is still using the old `InstrumentHandler`. This leads to weird naming inconsistencies but I have deemed it better to not break the world right now but do it in the change that provides better ways of instrumenting HTTP handlers. Cf. https://github.com/prometheus/client_golang/issues/200 - There is work underway to make the whole handling of metric descriptors (`Desc`) more intuitive and transparent for the user (including an ability for less strict checking, cf. https://github.com/prometheus/client_golang/issues/47). That's quite invasive from the perspective of the internal code, namely the registry. I deliberately kept those changes out of this commit. - While this commit adds new external dependency, the effort to vendor anything within the library that is not visible in any exported types will have to be done later. Non-goals that _might_ be tackled later --------------------------------------- There is a strong and understandable urge to divide the `prometheus` package into a number of sub-packages (like `registry`, `collectors`, `http`, `metrics`, …). However, to not run into a multitude of circular import chains, this would need to break every single existing usage of the library. (As just one example, if the ubiquitious `prometheus.MustRegister` (with more than 2,000 uses on GitHub alone) is kept in the `prometheus` package, but the other registry concerns go into a new `registry` package, then the `prometheus` package would import the `registry` package (to call the actual register method), while at the same time the `registry` package needs to import the `prometheus` package to access `Collector`, `Metric`, `Desc` and more. If we moved `MustRegister` into the `registry` package, thousands of code lines would have to be fixed (which would be easy if the world was a mono repo, but it is not). If we moved everything else the proposed registry package needs into packages of their own, we would break thousands of other code lines.) The main problem is really the top-level functions like `MustRegister`, `Handler`, …, which effectively pull everything into one package. Those functions are however very convenient for the easy and very frequent use-cases. This problem has to be revisited later. For now, I'm trying to keep the amount of exported names in the package as low as possible (e.g. I unexported expvarCollector in this commit because the NewExpvarCollector constructor is enough to export, and it is now consistent with other collectors, like the goCollector). Non-goals that won't be tackled anytime soon -------------------------------------------- Something that I have played with a lot is "streaming collection", i.e. allow an implementation of the `Registry` interface that collects metrics incrementally and serves them while doing so. As it has turned out, this has many many issues and makes the `Registry` interface very clunky. Eventually, I made the call that it is unlikely we will really implement streaming collection; and making the interface more clunky for something that might not even happen is really a big no-no. Note that the `Registry` interface only creates the in-memory representation of the metric family protobufs in one go. The serializaton onto the wire can still be handled in a streaming fashion (which hasn't been done so far, without causing any trouble, but might be done in the future without breaking any interfaces). What are the breaking changes? ============================== - Signatures of functions pushing to Pushgateway have changed to allow arbitrary grouping (which was planned for a long time anyway, and now that I had to work on the Push code anyway for the registry refurbishment, I finally did it, cf. https://github.com/prometheus/client_golang/issues/100). With the gained insight that pushing to the default registry is almost never the right thing, and now that we are breaking the Push call anyway, all the Push functions were moved to their own package, which cleans up the namespace and is more idiomatic (pushing Collectors is now literally done by `push.Collectors(...)`). - The registry is doing more consistency checks by default now. Past creators of inconsistent metrics could have masked the problem by not setting `EnableCollectChecks`. Those inconsistencies will now be detected. (But note that a "best effort" metrics collection is now possible with `HandlerOpts.ErrorHandling = ContinueOnError`.) - `EnableCollectChecks` is gone. The registry is now performing some of those checks anyway (see previous item), and a registry with all of those checks can now be created with `NewPedanticRegistry` (only used for testing). - `PanicOnCollectError` is gone. This behavior can now be configured when creating a custom HTTP handler.
2016-07-20 18:11:14 +03:00
Name: "test",
Help: "help",
},
[]string{"foo", "bar"},
)
Remove deprecated features that are esay to replace That's the "soft" part of the deprecation: Everything that has been marked deprecated in v0.8 or earlier and is straight-forward to replace by a non-deprecated way, is removed here. Sadly, this does not include the HTTP part. We first need to provide a replacement for HTTP instrumentation (as planned for v0.8) to then remove the deprecated parts in v0.9.
2016-10-25 17:41:39 +03:00
var err error
Adjust TestRegisterWithOrGet to the present Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-10-10 16:41:21 +03:00
if err = reg.Register(original); err != nil {
Create a public registry interface and separate out HTTP exposition General context and approch =========================== This is the first part of the long awaited wider refurbishment of `client_golang/prometheus/...`. After a lot of struggling, I decided to not go for one breaking big-bang, but cut things into smaller steps after all, mostly to keep the changes manageable and easy to review. I'm aiming for having the invasive breaking changes concentrated in as few steps as possible (ideally one). Some steps will not be breaking at all, but typically there will be breaking changes that only affect quite special cases so that 95+% of users will not be affected. This first step is an example for that, see details below. What's happening in this commit? ================================ This step is about finally creating an exported registry interface. This could not be done by simply export the existing internal implementation because the interface would be _way_ too fat. This commit introduces a qutie lean `Registry` interface (compared to the previous interval implementation). The functions that act on the default registry are retained (with very few exceptions) so that most use cases won't see a change. However, several of those are deprecated now to clean up the namespace in the future. The default registry is kept in the public variable `DefaultRegistry`. This follows the example of the http package in the standard library (cf. `http.DefaultServeMux`, `http.DefaultClient`) with the same implications. (This pattern is somewhat disputed within the Go community but I chose to go with the devil you know instead of creating something more complex or even disallowing any changes to the default registry. The current approach gives everybody the freedom to not touch DefaultRegistry or to do everything with a custom registry to play save.) Another important part in making the registry lean is the extraction of the HTTP exposition, which also allows for customization of the HTTP exposition. Note that the separation of metric collection and exposition has the side effect that managing the MetricFamily and Metric protobuf objects in a free-list or pool isn't really feasible anymore. By now (with better GC in more recent Go versions), the returns were anyway dimisishing. To be effective at all, scrapes had to happen more often than GC cycles, and even then most elements of the protobufs (everything excetp the MetricFamily and Metric structs themselves) would still cause allocation churn. In a future breaking change, the signature of the Write method in the Metric interface will be adjusted accordingly. In this commit, avoiding breakage is more important. The following issues are fixed by this commit (some solved "on the fly" now that I was touching the code anyway and it would have been stupid to port the bugs): https://github.com/prometheus/client_golang/issues/46 https://github.com/prometheus/client_golang/issues/100 https://github.com/prometheus/client_golang/issues/170 https://github.com/prometheus/client_golang/issues/205 Documentation including examples have been amended as required. What future changes does this commit enable? ============================================ The following items are not yet implemented, but this commit opens the possibility of implementing these independently. - The separation of the HTTP exposition allows the implementation of other exposition methods based on the Registry interface, as known from other Prometheus client libraries, e.g. sending the metrics to Graphite. Cf. https://github.com/prometheus/client_golang/issues/197 - The public `Registry` interface allows the implementation of convenience tools for testing metrics collection. Those tools can inspect the collected MetricFamily protobufs and compare them to expectation. Also, tests can use their own testing instance of a registry. Cf. https://github.com/prometheus/client_golang/issues/58 Notable non-goals of this commit ================================ Non-goals that will be tackled later ------------------------------------ The following two issues are quite closely connected to the changes in this commit but the line has been drawn deliberately to address them in later steps of the refurbishment: - `InstrumentHandler` has many known problems. The plan is to create a saner way to conveniently intrument HTTP handlers and remove the old `InstrumentHandler` altogether. To keep breakage low for now, even the default handler to expose metrics is still using the old `InstrumentHandler`. This leads to weird naming inconsistencies but I have deemed it better to not break the world right now but do it in the change that provides better ways of instrumenting HTTP handlers. Cf. https://github.com/prometheus/client_golang/issues/200 - There is work underway to make the whole handling of metric descriptors (`Desc`) more intuitive and transparent for the user (including an ability for less strict checking, cf. https://github.com/prometheus/client_golang/issues/47). That's quite invasive from the perspective of the internal code, namely the registry. I deliberately kept those changes out of this commit. - While this commit adds new external dependency, the effort to vendor anything within the library that is not visible in any exported types will have to be done later. Non-goals that _might_ be tackled later --------------------------------------- There is a strong and understandable urge to divide the `prometheus` package into a number of sub-packages (like `registry`, `collectors`, `http`, `metrics`, …). However, to not run into a multitude of circular import chains, this would need to break every single existing usage of the library. (As just one example, if the ubiquitious `prometheus.MustRegister` (with more than 2,000 uses on GitHub alone) is kept in the `prometheus` package, but the other registry concerns go into a new `registry` package, then the `prometheus` package would import the `registry` package (to call the actual register method), while at the same time the `registry` package needs to import the `prometheus` package to access `Collector`, `Metric`, `Desc` and more. If we moved `MustRegister` into the `registry` package, thousands of code lines would have to be fixed (which would be easy if the world was a mono repo, but it is not). If we moved everything else the proposed registry package needs into packages of their own, we would break thousands of other code lines.) The main problem is really the top-level functions like `MustRegister`, `Handler`, …, which effectively pull everything into one package. Those functions are however very convenient for the easy and very frequent use-cases. This problem has to be revisited later. For now, I'm trying to keep the amount of exported names in the package as low as possible (e.g. I unexported expvarCollector in this commit because the NewExpvarCollector constructor is enough to export, and it is now consistent with other collectors, like the goCollector). Non-goals that won't be tackled anytime soon -------------------------------------------- Something that I have played with a lot is "streaming collection", i.e. allow an implementation of the `Registry` interface that collects metrics incrementally and serves them while doing so. As it has turned out, this has many many issues and makes the `Registry` interface very clunky. Eventually, I made the call that it is unlikely we will really implement streaming collection; and making the interface more clunky for something that might not even happen is really a big no-no. Note that the `Registry` interface only creates the in-memory representation of the metric family protobufs in one go. The serializaton onto the wire can still be handled in a streaming fashion (which hasn't been done so far, without causing any trouble, but might be done in the future without breaking any interfaces). What are the breaking changes? ============================== - Signatures of functions pushing to Pushgateway have changed to allow arbitrary grouping (which was planned for a long time anyway, and now that I had to work on the Push code anyway for the registry refurbishment, I finally did it, cf. https://github.com/prometheus/client_golang/issues/100). With the gained insight that pushing to the default registry is almost never the right thing, and now that we are breaking the Push call anyway, all the Push functions were moved to their own package, which cleans up the namespace and is more idiomatic (pushing Collectors is now literally done by `push.Collectors(...)`). - The registry is doing more consistency checks by default now. Past creators of inconsistent metrics could have masked the problem by not setting `EnableCollectChecks`. Those inconsistencies will now be detected. (But note that a "best effort" metrics collection is now possible with `HandlerOpts.ErrorHandling = ContinueOnError`.) - `EnableCollectChecks` is gone. The registry is now performing some of those checks anyway (see previous item), and a registry with all of those checks can now be created with `NewPedanticRegistry` (only used for testing). - `PanicOnCollectError` is gone. This behavior can now be configured when creating a custom HTTP handler.
2016-07-20 18:11:14 +03:00
t.Fatal(err)
}
Adjust TestRegisterWithOrGet to the present Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-10-10 16:41:21 +03:00
if err = reg.Register(equalButNotSame); err == nil {
t.Fatal("expected error when registering equal collector")
Create a public registry interface and separate out HTTP exposition General context and approch =========================== This is the first part of the long awaited wider refurbishment of `client_golang/prometheus/...`. After a lot of struggling, I decided to not go for one breaking big-bang, but cut things into smaller steps after all, mostly to keep the changes manageable and easy to review. I'm aiming for having the invasive breaking changes concentrated in as few steps as possible (ideally one). Some steps will not be breaking at all, but typically there will be breaking changes that only affect quite special cases so that 95+% of users will not be affected. This first step is an example for that, see details below. What's happening in this commit? ================================ This step is about finally creating an exported registry interface. This could not be done by simply export the existing internal implementation because the interface would be _way_ too fat. This commit introduces a qutie lean `Registry` interface (compared to the previous interval implementation). The functions that act on the default registry are retained (with very few exceptions) so that most use cases won't see a change. However, several of those are deprecated now to clean up the namespace in the future. The default registry is kept in the public variable `DefaultRegistry`. This follows the example of the http package in the standard library (cf. `http.DefaultServeMux`, `http.DefaultClient`) with the same implications. (This pattern is somewhat disputed within the Go community but I chose to go with the devil you know instead of creating something more complex or even disallowing any changes to the default registry. The current approach gives everybody the freedom to not touch DefaultRegistry or to do everything with a custom registry to play save.) Another important part in making the registry lean is the extraction of the HTTP exposition, which also allows for customization of the HTTP exposition. Note that the separation of metric collection and exposition has the side effect that managing the MetricFamily and Metric protobuf objects in a free-list or pool isn't really feasible anymore. By now (with better GC in more recent Go versions), the returns were anyway dimisishing. To be effective at all, scrapes had to happen more often than GC cycles, and even then most elements of the protobufs (everything excetp the MetricFamily and Metric structs themselves) would still cause allocation churn. In a future breaking change, the signature of the Write method in the Metric interface will be adjusted accordingly. In this commit, avoiding breakage is more important. The following issues are fixed by this commit (some solved "on the fly" now that I was touching the code anyway and it would have been stupid to port the bugs): https://github.com/prometheus/client_golang/issues/46 https://github.com/prometheus/client_golang/issues/100 https://github.com/prometheus/client_golang/issues/170 https://github.com/prometheus/client_golang/issues/205 Documentation including examples have been amended as required. What future changes does this commit enable? ============================================ The following items are not yet implemented, but this commit opens the possibility of implementing these independently. - The separation of the HTTP exposition allows the implementation of other exposition methods based on the Registry interface, as known from other Prometheus client libraries, e.g. sending the metrics to Graphite. Cf. https://github.com/prometheus/client_golang/issues/197 - The public `Registry` interface allows the implementation of convenience tools for testing metrics collection. Those tools can inspect the collected MetricFamily protobufs and compare them to expectation. Also, tests can use their own testing instance of a registry. Cf. https://github.com/prometheus/client_golang/issues/58 Notable non-goals of this commit ================================ Non-goals that will be tackled later ------------------------------------ The following two issues are quite closely connected to the changes in this commit but the line has been drawn deliberately to address them in later steps of the refurbishment: - `InstrumentHandler` has many known problems. The plan is to create a saner way to conveniently intrument HTTP handlers and remove the old `InstrumentHandler` altogether. To keep breakage low for now, even the default handler to expose metrics is still using the old `InstrumentHandler`. This leads to weird naming inconsistencies but I have deemed it better to not break the world right now but do it in the change that provides better ways of instrumenting HTTP handlers. Cf. https://github.com/prometheus/client_golang/issues/200 - There is work underway to make the whole handling of metric descriptors (`Desc`) more intuitive and transparent for the user (including an ability for less strict checking, cf. https://github.com/prometheus/client_golang/issues/47). That's quite invasive from the perspective of the internal code, namely the registry. I deliberately kept those changes out of this commit. - While this commit adds new external dependency, the effort to vendor anything within the library that is not visible in any exported types will have to be done later. Non-goals that _might_ be tackled later --------------------------------------- There is a strong and understandable urge to divide the `prometheus` package into a number of sub-packages (like `registry`, `collectors`, `http`, `metrics`, …). However, to not run into a multitude of circular import chains, this would need to break every single existing usage of the library. (As just one example, if the ubiquitious `prometheus.MustRegister` (with more than 2,000 uses on GitHub alone) is kept in the `prometheus` package, but the other registry concerns go into a new `registry` package, then the `prometheus` package would import the `registry` package (to call the actual register method), while at the same time the `registry` package needs to import the `prometheus` package to access `Collector`, `Metric`, `Desc` and more. If we moved `MustRegister` into the `registry` package, thousands of code lines would have to be fixed (which would be easy if the world was a mono repo, but it is not). If we moved everything else the proposed registry package needs into packages of their own, we would break thousands of other code lines.) The main problem is really the top-level functions like `MustRegister`, `Handler`, …, which effectively pull everything into one package. Those functions are however very convenient for the easy and very frequent use-cases. This problem has to be revisited later. For now, I'm trying to keep the amount of exported names in the package as low as possible (e.g. I unexported expvarCollector in this commit because the NewExpvarCollector constructor is enough to export, and it is now consistent with other collectors, like the goCollector). Non-goals that won't be tackled anytime soon -------------------------------------------- Something that I have played with a lot is "streaming collection", i.e. allow an implementation of the `Registry` interface that collects metrics incrementally and serves them while doing so. As it has turned out, this has many many issues and makes the `Registry` interface very clunky. Eventually, I made the call that it is unlikely we will really implement streaming collection; and making the interface more clunky for something that might not even happen is really a big no-no. Note that the `Registry` interface only creates the in-memory representation of the metric family protobufs in one go. The serializaton onto the wire can still be handled in a streaming fashion (which hasn't been done so far, without causing any trouble, but might be done in the future without breaking any interfaces). What are the breaking changes? ============================== - Signatures of functions pushing to Pushgateway have changed to allow arbitrary grouping (which was planned for a long time anyway, and now that I had to work on the Push code anyway for the registry refurbishment, I finally did it, cf. https://github.com/prometheus/client_golang/issues/100). With the gained insight that pushing to the default registry is almost never the right thing, and now that we are breaking the Push call anyway, all the Push functions were moved to their own package, which cleans up the namespace and is more idiomatic (pushing Collectors is now literally done by `push.Collectors(...)`). - The registry is doing more consistency checks by default now. Past creators of inconsistent metrics could have masked the problem by not setting `EnableCollectChecks`. Those inconsistencies will now be detected. (But note that a "best effort" metrics collection is now possible with `HandlerOpts.ErrorHandling = ContinueOnError`.) - `EnableCollectChecks` is gone. The registry is now performing some of those checks anyway (see previous item), and a registry with all of those checks can now be created with `NewPedanticRegistry` (only used for testing). - `PanicOnCollectError` is gone. This behavior can now be configured when creating a custom HTTP handler.
2016-07-20 18:11:14 +03:00
}
Remove deprecated features that are esay to replace That's the "soft" part of the deprecation: Everything that has been marked deprecated in v0.8 or earlier and is straight-forward to replace by a non-deprecated way, is removed here. Sadly, this does not include the HTTP part. We first need to provide a replacement for HTTP instrumentation (as planned for v0.8) to then remove the deprecated parts in v0.9.
2016-10-25 17:41:39 +03:00
if are, ok := err.(prometheus.AlreadyRegisteredError); ok {
if are.ExistingCollector != original {
t.Error("expected original collector but got something else")
}
if are.ExistingCollector == equalButNotSame {
t.Error("expected original callector but got new one")
}
} else {
t.Error("unexpected error:", err)
Create a public registry interface and separate out HTTP exposition General context and approch =========================== This is the first part of the long awaited wider refurbishment of `client_golang/prometheus/...`. After a lot of struggling, I decided to not go for one breaking big-bang, but cut things into smaller steps after all, mostly to keep the changes manageable and easy to review. I'm aiming for having the invasive breaking changes concentrated in as few steps as possible (ideally one). Some steps will not be breaking at all, but typically there will be breaking changes that only affect quite special cases so that 95+% of users will not be affected. This first step is an example for that, see details below. What's happening in this commit? ================================ This step is about finally creating an exported registry interface. This could not be done by simply export the existing internal implementation because the interface would be _way_ too fat. This commit introduces a qutie lean `Registry` interface (compared to the previous interval implementation). The functions that act on the default registry are retained (with very few exceptions) so that most use cases won't see a change. However, several of those are deprecated now to clean up the namespace in the future. The default registry is kept in the public variable `DefaultRegistry`. This follows the example of the http package in the standard library (cf. `http.DefaultServeMux`, `http.DefaultClient`) with the same implications. (This pattern is somewhat disputed within the Go community but I chose to go with the devil you know instead of creating something more complex or even disallowing any changes to the default registry. The current approach gives everybody the freedom to not touch DefaultRegistry or to do everything with a custom registry to play save.) Another important part in making the registry lean is the extraction of the HTTP exposition, which also allows for customization of the HTTP exposition. Note that the separation of metric collection and exposition has the side effect that managing the MetricFamily and Metric protobuf objects in a free-list or pool isn't really feasible anymore. By now (with better GC in more recent Go versions), the returns were anyway dimisishing. To be effective at all, scrapes had to happen more often than GC cycles, and even then most elements of the protobufs (everything excetp the MetricFamily and Metric structs themselves) would still cause allocation churn. In a future breaking change, the signature of the Write method in the Metric interface will be adjusted accordingly. In this commit, avoiding breakage is more important. The following issues are fixed by this commit (some solved "on the fly" now that I was touching the code anyway and it would have been stupid to port the bugs): https://github.com/prometheus/client_golang/issues/46 https://github.com/prometheus/client_golang/issues/100 https://github.com/prometheus/client_golang/issues/170 https://github.com/prometheus/client_golang/issues/205 Documentation including examples have been amended as required. What future changes does this commit enable? ============================================ The following items are not yet implemented, but this commit opens the possibility of implementing these independently. - The separation of the HTTP exposition allows the implementation of other exposition methods based on the Registry interface, as known from other Prometheus client libraries, e.g. sending the metrics to Graphite. Cf. https://github.com/prometheus/client_golang/issues/197 - The public `Registry` interface allows the implementation of convenience tools for testing metrics collection. Those tools can inspect the collected MetricFamily protobufs and compare them to expectation. Also, tests can use their own testing instance of a registry. Cf. https://github.com/prometheus/client_golang/issues/58 Notable non-goals of this commit ================================ Non-goals that will be tackled later ------------------------------------ The following two issues are quite closely connected to the changes in this commit but the line has been drawn deliberately to address them in later steps of the refurbishment: - `InstrumentHandler` has many known problems. The plan is to create a saner way to conveniently intrument HTTP handlers and remove the old `InstrumentHandler` altogether. To keep breakage low for now, even the default handler to expose metrics is still using the old `InstrumentHandler`. This leads to weird naming inconsistencies but I have deemed it better to not break the world right now but do it in the change that provides better ways of instrumenting HTTP handlers. Cf. https://github.com/prometheus/client_golang/issues/200 - There is work underway to make the whole handling of metric descriptors (`Desc`) more intuitive and transparent for the user (including an ability for less strict checking, cf. https://github.com/prometheus/client_golang/issues/47). That's quite invasive from the perspective of the internal code, namely the registry. I deliberately kept those changes out of this commit. - While this commit adds new external dependency, the effort to vendor anything within the library that is not visible in any exported types will have to be done later. Non-goals that _might_ be tackled later --------------------------------------- There is a strong and understandable urge to divide the `prometheus` package into a number of sub-packages (like `registry`, `collectors`, `http`, `metrics`, …). However, to not run into a multitude of circular import chains, this would need to break every single existing usage of the library. (As just one example, if the ubiquitious `prometheus.MustRegister` (with more than 2,000 uses on GitHub alone) is kept in the `prometheus` package, but the other registry concerns go into a new `registry` package, then the `prometheus` package would import the `registry` package (to call the actual register method), while at the same time the `registry` package needs to import the `prometheus` package to access `Collector`, `Metric`, `Desc` and more. If we moved `MustRegister` into the `registry` package, thousands of code lines would have to be fixed (which would be easy if the world was a mono repo, but it is not). If we moved everything else the proposed registry package needs into packages of their own, we would break thousands of other code lines.) The main problem is really the top-level functions like `MustRegister`, `Handler`, …, which effectively pull everything into one package. Those functions are however very convenient for the easy and very frequent use-cases. This problem has to be revisited later. For now, I'm trying to keep the amount of exported names in the package as low as possible (e.g. I unexported expvarCollector in this commit because the NewExpvarCollector constructor is enough to export, and it is now consistent with other collectors, like the goCollector). Non-goals that won't be tackled anytime soon -------------------------------------------- Something that I have played with a lot is "streaming collection", i.e. allow an implementation of the `Registry` interface that collects metrics incrementally and serves them while doing so. As it has turned out, this has many many issues and makes the `Registry` interface very clunky. Eventually, I made the call that it is unlikely we will really implement streaming collection; and making the interface more clunky for something that might not even happen is really a big no-no. Note that the `Registry` interface only creates the in-memory representation of the metric family protobufs in one go. The serializaton onto the wire can still be handled in a streaming fashion (which hasn't been done so far, without causing any trouble, but might be done in the future without breaking any interfaces). What are the breaking changes? ============================== - Signatures of functions pushing to Pushgateway have changed to allow arbitrary grouping (which was planned for a long time anyway, and now that I had to work on the Push code anyway for the registry refurbishment, I finally did it, cf. https://github.com/prometheus/client_golang/issues/100). With the gained insight that pushing to the default registry is almost never the right thing, and now that we are breaking the Push call anyway, all the Push functions were moved to their own package, which cleans up the namespace and is more idiomatic (pushing Collectors is now literally done by `push.Collectors(...)`). - The registry is doing more consistency checks by default now. Past creators of inconsistent metrics could have masked the problem by not setting `EnableCollectChecks`. Those inconsistencies will now be detected. (But note that a "best effort" metrics collection is now possible with `HandlerOpts.ErrorHandling = ContinueOnError`.) - `EnableCollectChecks` is gone. The registry is now performing some of those checks anyway (see previous item), and a registry with all of those checks can now be created with `NewPedanticRegistry` (only used for testing). - `PanicOnCollectError` is gone. This behavior can now be configured when creating a custom HTTP handler.
2016-07-20 18:11:14 +03:00
}
}
Add a concurrent end-to-end test for observe-register-gather This is an attempt to expose https://github.com/istio/istio/issues/8906 . The failure to do so makes me believe the error is either already fixed in current client_golang, or something weird I haven't spotted yet is happening in the istio code. Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-10-10 17:59:24 +03:00
// TestHistogramVecRegisterGatherConcurrency is an end-to-end test that
// concurrently calls Observe on random elements of a HistogramVec while the
// same HistogramVec is registered concurrently and the Gather method of the
// registry is called concurrently.
func TestHistogramVecRegisterGatherConcurrency(t *testing.T) {
var (
reg = prometheus.NewPedanticRegistry()
hv = prometheus.NewHistogramVec(
prometheus.HistogramOpts{
Name: "test_histogram",
Help: "This helps testing.",
ConstLabels: prometheus.Labels{"foo": "bar"},
},
[]string{"one", "two", "three"},
)
labelValues = []string{"a", "b", "c", "alpha", "beta", "gamma", "aleph", "beth", "gimel"}
quit = make(chan struct{})
wg sync.WaitGroup
)
observe := func() {
defer wg.Done()
for {
select {
case <-quit:
return
default:
obs := rand.NormFloat64()*.1 + .2
hv.WithLabelValues(
labelValues[rand.Intn(len(labelValues))],
labelValues[rand.Intn(len(labelValues))],
labelValues[rand.Intn(len(labelValues))],
).Observe(obs)
}
}
}
register := func() {
defer wg.Done()
for {
select {
case <-quit:
return
default:
if err := reg.Register(hv); err != nil {
if _, ok := err.(prometheus.AlreadyRegisteredError); !ok {
t.Error("Registering failed:", err)
}
}
time.Sleep(7 * time.Millisecond)
}
}
}
gather := func() {
defer wg.Done()
for {
select {
case <-quit:
return
default:
if g, err := reg.Gather(); err != nil {
t.Error("Gathering failed:", err)
} else {
if len(g) == 0 {
continue
}
if len(g) != 1 {
t.Error("Gathered unexpected number of metric families:", len(g))
}
if len(g[0].Metric[0].Label) != 4 {
t.Error("Gathered unexpected number of label pairs:", len(g[0].Metric[0].Label))
}
}
time.Sleep(4 * time.Millisecond)
}
}
}
wg.Add(10)
go observe()
go observe()
go register()
go observe()
go gather()
go observe()
go register()
go observe()
go gather()
go observe()
time.Sleep(time.Second)
close(quit)
wg.Wait()
}