2015-02-02 17:14:36 +03:00
|
|
|
// Copyright 2014 The Prometheus Authors
|
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
|
2013-01-19 17:48:30 +04:00
|
|
|
//
|
2014-05-07 22:08:33 +04:00
|
|
|
// 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.
|
2012-05-24 22:02:44 +04:00
|
|
|
|
2013-04-03 20:33:32 +04:00
|
|
|
package prometheus
|
2012-05-24 22:02:44 +04:00
|
|
|
|
2015-11-27 17:56:42 +03:00
|
|
|
import dto "github.com/prometheus/client_model/go"
|
2013-04-19 16:11:01 +04:00
|
|
|
|
2015-08-23 14:51:32 +03:00
|
|
|
const separatorByte byte = 255
|
|
|
|
|
2014-05-07 22:08:33 +04:00
|
|
|
// A Metric models a single sample value with its meta data being exported to
|
|
|
|
// Prometheus. Implementers of Metric in this package inclued Gauge, Counter,
|
|
|
|
// Untyped, and Summary. Users can implement their own Metric types, but that
|
|
|
|
// should be rarely needed. See the example for SelfCollector, which is also an
|
|
|
|
// example for a user-implemented Metric.
|
2012-05-24 22:02:44 +04:00
|
|
|
type Metric interface {
|
2014-05-07 22:08:33 +04:00
|
|
|
// Desc returns the descriptor for the Metric. This method idempotently
|
|
|
|
// returns the same descriptor throughout the lifetime of the
|
Allow error reporting during metrics collection and simplify Register().
Both are interface changes I want to get in before public
announcement. They only break rare usage cases, and are always easy to
fix, but still we want to avoid breaking changes after a wider
announcement of the project.
The change of Register() simply removes the return of the Collector,
which nobody was using in practice. It was just bloating the call
syntax. Note that this is different from RegisterOrGet(), which is
used at various occasions where you want to register something that
might or might not be registered already, but if it is, you want the
previously registered Collector back (because that's the relevant
one).
WRT error reporting: I first tried the obvious way of letting the
Collector methods Describe() and Collect() return error. However, I
had to conclude that that bloated _many_ calls and their handling in
very obnoxious ways. On the other hand, the case where you actually
want to report errors during registration or collection is very
rare. Hence, this approach has the wrong trade-off. The approach taken
here might at first appear clunky but is in practice quite handy,
mostly because there is almost no change for the "normal" case of "no
special error handling", but also because it plays well with the way
descriptors and metrics are handled (via channels).
Explaining the approach in more detail:
- During registration / describe: Error handling was actually already
in place (for invalid descriptors, which carry an error anyway). I
only added a convenience function to create an invalid descriptor
with a given error on purpose.
- Metrics are now treated in a similar way. The Write method returns
an error now (the only change in interface). An "invalid metric" is
provided that can be sent via the channel to signal that that metric
could not be collected. It alse transports an error.
NON-GOALS OF THIS COMMIT:
This is NOT yet the major improvement of the whole registry part,
where we want a public Registry interface and plenty of modular
configurations (for error handling, various auto-metrics, http
instrumentation, testing, ...). However, we can do that whole thing
without breaking existing interfaces. For now (which is a significant
issue) any error during collection will either cause a 500 HTTP
response or a panic (depending on registry config). Later, we
definitely want to have a possibility to skip (and only report
somehow) non-collectible metrics instead of aborting the whole scrape.
2015-01-12 21:16:09 +03:00
|
|
|
// Metric. The returned descriptor is immutable by contract. A Metric
|
|
|
|
// unable to describe itself must return an invalid descriptor (created
|
|
|
|
// with NewInvalidDesc).
|
2014-05-07 22:08:33 +04:00
|
|
|
Desc() *Desc
|
|
|
|
// Write encodes the Metric into a "Metric" Protocol Buffer data
|
|
|
|
// transmission object.
|
|
|
|
//
|
|
|
|
// Implementers of custom Metric types must observe concurrency safety
|
|
|
|
// as reads of this metric may occur at any time, and any blocking
|
|
|
|
// occurs at the expense of total performance of rendering all
|
|
|
|
// registered metrics. Ideally Metric implementations should support
|
|
|
|
// concurrent readers.
|
|
|
|
//
|
|
|
|
// The Prometheus client library attempts to minimize memory allocations
|
|
|
|
// and will provide a pre-existing reset dto.Metric pointer. Prometheus
|
|
|
|
// may recycle the dto.Metric proto message, so Metric implementations
|
|
|
|
// should just populate the provided dto.Metric and then should not keep
|
|
|
|
// any reference to it.
|
|
|
|
//
|
|
|
|
// While populating dto.Metric, labels must be sorted lexicographically.
|
|
|
|
// (Implementers may find LabelPairSorter useful for that.)
|
Allow error reporting during metrics collection and simplify Register().
Both are interface changes I want to get in before public
announcement. They only break rare usage cases, and are always easy to
fix, but still we want to avoid breaking changes after a wider
announcement of the project.
The change of Register() simply removes the return of the Collector,
which nobody was using in practice. It was just bloating the call
syntax. Note that this is different from RegisterOrGet(), which is
used at various occasions where you want to register something that
might or might not be registered already, but if it is, you want the
previously registered Collector back (because that's the relevant
one).
WRT error reporting: I first tried the obvious way of letting the
Collector methods Describe() and Collect() return error. However, I
had to conclude that that bloated _many_ calls and their handling in
very obnoxious ways. On the other hand, the case where you actually
want to report errors during registration or collection is very
rare. Hence, this approach has the wrong trade-off. The approach taken
here might at first appear clunky but is in practice quite handy,
mostly because there is almost no change for the "normal" case of "no
special error handling", but also because it plays well with the way
descriptors and metrics are handled (via channels).
Explaining the approach in more detail:
- During registration / describe: Error handling was actually already
in place (for invalid descriptors, which carry an error anyway). I
only added a convenience function to create an invalid descriptor
with a given error on purpose.
- Metrics are now treated in a similar way. The Write method returns
an error now (the only change in interface). An "invalid metric" is
provided that can be sent via the channel to signal that that metric
could not be collected. It alse transports an error.
NON-GOALS OF THIS COMMIT:
This is NOT yet the major improvement of the whole registry part,
where we want a public Registry interface and plenty of modular
configurations (for error handling, various auto-metrics, http
instrumentation, testing, ...). However, we can do that whole thing
without breaking existing interfaces. For now (which is a significant
issue) any error during collection will either cause a 500 HTTP
response or a panic (depending on registry config). Later, we
definitely want to have a possibility to skip (and only report
somehow) non-collectible metrics instead of aborting the whole scrape.
2015-01-12 21:16:09 +03:00
|
|
|
Write(*dto.Metric) error
|
2014-05-07 22:08:33 +04:00
|
|
|
}
|
|
|
|
|
2015-11-27 17:56:42 +03:00
|
|
|
// MetricType is an enumeration of metric types. It deliberately mirrors the
|
|
|
|
// MetricType enum from the protobuf specification to avoid exposing protobuf
|
|
|
|
// references to the user of this package. (The protobuf parts could be
|
|
|
|
// internally vendored.)
|
|
|
|
type MetricType int
|
|
|
|
|
|
|
|
// Possible values for the MetricType enum.
|
|
|
|
const (
|
|
|
|
CounterMetric MetricType = iota
|
|
|
|
GaugeMetric
|
|
|
|
SummaryMetric
|
|
|
|
UntypedMetric
|
|
|
|
HistogramMetric
|
|
|
|
)
|
|
|
|
|
|
|
|
func (m MetricType) Valid() bool {
|
|
|
|
return m >= CounterMetric && m <= HistogramMetric
|
|
|
|
}
|
|
|
|
|
|
|
|
func (m MetricType) String() string {
|
|
|
|
switch m {
|
|
|
|
case CounterMetric:
|
|
|
|
return "COUNTER"
|
|
|
|
case GaugeMetric:
|
|
|
|
return "GAUGE"
|
|
|
|
case SummaryMetric:
|
|
|
|
return "SUMMARY"
|
|
|
|
case UntypedMetric:
|
|
|
|
return "UNTYPED"
|
|
|
|
case HistogramMetric:
|
|
|
|
return "HISTOGRAM"
|
|
|
|
default:
|
|
|
|
return "INVALID"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-05-07 22:08:33 +04:00
|
|
|
// Opts bundles the options for creating most Metric types. Each metric
|
|
|
|
// implementation XXX has its own XXXOpts type, but in most cases, it is just be
|
|
|
|
// an alias of this type (which might change when the requirement arises.)
|
|
|
|
//
|
|
|
|
// It is mandatory to set Name and Help to a non-empty string. All other fields
|
|
|
|
// are optional and can safely be left at their zero value.
|
|
|
|
type Opts struct {
|
|
|
|
// Namespace, Subsystem, and Name are components of the fully-qualified
|
|
|
|
// name of the Metric (created by joining these components with
|
|
|
|
// "_"). Only Name is mandatory, the others merely help structuring the
|
|
|
|
// name. Note that the fully-qualified name of the metric must be a
|
|
|
|
// valid Prometheus metric name.
|
|
|
|
Namespace string
|
|
|
|
Subsystem string
|
|
|
|
Name string
|
|
|
|
|
|
|
|
// Help provides information about this metric. Mandatory!
|
|
|
|
//
|
|
|
|
// Metrics with the same fully-qualified name must have the same Help
|
|
|
|
// string.
|
|
|
|
Help string
|
|
|
|
|
|
|
|
// ConstLabels are used to attach fixed labels to this metric. Metrics
|
|
|
|
// with the same fully-qualified name must have the same label names in
|
|
|
|
// their ConstLabels.
|
|
|
|
//
|
|
|
|
// Note that in most cases, labels have a value that varies during the
|
|
|
|
// lifetime of a process. Those labels are usually managed with a metric
|
|
|
|
// vector collector (like CounterVec, GaugeVec, UntypedVec). ConstLabels
|
|
|
|
// serve only special purposes. One is for the special case where the
|
|
|
|
// value of a label does not change during the lifetime of a process,
|
|
|
|
// e.g. if the revision of the running binary is put into a
|
|
|
|
// label. Another, more advanced purpose is if more than one Collector
|
|
|
|
// needs to collect Metrics with the same fully-qualified name. In that
|
|
|
|
// case, those Metrics must differ in the values of their
|
|
|
|
// ConstLabels. See the Collector examples.
|
|
|
|
//
|
|
|
|
// If the value of a label never changes (not even between binaries),
|
|
|
|
// that label most likely should not be a label at all (but part of the
|
|
|
|
// metric name).
|
|
|
|
ConstLabels Labels
|
|
|
|
}
|
|
|
|
|
|
|
|
// LabelPairSorter implements sort.Interface. It is used to sort a slice of
|
|
|
|
// dto.LabelPair pointers. This is useful for implementing the Write method of
|
|
|
|
// custom metrics.
|
|
|
|
type LabelPairSorter []*dto.LabelPair
|
|
|
|
|
|
|
|
func (s LabelPairSorter) Len() int {
|
|
|
|
return len(s)
|
|
|
|
}
|
|
|
|
|
|
|
|
func (s LabelPairSorter) Swap(i, j int) {
|
|
|
|
s[i], s[j] = s[j], s[i]
|
|
|
|
}
|
|
|
|
|
|
|
|
func (s LabelPairSorter) Less(i, j int) bool {
|
|
|
|
return s[i].GetName() < s[j].GetName()
|
|
|
|
}
|
|
|
|
|
|
|
|
type hashSorter []uint64
|
|
|
|
|
|
|
|
func (s hashSorter) Len() int {
|
|
|
|
return len(s)
|
|
|
|
}
|
|
|
|
|
|
|
|
func (s hashSorter) Swap(i, j int) {
|
|
|
|
s[i], s[j] = s[j], s[i]
|
|
|
|
}
|
|
|
|
|
|
|
|
func (s hashSorter) Less(i, j int) bool {
|
|
|
|
return s[i] < s[j]
|
2012-05-24 22:02:44 +04:00
|
|
|
}
|
Allow error reporting during metrics collection and simplify Register().
Both are interface changes I want to get in before public
announcement. They only break rare usage cases, and are always easy to
fix, but still we want to avoid breaking changes after a wider
announcement of the project.
The change of Register() simply removes the return of the Collector,
which nobody was using in practice. It was just bloating the call
syntax. Note that this is different from RegisterOrGet(), which is
used at various occasions where you want to register something that
might or might not be registered already, but if it is, you want the
previously registered Collector back (because that's the relevant
one).
WRT error reporting: I first tried the obvious way of letting the
Collector methods Describe() and Collect() return error. However, I
had to conclude that that bloated _many_ calls and their handling in
very obnoxious ways. On the other hand, the case where you actually
want to report errors during registration or collection is very
rare. Hence, this approach has the wrong trade-off. The approach taken
here might at first appear clunky but is in practice quite handy,
mostly because there is almost no change for the "normal" case of "no
special error handling", but also because it plays well with the way
descriptors and metrics are handled (via channels).
Explaining the approach in more detail:
- During registration / describe: Error handling was actually already
in place (for invalid descriptors, which carry an error anyway). I
only added a convenience function to create an invalid descriptor
with a given error on purpose.
- Metrics are now treated in a similar way. The Write method returns
an error now (the only change in interface). An "invalid metric" is
provided that can be sent via the channel to signal that that metric
could not be collected. It alse transports an error.
NON-GOALS OF THIS COMMIT:
This is NOT yet the major improvement of the whole registry part,
where we want a public Registry interface and plenty of modular
configurations (for error handling, various auto-metrics, http
instrumentation, testing, ...). However, we can do that whole thing
without breaking existing interfaces. For now (which is a significant
issue) any error during collection will either cause a 500 HTTP
response or a panic (depending on registry config). Later, we
definitely want to have a possibility to skip (and only report
somehow) non-collectible metrics instead of aborting the whole scrape.
2015-01-12 21:16:09 +03:00
|
|
|
|
|
|
|
type invalidMetric struct {
|
2015-11-27 17:56:42 +03:00
|
|
|
desc Desc
|
Allow error reporting during metrics collection and simplify Register().
Both are interface changes I want to get in before public
announcement. They only break rare usage cases, and are always easy to
fix, but still we want to avoid breaking changes after a wider
announcement of the project.
The change of Register() simply removes the return of the Collector,
which nobody was using in practice. It was just bloating the call
syntax. Note that this is different from RegisterOrGet(), which is
used at various occasions where you want to register something that
might or might not be registered already, but if it is, you want the
previously registered Collector back (because that's the relevant
one).
WRT error reporting: I first tried the obvious way of letting the
Collector methods Describe() and Collect() return error. However, I
had to conclude that that bloated _many_ calls and their handling in
very obnoxious ways. On the other hand, the case where you actually
want to report errors during registration or collection is very
rare. Hence, this approach has the wrong trade-off. The approach taken
here might at first appear clunky but is in practice quite handy,
mostly because there is almost no change for the "normal" case of "no
special error handling", but also because it plays well with the way
descriptors and metrics are handled (via channels).
Explaining the approach in more detail:
- During registration / describe: Error handling was actually already
in place (for invalid descriptors, which carry an error anyway). I
only added a convenience function to create an invalid descriptor
with a given error on purpose.
- Metrics are now treated in a similar way. The Write method returns
an error now (the only change in interface). An "invalid metric" is
provided that can be sent via the channel to signal that that metric
could not be collected. It alse transports an error.
NON-GOALS OF THIS COMMIT:
This is NOT yet the major improvement of the whole registry part,
where we want a public Registry interface and plenty of modular
configurations (for error handling, various auto-metrics, http
instrumentation, testing, ...). However, we can do that whole thing
without breaking existing interfaces. For now (which is a significant
issue) any error during collection will either cause a 500 HTTP
response or a panic (depending on registry config). Later, we
definitely want to have a possibility to skip (and only report
somehow) non-collectible metrics instead of aborting the whole scrape.
2015-01-12 21:16:09 +03:00
|
|
|
err error
|
|
|
|
}
|
|
|
|
|
|
|
|
// NewInvalidMetric returns a metric whose Write method always returns the
|
2015-11-27 17:56:42 +03:00
|
|
|
// provided error, and whose descriptor is invalid, carrying the provided
|
|
|
|
// error. It is useful if a Collector finds itself unable to collect a metric
|
|
|
|
// and wishes to report an error to the registry.
|
|
|
|
func NewInvalidMetric(err error) Metric {
|
|
|
|
return &invalidMetric{NewInvalidDesc(err), err}
|
Allow error reporting during metrics collection and simplify Register().
Both are interface changes I want to get in before public
announcement. They only break rare usage cases, and are always easy to
fix, but still we want to avoid breaking changes after a wider
announcement of the project.
The change of Register() simply removes the return of the Collector,
which nobody was using in practice. It was just bloating the call
syntax. Note that this is different from RegisterOrGet(), which is
used at various occasions where you want to register something that
might or might not be registered already, but if it is, you want the
previously registered Collector back (because that's the relevant
one).
WRT error reporting: I first tried the obvious way of letting the
Collector methods Describe() and Collect() return error. However, I
had to conclude that that bloated _many_ calls and their handling in
very obnoxious ways. On the other hand, the case where you actually
want to report errors during registration or collection is very
rare. Hence, this approach has the wrong trade-off. The approach taken
here might at first appear clunky but is in practice quite handy,
mostly because there is almost no change for the "normal" case of "no
special error handling", but also because it plays well with the way
descriptors and metrics are handled (via channels).
Explaining the approach in more detail:
- During registration / describe: Error handling was actually already
in place (for invalid descriptors, which carry an error anyway). I
only added a convenience function to create an invalid descriptor
with a given error on purpose.
- Metrics are now treated in a similar way. The Write method returns
an error now (the only change in interface). An "invalid metric" is
provided that can be sent via the channel to signal that that metric
could not be collected. It alse transports an error.
NON-GOALS OF THIS COMMIT:
This is NOT yet the major improvement of the whole registry part,
where we want a public Registry interface and plenty of modular
configurations (for error handling, various auto-metrics, http
instrumentation, testing, ...). However, we can do that whole thing
without breaking existing interfaces. For now (which is a significant
issue) any error during collection will either cause a 500 HTTP
response or a panic (depending on registry config). Later, we
definitely want to have a possibility to skip (and only report
somehow) non-collectible metrics instead of aborting the whole scrape.
2015-01-12 21:16:09 +03:00
|
|
|
}
|
|
|
|
|
2015-11-27 17:56:42 +03:00
|
|
|
func (m *invalidMetric) Desc() Desc { return m.desc }
|
Allow error reporting during metrics collection and simplify Register().
Both are interface changes I want to get in before public
announcement. They only break rare usage cases, and are always easy to
fix, but still we want to avoid breaking changes after a wider
announcement of the project.
The change of Register() simply removes the return of the Collector,
which nobody was using in practice. It was just bloating the call
syntax. Note that this is different from RegisterOrGet(), which is
used at various occasions where you want to register something that
might or might not be registered already, but if it is, you want the
previously registered Collector back (because that's the relevant
one).
WRT error reporting: I first tried the obvious way of letting the
Collector methods Describe() and Collect() return error. However, I
had to conclude that that bloated _many_ calls and their handling in
very obnoxious ways. On the other hand, the case where you actually
want to report errors during registration or collection is very
rare. Hence, this approach has the wrong trade-off. The approach taken
here might at first appear clunky but is in practice quite handy,
mostly because there is almost no change for the "normal" case of "no
special error handling", but also because it plays well with the way
descriptors and metrics are handled (via channels).
Explaining the approach in more detail:
- During registration / describe: Error handling was actually already
in place (for invalid descriptors, which carry an error anyway). I
only added a convenience function to create an invalid descriptor
with a given error on purpose.
- Metrics are now treated in a similar way. The Write method returns
an error now (the only change in interface). An "invalid metric" is
provided that can be sent via the channel to signal that that metric
could not be collected. It alse transports an error.
NON-GOALS OF THIS COMMIT:
This is NOT yet the major improvement of the whole registry part,
where we want a public Registry interface and plenty of modular
configurations (for error handling, various auto-metrics, http
instrumentation, testing, ...). However, we can do that whole thing
without breaking existing interfaces. For now (which is a significant
issue) any error during collection will either cause a 500 HTTP
response or a panic (depending on registry config). Later, we
definitely want to have a possibility to skip (and only report
somehow) non-collectible metrics instead of aborting the whole scrape.
2015-01-12 21:16:09 +03:00
|
|
|
|
|
|
|
func (m *invalidMetric) Write(*dto.Metric) error { return m.err }
|