Commit Graph

81 Commits

Author SHA1 Message Date
beorn7 ff0177896a Be more precise about concurrency requirements
Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-09-29 10:47:28 +02:00
beorn7 7eb5e8a08a Drain the desc channel after registering
This avoids leaking goroutines.

Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-09-29 10:44:19 +02:00
beorn7 84d7aa0cd9 Add wrapping of Registerers with labels and prefix
Essentially middleware for Registerers!

Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-09-12 15:34:07 +02:00
beorn7 773f502723 Rework process collector
This unifies both constructors in one with an options argument.

The options argument allows to switch on error reporting, as discussed
in #219.

The change of the contructor signature is breaking, but only mildly
so. Plus, the process collector is rarely used explicitly. I used
Sourcegraph to search for public usages, with the following results:

- 2 occurrences of NewProcessCollectorPIDFn, once in @discordianfish's
  glimpse, once in @fabxc's etcd_exporter (deprecated anyway). Both
  are Prom veterans and will simply do the one line change if needed.
- 8 occurrences of NewProcessCollector, of which 7 are of the form
    NewProcessCollector(os.Getpid(), "")
  Thus, it's a very easy change, which I even hinted at in the doc
  comment.

Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-09-07 12:09:26 +02:00
beorn7 da330f4281 Un-export prometheus.LabelPairSorter
The only known external usage of it was in prometheus/pushgateway,
where it was removed by
https://github.com/prometheus/pushgateway/pull/200 .

Originally, the expectation was that users would implement the Metric
interface now and then. As we know now, neither it is happening, nor
would it make a lot of sense. (Users implement the Collector interface
instead.) By now, LabelPairSorter is essentially noise in the already
quite cluttered namespace in the prometheus package.

Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-09-03 16:20:55 +02:00
beorn7 7be86f93c1 Create an internal package
This is for types we don't want to export but which are used in
different packages within client_golang.

Currently, that's only NormalizeMetricFamilies (used in the prometheus
package and in the testutil package). More to be added as needed.

Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-09-03 00:18:11 +02:00
beorn7 4572e24546 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 16:29:17 +02:00
beorn7 767a0218df 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 14:14:39 +02:00
beorn7 ad1b9f7754 Introduce unchecked Collectors
Fixes #47 . See there for more detailed discussion.

Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-07-09 14:33:18 +02:00
beorn7 f6b1978ed4 Use stricter wording for Gather returning a non-nil error
Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-06-07 14:35:06 +02:00
beorn7 c06fb788be Relax consistency checks during gathering
Also, clarify in the doc comment.

Previously, the assumption was that inconsistent label dimensions are
violating the exposition format spec. However, especially with the
knowledge that OpenMetrics will explicitly allow inconsistent label
dimensions in expositions, we should allow it in client_golang, too.

Note that registration with proper Descs provided will still check for
consistont label dimensions. However, you can "cheat" with custom
Collectors as you can collect metrics that don't follew the provided
Desc (this will be made more explicit and less cheaty once #47 is
fixed). You can also create expositions with inconsistent label
dimensions by merging Gatherers with the Gatherers slice type. (The
latter is used in the Pushgateway.)

Effectively, normal direct instrumentation will always have consistent
label dimensions in this way, but you can cover special use cases with
custom collectors or merging of different Gatherers.

Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-06-06 19:30:53 +02:00
beorn7 1b56b5c497 Be more robust about nil pointers in protobuf
While not strictly correct, it can easily happen that proto messages
are created that use nil pointers instead of pointers in empty strings
to denote an empty string.

Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-05-29 17:57:33 +02:00
beorn7 d66ac8f863 Document the stop-the-world implications of the Go collector
Signed-off-by: beorn7 <beorn@soundcloud.com>
2018-05-19 21:14:04 +02:00
Karsten Weiss 958ea82988 Fix typos
Signed-off-by: Karsten Weiss <knweiss@gmail.com>
2018-04-13 23:23:52 +02:00
beorn7 154bb450e4 Document that the process collector only works on Linux 2018-02-08 14:17:54 +01:00
beorn7 4957f7bba4 Add a safety goroutine budget
This makes sure we don't spin up a possibly infinite number of
goroutines in `Gather`, which could theoretically happen with unlucky
scheduling.
2018-01-31 14:49:15 +01:00
beorn7 e04451f4be Create goroutines adaptively during metrics gathering 2018-01-26 19:58:07 +01:00
Brian Brazil 9f5d03c01f Fix typo in comment 2017-10-04 17:44:49 +01:00
Marco Jantke 0b8aef084e implement review feedback 2017-08-25 14:51:19 +02:00
Marco Jantke 685a3c90d4 fail Gather'ing when label value is not utf8 2017-08-20 00:10:32 +02:00
Maxime Song 90494ea7b1 fix typo in comments
Signed-off-by: Maxime Song <me@cppdo.com>
2017-07-07 23:28:24 +08:00
Julius Volz 69bb387064 Fix typo 2017-02-23 10:28:41 +01:00
beorn7 2fee50beaa 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 18:28:15 +02:00
beorn7 c9325a4a67 Add goreport card and remove warnings where feasible 2016-09-16 19:59:04 +02:00
beorn7 a6321dd0b1 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-12 21:34:17 +02:00
beorn7 1dc03a72f6 Replace hashicorp/go-multierror by own implementation
The own implementation is much easier as it only has to serve our one
use case.
2016-08-04 16:03:06 +02:00
beorn7 f0c45acc50 Rename Deliver into Gather 2016-08-04 15:26:27 +02:00
beorn7 f9c977b1d6 Doc: Make the AlreadyRegisteredError example a real example 2016-08-04 11:41:02 +02:00
beorn7 2e66d12fe5 Act on DefaultRegisterer and DefaultDeliverer where possible
Both point to the DefaultRegistry anyway, but users can now replace it
with interfaces rather than only other Registry instances.
2016-08-03 12:50:39 +02:00
beorn7 e5c6302150 Fix a number of doc comments and similar nits 2016-08-03 12:23:37 +02:00
beorn7 9c3fe750dd Expose the registry implementation and add two interfaces.
Registry is now a struct, which implements two interfaces, Registrerer
and Deliverer. The latter is particularly important as it is now the
argument type for pushes and HTTP handler construction (i.e. it is
easy to implement a custom Deliverer for testing or other
purposes). The Registerer interface is not used as a parameter type
but can (and should) be used by users of custom registries so that
they can easily do things like mocking it out for testing purposes.

