metrics: refactor metrics (#28035)
This change includes a lot of things, listed below.
### Split up interfaces, write vs read
The interfaces have been split up into one write-interface and one read-interface, with `Snapshot` being the gateway from write to read. This simplifies the semantics _a lot_.
Example of splitting up an interface into one readonly 'snapshot' part, and one updatable writeonly part:
```golang
type MeterSnapshot interface {
Count() int64
Rate1() float64
Rate5() float64
Rate15() float64
RateMean() float64
}
// Meters count events to produce exponentially-weighted moving average rates
// at one-, five-, and fifteen-minutes and a mean rate.
type Meter interface {
Mark(int64)
Snapshot() MeterSnapshot
Stop()
}
```
### A note about concurrency
This PR makes the concurrency model clearer. We have actual meters and snapshot of meters. The `meter` is the thing which can be accessed from the registry, and updates can be made to it.
- For all `meters`, (`Gauge`, `Timer` etc), it is assumed that they are accessed by different threads, making updates. Therefore, all `meters` update-methods (`Inc`, `Add`, `Update`, `Clear` etc) need to be concurrency-safe.
- All `meters` have a `Snapshot()` method. This method is _usually_ called from one thread, a backend-exporter. But it's fully possible to have several exporters simultaneously: therefore this method should also be concurrency-safe.
TLDR: `meter`s are accessible via registry, all their methods must be concurrency-safe.
For all `Snapshot`s, it is assumed that an individual exporter-thread has obtained a `meter` from the registry, and called the `Snapshot` method to obtain a readonly snapshot. This snapshot is _not_ guaranteed to be concurrency-safe. There's no need for a snapshot to be concurrency-safe, since exporters should not share snapshots.
Note, though: that by happenstance a lot of the snapshots _are_ concurrency-safe, being unmutable minimal representations of a value. Only the more complex ones are _not_ threadsafe, those that lazily calculate things like `Variance()`, `Mean()`.
Example of how a background exporter typically works, obtaining the snapshot and sequentially accessing the non-threadsafe methods in it:
```golang
ms := metric.Snapshot()
...
fields := map[string]interface{}{
"count": ms.Count(),
"max": ms.Max(),
"mean": ms.Mean(),
"min": ms.Min(),
"stddev": ms.StdDev(),
"variance": ms.Variance(),
```
TLDR: `snapshots` are not guaranteed to be concurrency-safe (but often are).
### Sample changes
I also changed the `Sample` type: previously, it iterated the samples fully every time `Mean()`,`Sum()`, `Min()` or `Max()` was invoked. Since we now have readonly base data, we can just iterate it once, in the constructor, and set all four values at once.
The same thing has been done for runtimehistogram.
### ResettingTimer API
Back when ResettingTImer was implemented, as part of https://github.com/ethereum/go-ethereum/pull/15910, Anton implemented a `Percentiles` on the new type. However, the method did not conform to the other existing types which also had a `Percentiles`.
1. The existing ones, on input, took `0.5` to mean `50%`. Anton used `50` to mean `50%`.
2. The existing ones returned `float64` outputs, thus interpolating between values. A value-set of `0, 10`, at `50%` would return `5`, whereas Anton's would return either `0` or `10`.
This PR removes the 'new' version, and uses only the 'legacy' percentiles, also for the ResettingTimer type.
The resetting timer snapshot was also defined so that it would expose the internal values. This has been removed, and getters for `Max, Min, Mean` have been added instead.
### Unexport types
A lot of types were exported, but do not need to be. This PR unexports quite a lot of them.
1 year ago
|
|
|
# TYPE system_cpu_schedlatency_count counter
|
|
|
|
system_cpu_schedlatency_count 5645
|
|
|
|
|
|
|
|
# TYPE system_cpu_schedlatency summary
|
|
|
|
system_cpu_schedlatency {quantile="0.5"} 0
|
|
|
|
system_cpu_schedlatency {quantile="0.75"} 7168
|
|
|
|
system_cpu_schedlatency {quantile="0.95"} 1.6777216e+07
|
|
|
|
system_cpu_schedlatency {quantile="0.99"} 2.9360128e+07
|
|
|
|
system_cpu_schedlatency {quantile="0.999"} 3.3554432e+07
|
|
|
|
system_cpu_schedlatency {quantile="0.9999"} 3.3554432e+07
|
|
|
|
|
|
|
|
# TYPE system_memory_pauses_count counter
|
|
|
|
system_memory_pauses_count 14
|
|
|
|
|
|
|
|
# TYPE system_memory_pauses summary
|
|
|
|
system_memory_pauses {quantile="0.5"} 32768
|
|
|
|
system_memory_pauses {quantile="0.75"} 57344
|
|
|
|
system_memory_pauses {quantile="0.95"} 196608
|
|
|
|
system_memory_pauses {quantile="0.99"} 196608
|
|
|
|
system_memory_pauses {quantile="0.999"} 196608
|
|
|
|
system_memory_pauses {quantile="0.9999"} 196608
|
|
|
|
|
|
|
|
# TYPE test_counter gauge
|
|
|
|
test_counter 12345
|
|
|
|
|
|
|
|
# TYPE test_counter_float64 gauge
|
|
|
|
test_counter_float64 54321.98
|
|
|
|
|
|
|
|
# TYPE test_gauge gauge
|
|
|
|
test_gauge 23456
|
|
|
|
|
|
|
|
# TYPE test_gauge_float64 gauge
|
|
|
|
test_gauge_float64 34567.89
|
|
|
|
|
|
|
|
# TYPE test_gauge_info gauge
|
|
|
|
test_gauge_info {arch="amd64", commit="7caa2d8163ae3132c1c2d6978c76610caee2d949", os="linux", protocol_versions="64 65 66", version="1.10.18-unstable"} 1
|
|
|
|
|
|
|
|
# TYPE test_histogram_count counter
|
|
|
|
test_histogram_count 3
|
|
|
|
|
|
|
|
# TYPE test_histogram summary
|
|
|
|
test_histogram {quantile="0.5"} 2
|
|
|
|
test_histogram {quantile="0.75"} 3
|
|
|
|
test_histogram {quantile="0.95"} 3
|
|
|
|
test_histogram {quantile="0.99"} 3
|
|
|
|
test_histogram {quantile="0.999"} 3
|
|
|
|
test_histogram {quantile="0.9999"} 3
|
|
|
|
|
|
|
|
# TYPE test_meter gauge
|
|
|
|
test_meter 0
|
|
|
|
|
|
|
|
# TYPE test_resetting_timer_count counter
|
|
|
|
test_resetting_timer_count 6
|
|
|
|
|
|
|
|
# TYPE test_resetting_timer summary
|
metrics: refactor metrics (#28035)
This change includes a lot of things, listed below.
### Split up interfaces, write vs read
The interfaces have been split up into one write-interface and one read-interface, with `Snapshot` being the gateway from write to read. This simplifies the semantics _a lot_.
Example of splitting up an interface into one readonly 'snapshot' part, and one updatable writeonly part:
```golang
type MeterSnapshot interface {
Count() int64
Rate1() float64
Rate5() float64
Rate15() float64
RateMean() float64
}
// Meters count events to produce exponentially-weighted moving average rates
// at one-, five-, and fifteen-minutes and a mean rate.
type Meter interface {
Mark(int64)
Snapshot() MeterSnapshot
Stop()
}
```
### A note about concurrency
This PR makes the concurrency model clearer. We have actual meters and snapshot of meters. The `meter` is the thing which can be accessed from the registry, and updates can be made to it.
- For all `meters`, (`Gauge`, `Timer` etc), it is assumed that they are accessed by different threads, making updates. Therefore, all `meters` update-methods (`Inc`, `Add`, `Update`, `Clear` etc) need to be concurrency-safe.
- All `meters` have a `Snapshot()` method. This method is _usually_ called from one thread, a backend-exporter. But it's fully possible to have several exporters simultaneously: therefore this method should also be concurrency-safe.
TLDR: `meter`s are accessible via registry, all their methods must be concurrency-safe.
For all `Snapshot`s, it is assumed that an individual exporter-thread has obtained a `meter` from the registry, and called the `Snapshot` method to obtain a readonly snapshot. This snapshot is _not_ guaranteed to be concurrency-safe. There's no need for a snapshot to be concurrency-safe, since exporters should not share snapshots.
Note, though: that by happenstance a lot of the snapshots _are_ concurrency-safe, being unmutable minimal representations of a value. Only the more complex ones are _not_ threadsafe, those that lazily calculate things like `Variance()`, `Mean()`.
Example of how a background exporter typically works, obtaining the snapshot and sequentially accessing the non-threadsafe methods in it:
```golang
ms := metric.Snapshot()
...
fields := map[string]interface{}{
"count": ms.Count(),
"max": ms.Max(),
"mean": ms.Mean(),
"min": ms.Min(),
"stddev": ms.StdDev(),
"variance": ms.Variance(),
```
TLDR: `snapshots` are not guaranteed to be concurrency-safe (but often are).
### Sample changes
I also changed the `Sample` type: previously, it iterated the samples fully every time `Mean()`,`Sum()`, `Min()` or `Max()` was invoked. Since we now have readonly base data, we can just iterate it once, in the constructor, and set all four values at once.
The same thing has been done for runtimehistogram.
### ResettingTimer API
Back when ResettingTImer was implemented, as part of https://github.com/ethereum/go-ethereum/pull/15910, Anton implemented a `Percentiles` on the new type. However, the method did not conform to the other existing types which also had a `Percentiles`.
1. The existing ones, on input, took `0.5` to mean `50%`. Anton used `50` to mean `50%`.
2. The existing ones returned `float64` outputs, thus interpolating between values. A value-set of `0, 10`, at `50%` would return `5`, whereas Anton's would return either `0` or `10`.
This PR removes the 'new' version, and uses only the 'legacy' percentiles, also for the ResettingTimer type.
The resetting timer snapshot was also defined so that it would expose the internal values. This has been removed, and getters for `Max, Min, Mean` have been added instead.
### Unexport types
A lot of types were exported, but do not need to be. This PR unexports quite a lot of them.
1 year ago
|
|
|
test_resetting_timer {quantile="0.50"} 1.25e+07
|
|
|
|
test_resetting_timer {quantile="0.95"} 1.2e+08
|
|
|
|
test_resetting_timer {quantile="0.99"} 1.2e+08
|
|
|
|
|
|
|
|
# TYPE test_timer_count counter
|
|
|
|
test_timer_count 6
|
|
|
|
|
|
|
|
# TYPE test_timer summary
|
|
|
|
test_timer {quantile="0.5"} 2.25e+07
|
|
|
|
test_timer {quantile="0.75"} 4.8e+07
|
|
|
|
test_timer {quantile="0.95"} 1.2e+08
|
|
|
|
test_timer {quantile="0.99"} 1.2e+08
|
|
|
|
test_timer {quantile="0.999"} 1.2e+08
|
|
|
|
test_timer {quantile="0.9999"} 1.2e+08
|
|
|
|
|