With the broken up interfaces, adding MustRegister to the interface is
not such a big deal anymore (interface is still small). And since
setting the injection hook is such a rare thing to happen, it is
acceptable to not have it in any of the interfaces.

The renaming from `Collect` to `Deliver` was done to avoid confusion
with Collectors. (The registry _collects_ from the Collectors, and
then _delivers_ to the exposition mechanism.)
2016-08-03 01:02:34 +02:00
beorn7 cf7e1caf17 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-08-02 18:46:22 +02:00
Uwe Dauernheim c1e8a41238 Fix typo in doc string 2016-08-01 23:14:45 +02:00
Andrew Stuart e63e6e3db7
Extend MustRegister function to accept variadic args 2016-07-11 15:04:23 -07:00
beorn7 f6b16ed256 Document the issues of InstrumentHandler
Obvious next step: Fix those issues.
2016-05-15 17:59:51 +02:00
Michael Stapelberg c1370d07ca Strip trailing / from push URL.
This circumvents the following problem:
• The prometheus client library appends “/metrics/…” to the pushURL.
• When pushURL ends in a trailing slash, the URL becomes e.g.
  http://pushgateway.example.com:9091//metrics/…
• The pushgateway will reply with an HTTP 307 status code
  (temporary redirect).
• While Go’s net/http client follows redirects by default, it will only
  follow HTTP 302 (Found) and HTTP 303 (See Other) redirects for PUT and
  POST requests, which the prometheus client library uses.

Hence, when calling e.g.:

    prometheus.Push("foo", "bar", "http://pushgateway.example.com:9091/")

…your metrics would not actually get pushed successfully, but rather
you’d see the error message:

    2015/11/26 10:59:49 main.go:209: unexpected status code 307 while pushing to http://push...
2015-11-26 19:16:53 +01:00
Harmen 5d4fdca1a5 use local fnv hash everywhere 2015-11-12 14:07:23 +01:00
David Nesting b0bd184e74 Simplify metricSorter timestamp comparison and improve comment 2015-11-10 09:37:58 -05:00
David Nesting 544f65f7fc metricSorter stops relying on time.Now and respects nil timestamps 2015-11-09 17:14:07 -05:00
David Nesting 5fb1b89678 Make metric sort stable and sort by timestamp 2015-11-09 16:55:26 -05:00
beorn7 90ddfa1c1e Move from client_golang/text to common/expfmt 2015-09-17 13:06:43 +02:00
Fabian Reinartz f2de0f589a Remove client_golang/model als direct dependency 2015-08-23 13:51:32 +02:00
beorn7 59f2c7d8b0 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-09 12:03:07 +02:00
beorn7 63acb006f7 Purge another trace of ext -> pbutil. 2015-04-07 15:19:47 +02:00
beorn7 4ab527fc50 Fix merge conflicts. 2015-03-16 15:15:02 +01:00
beorn7 f3cda15667 Add functions to push individual collectors to a Pushgateway.
Move all Pushgateway related top-level functions to push.go.
2015-03-15 19:29:57 +01:00
beorn7 a762e0612e 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 16:34:31 +01:00
Julius Volz 738b69e61a Use non-rewritten Godep imports. 2015-02-27 16:49:40 +01:00
Julius Volz 169c8a68e1 Use godep with import rewriting for vendoring.
The new vendoring was produced by running:

    godep save -r ./examples/... ./prometheus/... ./text/... ./model/... ./extraction/...

Two things to note:

- "extraction/processor0_0_{1,2}_test.go" imported a package from
  "github.com/prometheus/prometheus", all for just one tiny testing
  function. To not have to deal with a circular vendoring dependency, I
  simply replaced the usage of the function by some in-line logic.

- godep grouped the rewritten imports slightly differently for some
  reason, but at least the standard library imports are still in a
  separate section. Not sure if it's worth manually keeping our old
  import grouping scheme or if we should simply use that godep-generated
  one.
2015-02-26 00:47:03 +01:00
Peter Bourgon 69c8dc87e9 Fix for Histogram in registry.writePB 2015-02-20 19:08:36 +01:00